Design Roadmap: Driver Architecture, IMU Signal Processing, multi-EKF

[dagar]

Under construction

Project Board: https://github.com/PX4/Firmware/projects/23

This is to discuss and design the path forward for a number of key architectural changes that will enable greater robustness, fault tolerance, and redundancy.

Problem
Failure to detect vibration induced inertial navigation failures early enough during system integration or operation has contributed to a number of vehicle loss incidents

The current practice of using the IMU’s internal DLPF is a major blocker for the following reasons:

• IMU internal sampling is then limited to 1kHz which makes the ADC step susceptible to aliasing on airframes with high RPM/geared motors and high blade count propellers
• The use of the IMU’s internal DLPF means that high frequency vibration clipping of the ADC cannot be detected externally until it has affected the INS
• Data cannot be logged at the ADC sampling frequency so it is not possible to use a data driven approach to resolving vibration induced navigation failures.

High Level Architecture
WIP - https://drive.google.com/file/d/13Mcztqcvcaa82bg5UD3o95UAd-6uKu50/view?usp=sharing

Specific problems and solutions

• IMU sampling at 1 kHz in ISRs
  Incremental work towards solutions
  • SPI DMA
    • WIP: STM32F7 DMA per SPI NuttX#25
  • split processing and publication for rate controller and INS publication
    • separate sensor_gyro and sensor_accel into messages for filtered and integrated data
      • [WIP] introduce new vehicle_imu message #9756
  • create work queue per bus for processing IMU data
    • PX4 general work queue #8814
    • Problem: limited memory available on typical stm32f4 systems
      • cdev and uORB subscriptions via file descriptors use quite a lot of memory
      • CDev begin extracting from drivers Device hierarchy #9825 (much more to come)
• PX4 limited to a single estimator
• enable estimators to subscribe directly to desired IMUs or other sensors
• where needed voting can happen in parallel rather than directly in the sensor pipeline
• drivers apply their own scale factors and offsets, but sensors module applies the temperature compensation
• insufficient memory on typical STM32F4 setups for multiple estimators (see above)

Side issues that we might want to eliminate or at least reconsider along the way

• sensor calibrations applied by sensors module on Nuttx, directly on other platforms

[philipoe]

@ASM3

[dagar]

Done!