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

Revision history [back]

click to hide/show revision 1
initial version

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, 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.

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.

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 also introduce a non-deterministic amount of latency, particularly in the face of 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.

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 also introduce a non-deterministic amount of latency, particularly in the face of 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, context to make sure that there isn't the possibility for a priority inversion somewhere.