ev-mp
commented
5 years ago @eospi, T265 is an inside-out tracking device that relies solely on self-obtained inertial and visual feeds and cannot receive external coordinates directly.
Note that the device does track the level (horizon plane) by resolving the G-force vector, so even though the position and heading angle are arbitrary set as [0,0,0] and [0] on device start up, the real pitch and roll angles are always correct.
Actual precision is bounded by IMU calibration tolerance
What you ask is ,imho, an open question, so I will try to outline the method for translating T265 pose into a "north-aligned" real world orientation which requires to establish (at least) two reference frames and perform matrix multiplications:
- T265 pose in Compass's CS (where compass is located at origin [0,0,0,0,0,0])
- Compass sensor pose with regards to "real world" (north)-aligned CS.
and then solve them iteratively to obtain north-aligned orientation:
- Calculate T265 pos in the Compass's CS
- Transform the resulted pose into "real-world" north-aligned CS
Note that the [xyz] component of the resulted pose is not necessary and can be omitted in case you're interesting only in "rectifying" the North reference.
The flow with the two major cases :
- T265 and the compass sensors are linked/ mounted to a common frame -
a) Calculate the mechanical 6DOF offset (translation and rotation) between the compass and T265 origins and use it to generate the [4x4] transformation matrix from T265 CS to compass CS.
repeat in loop: b) Capture T265 Pose and compass azimuth. generate [4x4] transformation matrices from both. c) Multiply the T265 Pose by (a) to calculate it in the Compass CS. d) Multiply result of (c) by the compass's transformation. e) The resulted rotation component [3x3] in the [4x4] matrix will provide T265 rotation aligned to north.
2) T265 and the compass are linked in kinematic chain, i.e. the compass and T265 sensors can move/rotate relatively to each other. This scenario is not that different from the previous one, and would require some modest modifications to employ a rigid-body transformation method similar to Denavit-Hartenberg convention so that the transformation matrix established in 1.a above will be update dynamically. In reality both scenarios are technically similar with (1) being the degenerated version of (2).
There are multiple robotic and non-robotic libraries and SDK that facilitate these type of kinematic transformations, but this is out of scope of this question.
Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):
All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)
Issue Description
Does the SDK have support to align the T265 with the compass such that 0 degrees is north? If not, what is the best way to implement this? Thanks!