Мы с командой (к которой Вы можете присоединиться) единомышленников с Хабра разрабатываем робота для сбора мячей для гольфа на driving range ^[1].

Владимир Гончаров Shadow_ru ^[2] рассказывает о сборе требований, формулировании задач для работа, разработке архитектуры и создания прототипа для обкатки ПО.

Проект для меня начался, со сбора требований, обобщению и последующей декомпозицией на подзадачи. Задача для робота на первый взгляд простая, однако ошибки на этапе планирования сильно портят результат работы и не всегда видны сразу, поэтому пропускать этот этапа — путь в никуда.

Обобщение требований упрощает общение с другими членами команды — вырабатывается общее понимание задачи, ситуация когда робот у каждого в голове свой уже не возникает. Так же когда в команду входит новый участник — достаточно дать прочесть подобный документ, что уменьшает время на фазу входа.

Между сбором требований и обобщениями всегда нужен баланс — хочется расписать поподробнее, но если вы не юрист, привыкший работать с сотнями связанных параграфов — задачу общего видения это не решит. Есть конечно правильный подход, когда делается несколько срезов требований под разных участников команды и внешних заказчиков-подрядчиков. Но пока это явно излишне, т.к. каждое изменение требований будет вести к серьезным затратам времени на обновление таких срезов, что не слишком хорошо влияет на продуктивность стартапа.

Для себя я решил разбить на функциональные и нефункциональные требования и уложить все это в одну страницу А4. Первая версия вышла такая:

Фаза 1. Постановка задачи

Задача: Необходим максимально непрерывный объезд тренировочного гольф поля в сложных климатических условиях для сбора шаров.

Проблема: Необходим Unmanned Ground Vehicle (UGV ^[3]) для выполнения циклических миссий по объезду пространства, заданного периметром с координатами точек в WGS-84 нотации.

Миссии должны включать следующие операции:

1. Нормальный старт с известной домашней позиции
2. Аварийный старт с неизвестной заранее позиции (запуск после срабатывания WD, защиты по питанию и т.д.)
3. Объезд площади с покрытием не менее 98% пространства за 1 или несколько заездов (начать объезд поля заново после заполнения бункера через 15 минут излишне)
4. Возврат на домашнюю позицию по заполнению бункера, истощению батареи, окончанию объезда
5. Заезд на платформу старта для сброса шаров, заряда батарей

Упрощенная версия алгоритма

Кроме этого UGV должна выполнять следующие требования:

1. Не покидать указанного периметра при объезде заданного периметра
2. Домашняя позиция может находиться вне заданного периметра
3. Выполнять мониторинг расхода заряда батарей и планировать возврат с учетом израсходованной мощности. Перемещение заполненного бункера требует больше мощности от батарей, чем пустого.
4. Вести логи телеметрии включающие, но не исчерпывающиеся координатами на плоскости, значениями 6 осей вращения, уровень сигнала телеметрии и внешних датчиков.
5. Иметь три системы позиционирования — GPS для получения грубых координат, IMU для верификации и коррекции координат на плоскости, оптическая для точного позиционирования по маркерам.
6. Иметь две системы Watch Dog — программная и аппаратная. Программная верифицирует состояние
7. Иметь дальнобойный аварийный канал связи с отдельным питанием, использующийся при выходе параметров миссии за заданные параметры (координаты, авария, авария по питанию, отказ оборудования)
8. Иметь возможность изменять параметры миссии при нахождении на домашней позиции
9. Иметь два канала связи  - низкоскоростной телеметрический и высокоскоростной для передачи аудиовизуальной информации. Высокоскоростной должен иметь возможность включения/отключения по телеметрической команде.

По этим требованиям была выбрана следующая архитектура решения:

В состав роботизированного комплекса входят: один центр управления (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 ^[4] — активно развивающийся софт, начинающийся как прошивка для квадрокоптеров на Ардуино. Однако, к нынешнему моменту он поддерживает и платы на Линуксе с RTL ядром, причем открыт для доработок. Допиливать в дальнейшем пришлось к слову, но скорее для ускорения работ, чем по нужде.

Как мозги ^[5] ровера был выбран BeagleBone Blue ^[6] — высокоинтегрированная система для робототехники.

Отличительной особенностью является использование чипов 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 ^[7].

Софт не бесспорный, приличный Web интерфейс вместо швейцарского ножа с 100500+ кнопок для любителей коптеров надо сделать, но для отладочных целей более чем пригоден. Для общения с ровером использует протокол MAVLINK ^[8] адаптеров и прикладного софта под 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 ^[9]. Плату подключения модулей для версии на raspberry pi и orange pi мы очень долго ждем от n12eq3 ^[10]. Версия с Ardupilot Владимир Гончаров Shadow_ru ^[2]

Благодарим за предложенную помощь и советы Process0169 ^[11], Trif ^[12], tersuren ^[13], vasimv ^[14], vovaekb90 ^[15], Вячеслава Солдатова, Левона Закаряна, Сергея Помазкина, Vladi Kuban, Karen Musaelyan, Алексея Платонова. Если Вы желаете помочь — просьба написать мне в ЛС или ВК ^[16], FB ^[17].

Планы:

У нас есть предварительные договоренности по размещению робота для тестов в гольф-клубах в России, Германии, Латинской Америке и Новой Зеландии. В ближайших планах доработать алгоритмы и конструкцию, провести тесты в Москве и внести доработки. Создать 5 роботов и бесплатно разместить их в гольф-клубах для длительных тестов к новому сезону.

Спасибо, что дочитали, спрашивайте и критикуйте нас полностью.

Автор: webzuweb

Источник ^[18]