We have been using EM Microelectronic's EM7180 motion co-processor for absolute orientation estimation with some success. The EM7180 embeds a 10 MHz ARC processor with single-precision floating point unit (FPU) optimized for fast fusion calculations using fusion algorithms developed by PNI Corporation. The EM7180 off-loads the management of the sensors and the computationally-intensive fusion calculations from the host MCU so that accurate absolute orientation estimation in the form of quaternions or Euler angles can be read from the EM7180 by the host via simple I2C register reads. This means even a poky 8 MHz Arduino Pro Mini can obtain <2-degree accurate heading data when using the EM7180 co-processor and a suitably accurate sensor suite like the MPU9250 or LSM6DSM+LIS2MDL.
This may seem trivial when low-cost, high-performance MCUs like the STM32L4, nRF52832, ESP32 and others abound. And when computationally-efficient, open-source fusion methods have been available for years making it easy for anyone to get quaternions (see here and here and here and here) with these host MCUs.
However, accurate sensor calibration and fusion methods are not trivial to implement, so the demonstrated performance (< 2 degree rms heading accuracy) of the EM7180 is quite attractive. Also, the idea of a co-processor (commonplace in SoC computers in the form of sensor hubs and GPUs, for example) is to off-load specialized sensor management and computationally-intensive data processing tasks from the host. This allows the host's full attention to be placed elsewhere, and/or allows a power-gulping host to sleep through sensor management tasks thereby conserving power. And for hosts with embedded connectivity like the nRF52 (BLE) and ESP32 (BLE and wifi), the radio stack usually commands top priority so off-loading computationally-intensive tasks when possible minimizes collisions.
In addition to sparing the host and obtaining superb heading accuracy, the advantages of using the EM7180 as motion co-processor include small size (1.6 mm x 1.6 mm WLCSP-16), auto gyro and magnetometer calibration, simple I2C serial output, and ultra-low-power usage. Quaternions can be updated at the rate of the gyro (up to 400 Hz guaranteed), and there is some flexibility in the form of generic user registers, fusion tuning parameters, and the ability to make use of RAM patches to allow some customization of the fusion algorithms (for example, we have added fusion of the accelerometer and barometer to provide a drift-corrected altitude estimation). There is a warm start capability that allows the EM7180 to start with the last session's calibration parameters upon subsequent power up.
There are some disadvantages to using the EM7180, of course. These include the fixed, "black-box" nature of PNI Corp.'s algorithms stored in ROM, the need to load the sensor-specific firmware into RAM on each power up, the very small amount of free RAM that limits customization, behaviors of the fusion algorithm (especially the dynamic magnetometer calibration) that cannot be adjusted or turned off. While the EM7180 is sensor agnostic, meaning it can use the input of almost any I2C accelerometer, gyro, and magnetometer to produce fused quaternions, the drivers for the sensors have to be created and compiled using a deprecated compiler. The ~24 kBytes of compiled firmware have to be stored on an EEPROM for loading into the EM7180 RAM on each power up, or loaded from the host. Lastly, the EM7180 is designed to manage I2C sensors so that devices with SPI or UART serial interfaces cannot be used directly and require a translator.
With the announcement of MAXIM Integrated's DARWIN family of MCUs, especially the MAX32660, we have an opportunity to design a motion co-processor that offers all of the advantages of the EM7180 with few, if any, of the disadvantages....Read more »
Since this unit has an onboard ARM processor, has there been any thought given to building FW modifications that can directly integrate with a wireless unit? I presently am using Teensy MCUs as an intermediary between IMU and wireless. Ideally I could, have two of the carrier boards: one mounted to the Teensy and the other mounted to the wireless unit. I could program the IMU on the Teensy and then remove it and attach it directly to the second carrier mounted to the wireless unit.