Любой протокол более высокого уровня для связи через последовательный порт?

Мы ведем курс по робототехнике, и Xbee — самый любимый протокол связи для студентов. За последние два года мы помогли им построить около 62 различных проектов (еще 40 в разработке).

Практически все проекты предполагают отправку различных данных боту. Иногда это 1-байтовая команда, а иногда это длинная строка, которую нужно интерпретировать. Иногда мы сталкиваемся с проблемой обращения к боту, когда один xbee используется в широковещательном режиме для отправки сообщений конкретному боту из нескольких. Студенты используют свое творчество для решения этой проблемы каждый раз.

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


communication embedded spi xbee
person Eastern Monk    schedule 12.10.2011    source источник
comment
Это не ответ, но лично мне, особенно в универе, не нравилось, что для меня делается слишком много вещей в проектах, над которыми мне предстояло работать. Изучение решения этих проблем со связью, возможно, может быть частью учебного процесса — как решить многоузловую широковещательную связь? Если вы уберете этот аспект, возможно, ваши студенты не будут брать столько же из вашего курса. Мне, например, часто давали код лекторов только для того, чтобы выкинуть его в мусорное ведро из-за того, что это был мешок с гвоздями. Это не значит, что и у вас будет так же ;-)   -  person RichColours    schedule 12.10.2011
comment
вы думаете в духе ppp или проскальзываете?   -  person old_timer    schedule 12.10.2011
comment
@RichColours Я согласен с вами в том, что, решая эти коммуникативные проблемы, студенты многому учатся. Как только я решу разработать такой протокол, студенты будут сотрудничать и создавать его сами. После того, как он будет разработан, он ускорит разработку проекта для следующих пакетов, и, возможно, эти пакеты смогут решать более сложные задачи, потому что над некоторыми проблемами позаботились их старшие.   -  person Eastern Monk    schedule 12.10.2011

Ответы (5)


arrow_upward
4
arrow_downward

Вы можете внедрить Modbus ASCII, если хотите использовать уже открытый стандартный протокол.

person mjh2007    schedule 12.10.2011
comment
Или Modbus RTU, если вы хотите сохранить простоту кода и уменьшить пропускную способность. Я написал малозатратный сервер Modbus менее чем за рабочий день. Спецификации доступны бесплатно на modbus.org. - person Sam Skuce; 13.10.2011

arrow_upward
5
arrow_downward

Вы имеете в виду внутренний только протокол вашей системы? Если да, то часто инженеры встроенного программного обеспечения склонны внедрять собственные протоколы. Большинство из них говорит, что это позволяет им сделать наиболее оптимальную систему.

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

К сожалению, я не знаю ни одного стека протоколов, хорошо подходящего для робототехники. Но я советую вам попробовать буфер протокола Google system, он способен упростить большинство усилий по созданию движков протоколов, и он также работает с простым c.

person Mtr    schedule 12.10.2011
comment
Мы будем открывать исходный код, что бы мы ни делали. - person Eastern Monk; 12.10.2011

arrow_upward
2
arrow_downward

Comli — это протокол ведущий/ведомый, который используется в некоторых старых устройствах или когда невозможно использовать Ethernet. Вы, вероятно, можете получить спецификацию от ABB, если спросите - это не секрет.

Тем не менее, вы можете поместить архитектуру сервера/клиента OPC поверх этого, чтобы получить немного более мощную связь, например.

+--------------+    +--------------+         +--------+
| OPC UA Client| -- | OPC UA Server| -comli- | Device |
+--------------+    +--------------+         +--------+

Это сделает ваш клиентский протокол OPC UA независимым, что немного облегчит дальнейшую работу.

Modbus — еще один последовательный протокол, который часто используется.

Я верю, что OPC даст вам работу высокого уровня, которую вы хотите.

см. www.opcfoundation.org www.abb.com

PS. OPC UA отличается от старой версии OLE и поэтому не имеет ничего общего с COM/DCOM.

person AndersK    schedule 12.10.2011

arrow_upward
2
arrow_downward

Как сказал mjh2007, Modbus является стандартным, открытым и простым. Единственная проблема, которую я вижу, - это если вы хотите, чтобы робот «быстро» реагировал на команду, поскольку последовательный Modbus использует тайм-ауты для обнаружения конца пакета. Вы можете обойти это, игнорируя требования тайм-аута и вычисляя ожидаемый размер пакета на основе его функционального кода и параметров по мере его получения, после чего вы можете начать обработку команды сразу после получения последнего байта и проверки любых контрольных сумм. На на этой странице есть более подробная информация о реализации такой схемы.

person Sam Skuce    schedule 14.10.2011

arrow_upward
0
arrow_downward

Обязательно используйте фрейм «Transmit Explicit» модуля XBee (тип 0x11), работающий в режиме API с ATAO, установленным на 1. Вы можете выполнять одноадресную рассылку конкретному боту в вашей сети вместо того, чтобы всегда транслировать кадры. В ячеистой сети ZigBee вы хотите максимально избегать широковещательных передач.

Я предполагаю, что вы либо используете «режим AT» для отправки необработанных данных, либо используете «режим API» с ATAO, установленным на 0 (иногда называемый «прозрачным последовательным»).

Если вы посмотрите на этот тип кадра (0x11), вы увидите, что получатель получает кадр 0x91, который уже содержит несколько полей (конечная точка источника/назначения, кластер, идентификатор профиля). Вы можете изменить назначение этих полей, так как вы не пытаетесь создать сеть ZigBee.

person tomlogic    schedule 04.01.2012