Pixhawk OTP certification

4240 views
Skip to first unread message

john...@gmail.com

unread,
Apr 14, 2014, 3:01:48 PM4/14/14
to drones-...@googlegroups.com
I normally don't follow the PX development groups, and was just made aware of that 3DR Pixhawks use OTP certification to limit "clone" functionality when using official builds.

Is this really true? And if so, why has it been kept semi secret? This is exactly the kind of thing that will blow up in our faces big time, and exactly the opposite of what our previous stance with regard to clones have been.

In fact, before learning about this,  I just defended 3DR in RCGroups with regard to a clone board having OTP problems. I naturally assumed this was just a problem with an incompatible bootloader, not 3DR actively blocking clone boards. Seems I was wrong. Dead wrong..

From the outside this looks very much like 3DR commercial interests taking priority over open software/hardware philosophy. And the issue needs to be addressed in a VERY CLEAR AND CONCISE WAY right now.

- JAB



Gmail

unread,
Apr 14, 2014, 3:10:50 PM4/14/14
to drones-...@googlegroups.com
It does nothing of the sort. 

The clones can generate their own cert and shove that into their own OTP. It is trivial to remove or re-write the OTP checks to bypass (in fact, perhaps we should drop in some better error handling to address cases where the OTP read is unsuccessful, for developers who chose not/cannot write their own cert.

This is method to determine if the board is genuine 3DR. It is not intended to prevent another board from working. A few folks have offered their (volunteer) time to help home-brew/clone makers get bootstrapped around making their own cert and writing it to OTP (so they, too, can determine if the board is actually theirs, later, when it comes to failure analysis and hardware warranty, quality control, etc.)

Craig and team can address this issue in an official capacity. I am in no way affiliated with 3DR. 

For those of you who want to understand the nuances of this, and understand NIST controls, this is about NIST SP800-53v4 SA-19: Component Authenticity and AU-10 Non-Repudiation. If the OTP cert is valid 3DR, then the hardware is held to be from 3DR. If code doesn’t run because the cert does not match, then (it’s open source) it’s trivial to bypass, so it would be completely ineffective to be a protection mode, like secure boot and that sort of nonsense. If it doesn’t run, it’s simply because the code hasn’t been written with the expectation that an OTP call or cert check/SN check might not return a result… 

This is all my take on the topic. I’m glad you asked, because there are a few folks on the list who want to discuss this, but were waiting to hear that it was still a concern.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

john...@gmail.com

unread,
Apr 14, 2014, 3:45:33 PM4/14/14
to drones-...@googlegroups.com
I am totally ok with detecting a genuine 3DR board for the purpose of offering official support by 3DR.

But the big questions is, what happens when a board without a genuine 3DR OTP tries to use mission planner and upload a new firmware. RCG posts indicates that it will fail with an OTP warning. And if so, then this is not about denying support anymore..

- JAB

Gmail

unread,
Apr 14, 2014, 4:57:25 PM4/14/14
to drones-...@googlegroups.com
Yes, a few parts of the system handle that unexpected condition poorly right now. It’s easy for the more savvy user to get around, and it wasn't done to prevent clone gear from working, but it should probably get attention.

 If someone has the technical chops to design and make a clone board, they should be able to not only patch for this issue, they should be able to figure out how the certs and OTP works. 

And if they cannot, simply asking nicely on this or the drone-dev list will most likely produce someone who will help. 

As for the core code, it should be an easy set of fixes if someone wants to take it on. 

I would imagine that the best way to solve this is for a home-brew/clone maker could/should offer up a board to someone like David Buzz (and offer some beer or at least ask very nicely) or a volunteer coder on the dev list and probably Michael Oborne and/or Bill Bonnie, so that a set of fixes could be tested. After all, it’s not good practice to commit untested code, and these folks will not have easy access to a homebrew/non-genuine board. I think it’s unfair to ask volunteers to help, and not provide them with the board the fix is supposed to support. 

If I had the time and the hardware, I’d volunteer to do it myself, but I don’t right now.

Sure, 3DR could produce a PixHawk and skip the OTP programming, and hand some out to volunteers to test handling of null OTP data, and maybe they will, if asked, but I don’t see how it’s really their _responsibility or obligation_. They are producing high quality, genuine boards, and the volunteer dev team wrote in a routine that looks for this information, but 3DR doesn’t *require* that boards be signed, or that boards be 3DR genuine to run the open source code. It just happens to be how the code is written (by people who use 3DR boards.)

Again, just my perspective.

Andrew Tridgell

unread,
Apr 14, 2014, 6:12:23 PM4/14/14
to john...@gmail.com, drones-...@googlegroups.com
Hi John,

I'd just like to note that this OTP behaviour is not a part of the
flight firmware. It is a restriction in MissionPlanner (and I believe in
APMPlanner?).

It also doesn't affect firmware upload using the command line tools that
come with the PX4Firmware tree. So it is a GCS enforced
restriction. There is no enforcement in the bootloader or flight
firmware, although the bootloader does provide the OTP to the GCS when
it requests it. The PX4Firmware command line uploader displays the OTP
if it gets one, but takes no action based on its content.

I just wanted to make that clear so any discussion can be about the
right component. The various components are developed separately.

Cheers, Tridge

john...@gmail.com

unread,
Apr 14, 2014, 7:30:42 PM4/14/14
to drones-...@googlegroups.com, john...@gmail.com, and...@tridgell.net
Sure, it is clear where the problem lies.

But even if there is no limitations in APM firmwares, the end product is still that some users are actively being prohibited from loading and using APM firmwares by the most common method to do so..

It's to early to say, but the fears about 3DR being affected by the VC (that where put down as nonsense), suddenly feels real again. Because there aren't any good technical reasons for doing this. Preventing clones from uploading APM firmwares in Mission Planner has nothing to do with protecting users, or giving better support.

-JAB

Chris Anderson

unread,
Apr 14, 2014, 7:37:24 PM4/14/14
to drones-discuss, johnarne, Andrew Tridgell
All the 3DR-funded GCSs are 100% open source. Anyone who would like to comment out the OTP checking and distribute them OTP-free is very welcome to do so.  It's an easy process and fully allowed/encouraged. 

-c


--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Chris Anderson
CEO, 3D Robotics

john...@gmail.com

unread,
Apr 14, 2014, 7:44:40 PM4/14/14
to drones-...@googlegroups.com, johnarne, Andrew Tridgell
Chris, thank you for replying.

I am trying very hard to constrain myself and be civil here. So just to be absolutely clear. Are you now confirming that this feature was intentionally put in there to prevent clone boards from using "official" GCS builds? Not just to check for genuine boards while doing 3DR support?

- JAB

Jonathan Challinger

unread,
Apr 14, 2014, 7:50:36 PM4/14/14
to drones-...@googlegroups.com
Why is this a problem? Everything is open-source. Anyone doing real derivative works and research won't be the slightest bit inhibited by this. The only people who will ever be inhibited by this are the cheapos who buy clones and don't actually contribute anything, and even they will trivially get past this by getting a hex from their cloner that was compiled for their board. I'm sure the project would even accept a patch to fix it for them. Chill out. There's no DRM crisis here.

Craig Elder

unread,
Apr 14, 2014, 8:16:56 PM4/14/14
to drones-discuss, John Arne Birkeland, Andrew Tridgell
Johnarne,

This is not a vc motivated topic.  Equipment Identification and secure communications between a GCS and a vehicle are becoming increasingly important as we move towards certification of the UAVs we operate. 

The OTP / One Time Programmable register in the STM32 contains a Certificate Of Authenticity and a serial number.  If you understand what a COA on a boxed software package looks like, and what it's for, then you'll understand that it's not about preventing user/s from doing anything but it's more about empowering users to a) know who the manufacturer is, and b) give them increased confidence in their product as a result.  This is a way the purchaser can directly check the quality of the product and the truth of the labeling.

hypothetical: 
Lets say you buy a "2nd-hand 3DR pixhawk" from ebay.  How do you know that it's really manufactured by the company that the seller says it is?  It might have been made by 3DR, or it might have been made by a "chinese cloner" that deliberately made their product physically appear identical to the 3DR branded one, or it may have been made by Joe Schmo who may just have just copied the circuit board design to save himself the hassle of re-branding, without ill intent.   

The issue is that you as the purchaser can't tell those three products apart just by looking at them so there needs to be a "smart way" to allow the end-user/s of the system to query the chip itself and say with some confidence "Who made you?" and get an honest result back.

A certificate-of-authenticity that identifies as "made by 3DR" can give you the confidence that the board *really* was made by 3DR and a certificate-of-authenticity that is "signed and sealed" by someone else will similarly give you confidence that you know who made the product and you can thus contact the right manufacturer if you have issues.   Lastly, a board with no certificate-of-authenticity, lets you know that it's probably made by someone in China, or by someone who wasn't willing to put their name to it and claim the hardware as their own, so the quality is "unknown". 

Any manufacturer can write a COA, and I strongly encourage anybody who is making "homemade" or "clone" boards that they really would be well off using the OTP/COA code to sign each of their boards with their personal or company "private key" before they leave the factory.  For all vendors, COA / Serial number is written to logs so that tech support people can track issues based on production lots and serial numbers and support people can check the serial number before spending time providing support to a board manufactured by another vendor.

Finally, the last thing that this entitles other software devs to do is to optionally choose to use this verification information to make different decision/s regarding what hardware they inter-operate with and how they inter-operate or do not inter-operate with it.

For example if a hypothetical GCS developer has had experiences with un-known  "chinese clones" being poorly made,  having marginal components, crashing otherwise lovely aircraft, and smearing the name of a company they make the "fakes/clones" from, then as a result of the OTP/COA code they now have options.  They might choose to present the user of a "real" hardware, with a screen saying "thanks for buying real hardware X" screen, or they may choose to say "it appears you are running hardware X made by manufacturer Y, did you know there are known issues with this specific hardware? ", or they might say "sorry, we can't inter-operate with hardware X, as it's nasty".   If on the other hand a company wants to clone the hardware, develop software to inter-operate with it, and then provide their own support to their own customers they are welcome to do that. 

