Descartes finding discontinuous path

asked 2019-05-24 10:27:47 -0600

jbeck28 gravatar image

I am currently trying to plan circular paths in moveit, using Descartes. Although I've compared the output with the built in cartesianpath functionality in Moveit, and have found that it comes up with a much smoother path than Descartes does. The Descartes path is riddled with instantaneous joint flips.

At first I thought this might be due to using TRAC-IK , so I figured out the parameters for OPW for the fanuc lrmate200id that I'm using, and I've found that even still, the path generated in descartes is quite bad.

Any ideas on where to look to solve this problem?

edit retag flag offensive close merge delete

Comments

Most problems with Descartes are caused by an incorrect or improperly configured IK solver. How are you using OPW exactly? And how are you configuring Descartes to use it?

gvdhoorn gravatar image gvdhoorn  ( 2019-05-24 11:08:00 -0600 )edit

Descartes interfaces with moveit via https://github.com/PickNikRobotics/de... so I'm essentially using the typical ComputeCartesianPath functionality in move group.

for OPW, I'm using the moveit_opw_kinematics_plugin https://github.com/JeroenDM/moveit_op... where I've configured my own kinematics.yaml file with values that I've determined to be correct by looking through the documentation for the Fanuc LRmate200id (note I intend to use this on an IRB1200 as well, but fanuc for now). The values I've found seem correct (enough) since motion plans work fine for individual points.

Thanks for responding so quickly!

jbeck28 gravatar image jbeck28  ( 2019-05-24 12:51:44 -0600 )edit

Descartes interfaces with moveit via https://github.com/PickNikRobotics/de...

I'd say it's the other way around, as this allows MoveIt to use Descartes.

In any case: I'd suggest to post an issue over at the PickNikRobotics/descartes_capability tracker. The MoveIt capability is a custom wrapper and I've not checked the code.

As I wrote earlier, problems with Descartes are often caused by IK solvers that don't return sufficient solutions for poses or by incorrect setup of the Descartes planning infrastructure. Only the PickNikRobotics/descartes_capability know how they set things up / are using it. I don't think ROS Answers is the correct venue here.

gvdhoorn gravatar image gvdhoorn  ( 2019-05-24 13:21:59 -0600 )edit

Post on the PickNikRobotics/descartes_capability tracker: PickNikRobotics/descartes_capability#4.

gvdhoorn gravatar image gvdhoorn  ( 2019-05-25 02:53:50 -0600 )edit

@gvdhoorn you said most problems with Descartes are caused by IK solvers incorrectly or inproperly setup. Is there any guidlines in setting up the IK solvers? I am using UR5 and I have been trying UR5Kinematics and also KDLKinematics with IkFastStateAdapter and MoveitStateAdapter respectively but neither of them gives reasonable paths/trajectories. Your help would be very much appreciated.

Victor Wu gravatar image Victor Wu  ( 2020-07-16 02:30:42 -0600 )edit

@Victor Wu I'm not well versed in how UR5Kinematics works, but KDLKinematics will not reliably give good paths. This is an optimization based kinematics solver and cannot reliably return all IK solutions, which Descartes relies on. You should be able to create an IKFast solver for your arm, however this will be fairly inaccurate as there is a calibration stored on the controller which improves absolute accuracy. IKFast won't work if you incorporate these changes into the URDF. I have tried in the past to use the IKFast solver created against the default URDF, generate the Descartes trajectory with that, then use the returned IK solutions as seed state in Trac IK, where TracIK is set up with these changes made to the URDF.

jbeck28 gravatar image jbeck28  ( 2020-09-08 11:28:52 -0600 )edit