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
@Fnoop
Snickerdoodle aka Zynq-7000:
In my opinion FPGA is not a solution we can realistically use. The user threshold is much to advanced (albeit simpler then it used to be), and making a CV system from scratch in FPGA would be an enormous amount of work. Alternatively you would have to purchase proprietary IP modules for the features you need (provided they exist at all). And besides the 7010 and 7020 does not have enough FPGA gates for the tasks we are talking about.
Odroid XU4 aka Samsung Exynos5422:
Samsung Exynos is pretty much the definition on proprietary hardware. Nobody but Samsung when using the chip in their phones knows how to use the included MFC hardware for accelerated video decoding and encoding. Linux support is nonexistent. Same with the Mali OpenGL hardware, limited support in Linux. So with the UDroid XU4 you are basically getting a Quad core ARM CPU system only.
NVidia Jetson:
I was primarily looking at the Tegra K1 as a starting point and the TX1 reserved for advanced/commercial users. But the important point is that while the NVidia hardware is proprietary (is there any hardware that is not?), they offer full hardware acceleration on open API's like for example OpenCV. So you write your application using C++ and those API's without any direct link to the hardware underneath. This mean you can later move to any platform you want, as long as this one also support the API you used. It also mean you can do easy prototyping on a desktop computer without the embedded board.
@Monroe
This is one of the main reasons why I advocate a secondary computer for higher order tasks. To keep the complexity out of the autopilot. There is no reason why the quadrillion core supercomputer and a simple 8-bit autopilot should not be able to coexist in a system. After all in the end the secondary computer would just be sending basic control commands to the autopilot.
Ardupilot should target the academia for support. A lot of projects use Ardupilot and I'm sure many would see donating to the cause is in their best interest.
Heck, for all we knew, Nvidia has already attempted to join and maybe even sponsor some development work, but have been turned down by DroneCode? Wouldn't surprise me one bit.
Nvidia, if you're watching, please contact us directly. :)
The last comments are really showing the difference between Dronecode and Ardupilot philosophy == Here we can openly talk about the choice of future developments using and mixing different platforms and not being confined into an Intel - Qualcom exclusive hardware. I dont think that NVIDIA nor XILINX would be welcomed into the Platinum Club.
What really amaze me about this whole situation is that most of the actual autopilots are running on STMicro either Baremetal or RTOS ... :-)
Yeah I'm sure you guys will be moving forever forward but the older stuff is just fine for hobby/model aircraft work it's really all that's needed and it can be very inexpensive for the majority of the hobby. There just is no need for all the bells and whistles for average hobby aircraft.
But yeah for sure keep going up!
@John @Rob Amen!
The TX1 is a good bet but too expensive and locked down (proprietary) to be a baseline for CC, although an excellent 'premium' option. I like the look of the snickerdoodle - lots of IO, runs linux/rtos/ros, FPGA, onboard wifi with support for external antenna, very open and a focus on robotics - perfect match. Odroid XU4+oCam also a good option.
Higher functions like this must be separated from the core FC. This is one thing that the solo got right.
John, I agree completely with all you have just said. It's been my opinion for a long time too, that it makes more sense to use the companion computer model instead of all-in-one. It's safer, and aslo makes it easier to keep upgrading the CC computer as we experience rapid advances in SBC hardware.
I would like to work on CV (Computer Vision) for ArduPilot. But it would have to be a separate system running in parallel with the autopilot. So let's just call it ArduVision for now.
The reason for this is that in my opinion a secondary computer is the only sensible approach. Anything else is just asking for trouble, where overloading the system with high order computing tasks could affect core flight performance. Software stability would also be a big concern, with complex systems like OpenCV, OpenVX, OpenCL etc. running on the same board as the autopilot. Another reason for using a secondary computer is that when doing CV, robust recognition and accuracy are almost directly linked to how much computing resources you have available. So you will end up wanting more frequent hardware upgrades as better solutions become available.
I will also say right here and now that relying on the CPU is a dead end when it comes to CV. Even on a high end desktop computer, the CPU quickly becomes a bottleneck for these kind of tasks.
Another monumentally important thing is to make sure the board you select has solid support for CV libraries (OpenCV/OpenVX etc.) in the hardware. Re-implementing those libraries in a FPGA or something similar, would be an enormous task. With OpenCV and friends supported you get a running start, and an easy upgrade path to better hardware later on.
With this is mind, one of the best candidates at the moment with the right hardware and necessary software to support flexible development, would be the NVidia Jetson family.
@Guy, movidius is now Intel look here
@Jerry how would this be different than Navio or PXFMINI ?
IMHO , BBBMINI is presently a true DIY project; its is quite easy to build, and Mirko has published an excellent wiki that explain all the required steps to make it work and there is a great support on gitter. The BBBMINI group is quite active on this site as well; here is an open discussion for the wish list on the next hardware release.
I'm doing some test and evaluation on Zynq platform , my opinion is that for a pro development it fir all our requirment. The new revision Multiscale Zynq is awensome :)
best
Roberto
-
1
-
2
-
3
-
4
-
5
of 14 Next