Сервисный робот Tod. Первые шаги вместе с ROS



    Добрый день, Хабр. Наша команда занимается разработкой сервисного робота Tod. Мы стремимся к созданию многофункционального робота, который в своих возможностях сможет потягаться с такими флагманами в мобильной робототехники как PR2 Willow Garage. Мы начинаем с малого, но с каждым днем наш робот приобретает новые навыки, оснащается новыми сенсорами. О том, что вообще из себя представляют сервисные роботы, вы можете узнать в нашей предыдущей статье, а сегодня речь пойдет о реализации навигационной системы Tod. Сегодня мы расскажем как научить робота выполнять навигационную задачу определения собственного местоположения на базе колесной одометрии и получать сенсорные данные с ультразвуковых сонаров. Всё это дело будет управляться под операционной системой для роботов ROS (Robot Operating System), которая хорошо зарекомендовала себя в различных робототехнических проектах. Добро пожаловать под кат.

    У обывателя слово «робот» скорей всего ассоциируется с умными человекоподобными роботами из фантастических фильмов в духе Терминатора. Чем отличаются настоящие роботы от обычных машин? В первую очередь, роботы обладают автономностью, которая выражается в способности самостоятельно, без вмешательства человека, принимать решения.
    Автономный робот для достижения поставленной цели должен уметь решать навигационные задачи. К базовым навигационным задачам можно отнести восприятие окружающей среде на основе интерпретации данных, поступающих с различных видов сенсоров (дальномеры, камеры, GPS-навигатор, специальные маяки и т.д.), планирование маршрута движения и интерактивное взаимодействие с окружающей средой с помощью исполнительных органов, колес и манипуляторов.
    В основе качественных навигационных алгоритмов лежит сложная математика, поэтому у многих начинающих робототехников пропадает энтузиазм после столкновения с расчетами якобианов и кватернионов, построением кинематической модели и применением вероятностных алгоритмов. К счастью, на сегодняшний день существует множество робототехнических фреймворков таких, как ROS, Player и Microsoft Robotics Studio, с помощью которых даже новички, обладающие необходимой настойчивостью, смогут использовать в своих проектах сложные навигационные и ИИ алгоритмы.

    ROS и навигационный стек


    Наша команда неслучайно решила использовать для робота Tod опенсорсный фреймворк Robot Operating System. ROS на сегодняшний день находит применение в робототехнических проектах многих исследовательских групп и компаний. Этот фреймворк предоставляет возможности, сравнимые с функциями целой ОС, включая аппаратные абстракции, управление устройствами на низком уровне, реализацию базовых функций и алгоритмов, передачу сообщений между процессами и менеджер пакетов. Исполняемая в ROS программа представляет собой набор узлов, которые могут обмениваться между собой сообщениями, подписавшись на общую тему. Такие узлы можно независимо реализовывать на языках C++ и Python. ROS полноценно работает под управлением Ubuntu, в частности, мы используем для Tod Ubuntu 12.40 и ROS Groovy. Более подробную информацию о ROS, документацию и хорошие пошаговые руководства можно найти на ros.org.
    Для решения навигационных задач ROS предоставляет навигационный стек. В качестве входных данных стек использует данные одометрии (пройденный колесами робота путь) и сенсоров, а на выходе передает роботу команды управления скоростью передвижения. Использование на роботе навигационного стека «из коробки» становится возможным при выполнении некоторых условий:
    — Робот по форме должен быть круглым или прямоугольным, а его колеса должны быть неголономными, т.е. движение робота должно осуществляться только вдоль направления вращения колес. Например, колеса автомобиля или велосипеда — неголономные.
    — Робот должен предоставить информацию о всех геометрических связях между кинематическими узлами и сенсорами робота. Эта информация задается в URDF модели, а сложные геометрические преобразования из одной системы координат в другую с использованием матриц поворотов, углов Эйлеров и кватернионов может осуществлять узел tf.
    — Робот должен посылать сообщения для управления перемещением в формате линейной и угловой скорости.
    — Для решения задач определения местоположения и построения карты должен использоваться лазерный дальномер или 3-D сканер. Однако, если несколько схитрить, то можно использовать вместо дорогостоящих сенсоров и другие более дешевые аналоги: сонары или инфракрасные дальномеры. В этом случае, главное соблюдать правильный формат сообщений, которые передаются исполняемому узлу.



    На диаграмме представлена общая схема навигационного стека. Текст между стрелками указывает на тип сообщения, которым обмениваются узлы. В этом стеки присутствуют 3 вида узлов:
    — Узлы, помещенные в белый прямоугольник предоставляются ROS
    — Узлы, помещенные в серые прямоугольники тоже предоставляются ROS, но их использование в стеке не является обязательным
    — Узлы, помещенные в бирюзовые прямоугольники, являются аппаратно-зависимыми и их реализация обычно лежит на плечах разработчика.
    Теперь, когда требования к использованию навигационного стека ROS известны, можно приступить к его адаптации к нашем роботу Tod.

    Base controller и управление перемещением


    Base controller — это узел навигационного стека, отвечающий за управление перемещением робота. ROS не предоставляет стандартного base controller'а, поэтому для своего робота необходимо писать собственный узел или брать за основу сторонние опенсорсные решения. Команды управления перемещением робота передаются к base controller в теме cmd_vel в сообщениях типа geometry_msgs/Twist.
    geometry_msgs/Vector3 linear
      float64 x
      float64 y
      float64 z
    geometry_msgs/Vector3 angular
      float64 x
      float64 y
      float64 z
    

    Вектор linear задает линейную скорость перемещения робота по осям x, y, z, а вектор angular — угловую скорость перемещения по осям x, y, z. Далее эти команды преобразуются в команды управления вращением двигателей, и робот осуществляет перемещение в заданном направлении.
    Порядок задания векторов скоростей зависит от кинематики робота. Наш робот Tod оснащен двухколесным дифференциальным приводом на базе двигателей постоянного тока, который позволяет ему перемещаться вперед, назад, по дуге или вращаться на месте. Это означает, что в сообщении geometry_msgs/Twist будет задаваться только линейная скорость по оси x (соответствует движению вперед-назад) и угловая скорость z (соответствует вращению на месте или перемещению по дуге при задании ненулевой линейной скорости).


    3-х колесный робот с дифференциальным приводом. Рулевое колесо или шаровая опора обеспечивает роботу устойчивость.

    Преобразование этих скоростей перемещения робота в соответствующие скорости вращения двигателей — тривиальная задача по кинематике, требующая некоторых геометрических расчетов.
    Низкоуровневую задачу управления вращением двигателем мы поручили Arduino Uno в связке с драйвером Pololu Dual MC33926 Motor Driver Shield, выдающего небходимую мощность для наших 12-ти вольтовых двигателей. После реализации base controller'a можно покататься роботом с помощью клавиатуры и ROS-вского узла turtlebot_teleop, посылающего сообщения geometry_msgs/Twist base controller'у.



    Одометрия


    Одометрия – самый распространенный метод счисления пути. Суть этого метода заключается в определении позиции робота на основании подсчета инкрементальных оборотов колес относительно любой фиксированной точки на карте. Обычно измерения одометрии производятся оптическими цифровыми энкодерами, закрепленными на колеса или непосредственно на двигатели робота. Tod оснащен цифровыми энкодерами c разрешением 64 импульса на каждый оборот вала двигателя, что соответствует 8384 импульсов на один оборот колеса.


    Геометрия одометрии. При заданной позиции робота (x, y, theta) и ширины колесной базы dbaseline требуется рассчитать новую позицию (x', y', theta').

    Навигационный стек использует сообщения типа nav_msgs/Odometry для получения данных одометрии.
    std_msgs/Header header 
      uint32 seq 
      time stamp 
      string frame_id 
    string child_frame_id 
    geometry_msgs/PoseWithCovariance pose 
      geometry_msgs/Pose pose 
        geometry_msgs/Point position 
          float64 x 
          float64 y 
          float64 z 
        geometry_msgs/Quaternion orientation 
          float64 x 
          float64 y 
          float64 z 
          float64 w 
      float64[36] covariance 
    geometry_msgs/TwistWithCovariance twist 
      geometry_msgs/Twist twist 
        geometry_msgs/Vector3 linear 
          float64 x 
          float64 y 
          float64 z 
        geometry_msgs/Vector3 angular 
          float64 x 
          float64 y 
          float64 z 
      float64[36] covariance
    

    Сообщение geometry_msgs/Pose определяет текущую позицию робота в трехмерном пространстве и ориентацию, которую в случае вращения объекта в трехмерном пространстве будет удобно рассчитывать кватернионами. Уже знакомое нам сообщение geometry_msgs/Twist определяет линейную скорость x и угловую скорость z.
    Так как при выполнении вычислений мы имеем дело с несколькими системами координат, то нам понадобится узел tf. Узел tf работая с URDF-моделью робота, берет на себя заботу по выполнению громоздких вычислений преобразования позиции из локальной системы координат робота в глобальную систему координат карты.


    Визуализация URDF-модел робота Tod с данными одометрии в симуляторе Rviz.

    Сонары


    Робот может использовать различные виды сенсоров для получения информации об окружающем мире. Сенсоры сильно различаются по своим характеристикам, имеют свои ограничения, слабые и сильные стороны, поэтому наиболее выгодным считается совместное использование нескольких их видов.
    Используя ультразвуковые сонары можно измерять расстояние от объекта до робота. Сонары работают по технологии TOF (time-of-flight). Они испускают звуковой сигнал, который отражается от ближайшего на пути объекта и возвращается в виде эха. Время «полета» сигнала фиксируется, и на его основе рассчитывается расстояние до объекта.


    Сонар испускает звуковой сигнал и «слушает» эхо.

    Tod использует сонары HC-SR04, поддерживающий диапазон измерения от 0.2 до 5 м с заявленной точностью 0.03 м. Угол обзора одного HC-SR04 составляет 30 градусов, и если разместить несколько сонаров рядом, то можно получить больший угол обзора. 3 сонара, размещенные на передней стороне Tod обеспечивают угол обзора 90 градусов.



    Навигационный стек ROS может использовать данные различных видов сенсоров для получения одометрии, построения карты помещения или объезда препятствий. Теоретически есть возможность использовать сонары для построения карты помещения, ведь 12 или более сонаров дают угол обзора в 360 градусов и представляют более дешевую замену дорогостоящим лазерным дальномерам. Tod для построения карты использует Kinect, который по многим сенсорным характеристиками превосходит сонары. Однако, это не повод сбрасывать сонары со счета. Kinect закреплен на роботе достаточно высоко, что не позволяет видеть происходящего прямо под колесами. Сонары захватывают эту слепую зону, тем самым оказываясь полезными в решении задач планирования пути и объезда препятствий.
    Как было сказано раннее, навигационный стек поддерживает работу только с лазерным сенсором и 3-D сканером. Это ограничение можно обойти, представив систему сонаров в виде фейкового 3-D сканера. 3-D сканер использует сообщение sensor_msgs/PointCloud, описывающее облако точек в трехмерном пространстве.
    std_msgs/Header header 
      uint32 seq 
      time stamp 
      string frame_id 
    geometry_msgs/Point32[] points 
      float32 x 
      float32 y 
      float32 z 
    sensor_msgs/ChannelFloat32[] channels 
      string name 
      float32[] values
    

    Сенсорные данные сонаров можно представить в таком формате, задав каждую точку облака в виде координат x, y и координаты z равной 0. При этом на каждый сонар можно задать несколько таких точек, что позволяет повысить плотность облака. Вот так выглядит визуализация сенсорных данных сонаров Tod.


    Визуализация сенсорных данных сонара в Rviz.

    Спасибо за внимание, на сегодня это всё. В следующей статье мы продолжим рассказывать о возможностях навигационного стека ROS на примере нашего подопытного: подключим к Tod Kinect, построим с его помощью карту квартиры, научим планировать маршрут и объезжать препятствия.
    TOD
    Компания
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

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

      +1
      Отлично.
      Спасибо.
      Вот и начали появляться адекватные статьи по ROS на русском языке.
      Хотелось бы поинтересоваться, а на каком микроконтроллере реализовано считывание данных и передача в Ubuntu с сонаров?
      А также, 3 сонара дают более точную картину, чем один, закрепленный на сервоприводе (так называемый, «лазерный дальномер для бездных»)?
        0
        Спасибо за интерес к проекту.

        Сонары так же подключены к Arduino Uno. На сонаре располагаются два цифровых пина: Trig — для испускания сигнала, Echo — для приема эха. Небольшой хак позволил считывать данные сонара с использованием только 1 порта Arduino, таким образом экономим порты). Для этого порт сначала переключается на вывод OUTPUT для испускания сигнала, а потом переключается на ввод INPUT для ожидания приема эха.

        Касательно сравнения 3 сонаров против одного «лазерного дальномера для бедных», сравнительных тестов не делали, т.к. решили сразу использовать несколько дальномеров. Однако, давайте порассуждаем:
        — у каждого сонара есть сектор охвата 30 градусов, если расположить их таким образом чтобы их зоны действия перекрывались — увеличим точность одназначно, хотя потеряем в общем охвате где-то градусов 15(если вести речь о 3 сонарах и перекрытием в 5 градусов);
        — 3 сонара дадут нам информацию о перманентном состоянии окружающей среды в зонах охвата, чего не сделает один (особенно это актуально при быстром перемещении).
        — также необходимо учитывать геометрию расположения сонаров, т.к. существеут проблема при отражении сигнала от круглых и находящихся под углом предметов. При одном сонаре на серве мы будем принимать сигнал в одну единственную точку, а при трех соответственно в 3 разные.
        image
        — и конечно же экономическая составляющая по грубым подсчетам серва стоит порядка 300р, сонар 100 — 150р. И того «лазерного дальномера для бедных» = 1 серва + 1 сонар = 3 сонара.
          –3
          Я правильно понял, что при круглых препятствиях вы считываете на 3 сонарах сигнал?
          То есть перманентно вы испускаете импульс только одного сонара, а считываете на 3-х?
            0
            Нет. Имелось ввиду что мы будем иметь 3 независимые точки получения сигнала находящихся в разных местах.
            В данный момент сонары используются для идентификации объектов(есть объект перед роботом — объезжаем, нет объекта — едем дальше), а не определения формы препятствия(про построение карты и форм объектов будет в следующей статье). Реализован алгоритм который последовательно запускает и опрашивает сонары, т.е. первый сонар испустил сигнал, принял отраженный сигнал, выдал результат, второй сонар и т.д.
            Идея испускания сигнала одним, а прием всеми — очень интересная и над этим мы подумаем. Спасибо за мысль.
          0
          Серва «фонит» и искажает данные с сонара. Это тоже надо учитывать.
          –1
          На первое фото изображен ваш робот? Если так, то почему вы не использовали Kinect для одометрии? В ROS есть неплохая имплементация RGBD слэма…
            0
            Мы уже используем Kinect, визуальную одометрию и SLAM. Этому будет посвящена следующая статьи, о чем сказано в конце этой (вы, наверно, не дочитали еще до туда).
              –1
              Да, пардон не дочитал до туда когда писал коммент…
              А еще ваш TOD до боли напоминает Turtle Bot от тех-же Willow Garage…
                0
                Да, это потому что при создании прототипа мы взяли конструкцию Turtle Bot за основу. :)
            0
            Спасибо за замечательную статью!

            Исправьте, пожалуйста, небольшую неточность: колеса у автомобиля и у велосипеда — неголономные.

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

              В таком случае верхний ярус платформы будет перекрывать обзор Kinect'a.
                0
                Не будет, у кинекта слепая зона около 50 см.
              0
              А на каком оборудовании располагается ROS и как соединяется с ардуино?
                0
                На данный момент используем ноутбук: Core 2 Duo 1.8 GHz, 2 Gb RAM. Для текущих испытаний его более чем достаточно, но необходимо учитывать и тот факт что с течением времени функционал будет расти, что скажется на потребляемых мощностях. И конечно же мы еще не производили оптимизации самого дистрибутива Ubuntu. В общем, выводы по железу можно будет сделать по окончательной реализации основных функциональных блоков и проведения нагрузочного тестирования.
                Касательно соединения ардуино c ROS, есть два пакета rosserial и ros_arduino_bridge. Мы используем ros_arduino_bridge.
                  0
                  Правильно лия понимаю, что ноут располагается на шасси робота и кабелем соединен с ардуино?
                    0
                    Если об этом — ДА! Наша цель сделать робота максимально независимым и автономным. Соответственно все должно быть при нем)
                0
                А вы не думали использовать вместо Kinect устройство Leap Motion?
                  0
                  Сомневаюсь что данный девайс подойдет. Не удалось найти информации по поводу рабочей дистанции, думаю он ограничен 1,5м. Если мои рассуждения ошибочны — жду поправок.
                  Но за мысль спасибо!
                    0
                    Возможно вы найдете ответы на свои вопросы, а может и новые дельные советы, ознакомившись с нашей следующей статьей — Что роботу стоит карту построить?
                      0
                      Спасибо. Я прочитал ваш следующий пост, очень интересно. Подскажите для примера, какой лазерный дальномер рекомендуется использовать вместе с ros?
                        0
                        Я думаю в данном вопросе следует отталкиваться от суммы которую Вы готовы потратить на лазерный дальномер. Профессиональный дальномер начального уровня такой как Hokuyo URG-04LX-UG01, начинается от 1000$. Бюджетная альтернатива, с наилучшим соотношением цена качество, которая имеется на сегодняшний день — это Kinect.
                          0
                          В данный момент на ebay уже можно купить 2D-лидар до 100$, например от пылесоса Neato XV-11 www.ebay.com/itm/331137478720
                          Драйвер под ROS для него имеется. Тут подробнее robocraft.ru/blog/robots/725.html
                          Также он компактнее Kinect однозначно будет и по идее точность выше.
                          Но это все догадки и хотелось бы услышать мнения по этому поводу…
                            0
                            Да. Лидар от пылесоса Neato вещица интересная и наш взор периодически падал на него, но на тот момент на ebay были доступны только б\у модели в единичных экземплярах. Исходя из того материала который есть в сети, он очень хорош, но собственного опыта касательно этого продукта, к сожалению, не имеем. В связи с этим мы уже сделали заказ, около недели назад, для тестов и в скором будущем сделаем небольшой обзор.
                    0
                    Спасибо большое за хорошую статью! Это первая статья из мною прочтенных, которая описывает возможности ROS на русском языке понятным образом.

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

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