Embedded Linux Autopilot

[octane-link]

Hey all:

I am starting a new project to create an autopilot that has an IMU, GPS, pressure sensors, control setup, all the good stuff.

I want to use embedded linux in order to learn it, but I have a few questions to start.

1) Where are some good resources to start learning embedded linux? I am also looking at a few different SBC's to use: the snapper 255, gumstix, and FOXBoard. The snapper 255 and gumstix look the most promising to me.

2) Best IMU option? I am not sure if I want to start with the raw sensors and then code the Kalman filter myself or if there is a module out there with the filtering built in that uses I2C or something similar to send a packet of processed data to the main computer. It looks like any ADC conversion will need a separate chip to do so. In that case, might it be better to run the IMU on a second chip and then send its data to the main computer?

I guess I am really looking for a good place to start learning, I already know how to code, I am just not familiar with the specifics of embedded linux. If this works, it will be some time before I finish, and I would release it to everyone. But for now, this is a one man show.

Thanks everyone!

[drex]

lol oh no not another OSD and autopilot!!!

we have too many !!!!

:D :D :D

good luck with it :)

hey use our techFX IMU as your sensor board.... connect via SPI bus.

:) :) ;) ;)

[drex]

www.TheSiliconHorizon.com/store

[octane-link]

Haha, well this is more of a chance for me to learn embedded linux programming. I will check out your stuff though.

[small_rcer]

I am not quite sure why you would need an OS for an autopilot. An OS is usually the interface between high level apps and the hardware. It also may allow control of multi tasking.

An autopilot is pretty much a single app with modules that all talk to each other. A single piece of executable is probably going to be more efficient in terms of speed and resources required to do the job. If you have read the full topic on Attopilot you will find that even using an 8 core processor, task specific code written in assembler gave the most speed and efficiency and allowed for the tasks to be very complex and reliable. Introducing an OS would not have been conducive to getting the same functionality in a small low power package.

Learning embedded Linux is commendable. Using it for a single task application may be less appropriate.

In many ways the paparazzi project is close to being an embedded Linux project but it is not. It runs complied C-Code directly. That C-Code may include libraries from the linux kernel. The paparazzi project is very complex and as it is currently documented very difficult to get to grips with.

Your C skills would need to be sharp to port the kernel to whatever processor you selected. I wish you success. Please keep us posted on your progress. When you have a working, tested Kalman filter incorporating thermopiles, and for 3 (or more) axis accelerometers, many people reading here will look forward to seeing your code.

Regards

Jim H

[octane-link]

Jim:

Thanks for the insight. I have been thinking along the same lines as what you said, but I was hoping to not have a bunch of small SBC's in the plane. However, I saw on DIY Drones that there is now a dual-processor Arduino board, which could be perfect (use one for navigation, control, and communication, one for the kalman filter or possibly even use three chips).

That might be a better option to use anyway, I will have to think on that.

[drex]

then you should seriously consider our OSD - IMU board.

youll get all your sensors done of our board, firmware already written and source code included... and a great OSD with lots of windows applications already written for it including a GPS logger!!!!

then connect it to your other board (arduino u said??) via the SPI bus at 20 mhz...

then you are set.

our board controls servos too however.

[zik]

I am not quite sure why you would need an OS for an autopilot.
Just to put an opposing viewpoint here - I'm using a multitasking OS on Flying Fox and I believe it offers some significant advantages over single tasking approaches.

I'm using FreeRTOS which is a small, ultra-reliable OS. It allows me to run the control loop in one thread while higher level functions such as the flight plan script language operate in other threads. This makes coding simpler and more reliable since there's a good match between the code and functionality. Autopilots inherently have a number of different tasks to do. Doing all of these things in a single thread leads to additional complexity in managing the way that different tasks are executed.

A good example of this is the paparazzi main loop. I don't meant to criticise paparazzi here - it works well but it's a good illustration of the single-threaded approach. It has tasks which are run frequently - 60Hz (the control loop), some less frequently - 20Hz (altimeter updates etc.), some less frequently again - 4Hz (navigation estimator etc.) and some very infrequently - 1Hz (ranging etc.). This all works pretty well. But what happens if one of your infrequent tasks takes more than 1/60 of a second to run? All of a sudden your control loop is losing integrity. It becomes difficult to manage any longer-running tasks. With a pre-emptive multitasking operating system this type of problem is a non-issue.

Another advantage of a single processor, multi-tasking approach is that I'm not stuck with either the complex coding you get in a single thread approach, or the maximum limit of eight low-powered threads like you get on the propeller chip. When the situation demands it I can have the control loop thread using nearly all the CPU cycles - all the while running a number of smaller threads doing simple things like flashing lights and getting instructions from the flight plan with no hiccups. Multi-core designs can't do anything like that because they can only easily partition the load in sizes of one CPU.

Having said all this, there are also arguments in favor of a single-tasking approach. The most compelling ones if you can't fit the OS in if you have in a very small processor or the potentially hard to predict interactions between threads if your code is poorly written. I use a powerful enough CPU to handle the OS and I'm careful with the parts of the code where the threads interact. This seems to me to be a better option than the non-OS alternatives but obviously other people have taken different approaches quite successfully.

Really each approach has advantages and disadvantages. I just wanted to point out that a multi-tasking OS is very much a viable and reasonable approach. I work in the embedded systems industry and it's the approach that most commercial embedded systems of this scale use these days.

[eddymoore]

I would like to echo exactly what Zik said, except I chose to use TNKernel over FreeRTOS. At a hand wavey level they're identical, but I thought TNKernel implemented a few things slightly better, and was a bit lighter. And very nicely documented indeed. It's been a pleasure to use. I also learnt a lot about operating systems with it, which is useful coming to programming from a non-CS background.

[octane-link]

The more I think about it, the more I like FreeRTOS or TNKernel. Not sure which one I like better, they seem to have their benefits and pitfalls.