What is the right RTOS for a humanoid robot? [closed]

Question

We're students developing a mid-size (~ 4.5 feet tall) humanoid robot as a sponsored research project in college. The major tasks that the robot should be able to perform include: moving around (forward, backward, sideways), running, picking up objects. We're considering using a hard real-time operating system to control the robot. However, since we're new to this field with practically no background in embedded systems or operating systems, and there are a wide range of options available, we're not sure which one would be a suitable choice. We've come across the following (in brackets is our current impression of them):

1. RTLinux (now dead, kernel 2.4.x, gcc 2.95 (so difficult to build), little to no documentation)
2. FreeRTOS (good community and documentation, popular, ported to many architectures)
3. uc-OS II (small, clean core, light-weight)
4. RTAI (Linux-based)

I have a number of questions:

1. Which of the options would be better suited for this project? I know this sounds a little subjective, but any advice would be greatly appreciated. If you feel some important information is missing, please do point that out.
2. I've come across something called the CONFIG_PREEMPT_RT patch for the Linux kernel, which grants hard real-time capabilities to the kernel. There are also pre-compiled kernels with this patch available for Debian-based distributions. Would that alone be sufficient for our requirements?
3. We have very little knowledge of operating systems in general. Is it necessary for us to learn about them first? If yes, what is a good, short primer to the subject?

UPDATE: Thank you for your incredibly detailed answers. It's clear that we're going about this the wrong way; diving in with no knowledge and vauge requirements certainly would be bad. We'll have to sit down and chalk out exactly what we need. As and when we're sufficiently ahead with that, we'll try to figure out a suitable OS. Let's see how that works out. I'm also going to read Chapter 2 of MicroC OS II: The Real Time Kernel.

Router

The OS decision should not be the first decision you make. Design your system solution first and then look at it (or ask) to find an OS that meets the system requirements and constraints. None of the OS requirements can be directly determined from your list of high level behaviours. – Adriatic

Answer 1

Your choice of OS is unlikly to be determined by the "humanoid robot" constraint, there is no specific "humanoid robot OS", and certainly no OS would be determined by how tall such a robot is! ;-) ! The critical factors are

• real-time constraints (for motion control PID update, sensor/actuator reaction time etc.)
• processor architecture
• system architecture (e.g. distributed processing, symetric-multiprocessing)

Other factors may be important such as:

• Communications and I/O requirements (e.g Ethernet, TCP/IP, USB, WiFi).
• File system support

although these need not necessarily be an intrinsic part of the OS in all cases, since third-party platform independent libraries are available in many cases, but where you need them, integration with the OS can be helpful since it avoids you having to deal with thread-safety and resource locking yourself.

Neither of the options you have suggested would likely make into my list.

Anything Linux based will require an MMU (unless using uCLinux or its derivitives, but MMU support is one of the few good reasons for using Linux in an embedded system). Linux is not intended to be a real-time OS and any real-time support it has is pretty much an after-thought, and will seldom be as deterministic as a true RTOS. Any Linux will also require significant memory resources just to boot-up, expect a minimum of 4Mb of RAM for anything usable, while RTOS kernels such as FreeRTOS and uC/OS-II require only about 4Kb - you are comparing chalk with cheese here. That said they do not have the utility of a Linux based OS such as file-systems, or networking support (although those can be added as stand-alone libraries).

If you are going to be performing the motion-control and sensor/actuator functions on the same processor as your cognitive functions, then you certainly need a deterministic RTOS. If however the platform will be a distributed system with separate processors dealing with motion-control and other real-time sensor/actuator I/O, then you may get away with a simple RTOS kernel or no OS at all in the I/O processors (which can also then be smaller, less powerful processors) and a GPOS in the cognitive (decision making and planning) processor.

