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

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

    Позиционирование ведется по 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 роботов и бесплатно разместить их в гольф-клубах для длительных тестов к новому сезону.



    Спасибо, что дочитали, спрашивайте и критикуйте нас полностью.
    Golf Robotics
    Производство роботов для сбора мячей для гольфа
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 27

      +1
      Довольно интересно)
      Но почему никто не догадается сделать робота по привозу чая/кофе к столу программиста, иногда работы валом, и просто некогда сделать чай…
        +2
        «Будь у меня такой котробот, я б и не женился вовсе» ©Простоквашино :)
      +1
      Как база ровера — использована модельная машинка масштаба 1/18 с отдельными приемником и контроллером двигателей.

      А в будущем база какая будет? Модельные варинаты — довольно нежные, а запчасти недешёвые. Я как-то пытался сварганить этакий железобетонный вариант, но получилось так себе — без омни или рулевого управления какая-то печаль получается.
        0
        В будущем база будет примерно как тут https://habr.com/post/421467/
          +1
          Проект классный.
          Но есть вопрос: на какую страну вы ориентируетесь? В США ваши роботы наверняка на ура будут продаваться, нежели чем в России.
          И еще: вы сейчас нацелены только на продажи для гольф-клубов?
            +1
            В мире более 34.000 гольф-клубов. Почти половина в Северной Америке.
            В России около 40.
            Конечно же основные рынки — США, Европа, Азия, Австралия и Новая Зеландия.
            Это робот B2B, исключительно клубам. Игроку он не нужен.
            Вообще идея при разработке этого робота получить платформу. Уже платформу использовать для создания других роботов( например робот — заливщик льда или ледовый комбайн) и продажу UGV в исследовательских целях.
            +1
            Шарики для гольфа это конечно классно.
            Для России будет версия, адаптированная для сбора грибов?
              +1
              Для заливки льда на катках.
                0
                Чёт сразу «Поколение П» в голову пришло при прочтении вашего комментария.
                Владлен Татарский одобрил бы изобретение такого робота ведь в перспективе это одна из дорог к быстрому обогащению...
                Сушеные мухоморы немного напоминал по вкусу картофельные хлопья, только были вкуснее — Татарский подумал, что их можно было бы продавать, как чипсы, в пакетиках, и здесь, видимо, скрывалась одна из дорог к быстрому обогащению, джипу, рекламному клипу и насильственной смерти.

                –1
                Зачем проезжать по всему пространству, если можно в каждый мяч поместить пассивный или активный радиомаяк? Бот испускает сигнал (в случае пассивного), мяч отвечает, бот едет к нему.
                  +1
                  Потому что мячи уже есть.
                  Потому что их за день на поле более 10.000шт.
                    0
                    Что мешает продавать свои мячи и при этом еще и получив денег? Одна из фич — мяч почти перестает быть расходником — потому что не теряется.
                      +2
                      Это отдельное производство, удорожание мячей. На каком расстоянии эта RFID метка будет работать?
                    0
                    Как мне кажется, электроника, которая спокойно переживает ускорение ~200g (не уверен про нагрузки на гольф шар) не так проста в производстве. Просто уголковый отражатель внутри шара для радара выльется в довольно большое количество ложно-положительных целей. Да еще батарею кушать будет этот радар. Можно подумать о радиотеленаведении, но тут могут быть проблемы с размещением (условно) стационарных радаров.
                      0
                      Проще камер высокого разрешения понаставить, мяч не так уж и сложно будет на изображении найти. Потом робота в ту сторону направлять.
                        0

                        Дроном облететь поле с камерой и нарисовать карту мячей

                        0
                        В этом плане лучше идти от обратного и подумать в сторону сенсорного покрытия
                        +1
                        Игроки (особенно те, которые промахиваются) — будут жаловаться, что мячи «какие-то не такие». Учитывая аудиторию — лучше им не перечить. :)
                          +1
                          Термостат разбудил сеньору опять :)
                        0
                        мяч всегда будет рассадником
                          0
                          Я просто оставлю ссылку тут www.youtube.com/watch?v=sKpaXItXNfo
                            0
                            Да, просто уже размещал это видео в первом посте habr.com/post/421467
                            0
                            Готов присоединиться к разработке ROS-версии и платы для апельсинки или малинки. Как раз есть удачный опыт в проектировании подобной платы под OrangePI Zero для проекта «умного кресла». По началу тоже использовал ROS, но в итоге написал собственный код на С для работы с датчиками и периферией, обменом данными с WEB-интерфейсом, и голосовым управлением. Так-что возможно что-то из этих наработок пригодится и для этого проекта.
                              0
                              Маленький тип для этой идеи.
                              Камеры класса PTZ и фотосъемка с эффектом «Длинная выдержка», таким образом Вы получите готовый трек мяча из точки А в точку B с привязкой к масштабу, далее датчик движения по линии.
                                0
                                Это нужно очень хорошие камеры и системы хранения и обработки. На полях для гольфа часто солнце вовсю светит, небо и земля сразу в кадре, контраст очень большой. Ну и чисто программно — очень сложная задача, там же и птички всякие летают, их тоже за мячи можно принять.
                                  0
                                  А никто и не обещал, что будет легко, к слову сам по себе гольф, удовольствие не из дешевых. Алгоритм отображения трека вполне решабельный, количество камер подбирается экспериментально, трек отображается в реальном времени и может обновляться по мере темпа игроков, а вот в Вашем случае тот факт, что в алгоритме задействована GPS, картография, та же оптика, система распознавания и нечто Х связующее, что упирается в небо…

                              Only users with full accounts can post comments. Log in, please.