I fully expect we will have FAA certification on Pixhawk and Pixhawk equipped aircraft.  Other vendors will have to have to establish their own ability to certify their own variants of the board and this is a great step forward for us in ensuring that certification criteria can be met.

I hope this clears things up and I would be happy to answer any more questions you might have about this.


Cheers,

Craig





On Mon, Apr 14, 2014 at 4:30 PM, <john...@gmail.com> wrote:

--

Jonathan Challinger

unread,
Apr 14, 2014, 8:47:15 PM4/14/14
to drones-...@googlegroups.com
Alright everyone, stop panicking, we've got a solution:
[5:41:59 PM] Sam Kelly: your copy of pixhawk may not be genuine *deletes wallpaper*
[5:42:11 PM] Jonathan Challinger: ahahaha
[5:42:47 PM] Jonathan Challinger: that would just be amazing
[5:43:28 PM] Jonathan Challinger: we should make a black wallpaper with "Your pixhawk is not genuine" in the bottom corner, and have the GCS change it in when you upload to a non-genuine pixhawk

Philip Rowse

unread,
Apr 14, 2014, 9:00:41 PM4/14/14
to drones-...@googlegroups.com, John Arne Birkeland, Andrew Tridgell

Just a few points, my opinion only...
  1. It is only fair for the cloners to have to do some work. either by maintaining their own releases, or by directly supporting the project.  I am sure that if a cloner was to directly be involved in the project, funding, engineering etc, then their COA could be added to the accepted list.
  2. The code is still open.
  3. This will become much more of an issue as the components in this become certified for FCC and FAA etc. it is then critical to know if the component is legitimate. Certification is by manufacturer, it doesn't care about open source.
  4. This will directly affect the ground station software, as Certified releases will need to behave in a predictable way.  that cannot be guaranteed unless both ends of the system are strictly controlled.
  5. This does not defeat Open source in any way, as you can still compile the GCS and the Firmware yourself.  with no certification

Ritchie Wilson

unread,
Apr 17, 2014, 3:17:18 AM4/17/14
to drones-...@googlegroups.com
Whilst open source means you can DIY it especially if something you want isn't there. It has also meant that help given for all.
OTP failure should not be the end. It should be a warning as clones are not approved.

Yes it's trivial to get around but that is not the point. It shouldn't need a get around just a big warning stating "at your own risk"

Regards
Ritchie

Sent from my iPad - so excuse spelling errors xD
--

Loic B

unread,
Apr 17, 2014, 5:29:52 AM4/17/14
to drones-...@googlegroups.com
it s not normal for opensource project to try to limitate external copy!!!!!!!!!!!i am very sad to see this new way from the team!!!!
i am pretty sure,it s for make more profit for 3drrobotics.....it will kill our great project

Craig Elder

unread,
Apr 17, 2014, 1:27:04 PM4/17/14
to drones-discuss
I appreciate your opinion Richie.  I think we need to adjust our nomenclature.  It is board and the Certificate of Authenticity that failed not the OTP.

Craig Elder

unread,
Apr 17, 2014, 1:28:57 PM4/17/14
to drones-discuss
We're not limiting external copies, just encouraging the cloners to get involved and support their own hardware rather than expecting that we are going to do that for them.


hontaksenpoka

unread,
Apr 17, 2014, 7:01:41 PM4/17/14
to drones-...@googlegroups.com
I fear that this will generate very bad rep to project at general, especially for those not so technically savvy (big masses). I have been there and see all the bad things that could happen (bad rep, lots of forks, etc). Most people just think that product is faulty or project is somewhat screwed and buy something else.

 If this is the new way for project it would be better make some parts as closed source (hardware? maybe some new software parts?), it would be more honest that way. And create clear process to hardware certification for new hardware partners. This should be best for the 3DR as well in business wise. Why give something as open source and then try to make use difficult.

I also think that it would be nice if cloners commit something, BUT if they obey licensing rules they are OK to go and just clone. They dont have to commit anything if they dont want, i think we all agreed that if we think about project licensing. 

And for now the process how to get certified is not very clear and there lots of boards out all ready that does not have OTP.

I think that DJI guys celebrate now as this will bring more money to them. My opinion is that this is wrong signal to market.

Rgs,

Sam

Paul Riseborough

unread,
Apr 18, 2014, 5:22:34 PM4/18/14
to drones-...@googlegroups.com
Sam,

Everything is still open source.

