Scorpio писал(а):Хотелось бы организовать обмен так, чтобы вообще о нем не думать. Чтобы каждый модуль знал, что получит ответ на свой запрос, не думая о режиме и приоритете.
Сделай программный блок отвечающий за взаимодействие с МК и все запросы через него, он отправляет запрос, получает ответ, только потом следующий запрос. Или в него сохраняй отправленные запросы и в каждый ответ в МК прицепляй ID запросы, чтобы получить асинхронный обмен. Но лучший вариант это сделать регистровую модель как у нас - все данные готовятся заранее и в момент обращения просто выдаются, как на МК, так и на таком программном блоке.
Добавлено спустя 1 минуту 36 секунд:
Scorpio писал(а):Во, блин! А, если сделать так: МК в одном цикле считывает буфер UARTа и состояние всех датчиков. На основании полученных данных выполняет какие-нибудь действия и всегда передает на ПК текстовое сообщение фиксированной длины, в котором зишиты показания всех датчиков и текущее состояние МК. Тогда ПК не надо будет ничего запрашивать и ждать ответа, т.к. все данные всегда под рукой. Только комманды передавать.
Во-во! И команды также пиши в регистры, чтобы ответа долго не ждать!
Можете попробовать мою программу AIAssistant. То, что может делать встроенная в нее Rules Engine, можно почитать в книге на странице 986. Пример задачи текущего контроля. Пример простенький, но показывает как можно наладить работу программы, управляемой данными. В моей программе есть возможность работы с COM портом. Поэтому можно легко получать факты, вызываемые событиями, получаемыми от МК. Любое правило в ECLIPS имеет параметр приоритета, который можно менять во время работы программы, а следовательно, и характер поведения робота. Т.о. можно запрограммировать чтобы однопоточная программа выполнялась не последовательно, а ситуативно, в зависимости от вновь появившихся фактов, в т.ч. и фактов требования выполнения какого-либо действия. Rules Engine очень хорошо подходит для различных распознаваний, например, тенденций, ситуаций и т.д. Если после ознакомления с примером из книги появится желание попробовать мою программу, я выложу ее текущую версию. Правда, без огромной базы онтологии, из-за работы над которой я и не смог программу до сих пор опубликовать в полном виде. Но для ваших задач эта база пока не будет нужна. У вас есть уже написанные вами программные модули и если вы хотите именно их использовать, а не написать их аналоги на языке ECLIPS, то мне потребуется некоторое время, чтобы сделать механизм плагинов с собственным API.
Пока решил сделать так: Перейти к обмену сообщениями фиксированной длины индетификатор – 2 байта данных- контрольная сумма. (Что делать в случае несовпадения КС пока не знаю) Отправлять комманды и запросы ПК->МК по мере поступления наплевав на приоритеты. Ответы, либо аварийные сообщения от МК, по мере поступления сортировать по регистрам (показания сонара, код завершения комманды перемещения и т.д.) взводя соответствующий флаг обновления. Процедура модуля, при запросе МК, сбрасывают флаг обновления соответствующего регистра, ждет обновления данных и считывают свой регистр. Для предотвращения зависания программы, контролируется время ожидания. Например, показания датчика должны вернуться в течении секунды, а время выполнения комманды перемещения рассчитывается в зависимости от расстояния и скорости. Пойдет? Книжка «экспертные системы» оказалась весьма увлекательной. Пожалуй я ее всю прочитаю.
Лучше еще упростить - сделать МК полностью пассивным, читать состояние нужных регистров МК с нужной частотой. Тогда не будет вопросов а-ля "что это за шняга пришла с МК, я же ничего не просил, куда это девать?"
В идеале исключить все ожидания - висит обработчик на ПК срабатывающий либо по прерываниям от МК, либо по запросу от любого из процессов. Ему сказал что-то сделать - он сам дождался слота в линке до МК, отправил запрос, запомнил что запрашивал, потом по прерыванию полученного с МК ответа проверил что запрашивал, записал в регистры итог выполнения и при необходимости потом вернул, когда спросят. Плюс к этому в обработчик можно поставить команду регулярного опроса датчиков, тогда он сам их опрашивает, а по запросу вышестоящей программы только возвращает последнее показание + время его измерения.
Как то не очень хочется все вешать на ПК. Получаеется, что во время движения например, ПК кроме серьезных дел, типа обработки видео, должен еще заниматься всякой ерундой типа проверки состояния бамперов, чем вполне может заниматься МК. А если исключить все ожидания, как тогда организовать пошаговое выполнени программы?
Scorpio писал(а):А время зачем, и где он его берет?
Если не нужно - забей, если нужно - записывает у себя инфу когда с МК получил этот параметр, если нужно точно - еще и МК передаёт локальное время замера относительно передачи измерения
Добавлено спустя 1 минуту 59 секунд:
Scorpio писал(а):Как то не очень хочется все вешать на ПК. Получаеется, что во время движения например, ПК кроме серьезных дел, типа обработки видео, должен еще заниматься всякой ерундой типа проверки состояния бамперов, чем вполне может заниматься МК.
Ну так ПК и так должен этим заниматься, или ты боишься, что ПК будет успевать обрабатывать 25 кадров в секунду, но не будет успевать читать 10 раз в секунду состояние бамперов?
Что-то опасаюсь я все на ПК пока вешать. Программа в стадии разработки, т.е. периодически виснет. Давеча гонял робота с работы по скайпу, задавая ему точки перемешения. Что-то там вылетело за пределы массива, управление пропало, а робот не вписался в дверной проем, зацепился мордой за дверную ручку (бампер при этом был свободен), и если бы МК самостоятельно не остановил моторы по перегрузке, могло бы кончится плачевно. С движением по карте пока похвастаться нечем. При перемещении с парой тройкой поворотов, робот довольно редко попадает в нужную клетку. И, что особенно противно, один и тот-же маршрут проезжает всегда немножко по разному, хотя задания на перемещения получает абсолютно одинаковые. Причем промахивается не только азимутом, но и расстоянием, чего я от него никак не ожидал (энкодер выдает 2 импульса на каждый мм пути). Думаю, что это связано с ПИД регулированием скорости в моторном блоке. Т.е. количество импульсов на единицу расстояния не постоянно из-за процесса регулирования. Зато едет идеально прямо, тут претензий нет. Короче, как и говорили аксакалы, без камеры не обойтись.
Scorpio писал(а):Что-то опасаюсь я все на ПК пока вешать. Программа в стадии разработки, т.е. периодически виснет.
1. Запретить продолженные команды исполнительным устройствам шасси; 2. Поставить общий контроль связи с ПК, если долгое время нет запросов от аплинка - вырубаем всё и засыпаем.
Добавлено спустя 1 минуту 6 секунд:
Scorpio писал(а):И, что особенно противно, один и тот-же маршрут проезжает всегда немножко по разному, хотя задания на перемещения получает абсолютно одинаковые. Причем промахивается не только азимутом, но и расстоянием, чего я от него никак не ожидал (энкодер выдает 2 импульса на каждый мм пути).
Что-то не так, не должен так быстро погрешность накапливать, неужели есть проскальзывания? Если нет - проверь, по энкодерам сколько кликов каждый раз собирает система? И вообще - ты в каком формате команды ему даешь и как ПИД настроен - что поддерживает скорость или расстояние?
