Gyro 1 rate 1000Hz < loop ratex1.8 1440Hz

[PRSH8YA]

After upgrading 2 of my flight controllers I get this error " Gyro 1 rate 1000Hz < loop ratex1.8 1440Hz"
The only way I can fix it is to drop my loop rate to 400hz from the 800hz that Methodic Config software suggested that I set it to, or enable fast sampling on the second IMU

Gyro 1 rate 1000Hz < loop ratex1.8 1440Hz
At this link I was dealing with a cube orange plus, now my durandal is doing it also.
https://discuss.ardupilot.org/t/cube-orange-plus-over-loaded-processor/134003/41

Bug report

Issue details

Please describe the problem

Version
What version was the issue encountered with

Platform
[ ] All
[ ] AntennaTracker
[ ] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Airframe type
What type of airframe (flying wing, glider, hex, Y6, octa etc)

Hardware type
What autopilot hardware was used? (Pixhawk, Cube, Pixracer, Navio2, etc)

Logs
Please provide a link to any relevant logs that show the issue

[rmackay9]

I've created a wiki issue to add this particular error to our list of pre-arm errors

[andyp1per]

I can't reproduce this on my Durandal - can you post your parameters

[PRSH8YA]

If you are trying to reproduce, increase the loop to 800hz and unselect your IMU's INS_FAST_SAMPLE or atleast one of them.

https://drive.google.com/file/d/1QKJfXBsaWYH4h802Ga7WSOEdQvFNpniG/view?usp=sharing

[tpwrules]

Do you remember the justification for the Methodic Configurator recommending 800Hz? AFAIK it's still marked as experimental.

[PRSH8YA]

I can't remember right off. Both of the flight controllers that this happened to were setup with mc. Once I set the loop rate back to 400hz that error went away. To be clear I am not trying to say MC is to blame at all.

[rmackay9]

The wiki's pre-arm error wiki page has been updated to cover this now so hopefully the next person will get to the short-term fix sooner

[andyp1per]

Do you remember the justification for the Methodic Configurator recommending 800Hz? AFAIK it's still marked as experimental.

Many of the MC recommendations come from my manual tuning. For smaller craft a fast loop gives better control. 800 is about as high as you can go on H7 without issue.

[andyp1per]

@PRSH8YA I loaded up your parameters on my Durandal, still cannot reproduce this error - either with 4.6 or with master

[PRSH8YA]

@andyp1per did you update my parameters to increase the loop to 800hz and unselect 1 of your IMU's INS_FAST_SAMPLE?

In the param file I sent it wouldn't give me the error unless I did the above to it.

When I get home I will update my param file and send it to you with the error showing.

[PRSH8YA]

Here is the param file for my durandal FC, it currently has that error.

https://drive.google.com/file/d/1rIGzY1wXioEMGjUFTozXUYJrYdT8X4Oq/view?usp=drive_link

[MichelleRos]

Methodic Configurator recommending 800Hz

That definitely does not sound like a good idea. Especially if that's as part of the initial setup. A lot of flight controllers can't handle 800 Hz, and even though you do have an H7, you might want to use the extra CPU for other things - there are very few vehicles where this fast loop rate makes enough of a difference to be worth it (mostly small FPV quads).

I'd definitely recommend leaving it at the default 400 Hz and just getting it hovering stably first before experimenting with different loop rates. One of the reasons is issues like this which only turn up at higher loop rates. Even with an FPV quad, I'd recommend getting a stable hover at 400 Hz (and finishing the setup) before raising the loop rate. I have yet to come across a copter that won't at least hover stably at 400 Hz (and I fly a 50g whoop on ArduPilot as one of my vehicles).

As for the error, your third IMU without fast sample is now running at only 1000 Hz, which is less than 1.8 times the loop rate of 800: 1.8*800=1440. AP has a pre-arm check to make sure the IMU rate is at least 1.8 times your loop rate. That is the error you're seeing. So if you want to keep such a fast loop rate, you either need to turn fast sampling back on, or turn that 3rd IMU off completely - which may not be a good idea, because, at least in the Cube Orange, it is the only non-isolated IMU, and there are some failure modes that can affect only the isolated IMUs - that's why that third one is there.