Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing about "difference between groundtruth and oxts solution" #54

Open
LongruiDong opened this issue Dec 26, 2020 · 2 comments
Open

Comments

@LongruiDong
Copy link

Hi~
Thanks for your great open-source work!

When I am reading code , noticed your note here

""" Note on difference between ground truth and oxts solution:
 - orientation is the same
- north and east axis are inverted
- position are closed to but different
=> oxts solution is not loaded
"""

What does "ground truth“ and ”oxts solution" specifically refer to here?

In my understanding, "ground truth" represents the real SE3 (T_w_imu) pose calculated from (lon, lat, alt, roll, pitch yaw), and Velocity in world frame. When it comes to v_gt, why you use (ve, vn, vu) insted of (vn, ve, vu) ?

In other words , why need to invert north and east axis?Will it be inconsistent with the coordinates of imu in KITTI?

                    v_gt[k, 0] = oxts_k[0].ve
                    v_gt[k, 1] = oxts_k[0].vn
                    v_gt[k, 2] = oxts_k[0].vu
                    v_rob_gt[k, 0] = oxts_k[0].vf
                    v_rob_gt[k, 1] = oxts_k[0].vl
                    v_rob_gt[k, 2] = oxts_k[0].vu

I have been troubled by this problem for a long time, and I will be very grateful to you for pointing out my mistake 😁

@scott81321
Copy link

Do you know how to model GPS outage with Brossard's code?

@scott81321
Copy link

scott81321 commented Jan 28, 2022

Hello @LongruiDong Have you sorted out your questions? OXTS is Kitti file format.
Ground truth is Brossard's ground truth of the vehicle according to his own system. Brossard's program seems to be using a mixture of NED and ENU coordinates systems. The ground velocity (v_gt) seems to be in the ENU format. However, his position vector is obtained by first transforming lat-lon-alt to NED but then he swaps N and E - making it almost ENU - but apparently leaving the 3rd coordinate alone and since this 3rd coordinate is in the direction of gravity (yes IMU accel+gyro is forward, leftward and up with gravity recorded as roughly +9.8 m/sec^2 on the sensor). I thought RPY would also be in ENU convention since KITTI states that yaw=0 means East. However, I found out for my successful test run that RPY agrees with MATLAB's imufilter using accel+gyro in NED and ZYX standard, certainly for Yaw. Can anyone confirm or deny if Brossard's program uses NED or ENU for RPY?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants