simIK.findConfig problem

[Mildred34]

Hello,

I was trying to do path planning with a manipulator, my code is close to the pathPlanningAndGrasping code.
I've seen a lot of times in an environment with some collisions, for instance empty with an object you want to grab.

The config found is really far away from the dummy target position.

I've done the same thing with the coppeliasim example without modifying the code. Sometimes the given config is not even close to the targe pose.

Is there another approach to do path planning without using this findconfig function ?

Best regards,

Alexis

[Mildred34]

Ok I found a solution. It seems that it's caused by the interaction between my Python code and the Lua side within the simulator.

It might be a problem of synchronization between the 2 threads?

[coppelia]

Hello,

yes, this could be a synchronization problem between two separate threads. But in general, if OMPL does not return a path that comes close to what is desired, this means that you ran out of time with computation. Try specifying a larger timeout value, or redo your computation if you notice that the last path point is not even close to coincide with the goal point. Keeping in mind that OMPL runs in a randomized fashion.

Cheers

edit: I probably read too quickly over your questions and didn't understand your problem. simIK.findConfig is also working in a randomized fashion. It normally isn't interrupted by any other thread as far as I understand. When you say that sometimes the given config is not even close to the target pose, does that mean that simIK.findConfig fails finding a solution? If increasing the timeout time doesn't help, make sure that a solution can really be found (e.g. as a you mentioned it, it could be that when the simIK.findConfig is called, that there is an obstacle in the way).

Cheers

[Mildred34]

Hello,

yes, this could be a synchronization problem between two separate threads. But in general, if OMPL does not return a path that comes close to what is desired, this means that you ran out of time with computation. Try specifying a larger timeout value, or redo your computation if you notice that the last path point is not even close to coincide with the goal point. Keeping in mind that OMPL runs in a randomized fashion.

Cheers

edit: I probably read too quickly over your questions and didn't understand your problem. simIK.findConfig is also working in a randomized fashion. It normally isn't interrupted by any other thread as far as I understand. When you say that sometimes the given config is not even close to the target pose, does that mean that simIK.findConfig fails finding a solution? If increasing the timeout time doesn't help, make sure that a solution can really be found (e.g. as a you mentioned it, it could be that when the simIK.findConfig is called, that there is an obstacle in the way).

Cheers

Indeed it was OMPL the issue not simIK.findConfig. I correct it by :
- changing the moment where I defined the collision collection (I don't know why it has such an impact)
- And when the result is too far away from what I expected, I redo a path planning search with OMPL .


Alexis

[fferri]

You don't have to measure distance to goal to determine if the solution is found, not found, or partial (approximate, as per OMPL's terminology).
Instead, use simOMPL.hasSolution(), simOMPL.hasExactSolution(), simOMPL.hasApproximateSolution().