Now that the initialization of MPU9250 is shared between the
AP_InertialSensor and other drivers using it as a backend, we can reset
the MPU9250 in order to put it in a known state.
Now we have the initialization code split in 2 parts:
1) Making sure the MPU9250 chip is alive and working: this is now in a
static function that may be called by other drivers that use MPU9250 as
backend.
2) The configuration of gyro and accel. Once the first part is completed
successfully the AP_InertialSensor_MPU9250 finishes the configuration of
the sensors it uses.
The only change in behavior here is that before we would try 25 time (5x
inside _hardware_init time 5x inside _init_sensor() that calls the first
function) to "boot the chip" and now we are doing "only" 5.
Add static methods to do the SPI transactions and provide the wrapper
methods when we have an instance of the object. This is useful so these
methods can be called from other contexts when the AP_InertialSensor
hasn't been initialized yet.
Allowing to change the SPI device state allows us to save the
information whether the device was already initialized and avoid 2
separate drivers to initialize it.
Uses reimplemented AK8963 driver. There's also no need trying to detect this
compass twice. Actually, it might even be bad, because the current code can
allocate an AK8963 object twice.
If a badly conditioned covariance matrix causes negative innovation variances, then the filter will diverge. The previous approach of increasing process noise was not effective in some cases, so a hard reset of the covariance matrix has been adopted to guarantee recovery.
This fixes a numerical error observed using the replay on flight log which had significant periods of compass rejection.
The Compass library is initialized before the InertialSensor. AK8963 with
MPU9250 as backend already takes care of resetting MPU9250. The problem with
also resetting it in the MPU9250 initialization code is that if the reset
happens during an internal I2C transaction, the AK8963 may hang. So here we
remove the reset inside MPU9250. There still a possibility that the first
MPU9250 initialization is not successful and it resets the chip, but it's not
happening in tests.
new param: BRD_SERIAL_NUM
// @Description: User-defined serial number of this vehicle, it can be any arbitrary number you want and has no effect on the autopilot
// @Range: -32767 to 32768 (any 16bit signed number)
The value for LINUX_STORAGE_SIZE was defined inconsistently against the one
defined for Linux boards in HAL_STORAGE_SIZE. That led to some values not
being written to the storage when running the test binary built at
libraries/StorageManager/examples/StorageTest.
Andrew Tridgell
Randy Mackay
Staroselskii Georgii
mirkix
dgrat
kozinalexey
dzollo
Lucas De Marchi
Paul Riseborough
Peter Barker
tcr3dr
Tom Pittenger
Gustavo Jose de Sousa