roboforum.ru

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

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

dccharacter писал(а):Почту она умеет получать?

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

dccharacter писал(а):Только что за имя у нее странное - Ванесса?

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

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

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

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

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

Какой протокол, и какие средства синхронизации событий лучше использовать для связи ПК - МК?

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

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

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

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

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

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

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

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

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

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

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

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