Для описания задач (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
Согласно [спецификации](https://planning.wiki/ref) PDDL Domain содержит следующие базовые сущности планируемой задачи:
#### Объекты (Objects)
Какие типы/подтипы объекты фигурируют в технологическом процессе.
- завершения - _робот-не-движется_, _пробирка-в-захвате_
- Эффекты
- в начале: _робот-занят_
- при завершении - _робот-свободен_, _пробирка-захвачена_
### PDDL Problem
Проблема описывает конкретную задачу с исходными условиями на момент начала задачи. Исходных условий может быть много. Problem обычно генерируется автоматически для подбора оптимальной конфигурации. Планировщик сам генерирует план исполнения в зависимости от описания задачи.
Описание задачи/проблемы выглядит следующим образом
- __Объекты__ (objects) - наличествующие объекты, обязательно должны соответствовать типам из PDDL Domain
- __Начальноесостояние__ (init) - текущие значения условий на момент начала
- __Спецификация целей__ (goal) - условия выполнения задания
[PlanSys2](https://github.com/IntelligentRoboticsLabs/ros2_planning_system) - это система планирования для ROS2 от создателей ROSPlan (система планирования для ROS1). 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.
* Устанавливает и удаляет экземпляры, свойства, функции и цели.
Данный план преобразуется в Дерево поведения, где заданы узлы для параллельного и последовательного выполнения задач:
Структура отдельного действия:
При определении порядка исполнения плана используется т.н. _Аукцион действий (action auction)_. Когда наступает очередь для выполнения действия (например, из схемы выше), формируется новая запись _ActionPerformerClient_ в таблице _ActionMap_.
Протокол работает так:
* Когда ActionPerformerClient запись создана, посылается сообщение-запрос с описанием действия и его параметров
* Ноды, находящиеся в состоянии ожидания и способные выполнить этот запрос, отвечают, подтверждая или отвергая данный запрос
* После подтверждения ноды приступают к исполнению
* Периодически ноды отправляют сообщения с обратной связью о действиях, которые они исполняют.
PlanSys2 был проверен сначала в симуляции, а потом и на реальной системе, состоящей из 3-ёх роботов. Исходные коды проекта опубликованы на [Github](https://github.com/IntelligentRoboticsLabs/plansys2_cooking_experiment).
В качестве основной рабочей среды модуля используется параметрическая САПР с открытым программным кодом 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д-принтера к работе.
Генерация спецификации предметной области позволяет получить полную информацию о входящих в состав изделия элементах, что, впоследствии, используется как напрямую, так и для создания производственных заданий.
`problem.pddl` описывает производственную задачу для сборки конкретного изделия. В данном случае, на примере коробки передач.
Исходный код сгенерированной PDDL-спецификации производственной задачи `problem.pddl`:
Полученные файлы передаются в качестве параметров в программу-решатель планов [POPF](https://github.com/fmrico/popf), который формирует план сборки. Фрагмент вывода полученного плана сборки в терминал:
Модуль технологической подготовки позволяет описывать все составные части объектов проекта — от оборудования и роботов-манипуляторов и до производимых изделий. При этом один и тот же объект в разных случаях может фигурировать как в одной, так и в другой роли.
В модуле реализованы следующие функции технологической подготовки:
1. [Добавление позиций с метаданными в CAD-модели](https://gitlab.com/robossembler/framework/-/blob/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames/markupEntities.py)
2. [Экспорт и импорт точек с метаданными о моделях для использования в средах симуляции и визуализации](https://gitlab.com/robossembler/framework/-/blob/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames/ImportExportEntities.py).
4. [Расчёт длительности печати для печатных деталей](https://gitlab.com/robossembler/framework/-/blob/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames/printETA.py).
5. [Подготовка материалов к экспорту в среды визуализации](https://gitlab.com/robossembler/framework/-/blob/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames/modelExport.py).
6. [Генерация сборочных спецификаций для САПР-модели](https://gitlab.com/robossembler/framework/-/blob/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames/BoMList.py).
[Исходный код модуля технологической подготовки](https://gitlab.com/robossembler/framework/-/tree/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames).
* Плагины для редакторов [VSCode](https://github.com/jan-dolejsi/vscode-pddl)  ([video-tutorial](https://www.youtube.com/watch?v=BFlCz49ETcA&list=PL1Q0jeuU6XppflOPFx1qQVuWbXTcjxevU)), [Sublime Text](https://github.com/Pold87/myPDDL) 
* [vPlanSim](https://github.com/mastrogiorgis/vPlanSim) - графический интерфейс для визуализации и симуляции PDDL-планирования на базе Python3.7, VTK8.2, PyQt5. 
* [planutils](https://github.com/AI-Planning/planutils) - библиотека общего назначения для разработки, запуска и оценки планировщиков. 
* [blockly-pddl](https://github.com/AI-Planning/blockly-pddl) - транслятор PDDL-файлов в язык Blockly и обратно. 
* [pddlstream](https://github.com/caelan/pddlstream) - фреймворк для планирования, состоящий из языка действий и набора алгоритмов для AI-планирования при наличии процедур выборки. PDDLStream расширяет PDDL, вводя потоки и декларативные спецификации процедур выборки. Алгоритмы PDDLStream не зависят от предметной области и решают проблемы PDDLStream только с описанием каждого сэмплера как черного ящика. Мотивом появления PDDLStream был Task and Motion Planning (TAMP) - [paper](https://arxiv.org/pdf/1802.08705.pdf). 
* [pddlgym](https://github.com/tomsilver/pddlgym) - фреймворк, который автоматически создает среду OpenAI-Gym из спецификаций PDDL - [paper](https://arxiv.org/pdf/2002.06432.pdf). 
* [LAPKT](https://github.com/LAPKT-dev/LAPKT-public) - набор легковесных инструментов для автоматизированного планирования (Lightweight Automated Planning Toolkit). Предлагает независимый от конкретных языков планирования абстрактный интерфейс для расчёта планов. Легко интегрируется с PDDL/STRIPS.
* [Fast Downward](https://github.com/aibasel/downward) - система планирования, поддерживающая PDDL. На конкурсе Classical Planing в 2018 году заняла первое место в двух треках ([подробнее](https://ipc2018-classical.bitbucket.io/#results)).
* [HDDL](https://www.uni-ulm.de/fileadmin/website_uni_ulm/iui.inst.090/Publikationen/2020/Hoeller2020HDDL.pdf) - расширения PDDL для поддержки иерархических задач. Использовался для создания планировщика [PANDA Planning Framework](https://panda-planner-dev.github.io/), где реализован [парсер HDDL](https://github.com/panda-planner-dev/pandaPIparser)
* [Universal PDDL Parser - Multiagent Extension](https://github.com/aig-upf/universal-pddl-parser-multiagent) - расширение [universal-pddl-parser](https://github.com/aig-upf/universal-pddl-parser), поддерживающие multi-agent расширение PDDL 3.1 для спецификаций Crosby, Jonsson and Rovatsos, 2014 и Kovacs, 2012.
