Вы находитесь на странице: 1из 8

(СЛАЙД1) Среда интеграции мобильной и автономной робототехники

(СЛАЙД2) MARIE - новый инструмент проектирования для мобильных


и автономных роботов, предназначенный для облегчения интеграции
множества разнородных программных элементов. Это гибкий
инструмент, основанный на распределенной модели, что позволяет
реализовать приложение с использованием одной машины или
различных сетевых машин, архитектур и платформ.
Интегра́ция — процесс объединения частей в целое.
(СЛАЙД3) Инициатива МАРИ основана на следующих основных
требованиях:
Повторно использовать программные средства, API, промежуточные
программные средства и структуры, часто используемые в робототехнике
(Player, CARMEN, SportsFlow и т.д.)
Внедрение метода быстрого создания прототипов для создания полной
системы
Разрешить распределенные вычисления на гетерогенных платформах
Разрешить одновременное использование различных
коммуникационных протоколов, механизмов и стандартов
Ускорение пользовательских разработок с четко определенными
слоями, интерфейсами, фреймворками и плагинами
Поддержка нескольких наборов концепций и абстракций
(СЛАЙД4) Мотивации
Область робототехники развивается быстро: разнообразие доступных
технологий и программных решений, разработанных в различных
исследовательских центрах по всему миру, фактически увеличивает
сложность интеграции. Все эти исследователи и разработчики, которые
работали над разработкой новых решений, видят повторное использование их
работы другими трудными или невозможными. Слишком часто такой отказ
или небрежность в использовании доступных компонентов обусловлены
сложностью интеграции различных несовместимых программных продуктов,
поскольку они предназначены для различных платформ, различных
операционных систем или протоколов и соглашений о связи.
- > Быстрое и упрощенное повторное использование гетероклитных
компонентов, разработанных другими, имеет важное значение для эволюции
этой области исследований.
(СЛАЙД5) Воздействия
Влияние такого инструмента на повторное использование
многочисленных существующих и будущих технологических и программных
решений имеет очень важное значение:
Позволить исследователям и разработчикам сконцентрироваться на
конкретном аспекте, где они имеют значительный вклад, чтобы принести.
Такой инструмент позволил бы избежать их усилий по воспроизведению и
адаптации модулей или приложений, уже разработанных другими и не
совместимых или непосредственно используемых.
Выполнение конфигураций, в которых определенные компоненты
никогда не соединялись вместе для одного и того же приложения реального
времени. Эта возможность потенциально открывает новые возможности для
исследований и разработок, которые до сих пор не изучены.
Развивать на более высоком уровне абстракцию, например архитектуру
принятия решений. Инструмент позволяет действовать на этом уровне, потому
что в нем изложена низкоуровневая реализация робототехнической системы.
(СЛАЙД6) Требования к проектированию
Архитектура программного обеспечения MARE основана на трех
вариантах проектирования, которые должны соответствовать основным
требованиям.
(СЛАЙД7) Подход к посредничеству по компонентам
Это способ использовать разнообразие коммуникационных протоколов
и механизмов, извлечь пользу из их сильных сторон и максимально
использовать их, а также преодолеть отсутствие стандартов в
роботизированных программных системах.
Для реализации распределенных приложений, использующих
гетерогенные компоненты, MARE адаптировала шаблон разработки
медиатора (Gamma, E. et al. 1994) для создания уровня совместимости
посредника (MIL - Mediator Interoperability Layer). Модель разработки
медиатора в первую очередь создает централизованный блок управления (под
названием Mediator), взаимодействующий с каждым коллегой (называемым
компонентами) независимо, и координирует глобальное взаимодействие
между коллегами для реализации желаемой системы.

В МАРИ MIL действует так же, как медиатор исходного шаблона, но


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

Кроме того, это способствует свободной связи между компонентами


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

За счет использования подхода к виртуальному пространству


конструкция MIL снижает потенциальную сложность управления большим
количеством централизованных компонентов, как это наблюдается при
исходной схеме. Это объясняется главным образом ограниченной
централизацией коммуникационных протоколов и механизмов, а также
децентрализованностью большинства функций.
(СЛАЙД8)
Многоуровневая архитектура
Поддержка нескольких наборов концепций и абстракций может
быть достигнута различными способами. Для этого в MARE
используется многоуровневая архитектура программного обеспечения,
определяющая различные уровни абстракции в глобальной структуре
промежуточного программного обеспечения. Три уровня абстракции
используются для сокращения объема знаний, опыта и времени,
необходимого для использования всей системы. Именно разработчик
должен выбрать наиболее подходящий слой для добавления элементов
в систему:

