search

moveit / moveit_ros

THIS REPO HAS MOVED TO https://github.com/ros-planning/moveit
70 stars 118 forks source link

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

Open beatrizleon opened 8 years ago

beatrizleon commented 8 years ago

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 commented 8 years ago

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

alainsanguinetti commented 8 years ago

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.

v4hn commented 8 years ago

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 commented 8 years ago

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

v4hn commented 8 years ago

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 commented 8 years ago

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.