Slow collision checking

[frenezulo]

Hello Johannes,
together with the previous topic I also deal with problem of quite slow collision checking during simulation. I'm not sure if it is normal speed of the checking or if there is some problem at my side.
When the collision checking is off, the profiler measures approximatelly 5-10 ms at KUKA|prc CORE. When the collision checking is on, it rises to some 300-700 ms (sometimes 1.6 s). It happens even if I use simple meshes (block with 6 faces).

Is it standard behaviour? Why is it so slow even with these simple meshes?

Best regards,
Tomas

[Johannes @ Robots in Architecture]

Hello Tomas,

Even with simple meshes it has to check them against the robot. What you can try, is to create a custom robot with a really, really simple geometry - either take one of the included robots in 0/90/-90/0/0/0 position and reduce it via the Reduce Mesh function in Rhino, or alternatively just draw simple mesh boxes around them - fastest way would be as a Bounding Box.
To set all the values via code you can try the C# script component that exposes tool and robot settings from the most recent member release: http://forum.robotsinarchitecture.org/index.php/topic,87.0.html

Best,
Johannes

[frenezulo]

Hello Johannes,
It's quite strange to me, but sometimes when I connect the slider and change the values (to change the positions of the robot), the profiler says it takes approximatelly 70 ms. But sometimes the values go to tenfold. I wasn't able to find, what's the reason for this, but I haven't changed anything else (eg. meshes, robot,...).

Thanks, I already found a way to change values and retrieve the results by script. I call it directly from Rhino Python Editor using calls based on this post on Grasshopper forum: http://www.grasshopper3d.com/forum/topics/automate-sliders-extract-model-data

Best regards,
Tomas

[Johannes @ Robots in Architecture]

Hello Tomas,

KUKA|prc uses certain caching methods and will only do calculations when necessary, that is most likely the reason for the differences in computation time!
Something that always slows KUKA|prc down is when you define a PTP position without a STATUS value, because it will test all possible configurations and take the fastest one. That takes much more time than e.g. a regular LIN movement which always assumes the previous status. That parallel checking is now multithreaded but even that gave only around +20% performance due to the general overhead.

Best,
Johannes

[frenezulo]

Hello Johannes,
thanks for clarifying this!
One more question. The STATUS value in PTP MOVE determines what configuration will be used? It probably relates to status bits description on the page 65 in this manual: http://forum.robotsinarchitecture.org/index.php?action=dlattach;topic=20.0;attach=11 . Is that right?
So if I don't define the STATUS value, KUKA|prc chooses "the best one", but I can choose best configuration by my own by changing this STATUS, right?

Best regards,
Tomas

[Johannes @ Robots in Architecture]

The status is basically the posture of the robot, as the robot has multiple ways of "reaching" towards a position with exactly the same end-effector orientation.
It's three bits, e.g. 010 or 110 etc.
The "best one" is the one with the least axis rotation compared to the previous position, it's definitely safer to define it yourself as there is no 100% guarantee that the robot will choose the same strategy as KUKA|prc.

Best,
Johannes