Board manufacturers can either produce their own cert for the OTP and approach the GCS developers (who likely don't receive a cent in support from the cloners), or provide their own firmware upload utility.

There are existing options for firmware upload that will work for those boards without the OTP information. 

The barrier to entry is very low so I don't see what the fuss is about.


john...@gmail.com

unread,
Apr 20, 2014, 7:23:20 PM4/20/14
to drones-...@googlegroups.com
Looking at the latest MissionPlanner commits, I see that the firmware check has been modified to show a warning and set the variable skipotp = true. I find references to this variable being used in the included px4uploader.exe binary. Perhaps I am looking in the wrong places, but I am not able to find the px4uploader source and confirm how it's used. Link please.

But I am assuming this means that MissionPlanner will now show the warning and continue to uploading firmwares despite a failed OTP certification?  If so this i great news. The previous implementation regardless of intent and what has been said, was effectively acting as DRM for non-dev users and this was bugging me BIG TIME.

- JAB

Craig Elder

unread,
Apr 21, 2014, 8:43:12 PM4/21/14
to drones-discuss
Paul Baxter at White Spy is now distributing his own version of Mission Planner.  You can see it in his downloads section of   http://witespyquad.gostorego.com/flight-controllers/rtfhawk-2-4.html

You'll note he is still linking back to the 3DRobotics and ardupilot websites for documentation 


--

Craig Elder

unread,
Apr 21, 2014, 9:22:28 PM4/21/14
to drones-discuss
These are the numbers for people accessing the ardupilot documentation site from his website

Screen Shot 2014-04-21 at 6.19.22 PM.png

paul Baxter

unread,
Apr 21, 2014, 11:15:54 PM4/21/14
to drones-...@googlegroups.com
I never was asked to remove any links. I did not know there was any problems? 


craig. I pm'ed you about how to get a cert. did you get it? 

First we had an "opt" error..
update.... (Easter day)
Now missing planner shows just a message, "this is a clone", but allows upload.
1 day later.. 
update.
Now the mission planner blocks all home-brew boards. 100% will not upload.
what is going on??

paul

john...@gmail.com

unread,
Apr 22, 2014, 4:51:49 AM4/22/14
to drones-...@googlegroups.com
Hi Craig,

If you have followed the RCGroups threads about the RTFHawk and friends, you will see that people are talking about 3rd party build-bots and experimenting with qupdate and really old versions of px4uploader.exe to work around the OTP issue. The point being that instead of unifying, this feature has up until now only made the distance between "official" and "clone" users even larger. People using all sorts of untested software builds and old firmware up-loaders is not something we want. It will only damage the perception of APM/PX as a whole in the long run.

But I digress, since it is now my understanding that the latest version of MissionPlanner will allow the users to bypass a failed OTP certification with a warning and continue the upload.

- JAB

john...@gmail.com

unread,
Apr 22, 2014, 5:51:52 AM4/22/14
to drones-...@googlegroups.com
And it seems I spoke to early. I see there was just added a commit to MissionPlaner made explicit to stop uploading firmwares if OTP fails. The exact thing that I have a big problem with that makes no sense to do in a open source project. I give up..

Craig Elder

unread,
Apr 22, 2014, 2:48:08 PM4/22/14
to drones-discuss
Paul, yes I got your pm late Monday just before I started the dev call.  You're in my queue to reply to.


David Pawlak

unread,
Apr 23, 2014, 1:42:09 PM4/23/14
to drones-...@googlegroups.com
Linux, another famous open soure project has over 1000 flavors.

3DR is just settling in on flavor #1. New flavors are your responsibility. And the OTP only supports that.

Don't expect 3DR to create your flavor for you.

I don't understand why you are so upset. I really don't think you understand "Open Source"

john...@gmail.com

unread,
Apr 23, 2014, 2:06:19 PM4/23/14
to drones-...@googlegroups.com
So your saying that if Linus suddenly decreed that from now on "official" Linux kernels will only support Intel hardware, you would be ok with that? Because after all since it's open source, you can make your own version with AMD or ARM support.

This all boils down to a very tiny but significant point. Warning about clone hardware before uploading firmwares, or denying. The first has value for users, but the second one only adds value to 3DR.

- JAB

Robert Lefebvre

unread,
Apr 23, 2014, 2:16:35 PM4/23/14
to drones-discuss
But John, the OTP check doesn't occur in the Ardupilot firmware.  The Ardupilot firmware has nothing to do with this.  IMO, that is the "kernel".  The check for COA actually occurs in the mission planner firmware.  So this is sort of more like saying that Google which makes Android, which is a front-end on top of Linux, should also be able to install on Apple hardware because Google chose to base the front end on Linux?  Something like that.  Hopefully you at least see the point I'm trying to make even if you disagree with it.

Anyway, how about this as a compromise:

What if the COA check was behind a #define?  The #define could be disabled by default, but could be enabled on all 3DR supplied binaries?  So what this means is, anybody can easily compile and not have it enabled.  And other manufacturers could also easily compile and supply their own binaries.  But what they couldn't do is simply point their own customers to 3DR's servers to get the binaries, because those are specifically compiled for 3DR hardware.  Isn't it fair that 3DR should not have to pay for the bandwidth used by customers of other manufacturers downloading binaries?


john...@gmail.com

unread,
Apr 23, 2014, 3:10:03 PM4/23/14
to drones-...@googlegroups.com
> the OTP check doesn't occur in the Ardupilot firmware

And thank <higher spiritual being> for that. I would be spitting flames if so, even if I haven't been actively contribution in a good while now. :)


> IMO, that is the "kernel"

On AVR hardware yes, but on PX hardware Nuttx is the kernel or ring 0 to be more accurate. And that's the software/hardware being addressed for OTP/COA via the px4uploader.exe. If APM has been running ring 0 without a RTOS beneath, then i suspect we would now be having OTP in the APM code also. The same px4uploader.exe binary is used by both Mission Planner and APM-Planner. You will find the RSA encryption public key used for the certification inside the .exe file if you look. So this is not some "just added for fun" feature. Someone has spent time implementing this. And btw. I am still looking for the source rep for that px4uploader binary.. Anyone? 100% open source?

> So this is sort of more like saying that Google which makes Android, which is a front-end on top of Linux, should also be able to install on Apple hardware <snip>

Actually there is no technical reason why not. :) It actually what Ubuntu wants to do (or at least wanted to do) on mobile phones with the Ubuntu for Android project. A better analog would be if Google aggressively started to activly try and limit the distribution of cheap unknown Chinese Android based phones and tables.


