ROS. Стек навигации

    title


    В данной статье будут рассмотрены подходы и библиотеки, предоставляемые ROS для решения задач автономной и не очень навигации.


    Также будут рассмотрены несколько специфичных для антропоморфных роботов пакетов. Любой робот (наверняка даже машинка со средне-мощным бортовым ПК под управлением Linux и парой веб камер) наверняка найдет здесь что — нибудь для себя.


    Если же аппаратура слишком слаба для подобных вычислений, можно воспользоваться распределенностью ROS, которая позволяет нодам на разных машинах взаимодействовать между собой. Подобный вариант описан здесь.


    Тезарус


    Карта препятствий (Occupancy Map, Grid)


    occupancy_grid


    Двухмерная дискретная карта, в которой каждая ячейка может быть в одном из трех состояний:


    • occupied_cell
    • free_cell
    • unknown_cell

    Облако точек (PointCloud)


    point_cloud


    В ROS облака точек существуют в основном в виде sensor_msgs/PointCloud2.


    Плотное облако точек


    octree


    Аналог Occupancy Grid, но в 3D.


    В данной статье по умолчанию будет подразумеваться реализация из библиотеки Octomap.
    Хороший разбор данной библиотеки в этой презентации.


    Концепция нод / топиков / подписчиков


    Если кратко, то вы можете запустить свою программу в контексте ROS, где она будет нодой (Node).
    Также существуют топики (Topics). Это своего рода именованные ящики, в которые ноды могут складывать и из которых забирать сообщения различных типов (например объекты типов geometry_msgs::Pose, sensor_msgs::PointCloud2, nav_msgs::Path и многих других).


    Любая из нод может публиковать в любые топики, а также считывать из любых топиков сообщения.
    Ноды работают асинхронно друг от друга.


    Если не совсем кратко, то



    ROS


    Robot operating system — очень удобная платформа для реализации роботехнических проектов.
    ros_pipeline


    • Удачная концепция пакетов (можно использовать функционал библиотек, просто запустив соответствующую ноду)
    • Предоставляет много нужных пакетов для робототехники
      В частности хорошо развиты стеки:
      • Навигации
      • Локализации
      • Картографии (SLAM алгоритмы)
    • Предоставляет визуализаторы, удобную концепцию сообщений и подписчиков и много другого.

    Подробности


    SLAM (с англ. одновременная локализация и картография)


    slam


    Для автономной навигации, да и вообще чего — либо, требующего полной информации об окружении нужна карта самого окружения.


    Для этих задач хорошо подходит карта в виде облака точек, из которой в дальнейшем можно получить другие варианты карт (плотное облако точек, OccupancyGrid).


    Vision-based SLAM алгоритмы позволяют строить карту окружения и приблизительно оценивать местоположение в ней.


    На входе


    datasources


    Данные с датчиков, помогающих оценить местоположение.


    Например:


    • ИНС
    • Данные с моторов
    • и т.д.

    Данные с Vision датчиков


    RGB-D Camera

    rgbd


    • Представители: Kinect, Real Sence, Asus Xtion
    • Предоставляет RGB снимок и карту глубины
    • Хорошо поддерживаются мними библиотеками
    • Дает приемлемую точность (зависит от расстояния. От 1 мм до 5 см)
    • Дальность 4 метра
    • Слепая зона 0.5 метра
    • sensor_msgs/PointCloud2

    Stereo Camera

    stereo


    • Высокая дальность
    • Практически нет слепой зоны
    • Точность ниже, чем у RGB-D камер
    • Пара веб камер — не являются хорошей стереокамерой (но чем черт не шутит)

    Lidar

    lidar


    • Очень высокая дальность
    • Не менее высокая стоимость
    • sensor_msgs/LaserScan

    На выходе


    • Карта окружения
    • Аппроксимация местоположения

    SLAM пакеты в ROS


    Примечание: в ROS можно получать облака точек со стереокамер или RGB-D камер. В свою очередь облака точек можно преобразовывать в LaserScan, который является ходовым форматом ROS сообщений для лидаров и принимается некоторыми из описанных ниже пакетов.


    Это значит, что имея на руках стереокамеру, вы скорее всего сможете использовать SLAM алгоритмы, принимающие данные от Лидаров или RGB-D камер. Аналогично для RGB-D камер, вы сможете использовать их в качестве Лидаров.


    rtabmap_ros


    ROS пакет, предоставляющий обвертку над бибилотекой rtabmap. Наверное, самый популярный, удобный в использовании и многосторонний пакет.


    • Качественная документация
    • Поддерживает многие датчики в качестве источников данных (ряд RGB-D камер, стерео камеры, лидары)
    • В меру требовательна к ресурсам даже при создании больших карт (хватает ноутбука с Intel Core i3 + 4 Гб RAM)
    • Имеет множество интересных настроек, влияющих на скорость работы / качество
    • Предоставляет много дополнительных функций.
      Например:
      • строит карту препятствий путем проецирования групп точек, начиная с некой высоты
      • имеет интеграцию с move_base (см ниже)
      • имеет ноду сегментации облака точек на 2 других облака (препятствия и земля)
    • Интеграция с библиотекой Octomap (спец. структуры для создания, хранения и обработки плотных облаков точек)

    hector_slam


    SLAM алгоритм, строящий 2D карту препятствий.
    По умолчанию использует данные от лидара, но
    с тем же успехом ему на вход можно подавать данные со стереокамеры, RGB-D камеры (см примечание вначале главы).


    Близкий родственний: slam_gmapping.
    Наверняка это самые легковесные реализации SLAM алгоритмов.


    ElasticFusion


    • строит мешь
    • высокие требования к ресурсам (GPU)
    • Не имеет пакета в ROS

    Эта библиотека хорошо рассмотрена в этой статье.


    Подходы к решению задачи автономной (и не очень) навигации


    В этом разделе будут разобраны основные подходы для решения вышеупомянутой задачи, которые предоставляет ROS. В официальном туториале представлена лишь малая часть из них. Для ряда роботов имеются готовые решения (разделы 6.2 — 6.6 по ссылке выше). Также советую посмотреть эту ссылку. Возможно имеет смысл немного переписать их код, если ваш робот похож на одного из представленного там списка.


    Также есть ряд пакетов, не упомянутых в источниках выше. Особенно решения для коптеров.


    Планирование по Карте Препятствий (OccupancyMap)


    occupancy_map


    Этот подход позволяет решать задачу навигации на плоскости, что довольно просто в алгоритмическом смысле.


    Карту препятствий (см в тезарусе статьи) можно получить из облака точек несколькими способами:


    • На основе среза на определенной высоте из облака точек
    • Как проекцию всех точек на плоскость z = 0 начиная с какой — нибудь заданной высоты z =?..
      Такой вариант предоставляет rtabmap.
      У него имеется много параметров, как то:
      • допустимый угол наклона "плоскости"
      • количество точек вблизи, которые стоит считать за препятствие
      • многое другое
    • Некоторые реализации SLAM алгоритмов изначально строят лишь карту препятствий (см. выше)

    ROS концепция move_base


    move_base


    Хорошо пододит для колесных роботов. Это концепция ROS, которая состоит из 2 планеров.


    Global Planner

    Ищет по Карте Препятствий глобальный маршрут в виде линии.


    global_planner


    Local Planner

    На локальный планер ложится рассчет скоростей и углов, так чтобы избежать столкновений.


    local_planner


    Далее скорость и углы подаются на ноду, управляющую роботом. Хорошо подойдет для колесных платформ.


    footstep_planners


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


    Применение такого варианта возможно, если контроллер робота может "выполнять" задания вида "наступить в точку с заданными координатами".


    На мой взгляд, при планировании должны быть учтены условия равновесия робота, хоть планирование и осуществляется из набора "безопасных шагов". Или при реализации шага контроллер робота должен оценивать возможность реализовать его, не упав при этом.


    footstep_planner & humanoid_navigation
    footstep_planner


    footstep_planner — часть решения humanoid_navigation по навигации антропоморфного робота в известном окружении.


    footstep_planner предоставляет возможность планировать маршрут в виде набора положений ступней, ведущей из стартовой в конечную позицию.
    Планирование осуществляется на 2D карте препятствий.


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



    Vigir_footstep_planner


    vigir_planner


    Это идейный продолжатель footstep_planner'a в 3D пространстве. При помощи него можно прокладывать маршрут прямо в плотных облаках точек. В комплекте — плагин к Rviz, позволяющий редактировать полученный маршрут.


    Подробности в публикации


    3D navigation


    3d_nav


    Расширение move_base, описанного выше до 3D с проверкой коллизий. Используется моделька робота и плотная 3D карта окружения.


    Интересная публикация по этому пакету


    Move It


    move_it


    Пакет планирования сложных движений для роботов любой конструкции. Робот представляется в виде модели с учетом всех подвижных частей и ограничений на их передвижения. Далее можно рассчитать траекторию всех конечностей робота при его переходе из одного состояния в другое. Возможен учет коллизий с окружением в виде плотных облаков точек (by Octomap).


    В доументации к MoveIt можно найти ряд моделек, которые можно экспортировать и поиграться с ними. Среди туториалов хорош этот, показывающий работу с библиотекой из C++ кода.


    Интересные ссылки


    Качественный разбор SLAM алгоритмов (англ.)



    Упомянутые в статье


    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 3

      0

      Сейчас я разрабатываю систему автономной навигации вместе с Alex_ME для AR600E.
      Этим обусловлено наличие пары пакетов для антропоморфных роботов в статье =)
      На сбор этой информации ушло довольно много времени.
      Надеюсь, кому — нибудь этот материал окажется полезным.

        0
        А как вообще выглядит жизненный цикл работы программы для робота?
        Нужно написать некий код, который подгрузит карту, найдёт текущее положение, поставил задачу планировщику (конечную точку) и будет крутить в цикле какой-то next_step(), пока робот не окажется в конечной точке? Потом обернуть запуск этой ноды и всех зависимостей в .launch?
          +1

          Привет!
          Некоторое время не следил за темой — возможно ребята (из / вместе с) ros уже придумали какой — нибудь комплексный подход. Мне в голову пришло следующее:


          1 — вроде у slam rtabmap есть некий localization mode и там говорится о multi-session mapping.
          возможно, локализацию в уже построеной карте можно положить на этот узел.


          2 — дальше в зависимости от того, что у нас за железо (ходящее, ездиющее, ползающее) и насколько оно маневренное — берем из карты какой — нибудь упрощенный агрегат — octomap, occupancy_map для планирования маршрута / движения


          выбор цели — отдельная история (широкий простор для фантазии).
          для простоты — можно попробовать задавать вручную — например с удаленной машинки.
          http://wiki.ros.org/ROS/Tutorials/MultipleMachines

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


          Здесь могу соврать — с этим почти не работал.

          Где это считать? Хороший вопрос.
          Мне кажется хорошей идеей считать это на отдельной машинке — думаю, встраиваемое железо, которому хватит сил bubuntu + ros + slam + планировщик — дорогое и в этом мало смысла.
          Интересная задачка — стриминг point_cloud по сети — тоже недешево (они вроде большие).
          Хотя, наверняка их пережимать можно.


          Писать скорее всего придется мало — и в основном конфиги =)
          Самое сложное уже давно реализовано.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое