I replaced the ground truth camera pose with the GT calculated by the devkit.

[LittleChild]

Hello. I find the sequences of your demo. I have extracted the ground truth camera pose from the "data_tracking_oxts", the KITTI Tracking Dataset. And I replaced the ground truth camera pose in the demo with the ground truth file calculated by myself. But the results were not as good as yours. So what should I noticed when I extract the ground truth using the raw data development kit? And could you tell me how you extract it for details?

[LittleChild]

哦，使用KITTI官方提供的devkit生成的pose真值，需要进行对应坐标系的转换，默认生成的是OXTS的坐标系，这在devkit对应函数中有说明，然后还要注意GPS/IMU的坐标系和相机坐标系的转换（具体在devkit的readme文件里有说明），经过转换后，得到的真值才是相机的真值，经过替换测试，结果跟demo的差不多。问题解决。

[LittleChild]

As the readme.txt shows,
"First, use oxts = loadOxtsliteData('2011_xx_xx_drive_xxxx') to read in the GPS/IMU data. Next, use pose = convertOxtsToPose(oxts) to transform the oxts data into local euclidean poses, specified by 4x4 rigid transformation matrices."

and

"The coordinate systems are defined the following way, where directions are informally given from the drivers view, when looking forward onto the road:

• Camera: x: right, y: down, z: forward
• Velodyne: x: forward, y: left, z: up
• GPS/IMU: x: forward, y: left, z: up
  All coordinate systems are right-handed."

Besides, OXTS coordinates are defined as x = forward, y = right, z = down (see OXTS RT3000 user manual).

So, after pose = convertOxtsToPose(oxts), we should transfer it from OXTS coordinates to camera coordinates.

Above are my understanding, are these right? @halajun

[Max617w]

哦，使用KITTI官方提供的devkit生成的pose真值，需要进行对应坐标系的转换，默认生成的是OXTS的坐标系，这在devkit对应函数中有说明，然后还要注意GPS/IMU的坐标系和相机坐标系的转换（具体在devkit的readme文件里有说明），经过转换后，得到的真值才是相机的真值，经过替换测试，结果跟demo的差不多。问题解决。

兄弟，OXTS转相机你具体是怎么转的，我试了试在convertOxtsToPose.m里转，想把输出的pose改成相机坐标系下。根据R_rect_00 * (R|T)_velo_to_cam * (R|T)_imu_to_velo这个转出来的不对啊。

[Max617w]

坐标转换没搞清楚，这样就行了，pose{i} = Tr_0_inv*[R t;0 0 0 1] * Tr_imu_velo_T * Tr_velo_cam_T;

[LittleChild]

兄弟，OXTS转相机你具体是怎么转的，我试了试在convertOxtsToPose.m里转，想把输出的pose改成相机坐标系下。根据R_rect_00 * (R|T)_velo_to_cam * (R|T)_imu_to_velo这个转出来的不对啊。
坐标转换没搞清楚，这样就行了，pose{i} = Tr_0_inv*[R t;0 0 0 1] * Tr_imu_velo_T * Tr_velo_cam_T;

我刚看到，你这应该是对的，我是觉得换不换到IMU的坐标系无所谓，就是要把这个Oxts的坐标系换到camera，跟你说一下我的具体做法。
我是这么做的：先用函数包中convertOxtsToPose函数计算得到的pose（OXTS的坐标系）
根据其设置：x = forward, y = right, z = down，发现跟IMU的比起来就是y和z反了，所以我就把这两个取反（变负数），然后直接算的变换后的坐标系跟camrea的坐标系的变换 T，计算出的pose根据T转换一下，左乘T，右乘T的转置:

T =[ 0    -1     0     0
     0     0    -1     0
     1     0     0     0
     0     0     0     1]
Pose=T*Pose*T';

这算出来的就是camera的了，我试过了，跟作者的demo里面的真值轨迹是一致的，跑的结果也差不多。
附图：

[gao19970315]

楼上兄弟们好！
按照你的方法，将Pose=TPoseT';仅在demo-kitti数据集（55帧），对比出来的结果是对的，但是如果放到全体144帧的基础上来比，就存在问题了。
拿第144张图片举例：
自己处理的GT:143 0.988913918 0.000807471 -0.148487746 9.974954671 -0.002023517 0.999965642 -0.008038644 2.741625980 0.148476154 0.008249994 0.988881575 172.391896386 0.000000000 0.000000000 0.000000000 1.000000000
作者提供的GT：
143 0.988933274 -0.001158800 -0.148356442 -8.665262612 -0.000368661 0.999947215 -0.010267974 -0.690116978 0.148360527 0.010209034 0.988880646 172.520788973 0.000000000 0.000000000 0.000000000 1.000000000
在平移量部分存在比较大的问题

兄弟，OXTS转相机你具体是怎么转的，我试了试在convertOxtsToPose.m里转，想把输出的pose改成相机坐标系下。根据R_rect_00 * (R|T)_velo_to_cam * (R|T)_imu_to_velo这个转出来的不对啊。
坐标转换没搞清楚，这样就行了，pose{i} = Tr_0_inv*[R t;0 0 0 1] * Tr_imu_velo_T * Tr_velo_cam_T;

我刚看到，你这应该是对的，我是觉得换不换到IMU的坐标系无所谓，就是要把这个Oxts的坐标系换到camera，跟你说一下我的具体做法。 我是这么做的：先用函数包中convertOxtsToPose函数计算得到的pose（OXTS的坐标系） 根据其设置：x = forward, y = right, z = down，发现跟IMU的比起来就是y和z反了，所以我就把这两个取反（变负数），然后直接算的变换后的坐标系跟camrea的坐标系的变换 T，计算出的pose根据T转换一下，左乘T，右乘T的转置:

T =[ 0    -1     0     0
     0     0    -1     0
     1     0     0     0
     0     0     0     1]
Pose=T*Pose*T';

这算出来的就是camera的了，我试过了，跟作者的demo里面的真值轨迹是一致的，跑的结果也差不多。 附图：

[darkyrs]

兄弟，OXTS转相机你具体是怎么转的，我试了试在convertOxtsToPose.m里转，想把输出的pose改成相机坐标系下。根据R_rect_00 * (R|T)_velo_to_cam * (R|T)_imu_to_velo这个转出来的不对啊。
坐标转换没搞清楚，这样就行了，pose{i} = Tr_0_inv*[R t;0 0 0 1] * Tr_imu_velo_T * Tr_velo_cam_T;

我刚看到，你这应该是对的，我是觉得换不换到IMU的坐标系无所谓，就是要把这个Oxts的坐标系换到camera，跟你说一下我的具体做法。 我是这么做的：先用函数包中convertOxtsToPose函数计算得到的pose（OXTS的坐标系） 根据其设置：x = forward, y = right, z = down，发现跟IMU的比起来就是y和z反了，所以我就把这两个取反（变负数），然后直接算的变换后的坐标系跟camrea的坐标系的变换 T，计算出的pose根据T转换一下，左乘T，右乘T的转置:

T =[ 0    -1     0     0
     0     0    -1     0
     1     0     0     0
     0     0     0     1]
Pose=T*Pose*T';

这算出来的就是camera的了，我试过了，跟作者的demo里面的真值轨迹是一致的，跑的结果也差不多。 附图：

大佬你好，我最近也在跑这个代码，我看您跑出的结果和真实值比较接近，但是我这边跑出来的结果明显有很大误差，我没有动过代码内容，所以我想问问您是修改过输出的一些东西吗

[FrozenSmile]

convertOxtsToPose输出的位姿为第k帧GPS/imu坐标系相对于第0帧GPS/imu坐标系的变换，记为:Ti0k，GPS/imu系与相机坐标系之间存在一个固定的变换关系，这个可以由calib得到，设imu到激光雷达系的变换为Tvi（对应calib里的Tr_imu_velo)，记激光雷达系到相机系的变换为Tcv（对应calib里的Tr_velo_cam)，则imu到相机系的变换为：Tci = Tcv*Ti。

最开始提到也提到，由于convertOxtsToPose输出的位姿表示了两个GPS/imu系之间的变换，要将其改变为对应的第0帧和第k帧两个相机系之间的变换：
Tc0k = TciTi0kinv(Tci)
其中inv代表逆矩阵
由此输出的位姿和作者提供的完全一致。

但我自己觉得不明确的地方那个在于：Tr_velo_cam代表的是否为激光雷达到相机2的变换？还是到相机0的变换？

[Cai-RS]

ConvertOxtsToPose输出的位姿为第k帧GPS/imu坐标系相对于第0帧GPS/imu坐标系的变换，记为：Ti0k，GPS/imu系与相机坐标系之间存在一个固定的变换关系，这个可以由calib得到，设imu到激光雷达系的变换为Tvi（对应calib里的Tr_imu_velo），记激光雷达系到相机系的变换为Tcv（对应calib里的Tr_velo_cam），则imu到相机系的变换为：Tci = Tcv*Ti。

最开始提到也提到，表示由于convertOxtsToPose输出的位姿进行了两个GPS/imu系之间的变换，相当于其改变为对应的第0帧和第k帧两个相机系之间的变换： Tc0k = Tci Ti0k inv(Tci) 其中inv代表逆矩阵 由此输出的位姿和作者提供的完全一致。

但我自己觉得不明确的地方是：Tr_velo_cam代表的是激光雷达到相机2的变换吗？还是到相机0的变换？

所有跟相机有关的位姿校准，都是以相机0为中间桥梁的，所以这个值代表的是激光到相机0的

[Cai-RS]

兄弟，OXTS转相机你具体是怎么转的，我试了试在convertOxtsToPose.m里转，想把输出的pose改成相机坐标系下。根据R_rect_00 * (R|T)_velo_to_cam * (R|T)_imu_to_velo这个转出来的不对啊。
坐标转换没搞清楚，这样就行了，pose{i} = Tr_0_inv*[R t;0 0 0 1] * Tr_imu_velo_T * Tr_velo_cam_T;

我刚看到，你这应该是对的，我是觉得换不换到IMU的坐标系无所谓，就是要把这个Oxts的坐标系换到camera，跟你说一下我的具体做法。 我是这么做的：先用函数包中convertOxtsToPose函数计算得到的pose（OXTS的坐标系） 根据其设置：x = forward, y = right, z = down，发现跟IMU的比起来就是y和z反了，所以我就把这两个取反（变负数），然后直接算的变换后的坐标系跟camrea的坐标系的变换 T，计算出的pose根据T转换一下，左乘T，右乘T的转置:

T =[ 0    -1     0     0
     0     0    -1     0
     1     0     0     0
     0     0     0     1]
Pose=T*Pose*T';

这算出来的就是camera的了，我试过了，跟作者的demo里面的真值轨迹是一致的，跑的结果也差不多。 附图：

你好，经过我的计算和比较，发现devkit的m文件计算出来的pose就默认是KITTi中imu的位姿了，即不需要y轴和z轴取反。这点我是通过kitti的odometry数据集中的序列04中的真值文件来比较的，发现m文件得到的pose”不取反“并经过多个传感器坐标转换就能得到和真值文件中的结果（如果取了反，很给定的真值文件反而差别很大）。虽然我也看了OXTS RT3000 user manual中的OXTS坐标系方向规定，确实和KITTI官方说的imu/gps的坐标系在y和z轴方向上相反，我也认为需要在这两个轴上取反。但是从计算结果来说，如果直接使用devkit给定m文件的函数来进行后续转换，那么是不需要取反的！我不知道这是kitti在计算odometry序列真值时疏忽了，还是在标定imu时坐标系实际规定与oxts相同，又或者m文件中的计算结果其实已经转换到与imu相同的方向。