MultiWii / NAZE / SP Racing F3 Warning about APM2.x performance on Octocopters

[R_Lefebvre]

Just throwing this out there as a courtesy to the folks on this forum who might not otherwise see it.

I started flying an octocopter with APM2.5 a few weeks ago, and discovered that it has a fairly significant performance issue. We have long been concerned about the processor loading on the 8-bit AVR, and as seems to be all too common, I'm the canary in the coal mine. I guess nobody else has been flying octocopters on AC 3.0 up until now? I was flying helicopters all summer and they do not exhibit the problem. I finally started flying my Octocopter on 3.0 and realized the problem.

Basically, quads and helis fly great on 3.0. And I guess Hexas are OK. But Octo's really start to bog down the processor in Loiter mode. Stab mode is fine. Alt_Hold is OK. But Loiter and Auto start to exhibit performance deficiencies that result in unacceptable behaviour. Basically just sloppy control from Alt Hold and Loiter, though stabilization is still good. However, if you use Simple mode, it really goes to hell. The extra couple trig calculations for Simple mode really kill it. And, if you have camera mount code running, the situation is critical and could result in a crash.

It's not a software bug, or a hardware design problem. It's just, the extra calculations, from those extra two motors, and simple mode, push it over the edge to where the process breaks down. In testing, I had repeatable crashes due to the issue.

So, my recommendation is, don't do it. Don't use an APM for Octocopters unless you only want to use Stabilize and Alt Hold mode. Avoid Loiter in combination with Simple mode. Waypoint flying could be bad too.

 

[Bartman]

Just throwing this out there as a courtesy to the folks on this forum who might not otherwise see it.

I started flying an octocopter with APM2.5 a few weeks ago, and discovered that it has a fairly significant performance issue. We have long been concerned about the processor loading on the 8-bit AVR, and as seems to be all too common, I'm the canary in the coal mine. I guess nobody else has been flying octocopters on AC 3.0 up until now? I was flying helicopters all summer and they do not exhibit the problem. I finally started flying my Octocopter on 3.0 and realized the problem.

Basically, quads and helis fly great on 3.0. And I guess Hexas are OK. But Octo's really start to bog down the processor in Loiter mode. Stab mode is fine. Alt_Hold is OK. But Loiter and Auto start to exhibit performance deficiencies that result in unacceptable behaviour. Basically just sloppy control from Alt Hold and Loiter, though stabilization is still good. However, if you use Simple mode, it really goes to hell. The extra couple trig calculations for Simple mode really kill it. And, if you have camera mount code running, the situation is critical and could result in a crash.

It's not a software bug, or a hardware design problem. It's just, the extra calculations, from those extra two motors, and simple mode, push it over the edge to where the process breaks down. In testing, I had repeatable crashes due to the issue.

So, my recommendation is, don't do it. Don't use an APM for Octocopters unless you only want to use Stabilize and Alt Hold mode. Avoid Loiter in combination with Simple mode. Waypoint flying could be bad too.

Honesty is certainly appreciated! I almost specifiedan APM 2.5 for a customer Okto build so I suppose I should be happy I didn't.

What's the solution? Is the newer hardware (forgot what it's called at the moment, PX4 maybe??) going to be better with this?

 

[R_Lefebvre]

Yes, absolutely, the PX4 and/or Pixhawk hardware will solve the problem. It has like 100 times the processing power of the APM. I actually flew my octo last night on Pixhawk, and it was sweet. Finally flying as well as my Helis were! And then on the second flight, I hit a sensor driver bug, it basically did a FOD and is destroyed. :dejection:

A year ago, I vowed never to put "beta" stuff on my high-value machines. But I was given a Pixhawk as a developer sample, and jumped the gun because of these problems with the APM performance. I have just learned that the Pixhawk development is not as far along as I thought it was. The problem has actually already been fixed. But too late for me.

I'm very upset at what's happened.

 

[R_Lefebvre]

And just to make the situation clear, Arducopter does work on Octos. It just does not meet my very high performance standards. This post is only intended to be a warning that you *can* overload it with too many features and you have to be careful. This video was shot mostly in Alt Hold:

And this video was shot in Loiter:

I was using the Mount code, but not using the Simple Mode (I almost never do).

 

[Bartman]

