Introduction

In our previous blog we saw how to get a real-time enabled kernel on the Hikey970 running Ubuntu 18.04. Building on top of it this time we will get ROS2 installed and will run the pendulum demo which requires real time capabilities available.

In addition we will also run a small test to assess the performance of FastRTPS and Eclipse Cyclone DDS implementations.

The post is organized as follows:

ROS2
Pendulum demo
- Rttest library
Cyclone DDS
FastRTPS vs Eclipse Cyclone DDS comparison

ROS2

ROS2 is a new version of ROS that improves some of the weaknesses that were identified for ROS1. In particular the custom ROS middleware has been replaced by DDS implementations from different vendors which allows users to choose between Open Source ones (FastRTPS, CycloneDDS, etc) and proprietary ones (Connext, Opensplice, CoreDX, etc) depending on the user needs.

At the time of writing ROS2 Dashing is the latest release available. ROS2 can be installed following the instructions in https://index.ros.org/doc/ros2/Installation/Dashing/Linux-Install-debians/. We will install the Desktop version that includes also the demos.

After installing is worth checking that it went fine by running one of the examples. Let’s open 2 terminals:

In terminal 1:

$ source /opt/ros/dashing/local_setup.bash
$ ros2 run demo_nodes_cpp talker

In terminal 2:
```
$ source /opt/ros/dashing/local_setup.bash
$ ros2 run demo_nodes_py listener
```
We can see that the messages published by the talker node in terminal 1 are received by the listener node in terminal 2.

Pendulum demo

In its present state ROS2 is not currently capable of achieving hard RT due to the number of changes that are yet to be developed by the community. Nevertheless, some support for realtime is already included in the distribution and a demo of an inverted pendulum control is available.

The pendulum demo is installed as part of the ROS2 distribution, by default it needs 8GB of RAM available in the machine. We can try to run the default demo by:

Sourcing our ROS2 installation:

$ source /opt/ros/dashing/local_setup.bash

Running the pendulum_demo executable:
```
$ pendulum_demo
```

If we have htop running in a different terminal we can observe how the RAM memory is allocated until it reaches the maximum of 6GB and Killed message is output in the terminal running the pendulum_demo executable.

Rttest library

The pendulum demo depends on the rttest library to compile and run. The library will look at the number of major and minor pagefaults and will allocate blocks of 64*system page size with the default page size of 4KB in our setup for the Hikey970. This configuration leads to +2M initial minor pagefaults, multiplied times the 4KB is roughly the 8GB of RAM that are required and mentioned in the tutorial page.

In order to be able to run the demo in the Hikey970 we need to modify the memory requirements to fit the 6GB RAM available on the Hikey970. To do so we first create a local ROS2 workspace and clone the realtime_support repository:

$ mkdir -p ~/ros2_rt/src
$ cd ~/ros2_rt/src
$ git clone https://github.com/ros2/realtime_support.git -b dashing

We can then modify the memory allocation lines (683 and 684) from:

ptr = new char[64 * page_size];
memset(ptr, 0, 64 * page_size);

ptr = new char[40 * page_size];
memset(ptr, 0, 40 * page_size);

This change leads to approximately 1.4M pagefaults which multiplied times the default page size returns approximately 5.6GB of RAM needed which fit in the Hikey970. So we can now compile the modified package and re-run the pendulum demo:

$ source /opt/ros/dashing/local_setup.bash
$ cd ~/ros2_rt
$ colcon build
$ source install/local_setup.bash
$ pendulum_demo

Upon completion we get:

Initial major pagefaults: 67
Initial minor pagefaults: 1342954
No results filename given, not writing results
rttest statistics:
  - Minor pagefaults: 0
  - Major pagefaults: 0
  Latency (time after deadline was missed):
    - Min: 5787 ns
    - Max: 114062 ns
    - Mean: 8574.65 ns
    - Standard deviation: 1.35819e+08


PendulumMotor received 1031 messages
PendulumController received 725 messages

which shows that the demo has completed succesfully.

Cyclone DDS

ROS2 installs FastRTPS as the default DDS implementation. Eclipse Cyclone DDS is another open-source DDS implementation being developed as an Eclipse IoT project. We will assess how both DDS implementations perform on the pendulum demo.

First we need to get the Eclipse Cyclone DDS and build it, which is pretty straighforward following the steps in its rmw repository. We will use the ROS2 workspace that we created to modify the rttest library:

$ source /opt/ros/dashing/local_setup.bash
$ cd ~/ros2_rt/src
$ git clone https://github.com/ros2/rmw_cyclonedds
$ git clone https://github.com/eclipse-cyclonedds/cyclonedds
$ cd ..
$ rosdep install --from src -i
$ colcon build
$ source ~/ros2_rt/install/local_setup.bash

We can now change the DDS implementation to use as explained in the Working with multiple ROS 2 middleware implementations tutorial.

FastRTPS vs Eclipse Cyclone DDS comparison

As stated in the pendulum demo: “The requirements of a real-time system depend on the application, but let’s say in this demo we have a 1KHz (1 millisecond) update loop, and we’re aiming for a maximum allowable latency of 5% of our update period.” For our tests, instead of taking the maximum allowable latency of 5% of the update period (50000 ns) a 3% limit has been chosen as shown in the Real time Performance in ROS 2 ROSCon 2015 presentation.

The images below show the jitter results of the pendulum demo using eProsima FastRTPS DDS (in blue), Eclipse Cyclone DDS (in red) and the 3% (30000ns) maximum jitter as a black dashed line for 2 different executions of the demo.

fastrtps_vs_cyclone_hikey970

We can see that the maximum allowed latency is violated in the first instant of the demo which could be linked to initialization and/or memory allocation tasks. Apart from this, the latency for both DDS implementations is well below the maximum allowed for the system.

Further investigation would be needed to identify the different behaviour of the DDS implementations on subsequent runs of the demo, which is out of scope of this initial test.

Conclusion

Although there are a number of items that still need to be addressed to get a fully real-time compatible system using ROS2, these first steps allow to start developing soft real-time applications using 96boards hardware and ROS2.

For our next post, we’ll look into getting the Qualcomm® Robotics RB3 Development Platform also ready for real time application development, so keep an eye to this space.

This article is Part 2 in a 4-Part Series.