Создание программной архитектуры гетерогенной системы управления группой мобильных роботов

Размещено на http://www.allbest.ru/

Создание программной архитектуры гетерогенной системы управления группой мобильных роботов

Закиров Евгений Аликович

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

Малёв Максим Валерьевич

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

Аннотация

Данная статья описывает программную архитектуру, позволяющую значительно снизить время разработки, организовать эффективный обмен данными и управление мобильным роботом или их группой. В основе данной архитектуры лежит представление мобильного робота как композиции мехатронных устройств, связанных иерархическим графом программных взаимодействий. Для такого рода систем устоялось англоязычное название middleware. Созданная архитектура обеспечивает высокую робастность, пропускную способность и частоту передачи управляющих команд и данных. Так, при работе через WiFi в режиме точка-точка удалось обеспечить частоту передачи команд управления и сенсорных данных 450-500 Гц (wifi).

Ключевые слова: архитектура, мобильный робот, драйвер, протокол, персональное обеспечение, сенсоры, информация, сеть

Для обозначения программного обеспечения для взаимодействия прикладного программного обеспечения с сетью и обеспечивающее унификацию взаимодействия между программами в условиях неоднородности вычислительных платформ используется термин Связующее программное обеспечение (Middleware). Такого рода ПО выступает в качестве подсистемы в более крупном ПО. И, если в современных технологиях Баз Данных, Интернет и распределенных вычислений оно (связующее ПО) подробно изучается, то относительно к робототехнике, исследования не достигли должного уровня. По всей видимости это связно с тем, что до недавнего времени ПО для роботов было достаточно просто (с точки зрения программой инженерии) и не выходило за рамки простейших взаимодействий между объектами и субъектами управления. программный архитектура мобильный робот

Последние несколько лет различными коллективами осуществлялись попытки построить универсальное ПО для программирования мобильных роботов. К наиболее удачными из них можно отнести Microsoft Robotics Developer Studio (MRDS) [4], Robotics Operating System (ROS) [5]. Их предшественники, такие как Palyer Project , LAAS GenoM уже не развиваются. ROS и MRDS представляют из себя фреймворки, повторяющие функциональность операционных систем (аппаратную абстракцию, низкоуровневый контроль устройств, передачу сообщений между процессами, и управление пакетами) применительно к робототехническим задачам и основаны на архитектуре графов, где обработка данных происходит в узлах, которые могут получать и передавать сообщения между собой.

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

Эти фреймворки можно условно отнести к “большим”, т.е. включающим в себя множество компонентов для решения SLAM задач, калибровки сенсоров, обработке изображений и т.п. Однако существуют и “малые” робототехнические фреймворки, например, Concurrency and Coordination Runtime (включен в MRDS) осуществляющие лишь передачу сообщений между компонентами.

При разработке связующего ПО для построения распределенной Виртуальной лаборатории [3] были сформированы следующие требования:

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

· разграничение прав на основе иерархического представления компонентов

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

· мультиплатформенность возможность функционирования на различных платформах и ос x86\arm\windows\linux\android

· минималистичность для функционирования на устройствах android и миниатюрных одноплатных промышленных компьютерах необходимо минимизировать размер программных компонент

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

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

Минимальным объектом управления является мехатронное устройство, для которого предварительно создан интегрирующий драйвер. Интегрирующий драйвер ПО, интегрирующею мехатронное устройство в разрабатываемую информационную систему и обеспечивающее вышеперечисленные функции.

Драйвер обеспечивает:

Схему именования и идентификации, т.е. способ получения доступа к устройству по его имени. При этом именем может является IP адрес и порт, произвольный текст, например “двигатель” или целый путь в иерархии, например “Университет->лаборатория1 ->Двигатели->3->ток”.

Передачу и получение команд. В разработанной архитектуре используется система обмена сообщениями ZeroMQ [1], благодаря чему и удается мультиплатформенность, ведь данная библиотека реализована для множества языков программирования и архитектур процессоров, что позволяет организовать обмен данными в гетерогенной среде.

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

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

· каждая команда или данные сенсоры снабжаются меткой времени, при прохождении каждого драйвера, это позволяет точно синхронизировать работу и учесть временные задержки, а так же разность во времени между несколькими лабораториями

· каждый драйвер имеет собственную Службу Имён, хранящую информацию о соседних (с точки зрения сетевой топологии) драйверах. Данная служба периодически сканирует локальную сеть и ищет аналогичные службы. Найдя же обменивается с нею всей доступной информацией алгоритмом, близким к распределенным хеш-таблицам Distributed Hash Table (DHT) . Благодаря этому появляется качество децентрализованности.

Наиболее значимыми отличиями от существующих систем являются:

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

· децентрализованность и автоконфигурирование - граф взаимодействий автоматически восстанавливается после нарушений связей даже в случае незначительного изменения топологии сети

· Система разграничения доступа (основана на LDAP), позволяющая управлять правами доступа группы пользователей.

Дальнейшие исследования:

Интересным представляется повысить надежность системы за счет использования алгоритма Хиндли-Милнера (Hindley-Milner) для вывода и контроля типов, т.к. на данный момент для взаимодействия используется нетипизированный JSON, и каждый компонент системы разбирает его самостоятельно, ориентируясь на умолчания.

Другим направлением является добавление поддержки Тьюринг-полных протоколов [2], однако это связано с разом затруднений, связанных с необходимостью привязки к конкретному языку программирования.

Список литературы

1. http://zeromq.org/

2. Кирсанов К. Б. " Разработка и отладка измерительной информации и систем управления для мобильных роботов с помощью динамического языка Python." 2009.

3. Андреев В. П., Кирсанов К. Б., Плетенёв П. Ф., Подураев Ю. В., Пряничников В.Е., Пруцев Е. А. ^"Виртуальная пространственно-распределенная научно-образовательная лаборатории для дистанционного управления мехатронных устройств через Интернет". 2014.

4. http://www.microsoft.com/robotics/.

5. http://www.ros.org/.

Размещено на Allbest.ru