Set the start planning state as "current" after finish the execution of a trajectory

Question

Set the start planning state as "current" after finish the execution of a trajectory

beatrizleon opened this issue 8 years ago · comments

After executing a trajectory, if the user wants to plan a new trajectory, he needs to click on the GUI start planning state set as current, otherwise it takes the start state as the one for the previous trajectory.

Is this the desired behaviour or can it be improved so the start state state gets updated to the current state (or goal state) when a trajectory finish its execution?

Dave Coleman · Answer 1 · Fri Feb 19 2016 00:38:20 GMT+0800 (China Standard Time)

I'm not sure, but it has advantages when you are trying to benchmark the same particular motion over and over

Alain Sanguinetti · Answer 2 · Fri Jul 08 2016 16:21:58 GMT+0800 (China Standard Time)

I think it is a desired behaviour.
If you look at move_action_capability.cpp in move_group package, you can see two different behaviour for plan and plan and execute.

Plan will plan using the requested start state
plan and execute will systematically use the current state as the start state for safety reasons (however there is still #442 )

Michael Görner · Answer 3 · Fri Jul 08 2016 18:19:11 GMT+0800 (China Standard Time)

I fully agree with @beatrizleon and I support any attempt to change the current behavior of the rviz-GUI. We had more than one case in our laboratory where someone forgot to update the start-state, but planned and executed the trajectory without checking... Therefore I believe this is a safety-issue that should be addressed soon!

Robert Haschke · Answer 4 · Fri Jul 08 2016 19:23:02 GMT+0800 (China Standard Time)

I suggest to disable the execution button, when the start state of a planned trajectory doesn't match the current state (anymore).

Michael Görner · Answer 5 · Fri Jul 08 2016 21:50:50 GMT+0800 (China Standard Time)

On Fri, Jul 08, 2016 at 04:23:03AM -0700, Robert Haschke wrote:

I suggest to disable the execution button, when the start state of a planned trajectory doesn't match the current state (anymore).

This is quite a confusing interface, unless you also add a notice on why execution is disabled.
+1 though, this is nice to have.

The more fundamental issue is that the option "" in the start-state menu is not always the current state (which is clearly what every user expects).
I'll try to look into this over the weekend.

Dave Coleman · Answer 6 · Mon Jul 11 2016 20:06:30 GMT+0800 (China Standard Time)

There is already a check here in move_action_capability that replaces an outdated start state with the current start state when running "Plan And Execute". It also displays the message "Execution of motions should always start at the robot's current state. Ignoring the state supplied as start state in the motion planning request".

I think that, perhaps in addition to disabling the Execute GUI button, we implement that failsafe check properly on the move_group side for the execute button.