My current vague understanding is that on Pixhawk, you can choose to use either the native PX4 flight control stack or you can run APM on the PX4 middleware instead: https://pixhawk.org/firmware/apm?s
Which one is better if I am interested in developing codes for indoor autonomous flight?
Also, how should I install APM on PX4 middleware and how to just install the native PX4 flight control?
Replies
I use the Ardupilot codebase in a university setting. I personally found the Ardupilot code to be much easier to follow and more straightforward to change. I also find that the developer website for ardupilot to be pretty well documented. Ardupilot code comes with 'UserCode.cpp' which allows you to easily add your own code into 100Hz, 50Hz, etc loops.
I'm no fan of NuttX, but I think the Nuttx concept is a Unix like system on a microcontroller. I dont see any barrier to porting it to different hardware. As to whether Posix is a good basis for an RTOS, probably not, though it is in use in most flavours of ArduPilot being worked on at the moment I think, since, as most developers on both projects come from a non embedded background, they find it familiar.
I think its lack of suitability becomes less visible as hardware improves and brute force overcomes the deficiencies.
Andy Little said:
Sure, the early APM years had a lot of make it up as you go. That's the price of being early and bleeding edge. But as the project matured there has been at least two major refactorings. So not much original code left there I am afraid. The current APM HAL is purpose made to quickly port to new hardware and as it becomes available. PX4 on the other hand is pretty much stuck with NuttX for better or worse.
1. You are paid to; or
2. You want to make proprietary changes.
Performance, functionality and support is simply so much better with Ardupilot - but the goals and attitudes of the two projects are different.
Andy's comment on the code structure is sort of true - the px4 codebase is easier to follow, but it is also less efficient.
Ethan, there’s no such thing as APM/Ardupilot running on PX4 middleware, the latter being based on a publish/subscribe uORB message passing architecture fundamentally incompatible with Ardupilot. It does get confusing though, as Ardupilot (on Pixhawk 1, which is just one of many hardware platforms Ardupilot runs on) indeed rests in a few places on some very low level PX4 firmware (definitely not middleware) with drivers jointly developed by the Ardupilot and PX4 team. This is being phased out by the way, (among other reasons for gains in flash space) and its origin mostly comes from the early days of the Pixhawk platform, back when the Ardupilot development team and 3DRobotics worked together with the PX4 team towards the commercialization of Pixhawk 1, designed for Ardupilot. At the time if was logical to share some of the drivers since both Ardupilot and PX4 run on Nuttx on Pixhawk. A significant part of the low level PX4 layer was written by the Ardupilot dev team by the way. This was after Ardupilot enjoyed wide adoption with the APM 2.5 hardware flight controller boards.
As to comparisons, only my opinion of course but both are great autopilots. Ardupilot has a longer history dating back to 2009 or so, vs PX4 circa 2012, although as with all things it depends on how you define maturity with an autopilot, and where you set the bar in terms of wide adoption. In fact, and as a historical aside and tidbit, if one were to go back as far back in time as possible one would find that the name arducopter (and a year or so later Ardupilot) was first used by Jordi Munoz in 2007 , (at the time this was only for flight stabilization). the same Jordi who later designed the APM Arduino based flight control boards that saw massive Ardupilot adoption in the autonomous UAV world, and the same Jordi who later co-founded 3DR and now runs mRobotics. It was only after that first phase (2009-2013) and wide adoption that Ardupilot was ported to the more powerful ST Micro based Pixhawk by its development team.
Ardupilot also has very detailed and in-depth documentation, (see Ardupilot documentation here, PX4 documentation here ) has plug and play support for a great number of sensors (IR for precision landing, L1 GPS and many plug and play l1 RTK solutions like Drotek’s Tiny RTK and the upcoming plug and play RTK solution on Pixhawk2, also l1+l2 RTK), plug and play rangefinders, actuators like parachutes and magnetic grippers, optical flow, indoor position systems like Pozyx, ADS-B transponder, antenna trackers, etc ... I’ve also found that integration of many sensors is easy and very tight, Lightware rangefinders parameters for instance can be tweaked with just a few clicks for sensitivity and response speed. This may sound like a detail but sometimes details make all the difference in the world ;) .
There are also many Ardupilot features uniquely available, like an unmatched number of flight modes in copter, advanced take-off and landing options in plane (e.g hand launch, bungee, catapult for take-off, or adjustable glide slope, helical, reverse thrust, net landings) auto-tuning, ports for a wide range of hardware platforms beyond Pixhawk and those supported by PX4 (VR brain, BeagleBone Black with cape, Pixhawk2, many older Arduino based boards, etc ...) and several groundstations (Mission Planner, APM Planner, Mavproxy, along with many phone and tablet GCS apps). And of course support for a unique and wide range of vehicles including rovers, boats, submarines, quadplanes, tilt rotors, etc ... used by many. See also this latest blog entry for the latest on seamless integration with companion computers like Intel Edison or NVidia's TX1 (still in beta).
In terms of development there’s been some great R&D work with PX4 (e.g. Kabir great work reported in this forum here, and that’s just one example), same with Ardupilot also widely used in academic research as in here , also just one example. There’s also been some cross fertilization within the two platforms, QGroundcontrol ground station for instance supports both architectures, or the development of Ardupilot’s Pymavlink. Also a large part of Mavlink implementation was written by the Ardupilot dev team.
In general though the availability of Ardupilot as a GPL FOSS project has greatly contributed to its wider adoption, both in the amateur and professional world, while PX4, as a BSD licence based open source, does not benefit as much from a code base growth perspective, as Rob wrote above. A few large players, however, like Qualcomm, Intel and Yuneec I believe, are using the PX4 base. That said Ardupilot has also been ported to the Qualcomm board, in a record two weeks time to boot, thanks to its modular architecture. And an Ardupilot Intel port is also on-going. Speaking of development look forward to some great Ardupilot work supporting vision based tasks, both with and without ROS integration. This work is being done as we speak ...
Ardupilot’s wide adoption has also been a great plus when it comes to testing, as there is a larger number of alpha and beta testers, be they professionals within the “industrial” UAV world, or hobbyists. This has greatly contributed to Ardupilot’s extraordinary reliability, as issues are easily caught early in the release cycle and code is wide open and available to anyone for inspection. This wider adoption is likely to remain so IMO, as most if not all companies using the PX4 code base do not “grow” the code base with their modificatons and improvement as they keep those in house. Ardupilot on the other hand follows a typical GPL FOSS model, like Linux and Apache who are prevalent, “industrial strength”, and the most reliable in this Internet world, and the standard for large businesses likes Google, Facebook or Amazon.
On the development side the Ardupilot community have been thriving, with many contributors from all walks of “UAV related” life, students, academic researchers, professional UAV service providers, UAV builders, hardware flight controller designers and manufacturers, world class software engineers, PhDs, high end electrical, mechanical engineers , etc ... you name it , joining and contributing. Ardupilot and technical questions are also widely discussed on Ardupilot.org, this forum, RCGroups, several Facebook groups, etc ... Of note Ardupilot has also won many prestigious awards, including first place and dominance at the 2016 International Micro Air Vehicle Conference held in China last year, and first place at the most difficult 2016 Medical Express Outback challenge in Australia. It was also the autopilot used in the successful maiden flight of the joint Airbus-Local motors “Cargo Drone” challenge winner late last year. And has always been a champion at the Sparkfun Autonomous Vehicle competition (rover category, and aerial drone when it was in place).
Could write more but this comment is long enough ;). All in all and to conclude your best bet really to answer your questions is for you to visit both sites, respective forums (here and here) Github repos and gitter channels, and check out both documentations. That’s where you’ll find the best information on how to work with Ardupilot or PX4, and see for yourself which one is more appropriate for what you’d like to do.
Hope this helps ...
Certainly the PX4 design is better in that it was top down designed whereas ArduPilot just kind of evolved
No, that article was trash when it was written, and hasn't gotten better with age. Mostly made-up facts, that I wonder if the author also works for Bietbart. Almost every statement they make can be countered with cold, hard facts.
The claim about the pace of commits on PX4 slowing down in particular, can be very easily disproven by simply going to Github and looking at the commit history. Nice little graph showing consistently less than half the commit rate, and not changing. Even after they tried to cook the books by pretending that operating system updates (Nuttx) were actual flight code work. This is the downside to BSD. All the users take the source, but don't contribute back.
The other thing the article doesn't talk about, is the actual flight performance. This is harder for people to judge, which is why PX4 is able to do such a good sales job to the CEO's of large companies who just don't know any better. However, the proof is out there. There are simply far more commercial systems successfully flying Ardupilot for real world uses than PX4. And most of the consumer/retail systems that use PX4, have been failures. The companies have to waste considerable time and money just getting the things to fly right in the first place.
Just as one example, some very advanced operations I'm doing. PX4 is simply incapable of flying like this. Forget that their heli code is about 5 years behind Ardupilot. Even their multirotor code is vastly deficient. You will see Ardupilot flying some of the largest multirotors in existence, carrying real payloads, doing real jobs. Most PX4 usage is on small quads in school laboratories.
But it is good to have choices. Try both. If you want more opinions on this post some questions at http://discuss.ardupilot.org
My reasons for not being enthused about PX4 are simply that I am not going to support any efforts to develop a flight stack that is being dangled in front of major corporations as a starting point for their proprietary commercial systems. It is a different kind of open source. That is just my opinion though. On a technical level it is hard to get the unbiased viewpoint.
https://medium.com/@Dronesmith/why-we-chose-px4-vs-apm-as-lucis-def...'
This Page will guide you!
and I think in indoor missions it's better to use px4 because it's compatible with several useful sensors!
I'm also wondering the same thing. It appears that to get the px4fmu "native" flight control stack you can upload firmware using Qgroundcontrol. If you want to run ArduPilot on top of the px4 middleware upload firmware through mission planner.
My question is will APM running on px4 middleware make use of the hardware advantages the px4 has over the APM 2.6, or is it simply emulating an APM 2.6 on px4 hardware?
I'd really appreciate someone weighing in on this
-
1
-
2
of 2 Next