POC for SE and SO

[Affie]

No description provided.

[codecov-commenter]

Codecov Report

Merging #45 (f9653f0) into master (1762ab7) will decrease coverage by 7.39%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master      #45      +/-   ##
==========================================
- Coverage   53.81%   46.41%   -7.40%     
==========================================
  Files           2        3       +1     
  Lines         433      502      +69     
==========================================
  Hits          233      233              
- Misses        200      269      +69     

Impacted Files	Coverage Δ
src/LazyLieManifolds.jl	0.00% <0.00%> (ø)
src/LegacySpecialEuclidean.jl	0.00% <0.00%> (ø)
src/Legacy.jl	61.31% <0.00%> (+3.35%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1762ab7...f9653f0. Read the comment docs.

[dehann]

@Affie please see review notes and be advised i changed the merge base to master for this PR

[dehann]

Note this PR is blocking RoME v0.15.2, see JuliaRobotics/RoME.jl#449

[Affie]

@Affie please see review notes and be advised i changed the merge base to master for this PR

@dehann i don’t see the review, dit you perhaps forget to submit?

[dehann]

ah, it might show up on the "Files" view of the PR:

[Affie]

ah, it might show up on the "Files" view of the PR:

It is still not showing up this side.

[dehann]

Hi Johan, i'm not so sure about adding new abstracts here. See Manifolds docs:
https://juliamanifolds.github.io/Manifolds.jl/latest/manifolds/group.html#Group-manifolds-and-actions

could you avoid adding a new abstraction below Manifolds? If these new abstracts are just to reduce the function definitions, I think it would be better to write out the functions instead -- i.e. write against <: SE or <: se rather than new abstracts?

[Affie]

If these new abstracts are just to reduce the function definitions, I think it would be better to write out the functions instead -- i.e. write against <: SE or <: se rather than new abstracts?

Yes, it is just to reduce function definitions.

AbstractLieGroup is not the correct name as it's a combination of a point and a manifold.
Maybe something like AbstractGroupManifoldPoint and AbstractGroupAlgebraVector is more accurate.

That is this wrapper exists, lets continue in JuliaRobotics/RoME.jl#450

[dehann]

we should move all these into RoME and replace the outdated RobotUtils.jl and OdometryUtils.jl currently in RoME

[dehann]

see related functions being moved in JuliaRobotics/RoME.jl#449

[Affie]

jip, just a sandbox to test the functions. not intended to stay.

[dehann]

Hi @Affie, i'm having doubts about this whole approach. I'm now thinking we should not be building types like SE and se at all.

I think we should drastically reduce the amount of duplication with Manifolds.jl and just simply use
VND.val::Vector{ProductRepr...}

and implement just RoME.oplus(::Pose3Pose3, p1,p2) which follows the same style as Manifolds.jl. That way we avoid the exp/retract issue we had in 366

I really want to avoid duplicating types, abstracts and API design from Manifolds. I'm actually thinking we should not implement a Lazy wrapper at all for the next couple of weeks and simply add the oplus functions in RoME until we have a better idea of what does and doesn't work. All we doing is dispatch against func(::AbstractFactor,...). E.g.
v = getCoordinates(Pose3, p1)

which is easily overloaded for
v_arr = getPointCoordinates(fg, :x1) # which we already know is a Pose2 or InertialPose3 etc