About temporal plans and replanning

[yashu88]

Hello,

In ROSPlan documentation you have mentioned current package supports temporal plans with concurrent actions and timed-initial-literals, but when I compare plan.pddl and problem.pddl file of a current package with the previous package I couldn't find any logical difference. Also, Rviz simulation looks the same in case of both the packages. Kindly highlight the difference.

It's hard to understand how re-planning work? ROSPlan generates the problem.pddl and plan.pddl file only once. It will not change until it finished execution of all the actions present in the plan. While execution even in case of action failure there is no change in plan.pddl so How replanting is work in case of this package?

Thank you and Regards.

[NagaDinesh1194]

I have arrived at the same problem. Adding to the questions raised above, is there any way by which i can manually halt the PLAN EXECUTION and re-plan from there? Also is there any mechanism by which the status of action execution can be queried?

[m312z]

when I compare plan.pddl and problem.pddl file of a current package with the previous package I couldn't find any logical difference.

The plan.pddl and problem.pddl files are both automatically generated during runtime. They will only be different if the domain file or the state (stored in the Knowledge Base) are different. Do you have a domain file for your problem (that models concurrency?).

Replanning is quite easy to achieve. For example, when the plan fails, call the planning interface and dispatcher again! E.g.:

while goals not achieved:
   rosservice call /rosplan_problem_interface/problem_generation_server;
   rosservice call /rosplan_planner_interface/planning_server;
   rosservice call /rosplan_parsing_interface/parse_plan;
   rosservice call /rosplan_plan_dispatcher/dispatch_plan;
end while.

is there any way by which i can manually halt the PLAN EXECUTION and re-plan from there?

Yes, there is a cancel plan service. You can see the details in the docs: http://kcl-planning.github.io/ROSPlan//documentation/interfaces/04_plan_dispatch.html

Also is there any mechanism by which the status of action execution can be queried?

This depends upon the action. The implementation of actions is not a part of ROSPlan, so you would have to look at where that is happening. For example, if you are using move_base to execute navigation actions, you can find details in the move_base wiki page: http://wiki.ros.org/move_base

[bilal9876]

when we trigger re-planning. The new generated problem file should skip the goals that are achieved by the execution of the old plan since the goals are inserted in KB.

is this right?

[m312z]

That's right. If the goal is already achieved in the initial state, the planner will not have to re-achieve it.

[bilal9876]

That's right. If the goal is already achieved in the initial state, the planner will not have to re-achieve it.

I mean that:

Is the ROSPlan framework deals with the current goal achieved in the KB?. So, when the framework regenerate the problem file, it automatically adds the goals to the new problem file.

[m312z]

The current goal is stored in the knowledge base. The default problem generation node fetches the current goals and adds them to the generated problem file - behaviour different from this would be a small extension to that node.

[oscar-lima]

The ROSPlan plan dispatch removes achieved goals from the KB as soon as they are complete (more precisely, when it receives feedback from the action interface stating that the action was successful). So when you trigger replanning (which means you need to call service to create a new problem and dispatch it) the new plan should already consider the updated situation and therefore will not retry to achieve goals again.

[m312z]

The ROSPlan plan dispatch removes achieved goals from the KB as soon as they are complete (more precisely, when it receives feedback from the action interface stating that the action was successful). So when you trigger replanning (which means you need to call service to create a new problem and dispatch it) the new plan should already consider the updated situation and therefore will not retry to achieve goals again.

I don't think this is right. Can you point me to the code in plan dispatch or action interface that removes current goals from the knowledge base?

It is true that the new plan should not attempt to re-achieve already achieved goals. However, this is only because those goals would be true in the initial state of the new problem.

[bilal9876]

I think oscar-lima means that the predicates that can be duplicated in the KB such as robot_at.

When the predicate has the same values (parameter values) such as robot_at kenny wp0, it should be updated to robot_at kenny wp1. the domain model should be designed well to secure the KB facts such as use the predicate visited wp0 and then visited wp1 and so on. so, these goals will be used in the init section of the problem file.

[oscar-lima]

I don't think this is right. Can you point me to the code in plan dispatch or action interface that removes current goals from the knowledge base?

I can't, seems I was wrong. Sorry!