RT limit of ROS

RT limit of ROS

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

955 ●67 ●83 ●98

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... ;)

Thanks,

Antoine.

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

ahendrix

47576 ●179 ●367 ●662 http://namniart.com/

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

Comments

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 ( 2014-06-10 06:20:21 -0500 )edit

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