Higherstateofawkwardness Linear Acceleration example#2
Conversation
Updated the example code to use the SENSOR_LINEAR_ACCELERATION output (Quat6 and acceleration), streamed at around 40 Hz. Code rotates the accelerometer data using the Quat6. During initialisation, the gravity vector is calculated. The accelerometer data is then further rotated so that values for Z acceleration are always pointing down the Z axis etc. i.e. the sensor retains the spacial orientation.
…ardness-patch-1 Create Example11_DMP_SENSOR_LINEAR
This uses the onboard DMP rotation sensor to adjust the XYZ readings from the accelerometer into a constant orientation in the real world. Gravity is always down. Due to drift in the Quat6 sensor, the gravity vector is periodically adjusted when the sensor is stationary. If we can get the Quat 9 reading to be more stable, then this step might be omitted.
Hi Jon, I am wondering if you have done more work on this since your last posting ? I am working on a similar problem, trying to get position from IMU data for a short term before the error will integrate to some crazy position, and found your code to be useful. Thank you! Thx |
2 participants
This example orientates the sensor to a constant real-world orientation, such that the acceleration vectors X, Y, and Z "always" represent acceleration in a given north-south, east-west and up-down axis.
Due to sensor drift, the gravity vector needs occasional updating, done when the sensor is relatively stationary (total acceleration below 1.08g). The initialisation fuction and this updating routine may need some tweaking if we want better accuracy, but works as an example.
I've pulled the IMU data collecting out into a separate routine that returns a value (1,-1,0) based on whether there was successful reads of data, no data, or no more data. This makes it easy to call multiple times within separate code with or without a delay (which I've done with limited success in OpenLog Artemis).
I can also get the Quat9/acceleration combo to work, but there are some weird issues with this; the Quat9 seems to take a bit of time to catch up with the real-world frame. This might be due to the refresh rate of the compass sensor, or might be an artifact of the sensor fusion.
I've tested it using the Openlog Artemis and think I've removed the specific code so that this will be device independent. Also, I've created two functions within the example (findGravity and readIMUDMP) but haven't updated "keywords.txt" as I presume this is something that would be more for the main code rather than example files.
Cheers,
Jon