ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Why is ROS not real time?

asked 2014-02-28 12:31:57 -0600

rosrunner gravatar image

I realize that ROS is not real-time OS. I read the architecture of ROS and am unable to realize why is ROS not real-time? What part of the architecture or what design decision is causing that?

edit retag flag offensive close merge delete



I guess it's you who opened this thread too, where you've got an insightful link.

130s gravatar image 130s  ( 2014-03-01 00:42:09 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2014-02-28 13:14:01 -0600

ahendrix gravatar image

updated 2014-02-28 20:58:45 -0600

There are a few reasons here. The simplest is that ROS is not realtime because it is built on top of linux, which is not inherently realtime.

The longer answer here goes back to the definition of a realtime OS. In particular, realtime software provides a set of time guarantees around certain operations; usually these can include process scheduling, IO, and inter-process communication.

While ROS is fast, and is used for online operation in many robots, it is inherently best-effort in many cases, and does not provide guarantees about the timing of operations. This means that you should not use ROS for operations that have strict timing requirements, such as high-frequency PID and motion control.

Many ROS robots will implement their timing-sensitive operations either on an embedded controller which communicates with a computer running ROS, or as a ROS node with separate realtime threads that communicate through a non-blocking API to ROS threads within the same node. The latter approach here requires a linux kernel with special realtime extensions that help guarantee realtime scheduling of user-space threads.

Some of the particular things that ROS does that can violate realtime constraints are:

  • Using a network-based transport:
    • Ethernet and IP are unreliable, but have minimal transport latency.
    • Standard switches and routers introduce a non-deterministic amount of latency, particularly when there is other traffic on the network.
    • The handshake and retry mechanisms that make TCP reliable also introduce a significant amount of latency.
  • Many of the ROS message types and other APIs do memory allocation internally. In a Linux system, this can cause a context switch which has the potential to break realtime.
  • The ROS message queue will drop messages when they become full.
  • I would study the locking and synchronization mechanisms inside of ROS before using it from a realtime context to make sure that there isn't the possibility for a priority inversion somewhere.
edit flag offensive delete link more



Is the usage to TCP/IP for inter-process communication also one of the reasons?

rosrunner gravatar image rosrunner  ( 2014-02-28 13:41:15 -0600 )edit

Great information, that's what I was searching for! I will patch my Jetson TK1 kernel with real-time features to use CAN sockets and link that to ROS.

Cyril Jourdan gravatar image Cyril Jourdan  ( 2016-10-02 05:02:56 -0600 )edit

answered 2014-03-02 16:24:43 -0600

Ryohei Ueda gravatar image

I'm controlling an industrial robot (DENSO) on realtime and the control cycle is 8msec (It's a conservative parameter).

The configuration is:

[ROS MACHINE] <--||ether||--> [Robot Controller PC] <--> Robot

The ROS MACHINE uses low-latency kernel and the thread which communicates with Robot Controller PC runs as a RT process (max pthread priority).

And the communication between ROS MACHINE and Robot Controller PC is on UDP/IP. The protocol is not ROS topic/service communication and it's a special stuff provided by the Robot Controller PC.

I found that TCP/IP communication is not reliable in order to achieve realtime communication over ethernet.

edit flag offensive delete link more

Question Tools



Asked: 2014-02-28 12:31:57 -0600

Seen: 27,568 times

Last updated: Mar 02 '14