| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
Dear all,
The doc for ros_control says controller_manager provides a hard RT loop.
Thanks,
Antoine.
The doc for ros_control says controller_manager provides a hard RT loop.
knowing that ROS is designed for non-RT OS (plain linux), how is that possible on a non-RT OS?
It isn't. Not without first making Linux capable of some deterministic scheduling and execution.
Two well known ways to add deterministic scheduling to a Linux system are to patch the kernel with the RT PREEMPT patch, or to install the Xenomai co-kernel next to it. The PR2 (which runs the pr2_mechanism package, the precursor to ros_control) has an RT PREEMPT patched kernel.
Whatever system is used, 'real-time-ness' can be configured with a per-thread granularity. So even if 'the rest' of ROS is not inherently real-time, parts of nodes can be made to be deterministically scheduled and executed. In the case of ros_control, the main loop responsible for executing all the instantiated controllers is an example of such a real-time thread. As such, the controller plugins themselves execute in a real-time context.
The fact that ROS itself (which is an ambiguous thing to say anyway) is not real-time does not really matter.
The only thing you need to take care of now is to make sure that you can safely communicate with the real-time parts of your node.
how does that relate to package realtime_tools ?
One of the main issues when programming on / within real-time (sub)systems is breaking the determinism achieved by the scheduler. To avoid this -- without a priori checked execution times and things like time-slicing and round-robin -- every process under the real-time scheduler basically has to make sure it doesn't hog the cpu for too long (ie: it should yield often enough). Any service (not a ROS service, but a syscall fi) that a process depends on which cannot be interrupted could potentially make this impossible. Memory allocation is one such service: if an allocation request results in a page fault, all bets are off wrt how long it takes the OS and the hardware to handle it. Locking of resources between non- and real-time threads (mutexes, semaphores) is also something that needs to be done with care, as priority inversions might cause undesirable scheduling latencies.
The realtime_tools package provides implementations of the ROS publish and subscribe mechanism that take these limitations into account. Memory allocation in the real-time components is done in the initialisation phase, and all dynamic message handling is done by non-real-time helper threads that would not cause any problems if they did require non-real-time safe services.
Some related questions (which I did not see in the Related questions box:
Hello @gvdhoorn and thanks for taking the time to answer. 1. What I understand from your links (and others) is that so long as you are not looking for high-end control you can get your control loops processed on a vanilla linux kernel, can you confirm? 2. Now, the feeling I have is that no clear architecture (RT OS, EtherCat driver) emerges as a standard for RT yet and everybody seems to have solutions which are hacky on the edges. Anyone has some updated insight on the matter?
You'll have to clarify what you mean with "high-end control" and "architecture [..] as a standard for RT". How would you like to see things being done? All real-time systems I've worked with are composed of real-time and non-real-time components, interacting through some sort of shared memory. That will always require some special care wrt locking, allocation and other potentially blocking services. Unless your entire OS and runtime are real-time capable of course.
Ok so my guess is that you can do this with a vanilla linux kernel if you are ok with a rough accuracy (say ~2cm), but this requires a RT patch as synchro between motors is critical.
Now what I meant about the architecture is that people using rt_preempt tend to observe jitter pikes and eventually turn to xenomai, without things being clear on why pikes occur with rt_preempt (as theoretically they should not occur). So my feeling is that there is not clear choice yet on which RT patch is best suited to robotic control. People start with rt_preempt and turn to xenomai because it does work but do not know why.
Any comment on this?
I don't think you can make any statement about real-time systems 'in general'. The only way to know whether soft or hard real-time, or even best effort, is good enough for your application is by measuring it. If you really require real-time determinism (or your requirements state it), install a real-time OS.
Also: this seems to go out-of-scope a bit. Your original question was about ros_control and how they can guarantee real-time execution of your controllers. Your follow-up comments would best be answered in a separate question, imo.
Asked: 2014-08-26 09:14:03 -0500
Seen: 3,122 times
Last updated: Aug 26 '14
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
