CPU Warning, Copter 4.5.1

Hi there. I updated my Hexacoper to FW 4.5.1, and since then i have a “CPU” warning in the MIssion Planner “Cockpit” WIndow, below, near the GPS Status . The CPU warning appears around every seconds, and in the LOG-File i can see a lot of 100% Peaks of the PM Load Parameter. I have no idea why this happens, i only changed the AHRS_EKF_Type from EKF2 to EKF3. Any Idea anyone?
Thanks in advance

To Compare, old FW was 4.0.5, and PM_Load for similar flight looked like this

Data Log (Bin): 2024-04-10 10-33-32.bin

Telemetry Log: 2024-04-10 10-18-32.tlog

Do you have both EKF2 and EKF3 running at the same time?
You should not do that, disable EKF2

Where did you see this? I can not find any EK2 Settings in FW4.5.1

It has been removed in V4.5.

I could not see a specific reason for such high CPU load.
There are some things I would point out though, and some I would change.

It’s a Cube Black, so there is NOT a lot of processing power to play with and I think a lot of improvements to attitude control (and related code) over the last couple of years has probably increased CPU load noticeably. I’ve got similar, or even better, flight controllers I’m putting aside or delegating to mundane jobs so I can continue to use the modern-day improvements and features (like scripting). I dont want this to sound like “ERROR - not enough money spent” when an old flight controller could still work fine.
It might be a case of working out which Arducopter version still allows reliable use with the most fixes and improvements. I’m guessing around version 4.2.3 or slightly earlier.

The tuning and attitude control needs some attention, it could be quite a bit better, even without enabling more features such as the Harmonic Notch Filter.

Some GPS settings are unrealistic and only one of the GPS units can keep up with the update rate you set. These would be better set back to 200ms


and try these at 5 or 65 , whichever gives you the lowest reliable HDOP


This will help to stabilise the update rate too.

You appear to relying heavily on GPS altitude, although your barometers appear quite well behaved and closely match GPS altitude. I would set:

BARO_FLTR_RNG,10  //to reduce the baro noise, but EKF does a good job anyway
EK3_ALT_M_NSE     //reduce to closer to default
EK3_SRCx_POSZ     //set at least 1 of these 3 parameters to Baro instead of GPS

Keep in mind the barometer can give variations in altitude with changing conditions, but GPS can give sudden step-changes for no apparent reason (although is generally reliable)

To help reduce CPU load I would start by disabling SRTL and setting these associated failsafe actions:


and try disabling these too:


Do you use the SBUS Out ? Maybe for a gimbal - If not set this

SR1 parameters have some relatively high values, you might want to scale them back to be more like SR0, after all you’ve only got a 56k telemetry link and sending all that data 20 time per second will be flooding it and needlessly using CPU cycles. In fact you usually dont even need to set these as the groundstation will be requesting the data, they are more important if you’ve got some older device that passively waits for the data and doesnt request anything.

Unrelated to CPU usage, but quite important, set these battery voltage parameters


Li Ion


Those MOT_BAT parameters will really aid tuning and attitude control.
Lastly I would reassess the attitude control - that might help with flight time and more.

I wonder if the new Filter Library is juicing these grey bearded F4’s even if they are not configured? FILTERx_TYPE parameter. Or just more stuff in the loop. I think this is the 2nd post about Load maxing out with a Cube Black.

Anyway, many reasons to bin the F4’s and move on.

Before downgrading the firmware, I’ve done a Cube Black build here with a lot of the optional features disabled. Usually we do this to cut down on memory usage, but it might (hopefully) lower the CPU usage.
Try it and see…
Download the arducopter.apj and load it via the custom firmware button in MissionPlanner.

Otherwise I suggest trying my pervious recommendations, then as a last resort going back to about 4.2.3

Please let us know the results.

Thanks for the report and for providing a log!

I see you’ve already disabled the CubeBlack’s 3rd IMU (by setting EK3_IMU_MASK = 3) so that’s good. That’s the first thing I’d recommend to CubeBlack users suffering from performance issues.

You could take it one step further than disable the backup IMU. Another alternative is to just reduce the main loop rate by setting SCHED_LOOP_RATE = 300 (instead of 400hz). You’ll probably find it flies just as well as at 400hz.

By the way, we’ve got this wiki page that lists nearly all pre-arm checks failure messages and has a little bit of advice (of course not as extensive as what others here have suggested).

These are only used with PID notches

1 Like

Wow, thanks for all the help from all of you!

I’ll read it carefully and let you know about my improvements!

1 Like