Колибри в робототехнике

Using Kolibri in embedded systems
  • Gluk wrote:Нужно всего лишь создать тему "Детали для роботов, безотносительно Колибри" в разделе "Разное", перенести соответствующие посты туда, и попросить модератора перенести вышеописанную тему в соответствующий раздел ("Оффтоп").
    да дорогой, ты совершенно запутался. Или
    art_zh wrote:в упор не желаешь видеть
    Разницу между словами детали, узел, устройство неужели не видно?
    Мне удивительно думать, что это не понятно современным студентам...
    Раз все так сложно, расставим точки над Ё.
    Детали, например: колеса, аккумулятор, корпус, гайки, оси, тяги.
    К устройствам уверенно можно относить любую сборочную единицу, комплесное изделие: муфта, двигатель, плата управления, управляющий контроллер, коробка передач.
    Так вот. Я ведь про детали речь не вел, я про устройства. Причем не механические, а интеллектуально-программные, комплесные. Это мат-платы со стороны ОСи с одной стороны и серва, например с другой или движёк совместно с его контроллером.

    Хочешь Колибри? Пожалуйста. Операционная система Колибри, равно, как любая другая операционная система, предполагает выполнение "ряда операций" над "внутренним" и внешним оборудованием. В данном сабже основное ударение логично упирается именно во внешние.

    Внешние - это физические интерфейсы и соответственно их логические интерфейсы.

    В широком общем смысле физика интерфейсов - это порты ввода-вывода.

    Алгоритмическая логика работы с ними тем или иным способом - это и есть логический интерфейс.

    Оба они предполагают драйверное решение. Как правило это отдельные драйвера.

    Хороший, наглядный пример - семиуровневая модель Ethernet. Там и физика и логика. Все разфасовано.

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

    Чтобы заюзать комплекс: контроллер + мотор, их нужно либо УЖЕ знать. Либо разобраться, изучить, освоить, создать драйвер...
    Если не знать, что, как в каком формате нужно послать, скажем по COM порту контроллеру двигателя, то как его использовать? ОтветЫ более чем очевидны!
  • Уважаемые Гуру. Если не затруднит, можете обрисовать принцип работы с СОМ-портом из Колибри? Есть задумка написать программу для связи с платой Arduino. На ардуинках много народу делает простейших роботов, поэтому, думаю, и Сообществу будет полезно.
    Соединяй, и здравствуй.
  • Eruman, есть два варианта - юзермодное приложение и драйвер. Пример юзермодного приложения есть в SDK - rtdata.asm, в качестве примера драйвера можно посмотреть на драйвер com-мыши com_mouse.asm из исходных текстов дистрибутива.
    Сделаем мир лучше!
  • Eruman
    Это конечно хорошая идея, но насколько она актуальна? Сейчас практически все дуинки идут с преобразователем USB->UART (например, на FT232). Да и заливать скетчи из КОС смысла нет (нет Java). Думаю лучше начать с терминала типа Serial Monitor.
    Если реализуешь что-нибудь для COM-портов или Arduino, могу попытаться потестировать.
  • 2Albom: В дуинки заливается обычный поток данных, насколько помню. Загрузчик хавает и перепрошивает МК. Если ему правильно дать посылку - перепрошьется на ура.
    Я говорил пока только о связи с дуинкой. Т.е. есть прошитый МК, к нему по ЮАРТ приходят байты и уходят байты. Вот такую слушалку-отсылалку на стороне Колибри и думаю накрутить. Не более, пока.

    Про USB: в дуинке между УСБ и МК есть преобразователь, минуя который можно прекрасно связываться с UART непосредственно микроконтроллера.

    2CleverMouse: Драйвер - это круто :)
    rtdata.asm в дистре Колибри не нашел, но в Минуэтовском есть. Похоже это то, что мне надо, буду изучать. Спасибо.
    Соединяй, и здравствуй.
  • Eruman wrote:можете обрисовать принцип работы с СОМ-портом из Колибри?
    лет 7 назад создал "юзермодное" приложение для работы с COM портами под менуэтом...
    После длительных боев с проблемой "потери байт" при дуплесном обмене через нульмодемный кабелек COM1-COM2 сначала пришел к тому что:
    - скорость более ~56000 нельзя получить в принципе даже с FIFO 16 байт
    - затем понял, что нужен полноценный драйвер со всеми "реалиями IRQ" для конкретного COMа
    - затем понял, что ядро нужно переписывать, а не плодить еще один COM костыль, т.к. это лишь единичный случай из обильного списка темы "ядро-драйвера"...

    В Колибри тебе, под реализацию COM портовых дел только листинг драйверка под COM-мышь подойдет "com_mouse.asm" с адаптацией естественно хотябы "под себя".
    Он без существенных изменений из менуэта пришел и заточен только на 1200 скорость...

    Про юзермод забудь сразу, разве что тебе уверенная и надежная скорость типа 9600...38400 - за глаза хватит и тяп-ляп реализация прокатывает.
  • Eruman
    Да, всё верно, обычный поток и UART после ft232 (не на всех, но есть). Я имел в виду, что разработку вести не получится (т.е. скомпилировать скетч). А для связи - просто замечательно должно получиться, даже на скорости 9600. Сейчас делаю самодельную дуинку (уже имею Freeduino 2009), в которой можно будет переключать USB или RS232.
  • я получаю данные на СОМ порт со скоростью 115200 и битых пакетов ~1,5%... сеть RS485 ~200м. + RS232 3м.
    *****:
    ;дух машины, мой бубен сильнее твоей тупости

    *****:
  • скорость собственно это еще не все, что нужно...
    VaStaNi wrote:с проблемой "потери байт" при дуплесном обмене
    полный, непрерывный дуплекс без пауз и ожиданий... битовые потоки "в обе струи" - вот такой тестинг этой проблемы.
    Есть такое понятие, как пропускная способность канала (количество полезной информации в единицу времени), которая со стороны ядра лимитируется для COMов за счет непроизводительной работы при работе с портами "напрямую" через API и без аппаратных вещей DMA, IRQ...
    хотя наличие 16 байтного FIFO у UARTа 16С550 (например, как самый ходовой на PCях) в некотором роде сглаживает ситуацию, но это далеко от совершенства при работе с потоковыми последовательными асинхронными приемо-предачами канала связи(ей).

    "под этим соусом" пост за 25 апреля viewtopic.php?f=25&t=897&p=32958#p32958 чтобы "понять расклад", как оно есть в широком смысле, остался без ответа...
  • Eruman, rtdata.asm не в дистрибутиве, он в SDK.
    Сделаем мир лучше!
  • Да, уже скачал/нашел/ковыряю. Спасибо ;)
    Соединяй, и здравствуй.
  • Возвращаясь к оригинальной теме этой ветки, закинул удочку на сайте англоязычных роботостроителей на базе Vortex86DX (тех, что используют специальную доску с сервомоторами): http://robosavvy.com/forum/viewtopic.php?p=31446

    Авось кто-нибудь заинтересуется :wink:
  • Так как там Энергия 3.0? Ездит уже? Фото есть?
  • нет, нет =(
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Who is online

    Users browsing this forum: No registered users and 6 guests