Standardize IIF.LinearRelative to IIF.Isometry

[dehann]

Here is what the code is currently doing:
https://github.com/JuliaRobotics/IncrementalInference.jl/blob/4bb501c5fb6fd917895df3ba2000b589317e625a/src/Factors/LinearRelative.jl#L42

Which is a linear transformation that preserves the metric relations from a to b, and for our case a and b are in the the same metric space.
https://en.wikipedia.org/wiki/Isometry

[dehann]

This improvement will likely then also work for all the rigid body transforms in other Manifolds.AbstractGroupManifold that we use in Position{N}, Pose2, Pose3, etc.

xref:

• Standardize `IIF.Position{N}` #807

[dehann]

What I mean is, 1D example, walk forward 10 units, becomes:

addVariable(dfg, :a, Position1)
addVariable(dfg, :b, Position1)
addFactor(dfg, [:a,:b], Isometry(Normal(10,1)))

[dehann]

But then in the same breath, 2D becomes:

addVariable(dfg, :a, Position2)
addVariable(dfg, :b, Position2)
addFactor(dfg, [:a,:b], Isometry(MvNormal([10;0],[1;1])))

[dehann]

And after getting all the Manifolds conventions right, we can basically have Pose2Pose2 potentially just wrap Isometry too. And the same for Pose3Pose3.

This way we are better leveraging the community code implementations of standard mathematical tools.

[dehann]

If recalling correctly, Eigen library (C++) named rigid transforms as Isometry<...>, so we'll be better standardizing all round. Community will probably like that.

[GearsAD]

Looking at the current variables, and we would then have: Position1, Point2, Pose2, etc. Is it better to not call ContinuousScalar Pose1?

[dehann]

I'm thinking

• Pose2 or Pose3 has rotation information info.
• Position2 would replace Point2 without rotation (and long deprecation cycle).
• ContinuousScalar best corresponds to Position1.

---

I'm also thinking IIF keeps the names ContinuousScalar and ContinuousEuclid as aliases for non-nav related use. IIF is just the raw solver. RoME ads the nav API