>Anyway, how about this as a compromise:

3DR can OTP as much as they want on they own hardware. And I agree that developers should not spent a second trying to support clone hardware if the clone manufactures don't give back. It's spending developer time to ACTIVELY prevent clone hardware from functioning I have a big problem with (warn vs deny), since it's something completely different. Even at a higher level that is easy to circumvent for devs/experienced users.

- JAB

Gary McCray

unread,
Apr 23, 2014, 3:40:37 PM4/23/14
to drones-...@googlegroups.com
Actually quite a good point Robert,

But the reality is that end users who buy clones will still flock here for support and worse, they will feel compelled to be doing recompiling themselves to remove the OTP protection. 

The net result is likely to be an increase in traffic, downloads and developer level support from illegitimate sources who are now also frustrated by complete lack of programming experience as well.

Open Source / Open Hardware, by concept and definition is egalitarian and not overtly capitalist.

It exists to provide open and unrestricted access.

It is truly not a commercially profit oriented solution.

That 3DR has to try and find some way to be profitable goes without saying and it is hard to be a benefactor if you yourself have no source of income.

There is also the simple fact that without having some sort of a lock on both the hardware and the software the various civil authorization organizations are very unlikely to look favorably at including this equipment for genuine UAV applications (I have my doubts about that anyway given the way our government and the FAA are acting).

Certainly the OTP thing can give them a leg up profit and corporate legitimacy wise and possibly with the FAA - etc as well.

But it does do so at some level compromise the spirit and likely legal specification of the open source and open hardware initiatives / contracts as well.

Not really sure I see an alternative, but to some degree, it is damned if you do and damned if you don't. (rock and a hard place?)

This issue does not realistically seem to have any simple resolution.

It is my personal hope that some reasonable and adequate framework that works for both 3DR corporate and our Open Source / Open hardware principles can be worked out.

Best Regards,

Gary

Robert Lefebvre

unread,
Apr 23, 2014, 4:13:25 PM4/23/14
to drones-discuss
I'm not suggesting that clone customers be forced to compile and upload themselves.  That's not a workable solution as you suggest.  The idea is that clone manufacturers should provide their own binaries to their own customers.

GNU is an Open Source license.  Not an Free Binary license. The point of the Open part, I believe, is that it's  "Libre", but not necessarily "Gratis".  And I believe that the license permits quite a bit of leeway on what you do with the distribution, it's the Source Code that is what is required to be open.  And it is.

I don't see anything in the license that suggests any person or company is required to expend resources distributing the software to somebody else's customers.  Nor does it say that any person or company is required to provide support to somebody else's customers.  And it seems like it allows a lot of leeway for distributed binaries to do things to prevent both of those things.  Really, nowhere does it say that a software creator must allow the compiled binaries that you distribute run on anybody's hardware.

I think John Arne's stance is more of a moral statement, than it is a legal one.  My moral compass points in a bit different direction.  I really don't see the problem here.  The Source is Open.  The very fact that somebody has forked it and set up distribution for an OTP modified version is testament to that fact.  There is the outstanding question about the binary blob that John has asked about.  I wonder if there's a problem here where, if the source code for that file was provided, would it then reveal the key for the OTP check?  If that's the case, then we have a real pickle. 

Gary McCray

unread,
Apr 23, 2014, 5:08:49 PM4/23/14
to drones-...@googlegroups.com
Hi Robert,

You are right it is open source, not open binary, but the reality is that people who do go out and buy unsupported "clones" with invalid OTP's are going to either have to throw them away or to attempt to compile them themselves.
And that is likely to cause more of our efforts to be diverted to them rather than less.
Given the hostility we have expressed for clone users, they have no incentive to reveal that they are trying to get us to deal with clones.
Just seems a logical outcome that's all.

The legal issue is separate from that and probably resides in the fine print.

Ethically and expectancy wise, the OTP issue is divisive and some people will think it's OK and others not.

I would think that if you were requesting direct support from 3DR it would be reasonable for 3DR to require you to prove you were in fact a customer who had purchased the part assistance was being requested for.

