A real time system is not really required for many (most?) robotic control systems. As long as you have a control loop that runs fast enough, with low enough jitter, and doesn't miss too many cycles, then this is quite adequate for robotic control and servoing.

As evidence of this, let me present the PR2 and the Shadow Robot Hand:

This robot has about 20 degrees of freedom, all of which are servoed through ROS's main loop. Or how about the Shadow Robot Hand, which also has 20 DOFs, plus an array of tactile and other sensors, and is also servoed through ROS's main loop.

The ROS main loop suffers from a little jitter, sometimes as much as 100us, and even sometimes misses cycles altogether. But it doesn't matter if 99.9% of cycles are executed successfully.

The use of many cores within the host PCs means that one whole core is dedicated to running the main loop, and so it is very rarely delayed by other tasks.

The main reason for using a really real-time OS for a robotic system is for safety. If the robot is working in a safety critical situation, then it is your responsibility to guarantee 100% control up-time, and part of this is guaranteeing the real time nature of it.

Whether you use a real-time OS or not, your servos should do something safe in the event that the control loop dies entirely. This safety system would also be helpful on the rare occasion your non-real-time OS skips more than a cycle. For example, on the Shadow Hand, the motors are halted if the control loop misses more than 20 cycles (20ms). I have never seen this happen though.

A real time system is not really required for many (most?) robotic control systems. As long as you have a control loop that runs fast enough, with low enough jitter, and doesn't miss too many cycles, then this is quite adequate for robotic control and servoing.

As evidence of this, let me present the PR2 and the Shadow Robot Hand:

This robot has about 20 degrees of freedom, all of which are servoed through ROS's main loop. Or how about the Shadow Robot Hand, which also has 20 DOFs, plus an array of tactile and other sensors, and is also servoed through ROS's main loop.

The ROS main loop suffers from a little jitter, sometimes as much as 100us, and even sometimes misses cycles altogether. But it doesn't matter if 99.9% of cycles are executed successfully.

The use of many cores within the host PCs means that one whole core is dedicated to running the main loop, and so it is very rarely delayed by other tasks.

The main reason for using a really real-time OS for a robotic system is for safety. If the robot is working in a safety critical situation, then it is your responsibility to guarantee 100% control up-time, and part of this is guaranteeing the real time nature of it.

Whether you use a real-time OS or not, your servos should do something safe in the event that the control loop dies entirely. This safety system would also be helpful on the rare occasion your non-real-time OS skips more than a cycle. For example, on the Shadow Hand, the motors are halted if the control loop misses more than 20 cycles (20ms). I have never seen this happen though.

Added

Another way to think about it is this: What update rate does your servo system actually need? If it's a largish arm, and doesn't need super high performance, high speed positioning, then 500Hz might be sufficient. For driving around, 200Hz is probably sufficient. In both of these cases, if your loop is actually running at 1000Hz, then a late or missing cycle really is no problem at all, as long as your control algorithm takes into account the actual elapsed time between loops.

A real time system is not really required for many (most) robotic systems. As long as you have a control loop that runs fast enough, with low enough jitter, and doesn't miss too many cycles, then this is quite adequate for robotic control and servoing.

As evidence of this, let me present the PR2 and the Shadow Robot Hand:

This robot has about 20 degrees of freedom, all of which are servoed through ROS's main loop. Or how about the Shadow Robot Hand

A real time system is not really required for many (most?) robotic control systems. As long as you have a control loop that runs fast enough, with low enough jitter, and doesn't miss too many cycles, then this is quite adequate for robotic control and servoing.

As evidence of this, let me present the PR2 and the Shadow Robot Hand:

This robot has about 20 degrees of freedom, all of which are servoed through ROS's main loop. Or how about the Shadow Robot Hand, which also has 20 DOFs, plus an array of tactile and other sensors, and is also servoed through ROS's main loop.

The ROS main loop suffers from a little jitter, sometimes as much as 100us, and even sometimes misses cycles altogether. But it doesn't matter if 99.9% of cycles are executed successfully.

The use of many cores within the host PCs means that one whole core is dedicated to running the main loop, and so it is very rarely delayed by other tasks.

The main reason for using a really real-time OS for a robotic system is for safety. If the robot is working in a safety critical situation, then it is your responsibility to guarantee 100% control up-time, and part of this is guaranteeing the real time nature of it.

Whether you use a real-time OS or not, your servos should do something safe in the event that the control loop dies entirely. This safety system would also be helpful on the rare occasion your non-real-time OS skips more than a cycle. For example, on the Shadow Hand, the motors are halted if the control loop misses more than 20 cycles (20ms). I have never seen this happen though.