Высокоуровневая интерфейс системы управления

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

Терминология

Поведение --- некий заданный образ взаимодействия робота с внешней средой. Например, слежение за объектом, приветствие встретившихся людей и т.п.)

Действие --- конкретная задача по взаимодействию с внешней средой (выполнение заданного движения, исполнение приветствия). Является частным случаем поведения.

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

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

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

Высокооуровнеые поведеня (действия) --- допускают компактное текстовое описание. В отличие от низкоуровневых удобны для задания и восприятия человеком.

Состояние --- множество устойчивых значений параметров объекта. Состояния как правильно длительны. Примеры: робот опрокинулся, робот идет, вижу лицо и т.п.

Событие --- некоторое явление, имеющее место в конкретной точке пространства-времени. Событие не имеет длительности. Примеры: смена состояния, появление в кадре лица и т.п.

Требования

  1. Основная функция СвитиБота --- имитация общения с людьми. Это предполагает, что ИИ должен решать следующие задачи:

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

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

  3. Система должна иметь возможность прерывать текущее поведение и переключаться на другое.

  4. Наличие реактивного уровня (в терминах 3-х уровневой модели), который позволяет замыкать потоки данных от датчиков к низкоуровневым компонентам системы управления, минуя высокий уровень. В этом случае информацию передается непосредственно от датчиков к задатчику. Такая схема должна снизить задержки при выполнении слежения за объектами до требований РВ, сократить время реакции на опасные события.

  5. Спецтребование: совместимость с текущей реализаций поведений посредством FlexBe.

Тезисы

  1. Исходя из области применения, наиболее логичным выглядит использование в качестве ядра ИИ чат-бота, программы имитирующей поведение собеседника. Для распознования речи возможно использование облачных сервисов (Google, Yandex), для синтеза программы типа festival (уже имее интеграцию с ROS).

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

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

    Соответвенно, модель робота и окружающего пространства (см. [Юревич. Основы робототехники]) представляется в виде набора состояний. Некоторые состония могут снабжаться низкоуровневой информацией для использования нижним уровнем системы управления (например, положение объекта в пространстве).

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

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

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

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

  5. Разложение сложного поведения на низкоуровневые может быть разным по сложности описания:

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

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

  9. В текущий момент в качестве основы высшего уровня управления рассматриваются:

    • FlexBE --- обеспечивает представление поведений в виде гибридных конечных автоматов. Автоматы способны получать параметры параметров и проверять внешние события. Имеет удобный интерфейс для управления оператором. Основной элемент --- flexbe-состояние (flexbe state), отвечающее состоянию конечного автомата. Оно представляет собой модуль, написанный на python, выполняющие отдельные callback функции при активации (on_enter), периодически в активном сотоянии (execute) и при деактивации (on_exit). Сотояние может иметь параметры, при способно получать аргументы от предыдущего сотония. Из сотояний строятся конечные автоматы --- flexbe-поведения (flexbe behavior)

    • Чат-бот. Вход чат-бота --- текст и метки состояний робота и внешней среды. Выход --- текст, метки поведений и действий. Трансляция показаний сенсорный системы во входные метки и преобразование выходных меток в действия будет выполнятся отдельными модулями.

Концерт высшего уровня системы управления

Предполагается трехуровневая система управления: 1. Низкий уровень. Задатчики движений OROCOS и компоненты ROS исполнительной подсистемы обеспечивают набор элементарных поведений. Функцию выбора конкретного набора активных компонент и организацию потоков данных между ними исполняют flexbe-состояние. Таким образом представляются сложные (высокоуровневые или низкоуровнеыве) поведения, являющиеся копозицией элементарных. 2. Средний уровень. FlexBe-поведения используются для описания высокоуровневых поведений, представимых как гибридный конечный автомат. Простейший автомат может включать только одно flexbe-состояние. 3. Высокий уровень. Подсистема принятия решения (чат-бот) отвечает за выбор активного высокоуровнего поведения.

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

Использование FlexBe

Роль реализации сложных действий возлагается на flexbe-состояния (тривиальное разложение действия) и flexbe-поведения (представление действия в виде конечного автомата из нескольких состояний). В первом случае используется python, а во втором --- графический редактор FlexBe.

Гибридным автоматам FlexBe присущи некоторые недостатки: - неудобство задания сложных параметров, громозкость описания сложного действия, как совокупности элементарных действия средствами FlexBe, - сложности реализации параллельных процессов и асинхронной реакции на события (например, команда "стой" для прекращения текущего действия), - плохая масштабируемость в смысле организации альтернативных цепочек действий (выбор одного действия из 10 в FlexBe выглядит очень громозко),

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

Для обеспечения "бесшовных" сопряжений движений целесообразно не прерывать исполнение задатчиков при получении команды о прекращении текущего поведения. В случае, если такое поведение нежелательно, то можно реализовать on_stop хуки со отвевающих состояний, либо выработать индивидуальную схему деактивации поведение (посылка сообщения, переключение на деактивиркющее поведение). Задача установить правильную конфигурацию задатчиков возлагается на активируемое flexbe-поведение. Так, если для выполнения движения требуется принять некоторую начальную позу, то вначале должен присутствовать обращение к поведению, которое приводит робота в это состояние.

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

Унификация интерфейсов задатчиков

