roboforum.ru

отдельный сервоконтроллер делать? удорожание опять же... + только в том что плату с н мостами тупо не ставить вместо того чтоб не запаять компоненты ..

Duhas писал(а):отдельный сервоконтроллер делать? удорожание опять же... + только в том что плату с н мостами тупо не ставить вместо того чтоб не запаять компоненты ..

Не понял, а на основном контроллере почему сервоконтроллер нельзя сделать? 3-4 сервами рулить много не сожрёт вычислительной мощности, а если надо шестинога делать - тогда открутите нафиг драйвер двигателей (вам он зачем в этом проекте?) и поставьте на его место отдельный сервоконтроллер.

Поддержу Dead - сервы тут нафиг не уперлись, если уж нужны и много - делать отдельный сервоконтроллер, а малым количеством и основной контроллер прекрасно порулит

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

да и допустим бот с 2-мя манипуляторами... по 3 степени свобды + схват... 8 серв... 1 модуль - рулез... вопрос вывезет ли ...

Правильно организованное управление полутора десятками серв занимает ~5% процессорного времени. Эту тему уже обсосали во всех подробностях, к чему повторяться.

вот я и тру о том чтобы повесить все на 1 модуль ..

Так я не понял, чего тут тереть, предложение простое, сделать 3 платы:
1. Головная плата минибота-про, в которой мощный МК + базовый набор выводов для датчиков и серв (скажем 8 выводов из под АЦП + 8 выводов цифровых) + разъемы для подключения всего остального;
2. Плата драйвера двигателей (с конвертером питания в очищенное, прямо на борту) - это для колёсных\гусеничных роботов;
3. Плата сервоприводов (с конвертером питания в очищенное, прямо на борту) - это для ногастых роботов;

Либо присоединись, либо скажи чего не нравится!

=DeaD= писал(а):Так я не понял, чего тут тереть, предложение простое, сделать 3 платы:
1. Головная плата минибота-про, в которой мощный МК + базовый набор выводов для датчиков и серв (скажем 8 выводов из под АЦП + 8 выводов цифровых) + разъемы для подключения всего остального;
2. Плата драйвера двигателей (с конвертером питания в очищенное, прямо на борту) - это для колёсных\гусеничных роботов;
3. Плата сервоприводов (с конвертером питания в очищенное, прямо на борту) - это для ногастых роботов;

Либо присоединись, либо скажи чего не нравится!

+1

ладно уговорили, тем более что плата ДД будет меньше из-за механики...

но SPI на шину нада...

итак какие функции нужны в плане софта?

Какая такая шина и зачем там SPI?

Про функции в плане софта - сделать тупое управление движками + очередь команд как у меня в модуле [[Шлюз-контроллер GATE-A8D8M2]], чтобы можно было на ДД переложить задачу движения по траектории.

я считаю что системной шине минибота быть

Объясни зачем? Давайте блин еще на каждый сонар из этого проекта выведем системную шину минибота.

сонары собираются в группу и вешаются на шину: в зависимости от их интерфеса или вешаем доп контроллер, если i2c то в кучу их и на шину...

шина нужна заетм, чтобы ЛЮБОЕ устройство можно было повесить и не ограничивать возможности соединения с центральным МК.. тут ПК как пример очень подходит, имея более или менее современный ПК можно не особо задумываясь над совместимостью выбирать кмплектующие, потому что была сделана универсальная шина... в нашем случае также... кто-то хочет общаться с модулями по СПИ кто-то по и2ц, кто-то вообще свой протокол захочет сделать...

Duhas писал(а):шина нужна заетм, чтобы ЛЮБОЕ устройство можно было повесить и не ограничивать возможности соединения с центральным МК.. тут ПК как пример очень подходит, имея более или менее современный ПК можно не особо задумываясь над совместимостью выбирать кмплектующие, потому что была сделана универсальная шина... в нашем случае также... кто-то хочет общаться с модулями по СПИ кто-то по и2ц, кто-то вообще свой протокол захочет сделать...

И почему это только тогда принтеры, сканеры, мониторы, мыши, клавы, джойстики, колонки, приводы НГМД, жесткие диски, оптические приводы и прочие прелести не втыкаются прямо в системную шину? Потому что это нецелесообразно. Да и используют шину тогда, когда надо засунуть девайс внутрь корпуса или нужна огромная пропускная способность. Скажите зачем это всё драйверу двигателей?

Это я к тому - что буржуи давно делают контроллер двигателей на i2c шине и не жужжат. Но мы видимо круче - нас неустраивает готовая рабочая концепция, нам надо всё усложнить и сделать очень неопределенным. Зачем? Драйвер двигателей подавляющему большинству людей надо просто использовать. Подцепил и работай. Мы же вроде не конструктор делаем для разработчиков драйверов двигателей?

PS: Сонары весь цивилизованный мир тоже уже на шину i2c вешает, а если денег нету, тогда делает один МК который рулит кучей сонаров. Но никто никогда не вешает их на какую-то загадочную общую шину. Потому что тупо у нас тут вместе взятых не хватит компетенции эту шину грамотно сделать, поэтому зачем вообще влезать? Будет бардак и полная несовместимость - один этот пин для себя использует и второй тоже и уже два компонента вместе не заработают никогда.

=DeaD= писал(а):буржуи давно делают контроллер двигателей на i2c шине и не жужжат.

Примеры модулей у Девантеч и у них же примеры как общаться с модулями. И http://OpenServo.org