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

Похоже, здесь играет роль та кривая обучения, про которую писал Brian Gerkey в своём письме, в котором сравнивал ROS и Player.

вариант кривой обучения для игры Dwarf Fortress:

Разработчики ROS позиционируют свою систему, как операционную систему для роботов (Robot Operating System) и не зря.
Дело в том, что ситуации в робототехнике напоминает историю развития ПК: для разных роботов — разные несовместимые системы.

Обычно, при разработке робота вам приходится реализовывать:
— свою архитектуру
– свой протокол обмена сообщениями
– свою систему логирования
– свою систему перехода в разные системы координат
– свой драйвер джойстика/пульта управления
– свою логику навигации
– свою систему технического зрения

И даже, если вы сможете использовать различные готовые библиотеки для этих задач, то всё равно перед вами встанет серьёзная проблема — объединить их в единую систему робота.

Вспомним экосистему ПК, состоящую из стандартных слоёв:
* железо (материнская плата, процессор, жёсткий диск и т.д.)
* операционная система (скрывает от пользователя работу с железом ПК, предоставляет API для программ)
* библиотеки и приложения пользователя

и спроецируем её на робота:
* железо робота (компьютер, контроллеры, датчики, актуаторы)
* операционная система (ROS) — скрывает непосредственную работу с «железом» робота, предоставляя единый интерфейс (API) для взаимодействия с ним.
* приложения для управления роботом.

Однако, было бы странно — не использовать возможности существующих операционных систем, поэтому ROS работает под уже готовой OC (Ubuntu Linux), в которой реализует свой дополнительный слой абстрации — для управления роботами.

Таким образом, для программ взаимодействия и управления роботом, ROS играет роль «операционной системы», предоставляя программам управления свои интерфейсы, библиотеки и готовые приложения.

Для ROS, уже реализованы драйвера, позволяющие единым образом работать со многими устройствами:
— джойстиками
— GPS
— камерами
— контроллерами
— лазерными дальномерами
и т.п.

Так же, ROS уже содержит вспомогательные библиотеки и приложения для роботов:
— преобразование систем координат
— утилиты для визуализации данных
— систему для отладки (логирования)
— SLAM
— стек навигации
— распознавание объектов
— планирование движения манипулятора
и многое другое.

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

Главный принцип ROS: «не изобретать велосипед» («don’t reinvent the wheel»)!

Сами разработчики ROS так же следуют этому принципу, стараясь использовать готовые открытые библиотеки и инструменты:

boost, OGRE, Player, OpenCV…
СMake, Python, gcc, wxWidgets…

игровой движок OGRE используется в визуализаторе rviz (в настоящее время на wxWidgets, но планируется перенос под Qt)

Исследователи со всего мира уже многие годы программируют роботов. Целью ROS является объединение готовых решений и наработок в единую среду, где любой желающий может использовать эти решения и делиться своими.

Именно поэтому, многие роботы уже работают под управлением ROS:

Возможно, проще всего, воспринимать ROS, как клей для самых разных модулей.
Можно провести параллель с миром UNIX:
не писать одну большую программу, а реализовать несколько маленьких, которые могут сообща решить поставленную задачу.
Именно так работают Узлы в ROS.
Но если в UNIX программы взаимодействуют друг с другом через каналы (pipe),
то в ROS, программы (Узлы) взаимодействуют друг с другом через Темы.
В UNIX они пересылают друг-другу данные вывода,
а в ROS — Сообщения.
Таким образом, можно брать разные программы и получать быстрый результат — просто объединяя их между собой, как кубики LEGO.
То же самое и в ROS. Только, вместо обычных компьютерных утилит, выступают программы для роботов.
Например, вместо программы поиска файлов — программа (Узел) для поиска местоположения. Вместо программы поиска нужной строки — программа (Узел) для поиска объекта на изображении с камер.
Вместо команды перемещения файла — программа для управления манипулятором.

