Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Inconsistent API Latency

#1
Hi All.
I have a question that I am looking for help with. I am working on a RoboDK simulation that uses the Python API. The task requires that I call setPose() or setJoints() on 10+ robots every 15ms or so.

This works fine in a simple test case. Using separate RDK sessions for each robot, setPose() and setJoints() both take about 1.35ms to return per call, according to cProfile.

But if I call solveIK() or solveFK() before or after setPose()/setJoints(), the set method now takes 10x longer to return (13ms per call). 

This happens even if the solveFK() is interacting from a separate thread, to a separate Robot in RoboDK, through a separate API instance. 

This is far too slow for my needs, and I just cannot figure out the root cause. It feels like congestion on a socket or similar, but I have no way of telling.

Has anyone encountered this before and found a good explanation, or better a fix?

I have attached the Python codes and rdk file if anyone is interested in taking a look.

Thanks All,
Fionn


.py   Profiler Test.py (Size: 298 bytes / Downloads: 106)

.py   Class_RobotTest.py (Size: 3.24 KB / Downloads: 110)

.rdk   API Latency Test V1.rdk (Size: 276.02 KB / Downloads: 119)
#2
After further digging, I have a candidate answer, looks like it's the render update causing the latency increase. solveIK() seems to force an update if there have been changes made to the scene. I used Render(False) and Update() to alleviate the issue in my test case.

But I am struggling to do the same in the full simulation codebase.

Is there a comprehensive list of functions and methods that have this behavior (forcing updates or whatever it is that's happening)? I noticed that solveFK() has the same issue for example, but I would rather not have to test the whole library function by function if it can be avoided ;)
#3
SolveIK should not require a render event. However, other functions that require an update such as setPose or setJoints requires an update, therefore, turning Render off can help speed things up.

If you have other threads that interact with the same instance of RoboDK, it is possible that your SolveIK gets queued after a render event from another API call. However, if you run a separate instance of RoboDK this should have no effect and you should be able to run both instances independently.

If your main concern is speed and you don't mind programming in C++/Qt you should consider using the Plugin Interface instead of the Python API:
https://robodk.com/doc/en/PlugIns/index.html
  




Users browsing this thread:
1 Guest(s)