RealDash (I’ve only tested the Android version) provides the “Acceleration ABS/X/Y/Z” channels which seems to be the acceleration vector without gravity. The issue is, the device does not actually know where gravity is pointing at. The gravity vector removal is only estimated from IMU sensor fusion and completely unreliable on a platform that can pull steady G-force (such as a car). So the displayed value is misleading.
Most G-force apps allow you to park the vehicle on flat ground and press a calibration button to measure the gravity vector. Then the raw acceleration vector is always compared against that saved gravity vector. Can we have a similar system in RealDash as well?
Channels/features that might be useful:
- Length of full acceleration vector (raw data minus the saved gravity vector)
- Horizontal acceleration (component of raw acceleration vector perpendicular to the gravity vector)
- Vertical acceleration (acceleration component along the gravity vector)
- Lat/long acceleration (use gravity vector and device forward direction to form a new orthogonal basis, then find the lat/long components)
- Yaw correction (rotate the forward vector to compensate for yaw angle of device mount)
Note that, to suppress the noise in the IMU data, the smoothing needs to be done on the raw input channels (device x/y/z), the vector math comes later. So we need a special smoothing feature that is decoupled from existing per-gauge output smoothing. The saved gravity vector should be an average of many samples.
Technically everything above can be achieved using the existing dummy value and trigger system. I’ve made a custom dash that displays a smoothed version of full acceleration and it does work (3 dummy values for smoothed x/y/z, 3 dash data values for saving gravity vector, 1 extra action for calculating distance between two vectors, 1 trigger for looping). But handling the vector math is a way easier with build-in code.