Комбинируя готовые Узлы ROS и, по необходимости, дописывая собственные, можно существенно сократить время разработки и позволить себе сконцентрироваться только на тех задачах, которые действительно нужно решить.
Например, захотим мы запрограммировать робота принесть нам с кухни яблоко.
Если делать всё самому, то можно потратить много времени, чтобы реализовать необходимый функционал. Изучить требуемую теорию (SLAM и т.п.) и реализовать:
определение роботом своего текущего положения, навигацию, объезд препятствий, обнаружение объектов, работа с манипулятором и т.д.
Если же использовать ROS, то можно, например, взять готовый стек навигации, настроить его для работы на своём роботе и сконцентрироваться только на тех задачах, которые пока в ROS не реализованы.
Таким образом, можно сэкономить многие сотни часов, которые будут потрачены на изобретение велосипеда и сконцентрироваться на чём-то действительно новом и интересном.
Разумеется, придётся потратить время на изучение ROS и нюансов его использования, но это время намного меньше чем то, которое потребуется на решение любой из вышеприведённых задач (особенно — с нуля).

А ещё можно сравнить ROS с… Arduino!

ROS делает для роботов тоже самое, что делает обычная ОС для компьютера — скрывает от пользователя/программиста «железо», предоставляя для этого свои функции.
Но ведь, точно так же Arduino, скрывает от пользователя/программиста железо микроконтроллера, предоставляя готовый и удобный фреймворк для программирования.
Плюс расширение возможностей с помощью готовых библиотек или написания собственных. Причём, при желании, можно не использовать Arduino-вскую обёртку, а залезть на более низкий уровень.
То же самое позволяет сделать и ROS.
Как ардуино позволяет любому почти сразу же начать программировать микроконтроллеры, так и ROS позволяет прикоснуться к робототехнике не только высоколобым учёным, но и простым любителям.
Вывод: Arduino дало возможность совершить качественный и количественный скачёк в развитии различных систем автоматизации (например, в роли контроллера 3D-принтеров RepRap), а ROS даёт аналогичную возможность развития систем робототехнических!

А уж о взаимном дополнении Arduino и ROS и говорить нечего — действительно гремучая смесь 🙂

Прелесть и гибкость единого интерфейса ROS, для оборудования робота можно оценить на следующем замечательном примере.
«Poor Man’s Lidar» — PML — «лазерный дальномер бедных»
Навигационный стек ROS, требует для своей работы выполнения определённых условий: робот должен предоставлять одометрию и иметь датчик, возвращающий дистанцию (лазерный дальномер) или облако точек (Kinect или стерео-камера).
Кажется, что выполнение последнего условия потребует больших финансов, но нюанс в том, что в ROS, программе навигации для работы, фактически, требуются данные (Сообщения), формата лазерного дальномера (sensor_msgs/LaserScan) или облака точек(sensor_msgs/PointCloud).
Получается, что мы можем использовать какой-нибудь другой сенсор, для которого можем реализовать драйвер, возвращающий данные в нужном формате.
Например, заменим лазерный дальномер на «лазерный дальномер бедных» (PML) — возьмём относительно недорогой Sharp-овский ИК-дальномер и закрепим его на качалке сервомашинки. Теперь, вращая сервомашинкой из стороны в сторону мы можем получать грубую оценку дальностей в секторе.

Остаётся написать драйвер, который будет считывать значения с нашего дальномера и Публиковать Сообщения типа sensor_msgs/LaserScan — тем самым реализуется «поддельный лазерный дальномер».
ROS будет успешно считывать данные через наш драйвер, а мы сможем использовать готовый навигационный стек ROS!

Красота!
Разумеется, подобной сенсор не идёт ни в какое сравнение с обычными лазерными дальномерами, но он более доступен, а если появятся средства на приобретение обычного дальномера, то нам не придётся ничего существенно менять в программе! Только заменить сенсор (и драйвер) и всё!

Кстати, на этом же принципе, в Turtlebot-е используется Kinect. В стеке Turtlebot-а есть пакет pointcloud_to_laserscan, который преобразует облако точек, получаемое от сенсора Kinect в данные лазерного сканера (Fake Laser), что позволяет использовать готовые алгоритмы SLAM (gmapping).

Сообщество

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

продолжение следует…

Ссылки
www.ros.org
ROS Introduction
Концепции ROS
Начальные руководства (на русском)
http://answers.ros.org
Pi Robot Meets ROS
Pi Robot + ROS

По теме
Робософт — обзор существующих решений
Дистрибутивы ROS
Установка ROS (Electric)

Автор: Vladimir (noonv), 2011-2012

Эксклюзивно для robocraft.ru
копирование на другие ресурсы и публикация
без разрешения автора запрещены.