Простой управляемый моторчик.

uaha1979

Мне нужно подсоединить к ПК 20 маленьких моторчиков (угловая скорость не больше 100 об/сек, моторчики на подобии тех, что в радиоуправляемых машинках стоят, нагрузка на ось будет меньше чем в машинках).
Угловая скорость моторчиков должна регулироваться с ПК, угловая скорость будет постоянно меняться, заранее не известно как именно.
ОС на ПК семейства linux.
Появились вопросы:
1. Какие моторчики стоит выбрать.
2. (Архитектура) К какой шине/шинам подключить?
Где об этом можно почитать?

margadon

бугага...
ну, я бы собрал на нескольких микроконтроллерах плату с ШИМ-выходами, этими выходами нагрузил бы полные мосты из MOSFET-ов для управления моторчиками (есть подозрение, что управление моторчиками должно поддерживать реверс?)... потом c этим всем бы общался через uart по USB. Гемора довольно много
Есть, вероятно, специализиорванные микросхемы для многоканального ШИМ-управления
вообше нихрена не простой проект :(

yroslavasako

я знаю как это делается в индустрии. Но думаю от цен на промышленное оборудование у автора может случится приступ жлобства

VitMix

Думаю надо что-то из этой серии: http://www.pc-control.co.uk/motorbee_info.htm
Или из этой: http://www.pololu.com/catalog/product/390

Dasar

Какая требуется скорость реакции и надежность? Как часто хочется менять скорость моторчиков? Насколько критично, если управляющая программа "забудет" или не успеет поменять скорость моторчика (например, один раз из тысячи)?

uaha1979

Какая требуется скорость реакции и надежность? Как часто хочется менять скорость моторчиков? Насколько критично, если управляющая программа "забудет" или не успеет поменять скорость моторчика (например, один раз из тысячи)?
Скорость реакции примерно 0.1 секунды.
Надежность нужна сильно.
Скорость меняется постоянно.
В этом случае управляющей программе придет оповещение: "движение нужно корректировать дальше"

yolki

шина - LPT, COM, USB
попробуй почитать про программирование микроконтроллеров. ключевые слова - AVR, PIC
особливо - пролистай тематические блоги на хабре: контроллеры, сделай сам
если не испугаешься возможного гемора с изготовлением печатной платы - то можно посмотреть на ARM типа STM32. для армов просто не совсем просто изготовить разводку, в кустарных условиях без опыта даже пробовать не стоит.
девборда от 1000 рублей. вона - одних GPIO штук 80
теоретически на эту девборду можно вкорячить линукс, но там вроде нету MMU, так что придётся повозиться.

uaha1979

Думаю надо что-то из этой серии: http://www.pc-control.co.uk/motorbee_info.htm
Или из этой: http://www.pololu.com/catalog/product/390
Спасибо, вечерком почитаю.
Спасибо, всем, кто отписался (и возможно еще отпишется
Я планировал следующую последовательность:
Разобрать USB кулер/вентилятор.
Разобрать радио-управляемую машинку.
Разобрать радио-управляемый вертолет.
Делать схему самому. =)
Сейчас почитаю ссылки, может смогу себе время сэкономить. =)

yolki

с моторами уже определились?
если нужна точность позиционирования, момент (сила поворота и удержания) и не очень важна скорость, то советую посмотреть на шаговые моторы (stepper motors с соответствующими драйверами.
там у мотора 4-5-6 ног (2-4 обмотки но достаточно бывает 2 выводов с контроллера задействовать: первый - направление вращения, второй - импульс поворота, многие моторы 200 шагов/оборот - 1.8⁰/step

tokuchu

А звуковой картой нельзя генерировать нужные сигналы? Как вариант.

Anna551

Есть казуальная платформа arduino которая на халяву дает удобный интерфейс для работы со сторонними девайсами. судя по описаниям различных проектов - характеристики неплохие

tokuchu

Кстати, вот тут предлагался один из девайсов за 80$ (пусть будет 2400 р) с 16 каналами. Это 150 рублей/канал.
Звуковуху сейчас посмотрел самую дешёвую в Олди — 600 рублей 6-канальная. Это 100 рублей/канал.
Ещё в википедии посмотрел — есть Arduino ADK с 16 аналоговыми каналами, стоит 50 евро (2000 рублей т.е. подешевле первого девайса и помимо этого ещё разные выходы там есть. Здесь 125 рублей/канал.
PS. Хотя я в этом мало что понимаю и возможно сравниваю несравниваемое. :)

Dasar

Звуковуху сейчас посмотрел самую дешёвую в Олди — 600 рублей 6-канальная. Это 100 рублей/канал.
Надо смотреть насколько выходы защищены от перегрузки, в хороших модулях - входы/выходы вообще гальванически развязаны (через оптику).

tokuchu

Надо смотреть насколько выходы защищены от перегрузки, в хороших модулях - входы/выходы вообще гальванически развязаны (через оптику).
Ну так у аналогов тоже сомнительно наличие защиты.

Dasar

Кстати, вот тут предлагался один из девайсов за 80$ (пусть будет 2400 р) с 16 каналами. Это 150 рублей/канал
кстати, там 32 канала, что дает 75руб/канал. Защиты - да, нету.
В плюс, по сравнению со стандартной звуковухой - кол-во легко наращивать, т.к. подключение usb-ишное.
на Arduino Adk 16 аналоговых входов, а не выходов
зы
вообще, звуковуха интересный вариант, т.к. за счет объема продаж может быть дешевле других решений, но необходимо смотреть детальнее

margadon

а то что там каналы для сервомоторов вас не смущает? чтобы этим питать обычные моторчики придётся потрудиться

yolki

Кстати, если нет опыта работы ни с какой платформой и есть желание освоить что-нибудь эдакое - советую посмотреть на MSP430.
девборда есть за 4.30$. С доставкой FedEx-ом в течение недели до квартиры :)
в комплекте девборды - два микроконтроллера, с каждого можно использовать по 14 выводов. Освоив платформу, можно взять другой контроллер этой же архитектуры, с бОльшим количествам GPIO
в качестве бонуса - высококачественные многоканальные АЦП ;)

Dasar

два микроконтроллера
Зачем здесь микроконтроллер? Комп же есть. Нужен только модуль выводов.

yolki

ну с компа много линий не снять. LPT? там максимум 12 по-моему, на порт.
или предлагаешь шифт-регистры использовать?

Dasar

а то что там каналы для сервомоторов вас не смущает? чтобы этим питать обычные моторчики придётся потрудиться
имхо, моторчики лучше запитывать самостоятельно, а выходы использовать чисто как управляющие.

Dasar

ну с компа много линий не снять. LPT? там максимум 12 по-моему, на порт.
или предлагаешь шифт-регистры использовать?
Я про то, что есть "коробки", которые просто добавляют компу входы/выходы, и эти коробки не надо программировать - их втыкаешь и они работают. Вся управляющая логика пишется на компе на произвольном языке программирования.
В треде, например, упоминали:
http://www.pololu.com/catalog/product/390
Или из "попсы":
http://www.icpdas.com.tw/product/solutions/pc_based_io_board...
http://www.moxa.com/product/ioLogik_E1241.htm
Основное преимущество, что при этом не требуются навыки низкоуровневого программирования, и что работа с ними под силу произвольному человеку хоть как-то знакомому с автоматизацией.

kiracher

Большинство выше предложенных вариантов достаточно затратно.
Исходя из относительно большого времени отклика (0.1с) и множества выходных аналоговых каналов (20) в отсутствие входных предложу свой низко-затратный вариант не привязанный к какому либо софту или оси вообще. Это линейка из 20 фотодиодов, прикрепленная к монитору, соответственно с 20ю усилителями для управления 20 драйверами (которые нужны в любом случае). Светлей какой то кусок экрана - быстрее крутится моторчик. Требуется реверсивное управление - значит 40 фотодиодов.
Фотодиоды можно взять со встроенными усилителями тока, тогда это вообще лафа, система собирается буквально за день. Программируется на чем угодно, хоть на яваскрипте в браузере.

Dasar

Светлей какой то кусок экрана - быстрее крутится моторчик. Требуется реверсивное управление - значит 40 фотодиодов.
Это совсем для нищебродов. Система адски неустойчива. Например, вывод messagebox-а на экран приведет к "взлету" моторчиков.

