Open Source Avionics?

While talking to a co-worker about his RV-7 build, an idea hit me:

Why not develop some kind of open source avionics platform?

Not only address the software side, but the hardware as well.

Indeed, I’m still trying to figure out the exact direction of where I would like to see a project like this go (as in, limit to Primary instruments? Flight directors?), but none the less, I have to start somewhere.

I’ll be posting more as I come up with it, but if you’re interested in assisting or giving ideas, let me know in a comment!

Bookmark the permalink.

10 Responses to Open Source Avionics?

  1. J.F. says:

    I’ve been pondering this as well … although researching what it takes to do this well and right has put a bit of a damper on my enthusiasm!

    Some concerns:

    – The community would be rather small I imagine, possibly unsustainably so.
    – Volunteers for design and coding might be found … the kind of testing avionics require however … that’s a whole other game …
    – Tools are, or can be, expensive? Is there a way to do it with the standard tools of open source communities? (Eclipse, GNU, etc …)
    – It’s very hard to find OTS hardware that would fit the needs. I’ve gotten close, but it’s too expensive. Would still need some custom work there …
    – Even if you create some reference hardware, avionics tend to run so close to the metal, it’d be tough to be as flexible as open source usually is in the more common IT spheres.
    – Testing compatibility and interoperability and integration can be complex and expensive … you need a lot of gear to test against all the popular other components out there (Garmin, Avidyne, Dynon, etc …).

    Anyways, as usual, nothing’s impossible, but that would be one heck of an endeavour.
    – You need sensors, and those don’t exactly come off the shelves. ADHARS and such …

    Oh and you’d want to start with basic instrumentation before you get into any kind of logic that can cause trouble (anything that outputs to an autopilot, or is an autopilot, for example). A standard PFD would be a good starting point. Maybe even a little backup one.

    • Jason Gillman Jr. says:


      Definitely some good points.

      Indeed the community would probably be small to start out with, but I would imagine that after some traction has been made, it may grow. But I could be wrong.

      As for testing, I would be more than happy to play test pilot :> Really though, I think testing along side currently used systems could be a decent way of doing things maybe?

      Now on to tools… I’ve done some thinking on how to approach the system generally (which I will write another article when I get back from my annual training). But the basic concept (as I envision it) is that a micro-controller, such as an Arduino board, could be used for some signal conversion, and then transmission to a a micro PC (maybe even a Raspberry Pi?). So, using a tachometer as an example, if my scientific wild ass guess is correct that a tach’s readings are generated from a voltage output based on RPM (again, I could be horribly wrong, and this is why I need to research how these systems usually send data), I could read the line voltage using the Arduino on one of the analog ports (the 10 bit A/D converter I think would be adequate in this case), and then serialize it into something like JSON, and then feed it to the Micro PC. From there, you can display the data however you want.

      On to the hardware issue and avionics running close to the metal, you bring up a good point. I don’t think a standard altimeter actually sends out data (or maybe there some that do?), but in cases like this, it might be possible to self roll an altimeter if you could properly interface it with the pitot system. Or for an attitude indicator, do the same thing by using a decent accelerometer. Hey, this *is* geared for the experimental aviation crowd.

      Of course trying to integrate something like a Transponder would certainly be a pain.

      As for an autopilot, you are correct, definitely want to be able to read and interpret data properly first, seeing as you can’t have an autopilot function unless you’re able to feed it information about the environment the aircraft is operating in.

      I definitely appreciate you taking the time to comment though. Nice to know that someone has stumbled on my little project. I’m definitely down for wargaming ideas.

  2. J.F. says:

    The problem I saw remains fundamental: Why do open source avionics? What are you hoping to achieve against other alternatives? More affordable? Technically superior? The thing is avionics are generally pretty excellent pieces of software in terms quality. The benefits open source development brings to things like Linux or Apache may not quite apply here. Even innovating on features would be pretty hard. Also the ecosystem is pretty closed, so finding people that will let you interface with their closed system from your open source project may be tough (Think video card drivers for Linux/X).

    The way I ended up thinking is that you’d still need to create a company that provides end to end solution, including your own hardware, but you could choose an open source development model for your software.

    I just don’t think it would be possible to create avionics software that runs on anything the builder would like …

    • Jason Gillman Jr. says:


      My big vision was having something that a pilot can customize to meet their needs. So for example, they could display their stuff however they want. Or another example might be that a pilot could make a flight director as aggressive or relaxed as they want.

      Then, of course there is also just the fun of working on a project like this (I’m a geek for my civilian job).

  3. J.F. says:

    Regarding your technical approach … JSON would be rather (very!) slow in terms of avionics … and probably unnecessary. this is where the bare metal approach comes in. If you can convert whatever form of analog signal into digital data, you then want it to move that data with as little fuss as possible. An RPM value would fit inside nicely inside say, a simple UDP data packet. The JSON overhead just creates avenues for potential problems, and therefore more testing, etc … I’ve been trying to learn more about this:

    Which I think would be very nice to use in any kind of new platform.

    For the hardware, I was looking at Gumstix … but Rapberry Pi might also be good. So long as they can withstand the environment they’re put in (Thermal, vibration, humidity, etc.). A gumstix with a custom daughter-board could make for a nice little CPU.

    • Jason Gillman Jr. says:


      The reason that I was thinking JSON (again, it was just an idea) was that way some kind of textual, serialized information could be passed that could be processed by anything that can natively parse the format. Again, this is strictly just an idea I had upfront, and could certainly change down the road.

      AFDX does look interesting though.

  4. c says:

    Would it be possible to incorporate opensource avionics into “do it yourself drones”? I have no idea what I’m talking about, but the idea of open source avionics might be a good push towards open avionics standards.

    • Jason Gillman Jr. says:


      I don’t see why that couldn’t be the case, as an open standard could be used for wireless transmission to a ground station.

      In the reverse, since the theory is that an open source flight director could be created, such a protocol could be used for controlling a drone.

  5. Rodrigo Damazio says:

    Has this ever moved forward? I’m interested in contributing (software engineer/pilot starting to build a RV-10 here)

    • Jason Gillman Jr. says:


      Unfortunately not. This has been one of those things I got an idea for, but haven’t had the time to really work on.

      I would be happy to setup a collaboration environment (I work for a hosting company as a software tester) if people like yourself are interested!

Leave a Reply

Your email address will not be published. Required fields are marked *