POC for SE and SO

[Affie]

[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%)	:arrow_up:

---

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 @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