Core Layer состоит из инструментов для связи, обработки данных,


распределения вычислений и низкоуровневых функций операционной
системы (например, памяти, потоков и процессов, управления
вводом/выводом).
Component Layer определяет и реализует полезные структуры для
добавления компонентов и поддержки концепций, специфичных для
домена.
Application Layer содержит полезные инструменты для создания
интегрированных приложений и управления ими с использованием
доступных компонентов, а также для создания робототехнических
систем.
(СЛАЙД9) Абстракция коммуникационного протокола
Функциональные возможности компонентов часто могут
использоваться без каких-либо проблем с протоколами связи, поскольку они
обычно предназначены для применения операций и алгоритмов к данным,
независимо от того, как данные принимаются или принимаются. В идеале этот
выбор должен быть сделан как можно позже, в зависимости от того, какие
компоненты должны быть соединены друг с другом (например, на этапе
интеграции или даже во время выполнения). Поэтому для протоколов связи и
межсоединений компонентов предусмотрена структура абстракции связи,
называемая Port.
(СЛАЙД10)
Платформа разработки приложений MARE
Разработка приложений робототехники с помощью технологии МАРИ
основана на программных блоках многоразового использования, называемых
компонентами, которые реализуют функциональные возможности путем
инкапсуляции существующих приложений, сред программирования или
выделенных алгоритмов. Компоненты сконфигурированы и соединены друг с
другом для реализации требуемой системы с использованием программных
приложений и инструментов, доступных через MARE.
(СЛАЙД11) В MIL используются четыре типа компонентов: адаптер
приложений (AA), адаптер коммуникаций (CA), диспетчер приложений (AM)
и диспетчер коммуникаций (CM). Роль AA заключается в взаимодействии
приложений с MIL и обеспечении их взаимодействия друг с другом. CA
являются компонентами логического канала связи, которые обеспечивают
связь между другими компонентами, адаптируя несовместимые механизмы
связи и протоколы, или реализуя традиционные функции связи
маршрутизации. Например, CA может связать AA, предоставляющий данные
с фиксированной скоростью, с AA, требующим этого асинхронно. AM и CM -
это компоненты системного уровня, которые создают экземпляры и
управляют компонентами локально или между распределенными узлами
обработки. Они могут, например, перезапустить компонент, который
некоторое время не отвечает, или могут перемещать компоненты с одного узла
обработки на другой, чтобы избежать перегрузки ЦП. Соединения с
использованием абстракции связи портов показаны на рис. 1 с малой красной
рамкой в компонентах.
(СЛАЙД12) На рис. 1 в примере показано, как программные
приложения могут быть интегрированы и соединены между собой в MIL.
Приложение A представляет собой интегрированное приложение,
непосредственно связанное с реализацией его AA (например, библиотека или
приложение с открытым исходным кодом). Когда приложение интегрировано
с использованием AA, оно может использовать протоколы связи MIL для
обмена данными с любыми другими компонентами, как это имеет место при
предоставлении данных прикладному адаптеру 2 и прикладному адаптеру 3.
Приложение B взаимодействует с другими приложениями двумя различными
способами. Для передачи данных на адаптер приложения 2 первый должен
иметь адаптер приложения 1. Которые преобразуют их в конкретный
коммуникационный протокол, не поддерживаемый MIL, чтобы сделать их
доступными для приложения B. Второй протокол используется для передачи
данных обратно на адаптер приложения 3, Использование протокола связи,
поддерживаемого MIL, позволяющего осуществлять прямое взаимодействие с
любыми компонентами. Однако приложение B и адаптер 3 приложения не
используют совместимые механизмы связи или протоколы, что требует от ЦС
их сопряжения. Адаптер 3 приложений реализует функции непосредственно в
MIL, инкапсулируя их в "автономный" AA (например, графический
пользовательский интерфейс, реализованный непосредственно в AA).
Приложение C уже может взаимодействовать с приложением B. Поэтому
никакого взаимодействия через MIL не требуется.
(СЛАЙД13) Спартак (Михо и др. 2005) - социально интерактивный
мобильный робот, предназначенный для работы в реальных жизненных
условиях. Робот должен быть способен к автономной навигации и
локализации, извлекать визуальную информацию из мира (такую как чтение
сообщений, слежение за людьми), локализовать, отслеживать и отдельные
источники звука для усиления распознавания речи и диалогового
взаимодействия, предоставлять графическую информацию через интерфейс
сенсорного экрана и планировать задачи (Beaudry et al. 2005) для
удовлетворения временных ограничений. Интеграция процессов принятия
решений для реализации такого сценария осуществляется с использованием
вычислительной архитектуры, называемой мотивированной поведенческой
архитектурой (MBA) (Michaud et al. 2005). MARIE используется для
программной реализации процессов принятия решений "Спартака".
Реализация Sparts требует 45 компонентов (~ 50 000 строк кода), состоящих из
26 AA, 17 CA и двух внешних приложений. Процессор распространяется через
три встроенных компьютера (Pentium M 1,6 ГГц) и один внешний ноутбук
(Pentium M 2,0 ГГц).
(СЛАЙД14)
Частичная реализация процессов принятия решений Спартака
проиллюстрирована на рис. 2. Она включает в себя зондирование и действие в
моделировании и реальных настройках робота, локализацию, планирование
путей, локализацию источника звука, отслеживание и разделение,
распознавание и генерацию речи, а также часть вычислительной архитектуры,
отвечающей за возможности навигации и взаимодействия робота. В реальной
установке робота LightingAA объединяет данные одометрии колес и
гироскопические (через GyroAA, сопряженные с гироскопом, установленным
на Спартак) данные и толкает результат с фиксированной частотой (10 Гц) к
его взаимосвязанной составляющей. Лазерные данные собираются с помощью
Интерфейса AA библиотеки Player, специализированной для абстракции
датчиков и исполнительных механизмов (Vohan et al. 2003), поддерживающий
лазерный дальномер SICK LMS200, установленный на Спартаке. АА
перемещает данные с фиксированной частотой (10 Гц) к подключенным
компонентам. В установке моделирования данные одометрии и лазера
одновременно собираются с помощью Программы AA, генерируемой с
помощью тренажеров Stage (2D) или Gazebo (3D) (Vahan et al. 2003).

