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

ROS-I Computer - Recommended RT - Operating System

asked 2014-11-22 11:15:40 -0500

updated 2014-11-26 05:50:08 -0500

As far as I found out there are three ways to send data to an industrial robot:

  1. Point Streaming
  2. Trajectory Streaming (like Point Streaming but with velocities added to the stream)
  3. Trajectory Downloading

The third point as I understood needs collision detection already before downloading the trajectory. So this is not ment for heterogenous environments?

The first and the second points are quite equal i guess. ROS-I on my PC can do on-the-fly-visualization and collision detection in realtime. What operating System on my PC/Laptop is needed for being able to use the realtime capabilities of ROS-I? Especially the collision detection? Is RTAI necessary or strong enough? Or is there any recommended RT-upgrade to any specific linux system?

What connection is needed? I guess Ethernet via TCP/IP won't do. Would EtherCAT be usable?


Edit: My Imagination of realtime is yet hard to explain. But to be not too specific, I would rather like to know how realtime ROS-I is. What update rates are possible with ROS-I?

edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted

answered 2014-11-24 04:02:55 -0500

Adolfo Rodriguez T gravatar image

It is my understanding that to use ROS-I you don't need any realtime guarantees. From what I've heard, typical ROS-I applications don't exceed update rates of 50Hz. You should be able to deliver that with decent latencies with a stock Linux kernel.

Something that is not clear from the question is what realtime means for you. At some parts of the question it seems that "realtime" means an update frequency fast enough to allow online visualization, which is in the order of tens of Hz. You typically start requiring some form of realtime scheduling when you need determinism at update rates of hundreds of Hz (or more).

edit flag offensive delete link more


That's some good information! Thank you! I am waiting a little more, may there are some more people who'd like to give me feedback, before closing this question. I now added on my imagination of realtime by editing my Question in the last line.

RosBort gravatar image RosBort  ( 2014-11-25 04:41:12 -0500 )edit

answered 2014-11-26 07:54:13 -0500

Thanks Adolfo for your answer. Just an additional point of clarification, the ROS-I interfaces as originally conceived would allow for individual point streaming. At a low level some driver work this way (i.e. points are queued on the PC side and sent to the controller one at a time). Other drivers send the whole trajectory all at once. This difference is primarily driven by the controller. Not all controllers were designed to take points one at a time. Unfortunately, at a ROS level, point streaming is not well supported. Much of ROS is built around calculating a full trajectory before sending it to the controller. Trajectories can be stopped during execution, but altering them was never really supported. All this means that dynamically changing the trajectories on the fly is only available on those controllers that support trajectory streaming and only at a code level (not a ROS message level).

edit flag offensive delete link more

answered 2014-11-26 13:02:26 -0500

corb gravatar image

updated 2014-11-26 13:06:02 -0500

A lean C++ TCP/IP app on standard Linux can achieve latency in the order of 100 micro-seconds without a lot of jitter (only caveat is you need all power mgt disabled in BIOS). With the large amount of processing needed for ROS/visualization/collision detection, a standard version of Linux will not likely be the limiting factor. If you need sub 100 micro-second, you will need an RT OS.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2014-11-22 11:15:40 -0500

Seen: 283 times

Last updated: Nov 26 '14