ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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.
2 | No.2 Revision |
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.
3 | No.3 Revision |
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:
4 | No.4 Revision |
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: