Your two's complement numbers are sign-extended "Normal" ints. So you only need to care for the sign extension when reading from the IMU. AFAIK the IMU result are already sign extended, but this may depend on the used chip. I remember that my chip was able to collect and buffer some (32?) measures which I could read-off as a burst and add them up.
Regarding the filters
There is an AHRS implementation that seems to be better and easier to install than Kalman filters. I implemented that in a PSoC4 already and it works quite fast. It is using quaternion math and so does not need the rather time-consuming math functions except when converting quaternions to Euler.
Thanks! Looks good, seems like printf is not the best /:)
Any deas on integration? Best practice or hints?
Tell us a bit more (or even a byte more).
What does your sensor(s) deliver?
Accelleration? magnetic? Gyro? How many axes each?
Link to datasheet of your sensor(s)
What should your final device be capable of? Mowing the gras? Moving the gras with a heli upside down? Anything in between?
Yes, you ae right ... I was a byte too brief :)
I am using I2C sensors ... pololu IMU V3 but the code should work with nay I2C module( it seems most are capable of 400kHz and return 2s complement data)
I have Accel, Magneto, Gyro - all three axes but don't need all the axes at the moment. I will start with a single one and take it from there.
The final application is of a on-ground robot unit. I will a 3 DOF pose estimator in the end, so yaw, pitch and roll. You mentioned the AHRS implementation on the PSoC 4 - that has a floating point math unit.
I wonder how well integration would work on normal fixed point MCUs and how to best do it. Mostly interested on the loop time parameter - how to best manage the loop timer for integration and also keep my unit alive and doing the current operations. ( I've seen delay(XX) being used but I don't want to hang the MCU waiting for nothing just to ensure the loop time)
Thanks for the help!