Software real-time of ROS system

Question

As far as I know, a hardware real-time robot control system requires a specific computing unit to solve the kinematics and dynamics of a robot such as interval zero RTX, which assigns CPU cores exclusively for the calculation, or a DSP board, which does exactly the same calculation. This configuration makes sure that each calculation is strictly within, maybe, 1 ms.

My understanding is that ROS, which runs under Ubuntu, doesn't have a exclusive computing unit for that. Kinematics and dynamics run under different threads of the same CPU which operates the Ubuntu system, path plan, and everything else.

My question is that how does ROS achieve software-real time? Does it slow down the sampling time to maybe 100ms and makes sure each calculation can be done in time? Or the sampling time changes at each cycle maybe from 5ms, 18ms, to 39ms each time in order to be as fast as possible and ROS somehow compensates for it at each cycle?

Answer 1

Short answer: it doesn't compensate at all.

ROS is generally not considered a real-time OS. You usually need specialized hardware and software to implement a real-time OS. The communication line and bus needs to be specifically designed to minimize lag, and the software needs to be written to be 'clock centric'. A real-time OS is built to do things at certain times, not to do as many calculations as it can in a certain amount of time. Unless you're running ROS on a real-time variant of Linux, and on hardware designed to operate with it, ROS won't operate in real time. Even then, you would probably have to modify or redesign ROS and the packages you want to use to operate primarily by the clock, instead of 'at their leisure'

Generally, you do not need an real-time OS for robotics. Usually, you only see it in aerospace applications, specifically rocket motor control. Getting from point A to point B using a rocket motor requires split second timing. If the motor goes for even a half second too long or too short, it will miss it's target velocity (and so, overshoot or undershoot it's target). Robots do not usually require this level accuracy in timing. We're more concerned about our creations doing it right, instead of doing it fast.

Answer 2

You can use Orocos RTT with ROS to achieve some real time performance. In order to use this you need to patch the Linux kernel with a real time patch like PREEMPT_RT or run a real time kernel like Xenomai.

You question about changing the sample time seems to actually miss the point of real time computing. Real time is not about doing calculations fast, it is about doing calculations within the required time frame. A rocket control system probably needs an update rate of several kHz, whereas a nuclear power plant is working more in the Hz range. Nevertheless, the power plant definitely needs real time computation. Basically it is up to you to set the required update rate, then the system can tell you if it can meet those demands. If you are working with hard real time, missing the deadline means a failure of the program and it should start a shut down procedure. Soft real time accepts some deviation but will know when the deadlines are not satisfied.

If you are working with balancing robots, e.g. segways, you will probably want update rates around 1 kHz hard real time. If you are doing trajectory following with a stable robot 100 Hz soft real time seems reasonable.

Answer 3

Hard real time : What ever time cycle you are setting for your loop, it should strictly follow that. In most of the robotics system they follow the cycle time to be 1ms.

You can go to this link for more information of above image. Current ROS version are having TCPROS (non realtime) for their node to node communication but in ROS2, the community is redesigning ros for hard real time application and instead of TCPROS they are using DDS (Data Distribution Service) for node to node communication.