RTOS or not for a UAV controller?

[Kaptah]

I would like to hear, how does a proper RC autopilot software topology should look like? If we have a single cpu (for example ARM7, ATMEGA or a PIC) doing all the stuff:

- NMEA parser
- SPI communication (3D acceleration & gyro's, altitude etc)
- PID controllers (running at 20Hz or so)
- navigation calculation
- PWM settings for servo (PWM outputs are hardware based)
- communication

Considering the complexity, is it "mandatory" to use an RTOS, like uCos or FreeRTOS?

Or can one do it with the traditional main() loop - interrupts style without too much additional discomfort, when compared to the RTOS based solution?

Thanks.

[zlite]

Typically, we don't use any OS at all. If you're using an atmega or pic, you tend to code straight to the hardware.

[carguy84]

Or can one do it with the traditional main() loop
I would imagine there's quite a bit of threading going on.

[hg1]

I would imagine there's quite a bit of threading going on.
Doesn't have to be. If your processor is fast enough, you can run a single large polled loop that handles all of the sensors and calculations. Basically, you have to map out how often each subsystem needs to be serviced and how much time is spent in that servicing. For example, IMU-based systems used in inherently unstable systems such a quad rotors will require a much faster core loop, while stable systems that are based mainly around GPS can manage with a slow core loop.

[zlite]

Exactly. We use standard inner loop/outer loop methods. It allows us to have very tight control over timing.

[eddymoore]

We have used TNKernel with the LPC2148 (arm7). It's not necessary, but I'd conservatively say it reduced code development time to about 25% of what it would have been otherwise, and makes adding new processes trivial. If you have a very tight and fixed software spec, you can plan the software without one. But if you're experimenting and messing around, you will really appreciate the benefits of an RTOS. The footprint of TNKernel is tiny too, and there are some nice freebies you can download from their site like USB Bootloading.

I rate the LPC2148 incidentally. It's very straightforward to set-up.

[zlite]

I don't know of any commercial autopilot that uses an OS, real time or otherwise. We all seem to code straight to the iron. Can anyone think of one?

[small_rcer]

If you are developing a one off project where the time and therefore the $ involved in the software apps are a key consideration then the RTOS may be a better option. It does have some downsides. One of those is usually the need to have more compute power in the form of either a more expensive or more power hungry CPU. If the electrical power is available and weight is not an issue then using an RTOS is a viable option.

Conversely, if the production run of the hardware is more than a couple, or the weight is critical, or the power consumption is restricted, the cost of the more complex processor and the power and space budgets, may outweigh the development costs. In addition, although it is often easier for an application developer who is familiar with a particular development tool to quickly write an app, there is often a person who is familiar with low level programming who is just as fast in the low level language. This would offset or negate the rapid development time possible using an RTOS. So it comes down, often times, to the skill set of the human resources and therefore the time cost, rather than the CPU or power restrictions. It is often harder to find or train the skilled low level assembly language programmer, than the RTOS high level app programmer.

So the saving and the decision, will usually come down to the people cost or skill set rather than the cpu or other restrictions. Unfortunately this human capital or skill set, could seriously cripple a project. If the management is not technical and chooses the wrong option just because the skill set was available in-house, the project could go seriously wrong, or not meet the price/performance/delivery targets.

Personally, I would go the assembly language route. Have an intimate understanding of the hardware, count-down timers, interrupts, A to D, PWM, and other I/O and other hardware factors. Then find a cpu which embodies those features that are a 'must have' and has the power and cost to fit the budgets. The ability to get everything out of a CPU that it offers and to have it service very time critical events, will usually be best served with the lowest level language that is available.

It is interesting to observe how many of the projects mentioned here have had a hardware/language shift as the project moved along. As the complexity rose the processor choice often changed. As other projects matured the targets for a project have changed, often causing a CPU change. Part way through some have found the tool sets or the language could not give enough fine grained control. Others just were exposed to a new or more readily available processor. Some parts may have reached end of life and were a dead end path. But change has happened. Some of the threads / projects here, appear to have died as a result.

In all of this it shows the wealth of choices and options that are available. Your mileage may vary. 8-))

Jim

[Jack Crossfire]

Rate damping on an unstable aircraft definitely needs to be as realtime as possible, but you probably bought parts for that.

[Ben C]

We have used TNKernel with the LPC2148 (arm7). It's not necessary, but I'd conservatively say it reduced code development time to about 25% of what it would have been otherwise, and makes adding new processes trivial. If you have a very tight and fixed software spec, you can plan the software without one. But if you're experimenting and messing around, you will really appreciate the benefits of an RTOS. The footprint of TNKernel is tiny too, and there are some nice freebies you can download from their site like USB Bootloading.

I rate the LPC2148 incidentally. It's very straightforward to set-up.
Thanks for point out TNKernel by the way. I'm also thinking of using an LPC2148 for some control projects, and TNKernel looks very nice. I agree with your previous comment that it will be a pleasure to use - I've just poked around the source, and it's nicely architected.

[Crashaholic]

If you use an RTOS, I would use a very light one. I have mixed feelings on RTOS's in general for most MCU applications but I have been using them more often recently.

Check out FreeRTOS (http://www.freertos.org/). It is very barebones and simple enough to understand so that you can beat it in to submission when you need to. It has also been ported to many MCUs so you can take your experience and code with you to new platforms. It also has ports that set it up for direct use in many different IDE's for each MCU.
(http://www.freeRTOS.com)

[jitterman]

Hi

Another choice may be QNX

www.qnx.com

Regards

[eddymoore]

There are lots of order-of-magnitude differences in the suggestions here. Whilst they're all RTOS, some will run on 8-bit micros and are still basically 'bare-metal', whereas others are much more developed operating systems.

FreeRTOS and TNKernel are similar in their scope and both pretty light. Using them is just like normal bare-metal programming, except you call an operating system sleep function rather than some other sleep function, say. So when we send radio teletype from a high altitude balloon, and have to beep something every 20ms (50 baud) we just call a tn_sleep for 20ms, during which time the OS gives CPU time to other things, then hands it back to the radio teletype thread after 20ms. But you're still doing stuff at the register level.

QNX is very much bigger. The last time I used it was for industrial embedded control on PC104 boards running (comparatively) chunky hardware - ~0.5GB Ram, 600MHZ CPUs etc. I don't know how small it goes but it's certainly a very different animal to the likes of TNKernel, FreeRTOS, eCos or whichever.

The best thing is to first define your hardware, then shop around for what's available to you.

[jitterman]

Hi

It´s true ... sorry, i don´t read carefully the first post. QNX it´s a bit huge for 8bits AVR or ARM7 devices, QNX is for micros with MMU.

I think... this OS it´s one of the best options for embedded RTOS with MMU, QNX runing in a Gumstix hardware or similar XScale platform may be a good choice for UAV RTOS.

Regards

[Unterhausen]

I would like an RTOS, not sure it has to be real-time. The problem if it isn't, the people who wrote it might have crazy ideas about what is important, when everyone knows determinism is important.

[ben_kapitan]

Having no experience on the subject and nothing worthwhile to contribute, I'll just say thanks for the great advice!