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
simIK.findConfig problem
Re: simIK.findConfig problem
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?
It might be a problem of synchronization between the 2 threads?
Re: simIK.findConfig problem
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
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
Re: simIK.findConfig problem
Indeed it was OMPL the issue not simIK.findConfig. I correct it by :coppelia wrote: ↑01 Aug 2023, 13:45 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
- 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
Re: simIK.findConfig problem
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().
Instead, use simOMPL.hasSolution(), simOMPL.hasExactSolution(), simOMPL.hasApproximateSolution().