Разработка Open Robotics: Контроллер под сервы, SMD-вариант

=DeaD=

Сергей писал(а):

А насчет трехпиновых разъемов - если делают сервы под 5А с таким разъемом, значит все ок

Или значит, что считают, что ток 5А кратковременный и рабочий цикл не более 20% от общего времени

demoontz

если устройство окажеться лучше чем первоисточник, то я был бы заинтересован

только мне надо 30-32 выхода. и это только для серв...

зы: а что это за контролер такой на картинке интересный?

=DeaD=

30-32 выхода? куда?

Добавлено спустя 2 минуты 3 секунды:
Устройство будет лучше как минимум потому что можно будет на него повесить блютуз-модуль уже готовый - [[Модули Open Robotics и документация к ним]] и немедленно получить радиоуправляемого по блютузу шагающего робота

FireFly

на SSC-32 блютуз легко и непринужденно вешается, на сайте у разрабов есть мануал как все делается :wink:

=DeaD=

FireFly писал(а):

на SSC-32 блютуз легко и непринужденно вешается, на сайте у разрабов есть мануал как все делается :wink:

Ну вот, ты расстроил меня

ну тогда у нас можно в сам контроллер заливать развесистые программки, которые не будут тормозиться мильоном прерываний для управления сервами и у нас есть 8 GPIO портов (а не 4, как у SSC-32) и еще у нас есть нормальные разъемы i2c

blindman

demoontz писал(а):

зы: а что это за контролер такой на картинке интересный?

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

Добавлено спустя 4 минуты 32 секунды:
Проблема с SSC-32 в том, что в сам контроллер мало что можно зашить. Например чуть подлиннее обработчик прерываний от уарта сделал - и все, при обмене сколь-нибудь большими объемами данных сервы задергались. И такие проблемы будут у любого контроллера, у которого временные интервалы формируются в прерывании.

FireFly

=DeaD= писал(а):

Ну вот, ты расстроил меня

ну тогда у нас можно в сам контроллер заливать развесистые программки, которые не будут тормозиться мильоном прерываний для управления сервами и у нас есть 8 GPIO портов (а не 4, как у SSC-32) и еще у нас есть нормальные разъемы i2c

мощно конеш, но ИМХО лишнее, хотя кому как

Добавлено спустя 2 минуты 4 секунды:

blindman писал(а):

Проблема с SSC-32 в том, что в сам контроллер мало что можно зашить. Например чуть подлиннее обработчик прерываний от уарта сделал - и все, при обмене сколь-нибудь большими объемами данных сервы задергались. И такие проблемы будут у любого контроллера, у которого временные интервалы формируются в прерывании.

ИМХО нет у него ни каких проблем, у меня он прекрасно работает - ничего не дергается, свои задачи на 100% выполняет, притом на максимальной скорости обмена адекватно отрабатывает все команды. :wink:

blindman

Я говорю о том, что в нем программа, которая учитывает особенности выбранной системы управления. И кроме этой программы в него ничего не зашивается. А чтобы писать свою прошивку, надо тоже все эти особенности учитывать - а это накладывает определенные ограничения, в первую очередь на работу с прерываниями.

FireFly

а там просто своя прошивка нифиг не нужна, его дача основная исполнять команды на перемещение серв по уарту или сом-у + опционально он может в обратку передавать 4 сигнала, все... больше от него ничего не требуется и с этим девайс справляется прекрасно. Для управления ставим любой свой контроллер, либо тот же радиоканал до ПК и управляем. По сути оно контроллер двигателей :wink:

зачем, к примеру, контроллер двигателей грузить еще обработкой датчиков? нихай этим контроллер основной занимается

Сергей

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

=DeaD=

Обновление:

blindman

FireFly писал(а):

зачем, к примеру, контроллер двигателей грузить еще обработкой датчиков? нихай этим контроллер основной занимается

Мы так и делаем

Рулить сервами будет выделенный контроллер, причем без внешних регистров

Добавлено спустя 1 минуту 43 секунды:

Сергей писал(а):

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

Не понял мысль. У нас 2 контроллера. Один формирует импульсы для серв (причем гарантированно точные и стабильные), а в другой юзер может залить что ему угодно.

=DeaD=

Сергей писал(а):

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

Он на то и общего назначения, что будут специализированные

вот это первый и может быть последний тип специализированного контроллера

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

) контроллер не выдержит.

FireFly

blindman писал(а):

Мы так и делаем

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

Это гуд

я выложенную схему просто не могу посмотреть

Сергей

я к тому, что можно просто разработать хороший СЕРВО-КОНТРОЛЛЕР, а его уже подрубать куда нада. А это это уже почти как писать программы для GPU от NVidia, только мощности не такие

roboforum.ru

Правила форума

Разработка Open Robotics: Контроллер под сервы, SMD-вариант

Кто сейчас на конференции