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

[beatrizleon]

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?

[davetcoleman]

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

[alainsanguinetti]

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 Trajectory start doesn't match Current Position, when using plan/execute #442 )

[v4hn]

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!

[rhaschke]

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

[v4hn]

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.

[davetcoleman]

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.