ROS (Robot Operating System) is a software environment (i.e., middleware) providing a set of tools to connect multiple parts of a robotic setup. It offers nice features to interface with a wide range of sensors and actuators. However, it does not natively provide any strict real-time guarantees. Yet, many modern-day robots have a strong need to achieve a deterministic, time-bounded behaviour (e.g., mobile robot collision avoidance).

The aim of the project is to determine how real-time capabilities can be brought to ROS. The first step would be to identify the existing real-time extensions, and carry out a comparative study about each of them. The next step would be to setup the installation process for a real-time environment using ROS and Linux/Xenomai. The final step will consist in developing and testing real-time ROS nodes.



What’s hard real-time computing ?

  • It’s about determinism, not performance.
  • Correct computation delivered at the correct time
  • Failure to respond is as bad as a wrong response
  • Missing a deadline is considered a system failure.
  • It is mandatory for safety or mission-critical systems.

On the top figure, each bar represent a task and the time at which it’s executed. The red line represents a deadline. If a task is executed after the deadline, it is considered - in hard real-time systems - a failure. It has a different behaviour for firm or soft real-time systems. For firm constraints, a task that was executed after the deadline will not cause a system failure, but its behavior (i.e. computations) won’t be considered. For soft constraints, the behavior will be considered with a non-critical warning.

Why do we need it ?

Let us take a self-driving car as an example : your system includes many actuators, sensors, and use them to operate in a environment with a changing environment including people, animals, moving obstacles… For a robot operating in an empty facility, the constraints are less critical, but for our example, it is necessary to operate with caution. You need to make sure the robotic system stops before a human can be hurt. If anyone gets hurt, it’s too late for computing as the system already failed to do its job.

While this constraint is actively applied, another can be too : a task fails for instance if a LiDAR scan fails, it’s not as critical as the prior safety constraint, but a failed scan cannot be used later because the car is always moving, the data, if retrieved too late, should be considered corrupted and the perception system fails the task.

The system must focus on not hurting human fast enough if it were to happen, as well as retrieving data fast enough so that it’s usable. But two tasks cannot happen at the same time, so what happens when both those failures happen ?

In our example, the constraint not to hurt humans (i.e. dodging) will be given a higher priority. If at some point a human walks into the “danger zone” and the lidar is late on delivering info, then the safety constraint will preempt any other lower-ranked constraints.

A real-time system must complete a task, or a set of tasks, on time. It doesn’t have to be fast, it should be on time.

ROS vs ROS2

Initially, ROS was developed to program with flexibility (hardware abstraction) a single robot. This robot had no real-time constraints, and was operating with great network connectivity. It also allowed you to develop nodes that could work on both humanoids and ground wheeled robots.

As the community made ROS grow through home and industrial projects, the limits were highlighted when projects with new constraints were developed :

  • Swarms
  • Embedded ROS
  • Real-Time Systems
  • Unstable networks

Due to how and why ROS was conceived, the community and OSRF (Open Source Robotic Fundation) deemed that ROS would stay as is, and that ROS2 would be conceived with those new constraints in mind, as those very intrusive and specific use-case (but important) projects could hurt the on-going and past projects.

Requirements

We need an OS able to deliver the determinism we need. For Linux variants, the Linux kernel itself is NOT real time and has a max latency of roughly 10^4 µs. RT PREEMPT is a soft real-time OS and has an average max latency between 10 and 100 µs. The later will be the one we use, as Xenomai is hard real-time and has an average max latency of 10 µs. (x86, traditional PC architecture)

Supervisors:

  • Prof. Audrey Queudet
  • Prof. Vincent Lebastard

Contributors:

  • Sampreet Sarkar sampreet.sarkar@eleves.ec-nantes.fr
  • Erwin Lejeune erwin.lejeune@eleves.ec-nantes.fr

References:

Wei Hongxing, Shao Zhenzhou, Huang Zhen, Chen Rennaim Guan Yong, Tan Jindong, Shao Zili(2015).”RT ROS: A real-time ROS architechture on multi-core processors”

Delgado Raimarius, You Bum-Jae, Choi Byoungwook. (2019). “Real-time Control Architecture Based on Xenomai Using ROS Packages for a Service Robot. Journal of Systems and Software.”

Ching-Chung (Jim) Huang, Chan-Hsiang Lin, Che-Kang Wu. “Performance Evaluation of Xenomai 3”