V-REP — гибкая и масштабируемая платформа для робомоделирования

в 5:06, , рубрики: api, Gazebo, open hpr, v-rep, webots, плагины, Разработка робототехники, робототехника, симулятор роботов, метки: , , , ,

V-REP — гибкая и масштабируемая платформа для робомоделирования - 1

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


Кстати, на хабре уже была публикацию на тему робосимулятора V-REP, поэтому рекомендую прочесть и ее.

Сегодня возможности использования робототехники огромны, роботы используются везде, начиная с изучения планет и заканчивая чисткой домов. Объединение в роботах трех подсистем: актуатора, сенсора и управления делает их эффективными в реальном мире, но усложняет виртуальную симуляцию. В этой статье мы хотим познакомить вас с фреймворком для симуляции роботизированных систем — V-REP.

Введение
Экспоненциальный рост вычислительной мощности компьютеров (не говоря уже о железе для трехмерной графики) вместе с появлением большого количества открытого ПО и электроники сильно изменили системы для виртуальной 3D симуляции роботов. Появилась возможность не только усложнить рабочую среду, но и обеспечить запуск физических робототехнических систем в реальном времени, а также включать в симуляцию передвижные/встраиваемые системы, управляемые непосредственно из среды.

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

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

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

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

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

Обзор методов управления моделированием.

Выполнение управляющего кода симуляции осуществляется с помощью следующих трех методов:

1. Управляющий код выполняется на другой машине.
Код может выполняться на отдельной машине или роботе, подключенному к симулятору машины через конкретную шину (например, разъем, последовательный порт и др.). Основное преимущество такого подхода заключается в оригинальности контроллера (управляющий код родной и будет работать на оригинальном оборудовании). Другим преимуществом является снижение вычислительной нагрузки на моделирование машины. Тем не менее, такой подход накладывает серьезные ограничения в отношении синхронизации с циклом моделирования.

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

3. Контрольный код выполняется на той же машине и в том же потоке, что и цикл моделирования.
Основным преимуществом такого подхода является синхронизация с циклом моделирования, отсутствие каких-либо задержек. Однако такой метод становится возможным только с увеличением вычислительной нагрузки на процессор. Этот метод часто реализуется через плагины, загруженные в симулятор.

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

Реализация V-REP.

V-REP позволяет пользователю использовать несколько возможностей для моделирования: (Таблица. 1 и Рис.2)

V-REP — гибкая и масштабируемая платформа для робомоделирования - 2

V-REP — гибкая и масштабируемая платформа для робомоделирования - 3

Встроенные скрипты
Представляют собой наиболее мощную отличительную особенность V-REP. Основной цикл моделирования lua скрипт (так называемый “основной сценарий”) — обрабатывает общие функциональные возможности. Например, он вызывает разные функции для обработки кинематики или динамики. Основной сценарий также отвечает за вызов дочернего скрипта каскадным способом. Дочерний скрипт, в отличие от основного скрипта, прикрепляется к конкретному объекту или конкретной части моделирования в процессе цикла моделирования. Он является неотъемлемой частью сценария объекта, и будет повторяться вместе с ним. Как таковой дочерний скрипт представляет собой вполне портативный и масштабируемый элемент управления: в нем есть один единый файл, содержащий определение модели вместе с ее контролем или функционалом, нет проблемы совместимости на разных платформах, нет необходимости в явной компиляции, никакого конфликта между несколькими версиями одной и той же модели и др. Дочерние скрипты могут быть запущены в потоковой или не потоковой реализации. Потоковый вариант дочерних скриптов сохраняет все преимущества техник описанных в пункте 3 раздела II.

Дополнения
Дополнения, как и встроенные скрипты, поддерживаются в V-rep через скрипты lua. Они могут быть использованы и в качестве самостоятельных функций (удобно для написания импортеров/экспортеров), или как регулярно выполняемый код (удобно в качестве облегченного тренажера настраиваемых методов).

Плагины
Плагины используются в V-REP в качестве удобного инструмента настройки симулятора. Они могут зарегистрировать пользовательские команды lua, позволяя быстрое выполнение обратного вызова функции из встроенного сценария. Плагины также могут расширить возможности конкретной имитационной модели или объекта. Часто они также реализуют конкретные импорты/экспорты, или обеспечивают интерфейс к конкретному оборудованию. Удаленный API интерфейс, а также интерфейс ROS (см. след. пункты) осуществляются через плагины.

Удаленные API клиенты
Удаленный интерфейс API в V-REP позволяет взаимодействовать с V-REP или моделированием внешнего объекта с помощью сокетов. Он состоит из дистанционного сервера API служб и удаленных API клиентов. На стороне клиента может быть встроен в компактный код (C/C++, Python, Java, Matlab & Urbi) практически на любом оборудовании, в том числе на реальных роботах, и позволяет осуществлять удаленный вызов функции, а также быструю потоковую передачу данных туда и обратно. На стороне клиента функции называются почти как обычные функции, с двумя исключениями: удаленные API функции принимают дополнительный аргумент, который является режимом работы и возврата кода ошибки. Режим работы позволяет вызывать функции блокировки (будет дожидаться ответа сервера), или не блокировки (будет читать потоковые команды из буфера, или начинать/останавливать службу потоковой передачи данных на стороне сервера). Удобство использования удаленного API, доступность на всех платформах, и его небольшие размеры, делают его интересной альтернативой ROS интерфейса.

Узлы ROS
V-REP реализует ROS узел с плагином, который позволяет ROS вызывать V-REP команды через ROS сервисы, или поток данных через ROD издателей/подписчиков. Издатели/подписчики могут быть включены через сервисный вызов, а также напрямую через встроенную в скрипт команду.

Продолжение статьи будет примерно через 2 недели, постараюсь выделить достаточно времени

Автор статьи: marc@coppeliarobotics.com
Эрик Ромер, преподаватель Государственного университета Кампинас, Бразилия
Сурья Сингх, преподаватель в университете Квинсленда, Австралия
Марк Фриз, генеральный директор Coppelia Robotics, Швейцария.
Перевод: Алеся Ханиева, роботехнопарк Навигатор кампус, г. Казань.

Автор: Alesya_Khanieva

Источник

Поделиться новостью

* - обязательные к заполнению поля