Real Time Operating Systems for autopilots [UPDATED]

If you've been following Tom Pyke's progress on his impressive Gluonpilot, you will have seen that he's implementing it with a realtime operating system (RTOS), rather than programming "straight to the iron" the way most autopilots are done, to gain maximum control over interrupts, timing and the like. He's using a relatively powerful dsPIC chip, which can handle the overhead of the RTOS (I think he's using FreeRTOS, but I've pinged him to find outUPDATE: yes, it's FreeRTOS. See below). Here, he makes the case for a RTOS:

"The main advantage of a real time OS is that you can use threads (which we will use tasks from now on). You don't need to bother anymore about the delay your telemetry processing can cause to your Kalman filter or PID control. No more need for timed loops or Timer interrupt routines. It looks perfect!
There are some things you need to keep in mind:

You need to prioritize every task
Every task has a separate stack. This stack is used for the task itself AND every interrupt routine that may be called during this task's execution
Thats about it! Let's take a look at the different tasks in gluonpilot:
--Telemetry: All the output needed for our groundstation
--ConsoleInput: Processing and answering all the commands you send to the autopilot
--Sensors: Gathers and processes (filters!) all the sensors (gyroscope, accelerometer, gps, pressure sensor) on our autopilot module
--Control: Sends the correct position to the servos! This handles both manual, stabilized and full autopilot modes."

The prioritization of the tasks is as follows:

Read on here.

UPDATE: In an email, Tom explains more:

"Yes I'm using FreeRTOS. Whether you should need to consider it [I had asked him if it would work on a 16Mhz Atmega--chris] is not easy to answer. 16MHz doesn't seem a lot. The dsPic runs at 80MHz (40MIPS) and - I think - has more memory. Using an RTOS does not cause an extreme amount of overhead, but you can no longer push the
processor to its limits:

- You need more memory because interrupts can be executed (and use
the stack) of any running task/thread (and you need to assign a stack
size to every task)

- You need enough spare CPU cycles to make sure all tasks can always
be handled in time.

- And the RTOS needs memory, flash and CPU time of its own

It may sound contradictory, but I started using FreeRTOS to make sure people can easier add code to the autopilot. In the last version without it, the code became complex and critical to change, because of all the timing-critical code and timed loops. Now with the RTOS, people can add lower priority tasks and I'm sure the manual control and time-critical filtering still works. However, you need to keep the design as simple as possible.

The only features I'm currently using is the scheduler (because it's easier than a timed loop) and a queue mechanism for pushing data from an interrupt to a sleeping thread.

There are some RTOS pitfalls such as priority inversions. But it's really up to you how far you want to go. Replacing your timer interrupt routine by a threads wonn't give you any problems you didn't have already. If you use mutexes for mutual exclusion all over your code, than you're down to a more challenging task :-)

In the end, I can only suggest that you play with it for a day or two... port some existing code to FreeRTOS and see how comfortable you are using it. It's not really that complex."

Views: 4565

Comment by David Ankers on December 22, 2009 at 2:10am
I have a fair bit of experience with FreeRTOS, I'm glad you are looking in to it, I actually replied to a comment you made about this earlier. Just to clarify a big misconception, you are still coding "straight on the iron", it is not an OS despite the name used. It is a task scheduler (kernel) with queues and semaphores and avoids writing your own routines for these functions. Basically, the idea is you to make a functions in to a infinite loop and have the kernel grant them time on the processor based on priority. Simply instead of having a single large infinite loop, you code key functions as their own infinite loop; that's it, no hardware abstraction just a different architecture concept.

I disagree with Tom's statement that it is perfect, it is just different, and you certainly can still starve tasks of processor time and need to be very careful with pre-emption as well. It makes some things easier for sure, specifically code architecture structure but has some things you must be careful of as well.

The coolest feature are the stats but these just can't be used in production code as they really take CPU time.
Comment by automatik on December 22, 2009 at 2:19am
I also agree that this is just 'different' approach with benefits and shortcomings - depending what one wants to accomplish. David A.'s comments about scheduling in this context reminds me of famous RTOS 'mishap' with task scheduling (priority inversion) which was the reason NASA lost Pathfinder....A lot of people in robotics industry learned big lesson there (and are still learning as this is commonly used example)...
more info
PPT: Timing and Race Condition


Race condition
Comment by Rana on December 22, 2009 at 3:11am
Seems to be pretty good ! In RTOS you have to carefully select the tick time as this tick has to be very very much smaller than the shortest task in the task list.