Для эффективного использования задатчиков из flexbe-состояния предлагается:

  • Обеспечить четкое разделение между типами задатчиков.

    1. Задатчики дискретного позиционного упраления решают задачи перевода робота в заданную позу за конечное время, используют интерфейс actionlib. Пример: MoveToJointState.
    2. Задатчики непрерывного упраления решают задачи слежение, используют интерфейс операций и подписку на топики. Пример: FollowJointState.
    3. Задатчики программного упраления решают задачи исполнения записанных траекторий, используют интерфейс actionlib. Пример: AnimationJointTrajectory.

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

    1. Поддержка на уровне задатчика нескольких действий actionlib. Решение плохо, т.к. требует на уровне задатчика частично реализовывать функции арбитра. Также интерфейс actionlib с несколькими задачами достаточно сложен.
    2. Загружено несколько однотипных задатчиков, высший уровень выбирает нужный. В таком случае на высший уровень накладывается функция мониторинга задатчиков, выбора подходящего, что излишне усложняет его. Как наиболее простой вариант можно выделить отдельный задатчик на несколько групп ресурсов, которые могут использоваться независимо. Тогда необходимости мониторинга можно избежать.
    3. Промежуточный прокси-компонент, пересылающий сообщение инициирующее новое действие на свободный из нескольких загруженных задатчиков. Этот вариант решения требует дальнейшего исследования. Рекомендуется решение 3 или 2 (с выделенными задачками под группы ресурсов). Последний вариант наиболее прост в реализации, предлагается использовать его до появления серьезных проблем.

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

Супервизор для поведение FlexBe и интеграция с чатботом

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

Активация поведения происходит через API behavior_onboard. Для активации поведения достаточно знать его имя (идентификатор). Этот интерфейс также позволяет передавать поведения параметры, прерывать исполнение поведения.

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

Способ представления информации в виде текста может отличаться: - Набор логических утверждений. ("свити_опрокинулась", "вижу_человека", "громкий_звук"). При необходимости утверждения снабжаются метаинформацией (например, положение человека). - Педикаты. ("вижу(A) & человек(A)"). Существенно более сложное представление, позволяет работать с несколькими объектами. Объекты также снабжаются метаинформацией. Вероятно, разумно выработать некое промежуточное представление в зависимости от типа метаинформации и возможных действий объекта. Например: "свити_опрокинулась() & свити_ждет_помощи() & вижу_объект(мяч) & вижу_человек(mutronics)"

Обработка объектов. Желательно, чтобы чатбот мог отслеживать объекты, в том смысле, что реакций на "вижу(мяч) & вижу(человек)" может быть либо "следить(мяч)", либо "следить(человек)". С "человек" и "мяч" связаны конкретные координаты, и действие слежение может быть реализовано только, если ему переданы эти координаты.

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

Хранение описаний поведений

Поведения задаются как состояния и поведения FlexBe, поэтому хранятся в виде кода на языке python.

Как альтернативное решение для простейших поведений, являющихся совокупностью нескольких элементарных, можно использовать xml-описание, как у эмоций глаз. Так, например, некоторая анимация есть совокупность ряда команд позиционирования (уши, хвост), записанных траекторий (голова, ноги), текстовых команд (эмоции глаз, речь). Здесь сложность представляет неспособность ROS сериализовывать сообщения в человекочитаемой форме. Для реального исполнения такого поведения потребуется состояние FlexBe.

Список элементарных действий

Большинство элементарных поведений исполняются непосредственно задатчиками движений.

  1. Все сочленения (включая фиктивные) и любые их комбинации:
    • Поместить в заданную позу в угловой СК (без учета самопересечение и позной устойчивости): MoveJointState (не реализован).
    • Следить за позой в угловой СК (без учета самопересечение и позной устойчивости): FollowJointState
    • Повторить записанное движение: AnimationJointTrajectory
  2. Голова
    • Повернуться на заданный объект/в заданном направлении: flexbe state+MoveJointState или MoveHeadDirection (не реализовано).
    • Слежение за объектом/направлением: flexbe state+FollowJointState или FollowHeadDirection (не реализовано).
    • Позиционировать рот/нос в заданную точку.
    • Слежение за заданной точкой положения нос/рта.
  3. Глаза
    • Смотреть на заданный объект/в заданном направлении.
    • Слежение за объектом/направлением.
    • Переключение эмоционального состояния, проигрывание анимаций.
  4. Одна нога
    • Поместить копыто в заданную позу: AnimationJointTrajectory+move_group
    • Слежение за заданной позой.
    • Силовое взаимодействие с объектом? (Надавить на заданную точку).
  5. Платформа, ноги и голова
    • Поменять положение платформы при сохранении положения опорных ног.
    • Переместить платформу в заданную точку (ходьба).
    • Двигаться в заданной скоростью (ходьба, рысь).
    • Принять известную позу (стоит, сидит и т.п.)
  6. Зрение
    • Детектирование лиц и их координат.
    • Детектирование объектов/AprilTags.
  7. Человекомашинный интерфейс
    • Получать координаты манипулятора Hydra и состояние его кнопок.
    • Получать координаты от LipMotion, классификация жестов.
  8. Речь
    • Распознавать человеческую речь, формировать сообщения с фразами.
    • Синтезировать речь.
    • Проигрывать предварительно записанные звуки.