On the Other hand requesting assistance from DIYDrones is not so clear cut. 

Although it is a heavily 3DR supported group, it is also an open group consisting of both paid and volunteer contributors, providing exclusivity to 3DR products there is not nearly as cut and dried.

In fact the primary justification in DIYDrones for being as monolithically supportive of 3DR relates more to the fact that we can best depend on their hardware to perform because they are in the front of the loop and they can be expected to and have proven to respond the fastest to fix and improve it.

DIYDrones actually has great synergy with 3DR and none of us want to waste our time dealing with the completely non-reciprocated problems associated with the straight rip-off unsupported clones (and we seriously resent being asked or expected to do so).

The OTP thing is one "Solution" but it is not without problems, that's all.

Best,

Gary

Robert Lefebvre

unread,
Apr 23, 2014, 5:29:18 PM4/23/14
to drones-discuss
The DIYD support thing is a completely separate issue.  My personal stance on that, if somebody has found a problem with the code, I'll help with that regardless of hardware source, because if they've found a bug, then squashing it helps all users.  But what I will not do is help clone users who are having problems due to janky hardware. Mismatched hardware, following Joe's advice, etc.    Where it gets tricky is the in-between...  people having operational issues, setup problems, things like that.  I generally go with don't ask/don't tell, and would help regardless unless I'm feeling particularly grumpy that day. ;)

jdennings

unread,
Apr 23, 2014, 6:08:10 PM4/23/14
to drones-...@googlegroups.com

Return from the OTP check a “3DR pixhawk” message, or “RTH-Pixhawk”, or “Unknown”, for boards that did not bother to implement? Simple,  fair, and fully in line with open-source philosophy.

