Unexpected behaviour of checkCollision for robot collision detection

8 views (last 30 days)
I am using the function checkCollision (R2020b version) to detect wheter a robot is in collision with itself. The basic code I use for this is:
robot = importrobot(robotPath,'MeshPath',collisionMeshPath);
isCollision = checkCollision(robot,jointAngles); % joint angles = [a1 a2 a3 a4 a5 a6]'
This function works great when the robot model does not have a tool attached. However, with a tool attached, the behaviour is not as expected anymore since it always returns true.
I need to shift the mesh of the tool away from the robot so far that no point of the robot sticks into the bottom of the tool even though there is a cut out. I have now removed the entire bottom part covering the tool and still get this problem. You can clearly see that the robot arm is far away from touching the tool but still the output is always true. In the image below, I added 18mm of vertical offset and still get the error. Once I add 19mm, no part of the robot stick into the tool and the error goes away. I want to use the function with no or very small z-offset in order to do a realistic collision detection.
Is this just the normal behaviour of this function or am I doing something wrong here? Is there maybe a workaround?
  1 Comment
fixusc on 22 Oct 2020
Here is another strange one. It almost looks like the checkCollision function applies a certain safety margin. When I let the robot move towards the floor, the position in the attached image is about the first one to be detected as a collision, so a few mm above the actual surface.
Is there actually a safety margin built into this function and can it be controlled?

Sign in to comment.

Accepted Answer

Karsh Tharyani
Karsh Tharyani on 26 Oct 2020
It will help to view the robot's collision geometry data instead of the visual data as they might be different. To do so,
show(robot, config, "Visuals", "off", "Collisions", "on");
You can also view the end-effector body's collision data by inspecting the Collisions property of the rigidBody
The next good step will be to find out which bodies are in collision. This can be done by viewing the separation distances between the bodies.
[isColliding, sepDist] = checkCollision(robot, config, "Exhaustive", "on");
In order to find out which bodies are colliding, you can view the entries in the sepDist matrix which are NaNs
[b1, b2] = find(isnan(sepDist));
Note that the rows and columns correspond to the body indices. The last row and column corresponds to the robot.Base body's collision with other bodies.
Adjacent bodies are ignored for collisions hence their separation distances are Inf.
Once you have found out which bodies are in collision, you can modify the collision data associated with that body to make the robot self-collision free for that configuration.
I suggest reaching out to Technical Support https://www.mathworks.com/support/contact_us.html in case you still see any unexpected results
fixusc on 27 Oct 2020
Yes it looks very much like thise is the case. However, it's not just the tool but also the base of the robot which gets a weird shape, leading to premature collision detection with the ground. So is it normal for Matlab to modify the geometry in such a way? Is there no other way to retain the original geometry other than splitting up the mesh into many parts?
I actually do not want to remove any collision mesh entirely but only look at certain cases. E.g. one arm colliding with the ground or the tool colliding with the ground or an arm. But arms colliding with arms is already taken care of by the joint angle limits. This is why I work with the sepDist matrix. But thanks anyway for the hint, I did not know about this function.
I will reach out to support now, thank you for helping me out so far.

Sign in to comment.

More Answers (0)

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!