With full commercial integration of UAS on the horizon for 2015, open-source projects like ours have the potential to erradicate barriers to entry into the UAS marketplace.

The regulations involved with getting software certified by the FAA are pretty intense, but is it really anything that an open-source community can't handle? This place is chock full of people who are passionate about unmanned systems, and more than just a few who really know their stuff. As an engineering student, I'd be willing to do some of the paperwork myself, just for the bullet point on my resume, and I know I'm not alone.

Moreover, because of all the work that's been put in by guys like Mick, our GCS has got most of the capabilities the big boys have, like HiL simulation. Depending on how D)-178C pans out with using simulation environments for some of the system validation, it might even make it easier for us to get our projects stamped than it would be otherwise.

If we went through the process ourselves, using community resources, we could get our FAA stamp for a helluva lot less money than it would cost the people who pushed for the regulations in the first place. While they pay millions in salary to validate their own systems, our manpower is free.

Chris just got 5 million dollars in venture capital. With us helping on the legwork, and him putting the money towards greasing the right palms, every single one of us could own an aerospace company in five years, powered by 3D Robotics hardware. 

Views: 1720

Reply to This

Replies to This Discussion

If somebody did that, certified a version of the Arducopter for example, wouldn't that meant that we would all benefit from the certification? We could all use that certified code?

Yes, but the usage would not be certified. Consider if Acme UAV sells an all-inclusive package of type-certified aircraft and goes to the expense of certifying the software branch, then Acme generously returns the certified code back to the community. It could happen, and everyone would benefit. For example, if Acme develops an ADS-B module and put it back into the Open Source community, then the community benefits from a new option, and Acme benefits because there will be dozens of developers hammering on their code.  Maybe even finding a bug that Acme missed.  But once the code is outside of Acme's control, it is no longer certified. (The frozen branch inside of and in Acme's control is the certified version).

But nobody can take the OS code, add value in any way, and then close-source that, can they? Is that against the rules?

As I said before, and Chris Anderson could comment on this, Open Source is a cooperative community and does not have force of law. So, yes, it's against the rules, but only community pressure can force cooperation.

This has been a really educational experience for me. Thanks to Stephen and Chris A. for coming in and setting the record straight.

So the way I understand this now, is that anyone can come in and grab the code, and run it through the certification process. Whether they change the code or not, the certification process is basically value added that is frozen to their now-closed branch of the code. So even if they kick whatever improvements they made back to the community, and that code goes into the trunk, the trunk does not become certified by extension. Is that correct?

To me, that creates value for the company who goes through the certification process, since the value they added basically remains their property. I could say that's a good thing since they are trying to start a for-profit business, and they are putting in the resources and effort to take that next step.

Pretty cool stuff.

Chris, but this is a VERY grey area.

IMO, that scenario should not be allowed.  As I see it, the Ardupilot/copter code is worth somewhere upwards of $1,000,000.  I dunno, maybe that's over the top but, I look at it as 10-20,000 hours at $50-100/hr.  That probably is an accurate reflection of the total hours put into it, and the billing rate of some of the minds working on it. (actually, $100/hr would be quite low for some guys, I think).

I don't really see how it's fair that some company could take that, spend $10-20k getting it certified, and then they get to hold that certification back for their sole benefit?

Does that seem fair to you?

It's also a huge grey area in my mind, if you have companies selling turn-key UAV systems, using mostly COTS hardware, and tailored to run the Ardupilot/copter code, and where there is a markup that is difficult to determine how much of that markup is due to the work of systems integration, and how much of that markup is actually "selling" the code.  Certification or not.

No, it's not fair and sometimes really pisses off the Open Source community.  Which is why the Acme UAV company would be very wise to return new code to the community following the open source practice.  Red Hat does this and is a model of cooperation with the open source community.

But, it's going to cost a lot more then $20K to get the software certified for use in a certified aircraft.  The tests for failsafe recovery and redundancy currently required in DO-178C will take a lot of outside engineering.  (It's been years since I was involved in software certification for aircraft use, but at the time, the company seeking certification was not permitted to do the certification tests themselves).

Certifying the aircraft could cost a few hundred thousand dollars if they certify under FAA Part 23 rules (think Cessna, Piper, etc).  If they certify to Part 25 standards (air transport) the process could cost a million $ or more.

Hopefully, when the FAA gets their act together regarding UAV certification, there will be a new type certificate and its' own certification standards.  For example, Part 23 certification requires wings to be stressed to failure.  Destructive drop-tests for occupant survivability are performed, and occupant seats are certified to 45G.  Certification also has specs for occupant restraints, exit placards, and lots of other stuff meant to keep the pilot and passengers breathing.  (Part 25 adds a lot more, such as flight into known icing, flotation devices, passenger oxygen, and the bird ingestion test - aka Chicken Gun.)

It isn't a small undertaking.

If it happens, I think that everyone would benefit.

I agree that making money based solely on the software would not be kosher. My thought was questioning what would happen when the user that went through the certification process shared the certified code. If that certification didn't transfer back to other integrators, it seems to me to be a bit of both good and bad.

The good would be that it protected the investment of the party who went through the certification. That alone would encourage parties to go through the process.

Obviously, the bad would be that unlike other shared work, the effort wouldn't be of equal benefit to the entire community. But consider this: once one branch achieves certification, it lends the credentials to the project, so even though the code isn't certified, per se, the next party to walk that path would face fewer obstacles in the form of skeptical regulators.

There is alot of correct and incorrect information in this thread.


DO-254 = Hardware

DO-178C = Software

I can speak for the software side of things from experience, hardware is not my expertise.

To clarify some points:

  • Certification
    • Both hardware and software certification is not currently required for UAVs since there is no human on board. This has been stated, but I wanted to reiterate it.
    • Compliance
      • There are levels of compliance or criticality that determine the extent of V&V (verification and validation) required.
      • This directly impacts the cost of the effort.
    • Independence
      • Depending on the compliance level of the software, a different level of independence is required. Typically you want an individual who do not write the software, to verify the software (compliance level may make this a requirement). An outside entity is not required. Physical copies must exist, and in FAA blue ink (true story).
  • Open sourcyness
  • The adu* family of software and tools is GPL, which is extremely specific. A commercial company cannot legally (USA) take the software, change it and or modify, and sell it as there own. They cannot even access the software via dynamic loading (implement an interface and i'll load you at run time) or use shared memory to access the software; for commercial gain. So, no fancy tricks.
  • A commercial company could provide the ardu* products for free, modify it, provide source, etc. and profit from it in another matter (typically via a service of some type - we'll implement toy mode for you, etc; or selling hardware).
  • Certifying Open-Source Software
    • Completely viable and a precedent has already been set
      • In fairness I've only seen proposed certification of linux in various forms, but it's likely this has succeeded by now.
    • But how is this possible?
      • Create a copy of code in compliance with all respective licensing (GPL namely), certify it. Done.
      • It does not matter that someone can take certified software and modify it. This only means that there modified version is not certified. Putting non-certified software on an aircraft is a world-of-hurt you do not want.
    • Would anyone have access to the certified software?
      • Yes, given its current licensing structure.
    • But if I change the code would it still be certified?
      • NO.
  • Simulation as part of V&V
    • The fun part of DO-178C is that even your tools have to be verified.


Yes, yes, yes, correct - they would have to make it available, correct - they cannot close-source any subset or superset, yes it violates GPL.

I think I answered in order :)


A STANAG compliant system would be awesome, and forward thinking honestly.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service