ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

ROS2 Planning System 1st Anniversary

Dear ROS Developers,

ROS2 Planning System (PlanSys2 in short) celebrates these days its first anniversary :partying_face: :birthday: :champagne:

It has been one year of intense development to which some contributors have joined this project. Along this year we have included many new improvements:

  • A new Web Page with videos, tutorials, and design documents.
  • New examples.
  • New solvers, like Temporal Fast Downward, apart of the default POPF, and the possibility of using your own PDDL planner as a plugin.
  • Parallel execution of plans.
  • Real multirobot execution.
  • New Repo CI with Github actions and codecov, and more tests.
  • Possibility of implementing actions as Behavior Trees.

It works in Eloquent (source and bin packages) and Foxy (source and coming packages in next Foxy sync, I hope)

Happy Planning!!!


Am I the only one who could use a better description of what this is useful for? Is it primarily for navigation or can you use it for task planning as well?

I mean, text like this doesn’t help me much if I don’t know what the acronyms mean:

This package contains a plan solver that uses popf for solving PDDL plans.

Another question – is the planner capable of learning/adapting over time?

I ask because MoveIt is starting to look for functionality like this. (@felixvd)

Hi @AndyZe

You are probably right. I’ve been swamped coding and writing documentation, and there may be some descriptions that are not very accurate. Sorry for that :sweat:. Perhaps it is interesting that some native English speaker (unfortunately, I am not) wants to contribute to PlanSys2 by reviewing the documentation, especially these descriptions :wink:

For answering you, POPF is a popular PDDL plan solver, but not everyone indeed has to know about it, and I should provide more context. The first video on the web page also tries to present the problem we want to solve with PlanSys2.

In classical planning, the use of learning is not straightforward. It would be exciting to address it. It does not seem that there are many scientific works in this line, but I find it an exciting topic. May I know what you have in mind? :slightly_smiling_face:

Thanks for your comments. They are very valuable.

1 Like

Is it primarily for navigation or can you use it for task planning as well?

AFAICT, it does task planning.

The explainer video shows describing a problem domain (eg. current world state, goal world state and action with their their effects on the world) and can generate a eg. behavior tree that makes the robot achieve the goal world state.

PDDL is a Planning Domain Definition Language. I’m not familiar with what POPF is exactly.

1 Like

I am actually very interested in task + motion planning for manipulation tasks, since I know that PDDL and classical planning has strong applications, but I find it very hard to find my bearings and apply anything. It certainly feels like I am not the alone with the difficulty - most projects I find are very abstract or focused on theoretical methods (e.g., FastDownward, PDDLStream) that are hard to grok for me, or provide only toy problems. And I mean no offense at all, but I think I have to count PlanSys2 among the latter. An added difficulty with the former is that a lot of it is GPL-licensed and poses an infection risk.

My biggest question marks are A) how to convert a real world scene to a PDDL problem in a useful way, B) make sure the symbolic plan is executable (this is not trivial for any manipulation task) and C) what to do when a step turns out to be infeasible or fails.

I was thinking about learning a heuristic to use in the PDDL search, somewhat like this.

TMKit sounds very relevant, but I can’t tell if it is worth attempting a ROS bridge. If there was a way to convert a MoveIt scene to it or a ROS interface, I would be inclined to try it out. Does anyone have experience with it?

Also, have you considered symbolic planning like this in the context of MoveIt Task Constructor @rhaschke @v4hn ?

Multiple people here seem to be interested in Task and Motion Planning (TAMP/TMP).
It’s a relatively big research field with many approaches/contributions.
As a recent example, RSS20 featured an interesting workshop on TAMP & Learning. As you can see from the talks it’s a rather open field people are actively looking into.

Traditionally, the symbolic reasoning side often views TAMP as a particularly difficult instance of SMT Planning, and the motion planning side might argue it’s a motion planning problem with an unknown plan skeleton. Both perspectives have their merits.

