Готовимся к Евроботу-2015. Софт. Часть 1

Так уж получилось, что в этом году меня снова втянули в Евробот. Едва ли я смогу набраться сил и полностью отвязаться от этого занятия. Да и незачем: за всё время моего участия в соревнованиях я сильно утомился от постоянной работы со стратегией и только с ней; системный софт писался от силы пару месяцев в самом начале сезона.

В этом году мы решили браться за подготовку не так рьяно, как раньше, и поучаствовать в своё удовольствие. Тем более, что меня заинтересовали сетевые технологии и одолело желание сделать систему управления роботом по-настоящему модульной, с программированием на Питоне и передачей данных через TCP/IP.

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

Для начала (по сути, с целью поэкспериментировать и попробовать себя в роли архитектора сетевой системы) я решил использовать библиотеку ZeroMQ. Для написания GUI-приложений системы (мониторинг состояния, удалённое управления) мы решили использовать Qt5.

Концепция

Архитектура системы вкратце должна выглядеть вот так:

На бортовом компьютере робота запущен демон, на котором открыт сокет ZeroMQ типа REP. (Подробней о сокетах в ZeroMQ можно почитать на официальном сайте zeromq.org). Подключение к этому сокету производится через TCP.

Главная задача демона - принимать сообщения от клиентов, обрабатывать их (часть локально, часть - с обменом данными с контроллером робота - Cerebellum board на схеме). Через эти сообщения клиенты получают состояние робота (активность двигателей, предполагаемые координаты на поле, состояние сенсоров и т.д.), а также могут управлять им (задать положение манипуляторов, передать команду на шасси).

В роли клиентов в данной модели выступают системы мониторинга состояния робота, система скриптования поведения, а также система ручного управления шасси.

Плюсы архитектуры

• Масштабируемость: большая часть нагрузки снимается с микроконтроллера и переносится на более мощные вычислители в сети.
• Расширяемость (в определённом смысле): возможность достаточно быстро создавать пользовательские приложения для управления роботом.
• Возможность быстрого создания и использования дружественных интерфейсов для наблюдения за состоянием робота.

Возможные проблемы

Уже сейчас можно сказать, что в самом простом случае реализации мы получаем серьёзные проблемы с безопасностью: если злоумышленник получает доступ к сервисной сети робота, он также получает полный контроль над роботом. На данном этапе остаётся только понадеяться на шифрование сервисной Wi-Fi сети.

Также по сравнению с работой с "голым железом", как мы это делали раньше, возможен проигрыш в предсказуемости поведения системы. Лично мне раньше было спокойней, когда логика робота была зашита в микроконтроллер и выполнялась практически линейно. Хотя подобный подход явно ущербен в плане возможностей по отладке и расширяемости, а также возможности использования более сложных алгоритмов и сенсоров. Так что смело можно сказать, что этот проигрыш должен оказаться полностью оправдан, да и связаны эти опасения пока что лишь с моими старыми привычками.

Реализация

На данный момент мы всей командой стараемся разработать все основные узлы получившейся системы.

Пройдём по схеме снизу вверх.

1. Плата Cerebellum - используется прошлогодняя Stepper 0.1. Она довольно неплохо себя показала в прошлом сезоне. Также использование именно этой платы связано с тем, что мы в целом решили не менять электронику (до известного предела: манипуляторы всё же будут новыми).
2. Бортовой компьютер. Изначально в планах было использование платы pcDuino 1.0 на базе Allwinner A10, которая была в "загашниках" нашей команды. Однако, мы столкнулись с серьёзными проблемами, связанными в основном с сонным сообществом вокруг этой платы, дистрибутивы Debian для неё довольно давно не обновлялись, и мы не смогли настроить на ней Wi-Fi донгл. Поэтому на данный момент в качестве бортового компьютера планируется использовать Raspberry Pi Model B+.
1. Демон Cerebellum. Изначально разрабатывался мной с использованием Qt Framework, однако я склоняюсь к написанию демона на чистом C++, чтобы не растрачивать почём зря и без того не очень многочисленные ресурсы. Прямо сейчас демон ещё пишется, и вместо него для отладки остальных компонентов системы используется "заглушка", написанная на Python.
2. Монитор состояния. В этом модуле уже активно используется Qt 5. Задача - вывести в окно программы разметку игрового поля и положение робота на ней. Для общения с сервером используется библиотека QtCerebellum, написанная в рамках этого проекта.
3. Скриптинг. Есть особое желание использовать Python для написания скриптов для робота. Это связано с тем, что язык довольно простой для изучения, имеет огромную гору готовых библиотек и на самом деле заставляет программиста писать хоть сколько-нибудь читаемый код. Но самое главное - скрипты не требуют предварительной компиляции, что должно очень сильно ускорить процесс написания прикладного ПО для робота (по сути, описания стратегии поведения на поле).

Итоги

До соревнований остаётся около 3 недель, и я не берусь утверждать, что к этому времени мы успеем подготовить абсолютно всё. Но надежда не гаснет, и сейчас разработка идёт полным ходом, вся команда (к слову, в этом году выступающая в расширенном составе) загружена работой.

Следить за нами можно на сайте dimrobotics.com, а здесь, на своём блоге, я буду выкладывать "вести с полей", краткие рапорты по текущему состоянию дел.

Всё ПО, написанное для проекта, размещается на нашем Github: https://github.com/DIMRobotics.

До следующих новостей!