Any Chance of a Teensy ++ 3.1?

[PaulStoffregen]

I wonder how fast the K66 with FPU at 180 MHz will run these algorithms?

 

[onehorse]

When I get my beta test board I will let you know!

Thanks for including me on the list!

In fact, I will perform some simple speed and current usage tests and post the results; I am kinda curious myself.

 

[tni]

STM has a factor of around 12 for HW FPU vs. SW FPU for the Cortex M4 in their test:
http://www.st.com/resource/en/application_note/dm00047230.pdf

With the processing power of K66, you could also run an Extended Kalman Filter instead of Madgwick (works better):
Experimental Comparison of Sensor Fusion Algorithms for Attitude Estimation

 

[onehorse]

Looks to me like Madgwick does just about as good as EKF; I suspect the error is dominated by the sensor data quality in any case. I would have chosen the MPU9250, where 2 degree heading error can be achieved with proper calibration.

I rely on the EM7180 for most applications, Madgwick is a computationally-convenient yardstick to compare MCU performance.

 

[Frank B]

How does the EM7180 work ? Which algorithm does it use ?

 

[onehorse]

It is a 10 MHz ARC processor with FPU optimized for sensor fusion that manages an IMU as master. It estimated orientation by fusing the sensor data using a combination of steepest descent and Kalman algorithms, but the details are proprietary (at least not published). The EM7180 updates the quaternion at the rate of the gyro, up to 400 Hz guaranteed, and the Kalman filter runs at 30 Hz. The EM7180 detects and corrects magnetic anomalies, dynamically calibrates mag and gyro, dynamically adjusts the fusion parameters for the conditions experienced and allows warm start of all of these so the device starts well-calibrated on subsequent power up. You can read more about it in the EM7180 User's Guide.

 

[manitou]

I wonder how fast the K66 with FPU at 180 MHz will run these algorithms?

I ran onehorse's Teensy propshield sketch on both dragonfly and K66 see K66 beta test
The "rate" improves with hardware floating point (Madgwick is float intensive), but the loop time is dominated by the I2C queries/read of the sensors. The dragonfly I2C supports DMA, and Kris has a similar dragonfly sketch for the IMU9250 that utilizes interrupts for sensor-data-ready and I2C DMA, and thus eliminates much of the I2C overhead.

EDIT:
I have run some teensy and dragonfly sketches with the MPU9250 with and without the data-ready interrupt. Polling with I2C takes about 120us with 400khz I2c readByte. That delay is eliminated with the data-ready interrupt and the rate is mostly determined by the speed of the float-intensive Madgwick filter (ref madgwick performance )

Config        sensor loop rate
dragonfly@80MHz      6328 Hz
 with interrupt     45409
 and I2C DMA        49458
K66@180MHz T3.6      7028
 with interrupt    152959
 @120MHz           103303
K64@120MHz T3.5      6639
 with interrupt     78959
T3.2@120MHz          2714
 with interrupt      4397 Hz

 

[defragster]

@manitou: That is a tremendous improvement when interrupts are used over polling! I've been sitting on these - will have to look at that when I get back to it.

 

[manitou]

@manitou: That is a tremendous improvement when interrupts are used over polling! I've been sitting on these - will have to look at that when I get back to it.

The I2C poll @400khz takes about 120us, the data transfer another 300us or so.

It's too bad the propshield doesn't break out all the interrupts. Actually, it's nice that MPU9250 has one data-ready interrupt. The optimized dragonfly sketch uses the data-ready interrupt to chain a sequence of I2C-DMA callbacks to fetch the sensor data. if you look at the logic analyzer, the I2C transfers are happening concurrent with the tight Madgwick loop, with new data integrated when newData is set true. I don't know if i2c_t3 has a similar construct.

dragonfly sketches at https://github.com/kriswiner/Dragonfly

at tindie.com onehorse has several tiny mpu9250 teensy shields. i've just been using sparkfun mpu9250 breakout.

 

[onehorse]

When possible it is always faster and more efficient to use the interrupt. This works on almost all MCUs, and I have noticed significant speeds up on the ESP8285 as well even without DMA.

Sparkfun's MPU9250 breakout is inexpensive but they made several mistakes in the hardware design including routing digital and power lines under the MPU9250 package; this will degrade the magnetometer accuracy. Of course, I have let them know all areas of improvement possible but I guess they have to work through the first production inventory before they can fix them.