Sachini
commented
12 months ago (1) pose/tango_ori represent the orientation of the tango device. pose/ekf_ori is the orientation of IMU device estimated with IMU and pose/tango_pos as measurements. This is only and estimation and not guaranteed to be better than synced/game_rv. Both are in w-x-y-z format.
(2) That's correct
(3a) Tango phone is oriented sideways wrt. body. In info.json align_tango_to_body corrects the misalignment, which maybe the +/- 10 you mentioned. You can see this in use in body-heading data loader.
(3b) There are some sequences where the user did not change the carry-type. But I believe this won't be true for most sequences.
(4) see (1) and data_description. pose/ekf_ori is the orientation of IMU device
I hope this helps. Please reopen if I missed any questions
First of all, thank you so much for all your hard work putting together this dataset and codebase.
I had a few related questions about understanding the different source of pose in the data.hdf5 files. I am trying to make sure I understand the format because I am trying to convert my own datasets to be compatible with the conventions in the ronin codebase.
(1) I just wanted to confirm that
pose/tango_oriandpose/ekf_oriboth represent the orientation of the tango device (either directly from the device or after some visual-odometery/ekf filtering),game_rvis the orientation of the IMU device, and all these 3 quaternion representations are in w-x-y-z format (that last part seems evident from the code, but just wanted to confirm).(2) Also wanted to verify that the x/y/z axes (both for the quaternions, and for the positional data (
pose/tango_pos) and gyroscope are in ENU (east-north-up) order, (although, as you mentioned elsewhere, they might not be aligned with true north/east so it's more like right/forward/up), and that positive gyroscope values correspond to counter-clockwise angular velocity. Is this correct?(3a) I was trying to visualize the quaternion orientations by converting them to Euler angles (roll/pitch/yaw) to check if my understanding of the axes and the pose format is correct. (For this question, I was looking in particular at the a000_7 sequence). The values for 'yaw' are consistent with the heading calculated by taking the difference is position between successive timesteps (with a constant offset), which makes me think I am on the right track. But depending on my choice of axes (ie. how I calculate the Euler angles), sometimes my plots seem to indicate that the tango device is oriented either upside down or sideways? (ie, values of 'roll' either hovers around 0 (straight), 90 (sideways), or 180 degrees (upside down))? Can you confirm the 'roll' orientation of the tango device? Also, on average (at least for this particular sequence), is it easy to tell (e.g. from video) if the worn tango device was facing slightly upwards or downwards across the sequence (I sometimes see a pitch offset hovering around 10 (+/- 5) degrees, and I'm hoping to establish whether it was 10 degrees facing up or down from horizontal to help constrain the possibilities of axis choice, etc.)
(3b) Another strange thing is that across this entire sequence (for a000_7, but for other sequences too), roll and pitch seem to maintain the same value (to within 5-10 degrees), for all 3 sources of orientation (
pose/ekf_ori,game_rvandtango_ori). I expected this for thepose/ekf_oriandtango_ori(since the device is strapped to the chest), but I would have thought that the pitch and roll from thegame_rvorientation, being the orientation of the IMU device, would vary much more across the sequence as the user interacts with the phone in normal every day use...?(4) In lines 65-66 of this file: https://github.com/Sachini/ronin/blob/master/source/data_glob_speed.py#L65 you have:
My understanding of these lines is that we are adjusting/reorienting the gyroscope and accelerometer data at each timestep into so that the values across all timesteps are aligned to have orientation in the world-frame coordinates. The function
select_orientation_sourcea few lines before selects an orientation source which can either be (1)gyro_integration, (2)synced/game_rvor (3)pose/ekf_ori. Now, this makes sense if the orientation source isgyro_integrationorgame_rv(1 or 2) since they are both orientations based on the local orientation of the IMU device). But how can we usepose/ekf_ori(3) for this, since that is the pose from the perspective of the tango device which (apart from during the initial calibration sequence) does not have the same orientation as the IMU device?Thanks for your help clarifying these issues!
Avi Ziskind