Source: http://discuss.ardupilot.org/t/ardupilot-and-dronecode/11295
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:
http://ardupilot.org/partners17We 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
ArduPilot.org
Comments
Your right sorry I was off topic-
@Marc Randy was around at that time but Tridge was not.
Sparkfun made the first boards and the first APM 1 boards as well as the oilpan.
No surely Hobby King was not a good idea at the time. There should be some commentary from Chris about it on this forum if your fu is good enough you could find it.
Back then clones where shunned big time.
Change of topic. I have been meaning to ask Chris Anderson about this, as I had heard independently about this. A Hobbyking exec is claiming they have emails documenting a request to donate to the project (in a way presumably that many have long wanted) and that Chris Anderson turned them down. Chris, did this actually happen and if so why? Surely the world's largest RC supplier contributing to Ardupilot would have been a good thing? Or was it not a good thing for 3DR at the time. And why did they ask you anyway? Why did they not contact, say Randy or Tridge?
Maybe Ardupilot can get as good at governance transparence as they are at Developer transparence. I hope Hobbyking and Ardupilot are now in discussion. In general, we need to see who the Ardupilot board members are and there should be a clear contact and even guidelines for hardware vendors and how they can support Ardupilot.
@Monroe King
That is all correct and I fully understand your point. Building an autopilot for teaching purposes is a great idea. And there was some post while back from a guy using a simple version of Ardupilot for teaching (probably lost somewhere in the NING space...)
But maybe this entire discussion is a little misleading and confusing here since making a simpler autopilot is not related to what this bog post is about. It is at least two stories and all seem to get mixed up here :-)
Just my 2 cents
Cheers,
Thorsten
We can do a tear-down and rebuild of the original code together at the Ardupilot forum.
Dissect it and do a postmortem and then reassemble it.
That should be a good learning experience for anyone that truly wants to learn the real deal.
nuts and nuttx are close - getting rid of the nuttx reduces the complexity.
andy showed how to utilize freertos.
new hw means porting nuttx - and where is the know-how?
Where would you prefer to begin with 700,000 lines of code or 100,000?
Lets say you pick up an old pc and run linux and your dirt poor but want learn to program. Say that ordinary project boards wont work for you because it really needs to do something interesting like fly a UAV.
Say you have no prior programming skills but your a fairly quick study.
What I have found is learning the core process of flight and ahrs Direction Cosine Matrix and EKF and understanding the math for Euler angles and Quaternions and such is quite difficult.
If I'm going to teach I'm going to teach it all and not just placate the masses by making them think they understand something when they really have no idea what's really going on.
The idea here is to remove the magic from the box.
"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"
Thorsten, was thinking along the same lines. Seems inevitable that the code complexity and size have grown enormously from the early ATmega days, given Ardupilot's vastly increased functionality, bells and whistles, reliability, stability, versatility, etc ... For a codebase orders of magnitude simpler and smaller there's always earlier versions, e.g. for copters Arducopter 2.x for instance circa 2011. All Arduino pde files, ancient, yet very small and simple code base. But then again not even close to as stable, reliable, no EKF, GUI, etc ... We just can't have it all, simplicity on one hand, reliability and functionality on the other.
Just be aware that the lack of resources in the 328 actually made the system more complex then it had to be. As shown with APM you quickly end up spending a lot of time just tweaking and hacking what should be straight forwards tasks (usually math or resource timing related), just to work around HW limitations.
Also today a 8-bit is so outdated, that there is nothing to be gained price wise compared to a low-end 32bit with much more resources.
At the very least if your mind is stuck on using the 8-bit AVR, select a more modern revision like for example the AT90USB1286 with more I/O, timers and a proper USB interface.
I am aware of two efforts that aren't really on the radar screen, but I think have very interesting elements.
1. (full disclosure: this is my project, so I'm being self serving in citing it here.) :-) I have a hybrid system that takes an APM2, rewrites the firmware to simply handle sensor I/O and the RC receiver/servos. This significantly lightens the load on the APM2, yet allows it to do all the hard real time tasks. This gets married to a beaglebone (through a simple interconnect cape) and the main flight code, EKF, logging, etc. happens on the beaglebone. The APM2 drives the system clock and timing so end to end throughput and latency is fairly consistent and not affected too much by the beaglebone's non-real time OS. This system began development before the APM1 so it has reached a fairly good level of maturity. The code base is developed entirely independent of ardupilot, so that may be a downside, especially here ... but it also offers an opportunity for a different perspective on constructing a body of flight controller code. In my case I have embraced python right onboard (not remote scripts, but integrated directly as part of the core flight controller code.) Python has worked out really well for me and I now have a system that allows me to right higher level mission tasks (like autoland) in python. My hope is that this could make the system more open and accessible for experimentation and prototyping new ideas. You can poke around the code base here: https://github.com/AuraUAS
2. A coworker of mine is developing new hardware (also in the form of a beaglebone cape.) The core system consists of a teensy (which is a pretty powerful board in it's own right) that connects to the different sensors. The software architecture is similar to the system described above in that the sensor IO and RC is handled on the cape+teensy and the heavy lifting code will run on the beaglebone. That effort probably will be pure C/C++ and not embrace python like I have in my own code base. The big advantage of this hardware is that (a) it's inexpensive, (b) it's relatively simple to assemble yourself, (c) it moves us beyond the apm2 (in terms of cpu power and sensor choices), (d) a lot of prior thought and a lot of industry and academic experience has gone into the design and layout. You can order boards and parts to build your own very inexpensively here: https://oshpark.com/shared_projects/oS4Qcwv8
Perhaps both of these efforts are small enough and off the radar so they will get lost in the noise with all the other smaller non-pix, non-ardu projects. But I think they both offer interesting elements to the discussion of trying to keep an entry level path available for new DIY'ers that want to learn more about the hardware and the software architecture (versus just being handed an easy to use black box.) Hopefully there is room for all of the above. But I personally think that unmanned flying vehicles are complicated enough that it is very helpful to your long term success to be able to understand core hardware and software issues. It's immensely frustrating to crash and not know why. It's slightly less frustrating to crash, and then be able to understand why, and now you know how to fix the problem, or what to avoid doing next time.
-
3
-
4
-
5
-
6
-
7
of 14 Next