And just to make the situation clear, Arducopter does work on Octos. It just does not meet my very high performance standards. This post is only intended to be a warning that you *can* overload it with too many features and you have to be careful. This video was shot mostly in Alt Hold:


.....videos removed.....

I was using the Mount code, but not using the Simple Mode (I almost never do).

did you catch hell last night for posting what you did?

 

[R_Lefebvre]

did you catch hell last night for posting what you did?

No, not at all. Why would you think that?

I've posted the same info on 3 boards, and in some of the other places the discussion starts to diverge. Some people questioning if this is the cause of a GPS glitch on a tricopter and things like that, which don't make any sense. This is a cut and paste of a response on another board. I strive to very fair to all users (thus the warning), but also very clear in what I'm communicating. The system does work on Octo in most cases. It's just that the potential exists to overload it, and thus the warning.

What happened with the Pixhawk should not be misconstrued as a knock against the system. This is what happens in the development process, you normally just don't see it, private companies aren't going to announce every time an engineer crashes during development. I made a mistake in putting it on my high-value machine, because I did not understand it was still quite "alpha". The boards are still not even for sale. What happened was very much like DJI FOD, but the difference is it only hit one person (me), a developer, and since we have data logging, the problem was found and solved after only a single crash. It was only a 1-in-1000 chance that it occured, but it happened on my second flight... I have really bad luck like that.

 

[R_Lefebvre]

Just a quick update on this issue. Randy and Tridge have spent all week working on this issue and have made very substantial progress. I hope to test it later today. So far it appears that they've managed to improve the efficiency of the code running on APM2.x enough that it's going to run perfectly again.

 

[TriGuy]

Just throwing this out there as a courtesy to the folks on this forum who might not otherwise see it.

I started flying an octocopter with APM2.5 a few weeks ago, and discovered that it has a fairly significant performance issue. We have long been concerned about the processor loading on the 8-bit AVR, and as seems to be all too common, I'm the canary in the coal mine. I guess nobody else has been flying octocopters on AC 3.0 up until now? I was flying helicopters all summer and they do not exhibit the problem. I finally started flying my Octocopter on 3.0 and realized the problem.

Basically, quads and helis fly great on 3.0. And I guess Hexas are OK. But Octo's really start to bog down the processor in Loiter mode. Stab mode is fine. Alt_Hold is OK. But Loiter and Auto start to exhibit performance deficiencies that result in unacceptable behaviour. Basically just sloppy control from Alt Hold and Loiter, though stabilization is still good. However, if you use Simple mode, it really goes to hell. The extra couple trig calculations for Simple mode really kill it. And, if you have camera mount code running, the situation is critical and could result in a crash.

It's not a software bug, or a hardware design problem. It's just, the extra calculations, from those extra two motors, and simple mode, push it over the edge to where the process breaks down. In testing, I had repeatable crashes due to the issue.

So, my recommendation is, don't do it. Don't use an APM for Octocopters unless you only want to use Stabilize and Alt Hold mode. Avoid Loiter in combination with Simple mode. Waypoint flying could be bad too.

Yep, the same happens with tricopters on 2.6 even if you power servos of external becs. Switching to Pixhawk.

 

[R_Lefebvre]

That's not even remotely the same issue.

 

[TriGuy]

Okay, my bad. Hey, I'm a noobie. I know nothing. I did think it was interesting that your description was exactly what I encountered, especially the part about loiter and auto modes. I used a separate bec (between the lipo & power mod), but still had frequent brownouts. That rules out a juice issue and apparently leaves a hardware or firmware issue. Apparently, Wii also has this problem with tricopters, but like the 2.6, not with quads. Everything I have read (from you guys) seems to indicate that the limited computing capacity and RAM of the 2.6 bogs it down on some platforms. That's why I ordered a Pixhawk. I have a lot to learn. I will keep reading your posts.

 

[R_Lefebvre]

But it sounds like you're having brownouts, not CPU bogging?

 

[TriGuy]

Looked like it too. Out of my last four flights, #1 & #4 were flawless. On #2 and #3, the tricopter gently settled to the ground from about 20 feet, even with the throttle all the way up. Had the tricopter been higher, those would likely have been crashes. This happened within the first 3 minutes of each flight. Both lipos still had 15.3v+ in them. Changed batteries between all flights. Go figure.

Previously, I had several abrupt, mid-air cutouts. Reboots?