[bp.tum]

During some testing with the Python API, I realized that pulling the pose from a running robot (repeatedly and writing it to a CSV) seems to work using Python 3.12 via PyCharm on macOS 14.5, robot is a KUKA KR 30 HA being connected via kukabridge. With 10 ms as the defined interval however, the time between to timestamps ranged mostly between 30 ms and 55 ms, which might be attributed to hardware constraints/my inefficient code.

While trying on a Virtual Machine (Windows 11 23H2, also Python 3.12 via PyCharm), the code was not able to get the current pose of the robot. Interestingly, it was still possible in RoboDK to update to the correct position using the corresponding button in the "Connect Robot" field. 

Despite this being a niche thing, did somebody encounter a similar phenomenon? Firewall was already deactivated, RoboDK was 5.7.1 & 5.7.4.

Long term goal would be to pull the orientation of the TCP as well as data from an attached scanner already synced via KUKA RSI if possible, and this in the domain of 50 Hz+. As somebody might have already experience, I'd be very happy to receive tips if I am possibly already on the wrong track with my approach.

Already thanks in advance and very kind regards,
Bene

[Albert]

You should be able to reach 20 to 50 Hz monitoring frequency when using most drivers. Having a faster response may be challenging.

However, keep in mind that rendering the scene can be very time consuming (from 15 to 500 ms, or even more, depending on your project). You can optimize some settings in the Display tab of the Tools-Options menu. Also, minimizing the RoboDK window should prevent the scene from being rendered. 

Another option if you don't need the 3D window or the user interface is to block rendering by using this command:

Code:

RDK.Command("Render", 0) # Lock 3D rendering
...
RDK.Command("Render", 1) # Unlock 3D rendering

[bp.tum]

You should be able to reach 20 to 50 Hz monitoring frequency when using most drivers. Having a faster response may be challenging.

However, keep in mind that rendering the scene can be very time consuming (from 15 to 500 ms, or even more, depending on your project). You can optimize some settings in the Display tab of the Tools-Options menu. Also, minimizing the RoboDK window should prevent the scene from being rendered. 

Another option if you don't need the 3D window or the user interface is to block rendering by using this command:

Code:

RDK.Command("Render", 0) # Lock 3D rendering
...
RDK.Command("Render", 1) # Unlock 3D rendering

Thank you for your quick reply, this indeed improved the performance very noticeably.

[Albert]

Perfect, thank you for your feedback!

[bp.tum]

Coming back to this thread due to a still unresolved issue: While running a program on the connected robot, the position is not updated in RoboDK (also when using get pose from the API), but is when I push the Get Position Button in the GUI of RoboDK's Connection tab.

Is there a difference between those two initially, or would I have to implement an update command in my Python code to continuously update the robot position? The problem does not persist when only running a simulation without the actual robot connected.

Best Regards
Bene

[Albert]

Do you see this issue with a KUKA robot controller or another robot?

[bp.tum]

Thanks for the quick response. The problem appears when running with a KUKA KR30 HA + KRC4 as Control, connected via kukabridge.

[Albert]

There should be one communication link between the robot and the computer. Either everything should work or nothing.

Maybe the connection gets cut at some point due to Network issues?
Can you provide us with more details about this issue? Do you have this issue when not using a virtual machine?

If you use a virtual machine, can you specify what works and what does not work?

[bp.tum]

The phenomenom persists when not using a virtual machine.

In both cases, it works to use the "Get Position" button in the UI to get the current position, but calling robot.Joints or Pose via Python does not give the correct information, but only the last position manually updated with the button. Interestingly, when not having the robot connected and only running the simulation the output is correct. Also checked with the position monitoring script coming with RoboDK, this showed the same behavior, so an error in the code might be unlikely.

A network issue was the first thought as well, but at least deactivating the firewall did not resolve it.

[Albert]

I'm sorry we took so long to get back to you. After checking your code we noticed that you are missing the Connect command.

Example:

Code:

robot.Connect() # This will force the connection to forward robot commands to the real controller
while True:
    joints = robot.Joints()
    time.sleep(0.1)