There’s this mistaken view sometimes  that 3DR “originated Ardupilot (http://www.diydrones.com/profiles/blogs/game-of-clones?id=705844%3ABlogPost%3A1616900&page=7#comments). That’s simply incorrect, as the code base, although much re-written, originated from classic open-source community a long time ago, and still exists thanks to the many great volunteers with no affiliation with 3DR.  While 3DR has been and is a great steward and facilitator, it does not own Ardupilot, nor Mission planner, and one-way and unannounced decisions disfavoring other boards,  e.g. in open-source Mission Planner, is disturbing.


On Monday, April 14, 2014 1:01:48 PM UTC-6, john...@gmail.com wrote:
I normally don't follow the PX development groups, and was just made aware of that 3DR Pixhawks use OTP certification to limit "clone" functionality when using official builds.

Is this really true? And if so, why has it been kept semi secret? This is exactly the kind of thing that will blow up in our faces big time, and exactly the opposite of what our previous stance with regard to clones have been.

In fact, before learning about this,  I just defended 3DR in RCGroups with regard to a clone board having OTP problems. I naturally assumed this was just a problem with an incompatible bootloader, not 3DR actively blocking clone boards. Seems I was wrong. Dead wrong..

From the outside this looks very much like 3DR commercial interests taking priority over open software/hardware philosophy. And the issue needs to be addressed in a VERY CLEAR AND CONCISE WAY right now.

- JAB



Andrew Tridgell

unread,
Apr 23, 2014, 11:22:43 PM4/23/14
to john...@gmail.com, drones-...@googlegroups.com
Hi John,

I just wanted to let you know that I share your view that there is an
important difference between "warn and continue" and "warn and abort"
for board manufacturer detection. I personally would far prefer "warn
and continue".

There are a range of views among the APM developers about this, and the
current behaviour is a stopgap while discussions continue on the
issue. My own views align closely with the ones you have expressed in
this thread, but I also think that the principle that a project leader
gets to set policy like this is very important, especially when there
are arguments both ways. So that is Michael and Bill in this case, not
me.

I don't use MissionPlanner or APM Planner myself, and I don't contribute
to them (or only on an insignificant level). I know they are very
important tools, and a lot of the community seem them as the "face of
APM", but I view them as separate projects, and as such I think
respecting the decisions of those projects is important.

There are some discussions going on to try to resolve this in a more
coherent way. I hope you will be patient while that is sorted out, but I
just wanted to let you know that you are not the only one who is
uncomfortable with the current mechanism.

This is the first FOSS project I've been involved with where this
specific issue has come up, so I don't have a strong set of precedents
to fall back on.

Cheers, Tridge

hontaksenpoka

unread,
Apr 24, 2014, 6:26:10 AM4/24/14
to drones-...@googlegroups.com
Why we fear cloners, we should fear competitors to project, and there are many. Leveraging market penetration should be number one goal at this time IMHO. This is not the war we should focus right now.

Saying that cloners, that do not contribute anything are parasites, is true, but saying they are not beneficial to project we love, is NOT, they really are. 

For now competition is fearsome in this area, winner is party who has best ecosystem and largest market penetration. 

For doing this kind of moves WILL slow down market penetration, which in long run could be devastating. I have seen many nice projects falls because of this. This very same thing is why Android is so successful now. I really hope that VC money not lead to this direction in means of short term financial wins...

I really would love to see as little forks as possible but many HW producers as possible. I would love to see that 3DR differentiates itself by means of support, hardware quality, certifications by 3rd party, certifications of govermental use etc, there are lots of ways to differentiate as a premium FC maker. 
 
For now there might be possibility to extend project visibility and market penetration to really compete DJI and the rest... and now there is move just opposite direction. I dont get it. Now market get very cumbersome signal.

...Or maybe i am only one who see market penetration and diversity so important in future success, for all parties. 

Sam

u4eake

unread,
Apr 24, 2014, 12:41:07 PM4/24/14
to drones-...@googlegroups.com

I'm fully with JAB and Tridge on this one.  Warn and continue, ok, but warn and stop is a bridge to far for me.  Already mission planner has been forked without the OTP check.  So the impact on knowledgeble users is limited to a nuisance.  But for inexperienced or new users this will lead to a lot of frustration, questions, etc.
Wat worries me also is what comes next?  Hiding commits or changes to the codebase so the forks are unable to follow?  This seems like the logical next step.

john...@gmail.com

unread,
Apr 24, 2014, 3:49:04 PM4/24/14
to drones-...@googlegroups.com, john...@gmail.com, and...@tridgell.net
Thanks for the support Tridge.

I must confess I have been a bit suprised on the lack of response or just plain acceptance on this topic. I could play the "this project is to influenced by one company" card, but I honestly just think it has do with the crowd being a special interest group with regard to unmanned robotics instead of the average FOSS project crowd. Which in many regards is a good thing, since it get's things done instead of the endless bickering. :)


- JAB

john...@gmail.com

unread,
May 3, 2014, 2:46:05 PM5/3/14
to drones-...@googlegroups.com, john...@gmail.com, and...@tridgell.net
I just wanted to say thanks to Michael for the latest commits recently made to MissionPlanner.

https://github.com/diydrones/MissionPlanner/commit/8bc7c9f3d3479017fee112000ec2522cd3c0fffa
https://github.com/diydrones/MissionPlanner/commit/b50baa50c81d52246ddac57435ca2011e4a1ac03

This is the proper way to integrate vendor checks and still maintain the open-source mentality or "spirit" if you like.
In my book the OTP issue is now solved and the case is closed. Cheers!

- JAB

witness...@gmail.com

unread,
May 3, 2014, 5:38:01 PM5/3/14
to drones-...@googlegroups.com, john...@gmail.com, and...@tridgell.net
Yes I concur, Michael has done the ethical and proper actions under GPL V3
and complete "installation information" for installing "modified objects" to User Consumer hardware is now available without restriction.

     kudos and thanx
     HZL

Craig Elder

unread,
May 3, 2014, 6:36:29 PM5/3/14
to drones-discuss, John Arne Birkeland, Andrew Tridgell
You are very mistaken.  There is no obligation to load compiled binaries onto any board just because it will run Ardupilot.   If there is an ethical choice to be made, it should be to support hardware that is made by manufacturers who are known to be adhering to the licenses, but even in the case of manufacturers who are adhering to the license, (VR BRrain and Fly Maple for example)  Mission Planner does not load code onto those boards and there is no expectation to do so.


--

Curtis Olson

unread,
May 3, 2014, 7:16:20 PM5/3/14
to drones-...@googlegroups.com
I'm jumping in here way late, but I'd like to add one comment.  I am one of the founding developers of FlightGear, an open-source flight simulator.  FlightGear has been challenged by a variety of rip off artists along the way and mostly we just try to get the word out as best we can that the newest version of everything is available for free from flightgear.org directly, and otherwise ignore these guys.  When I have engaged in a battle, I've found that these guys are willing to get far nastier than I am willing and thus it's not a battle I wish to fight.  (And I'm only reporting my personal experience, not projecting implications on the parties involved here in this discussion.)

FlightGear is open-source and 100% free, but we and others sell distributions for those that want a physical copy of the program or scenery, and as long as our open-source licensing terms are honored, there is no problem.  But the point I'm getting to here is that I (too often) receive personal emails demanding help or even demanding a refund from me, when I was not the original seller.  My typical response is that I  have no record of selling them their copy of FlightGear, but if they can show me a paypal transaction ID or some other proof that I'm mistaken, I'll happily work something out.  Usually that sends them on their way.

But because of my own experiences, I totally "get" the desire for 3d robotics to tag their own products with a specific code that can't be copied by cloners.  It protects them from a worst case scenario of some cloner's customer coming to 3dr and demanding their money back, or a replacement board, or some sort of service/support, or even some sort of restitutions for damage caused, etc.  I'm sure 3dr does 10,000x the volume FlightGear does, so if I see a few of these a year, I can only imagine what 3dr probably has to deal with.

At the end of the day, for an open-source project, the complaint department is over there through that door ... well stocked with text editors and compilers and documentation editing tools. :-)

Curt.


witness...@gmail.com

unread,
May 3, 2014, 9:37:04 PM5/3/14
to drones-...@googlegroups.com, John Arne Birkeland, Andrew Tridgell
Hi Craig ,
          I feel all of us have argued this into oblivion.. but again my main issue was "installation information" which has now been satisfied according to the terms in COPYING.txt.
about clones vs "authorized" clones that was never the issue for moi.. just the legal clauses in COPYING.txt.
And those were resolved with the latest checkins by Michael. All the rest of this is for others to keep arguing about or to get resolved and go back to flying and developing.

        all the best
        hzl
ps who is is trying NOT to be distracted by this anymore.

David Pawlak

unread,
May 4, 2014, 12:55:24 PM5/4/14
to drones-...@googlegroups.com
@Curt,

You sometimes wonder.... the lengths they are will to go to to make a stink, when 9 times out of 10, it would be far, far less of a hassle for them to stick to the rules.

Thanks for your words.

Toby Lankford

unread,
May 19, 2014, 9:09:50 PM5/19/14
to drones-...@googlegroups.com
I would have to say that I am of the camp of open to everyone and don't start or engage in battles.  The decision to limit the software was detrimental as the posts in every forum have been rather negative with a few 3dr people trying to defend this move.  We are all working and contributing in some way.  Whether through ambassadorship for drones and FPV in our community or working with the community to get features working and working with the equipment.  If we start keeping score then we will see that a lot of contributors should have been paid and maybe a few that were paid should not have been.  Open source is so that you don;t have to worry about trying to fight these battles.  If 3DR needs to adapt then that what it has to do.  But I am afraid that this conversation is dangerous and could have serious implications for the future of the project as a whole.

Peter King

unread,
Oct 22, 2014, 10:00:46 AM10/22/14
to drones-...@googlegroups.com
OK So is 3DR saying that their boards are not clones???
So did 3DR develop the Pixhawk board? Because I was under the impression that it was developed by ETH in Switzerland?
Then if 3DR didn't develop the board and indeed the Pixhawk board is n fact an open source hardware project then the 3DR manufactured Pixhawk boards are clones just the same as any other company in China printing their own PCB's.

I agree their are plenty of cheap Chinese boards on the market with inferior quality components.

Craig Elder

unread,
Oct 22, 2014, 2:01:47 PM10/22/14
to drones-discuss

3D Robotics developed the Pixhawk autopilot in collaboration with the Pixhawk.org group at ETH.
Please check the list of contributors at https:// pixhawk.org/credits
Hardware
px4dev, ETH
Lorenz Meier, ETH
Philip Rowse, 3DR
Laurens Mackay, ETH
Dominik Honegger, ETH
Julian Oes, ETH/ 3DR
Sam Kelly, 3DR
Jeff Wurzbach, 3DR
Craig Elder, 3DR

The boards manufactured by 3D Robotics are not clones. We are the original and primary source for the boards.

Wang Eric

unread,
Oct 14, 2015, 9:48:26 AM10/14/15
to drones-discuss
I just met the same problem 

在 2014年4月15日星期二 UTC+8上午3:01:48,john...@gmail.com写道:

Philip Rowse

unread,
Oct 14, 2015, 10:22:36 AM10/14/15
to drones-...@googlegroups.com
Far from it.  There is NO blocking of any boards.  Even if the OTP is empty.  It simply gives a warning.

It is helpful for all users to know where their boards come from! 

At the moment, if you try to load on the 3DR Pixhawk 2, you get the same error! 

There is NO attempt to lock out any other hardware.

PHILIP ROWSE
    LEAD SYSTEMS ENGINEER 
    3D Robotics
    website | facebook | Instagram

Wang Eric

unread,
Oct 14, 2015, 9:45:33 PM10/14/15
to drones-discuss
Thanks

在 2015年10月14日星期三 UTC+8下午10:22:36,Philip Rowse写道:

Craig Elder

unread,
Oct 14, 2015, 10:43:48 PM10/14/15
to drones-discuss
You can also create your own certificate and load it to your board.

Coleman

unread,
Jan 29, 2016, 4:55:53 PM1/29/16
to drones-discuss, Craig...@uniserve.com
Craig,

How do we go about creating our own certificates?

Craig Elder

unread,
Jan 29, 2016, 4:56:34 PM1/29/16
to Coleman, drones-discuss

Daniel Frenzel

unread,
Jan 29, 2016, 6:10:46 PM1/29/16
to drones-discuss
I think that all this certificate stuff would make sense in closed source software projects.
As Craig already noticed, for OSS it doen't make any sense, as the system can be avoided.
For customers it could make sense, if they would be warned. However, I think ths is not really done accurately. 
I mean, if its true, it seems to be solved in a totally rediculous way :D Just at the end of the line @ the level of the GCS software :D

john...@gmail.com

unread,
Feb 1, 2016, 9:11:44 AM2/1/16
to drones-discuss
I have to agree. I did understand the need for 3DR to only support legitimate boards, but DRM has never been an effective solution.

Point in case. When this was going on at worst, it took me less then an hour to figure out and compile a OTP free version of the firmware tool. And while I stopped there, it would only have taken me an hour or so more to make a version that would spoof the correct 3DR key for any board.
Reply all
Reply to author
Forward
0 new messages