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

RT limit of ROS

asked 2014-06-06 02:32:07 -0600

arennuit gravatar image

Dear all,

As we know ROS is not a RT system (due to its use of TCP/IP, memory allocations in messages...). Hence I was wondering whether you could build systems such as the one in this Maxon Epos 3 EtherCAT demo with ROS.

I guess that a typical ROS architecture will have the high level planification computed onto the ROS PC (i.e. the desired joints position and velocity will be computed within ROS). Now what I understand is that if the low level controllers do not receive these instructions at the same time (due to non-RT transport) then the instructions will not be executed simultaneously by the motors. This would result in the 2 wheels shown in the video not aligned well enough for the pins of one wheel to match the holes of the other wheel.

Am I right? If I am wrong, does this mean the +-1 ms error typically found in ROS transport is negligible for such mouvements coordination ? I fear you'll tell me it depends on the speed and the configuration of the system and task and there is no other way but trying... ;)



edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2014-06-06 11:49:07 -0600

ahendrix gravatar image

The EtherCAT bus is designed so that you can send a command to all devices on the bus simultaneously, so as long as you have a single ROS node responsible for sending commands, you may have some jitter between commands, but you should be able to keep the motors in sync.

If you're building a precision motion system like the one demonstrated in the video, you should have a good understanding of the required control frequency and jitter tolerance before you start building your system.

It is possible to achieve high-speed, low jitter motion control on linux, but you'll need to use a real-time linux kernel. For example, the PR2 has a 1kHz motion control loop, with a few dozen microseconds of jitter, running the realtime fork of the linux kernel.

Be aware that the stock linux kernel isn't designed for real-time applications, and will occasionally block user processes for a few milliseconds while it does housekeeping. This may be acceptable if your control loop only needs to run around 50Hz.

Finally, if you're looking at expensive realtime control products from a specific vendor, I STRONGLY suggest you contact the vendor to get their input on your use-case.

edit flag offensive delete link more


Right, but what if my non-RT ROS is preempted by the kernel while sending EtherCAT frames? Imagine ROS sends the command to the first motors and is preempted before finishing? The commad will arrive to the first motors before arriving to the other motors, no?

arennuit gravatar image arennuit  ( 2014-06-10 06:20:21 -0600 )edit

This can't happen if you structure your EtherCAT packets correctly. Please go read the EtherCAT spec.

ahendrix gravatar image ahendrix  ( 2014-06-10 15:05:06 -0600 )edit

Haha! Good point, this is the key, thanks!

arennuit gravatar image arennuit  ( 2014-06-11 18:27:11 -0600 )edit

Question Tools



Asked: 2014-06-06 02:32:07 -0600

Seen: 719 times

Last updated: Jun 06 '14