search

ros-industrial / staubli_experimental

Experimental packages for Staubli manipulators within ROS-Industrial (http://wiki.ros.org/staubli_experimental)
Apache License 2.0
27 stars 27 forks source link

val_3 driver: rough and jerky trajectories #25

Closed nilsmelchert closed 5 years ago

nilsmelchert commented 6 years ago

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

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 ros-planning/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 commented 6 years ago

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

Thing is, the time parameterisation code hadn't changed much (at all actually) between Indigo and Kinetic, until ros-planning/moveit#441 got merged. That seemed to point to something else that was interfering here. As you can read further down in ros-planning/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 (ros-planning/moveit#809).

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

gavanderhoorn commented 6 years ago

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

nilsmelchert commented 6 years ago

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

nilsmelchert commented 6 years ago

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

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

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

gavanderhoorn commented 6 years ago

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

nilsmelchert commented 6 years ago

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

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

nilsmelchert commented 6 years ago

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

gavanderhoorn commented 6 years ago

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

@nilsmelchert: has this improved at all for you?

nilsmelchert commented 5 years ago

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