ICM426XX - Disable AFSR

[nerdCopter]

• ICM426XX - Disable AFSR
• Betaflight: Disable ICM426XX AFSR feature to prevent stalls
• Ardupilot: AP_InertialSensor: fix for ICM42688 stuck gyro issue
  these undocumented bits in register 0x4d control the "adaptive full
  scale range" mode of the ICM42688. The feature is enabled by default
  but has a bug where it gives "stuck" gyro values for short periods
  (between 1ms and 2ms):, leading to a significant gyro bias at longer
  time scales, enough to in some cases cause a vehicle to crash if it is
  unable to switch to an alternative IMU
• Thanks to all participants here: Artefacts in ICM-42688-P gyro output betaflight/betaflight#12970
• Thanks to @DutchFPV for quick-turnaround testing
• Thanks to Betaflight devs communications

Co-authored-by: Andrew Tridgell [email protected]
Co-authored-by: Steve Evans [email protected]

[nerdCopter]

i'm unsure what to use: spiBusReadRegister or spiReadRegMsk. both seem to work. but BBL shows some different axis behavior. I don't have this FC mounted so i cannot flight-test :(

left=spiBusReadRegister ; right=spiReadRegMsk (debug, X,Y,Z seemingly re-arranged or maybe just scaled differently)

EmuFlight did not have spiReadRegMsk before ICM426xx, which seems to only "wait" before calling spiBusReadRegister.

EmuFlight/src/main/drivers/bus_spi.c

Lines 275 to 279 in c55b0d7

	// Wait for bus to become free, then read a byte of data where the register is ORed with 0x80
	uint8_t spiReadRegMsk(const busDevice_t *bus, uint8_t reg)
	{
	return spiBusReadRegister(bus, reg | 0x80);
	}

[Quick-Flash]

This looks like it should fix the issue, before we merge it we should see if we can replicate the issue on the bench and then show it not happening after this fix.

[Quick-Flash]

i'm unsure what to use: spiBusReadRegister or spiReadRegMsk. both seem to work. but BBL shows some different axis behavior. I don't have this FC mounted so i cannot flight-test :(

left=spiBusReadRegister ; right=spiReadRegMsk (debug, X,Y,Z seemingly re-arranged or maybe just scaled differently)

EmuFlight did not have spiReadRegMsk before ICM426xx, which seems to only "wait" before calling spiBusReadRegister.

Since you have an FC that works with this code, If your unsure what scaling or whatever it needs try using the gui to see what rotating the quad does. If you tilt the fc 90 degrees you should see the quad respond correctly to that and not take some extra time to correct, or see it overshoot. If thats the case then we know its working right.

[nerdCopter]

@Quick-Flash , 90 tilts seem to work fine, with the caveat that our Configurator can become out-of-sync with physical position if moved too rapidly. (tested with mpu6000 and bmi270, this is still true, but maybe worse with icm42688p, both this PR and master)

master vs fix (where fix uses spiReadRegMsk)
obvious ticks left, not on right

[Quick-Flash]

@nerdCopter can you test 90 degree pitch with dcm_kp and dcm_ki to zero? This will disable the accelerometer fusion. If 90 degree pitch without going to crazy works fine then I'll say it looks good to merge.

[nerdCopter]

still does it, but sensors tab looks good. maybe i'll wait for flight-test. or maybe just know/consider taht Configurator is obsolete on setup page render.

[nerdCopter]

findings:

• Flight-tested as good. (@DutchFPV tested multiple builds on JHEF7DUAL)
• Generally, logging at 8k will cause undesired effect. flight-control is less responsive to stick-input. (not a factor of this PR)
• ICM4266p Configurator 3D render becomes unsynchronized in both EmuFlight and Betaflight. All gyro's seem to do but icm426xx is a bit more drastic. Does not affect flight.
• Sensors tab seems to be fine.
• I had concerns about using spiReadRegMsk versus spiBusReadRegister because they both had a bitwise OR operator (reg | 0x80), but it turns out that reg | x80 is equal to reg | 0x80 | 0x80. Ultimately choosing to call the old function spiBusReadRegister.