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
@Marc You got it right , the future is shifting from code to data. AI will exploit Neural Networks designed for very specific task and trained with rich datasets. The secret sauce will reside be in the training and not the code. For me it seem pretty obvious now that this is the future for autonomous fly of uav.
i have a new perspective proprsal for drone hardware/software integration:
1) IMU should be AHRS capable and easy for redundant backup integration
2) Actuator Units should use high voltage or main battery unit rail
3) High level job should be script language like python, so easy for testing
and:
DO NOT TOUCH ZYNQ UNLESS YOU ARE A EXPERT: F22 used VHDL and after lots of work it still buggy, how could you run it good on your Sunday project. after years parallella project still not promoted Zynq too much, and i don't think others will be too much different. only a Japanese kickstarter used it for micro quad but closed source.
HDL require too much compile time, i like writing code in trail and error way.
I love the design of PXFmini and NavIO 1, easiest way to do the hardware, the only problem is RPi ZERO could not be bought in bulk, and standard Pi is too big. I am planning to do it in Pi Computing Module version. And a Pi3 version CM is coming.
For a whole drone electronics, a CM works with and IMU and GPS, could work as an AHRS unit, you can do multiple of this AHRS on a plane and run an ESC array through a failsafe protocol bus, i2c, or multiple can chains. If it's a fixed wing, we can use FFC with battery voltage and bus signal (i2c or can), and a downconverter for 5A for servo.
use python code for high level code like opencv, probably will be easy to run on TX1/CUDA/myHDL or simply a powerful x86.
@John,
i did some test on LOAM on ROS and i have a benchmark Odroid X4 Octacore vs I7 5Gen .
So the result is with top tools 110 % cpu vs 15 % cpu ... so for advanced development no doubt about technology to use . About the Zynq , i agree that is not so simple but could be a great option need very good developer on it but it could be a not proprietary solution. On Zynq OpenCv i saw that is possible to use part of library on Arm CPU and other part on FPGA and mix this solution with great improvment of performance like a cuda systems.
Not yet tested the application that we are writing on Opencv on Nvidia TK1 but could be next step . I would try the same solution to Zynq and doing some benchmark.
Best
Roberto
haha, just happend to look at DroneCode to see which board members left ... which inspired me to this cartoon (you easily realize I'm not an artist LOL) link
@John - Don't want to sidetrack this thread too much or get into an argument as I'm certainly no authority on the matter, but I hope you're wrong about the snickerdoodle :) I think it's a really, really interesting proposition as a companion to ardupilot - it's a near perfect form factor, incredibly flexible, opensource and it's clearly being targeted at the hobbyist/education/low-end professional robotics market so hopefully it will quickly grow a community that will support basic usage without too much expertise. The Vivado High-Level-Synthesis IP is free to use and includes synthesis for all sorts of maths and vision algorithms ready to go. And if we can't do interesting things in 120 gflops then we're aiming too high! It's very early days, maybe it won't come to anything, but maybe it could be a 'new raspberry'.
Re the odroid, samsung are surprisingly active in the kernel community but they and odroid have done a very poor job of opening up the hardware, which is really odd. But Mali has been working for a long time so full access to the GPU power, and the MFC is finally now working for encoding as well as decoding. It could be worth another look with the oCam as there are very few other options out there for high speed uncompressed video with decent horsepower to process it.
Re Nvidia, I agree it's a really strong offering, but it's very expensive so far with poor form factor and availability (can you even buy the TX1 standalone yet?). And once you start writing to CUDA you're locked into nvidia.
@John
Here my suggestion: What about upgrading ArduPilot with AI-Pilot and running on the Tensor Processing Unit from Google ? :-)
@John
Yep, I agree to a larger extent that the flight controller should stand alone. I also believe at some point the flight controller needs to be triple redundant. At least on the higher level gear where things get too busy IMO to make the flight controller highly reliable (safer).
For development purposes I don't think it matters much but for complex industrial use applications you really need that kind of safety.
So I believe the ultimate end for a flight controller would be very fast redundant cores with a very simple and reliable polling controller/mux failsafe land,RTL ect... With a separate and simple manual mode comms and control system. The comms here are also redundant but there is no mission for this system other than to fly and RTL or land (say you had mechanical failure that would be a land best you can situation)
Put everything else in your main onboard computer.
Communications, Avoidance, Mapping, Mission and objectives ect... and higher functions not necessary to basic flight off board.
You may think avoidance would belong on the basic flight controller I would disagree and say any higher functions not required to RTL or land. Mainly because if your in this situation something is already wrong and main functionality is all you want between you and the aircraft.
@Jerry Giant.
If you are offering me one of your boards for free. I'll say yes :) How do I get one?
-
1
-
2
-
3
-
4
-
5
of 14 Next