PlanSys2 & PDDL

Для описания задач (task planning) в фреймворке Робосборщик используется язык PDDL и основанная на нём система планирования и управления задачами Plansys2.

Planning Domain Definition Language (PDDL)

PDDL (Planning Domain Definition Language) - Lisp-подобный язык для логического планирования. PlanSys2 поддерживает PDDL версии 2.1, текущая версия PDDL - 3.1.

Описание технологического процесса для автоматического планирования на языке PDDL состоит из двух частей:

• Описание предметной области - Domain (какие в принципе существуют типы объектов, условий, функций и действий)
• Описание конкретной задачи - Problem (какие объекты и какие стартовые условия представлены в конкретном техпроцессе - т.е. что у нас есть вообще в сцене/установке/производстве)

PDDL Domain

Согласно спецификации PDDL Domain содержит следующие базовые сущности планируемой задачи:

Объекты (Objects)

Какие типы/подтипы объекты фигурируют в технологическом процессе. Примеры

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

Условия (Predicates)

Типы условий, при которых начинаются те или иные действия. Это вопросы, подразумевающие ответ Да или Нет.

Примеры:

• Посадочный материал в пробирке?
• Робот свободен для задачи?
• Объект распознан?
• Посадочный материал поврежён?

Функции (Functions)

Функции похожи на условия - это тоже вопросы. Разница в том, что это вопросы, подразумевающие ответ в виде числа.

Примеры:

• Какой заряд у аккумуляторной батареи?
• Какая масса у посадочного материала X?

Действия (actions)

Действия, производящиеся в рамках технологического процесса. Состоят из:

• Параметров (parameters) - задействованные объекты
• Длительности (duration) - продолжительность действия
• Условий (condition) - условия, при которых действие начинается/продолжается/завершается
• Эффектов (effect) - результаты после начала и завершения

Пример:

• Действие захват-пробирки
• Параметры робот, захватное-устройство, пробирка
• Условия
  • начала: робот-свободен, захватное-устройство-подключено, пробирка-в-наличии
  • продолжения - в-комнате-нет-людей
  • завершения - робот-не-движется, пробирка-в-захвате
• Эффекты
  • в начале: робот-занят
  • при завершении - робот-свободен, пробирка-захвачена

PDDL Problem

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

Описание задачи/проблемы выглядит следующим образом

• Объекты (objects) - наличествующие объекты, обязательно должны соответствовать типам из PDDL Domain
• Начальное состояние (init) - текущие значения условий на момент начала
• Спецификация целей (goal) - условия выполнения задания

ROS2 Planning System (PlanSys2)

PlanSys2 - это система планирования для ROS2 от создателей ROSPlan (система планирования для ROS1). PlanSys2 не ограничивается планированием в рамках одного устройства, а поддерживает распределение задач между многими взаимодействующими агентами в реальном времени. Исполнение планов реализовано на базе Деревьев поведения.

Видео-презентация 1, 2

Архитектура фреймворка PlanSys2

Архитектура PlanSys2 модульная и каждый отдельный компонент может быть заменён.

Описание компонентов

• Planner Node - основной узел. Содержит алгоритм планирования и использует разные т.н. plan solvers - POPF, TFD. При генерации планов Planner Node обращается к узлам Domain Expert и Problem Expert, содержащими описания соответствующих предметным областям в формате PDDL.
• Domain Expert считывает PDDL-файлы и размещает их во внутренней памяти. Этот компонент содержит общее описание предметной области.
• Problem Expert содержит описание проблемы(задачи), которую нужно решить, включая конкретные экземпляры классов, предикаты, функции и цели, которые валидируются Domain Expert. то есть Problem Expert содержит динамическое знание приложения. Этот узел создаёт описания задач для Planner Node в формате PDDL.
• Executor Node запрашивает у Planner Node план и, если тот существует, то выполняет его. План превращается в Дерево поведения (Behaviour Tree). Для исполнения действий используется протокол аукциона, который выбирает наиболее подходящий узел, реализующий выполняемое действие.
• Applications - приложения роботов, использующие PlanSys2. Содержат узлы, реализующие действия(Actions), и модель PDDL, которая их реализует. Любое приложение также включает в себя узел Controller Node, который обращается к знаниям Problem Expert для консультаций и установления экземпляров, предикатов и целей. Этот контроллер также запрашивает Executor Node для выполнения или отмены планов.
• Terminal - среда исполнения команд для управления и мониторинга PlanSys2.
  • Визуализирует структуру сущностей PDDL и информацию Problem Expert.
  • Показывает подробности о свойствах и действиях в терминах PDDL.
  • Устанавливает и удаляет экземпляры, свойства, функции и цели.
  • Визуализирует, исполняет и отслеживает планы.
  • Проверяет статус узлов, исполняющих действия.