My biggest question marks are A) how to convert a real world scene to a PDDL problem in a useful way, B) make sure the symbolic plan is executable (this is not trivial for any manipulation task) and C) what to do when a step turns out to be infeasible or fails.

Traditionally, this is hand-crafted since Shakey’s time.
With the advent of complex knowledge graphs/ontologies, researchers looked more into generating planning descriptions (or even just inferring goal conditions for a known domain) on the basis of ontologies. The KnowRob system, developed under Michael Beetz, is a prime example of this approach. It still remains a hard problem to keep the domains consistent and provide enough information to produce the desired outcomes. That being said, with a lot of engineering effort it can produce impressive results.
A quite neat combination that generates planning domain facts from perceived scenes can be found in Chris Paxton’s research (they also gave a talk at the workshop I linked). They employ learning-based systems to generate domain facts from camera input.

If you look into SMT problem solvers, they discriminate between eager and lazy solvers.
The latter approach is quite straightforward: you find a symbolic plan that’s valid according to your planning domain and then attempt to solve the resulting problem with a dedicated solver (in this case a motion planner). MP solvers are notoriously anytime algorithms, so you either end up with an incomplete TAMP solver or a complex anytime system.
Eager approaches try to encode everything relevant about the problem in the planner itself.
Some people try this with TAMP by encoding predicates like reachability directly. In practice though, they either have to come up with geometric heuristics for it, or they have to solve the MP problem to reach the object under the hood. Viewing the problem from the motion planning side, “making sure the plan is executable” is not a problem at all because they only consider executable trajectories. But they fight with many more local minima that way.
A noteworthy example that comes from the motion-planning side, but combines it with logic inference is Logic-Geometric Programming introduced by Marc Toussaint.

That’s recovery behavior and approaches differ (of course they do).
For repeatable actions, you can try again. But how often should you retry before giving up trying to push the damn button?
The obvious choice is plain replanning. In practice you might end up with long delays and oscillating behavior though.
Some projects introduced repair techniques that, e.g., attempt to instantiate an assumed object that’s not found with a different object that might be around (“just use a different glass then”).

Also, have you considered symbolic planning like this in the context of MoveIt Task Constructor?

If you read the introduction to our ICRA19 paper you see that MTC aims for a middle ground.
The goal of the framework is not to solve general TAMP problems, but to provide a systematic structure for tasks more general than A-to-B Motion Planning, but easier than “I want to drink something”. The main reason for this ambition is that general TAMP solvers can generate unexpected robot behavior. That might be exactly what you want it to do to show adaptive behavior, but it might also break your beautiful workflow & demo if the system suddenly decides to use a different tool. Tuning TAMP solvers to generate only solutions you actually consider valid is quite hair-raising at times.

That being said, MTC could theoretically be used as a lazy domain solver in an SMT setting, but it would be a lot of work.

Hope that answers your seemingly simple question :slight_smile:


No, MoveIt Task Constructor doesn’t aim for symbolic planning. Did you have a look into Marc Toussaint’s RAI framework? This allows for symbolic-level planning combined with geometric planning.

1 Like

Thanks for the detailed and comprehensive response and sharing your experience @v4hn :slight_smile: Jeanette’s talk in that RSS workshop is one of my favorite videos from 2020.

Actually I even signed up for the mailing list back in 2018, but it died out quickly. I ended up never testing it properly, since the startup cost for these methods is so high (I estimate several person-weeks, if not person-months). It might have been like KnowRob for me in that respect – it looks promising and powerful and makes sense from what little you can read through (or what little you understand), but it’s hard to judge how much you will be really be able to do with it. As v4hn said (confirming my suspicion), it can take a lot of engineering to get somewhere.

It’s true that one can read this as me whining about a lack of turnkey solutions, but I think I’m not alone with this difficulty.

It’s part of the reason why I brought up supplying previous solutions to MTC tasks – it would save replanning when a symbolic plan is invalid. We are playing around with the idea, so hit me up by email if you want to get into the details :slight_smile: