search

ros-industrial-consortium / descartes

ROS-Industrial Special Project: Cartesian Path Planner
Apache License 2.0
131 stars 91 forks source link

Randomly added offset in planned path #214

Closed haisongdong-harrison closed 6 years ago

haisongdong-harrison commented 6 years ago

I just encountered a very weird problem when using Descartes with MoveIt!. We have a fixed trajectory to plan and we always start from the same pose and of course seed the trajectory with this pose. Every time the planned path can reproduce the trajectory perfectly but it may or may not add some offset to the path on a certain axis (X-axis in our case), completely at random. The screenshot below may give you a better idea: 1st_run 2nd_run

The first photo is when the path follows our desired trajectory while the second one is a path that looks similar but about 10cm back on the X-axis.

Our program is adapted from the tutorial. And we use the specific UR3 kinematics solver from ur_kinematics package. It is understandable that each time the planned path may be slightly different, but I really cannot figure out what could introduce such a great offset to the path randomly when all the conditions/inputs are the same?

Any help would be appreciated!

haisongdong-harrison commented 6 years ago

Oops, it seems to be a bug in our getAllIK function. Although I still have no idea why this bug can generate a different path every run, after some tiny fix it is working well now. Sorry for the unnecessary issue report.

gavanderhoorn commented 6 years ago

Oops, it seems to be a bug in our getAllIK function.

@hansondon: this would be in a custom descartes wrapper for ur_kinematics?

haisongdong-harrison commented 6 years ago

@gavanderhoorn Yes. We checked this issue and it seems ur_kinematics is faster than IkFast solutions? Our code is adapted from the roscon2015 demo project so we are still using the MoveitStateAdapter to wrap it up.

BTW, is it actually better to set IkFast as the solver in the kinematics.yaml and use IkFastMoveitStateAdapter instead? (well, I know it may be inappropriate to ask another question in a closed issue, but this isn't an issue)

gavanderhoorn commented 6 years ago

ur_kinematics provides analytic ik solvers for the various UR robots, written by hand by Kelsey. IKFast would be the same, but then generated. I haven't benchmarked the two, but I almost assume that ur_kinematics is comparable to IKFast, if not faster.

The only direct disadvantage I see of using ur_kinematics directly is that you'll have to maintain a wrapper, as you cannot reuse the IkFastMoveitStateAdapter with it.