My Opinion of the ArduPilot Platform and APM 2.x HW

The ArduPilot project gained a lot from the investment from 3DR, and it’s arguable that it would not be in this great and awesome state it is today without the money invested in enabling developers to focus full time on it over that period. If that meant prioritizing features that 3DR benefited from and the community also benefited from, that has been a good thing.

The other fact is that ArduPilot in a GPLv3 project which gives people freedom to use the code, fork the code and create new projects (as ling as they respect the license) to do as they please. Which you may not agree or like it, but that isn’t a license violation

I see that it was asked who’s funding the project now. Its the very same developers that @ChrisOlson and @Tim_D are giving a hard time. It’s a lot of free time and some paid contract work (ArduPilot and unrelated) to produce the product that is used by 1000s. Shame this whole thread isn’t really a positive engagement with the people contributing to the project. For example it could have been “How can we move forward development on APM2.x HW?” Some developer maybe interested, maybe not. Or “What the future roadmap for ArduPilot, not 3DR are less involved?” “How can i contribute to requirements management?” There a whole raft of things to be helpful with.

In the end whatever platform you use, it’s based on your requirements. And that will have Pros (APM2.x cheaper HW easier entry to development (though more tricky at this level that Arduino), PH continued development and improvements) or Cons( stalled development, slightly higher entry price, complexity in development)

In any case if you need help and I can help I will.

@ChrisOlson Thanks for the offer of the Debian build I will reply in that thread to get it up on the server. What would really be great is somebody with Linux skills to create a PPA, to a auto build server for linux. it’s on my list todo, but it’s a long list :wink:

1 Like

It would require a different I/O board. Possibly like a 2560 handling I/O while the A7 handles higher level functions. But the 8-bit platform is also easily and economically expandable, such as running dual cores with SMT. And if you need a little more clock simply replace the 16MHz oscillator with a 20. If you need more I/O capabilities, stack on a shield. Like you say, the 8-bit is pretty efficient on flash use, and I don’t think the full capabilities, and expandability was really explored much. When the code would no longer fit, it was just dropped.

It looks to me like the Pixhawk2 is using a form of Arduino shields for expansion of I/O.

I think you could use an APM2.5 or similar FC board for IO, and look at the ardupilot master-AVR branch for ready made libraries:
https://github.com/ArduPilot/ardupilot/tree/master-AVR/libraries

If you are starting from scratch I would avoid the Atmega2560 though, for all the reasons cited above. I would go for an Arm Cortex M4 processor. There is a wide range of dev boards, many of which are Arduino shield compatible:
https://developer.mbed.org/platforms/

You could even program the board in python if you wish and get about the performance of the Atmega2560 running C :slight_smile:
https://micropython.org/

regards
Andy

Hi Andy,

I took a little time to look over what I’ll term as “bloatware” that has been added since the move to 32-bit chips. And ahh… my god … I see a lot of parallels with the KDE project :slight_smile:

Anyway, you just do not need more than a 8-bit chip to fly a multi or fixed wing. And fly it really darn well. I have limited interest in heli’s but they are more fragile and maintenance prone than multi’s in the world of VTOL. So heli’s remain a limited interest, multi’s primary.

I’m from the camp of using the 8-bit as a navigation controller and stack the features on with shields. If the shield requires or enhances navigation it feeds the info to the flight controller. I never have been much for designs that stuff everything into one box because eventually, no matter what box you choose, it gets full. And when something breaks in it the whole thing is broke. And the more complicated the box gets, the more expensive it gets.

I’m exploring taking a few steps backwards, getting rid of the stuff that the 8-bit platform does not need and making a few optimizations, and see how much resources I gain on that old board. Then add something on to it, like say a camera controller. Or maybe a add-on LIDAR. But the add-on’s are separate components. All the basic flight controller does is fly the aircraft.

Just so people don’t make the mistake of thinking I’m advocating this as “better”, I’m not. It’s DIY for people that are not that interested in turn-key stuff.

