Is it possible to use ROSPlan to control al robot in a non fully-observable world?

72 views
Skip to first unread message

Jorge Santos Simón

unread,
Feb 20, 2020, 8:35:43 AM2/20/20
to ROSPlan
Hi!

ROSPlan looks very interesting as a tool to produce complex high-level behavior on robots. But I don't see how to implement tasks involving elements not known by the robot in advance. For example, a robot that explores its environment and collects all the objects of a given type he finds and brings to "home". If he knows where all the objects are at planning time, that would be relatively easy, accomplished with actions like move_to, pick, place and so. But if he must explore the world and pick objects as he finds them, I have no idea how to encode that in PDDL. I know I can update the knowledge base at runtime, by adding facts as I discover objects, and retrigger the planner. But if I state from the beginning that my goal is to gather all objects of a kind (let's imagine I know how many there are in advance), the planner will never succeed until I add ALL the objects to the knowledge base, what can only happen after exploring the whole environment. So the exploration cannot make part of the plan. Or alternatively, run the planner with different goals all the time, like "find object" if there's no object discovered (so only viable action is "explore"), or "object X in home" if robot have found object X. But all this sounds very convoluted and robbing all protagonism to the planning part.

All this kind of make sense? Or am I completely misguided? Or am I missing something important about using ROSPlan?


Side note:

I took a look at this paper about continuous planning with partial goals. Sounds like what I was looking for! But is it actually supported on ROSPlan? Combining both PDDL and RDDL domains sounds intimidating! (not to say that I have no idea about RDDL). Moreover, the PROST command help looks rather confusing to me:

Usage: ./prost <rddl-parser-output | rddl-problem-name> [PROST <options>]


What is parser-output?

Thanks a lot!  And sorry for the verbose comment...

Victor Paléologue

unread,
Feb 26, 2020, 11:02:33 AM2/26/20
to Jorge Santos Simón, ROSPlan
I used this approach in my thesis (being published), without ROSPlan, but with my own knowledge base and with the fast-downward planner.
For every change happening in the world, the PDDL content (or RDDL for you) was updated, and a new plan was evaluated.
It worked fine, even though it was quite CPU consuming, and the robot adapted its behavior to the new information coming in.
For me this is a promising approach, and can be used for Human-Robot Interaction.

This is also what they recommend to do in this wiki page of PDDL4J: https://github.com/pellierd/pddl4j/wiki/Automated-planning-in-a-nutshell



Then, to explore, you invoke the possibility of your exploration action to make a virtual object "object_to_discover" to appear in your surroundings. If your goal involves the discovery of the virtual object, you can trigger the exploration action. Then your exploration action leads to observing a real object, that changes the state of your world, from which you can plan again.


--
You received this message because you are subscribed to the Google Groups "ROSPlan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rosplan+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rosplan/2c164722-a584-48b6-9f4d-da33a01fd5f1%40googlegroups.com.

This email and any attachment thereto are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient, please be advised that disclosing, copying, distributing or taking any action in reliance on the contents of this email is strictly prohibited. In such case, please immediately advise the sender, and delete all copies and attachment from your system.
This email shall not be construed and is not tantamount to an offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe on any discussion or contractual document whatsoever. No employee or agent is authorized to represent or bind SoftBank Robotics Europe to third parties by email, or act on behalf of SoftBank Robotics Europe by email, without express written confirmation by SoftBank Robotics Europe’ duly authorized representatives.


Ce message électronique et éventuelles pièces jointes sont confidentiels, et exclusivement destinés à la personne ou l'entité à qui ils sont adressés.
Si vous n'êtes pas le destinataire visé, vous êtes prié de ne pas divulguer, copier, distribuer ou prendre toute décision sur la foi de ce message électronique. Merci d'en aviser immédiatement l'expéditeur et de supprimer toutes les copies et éventuelles pièces jointes de votre système.
Ce message électronique n'équivaut pas à une offre, à une acceptation d’offre, ou à un accord de SoftBank Robotics Europe sur toute discussion ou document contractuel quel qu’il soit, et ne peut être interprété comme tel. Aucun employé ou agent de SoftBank Robotics Europe n'est autorisé à représenter ou à engager la société par email, ou à agir au nom et pour le compte de la société par email, sans qu’une confirmation écrite soit donnée par le représentant légal de SoftBank Robotics Europe ou par toute autre personne ayant reçu délégation de pouvoir appropriée.