After my graduation, I did diploma in RTOS (VxWorks, this RTOS was there in the NASA's Pathfinder to Mars)
According to me, if you have time critical critical tasks then better to go for multi processor environment with RTOS too.

The calssical example is ArduPilot in which all servo's are controlled by ATTiny45 and Navigation & Telemetry is taken care by the ATMega328. Yeah its a multi processor environment and people can extract much more from it using RTOS.

One can also make his own sort of RTOS as per his requirement.

But certainly onething for sure that code programming with RTOS for Autopilots would defenately result in much better performance even if it is a single processor environment.

Chris, I would like to thank you from my heart, for initating this discussion.

Thanks & Best Regards


Comment by Sami Finnila on December 22, 2009 at 4:09am
For some reason it never dawned on me why I liked NXT so much as an AP platform until I saw this blog post: A RTOS is precisely why programming NXT, for example, is so easy and the code is much easier to read and understand. Separate functions instead of tens of interrupts is certainly much more intuitive and simpler. I.e. RTOS is as userfriendly as it get's given some spare CPU time left in the system so that the task priorization isn't too critical. Maybe this'd be something to consider while planning the future versions of ArduPilot..? Or would it be "Ardu-" anymore? Dunnno..
Comment by Sarel P. Wagner on December 22, 2009 at 4:46am
Like every thing else its a compromise. We have Bare metal, RTOS and full OS. Each one of them has advantages and disadvantages. The one you choose, well normally you select one depending a a few things, horsepower available, efficiency, power consumption, shortest time to develop and many more such things. Is the system GUI based with HMI or is a a timing critical embedded system or a game you are developing?

Play them off against each other and select one, it dont mean that one is better or worse than another, its about the compromises you are prepared to make.....

3D Robotics
Comment by Chris Anderson on December 22, 2009 at 8:47am
Please note that I've updated the post with more information from Tom via email.
Comment by Sashi Ono on December 22, 2009 at 9:16am
The use of FreeRTOS co-routines can allow for modular code without the full overhead of task swapping. check out
Basically you don't need a very large stack, because everything is still running in the normal system stack. You do loose the ability to make system blocking calls outside of root of a task. But if you are just using it to decouple your code and for timing loops, you wouldn't have to change much.
I have a fully working FreeRTOS co-routine application working with an atmega168, and am fairly confident that the current ardupilot code could be ported with minimal effort.
Comment by Curt Olson on December 22, 2009 at 9:54am
I have a question for Tom on task timing. What mechanism are you using to schedule your tasks and control the loop timing?

Are you using an interrupt/signal/timer sort of mechanism to launch each task at the appropriate rate? Are you using a sleep/delay at the end of each loop iteration? Are you using a network of intricately woven signal/wait constructs? Something else?

I've seen systems that use a delay at the end of each loop and in fact didn't get the actual loop rates they intended because they didn't account for the kernel tick timer rate and the amount of time required to execute the loop code.

I've seen systems that used an intricate network of signal/wait primitives for all the threads. The end result was that they had implemented a simple linear flow of control using a complicated threaded architecture and if any thread blocked the whole application blocked. They got all the complexity and brittleness of a threaded architecture with none of the benefits.

The only way I can see to do this sensibly and actually get some real benefit from threads is to have a hardware timer(s) generate an interrupt at a regular rate and use that to launch each loop iteration of each thread.

But I'm certainly no expert, so I'm curious what approach you used and curious to see if you've thought of a smarter approach than I've thought of (or that other's whose code I've seen have thought of.)


Comment by Jack Crossfire on December 22, 2009 at 12:05pm
Our only problem with FreeRTOS is that it's not a POSIX interface. You couldn't write for FreeRTOS & get all the advantages of a full Linux ARM without serious rewriting. Microprocessors are at the point where someone could probably sell a bare chip with a full Linux OS instead of a NetBurner or Gumstix.

Still impressive that it's actually been ported to something as small as a dsPIC. Had a coworker using it on an ARM to run a web server that streamed HD video.
Comment by lionel on December 22, 2009 at 12:56pm
ESA's project are quite a big fans of RTEMS. I have also seen QNX being used for example for YES-2
With RTOSes it is very important to do a memory analysis taking into account the dependencies between managers (nightmare on Herschel/Plank) as well as a schedulability one using the Worst Case Execution Time. For our purpose, one can think of RTAI which allows to run GNU/Linux on top of an Hard Real Time Operating System. But, first, one should decide on the hardware platform after selecting the applications and the underlying OS and not the other way around by trying to shoehorn the SW in the hardware.
Hope this helps


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service