ChrisOlsen, what you term bloatware might be some one else’s must have feature to do something (either commercially or for hobby). Lets take QuadPlanes as an example - something I’m assuming you have no need for and therefore bloatware, its something that a number of people are actively using, I have 1 completed and another 2 on the way.

The beauty of this project is that if you want to have 8bit support then you put the effort in, it’s simple really. You focus on what you want and you spend your time on the features you want. The great majority of users want this stuff, things like EKF2, etc…

Mean while the dev team will continue to support new features to spur on innovation. I look forward to seeing your contributions in the coming months to the 8bit version.

The reason I said it reminded me of KDE is because KDE, when it started, was pretty good. With time it became said that if there’s something you want to change in KDE, rest assured there’s a button, switch or slider someplace to change it. Only problem is, even the dev’s couldn’t remember where they were anymore.

Because so many features and options were added it got top heavy and unusable and was dropped by virtually every mainstream *nix distribution as the default desktop.

Today, unless you got a quad-core with a dedicated GPU and 8GB RAM you may as well forget trying to run it. On lesser hardware it is slow and crash-prone, and plagued with endless bugs no matter what hardware you run it on.

I call that “code bloat” or “bloatware” and it’s very easy for open source projects to fall into that trap.

ArduPilot software is far from perfect, but bloatware is better than vapourware.
Criticism doesn’t really solve anything. The only way things will change is

  • Write some better code.
  • Write down a detailed document with well thought out arguments and details of how to improve matters.

OTOH You could do well by re-invigorating the 8 bit code. There are a lot of APM2.x board and derivatives around

1 Like

I thought I’d add my thoughts on this as I was the maintainer of the APM1/APM2 port of ArduPilot.
At the time my roles in ArduPilot were:

  • HAL_AVR maintainer (for APM1 and APM2)
  • HAL_PX4 maintainer (for Pixhawk and related boards)
  • Plane maintainer
  • Rover maintainer
    Chris Anderson from 3DRobotics wanted the ArduPilot dev team to abandon the AVR based boards soon after the Pixhawk was released. The ArduPilot developers did not want to do that. I worked for a very long time to keep support for the APM1 and APM2 going. I had been the maintainer of the AVR port from the time the very first APM2 was produced (I did a lot of the original port to the APM2) and I didn’t want to abandon a board that was still working well.
    My work (along with several others) on supporting the PX4 series of boards started in late 2012. I kept the APM1 and APM2 working and kept doing releases up until September 2015. That is an eternity in the embedded development world.
    I finally stopped doing updates to the APM1/APM2 port because it was taking nearly all of my time just to scrounge up enough cpu cycles, memory and flash to add very simple features. I could not continue in my other roles and also maintain the APM1/APM2 port. The cost in terms of code structure and code complexity of maintaining the APM1/APM2 while also supporting newer boards was becoming overwhelming. It was severely limiting our ability to work properly with the HAL_Linux port which was far more interesting technically.
    When I announced the final release of plane for APM1/APM2 I put out a call for someone else to keep it going. I didn’t get any volunteers. I am still open to someone else taking on that role if they want it. It won’t be easy, but if someone was passionate enough about supporting these boards they could do new releases. I won’t be doing any new releases for the same reason I stopped doing them last year. It is just too difficult to work within the CPU, memory and flash constraints of the APM2 for the feature set that I want to work on.
    We kept this port going far beyond the time there was any commercial support for it because we care about the user community. Please remember that when criticising our decision.
    Cheers, Tridge
6 Likes

Tell it like it is Tridge.:slight_smile:
Regards,
TCIII AVD

I appreciate all the comments. I can certainly understand 3DR wanting to discontinue a very good platform in order to sell a new one. It makes it harder to sell something new when you have a product that is viable and very good, that meets the needs of most people, and is less expensive.

It is also quite unusual to see volunteer open source developers be driven by the needs of a commercial company and work in partnership with them. When that company is burning thru venture capital at a rate unprecedented by most startups, they can provide a lot of “perks” for an open source project like this - while it lasts. Something that most other less well-funded companies are not able to do. So it is obvious that ArduPilot would not be where it is today without the past support of 3D Robotics.

