0
$\begingroup$

Rosanswers logo

Hello,

I am new to real-time control in ROS. When I looked up it in this wiki, integrating ROS and OROCOS and using Xenomai seems to be a good solution for it. I don't have a high level understanding of the advantage of using them. If you could share your insight into it with me, I would really appreciate it.

I can enumerate several possible set-ups for real-time control in ROS although some of these may not make sense.

  1. ROS on Ubuntu
  2. ROS on Xenomai patched Ubuntu
  3. ROS+OROCOS on Ubuntu
  4. ROS+OROCOS on Xenomai patched Ubuntu

We may scarcely be able to expect any good real-time performance on (1). How/why bad is it? Would be there any improvement in using (2) over (1)? How would (3) be different to (4) in real-time performance? Do you have any other recommended set-up? Dose it need to be broken down into some subdivided set-ups?

Thank you very much in advance.


Originally posted by dj on ROS Answers with karma: 1 on 2013-04-19

Post score: 4

$\endgroup$

3 Answers 3

0
$\begingroup$

Rosanswers logo

You can only get good realtime performance with option 4. The OROCOS RTT toolkit provides realtime behaviour but only on a kernel with a realtime extension. The other options can also give good performance but it will vary a lot. See also this: http://answers.ros.org/question/9500/what-realtime-patch-should-i-use-with-ros/

A good example is how the realtime controllers of the PR2 work. ROS runs non realtime while the controller manager (which uses the RRT toolkit I think) is realtime.

image description http://pr2support.willowgarage.com/wiki/PR2%20Manual/Chapter7?action=AttachFile&do=get&target=mechanism_control.png From:http://pr2support.willowgarage.com/wiki/PR2%20Manual/Chapter7#Realtime_Loop


Originally posted by davinci with karma: 2573 on 2013-04-19

This answer was ACCEPTED on the original site

Post score: 7


Original comments

Comment by dj on 2013-04-19:
Thank you very much for your answer. I'd also like to know the advantage of using OROCOS. If both a ROS node and a OROCOS component can be real-time priority threads, what makes OROCOS on Xenomai better perform than ROS on Xenomai?

Comment by Thomas D on 2013-04-19:
http://engineering.oregonstate.edu/mailman/archives/public/ethercat-ros/ -- That mailing list has a lot of discussion about using ROS in a real-time system.

$\endgroup$
0
$\begingroup$

Rosanswers logo

Hi, I've mainly used option 2. Theoretically options 2 and 4 should give you the same performance. The benefit of OROCOS is that it makes the integration easier, and makes it possible to switch between different real-time Kernels. OROCOS also provides many other tools to help develop real-time applications, such as methods for real-time modules to communicate with each other.

So your list should include options 5,6, etc. for other real-time Kernels.

e.g. Option 5, ROS on Preempt patched Ubuntu (this is what the PR2 uses)


Originally posted by dbworth with karma: 1103 on 2013-04-25

This answer was NOT ACCEPTED on the original site

Post score: 1

$\endgroup$
0
$\begingroup$

Rosanswers logo

In our research group we have used OROCOS for several years, and have hired some of the OROCOS developers as consultants to help us tune the real-time performance of our system. I would recommend starting with the easiest to set up system (ROS on a vanilla kernel, components written in Python), and make the following upgrades ONLY as necessary after MEASURING your current performance, and ONLY to the parts of your system that NEED it:

  1. Make sure you have your components/nodes that need it running with real-time priority
  2. Upgrade your kernel to one with the PREEMPT_RT patches applied
  3. Dedicate a fraction of the cores on your CPU (if multicore) to your real-time processes, make sure the non-critical processes are launched on the other cores.
  4. Port components to C++ if delays within the components are the bottleneck
  5. Port components to Orocos if delays of message transmission between components is the bottleneck
  6. Install Xenomai kernel and recompile against it's API's (at this point you are pretty deep into black magic territory; the only people using this are either operating obscenely tight control loops, or implementing safety-critical systems)

Never make any assumptions about where your bottleneck is; ALWAYS measure at every stage of development. Rules of thumb like "avoid dynamic memory allocation" and "only use low-level systems programming languages like C/C++/Fortran" come secondary to this.


Originally posted by drewm1980 with karma: 258 on 2014-05-10

This answer was NOT ACCEPTED on the original site

Post score: 5

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.