For the attention of the users, supporters, fans and corporate users of ArduPilot:
The ArduPilot project is going through a transition. We will no longer be associated with DroneCode and instead will be focused directly on the needs of our users, contributors and partners.
We had high hopes for DroneCode as a collaborative project. DroneCode was born out of the ArduPilot project and we led the technical collaboration since its inception nearly two years ago. As part of that collaboration we welcomed and nurtured close ties with the PX4 project and worked closely with a number of corporate partners.
Unfortunately DroneCode has a built-in flaw. The structure and bylaws of DroneCode are built around exceptional power for the Platinum members, giving them extraordinary control over the future of DroneCode. This is a fundamental flaw in a project meant to promote free and open source software as it means that the business interests of a very small number of members can override the interests of the rest of the members and the community.
Just how great a flaw that is has been shown by the actions of the Platinum members over the last two months. Due to their overwhelming desire to be able to make a proprietary autopilot stack the Platinum members staged what can only be called a coup. They removed all top level open source projects from DroneCode, leaving only their own nominees in the Technical Steering Committee. They passed a resolution requiring that all projects hand over control of all trademarks, accounts and domains to their control.
The PX4 project leadership decided to accept this, and will be handing over control of the PX4 project in order to remain in DroneCode. The ArduPilot project won’t be doing this, as we firmly believe that community directed development is the best way to create a long-term sustainable free software autopilot stack. That means we are not willing to hand control of our domains, trademarks and development accounts to DroneCode, and by extension to the Platinum members. We believe that giving the Platinum members that degree of control over the future of ArduPilot would be irresponsible. ArduPilot is a community project, and its future direction must be set by the community.
We did not want this outcome, and neither did the Silver members (represented by all 3 elected Dronecode board members). We wanted to continue to collaborate, but the actions of the Platinum members and the choice made by the PX4 project means that DroneCode is no longer a place where community directed collaboration is welcome.
There is one aspect of DroneCode which we will miss. It offered a forum where we could work with the many companies that use ArduPilot to help their businesses make the most of ArduPilot.
To allow us to continue to have that relationship and improve upon the flawed DroneCode model we have made the decision to accept partners to the ArduPilot project. These partners will have their logo displayed on our new homepage (unveiled today; visit us at www.ardupilot.org33) and we will work closely with them to build a strong relationship for the benefit of both their businesses and the ArduPilot project.
We will have a monthly meeting between the ArduPilot development team and partners where we will discuss the future direction of ArduPilot and work together on issues that are important to our partners.
More information on becoming an ArduPilot partner is available here:
We also welcome individual contributions, with donations welcome from all users. The most important contributions, however, are those made by the hundreds of people in our vibrant community who have contributed code, documentation, code reviews and support for our users.
The ArduPilot development team would like to thank all our users, contributors and partners for their support, and we look forward to continuing the development of the autopilot that this community loves.
The ArduPilot Dev Team
I don't think it matters much if you use the original code that was written for the ardupilot. If you want an easy onramp to coding the best way would be the ardupilot 1.
The code back then was simpler and it worked well for planes. It could be much better and the size of the memory keeps the code small which is good for beginners.
That was an amazing feet to get that much performance from the 328.
I've already decided that's the way I need to start and I'll document it for others to follow.
Then just climb the ladder.
@Rob_Lefebvre You wrote
Correct me if I'm wrong but in Europe you really can't patent a general idea like Gain Scheduling or white rectangle. Even APIs are unpatentable in Europe. You can only license (maybe also patent if it is really not too general) your implementation.
And there are things that you really can't implement in many ways so similar implementations do not necessarily indicate licence violations. However if the code is really outright copied like you indicated that it is then it is seriously bad...
Isn't the "complexity" stemming from the fact that Ardupilot is a very mature and reliable autopilot firmware that serves almost all needs with perfection. There are other firmwares focusing on specific UAVs - for example racers. But these may not be able to trigger cameras. Others may not have autotune. Etc.
I really appreciate the effort the devs put into the system! The current code review process is professional and strict. And I think this is what really counts. If there are ideas to make the code structure simpler - I am sure they are welcome. But there are so many users with different needs relying on Ardupilot that it is hard to image what a "simpler" ArduPilot should be.
there are three types of linux fc designs has been implemented, and a incomplete zynq soc/fpga poc:
* BBB based integrated RTC pwm control: erle robotic 1st gen and bbb mini
* i2c to pwm: navio1 and pxfmini
* stm32 pwm with failsafe: raspilot beta, v1.0, v1.1, and navio2
I have a few stm32 version board i can spare if you are interested to test, and new i2c2pwm board under testing, i want to build a rpi zero copter with sololink equivalen. new board will be available in Oct.
I seriously think that it might be a good time to start work on this mythical "simpler" Ardupilot that I have been baning on about. I have had a lot of thought about it. The only thing that has stopped me really is the inevitable backlash, but it is making more and more sense to me and now with active encouragement from some devs... maybe it is time ! The point is that there is loads of great cheap hardware including APM2.x , like Naze32, OpenPilot Revo etc and it would be fun to try to those running a version of Ardupilot or running as IO boards with a linux sbc etc.
I am an outsider who has benefitted greatly from the work of this community (while contributing very little) and I'm hopeful that these disturbances damp out over the next few weeks and months. I've read everything people have linked to in this thread it's been a good reminder of how invested all of you are in this work. As hot as emotions are running, I'm impressed at the level of professionalism people are showing in this very public forum.
From what I've read, it sounds like the Ardupilot developers are walking away from Dronecode with their principles intact and full control over the future of their project. They are leaving behind the resources of the Dronecode Foundation, though I get the feeling (from what I've read tonight) that there wasn't much future support for them there anyway.
It also sounds like Dronecode has found a successful path forward to address their goals. I expect that both groups will keep publishing a lot of code and healthy competition will take us all further, faster, in the end. I don't think either group would benefit from the other's failure.
As someone who still has an Ardupilot 1 with a bunch of thermopiles taped to an Easystar in the corner of my lab, I sympathize with the calls for a simpler codebase that provides an easier onramp to this kind of work, but the facts are that making robots fly really well is not easy and the costs of not flying well are well known to all of us. The drive of the members of this community to continuously improve is what has distinguished it.
If you are looking for good onramps, for middle school and high school kids, I would highly recommend introducing them to a Parrot Minidrone and the Tickle App on a tablet or smartphone. It provides a great starting point for learning what it's like to program a thing that flies. For someone wanting to learn about PID controllers and performance tuning, I'd point them toward a cheap FPV quad with a controller that supports Blackbox. When I see youtube videos of people analyzing flight logs with Balckbox Explorer, I feel like I learned control theory using a chalk slate in a one-room country schoolhouse 200 years ago. The Baseflight/Cleanflight/Betaflight code bases are not tiny, but they are a smaller place to start than Ardu(code). While I am on the topic, if someone wants to dip their toes into assembly language, I'd point them to SimonK's ESC firmware. It's awesome and it's commented.
I'm hoping this community stays centered around DIYDrones.com. I've been coming here for a long time and we've achieved a critical mass that I haven't seen anywhere else. There is a momentum here and I think the broader community is elastic enough to accommodate many of these kinds of upheavals.
I'm hoping we all figure out a way for the Ardupilot project and team to truly thrive for many years to come. It really is on all of us, now, to make sure that happens.
Earlier in this thread, someone referred to the popular story of Apple stealing ideas from Xerox PARC. Apple actually licensed those technologies from PARC. Xerox keeps lots of lawyers on staff to flatten companies that steal their ideas. Xerox Parc's business model is to develop new ideas and license them to companies who will do the very hard work of turning them into products and bringing them to market.
I think there is an important parallel in that story to this situation. Chris Anderson has always been one of the first to respond whenever anyone has posted about someone "ripping off" the APM or the Pixhawk, reminding us that the open source license that all the work is published under allows that.
So even though it might be easy to cast these events in terms of stealing or back-stabbing, in many ways it's just the same stuff being given away that's been given away this whole time, because the license is free...
Anyway, it sounds like being associated with the Linux Foundation was just making everyone miserable anyway.
Now, how do we move forward?
i have put p9x design files on github, and i suspect pix2 or solo pix implementation suspension caused hard landing flip/bonny hop, and stm32 pwm/serial for linux designs. you guys just don't study it because it's from china.
So maybe to be clear, should ArduPilot clearly host the reference board open hardware designs they work with? So perhaps fork/host Pixhawk2, rebrand it, and host it as the preferred reference board for implementers?
Since ArduPilot cut their ties and are going to back to more open operations, perhaps now might be a good time to invite again people who are open source hardware guys (perhaps of the slightly famous variety) to take another look at Pixhawk2, perhaps Bunny Huang?
By the way guy's I baled out a while back to avoid the politics. Once Ardupilot is clean again I'll want to contribute again.
@Rob hey your so much more in the thick of things than I am I totally understand where your coming from.