Пояснения к картиночке
AA используются для сопряжения различных программных
приложений, необходимых для принятия решений роботом. Почтовые ящики,
разделители, SharedMap и коммутаторы - это четыре типа используемых ЦС.
Почтовый ящик служит буфером данных между асинхронными
компонентами. Разветвитель пересылает входящие данные на несколько
выходов. SharedMap - это структура данных "push-in/push-out key-value",
используемая для хранения системных состояний, доступ к которым могут
получить многие компоненты. Коммутатор отправляет только один из своих
входов на выходной порт.
(СЛАЙД15)
Несмотря на то, что МАРИ использовалась в небольших реализациях,
"Спартак" представлял собой свою первую реальную задачу интеграции и
продолжает работу. В этом разделе представлены предварительные
результаты и замечания относительно требований к программному
обеспечению и архитектуре проектирования MARIE, основанные на нашей
работе над Sparts. МАРИ кодируется в C (~ 10 000 строк кода) и использует
библиотеку ACE (Adaptive Communication Environment) для транспортного
уровня (TCP/IP, Shared Memory и т. д.) и низкоуровневые функции
операционной системы (потоки и процессы, доступ к памяти, таймеры,
совместимость операционных систем, поддержка в реальном времени и т. д.)
(Шмидт, округ Колумбия, 1994). Несмотря на то, что ACE удовлетворял
требованиям к внедрению Spacet, MARE не полагается на эту специфическую
библиотеку транспортного уровня.
Девять существующих специализированных приложений/библиотек
были интегрированы вместе для создания полной системы:
Player/Stage/Gazebo, Pmap, CARMEN, Flowdesigner/FlowerFlow, SOUND,
Nuance, Festival, DECIBEL, QT3 и OpenCV. Каждое из этих приложений
требует разных стратегий интеграции.