I have evaluated FreeRTOS recently, it is minimalistic, simple and small, providing only the basic threading, timing and IPC mechanisms and little else. It works, but so do many other more attractive options, both commercial and non-commercial. I compared it with Keil's RTX kernel (included with their MDK-ARM tool suite), and the commercial Segger embOS. It has significantly slower context switching time that the other two candidates (though still in the microseconds on a 72MHz Cortex-M3, and faster than anything you are likely to achieve with Linux).

uC/OS-II is well designed and documented (in Jean Labrosse's book), and is great if you aim were to see how an RTOS works. Its biggest failing is its very restrictive priority scheduling scheme, which is efficient for very small targets, but possibly not as flexible as you might like. Each thread must be assigned a distinct priority level so it has no support for round-robin scheduling, useful for non-real-time background tasks. uC/OS-III fixes that shortcoming, but again so do many other options.

If your target processor has an MMU I strongly suggest the use of an OS that supports it in such a way that each thread or process is protected from any other, the system will be far more robust and easy to debug, especially when developed as a team. In such an OS an errant task that would otherwise stomp on some other thread's resources with non-deterministic and generally hard to debug results, will instead cause an exception and halt right where the error occurred, rather than perhaps sometime later when the corrupted data gets used.

You probably need not restrict yourself to a free or open-source RTOS, many vendors allow free use for education and evaluation. I would strongly suggest that you consider QNX Neutrino, it is free for non-commercial and academic use, and has the most robust intrinsic MMU support available in any RTOS, and all the development tools you need including the Eclipse based Momentics IDE are included. It is more than just a mere scheduling kernel, including support for all the services you would expect of a complete OS. It runs on ARM, x86, SH-4 PowerPC and MIPS architectures. Running on x86 is particularly useful since it means you can test and evaluate it, and even develop much of your code in a VM running on your desktop.

Another alternative that is true hard-real-time, while supporting OS services beyond mere scheduling and IPC, is eCos. It has a native, POSIX and uITRON API, standard drivers for CAN, ADC, SPI, I2C, FLASH, PCI, Serial, Filesystems, USB and PCI and more, and includes TCP/IP networking support. It is a complete OS in that sense, but unlike Linux is not monolithic; it is scalable and statically linked to your application code, so that features you do not use are simply not included in the runtime binary. It runs on ARM, CalmRISC, Cortex-M, FR-V, FR30, H8, IA32, 68K/ColdFire, Matsushita AM3x, MIPS, NEC V8xx, PowerPC, SPARC, and SuperH. Again in theory you could run the IA32 (x86) port it on a VM on a PC for test and development of high level code, though you'd have to get that working yourself unlike QNX's out of the box evaluation.

Added regarding:

We have very little knowledge of operating systems in general. Is it necessary for us to learn about them first? If yes, what is a good, short primer to the subject?

This then is perhaps not the time to start learning Linux (although it has the advantages of wide familiarity and community support, it has a lot of stuff you will not need, and a lot of available support resources will not be familiar with real-time control systems applications.

Chapter 2 of Labrosse's uC/OS-II book gives a general overview of RTOS concepts such as scheduling, synchronisation and IPC that are applicable to most RTOS not just uC/OS-II. Similar material is presented in Jack Ganssle's recent RTOS Fundamentals course on EETimes (it is similar perhaps because it is sponsored by Mircium and uses uC/OS-II as a case study, but it is similarly general for the most part).

My solution to getting a quick start in any subject is to Google the subject with "101" after it (a common introductory course number in academia). "RTOS 101" will get you some starting points of admittedly varying quality - check the reputability of the source, if it is a company, they may be peddling a specific product, if it is a hobbyist, they may have some insights, but perhaps a narrow view (often relating to specific favourite hardware), and may not have the rigour of an academic paper.

Added regarding CONFIG_PREMPT_RT:

It does not render Linux a hard real-time OS. It may be suitable for some applications. If you are doing PID motion control (rather than using a dedicated controller or separate processor), or any kind of closed loop feedback control for that matter, this patch will not enable it in my opinion, at least not reliably. I found this: A comparison of real-time Linux approaches. It discusses a number of approaches to using Linux in real-time applications, including CONFIG_PREMPT_RT. It discusses these in detail in part C.

Adriatic

Thanks :). You rightly point out that we need to figure out the requirements in more detail first. I'm also taking your suggestion for Labrosse's book, I think that should provide a good starting base for further knowledge. – Router

By the way, do you know anything about the CONFIG_PREEMPT_RT patch? What do you think of it? – Router

@VickyChijwani: I added a not to the answer regarding CONFIG_PREMPT_RT, but I an no expert. My expertise on embedded Linux extends only to understanding that there are very few reasons that would make me want to use it. – Adriatic

Just came across this: download.dedicated-systems.com May be helpful to you. – Adriatic

Clifford, I read that you've try Keil's RTX kernel (MDK-ARM) and SEGGER's embOS. I yould like to hear from you what you think of them and which one would you recommend. Thanks. – Joannejoannes

@Vincent: RTX was not mature on Cortex-M when I used it - we found a number of bugs, and it did not have flexible support for CM3 interrupt priority grouping (a fact hidden deep in the documentation which we overlooked). That situation has changed somewhat since then and the CMSIS v3 now includes low-level code to RTOS implementation, so I would expect that RTX may now be based on that. RTX had marginally faster context switch times than embOS, but that may have been at the expense of correct and reliable operation - the fixes applied since may have changed that. – Adriatic

Answer 2

This doesn't answer the specific question, but:
Before you ask for advice on a specific OS, you need a lot more details about the architecture and constraints.

I'd start with the I/O:

• How do you interact with the outside world? How many sensors?
• What kind of motors drive the robot? How many? How are they driven?
• What kind of sensors do you need for the motor control feedback?
• What about body position feedback?
• Have you done any systems analysis?
  
  • What update rate do you need to maintain stablity?
• What other tasks need to run?
  • Vision?
  • Audio recognition
  • Audio generation?

Now that you know what you need to control and how fast, how do you control it?

• Do you use a micro-controller with embedded A/D capability?
• Or a PC with a plug-in A/D card?
• Is one processor fast enough or do you need multiples
  • If more than one, how will they synchronize?

At this point you can start considering specific processors and architectures. Only after you have narrowed it down to one or two good options, should you start to consider the OS.

I do expect that you will end up needing a Hard Real-Time OS for the motion control aspects of a running robot.

Spud

Thanks a lot :). We'll keep this list in mind, sketch out the details as much as possible, and then try to look for an appropriate OS. – Router

Answer 3

It may not be necessary to run the Linux in hard real-time. Given a 4.5ft tall humanoid with CM at say 3ft, your control loop can run at 20hz and you can still digest your IMU signals and prevent the thing from falling. Normal embedded Linux that isn't running a counterstrike game server in parallel to controlling the robot's motors will give you reliable event handling at least at 50hz even without even "nice"ing the robot's control process. (assuming you will run your Linux on a RoBoard or FitPC). In any case, it is probably easier to recover from a missed frame than to run RT linux. Getting the kernel to run so that it reliably calls your handlers upon an interrupt within X microseconds (ie: real-time) involves what would be considered by some as non-trivial and with some side effects.

You may be better off having another microprocessor board that does some low level talking to the motors/servos and relays digested information to the Linux.

In our project ActuatedCharacter.com we managed to get a control loop between a RoBoard.com Linux and 20 (dynamixel) servos (with custom firmware) at over 200Hz with an FTDI interface to the servos and without any real-time kernel modifications. If you are considering using dynamixel servos as actuators, please check out robosavvy.com forums for general information about building humanoid robots (for robocup or for general research), alternative firmware for better closed loop control rates, issues with FTDI latency, serial controlled servos. Also consider the software framework you want to develop, which in turn will help you with your requirements. Obviously talk to established Robocup humanoid league teams but also of interest are inriaflowers, NAO/Aldebaran and ofcourse ROS.

Margaretemargaretha