Jorge Santos Simón

unread,
Feb 27, 2020, 11:04:33 AM2/27/20
to ROSPlan
Hello Victor, and thanks for your response.
Essentially, it confirms my supposition: that I need another logic layer on top of ROSPlan that keeps changing planner goal:

 "object_to_discover"  -->  "pick_discovered_object_X" --> "object_to_discover"  -->  "pick_discovered_object_Y" -->  and so on

every time a "subplan" is completed. Moreover, X, Y, ... is a grounded fact, so I cannot even plan with a goal like "pick any discovered object", as goal declaration doesn't accept variables.

Or am I missing something?



On Thursday, February 27, 2020 at 1:02:33 AM UTC+9, Victor PALEOLOGUE wrote:
I used this approach in my thesis (being published), without ROSPlan, but with my own knowledge base and with the fast-downward planner.
For every change happening in the world, the PDDL content (or RDDL for you) was updated, and a new plan was evaluated.
It worked fine, even though it was quite CPU consuming, and the robot adapted its behavior to the new information coming in.
For me this is a promising approach, and can be used for Human-Robot Interaction.

This is also what they recommend to do in this wiki page of PDDL4J: https://github.com/pellierd/pddl4j/wiki/Automated-planning-in-a-nutshell



Then, to explore, you invoke the possibility of your exploration action to make a virtual object "object_to_discover" to appear in your surroundings. If your goal involves the discovery of the virtual object, you can trigger the exploration action. Then your exploration action leads to observing a real object, that changes the state of your world, from which you can plan again.


Le jeu. 20 févr. 2020 à 14:35, Jorge Santos Simón <jsanto...@gmail.com> a écrit :
Hi!

ROSPlan looks very interesting as a tool to produce complex high-level behavior on robots. But I don't see how to implement tasks involving elements not known by the robot in advance. For example, a robot that explores its environment and collects all the objects of a given type he finds and brings to "home". If he knows where all the objects are at planning time, that would be relatively easy, accomplished with actions like move_to, pick, place and so. But if he must explore the world and pick objects as he finds them, I have no idea how to encode that in PDDL. I know I can update the knowledge base at runtime, by adding facts as I discover objects, and retrigger the planner. But if I state from the beginning that my goal is to gather all objects of a kind (let's imagine I know how many there are in advance), the planner will never succeed until I add ALL the objects to the knowledge base, what can only happen after exploring the whole environment. So the exploration cannot make part of the plan. Or alternatively, run the planner with different goals all the time, like "find object" if there's no object discovered (so only viable action is "explore"), or "object X in home" if robot have found object X. But all this sounds very convoluted and robbing all protagonism to the planning part.

All this kind of make sense? Or am I completely misguided? Or am I missing something important about using ROSPlan?


Side note:

I took a look at this paper about continuous planning with partial goals. Sounds like what I was looking for! But is it actually supported on ROSPlan? Combining both PDDL and RDDL domains sounds intimidating! (not to say that I have no idea about RDDL). Moreover, the PROST command help looks rather confusing to me:

Usage: ./prost <rddl-parser-output | rddl-problem-name> [PROST <options>]


What is parser-output?

Thanks a lot!  And sorry for the verbose comment...

--
You received this message because you are subscribed to the Google Groups "ROSPlan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros...@googlegroups.com.

Victor Paléologue

unread,
Mar 3, 2020, 1:47:44 PM3/3/20
to ROSPlan


Le mar. 3 mars 2020 à 19:46, Victor Paléologue <victor.p...@softbankrobotics.com> a écrit :
It works here with fast-downward, but I needed to change the requirements to :adl, because some others were not supported.