tokuchu

Например, вывод messagebox-а на экран приведет к "взлету" моторчиков.
Я думаю без венды уж обойтись точно можно будет. :)

Dasar

Я думаю без венды уж обойтись точно можно будет. :)
ты так говоришь, как будто сообщения об ошибках выводятся на экран только в виндоусе.

tokuchu

ты так говоришь, как будто сообщения об ошибках выводятся на экран только в виндоусе.
Ну если говорить вообще, а не про частности то в Линуксе с этим проблем не должно быть.

Dasar

Ну если говорить вообще, а не про частности то в Линуксе с этим проблем не должно быть.
гарантия будет только в консоли в эксклюзивном режиме и если stderr сливать в файл или в /dev/null

tokuchu

гарантия будет только в консоли в эксклюзивном режиме и если stderr сливать в файл или в /dev/null
А не в консоли откуда это окошко с сообщением возьмётся? Свистелки и перделки никто не обязывает запускать.

Dasar

А не в консоли откуда это окошко с сообщением возьмётся? Свистелки и перделки никто не обязывает запускать.
Из ПО которое о данном требовании ничего не знает. Например, tooltip-ы тоже отключишь во всём ПО?

yolki

у меня оконный менеджер тултипы не поддерживает :grin:

tokuchu

Из ПО которое о данном требовании ничего не знает. Например, tooltip-ы тоже отключишь во всём ПО?
Так зачем во всём, если нужно только свою прогу запускать будет? А она не должна ничего лишнего показывать.
Вроде как даже можно вообще без иксов через framebuffer показывать.

Dasar

Вроде как даже можно вообще без иксов через framebuffer показывать.
В итоге всё это выльется в создание велосипеда с квадратными колеса. И если уж создание велосипедов приводит к ужасным последствиям, то создание велосипедов с квадратными колесами - тем более.
И я верю, что некоторые энтузиасты могут ездить и на квадратных колесах, и что на open source-е проще создать велосипед с квадратными колесами.
зы
Этим и ужасно нищебродство в России. Вместо того чтобы потратить 200$ на готовый полуфабрикат и потом за пару дней создать нормальную надежную программу, которую легко поддерживать, какой-нибудь энтузиаст закопает пару человеко-лет своего труда на то, чтобы создать велосипед с квадратными колесами, а потом еще десяток человеко-лет окружающих на поддержку этого чуда.
При этом даже человеко-неделя труда стоит больше, чем 200$ (и это даже если тупо брать по средней зарплате). Или другими словами, для всех выгоднее будет, если чел две недели подколымит и купит готовый полуфабрикат на свои деньги вместо того, что он месяц своего труда закопает в создание непонятно чего.

yroslavasako

Вроде как даже можно вообще без иксов через framebuffer показывать.
ну это радикально. Можно просто в иксах запустить нужную прогу без оконного менеджера.
Главное не выбрать винду, чтобы потом её героически преодолевать, в остальном работать будет

yroslavasako

Этим и ужасно нищебродство в России. Вместо того чтобы потратить 200$ на готовый полуфабрикат и потом за пару дней создать нормальную надежную программу, которую легко поддерживать, какой-нибудь энтузиаст закопает пару человеко-лет своего труда на то, чтобы создать велосипед с квадратными колесами, а потом еще десяток человеко-лет окружающих на поддержку этого чуда.
Придумывать как потрать 200$ за рисование пятен на экране дольше чем собственно писать приложение

Dasar

Ты уверен что вывести двадцать цветовых пятен на экран невозможно без затраты 200$?
Я уверен, что за неделю работы не получиться обеспечить, чтобы эти цветовые пятна гарантированно преобразовывались в заданный токовый сигнал с дискретностью 12 бит, при этом чтобы сигнал со значением 386 гарантированно отличался от сигнала 387.
Также не получится за это время обеспечить чтобы на этот процесс не влияли все окружающие факторы (риски):
 взаимная засветка,
 засветка от внешних источников,
 мерцание и разогрев ламп подсветки,
 тепловой шум от монитора,
 вывод на экран от другого кода
 и т.д.

kiracher

Я уверен, что за неделю работы не получиться обеспечить, чтобы эти цветовые пятна гарантированно преобразовывались в заданный токовый сигнал с дискретностью 12 бит, при этом чтобы сигнал со значением 386 гарантированно отличался от сигнала 387.
Также не получится за это время обеспечить чтобы на этот не процесс не влияли окружающие факторы: взаимная засветка, засветка от внешних источников, мерцание и разогрев ламп подсветки, тепловой шум от монитора и т.д.
Пипец ты упоротый. И почему 12 бит а не 16 например или 24? А защита от космического излучения или близкого ядерного взрыва? В исходной задаче про требования вообще ни слова, по отдельным намекам я предполагаю, что речь идет о роботизированной руке, положение которой определяется каким-то иным способом - например, через видеокамеры, а изменение скорости, про которой говорит ТС - не что иное, как обратная связь чтобы привести эту руку с многими степенями свободы в определенное положение. То есть вообще-то речь идет о сервоприводе, поэтому большая битность тут никакой роли не играет (разве чтобы подавить осцилляции исполнительного механизма главное знак не перепутать. Иначе ТС бы сразу говорил про шаговые двигатели, поскольку без обратной связи с простым коллекторным двигателем нет никакой возможности узнать текущее положение его ротора. Из чего и следует вывод что либо есть некая обратная связь, либо нет никакой опасности задать произвольные скорости и времена вращения движков - например, для изучения механических колебаний маятника с н-ным количеством возмущающих воздействий.
Я не настаиваю на этом решении, я просто предложил его в качестве одного из возможных решений, исходя только из представленной информации. Если у тебя есть другая дополнительная информация - выложи, обсудим. А то звуковая карта тебя устраивает, а фотодатчик - нет. Окошко тебе с тултипом мешает, а звук тултипа почему то нет.

Dasar

И почему 12 бит а не 16 например или 24?
Потому что это задает высокую планку качества решения. Хотя, конечно, некоторых устраивает качество уровня ВАЗ-а (одним не стыдно такое разрабатывать и производить, другим не стыдно таким пользоваться)...

margadon

я жду, когда ты уже предложишь золотые провода для передачи цифровых сигналов

Dasar

речь идет о роботизированной руке, положение которой определяется каким-то иным способом - например, через видеокамеры, а изменение скорости, про которой говорит ТС - не что иное, как обратная связь чтобы привести эту руку с многими степенями свободы в определенное положение.
И это означает, что основные исследования будут именно в этой области (в создании управляющего кода и распознавании сигнала с камер).
Других исследований при этом стоит избегать (в частности, стоит избегать одновременного исследования в области супербюджетной передачи сигналов цифра->аналог) - это позволит все трудовые ресурсы сфокусировать на решении одной проблемы, и избежать ситуации когда неточности одного исследования накладываются на неточности другого исследования, что приводит к постоянной борьбе с ошибками вместо продвижения к результату.

Dasar

я жду, когда ты уже предложишь золотые провода для передачи цифровых сигналов
Нет достоверных данных о ситуациях, когда золотые провода помогают.
При этом если планируются полевые испытания (или работа во влажной, а тем более в агрессивной среде - а такой средой может быть обычное полуподвальное помещение то золотые контакты здорово уменьшают головную боль от борьбы с "потерей контакта".

yroslavasako

помимо неокисляемости у золота есть ещё один большой плюс - меньший порог напряжения для начала передачи тока. То есть можно делать очень низковольтные управляющие линии

Dasar

Из личного опыта - наблюдал несколько ситуаций, когда человеко-месяцы высококлассных программистов (а это минимум 6000$/месяц по себестоимости для компании) тратятся на борьбу с дребезгом в передачи сигнала из-за того, что было жалко потратить несколько сотен баксов на создание опытного стенда из готовых полуфабрикатов.

Dasar

А то звуковая карта тебя устраивает, а фотодатчик - нет.
Звуковуха хотя бы изначально заточена под задачу преобразования цифра->аналоговый электрический сигнал, поэтому можно ожидать, что это она делает хорошо.
Хотя и здесь могут быть всякие подводные камни из-за того, что звуковуха затачивается под человеческое ухо, поэтому могут встраиваться всякие хардварные фильтры (под соусом - такие изменения ухо воспринимает положительно или наоборот какие-то проблемы могут игнорироваться ради удешевления (такое ухудшение сигнала ухо все равно не заметит, или таких изменений звука всё равно не бывает).
Соответственно, я и утверждаю, что звуковуху пробовать можно для такой задачи, но аккуратно - сначала протестировав как она справляется с поставленной задачей на всяких нештатных режимах.

margadon

kiracher

Не справится тут звуковуха, потому что постоянный ток она отрежет. По крайней мере у большинства выход через конденсатор. Другими словами, если поставить постоянную скорость вращения то моторчик тупо остановится. Придется частотой какой-то модулировать, а на выходе ставить соответственно фильтр. Можно скрестить кучку фильтров и посадить на один канал (стерео) 2 по 10 частот. Я обдумывал это вариант но он реально сложней в реализации и настройке, даже если взять несколько звуковых каналов и меньше частот на канал.
Советовать что-то типа купи usb-ttl на ft232, за ним посади пачку ЦАП на i2c/spi, а за ними дальше и сами драйвера - не знаю как к этому отнесется ТС, хотя это самый оптимальный путь. Ардуинка с ШИМ - один фиг, кучка фильтров (RC, хотя бы) плюс драйверы, но к ним еще плюс промежуточный слой в виде ардуинки. Генерить ШИМ программно с компа на цифровой порт - это убиться можно. Карта расширения на ЦАП самый правильный путь - но такая канальность - минимум 24 - дорого обойдется и с программированием могут быть проблемы, если библиотечка только для c/c++/nidaq/labview то геморрой может быть обеспечен. Вариантов много, но от ТС они все потребуют гораздо больше познаний в целевой области.

Dasar

Советовать что-то типа купи usb-ttl на ft232, за ним посади пачку ЦАП на i2c/spi, а за ними дальше и сами драйвера - не знаю как к этому отнесется ТС, хотя это самый оптимальный путь.
Во сколько времени ты оцениваешь сборку такого устройства (начиная от выбора и покупки комплектующих, заканчивая опытной эксплуатацией с выдачей сигналов из python-программы) и уровень зарплаты соответствующего специалиста, который это сможет поднять?
Карта расширения на ЦАП самый правильный путь - но такая канальность - минимум 24 - дорого обойдется и с программированием могут быть проблемы, если библиотечка только для c/c++/nidaq/labview то геморрой может быть обеспечен.
Текущая рыночная цена на промышленный серийный цап с доступом хоть через wget(http) - порядка 50$ за канал.
Имхо, даже 1200$ будет меньше стоимости работы потраченной на создание и обслуживание своего колхоза.

tokuchu

Я уверен, что за неделю работы не получиться обеспечить, чтобы эти цветовые пятна гарантированно преобразовывались в заданный токовый сигнал с дискретностью 12 бит, при этом чтобы сигнал со значением 386 гарантированно отличался от сигнала 387.
Также не получится за это время обеспечить чтобы на этот процесс не влияли все окружающие факторы (риски):
взаимная засветка,
засветка от внешних источников,
мерцание и разогрев ламп подсветки,
тепловой шум от монитора,
вывод на экран от другого кода
и т.д.
Это как-бы отдельный вопрос и обсуждался не он, а выскакивающие на винде окошки. На что я заметил, что это проблемой не является. В Линукс для того, чтобы они не выскакивали никаких квадратных колёс и велосипедов не нужно.
Что, конечно, не отменяет других проблем.

tokuchu

Не справится тут звуковуха, потому что постоянный ток она отрежет. По крайней мере у большинства выход через конденсатор.
А я думал что им пофигу, потому и предложил. Если так, то да, не получится.

kiracher

Во сколько времени ты оцениваешь сборку такого устройства (начиная от выбора и покупки комплектующих, заканчивая опытной эксплуатацией с выдачей сигналов из python-программы) и уровень зарплаты соответствующего специалиста, который это сможет поднять?
Так ведь все относительно и не только ценой все определяется. Например, посадить спеца возиться неделю над этой штукой всяко лучше чем ждать месяц поставки промышленной железки плюс еще пару дней тому же спецу разбираться. Не говоря уж о РФ/Москве, где разброс цен, сроков поставки и зарплат такой, что заранее предугадать что окажется более выгодным практически невозможно. Я не в курсе сколько ТС готов потратить времени и денег и что для него более важно, а ты?

Dasar

На что я заметил, что это проблемой не является.
Проблемой они не являются только, если о таких ситуациях знать и иметь навык по их не допущению, что подразумевает, что, человек который не съел на этом собаку, выдаст правильное решение только с n-ой попытки.

tokuchu

Проблемой они не являются только, если о таких ситуациях знать и иметь навык по их не допущению, что подразумевает, что, человек который не съел на этом собаку, выдаст правильное решение только с n-ой попытки.
Поэтому лучше не использовать Винду, т.к. там нужно ещё обладать сакральными знаниями о засадах которые она приготовила. :p

Dasar

Например, посадить спеца возиться неделю над этой штукой всяко лучше чем ждать месяц поставки промышленной железки плюс еще пару дней тому же спецу разбираться.
В случае если горят сроки, то да можно на коленке сначала сделать колхоз для экономии времени, но потом все равно его лучше заменить на готовое изделие (все окружающие за это скажут спасибо).
Я не в курсе сколько ТС готов потратить времени и денег и что для него более важно, а ты?
Поэтому я и привожу оценки и описания рисков, чтобы можно было сделать выбор с открытыми глазами, а также усиленно подчеркиваю тот факт, что большинство склонно сильно недооценивать стоимость своего времени, стоимость пропущенных рисков и стоимость обслуживания колхоза.

uaha1979

Прошу прощения что отсутствовал.
Отвечу на поставленные мне вопросы.
Да, это будет роботизированная рука.
Проект я планирую начинать через месяц - полтора, тему создал, чтобы знать с чем имею дело, когда это дело начинаю.
Денег можно потратить на это около 60000 рублей для начала, если пойдет дело то потрачу и больше, главное чтобы работало качественно.
Времени хочу потратить около года на создание (начиная от просто движения заканчивая движения в указанное место).
Со временем отклика я погорячился =) поставив 0.1 сек, посмотрю какое минимальное можно реализовать будет.
Я планирую такую реализацию:
есть у руки исходное положение, есть конечное,
разбиваем путь (из начала в конец) на n частей, когда "рука" проходит одну часть пути, смотрим в каком она положении, корректируем остальные части пути, переходим к следующей части пути.

kiracher

разбиваем путь (из начала в конец) на n частей, когда "рука" проходит одну часть пути, смотрим в каком она положении, корректируем остальные части пути, переходим к следующей части пути.
Как смотрим в каком положении оказалась рука? Полагаться на то что она окажется в расчетном положении не стоит, на более чем 1-2 степеней свободы люфтов будет столько что Азимов с основным принципом робототехники (не навреди человеку рядом!) в гробу перевернется.
Оптимальней всего на мой взгляд - использование шаговых двигателей, с микростепом на 4/8 импульсов на шаг, более менее определенная гарантия положения и демпфирование будет. Поэтому стоит поискать наборы для любительских cnc - там будет интерфейсная плата с 3-4 мя драйверами для шаговиков. Трудно предсказать можно ли будет сразу 5 таких комплектов использовать на одном компе (мало кому такое просто придет в голову но в принципе все проблемы решаемы.
Можно купить просто платки типа Pololu-A4983, плюс какой-то достаточно быстрый цифровой порт, они дешевые. На крайняк сгодится и lpt порт на pci. Несколько оборотов в секунду с учетом микростепа легко. Получить большую скорость без специального контроллера или программных ухищрений (реалтайм, ага) будет сложновато. Шаговики можно купить или выдрать откуда угодно, они дешевые. Основная проблема будет выдавать н-ное количество импульсов на определенной частоте для каждого канала, это не так просто как кажется, формально, на каждый канал должен быть свой счетчик импульсов со свом пред-делителем частоты.
С двигателями постоянного тока проблем будет ИМХО больше и управлять ими сложнее. А без обратной связи ничего хорошего все равно не получится.

yolki

кстати, попробуй заказать готовые простые манипуляторы, "поиграться", освоиться с механикой и управлением.
например
девборда на STM32, за 100$ с полным фаршем :shocked:
Оставить комментарий
Имя или ник:
Комментарий: