So ran across this today. Doesn’t APM 3.3/3.4 run native on the hardware?
That is an interesting article, that we will have to address in time. Watch this space.
I would like to comment on a few specific points that I am knowledgeable on:
First, I’m not quite sure what the article is getting at with the discussion of the OS and Middleware. On Pixhawk, APM operates on top of the same exact OS and Driver layers as PX4 does. This has been a collaborative effort over the years, with APM developers making significant contributions to these codebases. However, APM is also able to run on top of Linux on some hardware. PX4-stack claims to do so, but, the proof is in the pudding. Has anybody seen PX4 running directly on the Qualcomm Snapdragon lately? How about the Intel Aero? Or a Raspberry Pi? APM is also still run “bare metal” on VirtualRobotix’s STM32 based hardware. We are simply more flexible here. And this answers your direct question.
Many of the claims to running more hardware peripherals, terrain estimation, etc. seems like false information to me. AC3.4 has terrain estimation, actually demonstrated to good effect in several videos by Randy where he has a quadcopter navigating a ski hill. Has PX4 actually published videos of their performance in real world conditions?
It is also rooted in traditional drone racing or hobbyist camera applications and has complete support for them.
This… this I’m going to have to say, is an outright lie. PX4-stack is rooted in the educational lab environment. Recently, PX4 tried to make an entry into the drone racing market with the Pixracer. While the Pixracer is nice hardware, the software was shown to be an abject failure. Unstable, and frankly, unsafe. Nearly nobody is using it.
By comparison, the majority of APM developers are professionals who got involved in development as they were flying RC as a hobby. Leonard, our lead multirotor control/aerodynamics developer, regularly flies racing quadcopters, capable of 30-40m/s. I regularly fly helicopters of similar performance. I use APM even on my sport/hobby helicopters, not just the UAV’s. Has anybody ever seen Lorenz Meier flying a racing quad?
APM (ArduPilot) was largely developed by 3DR.
No, APM was largely developed by APM developers. 3DR did provide some funding, but much of the work was done completely unfunded by community members.
However, as of late, APM’s development has drastically slowed down.
This is, again, an outright lie. This is very easily proven by simply looking at the Github stats.
PX4 on the other hand, is being championed by ETH Zurich as it continues to push the limits of flight control technology.
Don’t confuse PX4 with Rafaello D’Andreas’ work!
If we take a look at the actual flight stack of the very popular Pixhawk, we will find that it only uses APM as the flight control layer and the PX4 for the middleware layer and underlying OS for performance reasons.
What is the point here? How is it an advantage to PX4, that we run the exact same OS and middleware, having contributed and collaborated over the years? This is a neutral point.
3 Likes
I think a major point of the article was in the final section called, “Licensing”. It makes Luci seem different than a Pixhawk for corporate customers.
We have had many of our customers and users wanting to keep their firmware proprietary — PX4 gives them the freedom to choose how they distribute.
1 Like
Greg,
That point is also confusing. They are promoting the use of an upper layer by including the Edison. You can talk to ArduPilot via MAVLink - or even receive information via our new AP_Module - and choose whatever license you want.
You only need to share back if you change ArduPilot - and that, in our view, is a good thing: not only everyone can improve but companies don’t have to run their separate fork of the autopilot (benefiting faster from upstream fixes).