I got this:
Solution found!
Actual search time: 0.000160928s [t=0.00237444s]
discover object_1 (1)
pick object_1 (1)

Trying planners around, I found that most of them had poor error reporting. Potentially POPF does not like one of the requirements but is not clear about it. Yes, that's frustrating...
Fast-downward on the other hand, was clear and told me about the problematic requirements.

Check this to see what :adl means: https://planning.wiki/ref/pddl/requirements#adl
Check this to get fast-downward: http://www.fast-downward.org/

Le mar. 3 mars 2020 à 17:14, Jorge Santos Simón <jsanto...@gmail.com> a écrit :
Hello Victor, and thanks a lot for your help.

Your solution sounds very reasonable, but I cannot make it work regardless whatever I try. Some obvious problems:

  • POPF doesn't support existential preconditions, so I must rewrite the goal with a grounded object
  • The  :precondition (not (is_reachable ?o)) prevents the use of discover action, but I don't understand why
All that said, here's my failed attempt:

DOMAIN

(define (domain exploration)

(:requirements :strips :typing :fluents
:disjunctive-preconditions :negative-preconditions
:durative-actions)

(:types object)

(:predicates
(is_reachable ?o - object)
(is_picked ?o - object)
)

(:action pick
:parameters (?o - object)
:precondition (is_reachable ?o)
:effect (is_picked ?o)
)

(:action discover
:parameters (?o - object)
:precondition (not (is_reachable ?o))
:effect (is_reachable ?o)
)
)

PROBLEM

(define (problem task)
(:domain exploration)

(:objects
object_1 - object)

(:init)

(:goal
(and
(is_picked object_1))
)
)

To my understanding, POPF should trivially solve this by calling discovery, then pick, but surprisingly he cannot find a solution!

I'm really puzzled. PDDL can get really frustrating, as there's no introspection on the planning process.

Again, thanks a lot for your help.

Jorge


On Fri, Feb 28, 2020 at 1:44 AM Victor Paléologue <victor.p...@softbankrobotics.com> wrote:
Yes, I think you're missing that you can avoid changing goals by adding another predicate.
If you distinguish between virtual objects and real ones with the fact that one cannot be physically reached, but the other can, then you can always mention this goal, even if it does not trigger an action.

Given:
(:types object)

(:predicates
  (is_reachable ?o - object)
  (is_picked ?o - object)
)

(:action pick
  :parameters ?o - object
  :precondition (is_reachable ?o)
  :effect (is_picked ?o)
)

