Long computation time in `ComputeIK` makes the task planning time very long
captain-yoshi opened this issue · comments
This issue might be related with the current limitations of the scheduler #312.
For my 2 cases I have a task which requires one ik solution.
Trac-IK with Speed
solver type (returns on the first successful ik)
Everything is good, the task is planned in 294 milliseconds.
Trac-IK with Distance
solver type (returns best solution after a timeout)
Holy macaroni ! It takes 37 seconds for planning the task. It took 2.8 seconds for returning an IK solution, which is normal because it stops after the timeout. While the IK is different from the other case, I don't think it's the bottleneck here.
Is there a way to speed up the process ?
Looks like the found IK solution in the 2nd case requires much more complicated planning trajectories (and thus more time). Did you had a look at the solutions?
I'm afraid there is no way to speed up the planning processes if you made them too complex ;-)
Pilz does not check collision when planning the path, so it is normally super fast (unless there is a bug).
I have managed to almost have the exact IK joint configuration as the one who gives 38 seconds to plan. Joint positions: (Left) Distance, (Right) Speed solve type.
Trac-IK with Distance
solver type
Trac-IK with Speed
solver type
With almost the exact IK cost and joint configuration. It takes 11 seconds but I have 8 seconds of trying to find 32 IK's and the rest is for planning the combinations. Which gives about 3 seconds to plan multiple sub-tasks.
As you can see, when the compute_ik
stage does not return fast (Distance solve type) it takes 36 seconds to plan 1 trajectory. When the compute_ik
stage returns fast (Speed solve type) it takes 3 seconds to plan multiple trajectories.
Oh well this one's on me...
Well if I set the IK to return after a timeout, this will also affect the other LIN Pilz planners of the same group because they rely on the same IK solver. Mystery solved.
Knowing that you use the Pilz planner for subsequent stages, this would have been my next hint 😉
Can we close this issue?