getConfigForTipPose Collision Problems

[Sibelius]

Hello guys, im having more questions about the behaviour of CoppeliaSim.

The documentation of "simGetConfigTipPose" tells me:
collisionPairs: an array containing 2 entity handles for each collision pair. A collision pair is represented by a collider and a collidee, that will be tested against each other. The first pair could be used for robot self-collision testing, and a second pair could be used for robot-environment collision testing. The collider can be an object or a collection handle. The collidee can be an object or collection handle, or sim_handle_all, in which case the collider will be checked agains all other collidable objects in the scene. Can be nullptr if collision checking is not required.

In my case there are two Collections; My Robot (handle 2000000) and the environment without the robot (handle 2000001).

Im calling sim.simGetConfigTipPose thorugh the console or through the b0 API, the result im getting is the same. The parameter for CollisionPairs looks like so: {{2000000, 2000000},{2000000,2000001}} since i dont want to collide with my environment as well with the robot itself. What im getting are poses which dont collide with my enviroment, but most of them do self collide, which i can test applying the calculated pose and checking sim.checkCollision(2000000, 2000000).

As far as I understand that shouldn't be the expected behaviour. I'd like to calculate the configurations without telling my Robot to move somewhere.

[coppelia]

Hello,

if I understand you correctly, the function is finding configurations where the robot self-collides, even if you specified robot-robot self collision? So that is probably a bug if sim.checkCollision(robot,robot) reports a collision, but the same collision pair does not detect collision in sim.getConfigForTipPose.

Can you provide a minimalistic, self-contained scene file that illustrates this?

Cheers

[Sibelius]

This is a modified scene from the example scenes, hosted on github.
The robot has to find a position which shouldnt be collision free at that point.
https://github.com/ravnicas/CoppeliaForum

If i read the documentation of this function, i would expect another return value. I'd expect 0, or an error at that point. The big cube is collidable and measurable.
sim.getConfigForTipPose

[coppelia]

Maybe I am still understanding something not right... but the found configuration doesn't self-collide if you check closely.
Keep in mind that simIK.getConfigForTipPose (or similar API function) doesn't check for collisions along the path. Only at the specified pose.

Additionally, have a look at the meaning of Collection self-collision indicator.

Cheers

[Sibelius]

Yeah, you are right, i didn't move the "testPose1" far enough in my example, probably didnt save it before upload. I changed it.

Anyway, I've made a screenshot to illustrate my problem, or maybe my problem of understanding.



I printed the ikGroup handle, joint handles, collection table and the returned pose from top to bottom.

Clearly it is colliding. Also if i run sim.checkCollision(2000000, 2000000) [where 2000000 is still the collection of the robot only] I'm getting a return value of 1, which should tell me there is a collision, which there is.

Also another problem surfaced, which also applies to sim.getConfigForTipPose. It is ignoring my low bound and range for another robot, which i cannot upload here. I will try to modify this example to demonstrate this issues.

At the moment I'm avoiding both issues, first checking if the returned pose is within bounds, after it es returned, second moving the whole robot to the calculated pose and checking for self collision, which I thought getConfigForTipPose should do as a all-in-one solution.

[coppelia]

Look again closely:

in your updated scene, your box is colliding with object IRB4600_link1_visible, which is perfectly fine since the box has a self-collision indicator or 0, and that object a self-collision indicator of 1. If you read about that self-collision indicator, you will see that consecutive numbers won't be check for collision, during self-collision checking.
However, in that configuration, the dynamics of the scene will collide and react to collision by pushing the box away --> the box will collide now also with the end-effector of the robot, thus collision is detected. And your box is vibrating because it is being pushed away from both ends.

Be careful not to mix up collision detection, and collision response (the first has nothing to do with dynamics, the second yes).

Cheers

[Sibelius]

Just to wrap up my own question, and maybe as a reference to others.

The bugs in my own scene were:

I didn't quite get the LUA syntax for tables and the definition of "pairs" within the documentation.
I passed

Code: Select all

{{handle1, handle2}, {handle2,handle2}}

to coppeliasim, but it has to be:

Code: Select all

{handle1, handle2, handle2,handle2}

Also i defined the same maximum joint positions within the simulation itself. After that I've got only plausible configurations, with very few exceptions.