Universal Robots Forum

Sample: getRobotData Real Time Client reader URCap

getRobotData Real Time Client reader URCap

Description of functionality:
This URCap implements a new custom class, getRobotRealtimeData.class, that connects to the Real Time Client interface, and reads the message.
The data from the Real Time Client is broken into the information it represents, and implements get-methods to read actual TCP pose, actual joint positions, joint temperatures, joint operation modes and the safety limited speed scaling percentage. You can add your own get-methods as well.

Hence, this class demonstrates how to read information about the robot state (position, running mode, etc.) and use this within another section of the URCap.

A sample placeholder Installation node is implemented, to show how to import the getRobotRealtimeData class into another class. The Installation node uses EventQueue.invokeLater to update the values from the getRobotRealtimeData dynamically.

What topics are covered:
socket, importing class, get actual TCP, client interfaces, live update

Find it on Github!

4 Likes

Hi Jacob,

Is it possible if i want to use getRobotRealtimeData.class on sdk lower than SDK 1.1+?

The getRobotData java class does not require the 1.1 SDK. (Only the placeholder Installation node does)
It is merely relying on native Java and that the client interface is compatible.
You can place this class in any of your projects, and import it, regardless of the SDK version used to create the project.

This sample doesn’t work on 3.5, when I try to getActualTcp I get an array index out of bounds error

I increased the RealtimeMessage size, but how much is the recommended?

The release notes for 3.5 are describing, that there are two 6D doubles added to the RealTime message.
See the updated protocol documentation.

Note, that this might be one of the downsides of using the Realtime Client (30003) over e.g. the RTDE interface, which is a more modern protocol.
Also note, that for the specific case of getting the TCP position, is is recommended to use the Robot Position Callback through the Move screen instead, in most cases, to allow users to define a position.

The increased message size in PolyScope 3.5 is corrected in the Github repo.