2. Limitations

Integration of complex products is never perfect. This chapter provides a list of features that might be expected by an experienced ROS2 or URScript developer. Limitations might be removed in future software releases.

2.1 ROS2 features

Action and service servers are not supported in URScript.
Node parameters are not supported in URScript.
Unsigned integer values are not supported in URScript. Unsigned 32bit integers are implicitly converted to signed 32bit integers.
Only supported Domain IDs are 0-5

2.2 Node discovery

2.2.1 Firewall configuration

Read Firewall Configuration section under Configuring ROS Domain ID and Firewall if Controller ROS node should be visible outside of the robot.

2.2.2 Unicast discovery for dockerized ROS2 nodes (Experimental)

Many network configurations including internal docker network on UR OS do not allow propagation of multicast UDP packets, that are by deafult used for ROS2 node discovery.

If dockerized ROS2 node should be visible outside robot, then in addition to firewall configuration, unicast discovery needs to be enabled. Remote node IP address needs to be known, and statically configured in DDS (underlying ROS2 communication) level.

Use unicast_discovery.xml file as a template. Copy to the docker image, and export to environment variable before starting ros node.

export FASTRTPS_DEFAULT_PROFILES_FILE=/workspace/unicast_discovery.xml

Example XML file:

<xml version="1.0" encoding="UTF-8" >
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
   <participant profile_name="unicast_connection" is_default_profile="true">
       <rtps>
           <builtin>
               <metatrafficUnicastLocatorList>
                   <locator/>
               </metatrafficUnicastLocatorList>
               <initialPeersList>
                   <locator>
                       <udpv4>
                           <address>10.54.253.121</address>
                       </udpv4>
                   </locator>
               </initialPeersList>
           </builtin>
       </rtps>
   </participant>
</profiles>

2.3 Threading model and Impact on processor load

ROS2 library functions are called in a separate thread within the controller, that results in delays for data exchange between realtime thread, and communication threads as well as additional processor load. ROS2 thread is not realtime. Calling read() method on subscriber handle or write() on publisher handle blocks program, allocates communication thread, exchanges information using queue, and waits for communication thread to complete. When communication thread is complete result is handed over to the robot program and execution continues.

There are two options to read the messages from subscriber handle:

read the oldest message from the queue and pop it out
read the latest message

The risk with reading the latest message is that if there is drop in synchronization between the thread then the message is lost.

2.3.1 Message rate and jitter

Due to the fact that communication threads don’t run with realtime priority there is possibility for overload. Following effects can be observed:

message delays, subscriber to one of the standard topics in the Robot is affected.
losing some messages in the process while clearing the queue.
jitter in the messages sent from robot

Note: timestamps are derived from realtime thread, so they are not affected by communication thread overload.

2.4 Latency of real time data

Real time communication with ROS2 is not possible, this is mainly due to the fact that a lot of functions in the controller are blocking calls using non-realtime threads for actual work. What that means is the functions have to wait for at least the entire cycle time before the next program statement is executed. Example: ros_handle.write() will block real time thread, until message is published on ROS2 topic in communication thread. Workaround: no workaround available.

2.5 Impact of changing the system time on published messages

Any message that contains a time stamp component is potentially vulnerable to system time changing. The time source of the messages are in UNIX time, coming from the system clock, and not from a steady clock. The user should be aware: after changing the system time backwards, new messages will contain older time stamps compared to the previously received ones. This can make certain calculations to behave incorrectly (e.g: TF2 messages and transforms), so make sure to properly react on these events. Changing the system time can be detected (on PSX) from the docker logs of universal-robots_ros2-web-bridge_ros2-web-bridge:

[2024-08-29 09:50:06] [      INFO] [frame_timer_callback] Clock has moved backwards. Clearing tf buffer.
[2024-08-29 11:00:00] [      INFO] [frame_timer_callback] Clock has moved backwards. Clearing tf buffer.
[2024-08-29 12:00:00] [      INFO] [frame_timer_callback] Clock has moved backwards. Clearing tf buffer.

2.6 Data type limitations

Capability across data types: Controller allows publishing and subscribing all ROS2 basic data types, including float64, int8, uint8, int16, uint16, int32, uint32, int64, and uint64.

There is no limitation on floating point values.

2.6.1 Limitations on publishing integer values

Despite the controller’s ability to publish across these data types, internal URScript integer type is limited to the INT32. Assigning integer values that exceed INT32 limit will result in a runtime or compile error.

2.6.2 Limitation for subscribing to integer values

Received values will be wrapped around when INT32 limit is exceeded. This behavior is a direct consequence INT32 internal number representation. There is no error, or warning - publisher should ensure that values are within limits, or URScript program should be able to handle wrapped around values.