When we announced earlier this year that we were going to be working with Sony to bring out the R10C, which has the best sensor in the industry, we also said we were going to do more than just strap a great camera on a Solo. And we did: we've created a custom gimbal and API interface with the R10C that allows Solo Site Scan to not only automatically control every aspect of the camera in real time during flight, but also automatically transfer full-resolution (20 megapixel) images to the cloud wirelessly in near real-time, via our new iOS app. It's out now!
I am afraid, that all initial indications to the contrary, we have become one of the prime examples of why big business and open source do NOT coexist.
I wish it were otherwise, but it seems that when business gets big there is no room for any altruism or sharing at all.
They want it all - they demand it all.
And in our football game mentality, we give it to them.
Well, it does go the other way... to some degree. We can see PX4 Master. And if we wanted to, we could copy any part of it to Ardupilot. Completely legally, because their license permits us to do that. The BSD license is pretty close to the "Do WTF You Want" license. The GPL license, however, demands a certain amount of reciprocity.
In reality, this almost never happens. It does occur with us using the PX4 Operating System (based on Nuttx). But not the actual flight code. This is because the flight code portion of PX4 is so very far behind Ardupilot. As an example... I've seen a claim that "PX4 can fly helicopters too". The PX4 helicopter code is like 10 lines of code. It can only fly a basic RTF coaxial helicopter with a flybar in an office. Ardupilot helicopter code is like 1-2000 lines of code, and can fly high performance FBL machines, gas powered even. They aren't even on the same planet.
Anyway, back to your point... So we aren't in actual fact, taking any PX4-flight code, but they may be taking ours. I think most of us don't really have a problem with our code making it into PX4-master, as it is effectively open source code, and there is this potential for back-forth collaboration. What we really don't like, however, is that commercial companies, then fork PX4-master, and improve it, without contributing anything back to PX4-master, and thus, us. It is an avenue for the fat cats, to take our community-based code, and fold it into their own proprietary code. And we will never know.
I do know that is the claimed practice, actually followed at least occasionally, and if anybody who worked for them ever claimed otherwise they would be criminally prosecuted for violating their non-disclosure.
The real crooks literally are above the law.
As for the Github commits, that is just a matter of on / off line timing and knowledgeable manipulation.
I doubt that the necessary methods are outside the skill set of either Qualcomm or Intel.
And I am sure they would expect their employees to be utterly meticulous.
Any company can choose whether to release source or only object code - subject to the licensing of the particular software they claim to be using of course.
So, of course, if they want to release only object, they don't choose a license that forces them to release source.
Simply normal business - sadly.
So Ardupilot develops, improves, and PX4 can just read the source and try to replicate, yet it does not go the other way?? They are not compelled to release source code??
Standard practice, totally denied by every major electronics firm is the room where they dismantle the competitors products using laser etching and microtomes to reveal the inner workings of the ICs.
Reverse engineering is done ALL the time, as long as they can deny it (and bullet proof non-disclosure agreements guarantee they can) they can continue doing it.
As for code, only the actual code itself can be copyrighted, the ideas can't although every once in a while one of the major players (Apple or IBM for instance) takes a swipe at another one to see what they can get.
All you have to do is port the code from one compiler to another to effectively cover your ass.
And if all you release is the compiled code, you can really get by just changing the compile time parameters.
Make no mistake, Lorenz has done serious actual work on "PX4", but each of the features implemented are really just taken from the capabilities of ArduPilot.
Now 3DR / Dronecode is simply in the process of porting over each of the capabilities of ArduPilot to PX4 as quickly and directly as possible.
In fact, it would have probably been more difficult for them to do that with such impunity if the ArduPilot developers were looking over their shoulder.
Certainly it would have caused alarm.
BTW, my comment on the reverse engineering room is not paranoid hyperbola, it is from being in the rooms.
That is actually what is happening. We talked to them a week or two ago about blatant "porting" because that would mean that our GPL spills over into their BSD code.
But we can't stop them from copying the ideas and just re-coding it.
but would they not be able to just look and analyze the Ardu code and port it to PX4??
No John, I don't think so. Despite all the hype, the PX4 multirotor code is pretty low performance, and could not fly the Solo with the level of control, yet fluidity, that Ardupilot currently does. Flight speeds and acceleration rates would all have to be reduced.
I have a question that is actually on topic for this blog post.
Will the commercial products offered by 3DR be converted to a clean PX4 software stack? You know, eat your own dog food and all that.. Last time I checked, Solo still very much rely on ArduPilot for core functionality.
Chris, I'm not sure what you are trying to show with that link. Are you intentionally misleading people who don't understand how Github works?
Here is a better link to show Mark Charlebois' contributions:
Can you please point to at least commit that is improving core flight control or functionality that will benefit all users? From what I see, his contributions are nearly exclusively those which are in the direction of getting PX4 to operate on Qualcomm hardware and/or build systems fixes (for the same reason).
I'm sure there must be some there somewhere. But I can't find them.