val_3 driver: rough and jerky trajectories

[nilsmelchert]

After working a while with ros kinetic and the val_3 driver in the staubli_experimental package, I figured that the executed trajectories of the real robot are not running very smoothly. Especially in the end of an executed path the movement is quite chopped.
Did also experience the same thing? Could there be a problem with the driver? Or is there a problem with the ompl library?

[gavanderhoorn]

The driver could always play a role (it hasn't been tested very extensively, partly why it is in an experimental repository), but if you're using Kinetic and MoveIt, you may be running into moveit/moveit#416 or related issues.

See ros-industrial/kuka_experimental#126 for a possibly related issue, and some links to relevant other issues.

I'm not saying this is the cause of what you're seeing, but it would be good to check this.

One way to see whether Kinetic OMPL is doing strange things is to generate a trajectory in some other way, time-parameterise it yourself and then send it to the driver directly.

Especially in the end of an executed path the movement is quite clipped.

I'm not sure I completely understand what you're describing here. What do you mean with 'clipped'?

[nilsmelchert]

I'm not sure I completely understand what you're describing here. What do you mean with 'clipped'?

By clipped I meant very jerky.

Yes ros-planning/moveit#416 seems to describe exactly the behaviour of my trajectories. I would guess that the content of the second comment in this answer could be a reason for the jerky trajectory execution.

[gavanderhoorn]

Thing is, the time parameterisation code hadn't changed much (at all actually) between Indigo and Kinetic, until moveit/moveit#441 got merged. That seemed to point to something else that was interfering here. As you can read further down in moveit/moveit#416, it would seem that changes to OMPL itself have introduced this. This was reported in bitbucket/ompl/ompl#309.

The comment you link to (it's not an answer) suggests that it's mostly the time parameterisation. As I hope is now clear, that could be related, but is most likely not the cause. A strong hint for that is that the reporter of bitbucket/ompl/ompl#309 mentions in the second comment on his own issue that:

I tested the following diff and the jerky trajectories are gone now.

Where "the following diff" undoes some changes to the trajectory generation parts of OMPL itself.

I believe it would make sense to see whether generating a path through some other means and then time parameterising it would immediately make clear whether or not OMPL is affecting this. Alternatively, have an Indigo version of MoveIt generate a trajectory and execute that. If that doesn't exhibit this behaviour, I believe it would point to OMPL again.

It would also be good to check whether configuring MoveIt to use TOTG improves things (moveit/moveit#809).

But that is all mentioned in ros-industrial/kuka_experimental#126 already.

[gavanderhoorn]

According to the latest comments on moveit/moveit#416, the issue with OMPL is now fixed and is going to be backported to Kinetic.

[nilsmelchert]

Thank you very much! I will close this Issue now.

[nilsmelchert]

When will I be able to update the fix for this Problem? Will it be updatable in the apt-tree or would I have to apply the changes myself with some kind of patch which will be published?

What are the next steps?

[gavanderhoorn]

The fix first needs to be verified. Then it needs to be backported to Kinetic. MoveIt/OMPL will need a new release, and that will need to be synced to the public repositories.

It could take some time. Building OMPL from source on Kinetic -- and thus MoveIt as well -- will make it available earlier to you.

Note also btw that it's not certain that this is the cause of what you describe. It's a good candidate, but there are no guarantees.

[gavanderhoorn]

I recommend you keep a close eye on moveit/moveit#416.

[gavanderhoorn]

Have you seen any improvement @nilsmelchert with the release of the new MoveIt+OMPL?

[nilsmelchert]

To be honest, I have not worked with the robots for about a month. Do I have to compile MoveIt from source or is it already available via apt-get?

I will test it on monday and then present the results.

[gavanderhoorn]

MoveIt & OMPL on Kinetic should have all the updates. No need for a source build.

[nilsmelchert]

Ok. I will test if there is any improvement and then post the results.

[gavanderhoorn]

One thing to check btw is that the reach and leave setting for each trajectory point in the driver is set to really low values, so the controller cannot do much blending.

That could also be the cause of some jittering.

See this diff for another user that experimented a bit with that.

Ideally blending should not be used, but if all else fails, it might be something to look into.

[gavanderhoorn]

@nilsmelchert: has this improved at all for you?

[nilsmelchert]

@gavanderhoorn I just tested it. And yes it works perfectly fine. Thanks!
I will close the Issue now.