Task and Motion Planning
This tutorial is devoted to illustrate the need to interact between task and motion planning levels in order to obtain a feasible set of actions for a robot to perform a given manipulation task.
The tutorial first presents the tools used for task planning and for motion planning and then shows the limitations of a naive task and motion planning approach based on a decoupled successive execution of planning levels.
Introduction
The tools
Task planning is done with the Fast Forward heuristic-based task planning approach. The downward_ros package is provided that offers a service to plan at task level given a PDDL domain file and a PDDL problem file.
PDDL files defining domains and problems can be checked with the following PDDL editor.
Motion planning is performed using the RRT-Connect sampling-based planner. The kautham_ros package provides a ROS2 interface to The Kautham Project motion planning suite, offering an extensive set of services.
Install instructions
First install the The Kautham Project and the Fast Downward, the motion planner and the task planner suits, respectively, to be used in this tutorial. The packages, built for Ubuntu Noble 24.04 LTS, are located in the debian-robotics repository at launchpad. Follow these steps:
sudo add-apt-repository ppa:deb-rob/noble-robotics
sudo apt update
sudo apt-get install kautham
sudo apt-get install fast-downward
sudo apt-get upgrade
The other packages need for this tutorial need to be build. They are stored in the task_and_motion_planning2 meta-repository.
This meta repository contains the following submodules:
downward_ros: A C++ server that calls the Fast Downward task planning functions.
kautham_ros: A C++ server to calls the Kautham motion planning functions.
ktmpb: A Python client to call the task planning and the motion planning services.
Follow these steps to install and build the packages (skip step 1 if you’re in the ETSEIB computer rooms):
Install Python3 modules required by the ktmpb package and the libcoin library required by kautham_ros:
sudo apt-get install python3-pip python3-yaml sudo pip3 install transformations sudo pip3 install pytransform3d sudo apt-get install libcoin-dev
Create a colcon workspace for this tutorial and clone the task and motion planning meta-repository in the src subfolder:
mkdir -p ws_tamp/src cd ws_tamp/src git clone --recurse-submodules https://gitioc.upc.edu/rostutorials/task_and_motion_planning2.git cd ..
Source the ROS2 setup file (omit this step if your .bashrc file already does it):
echo "source /opt/ros/jazzy/setup.bash" >> ~/.bashrc source ~/.bashrc
Then build the packages:
colcon build --symlink-install source install/setup.bash
The demos
Four demos have been prepared for this tutorial, where one or several objects have to be transferred from one place to another by a robot:
Table_Rooms_R2: The first one consists of a two-room scenario and a mobile robot (shaped as a table) that moves around with only translational degrees of freedom, and that is able to carry objects. This will be the main demo being used in the tutorial.
All the files related to this demo are stored in the folder: task_and_motion_planning2/ktmpb/ktmpb_demos/OMPL_geometric_demos/Table_Rooms_R2/.
Tiago-kitchen: The second one consists of the Tiago mobile manipulator moving in a kitchen environment and manipulating objects (cans) between two counters.
All the files related to this demo are stored in the folder: task_and_motion_planning2/ktmpb/ktmpb_demos/OMPL_geometric_demos/Tiago-kitchen/.
UR3-chess: The third one consists of the UR3 manipulator manipulating chess pieces on the chessboard.
All the files related to this demo are stored in the folder: task_and_motion_planning2/ktmpb/ktmpb_demos/OMPL_geometric_demos/chess/.
Yumi-table-top: The fourth one consists of the Yumi dual-arm manipulator manipulating pieces on a table.
All the files related to this demo are stored in the folder: task_and_motion_planning2/ktmpb/ktmpb_demos/OMPL_geometric_demos/Yumi_Table_Top/.
The following rules are assumed:
After manipulating an object (picking/placing) the robot always returns to a home configuration. For the Table the home configurations are positions in the middle of the rooms facing the door; for the Tiago they are positions of the base in front of each counter and with the arm folded; for the UR3 it is the configuration shown in the picture above.
The grasp configurations are defined by the Table as positions on top of the objects; for the Tiago and UR3 any arm configuration that places the gripper enveloping the object can be defined (top and lateral grasps are provided in the Tiago demo and just top grasp for the UR3 demo).
Task Planning
The purpose of this section is to illustrate the use of PDDL files to describe a planning domain and a planning problem, and to find a solution plan using the Fast Forward task planning method.
The PDDL domain and problems files are located at task_and_motion_planning2/ktmpb/ktmpb_demos/OMPL_geometric_demos/Table_Rooms_R2/ff-domains.
Task modelling
A manipulation planning domain will be considered to illustrate the task planning problem.
The domain describes the following predicates:
at: to determine if a given robot is at a given location;
handEmpty: to determine if the robot has no object on its gripper;
holding: to determine if the robot is holding a given object;
in: to determine if a given object is in a given location.
The domain describes the following actions:
move: a given robot moves either carrying an object or not;
pick: a given robot picks a given object, provided both are at the same location;
place: a given robot places, at its current location, the object it is carrying.
The PDDL file defining these predicates and actions is the manipulationdomain.pddl file listed below:
(define (domain manipulation)
(:types obstacle robot location)
(:predicates
(at ?rob ?from)
(handEmpty)
(holding ?rob ?obs)
(in ?obs ?from))
(:action move
:parameters (?rob - robot ?from - location ?to - location)
:precondition (at ?rob ?from)
:effect (and (at ?rob ?to)
(not (at ?rob ?from))
)
)
(:action pick
:parameters (?rob - robot ?obs - obstacle ?from - location)
:precondition (and (handEmpty)
(in ?obs ?from)
(at ?rob ?from)
)
:effect (and (holding ?rob ?obs)
(not (handEmpty))
)
)
(:action place
:parameters (?rob - robot ?obs - obstacle ?from - location)
:precondition (and (holding ?rob ?obs)
(at ?rob ?from)
)
:effect (and (handEmpty)
(in ?obs ?from)
(not (holding ?rob ?obs))
)
)
)
Different problems have been set, using this manipulation domain, to move objects within two rooms in the Table_Rooms_R2 demo.
Each problem file must define the objects and the initial and goal states.
In the Table_Rooms_R2 demo the following objects have been defined:
room1, as a location
room2, as a location
objA, as an obstacle
Rob, as a robot.
In the manipulation_problem_A problem file, an initial state has been defined where Rob is in room1 and objA in room2, as well as a goal state where objA must be in room1:
(define (problem manip_objA)
(:domain manipulation)
(:objects
room1 room2 - location
objA - obstacle
Rob - robot
)
(:init
(at Rob room1)
(in objA room2)
(handEmpty)
)
(:goal
(in objA room1)
)
)
The Fast-Forward task planner package
The downward_ros package has been implemented to provide a ROS shell to the Fast Downward suite of heuristic-based task planers. The FF task planner will be used.
The downward_ros package contains two ROS2 nodes:
The downward_server_node that offers the service called downward_service that returns a solution plan (computed with the FF task planner) corresponding to the planning domain and problem files sent as a request.
The downward_client_node that is used to test the server with PDDL files available at the folder examples/pddl_examples of the downward_ros2 package. The default test example is from the blocksworld domain using pickup, putdown, stack, unstack actions.
The .srv file describing the request and response is:
string problem
string domain
string evaluator
string search
---
bool response
string[] plan
problem and domain are the PDDL problem and domain files, and evaluator and search are the Downward arguments. If they are left void, then the parameters for the FF are set, i.e.:
evaluator = “hff=ff()”
search = “lazy_greedy([hff], preferred=[hff])”
A launch file has been created to launch the server. Optionally a client node could be run using the same launch with the test argument set to true:
ros2 launch downward_ros2 downward_service.launch.py test:=true
The downward_client calls the service both using Fast-forward (FF) and context-enhanced additive heuristic (CEA) options. The solution, printed in the terminal is: [‘PICKUP OBJB’, ‘STACK OBJB OBJA’]
The PDDL domain and problem files can be changed with the arguments domain and problem passed to the testing client node in the launch file, where the arguments must be relative to the examples/pddl_examples/ folder:
ros2 launch downward_ros2 downward_service.launch.py test:=true domain:=domains/block_world problem:=problems/block_world_2
EXERCISE 1
Test the task planner with other domain and problem files (the folder examples/pddl_examples of the downward_ros2 package contains several examples, as well as the folder ktmpb_demos/OMPL_geometric_demos/Table_Rooms_R2/ff-domains of the ktmpb package).
>>> EXERCISE 1.1
Launch the server and client nodes with different *domain* and *problem* arguments to obtain the task plans solutions.
>>> EXERCISE 1.2
Repeat for the *blocks_world* domain by creating two new problems involving three objects and different initial and goal states.
Note: New files should be created in the examples/pddl_examples/ folder. Remember to build the workspace again before launching.
Motion Planning
The purpose of this section is to demonstrate and validate the ROS2 interface of The Kautham Project through kautham_ros, by executing and testing motion planning queries, managing problems and visualizing results in RViz.
The kautham_ros package
The ROS2 kautham_ros node offers a comprehensive set of services designed to facilitate interaction with The Kautham Project. These services cover various aspects of robot motion planning, including problem management, environment and robot configuration, query setting, planner customization, and visualization in RViz.
Additionally, all these functionalities are accessible via a Python library that encapsulates the ROS2 service calls, enabling flexible scripting and automation. This functionality is provided in the file kautham_ros/kautham_ros/kautham_ros_interface_python.py.
For a detailed description of all available services and usage guidelines, please refer to the following sections:
Kautham ROS interface details: The ROS interface
Kautham ROS Python interface details: The Python interface
To test the services, the client node kautham_ros/scripts/kautham_ros_client_python_node.py uses these functions to open a problem, solve a query, attach and detach an object, etc.
This tutorial is done using the OMPL_geometric_demos/chess_ur3_robotiq/OMPL_RRTConnect_chess_ur3_gripper_2_simple.xml problem file as a base. First use the GUI to load and solve the problem:
To test the kautham_ros package, launch the following launch file. It will open the kautham_ros_node that offers the different services.
ros2 launch kautham_ros kautham_ros_node.launch.py
Then, in a different terminal, run the client node, which will solve the OMPL_RRTConnect_chess_ur3_gripper_2_simple.xml problem and call other services from the node.
kautham_ros_client_python_node.py
Note: If kautham has been installed in a different location than the default one, you can open the demo by giving it the following arguments:
Path to your scenario folder
Path to your demo folder
Path to your kautham problem file
kautham_ros_client_python_node.py /home/users/user.name/ws_tamp/src/task_and_motion_planning2/ktmpb/ktmpb_demos/OMPL_geometric_demos/chess_ur3_robotiq /home/users/user.name/ws_tamp/src/kautham_demos/kautham_demos/models OMPL_RRTConnect_chess_ur3_gripper_2_simple.xml
EXERCISE 2
>>> EXERCISE 2.1
Browse the *kautham_ros_client_python_node.py* file in the *kautham_ros* package to analyze the functions that wrap the calls to the *kautham_ros_node* services.
>>> EXERCISE 2.2
Modify the *kautham_ros_client_python_node.py* file to solve the motion planning problem using a PRM planner (using the *kSetPlannerByName* function) and *colcon build* again.
Task And Motion Planning (TAMP)
In this section a TAMP modelling XML file is introduced as an intermediate layer to flexibly configure the linking between the task and motion planning layers. Then different problem instances are defined to show the coupling that exists between the task and the motion planning levels.
TAMP Modelling
An XML file structure has been defined to link the symbolic information with the geometric one, enabling automatic processing of the task plan obtained by the FF planner and the use of Kautham to generate paths for executing each action in the plan.
This file structure includes the following main tags:
<Problemfiles>: specifies the locations of the relevant files, including:
The Kautham problem filename.
The PDDL domain and problem filenames.
And a placeholder for the GraspIt file (DEPRECATED).
<States>: contains the initial configurations for the scene, including obstacle poses given in axis-angle format and robot configurations defined with Kautham controls. If they are not set, the initial query of the Kautham Problem file is used as initial state.
<Actions>: details how to execute each symbolic action in the plan, including:
The robot and robot link involved.
The kautham control file used to actuate the robot.
Kautham control values defining the home and grasping configurations.
The object to be attached or detached during the action.
As an example, the ktmpb/ktmpb_demos/OMPL_geometric_demos/Table_Rooms_R2/tampconfig_a.xml file combines these elements to describe pick, place, and move actions for a robot within specified regions, with control values and object references matching the files specified above.
<?xml version="1.0"?>
<Config>
<Problemfiles>
<kautham name="OMPL_RRTConnect_table_rooms_R2_a.xml" />
<pddldomain name="ff-domains/manipulationdomain.pddl" />
<pddlproblem name="ff-domains/manipulation_problem_A" />
</Problemfiles>
<States>
<!-- You can set a different instance of the problem by modifying the intial object poses-->
<!-- The GraspControls will be to be changed accordingly the new intial object poses-->
<!-- (be careful: if the objects change their initial room then also the pddl problem file has to be set accordingly) -->
<Initial>
<Object name="OBJA" kthname="bigbox"> 20 70 40 1 0 0 0 </Object> <!-- orientation in axis-angle (vx,vy,vz,theta) like in the kautham problem files-->
<Robot name="ROB" controlfile="controls/table_R2.cntr"> 0.9 0.1 </Robot>
</Initial>
</States>
<Actions>
<Pick robot="ROB" object="OBJA" region="ROOM2">
<Rob> table </Rob> <!-- Index of the robot according to the order in the kautham problem file-->
<Obj> bigbox </Obj> <!-- Index of the object according to the order in the kautham problem file-->
<Link> base </Link> <!-- Index of the robot link -->
<Cont>controls/table_R2.cntr</Cont> <!-- Control set-->
<HomeControls>0.31 0.67</HomeControls> <!--Controls that define the home robot configuration at this 'region'-->
<GraspControls grasp="1">0.6 0.8</GraspControls> <!--Controls that define the grasp configuration'-->
</Pick>
<Place robot="ROB" object="OBJA" region="ROOM1">
<Rob> table </Rob>
<Obj> bigbox </Obj>
<Cont>controls/table_R2.cntr</Cont>
<HomeControls>0.31 0.31</HomeControls>
<GraspControls grasp= "1"> 0.9 0.1</GraspControls>
<!--Poseregion> 0.1 0.0 0.15 0.3 0 0 0 0 </Poseregion-->
</Place>
<Move robot="ROB" region_from="ROOM1" region_to="ROOM2">
<Rob> table </Rob>
<Cont> controls/table_R2.cntr </Cont>
<InitControls> 0.31 0.31</InitControls>
<GoalControls> 0.31 0.67</GoalControls>
</Move>
<Move robot="ROB" region_from="ROOM2" region_to="ROOM1">
<Rob> table </Rob>
<Cont> controls/table_R2.cntr </Cont>
<InitControls> 0.31 0.67</InitControls>
<GoalControls> 0.31 0.31</GoalControls>
</Move>
</Actions>
</Config>
Multiple problem instances exist within the specified directory path, combining different PDDL problem files such as manipulation_problem_A, manipulation_problem_B, and manipulation_problem_AB with corresponding Kautham problem definitions like OMPL_RRTconnect_table_rooms_R2_a.xml, OMPL_RRTconnect_table_rooms_R2_b.xml, and others. These illustrate various configurations showcasing the interaction between the task and motion planning layers.
The small cube is called objB and the big cube objA:
TAMP Manager Node
The ktmpb_client package includes a ROS node that manages both the task and motion planning services provided by the downward_ros and kautham_ros packages, respectively.
The workflow first uses the downward_ros services to find a task plan to solve the problem. Then, kautham_ros computes the geometric paths needed to execute each action in the plan. This includes:
Attaching and detaching objects as required by pick and place actions.
Moving the robot to predefined positions, such as towards the middle of the room facing the door after placing an object, as specified at the beginning of the tutorial.
To launch the system, run:
ros2 launch ktmpb_client ktmpb_full.launch.py models_folder_path:=[path/to/the/models/folder] scenario_folder_path:=[path/to/the/Table_Rooms_R2/scenario/folder] tamp_config_filename:=tampconfig_a.xml
This launch file sets up the following nodes:
kautham_ros_node (motion planning server)
downward_server_node (task planning server)
ktmpb_manager_node (TAMP client manager), which receives the configured paths and handles coordination.
The parameters that need to be specified as launch arguments are:
models_folder_path: Absolute path where Kautham will look for the model files. If in the ETSEIB computers, it should be at /usr/share/kautham/demos/models.
scenario_folder_path: Absolute path of the scenario folder. ALL files that are referenced inside the Kautham Problem file and the TAMPConfig file, excluding models, have to be referenced relative to the scenario_folder_path. - For example, in the Table_Rooms scenario, the pddl files are inside the ff-domains subfolder, so they are written as <pddldomain name=”ff-domains/manipulationdomain.pddl”/> in the .xml.
tamp_config_filename: name of the tampconfig file. It must be located inside the scenario folder.
[Optional] rviz_config_filename: configuration file for RViz. The demos have examples of these files on the /rviz subfolder. Note: some demos use .iv files for the 3D models, which have issues appearing in RViz. In these cases, the models will not appear but the tf frames of each frame will.
Output: Task solution file
When the launch completes, the resulting transit and transfer robot paths are saved in a taskfile XML named taskfile_[tamp_config_filename].xml in the same folder as the TAMP modelling XML. This file contains sequence configurations and object transfers in XML format, such as:
<?xml version="1.0"?>
<Task name="OMPL_RRTConnect_table_rooms_R2_a.xml">
<Initialstate>
<Object object="bigbox"> 20.0 70.0 40.0 1.0 0.0 0.0 0.0 </Object>
</Initialstate>
<Transit>
<Conf> ... </Conf>
...
</Transit>
<Transfer object="bigbox" robot="table" link="base">
<Conf> ... </Conf>
...
</Transfer>
...
</Task>
This taskfile allows offline visualization of the plan using the kautham-gui application. To visualize:
Open kautham-gui and load the problem file OMPL_RRTConnect_table_rooms_R2_a.xml.
In the planner tab, click “Load Task File” and select taskfile_tampconfig_a.xml.
Press “Start move” to execute the plan visualization step-by-step.
EXERCISE 3
Test for other problems:
>>> EXERCISE 3.1
Test problem manipulation_problem_B by setting tamp_config_filename:=tampconfig_b.xml
Test problem manipulation_problem_B by setting tamp_config_filename:=tampconfig_ab.xml
>>> EXERCISE 3.2
Repeat for problem manipulation_problem_BA with geometry OMPL_RRTConnect_table_rooms_R2_ba.xml, that considers the position of the objects interchanged.
What is happening?
Improve the domain and the problem definition to take into account that:
An object cannot be picked if the other object is blocking its path. This has to be considered in the precondition of the pick action.
After moving the blocking object it no longer precludes the pick action of the other object. This has to be considered in the effects of the place action.
>>> EXERCISE 3.3
Modify the domain and problem files (call them manipulationdomain_modified.pddl and manipulation_problem_AB_modified).
They should use a predicate called 'iscritical', with two objects as arguments, to assert that the first one is critical for the second one (i.e. it is blocking it) and therefore should be manipulated first.
Hint1: Conditional effects should be used in the place action. See Planning Domains and Problem Instances in PDDL. This needs the declaration of the :adl requirement.
Hint 2: The same object may not instantiate two parameters of an action; the equality predicate could be used in the precondition to avoid this. The use of the equality predicate needs the declaration of the :equality requirement.
You can find the solution of this exercise here.
Manipulation Planning
This section presents manipulation planning capabilities demonstrated through a variety of robotic setups. It focuses on how robots can perform fundamental manipulation actions — moving through the environment, picking up objects, and placing them at desired locations. These demonstrations highlight the integration of task-level planning with geometric motion planning to solve practical robot manipulation problems.
Manipulation demos
Some demonstration scenarios featuring fixed and mobile manipulators have been prepared. These demos utilize three fundamental actions: MOVE, PICK, and PLACE.
For example, the Tiago-kitchen problem involves the Tiago robot, a mobile manipulator operating within a simulated kitchen environment.
To execute the demo, run the following command:
ros2 launch ktmpb_client ktmpb_full.launch.py models_folder_path:=[path/to/the/models/folder] scenario_folder_path:=[path/to/Tiago/scenario/folder] tamp_config_filename:=tampconfig_tiago_kitchen.xml
Visualization with RViz
Optionally, the ktmpb interface can be run in paralel with an RViz instance that will reproduce the movements that the motion planner calculates concurrently. To run the demos with RViz, the same launch file is run using the additional rviz_config_filename parameter. The .rviz configuration file needs to be located inside the scenario folder.
ros2 launch ktmpb_client ktmpb_full.launch.py models_folder_path:=[path/to/the/models/folder] scenario_folder_path:=[path/to/Tiago/scenario/folder] tamp_config_filename:=tampconfig_tiago_kitchen.xml rviz_config_filename:=rviz/kautham_tiago_kitchen.rviz
With the .rviz configuration, RViz will be opened. The .rviz files included in the demos have already been configured to show the scenarios properly. To visualize different scenarios, follow the instructions in Visualizing Kautham in RViz
RViz vs Taskfile: The ktmbp interface will always generate a taskfile as a solution to a TAMP problem. This taskfile can be then visualized in the Kautham GUI as many times as necessary. Several taskfiles can be saved for different TAMP problems, for instance. On the other hand, the current implementation of RViz visualization runs step by step with the solving of the TAMP problem, and is not stored anywhere.
Note: RViz is an external tool to Kautham, and the current implementation of visualization may be unstable on some demos depending on the models used. For the final project, RViz implementation is *optional*, as it is a feature that is still experimental.
EXERCISE 4
>>> EXERCISE 4.1
Examine the PDDL files included in the *ktmpb_demos* package to familiarize yourself with their structure and content.
>>> EXERCISE 4.2
Review the *tampconfig_tiago_kitchen.xml* file from the Tiago-kitchen demo, noting that different control files are employed for various actions.
Understand the reasons for using these different control files. Finally, execute the demo and verify it works as expected.
>>> EXERCISE 4.3
Repeat the previous exercise for the UR3 chess demo by selecting the *tampconfig_chess_1_simple.xml* file in the launch file.
>>> EXERCISE 4.4
Repeat similarly for the YuMi demo by selecting the *tampconfig_chess_1_simple.xml* file in the launch file
EXERCISE 5
Manipulation problems can be customized easily by modifying the data in the TAMP configuration file. To do this:
Change the initial object poses in the <States> section of the TAMP configuration file and update the corresponding <Graspcontrols> in the PICK action accordingly.
Adjust the placement poses by modifying the <Graspcontrols> parameters in the PLACE action.
Be cautious to update the symbolic initial state definition in the PDDL problem file if the new geometric initial data differ, ensuring consistency between symbolic and geometric representations.
>>> EXERCISE 5.1
Define a new manipulation problem using customized grasp configurations.
Defining new actions
In order to expand the type of tasks that a manipulator can do, new actions can be defined.
As a way to illustrate how to define new actions, the chess demo has been modified to include a DUMMY action.
The files involved are:
tampconfig_chess_1_simple_dummy.xml: The tampconfig file includes the definition of the parameteres related to the new action.
<Dummy robot="UR3A" parameter1="D1" parameter2="D2"> <Rob> ur3_right </Rob> <!--Optional, but usually needed if the action involves the robot --> <Cont>controls/right_ur3_with_gripper.cntr</Cont> <!--The controls to move the robot if a tag Rob exists --> <DummyTag> Dummy_tag_value </DummyTag> <!-- Enter the tags with the info needed for the action --> <DummyMultiEntryTag multientrytagname = "dummy_1"> 1.0 2.0 3.0 </DummyMultiEntryTag> <!-- Multy entry tags are also possible --> <DummyMultiEntryTag multientrytagname = "dummy_2"> -1.0 -2.0 -3.0 </DummyMultiEntryTag> <!-- Multy entry tags are also possible --> </Dummy>
chessmanipulationdomain_dummy.pddl: The PDDL domain file includes the new dumyparam type, the new dummyCalled predicate and the new action dummy (to complement the pcik and place actions).
(:types obstacle robot location dummyparam) (:predicates (handEmpty ?rob) (holding ?rob ?obs) (in ?obs ?from) (dummyCalled ?rob ?param1 ?param2) ) (:action dummy :parameters (?rob - robot ?param1 - dummyparam ?param2 - dummyparam) :precondition (not (dummyCalled ?rob ?param1 ?param2)) :effect (dummyCalled ?rob ?param1 ?param2) )
manipulation_problem_chess_dummy: The PDDL problem file includes two objects of type dummyparam and the init and goal of the problem used the predicate dummyCalled.
(:objects pos1 pos2 - location pawnB1 - obstacle ur3a - robot d1 d2 - dummyparam ) (:init (in pawnB1 pos1) (handEmpty ur3a) (not (dummyCalled ur3a d1 d2)) ) (:goal (and (in pawnB1 pos2) (dummyCalled ur3a d1 d2) ) )
DUMMY.py: This file is where the action is actually defined. This DUMMY action just prints the parameters that appear in the tampconfig file and calls Kautham to get the configuration of the robot.
Two functions are coded in this file, DUMMY and Dummy_read:
Function for the management of the action on the task plan:
def DUMMY(node, dummy,info,Line):Function to read the tampconfig file with the parameteres of the action:
def Dummy_read(action_element):
ktmpb_python_interface.py: In this file the DUMMY.py is imported.
import MOVE, PICK, PLACE, DUMMY
A new action can also involve only the modifications of the PDDL and tampconfig files and reuse any of the other action descriptions, e,g, we may have a new move action that involves different preconditions but the actual action is a move described in the MOVE.py file. In this case steps 3 and 4 below are not necessary.
Check the chess demo with the DUMMY action added:
ros2 ros2 launch ktmpb_client ktmpb_full.launch.py models_folder_path:=[path/to/the/models/folder] scenario_folder_path:=[path/to/chess_ur3_robotiq/scenario/folder] tamp_config_filename:=tampconfig_chess_1_simple_dummy.xml
As a summary, to define a new action (MYACTION) you need to:
Include the action in the tampconfig file that will use it.
Define the PDDL domain and problem files with the new predicates and the new action.
Code the file MYACTION.py with the functions:
def MYACTION(node, myaction,info,Line):def Myaction_read(action_element):- Add the action to the list of imported actions in the ktmpb_python_interface.py file:
import MOVE, PICK, PLACE, DUMMY, MYACTION
Create a launch file with the problem using the new action.
Enjoy!