search

BjarneBitscrambler / OrientationSensorFusion-ESP

Files for performing orientation sensor fusion using NXP version 7 algorithm, ported to Espressif platforms.
BSD 3-Clause "New" or "Revised" License
23 stars 12 forks source link

Allow fusion to continue despite non-communicating sensor #18

Closed BjarneBitscrambler closed 3 years ago

BjarneBitscrambler commented 3 years ago

For compatibility with Signal-K/SensESP project, it's best to allow program execution to continue, despite lack of comms with a sensor. SensESP may have multiple sensors attached, and failure of one should not bring down the whole system.

Will need a method for passing back the status of the sensors, and for retrying comms. Something like GetSensorStatus()...

BjarneBitscrambler commented 3 years ago

In readSensors() the status condition SOFT_FAULT is set if an error occurs during a sensor read. The same status is also set if a sensor FIFO is overrun (indicating that it is not being read often enough).

In all statuses other than NORMAL condition, a call to IsDataValid() will return false, which indicates that the orientation data are not trustworthy. This could also happen, in addition to a sensor failure, during the short period that the fusion system is initializing.

Whenever the status of a sensor is uninitialized, each time a read is attempted, an initialization is performed first. If the initialization succeeds, then the system status is set back to NORMAL on subsequent cycles.

This seems to work fine when using the library from SensESP and performing Attitude outputs. Disconnecting the I2C SDA line causes the Signal K display to switch to -.----. It returns to the expected numeric values when the I2C connection is restored.