moveit / moveit_ros

THIS REPO HAS MOVED TO https://github.com/ros-planning/moveit

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

beatrizleon opened this issue · 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?

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

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 )

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

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.

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.