ROS2 Planning System (plansys2 in short) is a project whose objective is to provide Robotics developers with a reliable, simple, and efficient PDDL-based planning system. It is implemented in ROS2, applying the latest concepts developed in this currently de-facto standard in Robotics.

This project is the result of several years of experience in the development of robotic behaviors using ROSPlan. ROSPlan has greatly inspired this project. In addition to the migration to ROS2, we contribute to key aspects: ease of use, efficiency, and new tools, such as our terminal.

We hope that this software helps to include planning in more Robotics projects, offering simple and powerful software to generate intelligent behaviors for robots.

We want to invite you to contribute to this Open Source project !!

Design

4 ROS2 nodes compose Plansys2: - Domain Expert: Contains the PDDL model information (types, predicates model, and actions). It is static and can be queried using services or a Domain Expert Client, that hides the ROS2 services complexity. - Problem Expert: Contains the current instances, predicates, and goals that compose the model. It is dynamic and volatile. It can be queried/modified using services or a Problem Expert Client, that hides the ROS2 services complexity. It uses a topic (std_msgs::msg::Empty) to notify when it changes. - Planner: Generates plans (sequence of actions) using the information contained in the Domain and Problem Experts. - Executor: Takes a plan and executes it by calling (using actions) the ROS2 nodes that implement each action. It verifies that requirements are accomplished during execution.

The Terminal is a plansys2 util for operating with the above components.

To make an application using plansys2, you must provide a PDDL model, the implementation of the actions in this model, and an application in charge of setting the starting instances and predicates. It can set goals and call to the executor to achieve these goals. Actions are easy to develop using the ActionExecutorClient class.

Another exciting feature of Plansys2 is the possibility of having several instances of Plansys2 running independently at the same time, in different namespaces. Each instance of Plansys2 can run different PDDL models. This feature lets you have independent or hierarchical planning in the same application.

Requirements and compilation

This project was initially developed for ROS2 Eloquent. In addition to official packages, plansys2 requires popf, a PDDL plan solver, developed by Marc Hanheide, to which we have contributed to its migration to a ROS2 package.

Before compiling, install popf and include cascade_lifecycle in your workspace (or install from deb packages when available):

plansys2_ws/src$ sudo apt-get install ros-eloquent-popf
plansys2_ws/src$ git clone http://github.com/fmrico/cascade_lifecycle.git

Next, only compile:

plansys2_ws$ colcon build --symlink-install

Example

In this example, the robot make plans to patrol some waypoints:

Further readings

• PDDL basics 1, 2 and 3
• Developers Guide
• Tutorials
• FAQ

Contribution Guidelines

As an open-source project, we welcome and encourage the community to submit patches directly to the ROS2 Planning System (Plansys2). In our collaborative open source environment, standards and methods for submitting changes help reduce the chaos that can result from an active development community.

This document explains how to participate in project conversations, log and track bugs and enhancement requests, and submit patches to the project so your patch will be accepted quickly in the codebase.

Licensing Licensing is very important to open source projects. It helps ensure the software continues to be available under the terms that the author desired.

Contributions should be made under the predominant license of that package. Entirely new packages should be made available under the Apache 2.0 license.

A license tells you what rights you have as a developer, as provided by the copyright holder. It is important that the contributor fully understands the licensing rights and agrees to them. Sometimes the copyright holder isn’t the contributor, such as when the contributor is doing work on behalf of a company.

Developer Certification of Origin (DCO)

To make a good faith effort to ensure licensing criteria are met, ROS2 Planning System requires the Developer Certificate of Origin (DCO) process to be followed.

The DCO is an attestation attached to every contribution made by every developer. In the commit message of the contribution, (described more fully later in this document), the developer simply adds a Signed-off-by statement and thereby agrees to the DCO.

When a developer submits a patch, it is a commitment that the contributor has the right to submit the patch per the license. The DCO agreement is shown below and at http://developercertificate.org/.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the
    best of my knowledge, is covered under an appropriate open
    source license and I have the right under that license to
    submit that work with modifications, whether created in whole
    or in part by me, under the same open source license (unless
    I am permitted to submit under a different license), as
    Indicated in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including
    all personal information I submit with it, including my
    sign-off) is maintained indefinitely and may be redistributed
    consistent with this project or the open source license(s)
    involved.

DCO Sign-Off Methods

The DCO requires that a sign-off message, in the following format, appears on each commit in the pull request:

Signed-off-by: Sofforus Jones <sjones@gmail.com>

The DCO text can either be manually added to your commit body, or you can add either -s or --signoff to your usual Git commit commands. If you forget to add the sign-off you can also amend a previous commit with the sign-off by running git commit --amend -s. If you’ve pushed your changes to GitHub already you’ll need to force push your branch after this with git push -f.

Note: The name and email address of the account you use to submit your PR must match the name and email address on the Signed-off-by line in your commit message.