ArduPilot
Gyro 1 rate 1000Hz < loop ratex1.8 1440Hz
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
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
Do you remember the justification for the Methodic Configurator recommending 800Hz? AFAIK it's still marked as experimental.
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.
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
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.
@PRSH8YA I loaded up your parameters on my Durandal, still cannot reproduce this error - either with 4.6 or with master
@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.
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
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.
Here is a screen shot of the methodic config software where they say increase the loop to 800hz
After Randys link to the wiki above, which simply recommend putting the loop rate back to 400hz in the event of this error, I think perhaps the MC should not be recommending the 400-->800 change without both linking to Randys wiki page and warning that not all configurations of hardware can do 800hz. @amilcarlucas ?
@davidbuzz Yes, that is a good point. I'll add that.
@PRSH8YA As you can see in the screenshot above, it recommends that for vehicles where "The propellers rotate at speeds higher than 400Hz and they have a powerful STM32 H7 family processor". Are your vehicle props that fast? If not, then the recommendation does not apply and you should either:
- use the default value and delete the change reason, or
- even better, read the documentation for that parameter by moving your mouse over the parameter name, set the parameter value and document why you choose that value in the change reason field.
The "change reason field" is the most important field in the entire application, and it's the reason I created the tool in the first place. It's completely missing from all other UAS tools.
