MichaelGrupp
commented
5 months ago I normalized the first frame of GT_poses.txt. To be specific, I extracted the poses of the first frame from GT_poses.txt, and then for each frame, I multiplied its poses with those of the first frame to obtain GT_poses_setorigin.txt.
If I understand correctly, your goal was to let GT_poses start at the origin. This would mean that the trajectory was transformed rigidly to the origin, without changing its shape.
But when I look at GT_poses vs GT_poses_setorigin, they have completely different shapes. This can be seen for example by plotting, comparing their path length (8cm vs 24cm), or by calculating their difference with a metric (as you also noticed, this should be zero but it's not).
So I suspect that your transformation step introduced this error and messed up your "setorigin" groundtruth trajectory. This can happen e.g. if you're using pose matrices and do the matrix multiplication in the wrong order (P*T vs T*P), but here you need to check the math of your code yourself.
the distances between the estimated poses and the ground truth poses, before and after rigid body transformation, are different
Not sure what the issue is here, this is the expected behavior. The alignment minimizes the distance. So unless you have already optimally aligned data, the distance will change compared to the unaligned case.
Running a metric to compare estimated_poses vs GT_poses gives a normal result (like "1.)" in your examples). They are similar and the alignment looks fine.
GT_poses_setorigin doesn't work well, but that's rather because of the general issues of that trajectory mentioned before, not because of alignment or the metric.
TwiceMao
@MichaelGrupp
Description: According to my understanding of Umeyama's method, it first aligns two sets of poses through similarity transformations and then I can calculate their distances. When using your Umeyama's method... (with scale correction), I encountered a peculiar issue. Simply put, the distances between the estimated poses and the ground truth poses, before and after rigid body transformation, are different. Specifically, All the camera poses I use are transformations from the camera to the world coordinate system，i.e. poses I used: camera to world(c2w). I suspect whether it is necessary to use 'world to camera' as the pose instead of 'camera to world'.I have a set of ground truth poses named GT_poses.txt and another set estimated through some method named estimated_poses.txt. Additionally, I normalized the first frame of GT_poses.txt. To be specific, I extracted the poses of the first frame from GT_poses.txt, and then for each frame, I multiplied its poses with those of the first frame to obtain GT_poses_setorigin.txt. I observed significant differences in distances, both in translation and rotation, between estimated_poses.txt and both GT_poses.txt and GT_poses_setorigin.txt. Finally, I tested the distance between GT_poses.txt and GT_poses_setorigin.txt, and it was also large. I cannot comprehend this phenomenon because performing normalization essentially involves a rigid body transformation, which should be solvable by Umeyama's method... (with scale correction). This issue did not occur when I used evo's Umeyama's method... (with scale correction) previously. This occurrence leaves me puzzled. At least the translation distance between GT_poses.txt and GT_poses_setorigin.txt should be close to 0, right? My commands and outputs are as follows:
Command:
1.
2.
3.
Additional files: Please attach all the files needed to reproduce the error.
Please give also the following information:
evo pkg --version:evo pkg --pyversion:evo_config show --brief --no_color:Ubuntu 20.04 evo version v1.16.0 evo pkg --pyversion 3.7.11
Download lineks of input files I used above tum_GT_poses.txt tum_estimated_poses.txt tum_GT_poses_setorigin.txt