I will take a look at what can be done with the APM hardware platform as time permits, and I am in my busy part of the season here at present. I like that platform because it is more DIY and I am familiar with the development environment for it.

I realize 99% who participated in the thread consider it “old news” and obsolete. But there are lots of things that are old news and obsolete still in common use. Like the Piper PA-18 Super Cub in bush flying that has been around for over 60 years. It has stood the test of time and has never been replaced by modern technology. Even though Piper quit building it in 1991 after a 42 year production run, Cub Crafters in Washington continues building it today, along with at least 10 other “kit” manufacturers. Like APM, it doesn’t have all the bells and whistles of the newer, more powerful stuff. But it remains the Gold Standard where utmost reliability and ruggedness are paramount.

I’m not sure if you actually read my post. The ArduPilot project did not do what 3DR wanted. We kept supporting the APM1 and APM2 for years after 3DR stopped selling it. The first release for fixed wing which didn’t support the APM2 was in January 2016. I stopped supporting the APM2 in new releases purely for technical reasons.

you will find that trying to continue development of ArduPilot for APM2 will be difficult. You are of course welcome to do it, but you will find that you are extremely low on flash and ram. We were down to the last 100 bytes or so of flash, out of 256k. We were down to the last few bytes of ram. We’d already been over the code many many times finding ways to cram as much in as we could.

Regardless of whether you do it, please don’t keep on with the stuff about us selling out or not caring about the community. I spent a couple of years of my life keeping the APM1 and APM2 going for the community, poring over object dumps to try to find bytes I could save, tweaking code to fit just one more feature in. That is what you are flying now. I did it because I wanted to support the community for as long as it was technically feasible to do so.

2 Likes

I, for one, certainly appreciate your efforts, tridge. The APM remains an excellent platform. It is so good that it continues to outsell Pixhawk and will long outlast it in the marketplace.

I just figured, based on the fact that it continues to be more widely used than Pixhawk for instance, that seeing “WARNING: The APM2.x is end of life for use with ArduPilot” is rather dramatic.
http://ardupilot.org/copter/docs/common-apm25-and-26-overview.html#common-apm25-and-26-overview

Wouldn’t it be more appropriate to say something like, “Due to APM2.x still being a very popular option to run ArduPilot, these pages are archived for APM2.x users. Firmware for it can be downloaded from ” and yadda yadda?

And then maybe include a summary of the features that the newer firmware supports that the APM2.x doesn’t?

I realize my viewpoint and opinion is not shared by anyone here. That is obvious. But I believe it to be valid based on the large number of people that continue to buy those APM boards. I don’t know if the 2.7 and 2.8 version of the boards is not considered “official” by the devs because 3DR didn’t build 'em, or what. I’ve read a couple posts on the forum where somebody bought a 2.7 or 2.8 and had a question about it. One of the folks that participated in this thread replied in one of those posts and told them there is no such thing as a v2.7 or v2.8 board and refused to answer their question about the compass, which was really simple. Kind of putting out the message that if 3DR didn’t build it, then it’s not “real” and just go away. And that the “cloners” are “stealing” from the community.

So I hope you can also appreciate some of the questions that I have, as to what has driven this project in the past, and what drives it today.

That’s all. This thread will be closed. But I am interested in seeing what I can do for and with the 2560 boards that are still being sold. And which are higher quality hardware than what came from 3DR in the last of the 2.6’s. The Chinese are turning them out in the cell phone capital of the planet in Shenzhen by the boat load and they are sold by just about every R/C vendor that has an online presence. End of life? Not even close.

I have to disagree with you on that. Once the price of the pixhawks come down a bit more so they are in line with the APM you will see the APM die off.

Consider that the APM 3.1 with the neo-m6 GPS is $79 and the pixhawk lite with the neo-m8n is $107. For $30 something odd more you can pickup a much better flight controller.

The pixhawk is a better flight controller. The only thing the APM has going for it is that its cheap.

4 Likes

This topic was automatically closed after 24 hours. New replies are no longer allowed.