Робототехническая платформа "K-LAB Robotics" для Profest Autonet 18+
Выступления и результаты
Студенческая команда лаборатории робототехники представляет своего робота для участия в соревнованиях PROFEST Autonet в категории 18+
В качестве отборочного этапа требовалось предоставить видеоролик с тестовым заездом робота.
Команда K-LAB Robotics:
Алексей Прутский – преподаватель КИТ ФКТиПМ, заведующий лабораторией робототехники и мехатроники Кубанского государственного университета, руководитель проекта;
Акимов Вадим Валерьевич – профиль – программирование микроконтроллеров.
Студент 3 курса бакалавриата факультета математики и компьютерных наук.
Барыбин Денис Александрович – профиль – аддитивные технологии и электроника.
Студент 4 курса бакалавриата факультета компьютерных технологий и прикладной математики, направление математическое обеспечение и администрирование информационных систем.
Васильев Евгений Юрьевич – профиль – конструирование систем реального времени.
Студент 3 курса бакалавриата физико-технического факультета, направление радиотехника.
Енокаев Ренат Муратович – капитан команды, профиль – машинное обучение.
Студент 3 курса бакалавриата факультета математики и компьютерных наук.
Остришко Данила Сергеевич – профиль – программирование микроконтроллеров.
Студент 3 курса бакалавриата факультета математики и компьютерных наук.
Основополагающим документом для начала работы над проектом является техническое задание, которое описывает требования к качественным и количественным характеристикам конечного устройства.
Техническое задание к площадке:
- Площадка представляет собой площадку 20 на 20 метров, поделенная на блоки 2 на 2 метра. Полотно – баннерная ткань серого цвета.
- Площадка разделена на 3 зоны – квартальная застройка с знаками, площадь со столбиками и трасса с парковкой.
- На площадки расположены знаки и светофор. Знаки показывающие направление движения робота. Располагаются перед поворотом. Также светофор с линией остановки.
- Знак устанавливается на высоте 70 см от дорожного полотна.
- Перед светофором располагается СТОП-линия толщиной не менее 5 см (белая).
- На площадке возможно появление препятствий шириной не более 50 см.
Требования к роботу:
- Робот должен быть полностью автономным. Управление оборудованием и приводами робота должно осуществляться бортовой системой без участия членов команды. Любые программные или аппаратные модули, входящие в состав системы управления, должны располагаться на борту робота.
- Командам запрещено изменять режимы работы или поведение роботов с пульта управления либо иным другим способом во время выполнения роботом заезда.
- К заездам допускаются только роботы осуществляющие перемещение посредством автомобильной кинематики. «Автомобильной» считается кинематика, содержащая два управляемых (поворотных) колеса на одной оси и два колеса на другой оси (не могут быть поворотными).
- Запрещены к использованию следующие типы механизмов и компонентов: способные повредить покрытие или элементы игрового поля; содержащие вредные для здоровья вещества, например, ртутные переключатели или свинец-содержащие детали; содержащие острые грани и углы, представляющие опасность для участников команды, судей или зрителей; содержащие жидкие или гелеобразные материалы; двигатели внутреннего сгорания;
- Максимальный размер робота для участия в матчах – 1500 мм в длину, 1000 мм в ширину и 700 мм в высоту. В качестве официального инструмента для определения соответствия размеров робота будет использован измерительный короб. Чтобы пройти техосмотр, робот должен поместиться в данном коробе и не оказывать усилия на стороны короба. В процессе измерений робот должен находится в том же положении, что и на старте. Размеры робота могут меняться после начала матча.
- В любой конструкции робота переключатель основного питания ДОЛЖЕН быть расположен в легкодоступном месте и быть видимым для судей и участников соревнований. Основной переключатель питания робота должен быть отмечен соответствующей наклейкой, размещенной рядом с ним. Приклейте наклейку (“Основной выключатель робота”) рядом с выключателем.
- Аккумуляторы должны быть надежно закреплены на роботе.
- На роботе ДОЛЖНО быть размещено легко читаемое наименование робота (или команды).
- Командам разрешается использовать в конструкции своих роботов любые системы управления и узлы. Особые требования к используемым датчикам и электрическим компонентам не предъявляются.
- Запрещена модификации электрических и электронных устройств, которые могут повлиять на безопасность их использования.
- Настоятельно рекомендуется подключать аккумуляторную батарею к модулям робота через общий выключатель питания.
- Запрещено использовать внешние (не установленные на роботе) источники питания и трансформатор напряжения.
- Использование источников света разрешено, однако запрещены устройства, обладающие мощным сфокусированным излучением, представляющим опасность для глаз человека.
- Командам запрещается проводить любые ходовые испытания в техзонах, используя любой способ управления роботом. Все испытания необходимо проводить только на поле во время тренировок.
- Использование сварки на территории технических зон запрещено.
- Разрешается использовать любой язык программирования. После запуска робота в стартовой зоне, он должен в течение 5 секунд оставаться без движения, а затем начать движение из зоны старта в зону парковки. По истечению 4 минут с момента старта робот должен автоматически отключить все приводы и остановиться, даже если он не достиг парковки.
Аванпроект
Аванпроектом является документ, включающий в себя совокупность работ, проведенных до начала опытно-конструкторских работ. Содержит в себе набор компонентов технического решения, являясь “ответом” на техническое задание. На входе процесса предоставляются функциональные элементы. На выходе – документ, содержащий укрупненный набор технических решений.
Конструктивные требования:
- Максимальные размеры, данные в техническом задании, не позволяют развернуться в пределах отдельной клетки карты, поэтому они должны быть снижены до максимум 1000 миллиметров в длину и до 600 миллиметров в ширину, минимальный угол поворота колёс должен составлять не менее 0.37 радиан
- Для минимизации проскальзываний колёс необходимо использовать рулевую систему, спроектированную по принципу Аккермана.
- Для корректного планирования маршрута расстояние распознавание знаков не должно превышать 2-х метров
- Для удовлетворения нужд машинного зрения необходимо по крайней мере 2 камеры: одна будет использоваться в целях распознавания знаков, другая в целях распознавания дорожной разметки
- Для корректного распознавания знаков одна из камер должна располагаться на высоте не менее 30 сантиметров от пола
- Основной набор алгоритмов представляет собой систему машинного зрения для детектирования знаков и дорожной разметки, систему построения маршрутов, систему хранения и обработки данных с периферийных устройств. На данном этапе разработки оценить сложность алгоритмов не представляется возможным, следовательно нам необходимо использовать х86_64 совместимый процессор для применения современного программного обеспечения, таких как OpenCV и TensorFlow и др., а также для облегчения процесса разработки для текущей неопытной команды. Так как у нас используется параллельно несколько вычислительных процессов, необходимо использовать многоядерные системы. использование микрокомпьютеров осложнено малой скоростью ввода-вывода данных из постоянной памяти. необходимо использование не менее чем 1 Гб оперативной памяти для работы ОС и загрузки данных с периферии.
Минимальная скорость робота должна составлять 0.3 метра в секунду, чтобы пройти максимально возможный путь за установленные 4 минуты. Если взять колесо диаметром 120 мм, то мотор должен совершать за минуту минимум 50 оборотов. - Лидар должен быть расположен на высоте не более 450 миллиметров, т.к. высота препятствий составляет 500 миллиметров.
Требования к электронике:
- В качестве устройства детекции расстояний должен быть использован лидар с частотой полного сканирования не менее 2-х Гц, что обусловлено минимальной скоростью робота, с минимальным радиусом детекции препятствий не менее 5 метров, т.к. существует необходимость обнаружения препятствий на зоне парковки с наиболее открытой области карты – трассы.
- Исходя из требований технического задания, минимальное время работы от аккумулятора должно составлять 4 минуты, но желательно обеспечить время автономной работы от аккумулятора в 2-3 раза больше для обеспечения возможности продолжительного тестирования тестирования.
- Для получения данных о положении на карте необходимо наличие энкодеров на моторах.
Также следует включить ИНС – метод навигации (определения координат и параметров движения различных объектов) и управления их движением, основанный на свойствах инерции тел, являющийся автономным, то есть не требующим наличия внешних ориентиров или поступающих извне сигналов.
Данная часть технического процесса представляет собой конструкторскую связку отдельных элементов конструкции, а также разработку технических решений для отдельных блоков движущихся элементов. Также в себе содержит проектировочные расчеты конструктивных элементов.
Определение оптимальной модели
Перед тем, как мы пришли к финальной конструкции, нами было перепробовано множество концептов автомобилей.
Рисунок 1 – Первый прототип.
Первый прототип был собран на скорую руку. Он был нужен для понимания направления развития инженерной мысли в целом, где рассматривалась целесообразность применения Xbox Kinect.
Из проведенных заездов стало ясно, что нужно менять пилота, поэтому в дальнейших версиях управляющий модуль был перемещен в миникомпьютер intel nuc.
Рисунок 2 — Второй прототип.
Второй концепт уже больше вписывался в реалии. Заезд на данной конструкции был снят и отправлен на отборочный видео-этап. На основе данной сборки была собрана следующая модель, изображенная на рисунке 3.
Рисунок 3 – Третий прототип.
В следующей конструкции видно, что плита с механическим управлением была развернута на 180 градусов. Это было сделано в связи с тем, что рулевая не удовлетворяла положительным углам Аккермана. Также был добавлен RPlidar A1.
Данная конструкция отличалась изрядной шаткостью. В связи с этим было принято решение – расположить в днище машины цельную плиту. В качестве материала было выбрано оргстекло, из-за своей легкости и устойчивости к трению.
Рисунок 4 – Конечная 3D модель.
Рисунок 5 – Финальная конструкция.
В финальной конструкции были исправлены все предыдущие ошибки и недочеты, а также правильно рассчитан угол Аккермана.
Рулевое управление
В ходе экспериментов с конструкциями был сделан вывод – рулевая робота должна удовлетворять правилу Аккермана.
Рисунок 6 – Моделирование рулевой.
В Autodesk Inventor были проверены различные прототипы рулевой. Так же с помощью подвижных сочленений были определены углы.
В качестве рулящего сервопривода был использован сервомотор Dynamixel mx64. Он подключен к ардуино с помощью протокола RS485.
Лидар
Помощь в ориентировании осуществляется благодаря Лидару и IMU. Также присутствуют энкодеры. Сначала мы попытались собрать лидар сами, но частота лазерного датчика оказалась слишком низкой и мы заказали готовое решение – Rplidar A1.
Рисунок 7 – Самодельный лидар.
Рисунок 8 – Rplidar a1.
В наш комплекс был добавлен инерциальный измерительный модуль. Он нужен для лучшего ориентирования в пространстве. Оптимальное место для размещения – середина задней оси машины.
Камеры
В конструкции нами используются 2 веб камеры: Ritmix и Megapixel. Для распознавания знаков и светофора используется Megapixel, крепящийся на высоте 600 мм от базы машины. Для детекции стоп линии спереди размещена Ritmix, смотрящая под углом в 45 градусов в пол.
Колёса
В модели использовались обычные бескамерные колёса, так как не подразумевалась езда по пересеченной местности. Амортизаторы не были добавлены по этой же причине.
Для получения одометрии на вал мотора была добавлена магнитная втулка, а к мотору датчик холла. Таким образом мы получили инкрементальный энкодер. На полный оборот колеса вышло 360 тиков.
Обслуживание конструкции
Для простоты обслуживания конструкции вся сборка осуществлялась на резьбовые заклепки. Благодаря этому, при поломке или отладке – конструкцию очень легко можно разобрать.
Рисунок 9 – Резьбовая заклёпка.
Сборка агрегата
Перед итоговой сборкой все части конструкции были смоделированы в система автоматизированного проектирования (САПР) Autodesk Inventor. Необходимые крепежи также были смоделированы и распечатаны на 3D принтере или фрезерованы на ЧПУ станке.
Требовалось максимально оптимально разместить все компоненты, также следовало учитывать вес того или иного элемента, во избежание опрокидывания конструкции. Также был рассчитан положительный угол Аккермана для данной конструкции.
Электроника
Данная часть технического процесса представляет собой проектировку и создание коммутационной части электронных компонентов питания и информационных каналов связи. Также содержит в себе проектировочные расчеты системы электропитания и информационных каналов.
Бортовая сеть машинки – 24 вольта. Данное напряжение слишком высокое для всех потребителей, поэтому был установлен понижающий преобразователь. На нём выставлено напряжение 12 вольт. От данного напряжения питаются все устройства.
По регламенту требовалась установка кнопки – при нажатии которой машина бы прекращала движение. Данная кнопка была отдельно вынесена и помещена в видимое место.
Рисунок 10 – Кнопка выключения.
Мы предполагали, что в данном мероприятии имеет место РКД и ЕСКД. На самом первом вебинаре, главному организатору был задан вопрос про оценку инженерной книги и критериям. Мы спросили про какие-то ГОСТы, получили ответ «Инженерная книга по госту это немножко другое, вот в этой инженерной книге опираетесь всё-таки на такие образцы соревновательных направлений как FTC. Или что имеется в виду по госту. Оформление по госту? Или содержание по ГОСТу, Оформление гостированное не требуем и не проверяем. В инженерной книге могут быть нарисованы схемы от руки, сфотографированы какие-то эскизы карандашом на бумаге и это абсолютно нормально. Никто не проверяет шрифт, что у вас там Times New Roman, 14 кегель с 1.5 интервалом, т.е. в этом плане ГОСТ не проверяем. С точки зрения наполнения, как инженерного документа, это тоже не гостированный документ. Это документ в свободной форме, который максимально детально должен отражать ваши результаты за прошедший период.». Так же в основном регламенте каких-либо стандартов замечено не было. Поэтому принципиальная схема разводки питания выглядит следующим образом.
Рисунок 11 – Принципиальная схема.
Для удобства отладки для Arduino mega был изготовлен шилд (Двухсторонняя плата, с коннекторами). Данное решение очень помогло во время отладки.
Из-за того, что дно агрегата стало цельным – конструкция стала тяжелее. В связи с этим было принято решение перейти на более мощные 37мм моторы. Данные моторы в несколько раз мощнее предыдущих. Также старый драйвер двигателя на l298n перестал подходить по мощности поэтому был заменен на пару vnh3sp30.
Рисунок 12 – Драйвера двигателей.
Основные расчёты проводятся на компьютере Intel NUC i7. К компьютеру посредством RS232 подключены микроконтроллеры Atmega, с которыми компьютер осуществляет общение с помощью средств ROS (Robot operating system).
Вся система стала потреблять слишком много тока. В связи с этим мы использовали аккумулятор 10000мАч 6S 25C. Данный аккумулятор имеет большой вес и размеры. Из-за этого он был помещён в заднюю часть конструкции, во избежание перевеса.
Так как подавляющее большинство элементов системы не могут питаться от напряжения выше, чем 12 вольт, был поставлен понижающий преобразователь 40 вольт 40 ампер.
Рисунок 13 – DC-DC Понижающий преобразователь.
Эмпирическим путем было проверено, что Intel NUC стабильно работает от напряжения питания 12 вольт.
Проектирование системы реального времени
Любая робототехническая система реального времени представляет собой набор датчиков (устройства приема данных), актуируемые устройства (выполняющие полезную работы), устройства обработки сигналов и вычислители. Данная сложная система должна быть объединена в общую логическую сеть.
Бурное развитие робототехники порождает необходимость тестирования моделей при отсутствии материальной базы или для проверки экспериментальных алгоритмов, конфигурирующих параметров. Решением этой проблемы может стать программная симуляция. В данной статье описан процесс создания модели автономного транспортного средства c рулевой системой с положительным углом Аккермана, осуществляющего навигацию по известной карте, выполняющего указания части дорожных знаков и светофора, в симуляторе Gazebo 10.0, интегрированном в Robot Operating System(далее ROS) версии Noetic.
ROS – это фреймворк, снабжающий программиста библиотеками и инструментами, нацеленными на разработку робототехнических приложений, построенный на системе топиков и нод, благодаря чему есть возможность использовать любой совместимый с моделью модуль машинного зрения, и обладающий широким набором стандартных пакетов. Gazebo (рисунок ) в данном случае является одним из них, хотя и может быть использован отдельно. Для построения 3D модели робота Gazebo использует её описание в Unified Robot Description Format (URDF), являющимся XML форматом представления моделей в ROS. Нужды сторонних пакетов машинного зрения, которые также разрабатываются в Лаборатории мехатроники и робототехники КубГУ, в модели удовлетворяются плагином camera, являющимся стандартным плагином Gazebo, а именно двумя камерами, соответствующие расположенных для детектирования знаков и светофора, а также дорожной разметки, изображения с которых публикуются в топики sign_camera и stop_line_camera.. Кроме того модель снабжена лидаром, за который отвечает плагин gpu_ray, данные с которого в формате sensor_msgs/LaserScan публикуются в топик scan.
Рисунок 14 – Модель в симуляторе Gazebo, синие лучи – визуализация области видимости лидара.
Для управления моделью в симуляции используется плагин gazebo_ros_control, а для навигации был задействован пакет Navigation Stack. За локализацию с использованием лидара отвечает пакет amcl.
Рисунок 15 – Визуализация одометрии карте.
Для выполнения требований светофора и парковки был разработан пакет pilot, задающий контрольные точки для global_planner’a посредством actionlib API, управляющий процессом парковки и блокирующий на красном сигнале светофора команды teb_local_planner’a – планировщика локального маршрута, задачи которого – указание контроллеру модели скорости движения и угла поворота, а также оптимизация глобального маршрута[5]. Данный планировщик был выбран за возможность учитывания динамических препятствий. Так как локальный планнер задаёт команды в форме сообщения geometry_msgs/Twist дополнительно используется скрипт cmd_vel_to_ackermann_drive.py из того же пакета, преобразующий исходную команду в сообщение AckermannDrive, более удобное для работы с автомобильной кинематикой.
Получения одометрии в симуляции реализовано самым простым способом, а именно с помощью средств Gazebo получается последнее положение робота, из которого вычитается предыдущее положение и публикуется в топик одометрии, что и было реализовано в ноде gazebo_odometry.
Рисунок 16 – Схема.
Таким образом, создана рабочая модель, выполняющую предъявленные требования. На основании данной модели был собран робот, проходящий тестирование. При переносе на реальную конструкцию основной проблемой является получение достаточно точной одометрии, что решается с помощью энкодеров моторов, IMU и пакета robot_localization, объединяющего разные источники данных об изменении положения робота. Последней проблемой можно считать нанесение поворотов на карту препятствий, что в случае возникновения петли может привести к построению некорректных маршрутов. Решением этой проблемы стало использование в pilot’е метапланнера на двунаправленном графе, вершинами в котором объявлены центры клеток карты, связанные рёбрами по признаку соседства.
Машинное зрение
Частичное решение задачи распознавания дорожных знаков
Для решения задач детекции и идентификации элементов дорожного движения необходимо использовать системы обработки видеосигнала. На языке Python 3.7 с использованием библиотеки OpenCV реализован алгоритм детектирования и распознавания дорожных знаков в видеопотоке. Суть алгоритма заключается в поиске наибольшего замкнутого контура, который удовлетворяет подобранной маске, затем эта область сравнивается с образцовым изображением поточечно, и чем больше найдётся общих точек, тем больше вероятность того, что в кадре замечен дорожный знак. Программа распознавания работает в реальном времени.
Достоинства:
- простота в реализации;
- адаптация алгоритма под все существующие классы дорожных знаков;
- возможен не только поиск дорожных знаков на изображении, но и их распознавание.
Недостатки:
- неустойчивость к изменению погодных условий;
- обнаружение схожих с геометрическими фигурами не только дорожных знаков, но и других объектов.
Работа алгоритма состоит из следующих этапов:
На первом этапе импортируется библиотека OpenCV и вызывается метод cv2.VideoCapture, чтобы получить поток изображений с камеры. Также загружаются эталонные изображения дорожных знаков, которые приводятся к одному разрешению, а именно 64×64 пикселя, и применяется маска. Маска — это цветовой фильтр, в котором весь сегмент очищается от шумов и бинаризируется на удовлетворяющий требованиям к разработке белый цвет и не удовлетворяющий черный.
Рисунок 17 – Вывод образцовых изображений дорожных знаков в разных вариациях.
На втором этапе выполняется обработка изображения с камеры. С помощью функции cv2.cvtColor конвертируется BGR(Blue, Green, Red)-изображение в изображение с новым цветовым пространством HSV(Hue – тон, Saturation – насыщенность, Value – значение).[3] Перед бинаризацией картинка размывается посредством метода cv2.blur, уже после применяется маска. Очень часто в кадре возникают посторонние шумы, которые влияют на работу алгоритма, разумеется, их надо убрать. Здесь на помощь приходят функции cv2.erode и cv2.dilate, первая уменьшит размер всего белого, заменив центральный пиксель шума минимальным пикселем в матрице изображения, а вторая расширит полученное изображение.
Рисунок 16 – Цветовой фильтр(маска) по красному и синему.
Рисунок 17 – Бинаризация по маске.
На последнем этапе метод cv2.findContours находит замкнутый контур по границе белого, а самый большой выделяется и вырезается из кадра. Теперь необходимо сравнить матрицу захваченного контура с матрицей эталонных снимков поэлементно, и установить порог распознавания по количеству общих пикселей. При проведении многократных тестов удалось определить, что минимальное число схожих элементов для распознавания дорожных знаков — 3100 пикселей. Около 83% изображений были обработаны верно.
Рисунок 18 – Выделение большого контура.
Рисунок 19 – Пример плохо замкнутого контура.
Рисунок 20 – Вывод результата в консоли.
На рисунке (6) выводятся: первая строка – значение распознаваемого знака, в данном случае «Движение только направо», вторая – количество общих пикселей с образцом знака. Таким образом, можно сделать вывод о целесообразности применения алгоритма для распознавания дорожных знаков на основе поиска цветных контуров. На данный момент описанный алгоритм практически полностью реализован, за исключением некоторых моментов:
- Необходима корректировка пороговых значений цвета для красных и синих контуров дорожных знаков при различной степени освещенности.
- Ведётся работа по оптимизации алгоритма для использования на устройствах с малыми вычислительными мощностями.
- Важно повысить порог общих пикселей для большей точности распознавания.
При продолжительном тестировании работы алгоритма были замечены погрешности в распознавании дорожных знаков, из-за чего идея реализации решения была изменена. Таким образом, для повышения точности распознавания целесообразно добавление в программу специально обученной нейронной сети.
Детекция стоп-линии
В целях осуществления корректного детектирования стоп-линии потребовалось написать скрипт, в котором за основу взят предыдущий алгоритм, но с другой цветовой маской. В нём описаны методы поиска контура самой стоп-линии.
Нейронные сети
Нейросеть для распознавания дорожных знаков
Решение задач идентификации знаков в различных условиях освещения лучше подходят технологии нейронных сетей. Для работы с большим количеством данных нам подходит язык программирования Python, а также библиотеки машинного обучения и машинного зрения: Keras, TensorFlow и OpenCV.
В качестве обучающей и тестовой выборки был использован RTSD (Russian Traffic Sign Dataset) в пользу наличия огромного количества необходимых дорожных знаков.
Архитектура нейронной сети выглядит следующим образом:
- Входной слой состоит из 12288 нейронов для изображений размером 64*64 и аддитивной цветовой моделью (RGB).
- Первый скрытый слой скрытый слой состоит из 1024 нейронов.
- Второй скрытый слой состоит из 512 нейронов.
- Выходной слой состоит из 6 нейронов для каждой метки класса знаков (“Проезд запрещен”, “Движение только прямо”, “Движение только направо”, “Движение только налево”, “Движение прямо или направо” и “Движение прямо или налево ” соответственно).
После того как мы определили архитектуру нашей нейронной сети, нам необходимо обучить ее распознавать и классифицировать дорожные знаки.
Скомпилируем модель, используя метод стохастического градиентного спуска, а также возьмём категориальную кросс-энтропию в качестве функции потерь. Категориальная кросс-энтропия используется почти для всех нейросетей, обученных выполнять классификацию. Единственное исключение — когда имеется только два класса и две возможные метки. В этом случае используется бинарная кросс-энтропия.
Обученную модель нужно оценить с помощью тестовой выборки. Оценка модели очень важна, поскольку необходимо получить непредвзятое (или как можно более близкое к непредвзятому) представление о том, насколько хорошо наша модель работает с данными, на которых она никогда не обучалась.
Также мы сохранили следующие графики:
- потери при обучении
- потери при оценке
- точность обучения
- точность оценивания
Как можно увидеть, мы достигли точности в ~87% на наборе изображений дорожных знаков с использованием нейронной сети.
Рисунок 21 – график обучения нейронной сети.
Теперь данную технологию уместно использовать для распознавания, а именно, получать входное изображение от алгоритма поиска знака передавая его нейросети для распознавания.
Таким образом точность работы всей программы удалось повысить до 92%. Сама программа работает в режиме реального времени.
Нейросеть для распознавания сигналов светофора
Нейросетевые технологии были также применены в решении задачи с распознавании светофора и его сигналов. Алгоритм был разработан в соответствии с алгоритмом распознавания дорожных знаков, единственное отличие состояло в том, что была использована модель сверточной нейросети.
Рисунок 22 – Детекция зеленого цвета.
Рисунок 23 – Детекция красного цвета.
Концептуальная схема информационной системы
Часть управления на роботе
Подключение устройств к Arduino
- HolyBro – приемо-передатчик, который подключается по интерфейсу Serial. Он берет на себя помехоустойчивость (под капотом осуществляет проверку пакетов данных на предмет повреждения). Работает как с текстом, так и с двоичными данными.
- Драйвер моторов. Подключается к Arduino по 4 пинам: два ШИМ, два аналоговых.
- Роборука. Подключается к Arduino по интерфейсу Serial.
- MPU9250 (гироскоп, акселерометр, магнитометр). Подключается к Arduino по интерфейсу I2C.
Получение пакетов управления
Пакет управления
struct Command
{
int8_t _SB0 = 0xA5; // стартовый байт
int8_t _SB1 = 0x5A; // -||-
int8_t WL = 0; // скорость левых колес
int8_t WR = 0; // скорость правых колес
int8_t AR = 0; // угол поворота основания роборуки
int8_t A0 = 0; // угол поворота нижнего звена роборуки
int8_t A1 = 0; // угол поворота верхнего звена роборуки
int8_t AS = 0; // угол поворота захвата роборуки
uint8_t AF = 0; // степень захвата роборуки
uint8_t LED = 0; // яркость подсветки
uint8_t CRC = 0; // контрольная сумма
};
Сбор данных из HolyBro
Рассмотрим пакет управления размером N байт полезной нагрузки.
Построим конечный автомат:
Проверка хэш-сумм пакетов
При получении байтов полезной нагрузки последовательно вычисляем хэш-сумму с помощью алгоритма CRC8.
При получении n+1-го байта, который является контрольной суммой пакета, сравниваем его с вычисленной локально хэш-суммой.
В случае, если они совпали, то пакет считается принятым и неповрежденным. Иначе – пакет поврежден.
Интерпретация пакета управления
Полученная в результате работы конечного автомата последовательность байт интерпретируется Arduino как пакета управления путем тривиального явного приведения типов С++.
Псевдокод
Command command = &(Command*)byteArrayPtr;
Отправка команд устройствам
Отправка команды драйверу моторов
Псевдокод
wheels.setSpeedLeft(command.WL);
wheels.setSpeedRight(command.WR);
Отправка команды сервомоторам роборуки
Псевдокод
arm.setAngleRotate(command.AR*158/255);
arm.setAngle0(command.A0*180/255);
arm.setAngle1(command.A1*240/255); arm.setAngleSpin(-command.AS*180/255);
arm.setFistPressure(command.AF);
Замечание. Применения параметров производится согласно физическим ограничениям соответствующих моторов. Таким образом уменьшается вероятность повреждения робота и увеличивается точность сервомотора за счет сужения рабочего диапазона положений роборуки при том же диапазоне управляющих значений от -128 до 127.
Опрос датчика MP9250
Псевдокод
if (IMU.readSensor() > 0) {
telemetry.ACC_X = (int8_t)((IMU.getAccelX_mss() / 20) * 127);
telemetry.ACC_Y = (int8_t)((IMU.getAccelY_mss() / 20) * 127);
telemetry.ACC_Z = (int8_t)((IMU.getAccelZ_mss() / 20) * 127);
}
Отправка пакетов телеметрии
Пакет телеметрии
struct Telemetry
{
int8_t _SB0 = 0xA5;
int8_t _SB1 = 0x5A;
int8_t WL = 0;
int8_t WR = 0;
int8_t AR = 0;
int8_t A0 = 0;
int8_t A1 = 0;
int8_t AS = 0;
uint8_t AF = 0;
int8_t ACC_X = 0;
int8_t ACC_Y = 0;
int8_t ACC_Z = 0;
uint8_t CRC = 0;
};
Пакет телеметрии аналогичен управляющему пакету, однако содержит дополнительные данные о положении в пространстве.
Формирование пакета телеметрии
Псевдокод
if (radio.receive_command(&command)) {
telemetry.WL = command.WL;
telemetry.WR = command.WR;
telemetry.AR = command.AR;
telemetry.A0 = command.A0;
telemetry.A1 = command.A1;
telemetry.AS = command.AS;
telemetry.AF = command.AF;
last_command = millis();
}
Получаем пакет управления и обновляем данные телеметрии.
if (millis() – last_telemetry > 50) {
radio.send_telemetry(&telemetry);
last_telemetry = millis();
}
Отправляем пакет телеметрии не чаще, чем раз в 50 миллисекунд.
Вычисление хэш-сумм пакетов
Псевдокод
void Radio::send_telemetry(Telemetry* telemetry) {
telemetry->CRC = calc_check_sum((uint8_t*)telemetry, sizeof(Telemetry));
_serial->write((uint8_t*)telemetry, sizeof(Telemetry));
}
uint8_t Radio::calc_check_sum(uint8_t* package, size_t len) {
return crc.smbus((uint8_t*)package + 2, len – 3);
}
Установка передатчик FPV камеры
Передатчик подключается к бортовой 12-ти вольтовой сети питания.
Часть хоста
Подключение устройств к хосту
- HolyBro – USB
- Геймпад – USB
- Приемник FPV камеры
Разработка системы ROS
Узлы связи
Узел TX
Предоставляет абстракцию для отправки команд на робот.
Узел подписывается на topic /node_tx/command. При получении сообщения из этого топика происходит формирование пакета управления, вычисление его контрольной суммы.
Узел RX
Предоставляет абстракцию для получения телеметрии от робота.
Узел работает с HolyBro, парсит полученные байты на предмет пакета, проверяет пакеты на валидность с помощью контрольной суммы по алгоритма CRC8.
Как только валидный пакет получен, то он преобразуется в сообщение и отправляется в топик /node_telemetry/telemetry
Узел контроля
Ручное управление построено на основе “чистых функций”.
Состояние робота эквивалентно команде, которая отправляется на робота.
От обработчика зависит то, как будут интерпретированы нажатия на кнопки геймпада.
Предусмотрены два типа управления: ручной и автоматический (следование по линии).
При автоматическом режиме происходит формирование команд с помощью механизма анализа кадра с FPV камеры.
Алгоритм для движения по линии на данный момент не существует.
Узел распознавания знаков опасности
Некий алгоритм пытается распознать на кадрах с FPV камеры:
- наличия знака на кадре
- распознавания типа знака
- выделения знака на кадре графически
Устройства, над которыми велась работа:
Цифровой сервомотор Dynamixel AX-12A(4 штуки)
Цифровой сервомотор Dynamixel MX-106(2 штуки)
Драйвер двигателя для моторов
Хронология работы над устройством:
Обеспечение движения платформы: движение робота вперёд-назад, выполнение танкового разворота в обе стороны. Начало написания кода.
Подключение серводвигателей к компьютеру через «переходник» USB to RS-485(на самом деле это преобразователь интерфейса U2D2, поддерживающий ещё 2 интерфейса для передачи).
После проверки исправности двигателей они были подключены к Arduino Mega через MAX485 MODULE к UART-выходам платы по Serial соединению и был написан пробный код для поворота двигателей на определенный угол.
Рефакторинг кода
Движение робота
Движение обеспечивается за счёт подачи тока на 4 пина драйвера двигателя, к которому подключены 6 коллекторных двигателей (по 3 на сторону). 2 пина отвечают за направление вращения двигателей на каждой из сторон робота, другие 2 – за скорость вращения на каждой из сторон.
Управление манипулятором
Для работы манипулятора использовались сторонние библиотеки AX-12A.h и Dynamixel_Serial.h. Были разработаны функции для вращения серводвигателей. Первая функция принимает значение угла, на которое должен повернуться двигатель, относительно выставленного «нуля». Другая функция – то же самое, только с ограничителем в промежутке от 10 до 170 градусов включительно, оно необходимо, чтобы двигатели не сломали свою основу. И последняя функция была разработана для вращения «весла», выбирается ID весла и направление его движения.
Медиа
