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

1

Планирование задач для автономного сервисного


робота
Томас Келлер, Патрик Эйрих и Бернхард Небель
Фрайбургский университет
Институт меховой информации
Жорж-Колер-Алли 52
79111 Фрайбург
{tkeller, eyerich, nebel} @informatik.uni-freiburg.de
Аннотация. В проекте DESIRE разработан автономный робот,
способный выполнять служебные задачи в типичной кухонной среде.
Общая система состоит из свободно связанных подкомпонентов,
обеспечивающих определенные функциональные особенности, такие как
манипулирование объектами или распознавание и взаимодействие с
человеком. Для объединения всех этих субкомпонентов в монолитную система,
была внедрена высокопроизводительная система планирования. В этой статье мы
представляем базовую архитектуру этой системы и некоторые
усовершенствованные расширения, необходимые для решения различных
проблем, возникающих в динамичных и неопределенных средах, подобных
тем, с которыми обычно сталкивается настоящий сервисный робот.

1 Введение

Общей целью проекта DESIRE [1] была разработка автономного


робота, способного выполнять задачи по обслуживанию на кухне. С самого
начала проекта вместо того, чтобы сосредоточиться на выполнении заранее
определенных сценариев, было решено сохранить систему максимально
неограниченной, чтобы добиться максимальной гибкости. Это привело к
системной архитектуре, состоящей из нескольких свободно связанных
подсистем, которые способны выполнять основные задачи, такие как
манипулирование объектами, автономное вождение в динамической среде
или распознавание и взаимодействие с человеком. С нашей точки зрения,
самым важным следствием этого решения стала необходимость в
независимой от домена системе планирования, которая способна эффективно,
но стабильно объединять любое количество этих подсистем.
Интеграция такого планировщика задач в систему повышает
интеллектуальность и гибкости робота, изменяя способ управления
роботом, от заранее определенных последовательностей подробных
пользовательских инструкций к более сложному целевому подходу.
Больше не требуется предоставлять роботу полностью проработанное
описание его задачи (например, "Идите к большому столу, затем возьмите
тарелку, затем вернитесь и дайте мне тарелку!") достаточно дать ему
какую-нибудь императивную команду (например, "Дайте мне тарелку!") и
оставить это роботу, чтобы он мог найти подходящий план для
достижения соответствующих целей самостоятельно, комбинируя
особенности различных компонентов значимым образом.
Планирование задач само по себе является тщательно исследованным
подразделом в искусственном интеллекте [2]. Однако в контексте
робототехники ИИ должен иметь дело с определенными аспектами,
усложняющими его применение, включая несовершенную информацию об
окружающей среде, недетерминированные изменения или взаимодействие с
пользователем. Основной вклад этой статьи состоит в том, чтобы показать,
как преодолеть эти проблемы и сделать планирование задач подходящим
для повседневного использования в робототехнике.
Остальная часть документа структурирована следующим образом: в
следующем разделе мы представим основы используемой системы
планирования, опишем, как текущая состояние робота и его окружения
может быть описаны на языке определения области планирования (PDDL)
и покажем, как его можно адаптировать к динамически изменяющейся и
частично неизвестной среде посредством непрерывного планирования. В
разделе 3 описывается, как преодолеть разрыв между несколькими
независимыми эпизодами планирования, в то время как в следующем
разделе показано, как можно эффективно решить проблемы, содержащие
подпроблемы различной степени детализации. Перед завершением мы
представляем всю системную архитектуру компонента планирования в
разделе 5.

2 Планирование в среде реального мира.

Учитывая начальное состояние, набор действий и формулу цели,


классическое планирование заключается в поиске последовательностей
действий, превращающих исходное состояние в состояние, удовлетворя-
ющее формуле цели. Структура планирования, которую мы используем в
данном документе, PDDL2.1 Уровень 3 [11] расширена объектными
флюентами, как предложил Геффнер [10]. Далее мы будем использовать
термин переменная состояния для ссылки на предикаты, числовые
флюенты и флюенты объектов.
Классический подход к планированию в значительной степени
опирается на полное и определенное описание ситуации, с которой
сталкивается агент. Кроме того, действия должны быть полностью
детерминированными, и единственные изменения, допускаемые в среде,
обусловлены действиями, которые решает выполнить агент. Очевидно, что
эти ограничения слишком сильны, когда речь идет о моделировании
3

области, изображающей реальный мир: могут быть другие агенты,


изменяющие состояние мира (включая природу), действия могут иметь
стохастические или вероятностные эффекты и текущее состояние мира
может быть не до конца известно.
Typical approaches dealing with such domains are contingent and
probabilistic planning. These approaches try to generate conditional plans and
policies (mappings from states to actions), respectively. Unfortunately, both
approaches are of much higher complexity [7, 8] than classical planning and
usually fail to scale in even moderately complex scenarios. Furthermore, it might
be impossible to model all potential outcomes of actions in dynamic
environments, or concrete probabilities of outcomes are unknown.
Недавно мы предложили альтернативный метод работы с реальными
средами: непрерывное планирование (Continual Planning, CP) [6], в котором
выполняется непрерывный цикл между планированием, выполнением плана
и контролем выполнения. На фазе планирования агенту разрешается
отложить решение о том, как выполнять подцели, на более поздний
момент времени, когда имеется больше информации, используя
утверждения как часть плана. Затем выполняется первое действие плана.
На третьей фазе процедура контроля проверяет, является ли остальная
часть плана по-прежнему выполнимой и по-прежнему ли она
соответствует поставленной цели. Если это не так или если план должен
быть уточнен, поскольку следующее исполняемое действие является
утверждением, агент переключается на фазу планирования. В противном
случае запускается выполнение следующего действия, и система
продолжает ее мониторинг.
Для DESIRE мы интегрировали подход CP в нашу систему временного
планирования, которая кратко представлена в следующем разделе. Поскольку
временное планирование допускает параллельные действия переменной
длительности, может быть более одного действия для начала фазы
выполнения, и эти действия могут иметь разную длительность. Кроме
того, могут возникнуть ситуации, когда действие уже завершено, в то
время как другие все еще выполняются. Поэтому мы расширили
компонент мониторинга, чтобы рассмотреть такие действия с их
оставшейся продолжительностью.

2.1 Базовая система планирования: TFD


В качестве базовой системы планирования используется функция
Temporal Fast Downward (TFD) [4]. TFD является независимым от домена
планировщиком поиска хода выполнения, построенным поверх
классической системы планирования Fast Downdown [3]. Он расширяет
исходную систему для поддержки дюративных действий и числовых и
объектных потоков.
TFD решает задачу планирования в три этапа: во-первых, задача
планирования PDDL преобразуется из его двоичного кодирования в более
лаконичное представление с использованием конечной области
переменных. Это позволяет использовать эвристику, использующую
иерархические зависимости между переменными состояния. На втором
этапе генерируются эффективные внутренние структуры данных для
эвристики и компонентов поиска. Наиболее важными являются графики
перехода в области для каждой переменной, которые кодируют, как можно
изменить значение переменной состояния, и причинный граф, который
представляет иерархические зависимости между различными перемен-
ными состояния. Наконец, выполняется поиск наилучшей первой
прогрессии, руководствуясь числовым временным вариантом улучшенной в
контексте аддитивной эвристики.

2.2 Формирование исходного состояния и описания цели


Предпочтительным способом назначения рабочих задач
сервисному роботу, безусловно, является формулирование их как
императивной команды. Для обработки такой команды робот должен уметь
распознавать, что высказывание пользователя направлено для него, и
анализироваться высказывание в соответствующем текстовом формате. В
DESIRE это выполняется компонентом автоматического понимания речи
(ASU). ASU имеет предопределенный набор основанных на грамматике
типов структур, используемых для отображения высказываний на
ключевые слова и их классификации на категории типа "социализация"
или "инструкция". Кроме того, отдельные структуры отображаются на
такие классы, как "действие" или "объект". С помощью этих ключевых
слов плановик извлекает информацию, собранную в инструкции, и
преобразует команду в логическую формулу, описывающую цель. В
основном, это делается путем отображения структуры действия на
структуру, сгенерированного ASU, на его описание в файле домена PDDL.
Отправной точкой сгенерированной формулы цели является эффект этого
действия. После этого параметры эффекта заменяют соответствующими
наполнителями, извлеченными из высказывания (снова обнаруживаются с
помощью грамматической структуры). Параметры, для которых не
существует наполнителя, становятся универсально или экзистенциально
количественно определяемыми, в зависимости от найденных ключевых
слов (например, "Принесите мне чашку соли!" преобразуется в ∃s (salt cup
(s) ∧ loc (s) = user), в то время как "Принесите мне все чашки соли!"
преобразуется в ∀s (salt cup (s) ⇒ loc (s) = user)).
Информация о текущем состоянии мира распределяется между
подсистемами, например, информация о положениях и ориентациях
объектов присутствует в компоненте анализа сцены, в то время как
5

положение и внутренний статус робота принадлежит самой модели. Таким


образом, информация, относящаяся к планированию, должна собираться и
объединяться, чтобы генерировать согласованное начальное состояние. С
этой целью мы разработали абстрактную модель мира (AWM). AWM
реализован как подключаемый механизм и, таким образом, не зависит от
активных в данный момент компонентов. Каждый компонент создает
прокси-подкомпонент, который отвечает за последовательную передачу
соответствующей информации планировщика. Во время выполнения
компоненты регистрируют свои прокси в планировщике, что позволяет
ему запрашивать всю соответствующую информацию. На основе
собранной таким образом информации планировщик создает глобально
согласованное начальное состояние.
Чтобы выразить информацию об определенных свойствах, таких как
цвет или форма, совместно используемые всеми экземплярами класса объектов,
мы разработали онтологическую структуру. Ее содержимое создается во
время выполнения и добавляется в исходное состояние. Кроме того, для
каждого класса объектов место, где обычно можно найти экземпляры
этого типа, также записывается в онтологию. Если один или более
объектов, явно необходимых для выполнения задачи, отсутствуют
(например, если цель состоит в том, чтобы отложить все соляные
стаканчики, но их нет), цель изменяется во времени, чтобы найти эти
объекты, и онтологическая информация может быть использована для
выполнения этой временной цели.
3 Глобальная Память

Пока непрерывное планирование служит гораздо более быстрой


заменой для планирования случайностей, еще не решена одна проблема:
системы планирования не предназначены для последовательного решения
задач планирования, которые, возможно, зависят друг от друга. Особенно
успешность или неудача выполнения действия, которые неизвестны во
время эпизода планирования, может вызвать зависимости, которые
необходимо устранить: в то время как в случае сбоя выполнения система
планирования осознает посредством мониторинга, что не был достигнут
прогресс в выполнении активных планов, поскольку состояние системы не
изменилось ожидаемым образом, она может быть не способна
отреагировать на это, потому что состояние не изменилось вообще. В этом
случае планировщик будет сталкиваться с одной и той же задачей
планирования снова и снова, оставляя всю систему в бесконечном цикле
генерации плана, неудачи в его выполнении, идентифицируя это
посредством контроля и снова генерируя тот же самый, невыполнимый
план.
Нашим решением этой проблемы является глобальная память
(GM), которая сохраняет дополнительные факты для каждого действия,
которые добавляются к начальному состоянию в следующем эпизоде
планирования после выполнения этих действий. Эти факты делятся на два
набора, один из которых поддерживает факты, которые применяются в
случае успешного выполнения, а другой – в случае ошибки выполнения.
Факт состоит либо из атомарных, либо из универсально количественно
определенных назначений переменных состояния, включая операторов
увеличения и уменьшения для числовых переменных состояния. В
зависимости от обратной связи секвенсора после выполнения действия
соответствующие факты применяются к GM, и в каждом прогоне
планировщика содержимое GM добавляется к начальному состоянию.
Пример синтаксиса, используемого для описания обновлений GM,
приведен на рис. 1. В первой строке просто указывается имя назначенного
оператора, в данном случае операция захвата с параметрами ?m
(подвижный объект), ?g (захват) и ?l (местоположение). Для этого
необходимы два предварительных условия, имеющих важное значение для
GM: Модель сцены среды должна быть актуальной, и количество
неудачных попыток захватить объект ?m с захватом ?g из местоположения
?l в прошлом не может превышать определенное количество испытаний (в
нашем случае максимальное количество в два испытания оказалось
разумным).

GRASP ?m ?g ?l
SUCC: (not (scene_model_updated))
(forall ?M ?G ?L ((grasp_unsuccessful ?M ?G ?L) = 0))
FAIL: (not (scene_model_updated))
((grasp_unsuccessful ?m ?g ?l) += 1)

Рисунок 1. Описание действия захвата в глобальной памяти

Обе части информации не могут быть собраны путем запроса


прокси AWM соответствующих субархитектур, поскольку ни модель
сцены, ни манипуляция не отслеживают их историю. По этой причине для
передачи этой информации между последовательными эпизодами
планирования используется глобальная память: независимо от успешности
выполнения действия захвата модель сцены считается устаревшей, как
видно в строке 2 и 4 - в обоих случаях (not (scene_model_updated))
добавляется к начальному состоянию. Отслеживание неудачных захватов с
другой стороны зависит от успеха выполнения действия: Если действие
захвата выполнено успешно, применяется строка 3 и все неудачные
захваты, которые когда-либо случались, забываются, т. е. сбрасываются в
ноль, так как при успешном захвате любого объекта среда изменяется
7

достаточно, чтобы оправдать повторение ранее неудачных захватов. В


случае неудачи выполнения действия переменная, отслеживающая
неудачные захваты, увеличивается на единицу, как указано в строке 5. Это
увеличение позволяет разорвать бесконечную петлю, в которую система
может войти в случае ошибок выполнения: После максимального
количества испытаний для захвата объекта переменная соответствующего
состояния (неудачный захват ?m ?g ?l) становится больше, чем
максимальное количество испытаний, приведенное в предварительном
условии действия захвата и оператор больше не применим, заставляя
планировщика находить новый план, не пытаясь снова захватить объект
?m с захватом ?g из местоположения ?l. Конечно, такое моделирование
домена приводит к ситуациям, когда робот больше не в состоянии
выполнять свои задачи, потому что он уже пытался захватить объект из
всех мест с обоими захватами. В этом случае мы добавили в домен
операторов, которые могут быть применены только в том случае, если
выполнение какого-либо оператора происходит с ошибками чаще, чем
позволяет заданное пороговое значение, и которые уведомляют пользователя
о том, что части полученной команды не могут быть выполнены.
Заметим, что подсчет числа неудачных действий - это, очевидно, не
единственный способ разорвать потенциальные бесконечные петли с
помощью GM. Альтернативно, мы могли бы, например, заставить
планировщика никогда не использовать неудачно выполненное действие
снова в том же состоянии, или, в случае захвата, соответствующее
положение стыковки может быть несколько изменено, но в проекте
DESIRE описанный способ работал достаточно хорошо.
4 Планирование с использованием внешних модулей

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


различной степени детализации: С одной стороны, высокоуровневые
действия, такие как перемещение в определенное положение или захват
определенного объекта, являются атомарными действиями с четко
определенными символическими предварительными условиями и
эффектами, с другой стороны, то, как на самом деле выполнить такое
действие, само по себе может быть сложной под-проблемой: для
достижения определенной позиции обычно требуется вызвать
подпрограмму планирования пути, и прежде чем объект может быть
захвачен, необходимо вычислить траекторию, свободную от препятствий.
В предыдущей работе мы представили новый подход к решению
таких типов задач: использование семантических вложений [5].
Семантическое вложение - это внешняя процедура, вызываемая в процессе
планирования для анализа определенных условий или непосредственного
изменения состояния планирования. Используя семантические вложения
для под-проблем, таких как планирование путей, мы комбинируем
преимущества обоих подходов, обходя их недостатки: с одной стороны,
планировщику высокого уровня не нужно заботиться о суб-проблемах,
поскольку они рассматриваются в семантических вложениях, с другой
стороны, в момент вызова семантического вложения генерируется только
информация, фактически необходимая для решения проблемы.
Для решения упомянутого вопроса решения задач различной сложности
мы реализовали несколько семантических вложений, в частности для
манипулирования объектами. При планировании захвата объекта,
становится понятно, что чисто символического представления
недостаточно для задачи. Следует понять, что полная интеграция
планировщика манипуляций слишком неэффективна, так как один вызов
такого планировщика обычно требует много времени на выполнения, а в
нетривиальных проблемах требуются сотни-тысячи таких вызовов.
Поэтому мы использовали компромиссное решение, используя процедуру
аппроксимации в качестве семантического вложения. Это дает нам более
точные результаты, чем чисто численное планирование при сохранении
эффективности даже в проблемах значительной сложности. В зависимости
от местоположения объекта и формы поверхности, на которой он
расположен, семантическое приложение проверяет, подходит ли данное
положение робота для захвата. С этой целью проверяется, находится ли
объект в пределах досягаемости данного манипулятора и не закрыт ли он
другими объектами, находящимися поблизости. Кроме того, проверяется,
что угол между роботом и положением объекта находится в пределах
некоторого заданного диапазона.
Чтобы найти подходящее положение на целевой поверхности для
размещения объекта, мы использовали семантическое вложение, которое
работает следующим образом: во-первых, поверхность разделяется на ячейки
сетки в один квадратный сантиметр. Затем определяются занимаемые ячейки на
основе всех остальных объектов на той же поверхности. Наконец, в качестве
положения для размещения объекта выбирается свободная область, достаточно
большая для удержания объекта и максимального увеличения оставшегося
свободного пространства. Обратите внимание, что все эти вычисления
выполняются только тогда, когда они необходимы.
5 Архитектура системы
Прежде чем подведем итоги, дадим обзор всей реализованной под-
архитектуры планирования, которая изображена на рис 2. Центральное
место в нем занимает планировщик TFD/M, как описано в Разделе 4. Его
ввод генерируется подкомпонентами, изображенными в поле внизу слева -
AWM и GM вносят текущее состояние систем, которое соответствует
начальному состоянию планировщика, а GoalGen преобразует команду
пользователя в PDDL-описание задачи.
9

Drive Mani-
Control pulation
Sequencer

Scene User
Analysis Interface

AWM Monitoring ASU


Proxy

TFD/M
Modules

Global
Memory AWM Goal Gen Domain

Fig. 2. System Architecture of the Planning subcomponent in DESIRE.

Как мы описывали в предыдущем разделе, символьного


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

6 Conclusion
В этом документе представлена система планирования,
используемая в проекте DESIRE. Мы показали, как текущее состояние
робота генерируется из информации распределенных суб-архитектур и как
дополнительные знания передаются между последовательными эпизодами
планирования, чтобы избежать бесконечных циклов в непрерывном
планировании, которые могут возникнуть, если какое-то действие кажется
исполняемым на символьном уровне, но действительно не находится в
реальном мире
Еще одной трудностью, возникающей при планировании в
динамичной и неопределенной среде, является необходимость расчетов,
превышающих вычислительную мощность PDDL. С помощью концепции
семантических привязанностей мы представили способ преодолеть это
препятствие.

Признание: Это исследование было поддержано федеральным


министерством образования и исследований Германии (BMBF) в рамках
гранта № 01IME01-ALU.
1

References
1. Plöger, P., Pervölz, K., Mies, C., Eyerich, P., Brenner, M., Nebel,
B.: The DESIRE Service Robotics Initiative. Künstliche Intelligenz 08 (4), pp. 29–32
(2008)
2. Ghallab, M., Nau, D., Traverso, P.: Automated Planning:
Theory and Practise. Morgan Kaufmann Publishers, San Fransisco, CA (2004)
3. Helmert, M.: The Fast Downward Planning System. JAIR (26),
pp. 191-246 (2006)
4. Eyerich, P., Mattmüller, R., Röger, G.: Using the Context-
enhanced Additive Heuristic for Temporal and Numeric Planning. In: 19th Int.
Conf. on Automatic Planning and Scheduling, pp. 130–137. AAAI Press,
California (2009)
5. Dornhege, C., Eyerich, P., Keller, T., Trüg, S., Brenner, M.,
Nebel, B.: Semantic Attachements for Domain-Independent Planning Systems. In:
19th Int. Conf. on Automatic Planning and Scheduling, pp. 114–121. AAAI Press,
California (2009)
6. Brenner, M., Nebel, B.: Continual Planning and Acting in
Dynamic Multiagent Environments. Journal of Autonomous Agents and Multiagent
Systems 19 (3), pp. 297-331 (2009)
7. Littman, M. L., Goldsmith, J., Mundhenk,M.: The Computational
Complexity of Probabilistic Planning. JAIR (9), pp. 1-36 (1998)
8. Rintanen, J.: Constructing conditional plans by a theorem-prover.
JAIR (10), pp. 323352 (1999)
9. Hoffmann, J, Nebel, B.: The FF Planning System: Fast Plan
Generation Through Heuristic Search. JAIR (14), pp. 253-302 (2001)
10. Geffner, H.: Functional STRIPS: a more flexible language for
planning and problem solving. In Logic-Based Artificial Intelligence. Dordrecht,
Holland: Kluwer (2000)
11. Fox, M., Long, D.: PDDL2.1: An extension to PDDL for
expressing temporal planning domains. JAIR (20), pp. 61-124 (2003)