Пример сборки автомобиля тремя роботами

Сначала формируется план в PDDL-формате:

0 (move rb1 assembly_zone body_car_zone)
0 (move rb2 assembly_zone steerwheel_zone)
0 (move rb3 assembly_zone wheels_zone)
5.001 (transport rb1 bc_1 body_car_zone assembly_zone)
5.001 (transport rb2 stwhl_1 steerwheel_zone assembly_zone)
5.001 (transport rb3 whl_1 wheels_zone assembly_zone)
10.002 (assemble rb1 assembly_zone whl_1 bc_1 stwhl_1 car_1)
10.002 (move rb2 assembly_zone body_car_zone)
10.002 (move rb3 assembly_zone steerwheel_zone)
15.003 (move rb1 assembly_zone wheels_zone)
15.003 (transport rb2 bc_2 body_car_zone assembly_zone)
15.003 (transport rb3 stwhl_2 steerwheel_zone assembly_zone)
20.004 (transport rb1 whl_2 wheels_zone assembly_zone)
20.004 (move rb3 assembly_zone body_car_zone)
25.005 (assemble rb2 assembly_zone whl_2 bc_2 stwhl_2 car_2)
25.005 (move rb1 assembly_zone steerwheel_zone)
25.005 (transport rb3 bc_3 body_car_zone assembly_zone)
30.006 (move rb2 assembly_zone wheels_zone)
30.006 (transport rb1 stwhl_3 steerwheel_zone assembly_zone)
35.007 (transport rb2 whl_3 wheels_zone assembly_zone)
40.008 (assemble rb1 assembly_zone whl_3 bc_3 stwhl_3 car_3)

Данный план преобразуется в Дерево поведения, где заданы узлы для параллельного и последовательного выполнения задач:

Структура отдельного действия:

При определении порядка исполнения плана используется т.н. Аукцион действий (action auction). Когда наступает очередь для выполнения действия (например, из схемы выше), формируется новая запись ActionPerformerClient в таблице ActionMap.

Протокол работает так:

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

Пример:

Симуляция и полевые испытания

PlanSys2 был проверен сначала в симуляции, а потом и на реальной системе, состоящей из 3-ёх роботов. Исходные коды проекта опубликованы на Github.

Имплементация модуля в составе фреймворка

В качестве основной рабочей среды модуля используется параметри­ческая САПР с открытым программным кодом FreeCAD. Данный выбор был сделан как из-за открытого программного кода и общедоступности системы, так и благодаря существенной гибкости и широким возможностям этого программного пакета, позволяющего включать в его работу пользовательские скрипты, макросы и верстаки самого широкого назначения. Модуль построения технологических карт и спецификаций производственного оборудования является верстаком (англ. workbench, аналог плагина или расширения) к FreeCAD, а не его модификацией. Исходный код модуля не предполагается встраивать в исходный код FreeCAD, поэтому лицензионные ограничения LGPL2+ на него не распространяются.

Модуль технологической подготовки имеет ценность не только как часть фреймворка Робосборщик, но и как самостоятельный инструмент, который позволит пользователю — участнику производственного коллектива — более эффективно и удобно создавать необходимую для запуска документацию — файлы, чертежи, 3D-модели и т.д., а также управлять производственными процессами в небольшом масштабе. При этом, будучи включенным в фреймворк, модуль многократно увеличивает свои возможности, позволяя создавать исполняемые спецификации, которые используются для подготовки автоматизированного производства. Метрикой для оценки работы модуля будет затрачиваемое оператором время на формирование спецификации с разметкой моделей.

Основные задачи модуля технологической подготовки:

1. Создание технологических карт и спецификаций;
2. Разметка геометрических моделей и наложение на них вспомогательной информации: позиций захвата, рабочих зон, плоскостей базирования, участков сопряжения и позиционирования, зон с особыми условиями допусков и посадок;
3. Разметка моделей оборудования с целью указания области работ, инструментов, указания связей с возможными технологическими операциями;
4. Экспорт моделей для последующей обработки в Blender, включая информацию об активно управляемых сочленениях робота (Joints).