(:action discover
  :parameters ?o - object
  :precondition (not (is_reachable ?o))
  :effect (is_reachable ?o)

(:objects
  object_to_discover - object)

(:init)

(:goal
  (and
    (exists (?o - object) (is_picked ?o))
)

For an object to be picked, it must be reachable. The discover action pretends that by running it will make the virtual object to discover to be reachable, so the planner runs it if nothing is around.
Then, by running the discover action, the state of the world gets updated when the robot actually finds an object.
In PDDL you end up with something like this:

(:objects
  object_to_discover object_1 - object)

(:init (is_reachable object_1))

When you run the planning again, with the same goal but with a different initial state, you get the robot to pick the object.


To unsubscribe from this group and stop receiving emails from it, send an email to rosplan+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rosplan/c19a0b64-bfc5-4876-a1cf-b5e9c56c5db6%40googlegroups.com.

This email and any attachment thereto are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient, please be advised that disclosing, copying, distributing or taking any action in reliance on the contents of this email is strictly prohibited. In such case, please immediately advise the sender, and delete all copies and attachment from your system.
This email shall not be construed and is not tantamount to an offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe on any discussion or contractual document whatsoever. No employee or agent is authorized to represent or bind SoftBank Robotics Europe to third parties by email, or act on behalf of SoftBank Robotics Europe by email, without express written confirmation by SoftBank Robotics Europe’ duly authorized representatives.


Ce message électronique et éventuelles pièces jointes sont confidentiels, et exclusivement destinés à la personne ou l'entité à qui ils sont adressés.
Si vous n'êtes pas le destinataire visé, vous êtes prié de ne pas divulguer, copier, distribuer ou prendre toute décision sur la foi de ce message électronique. Merci d'en aviser immédiatement l'expéditeur et de supprimer toutes les copies et éventuelles pièces jointes de votre système.
Ce message électronique n'équivaut pas à une offre, à une acceptation d’offre, ou à un accord de SoftBank Robotics Europe sur toute discussion ou document contractuel quel qu’il soit, et ne peut être interprété comme tel. Aucun employé ou agent de SoftBank Robotics Europe n'est autorisé à représenter ou à engager la société par email, ou à agir au nom et pour le compte de la société par email, sans qu’une confirmation écrite soit donnée par le représentant légal de SoftBank Robotics Europe ou par toute autre personne ayant reçu délégation de pouvoir appropriée.

Rohan Haseloff

unread,
Mar 4, 2020, 4:19:46 AM3/4/20
to ROSPlan
hey,

which planner are you using with that domain ?

as far as i know POPF doesn't support negative preconditions. Should work with FF. Otherwise change your discover action. Might be able to use the predicate (not_reachable ?o) then you would not need the negative preconditon.

This email and any attachment thereto are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient, please be advised that disclosing, copying, distributing or taking any action in reliance on the contents of this email is strictly prohibited. In such case, please immediately advise the sender, and delete all copies and attachment from your system.
This email shall not be construed and is not tantamount to an offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe on any discussion or contractual document whatsoever. No employee or agent is authorized to represent or bind SoftBank Robotics Europe to third parties by email, or act on behalf of SoftBank Robotics Europe by email, without express written confirmation by SoftBank Robotics Europe’ duly authorized representatives.


Ce message électronique et éventuelles pièces jointes sont confidentiels, et exclusivement destinés à la personne ou l'entité à qui ils sont adressés.
Si vous n'êtes pas le destinataire visé, vous êtes prié de ne pas divulguer, copier, distribuer ou prendre toute décision sur la foi de ce message électronique. Merci d'en aviser immédiatement l'expéditeur et de supprimer toutes les copies et éventuelles pièces jointes de votre système.
Ce message électronique n'équivaut pas à une offre, à une acceptation d’offre, ou à un accord de SoftBank Robotics Europe sur toute discussion ou document contractuel quel qu’il soit, et ne peut être interprété comme tel. Aucun employé ou agent de SoftBank Robotics Europe n'est autorisé à représenter ou à engager la société par email, ou à agir au nom et pour le compte de la société par email, sans qu’une confirmation écrite soit donnée par le représentant légal de SoftBank Robotics Europe ou par toute autre personne ayant reçu délégation de pouvoir appropriée.

Jorge Santos Simón

unread,
Mar 4, 2020, 9:59:50 AM3/4/20
to ROSPlan
I have successfully run fast_downward with the problem I posted yesterday. As Victor said, I removed :fluents and :durative-actions. But if I try with the existential in the goal, as Victor suggested:

(exists (?o - object) (is_picked ?o))

I get the following error:

INFO search command line string: /home/jorge/catkin_ws/thorp/src/fast_downward/builds/release/bin/downward --search 'astar(lmcut())' --internal-plan-file sas_plan < output.sas
reading input... [t=3.062e-05s]
done reading input! [t=9.7031e-05s]
Error: This configuration does not support axioms!
Terminating.
Tried to use unsupported feature.
Peak memory: 22188 KB
Remove intermediate file output.sas
search exit code: 34

Driver aborting after search

So looks like fast_downward doesn't support existential quantifier, nor durative actions. So looks like a worse option that POPF for robot planning, I think.

Or am I misusing it?

Victor Paléologue

unread,
Mar 4, 2020, 10:07:35 AM3/4/20
to Jorge Santos Simón, ROSPlan
I did not suggest to use the exists statement, which is a specific feature.
I suggested that you use another predicate (is_reachable, here).
In my suggestion, the object always exist, virtually.

To unsubscribe from this group and stop receiving emails from it, send an email to rosplan+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rosplan/9b275e37-8f99-4106-a236-6229c6098989%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages