Arsenii Iarmolinskii

Рассуждения на тему архитектур систем управления роботами

Введение

Создание робота можно разделить на несколько важных компонентов. Как правило выделяют три из них:

• конструкция,
• электроника,
• программное обеспечение.

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

Что такое архитектура системы управления роботом?

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

Архитектура СУ роботов отличается от других архитектур программного обеспечения особыми потребностями роботизированных систем.

Требования к роботам

Каковы особые требования к роботизированным системам?

Роботизированные системы работают в сложных динамичных средах реального времени. Эти системы должны:

• управлять различными датчиками и исполнительными механизмами в режиме реального времени,
• делать это в условиях значительной неопределенности и шума, отслеживая неожиданные ситуации и реагируя на них,
• и делать все это одновременно и асинхронно.

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

Иерархическая архитектура

Разработка архитектуры и программирования роботов началась в конце 1960-х годов с создания робота Shakey в Стэнфордском университете.

На рисунке: робот Shakey. У Shakey была камера, дальномер и датчики ударов, и он был подключен к компьютерам DEC PDP-1O и PDP-I5 по радио- и видеосвязи.

Архитектура Shakey была разделена на три функциональных элемента: Sense, Plan и Act.

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

Этот подход получил название парадигмы “sense-plan-act” (SPA).

Рисунок: Парадигма “sense-plan-act” (SPA).

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

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

В этих ранних системах основное внимание уделялось созданию подробной модели мира, а затем тщательному планированию дальнейших шагов.

Проблема заключалась в том, что, пока робот создавал свою модель и размышлял о том, что делать дальше, мир, скорее всего, менялся.

Таким образом, эти роботы демонстрировали странное поведение: они смотрели (собирали данные, часто в виде одного или нескольких снимков с камеры), обрабатывали и планировали, а затем (часто после значительной задержки) приступали к действию на пару шагов, прежде чем начать цикл сначала (look and lurch behaviour).

Проблемы с архитектурой SPA

1. В реальном мире создание плана занимает продолжительное время в течение которого робот заблокирован и не реагирует на возможные изменения мира.
2. Исполнение плана без датчиков обратной связи может быть опасно для успешности выполнения задания или для самого робота.

Может быть так, что система SPA разработает план, но прежде чем этот план может быть выполнен в полном объеме, он становится недействительным из-за изменений в реальном мире.

Реактивная архитектура

В 1986 году Родни А. Брукс опубликовал статью, в которой описывался тип реактивной архитектуры, называемый архитектурой подчинения (subsumption architecture).

Реализация

Архитектура подсистемы построена на основе уровней взаимодействующих конечных автоматов, каждый из которых напрямую соединяет датчики с исполнительными механизмами.

Эти конечные автоматы назывались поведения (behaviors) (что привело к тому, что некоторые назвали архитектуру subsumption - behavior-based или поведенческой робототехникой).

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

Архитектура подчинения на время стала доминирующим подходом в архитектурах реактивных роботов.

Рисунок: Архитектура подчинения

Архитектура подчинения (Brooks, 1986) характеризовалась:

1. отсутствие представления о внешнем мире,
2. the analysis of the architecture on a task rather than a functional basis, (?)
3. подчинение низкоуровневых поведений поведениями более высокого уровня,
4. плотная связь между датчиками и исполнительными механизмами.

Пример

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

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

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

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

Сравнение архитектуры подчинения и SPA

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

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

Проблемы с реактивным (поведенческим) подходом

Однако роботы, основанные на поведении, вскоре достигли предела своих возможностей.

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

Гибридная архитектура

По сути, роботам требовались возможности ранних архитектур строить долгосрочные планы, также как и реактивное поведение behaviour-based систем. Осознание этого привело к разработке многоуровневых архитектур управления роботами.

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

Наиболее популярным вариантом этих гибридных архитектур являются трехуровневые архитектуры:

1. Контроллер или Реактивный уровень
2. Секвенсор или Исполнительный уровень
3. Планировщик или Совещательный уровень

Контроллер (реактивный уровень)

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

Цикл принятия решения часто составляет порядка миллисекунд.

С точки зрения разработки программного обеспечения контроллер представлял бы собой набор драйверов с базовыми реакциями, в то время как с биологической точки зрения контроллер - это набор нервных связей с мышцами и другими органами.

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

Секвенсор (исполнительный уровень)

Уровень секвенсора (он же исполнительный) находится между уровнем контроллера низкого уровня и уровнем планировщика более высокого уровня.

Он принимает директивы от уровня планировщика и упорядочивает их для реактивного уровня.

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

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

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

Планировщик (совещательный уровень)

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

Планировщик генерирует глобальные решения для сложных задач.

Цикл принятия решений в нем часто составляет несколько минут.

Для принятия решений планировщик использует модели.

Эти модели обычно используют информацию о состоянии, собранную на исполнительном уровне.

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

Рисунок: Временная шкала архитектур управления роботами.

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

• ЧУТЬЕ: Робот должен уметь распознавать важные моменты в окружающей среде, такие как наличие препятствий или навигационных средств.
• ПЛАНИРУЙТЕ: Робот должен получить полученные данные и выяснить, как правильно на них реагировать, основываясь на уже существующей стратегии.
• ДЕЙСТВИЕ: Наконец, робот должен действительно действовать, чтобы выполнить действия, предусмотренные планом.

Пример с кодом

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

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

На основании этой информации составляется план движения, который впоследствии приводится в исполнение.

void loop()
{
    ////// SENSE //////

    // Чтение сигнала с датчика расстояния
    float dist_forw = LIDAR.read();

    // Построение математической модели окружения
    bool is_free = dist_forw  > 20;


    ////// PLAN //////

    // Построение плана действий на основании математической модели
    if(is_free)
    {
        // Если впереди свободно - едем вперед
        m_left = 100;
        m_right = 100;
    }
    else
    {
        // Если впереди препятствие - отворачиваем
        m_left = -100;
        m_right = 100;
    }


    ////// ACT //////

    // Исполнение плана
    motors.run(m_left, m_right);
    delay(500);
}

Заключение

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

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

Источники

1. Kelleher, “Robot Control Architectures”. https://pdfs.semanticscholar.org/a621/723d1f3d27539c0e9094fcfa8d1e9bbda7b2.pdf