В верстаке используется дополнительное дерево построения вспомогательных объектов, таких как ориентированные системы координат, выделенные плоскости, объемы и тела, в которых указывается информация, описывающая состояния, привязки и характеристики описываемой сущности. Затем осуществляется экспорт объектов в форматах JSON, PDDL, SDF в пригодном для использования другими модулями виде.

Для CAD-модели изделию формируется набор PDDL, SDF и JSON файлов, которые полностью описывают его поведение как производственной единицы, а также технологическая карта на изготовление. Для этого используются реализованные алгоритмы создания спецификаций, расчета заданий на 3д-печать, загрузка полученной очереди в слайсер и анализ полученной программы на языке G‑код с целью внесения информации в PDDL-спецификацию задачи для оценки длительности работ. На примере робота-манипулятора Robossembler Arm продемонстрирована генерация вспомогательной разметки и спецификации. В модели манипулятора размечены позиции сочленений звеньев, экспортируемые в виде JSON-файлов, которые затем использовались в ходе адаптации модели для задач симуляции.

Примеры генерации

Для демонстрации работоспособности модуля в части генерации спецификаций для системы планирования сгенерируем файлы domain.pddl и problem.pddl. domain.pddl описывает рабочий домен, состоящий из 3д-принтера, производящего печать деталей, робота-манипулятора, производящего операции извлечения и сборки деталей, и наблюдателя, осуществляющего подготовку 3д-принтера к работе.

Фрагмент исходного кода сгенерированной спецификации domain.pddl:

(define (domain Printer)
 
(:requirements :strips :typing :fluents :durative-actions)
(:types 
    printer workspace - zone 
    part 
    arm 
    assembly 
    human 
    filament 
)
   (:predicates
       (arm_available ?a - arm)
       (part_at ?p - part ?z - zone)
       (printer_ready ?p - printer)
       (printer_checked ?p - printer)
       (printer_at_work ?p - printer)
       (part_of ?part - part ?whole - assembly)
       (assembly_order ?prev ?next - assembly)
       (assembled ?whole - assembly ?z - zone)
       (observer_free ?h - human)
       (filament_at ?f - filament ?z - zone)
   )

(:durative-action print
    :parameters ( ?p - part ?pr - printer )
       :duration ( = ?duration 20)
    :condition (and 
       (at start(printer_ready ?pr)) 
  )
    :effect (and 
       (at start (not (printer_ready ?pr))) 
       (at start (printer_at_work ?pr )) 
       (at end(part_at ?p ?pr)) 
       (at end (not (printer_at_work ?pr ))) 
	)
  )
...

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

problem.pddl описывает производственную задачу для сборки конкретного изделия. В данном случае, на примере коробки передач.

Исходный код сгенерированной PDDL-спецификации производственной задачи problem.pddl:

(define (problem p1)
(:domain robossembler)
(:objects
	;; information from Scene
	rasmt - arm
	printer1 printer2 printer3 - printer
	workspace1 - workspace
	worker - human
	filament1 filament2 filament3 - filament
	;; information from CAD
	pad009003002002 pad009003002003 pad009003002005 pad009003002011 fusion004003 o_2_a001 o_2_m001 o_3_m001 o_3_a001 pad009003002008 fusion005 o_4_m001 o_5_m001 o_5_a001 o_4_a001 fusion006 r_a001 r_m001 r_l001 synfix synfix001 fusion fusion001 synfix002 fusion002 synfix003 fusion007 pad009003002012 pad001 pocket pad002 fusion008 fusion009 bearing_dgsr_6006_001 bearing_dgsr_6006_002 bearing_dgsr_6006_003 bearing_dgsr_6005_ bearing_dgsr_6005_001 bearing_dgsr_6005_002 bearing_dgsr_6005_003 bearing_dgsr_6005_004 pad003 pocket001 - part
	subasm00 subasm0 subasm1 subasm2 subasm3 subasm4 subasm5 subasm6 subasm7 subasm8 subasm9 subasm10 subasm11 subasm12 subasm13 subasm14 subasm15 subasm16 subasm17 subasm18 subasm19 subasm20 subasm21 subasm22 subasm23 subasm24 subasm25 subasm26 subasm27 subasm28 subasm29 subasm30 subasm31 subasm32 subasm33 subasm34 subasm35 subasm36 subasm37 subasm38 subasm39 subasm40 subasm41 subasm42 - assembly
)
(:init
	;; information from Scene

	(observer_free worker)
	; (not(printer_ready printer1))

	; (printer_ready printer2)
	; (printer_ready printer3)
	(filament_at filament1 workspace1)
	(filament_at filament2 workspace1)
	(filament_at filament3 workspace1)

	(arm_available rasmt)
	;; information from CAD
	(assembled subasm00 workspace1)

(part_of pad009003002002 subasm0)
    (part_of pad009003002003 subasm1)
    (part_of pad009003002005 subasm2)
    (part_of pad009003002011 subasm3)
    (part_of fusion004003 subasm4)
	...

Полученные файлы передаются в качестве параметров в программу-решатель планов POPF, который формирует план сборки. Фрагмент вывода полученного плана сборки в терминал:

/nix/store/j9i8z3271jv3hf43i30d41sx2m3zwxia-ros-humble-popf-0.0.14-r1/lib/popf/popf domain.pddl problem.pddl 
Constructing lookup tables: [10%] [20%] [30%] [40%] [50%] [60%] [70%] [80%] [90%] [100%]
Post filtering unreachable actions:  [10%] [20%] [30%] [40%] [50%] [60%] [70%] [80%] [90%] [100%]
92% of the ground temporal actions in this problem are compression-safe
b (174.000 | 1.000)b (173.000 | 6.001)b (172.000 | 6.001)b (171.000 | 27.003)b (170.000 | 47.004)b (169.000 | 48.005)b (168.000 | 68.006)b (167.000 | 69.007)b (166.000 | 89.008)b (165.000 | 90.009)b (164.000 | 110.010)b (163.000 | 111.011)b (162.000 | 131.012)b (161.000 | 132.013)b (160.000 | 152.014)b (159.000 | 153.015)b (158.000 | 173.016)b (157.000 | 174.017)b (156.000 | 194.018)b (155.000 | 195.019)b (154.000 | 215.020)b (153.000 | 216.021)b (152.000 | 236.022)b (151.000 | 237.023)b (150.000 | 257.024)b (149.000 | 258.025)b (148.000 | 278.026)b (147.000 | 279.027)b (146.000 | 299.028)b (145.000 | 300.029)b (144.000 | 320.030)b (143.000 | 321.031)b (142.000 | 341.032)b (141.000 | 342.033)b (140.000 | 362.034)b (139.000 | 363.035)b (138.000 | 383.036)b (137.000 | 384.037)b (136.000 | 404.038)b (135.000 | 405.039)b (134.000 | 425.040)b (133.000 | 426.041)b (132.000 | 446.042)b (131.000 | 447.043)b (130.000 | 467.044)b (129.000 | 468.045)b (128.000 | 488.046)b (127.000 | 489.047)b (126.000 | 509.048)b (125.000 | 510.049)b (124.000 | 530.050)b (123.000 | 531.051)b (122.000 | 551.052)b (121.000 | 552.053)b (120.000 | 572.054)b (119.000 | 573.055)b (118.000 | 593.056)b (117.000 | 594.057)b (116.000 | 614.058)b (115.000 | 615.059)b (114.000 | 635.060)b (113.000 | 636.061)b (112.000 | 656.062)b (111.000 | 657.063)b (110.000 | 677.064)b (109.000 | 678.065)b (108.000 | 698.066)b (107.000 | 699.067)b (106.000 | 719.068)b (105.000 | 720.069)b (104.000 | 740.070)b (103.000 | 741.071)b (102.000 | 761.072)b (101.000 | 762.073)b (100.000 | 782.074)b (99.000 | 783.075)b (98.000 | 803.076)b (97.000 | 804.077)b (96.000 | 824.078)b (95.000 | 825.079)b (94.000 | 845.080)b (93.000 | 846.081)b (92.000 | 866.082)b (91.000 | 867.083)b (90.000 | 887.084)b (89.000 | 888.085)b (88.000 | 908.086)b (87.000 | 909.087)b (86.000 | 914.088)b (85.000 | 914.088)b (84.000 | 919.089)b (83.000 | 919.089)b (82.000 | 924.090)b (81.000 | 924.090)b (80.000 | 929.091)b (79.000 | 929.091)b (78.000 | 934.092)b (77.000 | 934.092)b (76.000 | 939.093)b (75.000 | 939.093)b (74.000 | 944.094)b (73.000 | 944.094)b (72.000 | 949.095)b (71.000 | 949.095)b (70.000 | 954.096)b (69.000 | 954.096)b (68.000 | 959.097)b (67.000 | 959.097)b (66.000 | 964.098)b (65.000 | 964.098)b (64.000 | 969.099)b (63.000 | 969.099)b (62.000 | 974.100)b (61.000 | 974.100)b (60.000 | 979.101)b (59.000 | 979.101)b (58.000 | 984.102)b (57.000 | 984.102)b (56.000 | 989.103)b (55.000 | 989.103)b (54.000 | 994.104)b (53.000 | 994.104)b (52.000 | 999.105)b (51.000 | 999.105)b (50.000 | 1004.106)b (49.000 | 1004.106)b (48.000 | 1009.107)b (47.000 | 1009.107)b (46.000 | 1014.108)b (45.000 | 1014.108)b (44.000 | 1019.109)b (43.000 | 1019.109)b (42.000 | 1024.110)b (41.000 | 1024.110)b (40.000 | 1029.111)b (39.000 | 1029.111)b (38.000 | 1034.112)b (37.000 | 1034.112)b (36.000 | 1039.113)b (35.000 | 1039.113)b (34.000 | 1044.114)b (33.000 | 1044.114)b (32.000 | 1049.115)b (31.000 | 1049.115)b (30.000 | 1054.116)b (29.000 | 1054.116)b (28.000 | 1059.117)b (27.000 | 1059.117)b (26.000 | 1064.118)b (25.000 | 1064.118)b (24.000 | 1069.119)b (23.000 | 1069.119)b (22.000 | 1074.120)b (21.000 | 1074.120)b (20.000 | 1079.121)b (19.000 | 1079.121)b (18.000 | 1084.122)b (17.000 | 1084.122)b (16.000 | 1089.123)b (15.000 | 1089.123)b (14.000 | 1094.124)b (13.000 | 1094.124)b (12.000 | 1099.125)b (11.000 | 1099.125)b (10.000 | 1104.126)b (9.000 | 1104.126)b (8.000 | 1109.127)b (7.000 | 1109.127)b (6.000 | 1114.128)b (5.000 | 1114.128)b (4.000 | 1119.129)b (3.000 | 1119.129)b (2.000 | 1124.130)b (1.000 | 1124.130);;;; Solution Found

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

В модуле реализованы следующие функции технологической подготовки:

1. Добавление позиций с метаданными в CAD-модели
2. Экспорт и импорт точек с метаданными о моделях для использования в средах симуляции и визуализации.
3. Генератор PDDL-спецификаций;
4. Расчёт длительности печати для печатных деталей.
5. Подготовка материалов к экспорту в среды визуализации.
6. Генерация сборочных спецификаций для САПР-модели.

Исходный код модуля технологической подготовки.

Другие полезные ссылки

Основные классы алгоритмов планирования

Программы для работы с PDDL

• Плагины для редакторов VSCode (video-tutorial), Sublime Text
• vPlanSim - графический интерфейс для визуализации и симуляции PDDL-планирования на базе Python3.7, VTK8.2, PyQt5.
• Парсеры PDDL - Julia, python, C#, Java, С++
• planutils - библиотека общего назначения для разработки, запуска и оценки планировщиков.
• blockly-pddl - транслятор PDDL-файлов в язык Blockly и обратно.

PDDL-фреймворки

• pddlstream - фреймворк для планирования, состоящий из языка действий и набора алгоритмов для AI-планирования при наличии процедур выборки. PDDLStream расширяет PDDL, вводя потоки и декларативные спецификации процедур выборки. Алгоритмы PDDLStream не зависят от предметной области и решают проблемы PDDLStream только с описанием каждого сэмплера как черного ящика. Мотивом появления PDDLStream был Task and Motion Planning (TAMP) - paper.
• pddlgym - фреймворк, который автоматически создает среду OpenAI-Gym из спецификаций PDDL - paper.
• LAPKT - набор легковесных инструментов для автоматизированного планирования (Lightweight Automated Planning Toolkit). Предлагает независимый от конкретных языков планирования абстрактный интерфейс для расчёта планов. Легко интегрируется с PDDL/STRIPS.
• Fast Downward - система планирования, поддерживающая PDDL. На конкурсе Classical Planing в 2018 году заняла первое место в двух треках (подробнее).

Расширения PDDL

• HDDL - расширения PDDL для поддержки иерархических задач. Использовался для создания планировщика PANDA Planning Framework, где реализован парсер HDDL
• Universal PDDL Parser - Multiagent Extension - расширение universal-pddl-parser, поддерживающие multi-agent расширение PDDL 3.1 для спецификаций Crosby, Jonsson and Rovatsos, 2014 и Kovacs, 2012.