Alignment with Starting at the same Initial Pose

[kameel2311]

The alignment does not take into consideration the constraint of starting the trajectories at the same pose. This is an issue as the --align would try to figure out the best un-constrained transformation that might skew the path off a more realistic alignment due to having sub-optimal path estimation from the ground truth.

Using the aligned_origin flag alongside align does not make a difference and having that as a feature would give more realistic errors.

[MichaelGrupp]

I don't understand what feature you are missing. It seems like you are talking about a constraint "starting the trajectories at the same pose" that you want to fulfill to have a "realistic alignment". But I am missing an exact specification of what you want to achieve and/or an example illustrating your current issue.

--align would try to figure out the best un-constrained transformation that might skew the path off a more realistic alignment

--align computes the least-squares alignment of both paths. Whether this is useful or not is completely use-case dependent, so please specify what a "realistic" result is in your case.

Using the aligned_origin flag alongside align does not make a difference

Not sure what you are trying to achieve with both flags, but --align_origin --align does not really make sense. Either use

• --align (full alignment, optionally with --n_to_align <number> to only align a limited number of poses)
• or --align_origin (aligning at the first matching pose).

Out of these options, --align_origin sounds like what you are looking for?

[kameel2311]

Sure let me further elaborate, and for simplicity I will provide an estimation of a straight line motion, of time-aligned ground truth data and estimated visual odometry.

Now not aligning the paths will of course have the motions in different planes as shown below, the mere purpose of this image to show the un-aligned trajectories:

Now using --align clearly shows that the paths are now on the same plane, but not starting from the same position (knowing that both trajectories start from the same point)

The issue is when we want to have the origins aligned , but the --align_origin flag does not achieve that , but rather gives the same results as without any alignment (even the plot title doesnt mention doing any origin alignment). As well as using both flags of --align_origin and --align. Realistic is a bad choice of words and what is meant is a more accurate estimate as I would imagine the best estimate is when the straight paths start at the same point and lie on the same plane.

The evo version I am using is: v1.30.0

EDIT: The --align_origin does not work with --correct_scale nor --align, the idea is to have alignment and aligning the origin at the same time (constrained optimization in a sense)

[kameel2311]

Checking the main_ape.py, why is the align_origin flag in an elif and not an if statement in line 64

[MichaelGrupp]

Thanks for the more detailed explanation. I see different things here:

• --align_origin --correct_scale: Mixing those was so far not yet considered in the evo_ape/rpe apps, but can be done. As you pointed out, this can be done by changing from elif to if.
• --align --align_origin: This is not supported, and also algorithmically doesn't make sense as it would break the properties of each other:
  • forcing start pose (position + orientation) to be the same
  • vs. minimizing distance over all poses

This is now handled clearer in v1.30.1, using both flags together is not possible anymore (details here)

idea is to have alignment and aligning the origin at the same time (constrained optimization in a sense)

This would require a completely new alignment algorithm, it's not possible to achieve with the available options.

[harry-graves]

I understand that --align and --align_origin are incompatible, however would it not be worth having an alignment algorithm that aligns the first pose in xyz, and then minimises the distance over all poses by adjusting the roll, pitch and yaw of the trajectory, with a flag to select the number of poses upon which to calculate this minimisation?

I am encountering situations whereby --align_origin results in the trajectories being vastly misoriented, so I am forced to use --align and --n_to_align, yet this minimisation results in the origins not being aligned, meaning the pose error does not start from zero. My understanding is that the pose error should start from zero and then drift.

[MichaelGrupp]

My understanding is that the pose error should start from zero and then drift.

I assume you are talking about an absolute pose error here. As you observed, these errors can quickly accumulate when aligning only at/around the start only. Errors at the start are weighted high, and the trajectory length influences the result too. That bias is one of the reasons why relative pose errors exist, because they measure drift invariant to global alignment and independent of total trajectory length.

I can't comment whether you "should" measure like that, because it depends on your use case. But I can say that absolute errors are usually not well-suited for drift comparison.

My recommendation that should cover most of the real-world evaluation scenarios is:

• APE without alignment: evaluation of absolute accuracy (example: localization quality)
• APE + full alignment: evaluation of overall trajectory shape consistency (example: mapping quality)
• RPE: evaluation of drift (example: odometry quality, e.g. rotational error per meter)

These are fair metrics that allow also to compare different results.

APE + origin alignment is also valid, but has this strong sensitivity on the quality of the first pose(s) that you need to keep in mind, so less suited to assess overall trajectory quality. APE with some new constrained alignment that minimizes around an arbitrary number of first poses while keeping the first position fixed (but not its orientation) also doesn't get rid of that problem. So I would recommend to check if a relative metric isn't better suited for the task.