Мы с командой (к которой Вы можете присоединиться) единомышленников с Хабра разрабатываем робота для сбора мячей для гольфа на driving range.
Владимир Гончаров Shadow_ru рассказывает о сборе требований, формулировании задач для работа, разработке архитектуры и создания прототипа для обкатки ПО.
Проект для меня начался, со сбора требований, обобщению и последующей декомпозицией на подзадачи. Задача для робота на первый взгляд простая, однако ошибки на этапе планирования сильно портят результат работы и не всегда видны сразу, поэтому пропускать этот этапа — путь в никуда.
Обобщение требований упрощает общение с другими членами команды — вырабатывается общее понимание задачи, ситуация когда робот у каждого в голове свой уже не возникает. Так же когда в команду входит новый участник — достаточно дать прочесть подобный документ, что уменьшает время на фазу входа.
Между сбором требований и обобщениями всегда нужен баланс — хочется расписать поподробнее, но если вы не юрист, привыкший работать с сотнями связанных параграфов — задачу общего видения это не решит. Есть конечно правильный подход, когда делается несколько срезов требований под разных участников команды и внешних заказчиков-подрядчиков. Но пока это явно излишне, т.к. каждое изменение требований будет вести к серьезным затратам времени на обновление таких срезов, что не слишком хорошо влияет на продуктивность стартапа.
Для себя я решил разбить на функциональные и нефункциональные требования и уложить все это в одну страницу А4. Первая версия вышла такая:
Фаза 1. Постановка задачи
Задача: Необходим максимально непрерывный объезд тренировочного гольф поля в сложных климатических условиях для сбора шаров.
Проблема: Необходим Unmanned Ground Vehicle (UGV) для выполнения циклических миссий по объезду пространства, заданного периметром с координатами точек в WGS-84 нотации.
Миссии должны включать следующие операции:
- Нормальный старт с известной домашней позиции
- Аварийный старт с неизвестной заранее позиции (запуск после срабатывания WD, защиты по питанию и т.д.)
- Объезд площади с покрытием не менее 98% пространства за 1 или несколько заездов (начать объезд поля заново после заполнения бункера через 15 минут излишне)
- Возврат на домашнюю позицию по заполнению бункера, истощению батареи, окончанию объезда
- Заезд на платформу старта для сброса шаров, заряда батарей
Упрощенная версия алгоритма
Кроме этого UGV должна выполнять следующие требования:
- Не покидать указанного периметра при объезде заданного периметра
- Домашняя позиция может находиться вне заданного периметра
- Выполнять мониторинг расхода заряда батарей и планировать возврат с учетом израсходованной мощности. Перемещение заполненного бункера требует больше мощности от батарей, чем пустого.
- Вести логи телеметрии включающие, но не исчерпывающиеся координатами на плоскости, значениями 6 осей вращения, уровень сигнала телеметрии и внешних датчиков.
- Иметь три системы позиционирования — GPS для получения грубых координат, IMU для верификации и коррекции координат на плоскости, оптическая для точного позиционирования по маркерам.
- Иметь две системы Watch Dog — программная и аппаратная. Программная верифицирует состояние
- Иметь дальнобойный аварийный канал связи с отдельным питанием, использующийся при выходе параметров миссии за заданные параметры (координаты, авария, авария по питанию, отказ оборудования)
- Иметь возможность изменять параметры миссии при нахождении на домашней позиции
- Иметь два канала связи - низкоскоростной телеметрический и высокоскоростной для передачи аудиовизуальной информации. Высокоскоростной должен иметь возможность включения/отключения по телеметрической команде.
По этим требованиям была выбрана следующая архитектура решения:
В состав роботизированного комплекса входят: один центр управления (Ground Station Control) — далее GSC.
Позволяет пользователю выполнять следующие действия:
- Задать периметр
- Спланировать миссии в зависимости от времени суток и загрузки корта
- Иметь возможность мониторинга гольф-роботов с дискретностью показаний не менее 1 минуты
- Иметь возможность аварийного прерывания миссии
Софт GSC должен заниматься планированием действий гольф-роботов, сами роботы же должны быть достаточно простыми. Решение не очень гибкое, конечно, но самосогласованные решения и меш-сети это не то, что можно решить в краткие сроки, да еще и дешево. Плюс — это типовой подход, а значит и известные проблемы. Один или несколько гольф-роботов (Golf rover) — далее GR.
Выполняет следующие типовые действия:
- Получает миссию при нахождении в радиусе 10 метров от наземной станции
- Выполняет миссию
- При типовом выполнении миссии отчитывается по телеметрическому каналу с частотой не менее 1 раза в минуту
- Возвращается на наземную станцию
- Ожидает новую миссию
- Каждая миссия должна быть прервана по следующим событиям:
- Заполнение бункера шаров
- Авария по питанию
- Невозможность движения (переворот, внезапное препятствие)
- Аварийный перезапуск
- Ручное прерывании миссии
- Каждое прерывание миссии должно быть передано по обычной телеметрии и резервному каналу
- После прерывания — GR возвращается на наземную станцию, если это позволяет его состояние
Т.к. наземных станций может быть 1, а GR много — заполнение бункера шаров отнесено к экстренной ситуации. Это решает сразу две проблемы — GSC с высокой степенью достоверности знает, что робот поехал на станцию и частое тестирование резервного канала. Также предполагается, что заполнение шаров должно происходить в течении миссии и если это не так — GSC где-то ошиблась в планировании и это стоит исправить. Интуитивно хочется выпустить робота в чисто поле, а когда соберет шары — вернется. Но тут вступает в дело экономика, если занимается 1-2 человека — лучше роботу постоять на станции, а начать движение когда шаров уже поднакопится. Меньше расход ресурс и энергии.
Одна или несколько наземных станций (Ground Station) — далее GS.
- Зарядка
- Бункер для сброса шаров
- Связь с GR
Схема всего комплекса вот такая:
Вторая фаза — оценка рисков и возможных проблем всего этого комплекса
По хорошему надо привести таблицу рисков и их оценок, но боюсь, три листа А4 вызовут только зевоту. Дам только интересную выжимку:
Основной проблемой всех автономных ползающих роверов является задача получения своей точной позиции. Причем позиция должна быть действительно точной — желательно в пределах 10-15 см. Именно потому, что эта задача толком не может быть решена на малой мобильной платформе не существует дешевых и массовых сельскохоз/транспортных/военных дронов.
Хотя казалось бы — вот есть решения для летающих дронов, переиспользуй на земле и все. Но это в воздухе 10-15 метров влево или вправо на развороте не решает почти ничего, а на земле же приведет к авариям и катастрофам. К тому же в воздухе камни свое место не меняют, дорогу живность не перебегает. Птицы таки да, но места в воздухе сильно побольше.
Позиционирование ведется по GPS/ГЛОНАСС модулю, что сразу приводит к двум последствиям: точность позиционирования не слишком велика и скорость получения координат. Координаты для uBlox M8N модуля по стационарным тестам: 2-3 метра в хороших условиях приема, 7-10 при плохих погодных условиях и видимости. В общем-то такие погрешности для задачи сбора шаров даже хорошо — ровер за несколько миссий захватит шаров больше чем ездящий по как по рельсам. Однако в этом случае получается так, что нельзя его вести рядом с препятствиями типа стен или крупных камней и в данных областях шары будут копиться. Были проанализированы оптические и УЗ системы навигации, однако выяснилось что надо большое кол-во маячков/камер при сложной геометрии поля, есть проблемы с зонами видимости (поле не всегда ровное как пол в ангаре) и не стабильная работа таких систем при сложных погодных условиях (дождь, туман). Так что пока GPS наше все, но с оговорками. Причем повысить точность GPS можно достаточно дешево — RTK, но проблему стен оно не решит.
Стало ясно, что выбранный подход, когда ровер ползет по загруженным точкам с точностью в 5-10 метров влево-вправо требует проверки. Залезать с ногами в поезд под названием SLAM для простенькой задачи кажется излишним. Если въезд в станцию по оптически ярким объектам (Aruco Code) как делать ясно, и сколько это требует ресурсов — тоже, то решение задачи классификатора всех возможных объектов на поле или нахождение границ это задачи совсем другого порядка.
Пришло время для фазы 3 — Proof of Concept
Необходимо сделать макет системы, опробовать в действии на поле, оценить применимость. По выработанным требованиям дело пошло гораздо веселее:
Как софт ровера был выбран Ardurover — активно развивающийся софт, начинающийся как прошивка для квадрокоптеров на Ардуино. Однако, к нынешнему моменту он поддерживает и платы на Линуксе с RTL ядром, причем открыт для доработок. Допиливать в дальнейшем пришлось к слову, но скорее для ускорения работ, чем по нужде.
Как ровера был выбран BeagleBone Blue — высокоинтегрированная система для робототехники.
Отличительной особенностью является использование чипов TI Sitara/Octavo, по сравнению с теми-же Raspberry там стоят Programmable Realtime Unit — PRU. Это два отдельных 200 МГц ядра, которые могут в реальном времени управлять железом, не отвлекая основное ядро прерываниями, нитками и прочей техномагией.
Кроме этого на платформе сразу есть WiFi, Bluetooth, распаянный разъем для балансировочного кабеля, контроллер зарядки Li-Po батарей, USB разъемы для подключения телеметрии и компьютера, разъемы для серводвигателей, стабилизаторы питания 5 и 3.3 вольта, АЦП сразу заведенный одним каналом на батарею, несколько UART. В общем бери и делай робота.
Ardurover туда встал не без проблем — использовать PRU из софта на текущий момент можно только с ядром 4.4 LTS. В более новых ядрах программирование PRU из пользовательского софта приводит к SIGBUS fault, после общения с разработчиками ardublue ветки я заказал JTAG адаптер, буду смотреть в чем причина. Самому роверу это жить совсем не мешает, но хочется четкого понимания в чем проблема.
Софт позволяет делать практически все из требований, кроме позиционирования на заезд в базу, тут я использую камеру JeVois-A33. Аварийный сигнал по части событий он тоже не пошлет, но это задача для отдельного модуль с раздельным питанием, т.к. аварии по питанию или хорошего переворота управляющий модуль может и не пережить.
Осталось прикупить GPS приемник, телеметрический радиопередатчик, УЗ датчик расстояния и подключить камеру машинного зрения. После пайки, соединения разъемов и тестового запуска получилось вот так:
Как центр управления использован Mission Planner.
Софт не бесспорный, приличный Web интерфейс вместо швейцарского ножа с 100500+ кнопок для любителей коптеров надо сделать, но для отладочных целей более чем пригоден. Для общения с ровером использует протокол MAVLINK адаптеров и прикладного софта под Java/JS написано достаточно много. В протоколе хотелось бы конечно иметь пакеты поменьше размером, и вести стандартный справочник параметров, но это было бы слишком хорошо.
Как база ровера — использована модельная машинка масштаба 1/18 с отдельными приемником и контроллером двигателей.
Приемник был выкинут, разъемы сервоприводов и контроллера двигателя заведены непосредственно на BeagleBone Blue, как и батарея.
Из смешного — я помнил, что в детстве паять совсем не получалось, на местах пайки все время висели сопли олова и за паяльник я взялся не без внутреннего трепета. Однако, как только нож, провод и паяльник попал в руки я неплохо залудил жало, обрезал изоляцию не задев внутренней жилы, руки сами закрутили концы кабеля, облудили их и запаяли соединение. И тут я вспомнил, что работать начинал как embedded разработчик и за пару месяцев натаскался в общении с паяльником. Прекрасная иллюстрация к поговорке “опыт не пропьешь”, по моему.
На текущий момент стенд выглядит так:
Как видно — контроллер без корпуса и крепежа. К сожалению псевдогермобокс я заказал распечатать на SLS 3D принтере нейлоном, и его еще не успели сделать. Выводить же ровер в чисто поле без корпуса — ходу такому викингу полчаса на свежем воздухе. Потом или электрохимическая коррозия доест, или после переворота-удара вовсе в выброс. Так что ждем корпус, герморазъемы и и крепежи по всем правилам демпфирования ударов и вибрации.
На видео обнаружение ровером Aruco Code
В итоге тестовые покатушки я провел дома на ручном управлении. Тут выяснилось что база выбрана не совсем верно — слишком быстро разгоняется, пришлось разучивать программирование китайского контроллера двигателя. Второе — задний ход на этом чуде китайской мысли включается двумя сигналами “назад” — первый включает торможение, второй уже включает реверс. Причем может и проигнорировать при слишком быстрой подаче сигнала — бережет ресурс шестерней и двигателя. Пришлось допилить ardurover, т.к. подобные фокусы в нем учтены не были.
Следующие действия — откатать маршрут 5-7 раз, снять логи телеметрии и GPS треки маршрутов. Я нашел футбольный стадион с отапливаемым полем, так что если пойдет снег — не страшно. Ровер явно не будет буровить сугробы, иначе Фаине Раневской стоило бы добавить в список извращений кроме хоккея на траве и балета на льду еще и гольф по сугробам. Не самое дешевое развлечение, конечно, но где еще в России, да в ноябре можно найти зеленую травку. Так же начаты работы по реализации гусеничных шасси, там скорости сильно ниже (текущая модель разгоняется до 20 км/ч за 15 секунд) и есть разворот на месте, а не заезды треугольником на пятачке. Скорее всего через пару недель оба шасси будут обкатаны одновременно, для проверки работы детектора препятствий и алгоритмов объезда.
В конце хочу заметить, что проверку решений на натурных моделях вести весьма быстро и дешево. Гораздо раньше отлавливаются мелкие неприятности, и более того — есть время внести изменения в дизайн большого робота, пока он еще в стадии проектирования или прототипа. Потом будет дороже, дольше и что-то да сломает в увязке узлов. Причем на таких моделях легко разрабатывается и проверяется почти весь нужный софт для задач. В идеале все что нужно для перехода на другую модель — заменить протокол контроллера двигателей на новый. Ну и возможно динамическую модель поменять.
Кроме этого использование специализированных и опробованных решений сильно экономит силы и время. Изобретать свою плату высокой плотности монтажа, свой протокол связи, наземный софт и софт ровера, отлаживать алгоритмы объезда препятствий и связи с китайскими контроллерами двигателей конечно очень увлекательно, однако в этом случае можно сразу добавить полгода-год на длинный и тернистый путь. Уже кем-то пройденный.
Нужна Ваша помощь:
- Если Вы готовы работать над ROS-версией.
- Требуется подготовка платы подключения модулей для версии на raspberry pi и orange pi
- Помощь с тестированием на driving range, особенно если Вы проживаете в стране, где активно играют в гольф;
- Правовые вопросы, вывоз робота из страны, патентное право, законодательные требования к конструкции;
- Требуется помощь с упаковкой стартапа, поиском инвестиций. Мы хорошо развиваемся и без инвестиций, у нас есть план действий, формируется команда. Нам нужны скорее не деньги инвестора, а опыт и компетенции в развитии коммерчески успешного проекта.
Текущее состояние проекта
Мы готовим второй вариант корпуса. В течении недели будет готов корпус методом вакуумной формовки, об этом напишем отдельный пост.
Нижнюю часть корпуса изготавливаем фрезеровкой композитного материала.
Корпус и механику проектирует NikitaKhvoryk. Плату подключения модулей для версии на raspberry pi и orange pi мы очень долго ждем от n12eq3. Версия с Ardupilot Владимир Гончаров Shadow_ru
Благодарим за предложенную помощь и советы Process0169, Trif, tersuren, vasimv, vovaekb90, Вячеслава Солдатова, Левона Закаряна, Сергея Помазкина, Vladi Kuban, Karen Musaelyan, Алексея Платонова. Если Вы желаете помочь — просьба написать мне в ЛС или ВК, FB.
Планы:
У нас есть предварительные договоренности по размещению робота для тестов в гольф-клубах в России, Германии, Латинской Америке и Новой Зеландии. В ближайших планах доработать алгоритмы и конструкцию, провести тесты в Москве и внести доработки. Создать 5 роботов и бесплатно разместить их в гольф-клубах для длительных тестов к новому сезону.
Спасибо, что дочитали, спрашивайте и критикуйте нас полностью.
Автор: webzuweb
