Trajectory slider plays for the previous goal when a plan for the new goal is unavailable

[130s]

Thanks for the nice feature @Jntzko @v4hn #491!

Description

Pressing Play button on Trajectory Slider panel shows older trajectory, when a plan for the current goal is not available.

Without knowing if this behavior is intended, this can be simply confusing.

Your environment

• ROS Distro: [Indigo]
• OS Version: Ubuntu 14.04
• Build

$ dpkg -p ros-indigo-moveit-ros-visualization |grep Ver                                                 
Version: 0.7.10-0trusty-20170607-162519-0800

Steps to reproduce

roslaunch pr2_moveit_config demo.launch

Using right hand eef,

1. Move it anywhere, then Plan and Execute.
2. Move eef anywhere. Don't run Plan.
3. "Play" on Trajectory Slider.

Expected behaviour

Show waypoints along the trajectory for the current goal.
UPDATE 20170617 Do not play any trajectory when a planning with the goal currently set failed.

Actual behaviour

Explained in Description section.

[v4hn]

Weeeell... I can see how this can be confusing.
Our MoveIt Motion Planning Panel only imports the Trajectory visualization display and uses it "as is".
This display caches the trajectory it received most recently and presents it to the user.
So as long as no new trajectory - produced by successful planning - was received the old one is still there.
I believe the behavior you noticed was the same with the "loop animation" mode before the panel, so this is not actually something new.

Knowing the internal structure of the plugins, the current behavior makes sense to me.
But maybe we want to adjust this?

[130s]

Would there be any issue when Play on Trajectory Slider panel gets pressed then planning internally runs? Assumption: I can't think of any situations where you want to see a trajectory from the goal previously set while a new goal is already set.

[v4hn]

I don't like that behavior. We wanted the user to be able to re"Play" the current trajectory over and over again (as a more controlled version of "loop animation"), so the play should not trigger planning. I suppose we could remove the current trajectory whenever the user pressed "Plan" or "Plan&Execute", so that there is *no* plan anymore when planning fails. Would that help?

[130s]

We wanted the user to be able to re"Play" the current trajectory over and over again (as a more controlled version of "loop animation"), so the play should not trigger planning.

That makes sense.

I suppose we could remove the current trajectory whenever the user pressed "Plan" or "Plan&Execute", so that there is no plan anymore when planning fails. Would that help?

+1
Is this something that someone on your end can work on (hopefully very quickly more quickly than others since it's you guys that added this feature)? Otherwise we'll see if someone incl. me in the community will have time to tackle.