Управление глазами

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

Можно сформулировать следющие требования. 1. Отображение набора эмоциональных сотояний. Например, спокойной состояние, заинтересованность, радость, недовольство, злость/гнев, усталость. Эмоциональное сотяние задается высшим уровнем. 2. Анимации эмоций сопровождаются анимацией: малые движения зрачков, век, подмигивание (один раз) и т.п. Здесь по аналогии с движениями робота можно выделить две группы анимаций: * Длящиеся непрерывно (движения глаз, присуствующие даже в статическом состоянии, например, периодическое моргание). * Имеющие конечную длительность (анимация подмигивания). 3. Возможность задавать направление взгляда двумя способами: точка в пространстве, направление для каждого глаза (в какой СК?). 4. Плавное сопряжение эмоций. 5. Синхронное движение глаз. 6. Система отображения глаз должна работать в реаьном времени (внешний наблюдатель не должен видеть задержек и зависания) и допускать синхронизацию с движениями робота. 7. Расширяемость и замена анимаций. 8. Поддержка разных устройств отображения.

Требования 1 и 3 определяются основными функциями системы. Требование 2 имеет вспомогательное отношение к 1, оно обеспечивает правдоподобность отображаемого состояния (глаза животных и человеко довольно подвижны, даже при фокусе внимания глаза моргают, зрачок может двигаться.

Требования 4--6 обеспечивают правдоподобность анимации.

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

  1. Изображение глаз --- изображение выдаваемое на экраны.
  2. Компоненты (элементы) изображения глаз --- отдельные элементы изображения глаз, соответсвующие частям глаза реальых животных: веко, зрачок, радужка. Разные изображения могут иметь разный набор компонент.
  3. Параметризация изображения глаз, параметры изображения --- при заданном наборе компонент изображения, определяет как они будут отрисваны и превратятся в изображение. Напрмер, зрачок обладает координатами на экране и диаметром. Радужка характеризуется диметром, веко степенью закрытия и углом и т.д.
  4. Отрисовщик изображения глаз --- программный модуль, по параметризаии формирует изображение. Соответсвенно, любой отрисовщик предполагает некий фиксиррованный набор компонент изображения глаз и, возможно, связи между ними (центры радужки и зрачка совпадают и т.п.).
  5. Отрисовщик анимации глаз --- программный модуль, обеспечивающий отображение анимации глаз (подмигивание, моргание, дрожжание зрачков). Статическое сотояние тоже можно рассматривать как проостейшую анимацию.
  6. Параметры анимации --- параметры того, как отображается конкретная анимация (частота моргания и т.п.).
  7. Сопряжение анимаций/отображений глаз --- процесс переключения между отрисовщиками.

Архитектура

Архитектура подсистемы отображения глаз определяет состав модулей в ней, их функции и взаимосвязи. Эта подсистема определяет как команда с высшего уровня транслируется в изображение глаз.

Возможные архитектурные решения

В этом пункте разбираются возможные решения, их достоинства и недостатки.

Типы данных

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

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

Возможные способы взаимождействия отрисовщиков анимации и изображения

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

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

Способ представления команды отображения эмоции

Здесь предалагется выделить две состяавлющеие: 1. Быстроменяющиеся характеристики, нуждающиеся в синхронизации с движениями робота. Направление взгляда: точка в пространстве, куда направлен взгляд или направление --- два способа задния. 2. Редко меняющиеся характеристики, не требующие жесткой синхронизациию. Отображаемое эмоциональное сотояние. Такое разделение обусловлено тем, что направления зрения тесно связано с движением робота, его структура детерменирована и определяется механикой. В первую группу могут быть добавлены еще, например, положение век.

Задание эмоциального сотояния можно делать разными способами: 1. Фиксированный отрисовщик, передача параметризации: * параметризации изображения глаз, * параметры анимации.

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

  1. Переключаемые отрисовщики, передача параметризации:

    • названя отрисовщиков
    • параметризации изображения глаз,
    • параметры анимации.

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

  2. Переключаеме отрисовщики, передача текстовых идентификаторов.

    • название оторбражаемого сотояниея,
    • список дополнительных параметров (опционально).

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

Информировании высшего уровня о завершении анимации конечной длительности (например, подмигивания):

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

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

Анимация --- демонический объект

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

Синхронность движений глаз

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

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

Переключение отрисовщиков

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

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

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

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

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

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

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

Способы реализации вычислений

По отрисовщикам (анимации/изображений):

  1. Общий тракт: один отрисовщик формирует изображение двух глаз.
  2. Раздельный тракт: отдельный отрисовщик для каждого глаза.

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

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

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

По организации вычислений:

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

Потенциальные компоненты: 1. Кинематика глаз: пересчет направления взгляда в положение зрачков. 2. Отрисовщик анимации (и посдистема выбора отрисовщика). 3. Отрисощик изображения. 4. Драйвер устройства отображения глаз. Опущены средства выбора и переключения отрисовщика.

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

Поток обработки днанных:

 ----------
 | таймер | ------------------|---------------------------------------------------------------------|
 ----------                  \|/                                                                   \|/ 
                          --------------                      ---------------                    -----------
 отображаемая эмоция ---> | отрисовщик | -- параметризация--> | отрисовщик  | -- изображение --> | драйвер |
 направление взгляда ---> | анимации   |     изображения      | изображения |                    -----------
                          --------------                      ---------------
                                : (вызывает)
                          -------------
                          | кинематика|
                          |  глаз     |
                          -------------

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

Таймер обеспечивает синхронность. На уровне анимации это одновременное изменение изображений, на уроне дравера --- передача изображения устройству.

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

Взаимодействие с оборудованием --- драйвер устройства отображения глаз

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

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

Такое решение наиболее просто, обеспечивает высокую универсальность. Для его реализации почти не требуется усилий программиста.
Однако расширяемость и поддержка виртуальных устройств отображения (3D-модель головы) затруднены. Могут возникнуть сложности при управлении 
несколькими глазами из одного приложения. Все зависит от реализации конкретной библиотеки.

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

    Более гибкое, но сложное решение. Например, возможно одновременная работа нескольких устройств. Однако отдельную техническую сложность пердставяет передача изображения: вызов функции: нет отдельного процесса/нити драйвера, драйвер реализуется как сервис (плагин ROS); танспорт OROCOS или nodelets: возможно передача по ссылке, но реализация без постоянных malloc/free затруднена; * транспорт ROS: только передача по значению в стандартном (например, RGB) формате.

Предлагаемые архитектурные решения

Исходя из приведеного выше анализа предлагаются следующие решения:

  • Анимация глаз задается тектовым идентификатором (именем). Идентификатор конкретного отрисовщика и его параметры хранятся в xml файле или файлах.

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

  • Отрисовщик анимации вызывается с заданным периодом и хранит свое состояние между вызывами.

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

  • Вложенная схема: отрисовщик изображения вызывается напрямую отрисовщиком анимации. Однако это не запрещает передавать отрисовщик изображения модулю анимации при инициализации.

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

  • Возможность выделения отдельного компонента-драйвера зависит сопособа передачи изображения. Мне преставляется что оптимальным будет выделенный драйвер в виде плагина. При этом сложный драйвер можно разделить на две части: плагин и отдельный процесс отображения (напрмер, 3D-render)., соединеные, например, транспортом ROS.

Открытые вопросы

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

  • Нужен ли внешний интерфейс для независмого управления направления взглядом каждого глаза? (Усложняет интерфейс).

  • Не нужно ли вынести наружу принудительный контроль положения век или еще каких-то элементов? (Усложняет интерфейс).

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

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

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

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

  • Список отображаемых эмоций и анимаций? (Для отрисовщийка анимаций первого этапа).

  • Как QT передает изображение в framebuffer. Нужна ли отдельная нить, когда точно эта операция происходит?

Компонент eye_control

Будет перенесено на отдельную страницу.

Типы данных

Направление взгляда

Два способа:

  1. Точка в пространстве geometry_msg::Point.
  2. Направление geometry_msg::Quaternion (?).

Система координат обсуждаема. Вероятно, имеет смысл использовать СК головы, либо передавать СК в Header и использовать tf.

Общая параметризация изображения глаза

Сртруктура eyes::BaseParametrization:

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

Способ представления изображения для драйвера

В примерах QT (если мы собирается ее использовать), применяется класс QImage: Double Buffered Graphics Driver Example.

Формат данных xml для описания отображаемых эмоций и анимаций

В качестве хранения настраиваемых параметров отрисовщиков анимации предлагается использовать XML или YAML. YAML проще по структуре, чем XML и менее многословен.

Общая структура файла:

gparam1                                 % глобальный параметр, общий для всех отрисовщиков и анимаций
gparam2
module1 name="module_name"              % декларация модуля, имя и тип --- атрибуты xml, либо дочерняя запись и тег для YAML.
  |- mparam1                            % параметр отрисовщика, общий для всех дочерних анимаций
  |- mparam2
  |- animation1 name="animation_name"   % декларация анимации
  |    |- param1                        % параметр анимации
  |    \- param2
  |- animation2
  |    |- ...
  |    \- ...
module2 name="module_name"
  ...

В простейшем случае параметр --- простой тип: число, строка, целочисленный массив. Примеры: полоение, цвет, угол, время движени и т.п.

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

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

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

Альтернативные варианты:

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

Формат хранения информации о кинематики (URDF)

Математическая модель глаза --- модель pinhole камеры. Соответсвенно требуется хранить внешние и внутренние параметры камеры.

  1. Внутренние: фокусные расстояния и размеры (можно задать в URDF).
  2. Внешние: связь СК головы и СК каждого из глаз (дополнительная информация).

Компонент управления глазами (отрисовщики и кинематика)

Интерфейс

Семантика исполнения

При использовании QT возможны разные варианты организации цикла исполнения компонента (драйвер не является отдельным компонентом):

  1. Держать все в одном потоке, синхронизировать по событиям ROS (внешнему таймеру). QT вообще не занимается обработкой событий, или делает это по явному вызову.

  2. Держать все в одном потоке, синхронизировать по событиям QT (частота обноления экрана, больше событий быть не может и не должно).

  3. Делать один поток ROS и отдельно поток QT.

Модуль отображения анимации (общее описание)

Модулем отображения анимации является класс C++.

Альтернативные варианты:

  • Для каждой зарегистрированной анимации создается свой объект. Набор параметров не меняется посде его создания.
  • Каждый отрисовщик хранится как объект. При смене анимации ему передается новый набор параметров соответвующей анимации.

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

Интерфейс (вариант "каждой анимации --- свой объект", общий отрисовщик для обоих глаз)

Базовый класс интерфейса eyes::Animator.

  • void step(Point direction) --- шаг анимации по времени.
  • void draw(QImage * right, QImage * left) --- построить изображение глаз.
  • string getName() --- имя отрисовщика.
  • BaseParametrization getBaseParamerization() (protected) --- получить базовую параметризацию сотояния глаз.
  • switch(const Animator * previos) --- активация атрисовщика по сотоянию предыдущего.

  • init(<дерево параметров>, const eyes::Kinematics *) (или конструктор) --- создание объекта анимации, получает ссылку на интерфейс кинематики глаз.

    ИЛИ

    init(<дерево параметров>, const eyes::Kinematics *, const eyes::Drawer *) --- то же но с передачей внешнего отрисовщика. Совместимость интерфейсов может быть проверена dynamic_cast внутри модуля анимации. В XML структуре появляется обязательное поле с имененем отрисовщика изображения.

Семантика исполнения, инициализации, сопряжения движений

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

step() не строит изображение, а только меняет его парметризацию.

draw() исполняет функцию отрисовщика изображений глаз. Можно разбить на drawLeft и drawRight.

Модифицируемость

  • Задание параметров и анимаций через XML описание.
  • Наследование от готовых классов-отрисовщиков анимаций.
  • Написание полного нового класса анимации.

Базовый модуль анимации

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

Модифицированный модуль анимации

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