roboforum.ru

Научить командам "брысь" и "ко мне"

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

с "брысь" проблем нет, а вот "ко мне" еще не придумал как...

пока нет, но научить думаю не сложно.

названа по имени персонажа, но можно и переименовать - не обидется

Брысь это то же самое что "ко мне", только в обратную сторону не может быть что одно есть, а другого нету

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Не скажи. Одно дело - свалить подальше в любом направлении, а другое - найти зовущего...

Спрошу здесь, чтобы не открывать новую тему. Может уже все знают, кроме меня.
Программа "ванесса" на ПК уже разрослась до 14 модулей и обещает вырасти еще. Во многих из них могут одновременно возникать события, запрашивающие связь с контроллером. В свою очередь контроллер, кроме ответов на запросы с ПК, сам посылает сообщения (например он все время контролирует заряд батареи). Синхронизировать всю эту хрень я пытаюсь вручную, путем расстановки приоритетов и блокировок. Но уже потихоньку начинаю запутываться.
Вопрос в следующем. Какой протокол, и какие средства синхронизации событий лучше использовать для связи ПК - МК?
Заранее прошу не ругаться, если это уже сто раз обсуждалось.

Контроллер упростить, на ПК сделать пачку драйверов.
Ну а дальше надо что-то типа ROS изучать, ну или самому делать

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

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

_________________
"There is nothing better than sliding down snow and flying through the air" (с) Shane McConkey.
Lieber ein Brett am Fuß als eins vorm Kopf, aber lieber ein Brett vorm Kopf als zwei am Fuß.

Либо сделать DNS, а потом уже каждый с каждым после знакомства в режиме команды или подписки. Как в полноценных ROS/MSRS и иже с ними.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

DNS не умею, да и лишний наворот в моем случае наверное

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

Тяжело что-то сказать без понимания что есть сейчас и чем это не нравится

Какие, например, комбинации приходится держать в голове?

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Возьмем простой пример:
Робот едет по маршруту по карте, модуль карты выдает комманды на перемещение и периодически запрашивает показания цифрового сонара. МК в это время выполняет комманду движения, т.е. следит за состоянием бамперов и ИК дальномеров, измеряет токи потребления двигателей и состояние маршевой батареи. Так же, по UART прерыванию, МК выполняет запросы ПК (передает состояние того-же сонара). Модуль управления по скайпу, допустим, передает на МК комманду «стоп» и ждет подтверждения ее выполнения.
Теоретически, может возникнуть ситуация ПК-МК: послали запрос сонару, ждем ответа, одновременно «стоп» по скайпу, тоже ждет + МК посылает сообщение о перегрузке одного из моторов. Все это через один СОМ, с одним событием «пришел новый символ в буфер».
Сейчас я разбираю полученные данные «вручную». Это от сонара? – скормим модулю карты, а если стоп аварийный, то на хрена ему сонар, надо сбрасывать карту, да не забыть текущий режим робота поменять, скайп-комманды заблокировать. Но, сонар уже все равно торчит в буфере. И возможные сбои связи надо учесть. И т.д.
Как то тупо все. Программа разрастается, как паутина, а робот еще ничего толком не умеет.
Хотелось бы организовать обмен так, чтобы вообще о нем не думать. Чтобы каждый модуль знал, что получит ответ на свой запрос, не думая о режиме и приоритете.

В разных потоках принимать и отправлять, не? Глаза поломал читать.
Смотри, посылаются несколько сообщений от разных модулей в центр сообщений. Там они разбираются по приоритету, и отправляются. Потому, что, например, запрос на проверку состояния батареи менее приоритетнее, чем команда "стоп". Теперь сообщения с контроллера: приходят в центр сообщений, а от туда они рассылаются по модулям тоже исходя из приоритетов.

_________________
"There is nothing better than sliding down snow and flying through the air" (с) Shane McConkey.
Lieber ein Brett am Fuß als eins vorm Kopf, aber lieber ein Brett vorm Kopf als zwei am Fuß.

Ну да, типа того.
Во, блин! А, если сделать так: МК в одном цикле считывает буфер UARTа и состояние всех датчиков. На основании полученных данных выполняет какие-нибудь действия и всегда передает на ПК текстовое сообщение фиксированной длины, в котором зишиты показания всех датчиков и текущее состояние МК. Тогда ПК не надо будет ничего запрашивать и ждать ответа, т.к. все данные всегда под рукой. Только комманды передавать.
Все переписывать неохота правда. Прицепляю на всякий случай табличку с существующим протоколом запрос – ответ. Правда неполную, но это неважно для понимания функционирования.

QoS называется. штука хорошая но не всегда помогает. например при попытках по поводу и без отсылать все данные по узкому каналу.

Примерно похожее состояние дел как у вас на роботе.
Поглядел экселевский файл.
Я использую
N (кол-во передаваемых байт)
Команда (байт)
Параметры (байты)
Checksum
Отказался от чтения датчиков в простое МК (когда нет команды от ПК).
Пока МК датчики читает, может уже срочная команда от ПК пришла
у меня UART-коннект на 230400 бит ПК<->МК
Как тут Grem описывал, использую один модуль управляющий UART,
все практически как он написал.
Но я не пользуюсь приоритетами.
Есть очередь команд на отправку в МК (на ДД, на pan/tilt),
у каждой команды есть время когда она должна выполниться,
и таймер на основной форме, который сканирует очередь.
Если пришла команда, которая уже есть в очереди, то старая удаляется.
Команда выполнилась -> от МК пришел ответ -> модуль на ПК получил данные.