Хабрахабр

Проектирование сервисного робота. Постановка задачи, архитектура решения

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

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

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

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

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

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

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

Проблема: Необходим Unmanned Ground Vehicle (UGV) для выполнения циклических миссий по объезду пространства, заданного периметром с координатами точек в 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 метров влево или вправо на развороте не решает почти ничего, а на земле же приведет к авариям и катастрофам. Хотя казалось бы — вот есть решения для летающих дронов, переиспользуй на земле и все. Птицы таки да, но места в воздухе сильно побольше. К тому же в воздухе камни свое место не меняют, дорогу живность не перебегает.

Координаты для uBlox M8N модуля по стационарным тестам: 2-3 метра в хороших условиях приема, 7-10 при плохих погодных условиях и видимости. Позиционирование ведется по GPS/ГЛОНАСС модулю, что сразу приводит к двум последствиям: точность позиционирования не слишком велика  и скорость получения координат. Однако в этом случае получается так, что нельзя его вести рядом с препятствиями типа стен или крупных камней и в данных областях шары будут копиться. В общем-то такие погрешности для задачи сбора шаров даже хорошо — ровер за несколько миссий захватит шаров больше чем ездящий по как по рельсам. Так что пока GPS наше все, но с оговорками. Были проанализированы оптические и УЗ системы навигации, однако выяснилось что надо большое кол-во маячков/камер при сложной геометрии поля, есть проблемы с зонами видимости (поле не всегда ровное как пол в ангаре) и не стабильная работа таких систем при сложных погодных условиях (дождь, туман). Причем повысить точность GPS можно достаточно дешево — RTK, но проблему стен оно не решит.

Залезать с ногами в поезд под названием SLAM для простенькой задачи кажется излишним. Стало ясно, что выбранный подход, когда ровер ползет по загруженным точкам с точностью в 5-10 метров влево-вправо требует проверки. Если въезд в станцию по оптически ярким объектам (Aruco Code) как делать ясно, и сколько это требует ресурсов — тоже, то решение задачи классификатора всех возможных объектов на поле или нахождение границ это задачи совсем другого порядка.

Пришло время для фазы 3 — Proof of Concept

Необходимо сделать макет системы, опробовать в действии на поле, оценить применимость. По выработанным требованиям дело пошло гораздо веселее:

Однако, к нынешнему моменту он поддерживает и платы на Линуксе с RTL ядром, причем открыт для доработок. Как софт ровера был выбран Ardurover — активно развивающийся софт, начинающийся как прошивка для квадрокоптеров на Ардуино. Допиливать в дальнейшем пришлось к слову, но скорее для ускорения работ, чем по нужде.

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

Отличительной особенностью является использование чипов TI Sitara/Octavo, по сравнению с теми-же Raspberry там стоят Programmable Realtime Unit — PRU. Это два отдельных 200 МГц ядра, которые могут в реальном времени управлять железом, не отвлекая основное ядро прерываниями, нитками и прочей техномагией.

3 вольта, АЦП сразу заведенный одним каналом на батарею, несколько UART. Кроме этого на платформе сразу есть WiFi, Bluetooth, распаянный разъем для балансировочного кабеля, контроллер зарядки Li-Po батарей, USB разъемы для подключения телеметрии и компьютера, разъемы для серводвигателей, стабилизаторы питания 5 и 3. В общем бери и делай робота.

4 LTS. Ardurover туда встал не без проблем — использовать PRU из софта на текущий момент можно только с ядром 4. Самому роверу это жить совсем не мешает, но хочется четкого понимания в чем проблема. В более новых ядрах программирование 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, особенно если Вы проживаете в стране, где активно играют в гольф;
  • Правовые вопросы, вывоз робота из страны, патентное право, законодательные требования к конструкции;
  • Требуется помощь с упаковкой стартапа, поиском инвестиций. Мы хорошо развиваемся и без инвестиций, у нас есть план действий, формируется команда. Нам нужны скорее не деньги инвестора, а опыт и компетенции в развитии коммерчески успешного проекта.

Текущее состояние проекта

Мы готовим второй вариант корпуса. В течении недели будет готов корпус методом вакуумной формовки, об этом напишем отдельный пост.

Нижнюю часть корпуса изготавливаем фрезеровкой композитного материала.

Плату подключения модулей для версии на raspberry pi и orange pi мы очень долго ждем от n12eq3. Корпус и механику проектирует NikitaKhvoryk. Версия с Ardupilot Владимир Гончаров Shadow_ru

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

Планы:

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

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

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

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

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

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

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