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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

Comli - это протокол master / slave, который используется в некоторых старых устройствах или когда невозможно использовать 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

Answer 5

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

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

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