Hi,
I'm running the project on an Android device and encountering severe positional drift immediately after initialization, even when the device is completely static. I would appreciate some advice regarding the expected IMU coordinate system alignment.
The Issue:
After the VINS system initializes, the position starts drifting rapidly (velocity climbing to >100m/s within seconds). The device is stationary on a desk during this time.
Log Evidence:
I added some telemetry logs to inspect the raw IMU data being fed. I noticed that my device's accelerometer reports gravity primarily on the X-axis when static:
[VIO_TELEM] ... v=126.34mps ... a=(9.82, -0.05, 0.08) |a|=9.83 aAxis=X ...
It seems the VINS estimator is interpreting this constant 9.8g on the X-axis as linear acceleration (forward/lateral movement) rather than gravity, causing the double-integration position error.
My Questions:
Expected IMU Frame: What coordinate system does the native FeedImu function expect?
Is it Camera Frame (Right-Down-Forward)?
Or IMU Frame (Forward-Left-Up)?
Specifically, which axis should Gravity be aligned with when the device is held in standard landscape mode? (e.g., should Gravity be on Y? or Z?)
Gravity Initialization: Does the underlying VINS initialization routine automatically detect the gravity vector direction, or does it assume a specific initial orientation (e.g., Gravity must be roughly along the Y-axis)?
What I've Tried:
I attempted to remap the Android Sensor data (Search: x,y,z) to a typical Camera Frame (Right, Down, Forward) by swizzling the vector before feeding it to FeedImu.
For example, mapping Android-Raw-X (Gravity) to Output-Y:
Vector3(-rawY, -rawX, -rawZ)
However, I am still fine-tuning this. Knowing the exact target convention would save a lot of debugging time.
Thanks for your help!
Hi,
I'm running the project on an Android device and encountering severe positional drift immediately after initialization, even when the device is completely static. I would appreciate some advice regarding the expected IMU coordinate system alignment.
The Issue:
After the VINS system initializes, the position starts drifting rapidly (velocity climbing to >100m/s within seconds). The device is stationary on a desk during this time.
Log Evidence:
I added some telemetry logs to inspect the raw IMU data being fed. I noticed that my device's accelerometer reports gravity primarily on the X-axis when static:
[VIO_TELEM] ... v=126.34mps ... a=(9.82, -0.05, 0.08) |a|=9.83 aAxis=X ...
It seems the VINS estimator is interpreting this constant 9.8g on the X-axis as linear acceleration (forward/lateral movement) rather than gravity, causing the double-integration position error.
My Questions:
Expected IMU Frame: What coordinate system does the native FeedImu function expect?
Is it Camera Frame (Right-Down-Forward)?
Or IMU Frame (Forward-Left-Up)?
Specifically, which axis should Gravity be aligned with when the device is held in standard landscape mode? (e.g., should Gravity be on Y? or Z?)
Gravity Initialization: Does the underlying VINS initialization routine automatically detect the gravity vector direction, or does it assume a specific initial orientation (e.g., Gravity must be roughly along the Y-axis)?
What I've Tried:
I attempted to remap the Android Sensor data (Search: x,y,z) to a typical Camera Frame (Right, Down, Forward) by swizzling the vector before feeding it to FeedImu.
For example, mapping Android-Raw-X (Gravity) to Output-Y:
Vector3(-rawY, -rawX, -rawZ)
However, I am still fine-tuning this. Knowing the exact target convention would save a lot of debugging time.
Thanks for your help!