Хабрахабр

OMower c ROS, первые шаги

Первоначально, OMower разрабатывался под простые интерфейсы управления pfodApp и Modbus. Первый — это текстовый протокол высокого уровня, в котором передаются менюшки и управляющие команды, а второй — известная, но не слишком удобная в данном применении вещь, так как требует от управляющей программы постоянно опрашивать состояние всех используемых датчиков «вручную». Поэтому, было принято решение постепенно переходить на ROS (Robot OS), широко используемый фреймворк для управления различными роботами.

То есть, чтобы сдвинуть робота с места или изменить какую-либо внутреннюю настройку робота — вы должны будете отправить на него текстовую команду в формате pfodApp. На данный момент, поддержка ROS находится в начальной стадии, включая в себя только передачу информации от датчиков в виде простых массивов (без использования специализированных форматов сообщений, предлагаемых многими библиотеками ROS), отладочного лога и управляющих потоков команд в формате pfodApp/Modbus, без возможности реально управлять роботом стандартными средствами ROS. Такие, например, предоставляемая omower_seeker.py возможность езды в направлении визуального шаблона (шахматной доски), для точного заезда на парковочную станцию. Но даже в таком усеченном виде — можно легко транслировать и записывать происходящее с роботом, визуализируя его движения в стандартных средствах ROS (rviz), а также добавлять сервисы для дополнительных функций.

Основные сервисы ROS исполняются на Orange PI Zero, воткнутой в специальный разъем на плате робота (на тестовой машинке для этого используется Raspberry PI3, соединенная аналогичным способом — через последовательный порт). На картинке нарисованы потоки данных в роботе. От двух дополнительных Raspberry PI Zero приходят потоки картинок с камер, но как показала практика — получить нормальной синхронизации для обработки стерео-изображений при такой схеме нельзя (качество видно на картинке внизу), поэтому скоро будет произведена замена на нормальную стереокамеру. Через интерфейс rosserial — робот передает в ядро ROS сообщения от датчиков (такие, как /imu/orientation или /motors/PWM), свой отладочный лог в текстовом формате и вывод меню/сообщений в формате pfodApp или Modbus, принимая поток текстовых команд или Modbus-запросов.

Степень интеграции ROS в OMower будет постепенно расширяться, вплоть до предоставления полного доступа ко всем внутренним переменным робота и возможности управлять им через стандартные средства ROS (типа cmd_vel-сообщений, задающих требуемую скорость движения).

Его назначение довольно простое — ехать в направлении шахматной доски, корректируя свой маршрут в реальном времени. Расскажу немного поподробнее про модуль omower_seeker.py, как пример использования ROS для добавления функций в OMower. Анализируя изображение с одной из камер — модуль вычисляет два угла (угол отклонения доски от центра камеры и угол поворота самой доски относительно перпендикуляра) и передает их в виде текстовой команды внутреннему модулю seeker (omower-seeker.h/cpp в OMower SDK). Эта функция будет использоваться для заезда газонокосилки на парковочную станцию, где он может быстро заряжать свои аккумуляторы.

Как показывает практика, скорость поиска шаблонов в opencv на изображении при использовании относительно маломощных Orange PI и Raspberry Pi — очень невысокая и нестабильная, занимающая от десятков до сотен миллисекунд при разрешении 640x480, что во время езды превращается в отклонения от необходимого маршрута, так как робот, даже со своей невысокой скоростью движения, успевает за это время повернуться на существенный угол или проехать относительно большую дистанцию. Внешне это выглядит довольно простой задачей, но в реальной жизни возникает серьезная проблема — скорость обработки изображений на встроенном в робота микрокомпьютере. Собственно, поэтому и была выбрана шахматная доска c минимумом клеток, так как другие шаблоны отнимают еще больше времени.

Вычисленные углы от omower_seeker.py (который также передает микроконтроллеру и время поиска шаблона) — пересчитываются в реальный угол поворота, с использованием сохраненного значения компаса, отстоящего от времени поиска не более чем на 100 миллисекунд, а уже по этому углу робот и едет. Чтобы компенсировать большое время поиска визуального шаблона, применяется схема с использованием компаса — микроконтроллер робота сохраняет его значения каждые 100 миллисекунд, храня пять отсчетов за последнюю половину секунды (более продолжительные анализы просто отбрасываются, в виду их малой пригодности для точной навигации). Или, если она немного повернута относительно перпендикуляра — по дуге, корректирующей угол приближения так, чтобы он был максимально близок к оси шаблона, так как нам нужно не просто подъехать к доске, но и попасть в направляющие полозья и подключиться к контактам зарядки. Это позволяет более-менее точно ехать в направлении шахматной доски по прямой.

На поле по GPS задаются две точки — стартовая (где-то в середине рабочей области), и точка перед станцией, а также угол поворота к станции. Полный алгоритм заезда на станцию реализуется в три этапа. Если какой-то из этапов не прошел, либо углы отклонения превышают заданные значения — робот отменяет заезд и снова возвращается в стартовую точку. После того, как робот приедет от стартовой точки до второй и повернется на нужный угол в сторону шахматной доски на станции — вступает в дело модуль seeker, корректируя обороты моторов через PID-регулятор.

Ссылки и видео:

→ OMower SDK, библиотека для Arduino IDE и принципиальная схема с разводкой платы
→ Готовая прошивка с использованием SDK, реализующая как pfodApp/Modbus, так и подключение к ROS
→ Пакет omower_gateway для ROS

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть