8000 SE3(3)? Or SEk(d) · Issue #328 · artivis/manif · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

SE3(3)? Or SEk(d) #328

New issue

Have a question about this project? Sign up for a free GitHub account to open an i 8000 ssue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
andre-nguyen opened this issue Mar 27, 2025 · 12 comments
Open

SE3(3)? Or SEk(d) #328

andre-nguyen opened this issue Mar 27, 2025 · 12 comments

Comments

@andre-nguyen
Copy link

I've stumbled upon two papers that reference the lie group SE3(3) [1], [2]. Admittedly, I don't have access to [1] but from [2] I can see that they add the magnetic field state and cite [3] as definition of SE3(3) but I don't see it being explicitly mentioned in [3].

Am I understanding correctly that there is a way to add more states to the lie group, call it SE_k(d). As long as the state has dimension d and satisfies certain properties? Would it be possible and would it even make sense to have a generic implementation for group SE_k(d)?

Would be very interested in hearing your thoughts @artivis @joansola !

  1. L. Chang, H. Tang, G. Hu and J. Xu, "SINS/DVL Linear Initial Alignment Based on Lie Group SE3(3)," in IEEE Transactions on Aerospace and Electronic Systems, vol. 59, no. 5, pp. 7203-7217, Oct. 2023, doi: 10.1109/TAES.2023.3285716.
  2. D. Caruso, A. Eudes, M. Sanfourche, D. Vissière and G. L. Besnerais, "Magneto-visual-inertial Dead-reckoning: Improving Estimation Consistency by Invariance," 2019 IEEE 58th Conference on Decision and Control (CDC), Nice, France, 2019, pp. 7923-7930, doi: 10.1109/CDC40024.2019.9029283.
  3. A. Barrau and S. Bonnabel, "The Invariant Extended Kalman Filter as a Stable Observer," in IEEE Transactions on Automatic Control, vol. 62, no. 4, pp. 1797-1812, April 2017, doi: 10.1109/TAC.2016.2594085.
@joansola
Copy link
Collaborator
joansola commented Mar 27, 2025 •
edited
Loading

Hello @andre-nguyen thanks for this suggestion.

Yes the SE_n(3) group is well known already as the n-isometries group, and several papers take advantage of it. For example see Section IV.A in:

P. Vial, J. Solà, N. Palomeras and M. Carreras, "On Lie Group IMU and Linear Velocity Preintegration for Autonomous Navigation Considering the Earth Rotation Compensation, " in IEEE Transactions on Robotics, vol. 41, pp. 1346-1364, 2025, doi: 10.1109/TRO.2024.3521865, see alternate link.

Mathematically, SE_n(3) is built from the same blocks as SE(3), and therefore the exponential map, the adjoint matrix and the Jacobian (left or right) are easy to build. All formulas can be found in Section IV.A of the paper above.

Code-wise, I ignore how to achieve a class that can handle any number 'n' of isometries, e.g. a template class SEn3<n> with 'n' specified at compile time. This aspect can be better addressed by @artivis .

There is also the 2-frames group SE_{n+m}(3) which also may deserve attention. Again, the blocks to build it are those existing for SE(3) -- if I am not wrong --, and in this case we'd have two sets 'n' and 'm' of isometries. The hypothetical template class would be SEmn3<m,n>.

In this line of thinking, other groups are available:

  • two-frame systems with scalings
  • SGal(3)

And of course the same is true for the 2-dimensional cases.

@artivis
Copy link
Owner
artivis commented Mar 28, 2025

Hello,
I haven't looked at this in details (yet?). To help me form a general idea, is SE_n(3) == SE(3) x T3 x T3 ... ??

Code-wise, I ignore how to achieve a class that can handle any number 'n' of isometries, e.g. a template class SEn3 with 'n' specified at compile time.

Any such generic class would require a clear repetitive pattern to implement it, which might be the case here. It really depends on how complex the pattern...

The Bundle class is a similar case, where the pattern is super simple since no element interact. It thus boils down to a straightforward for loop.

@joansola
Copy link
Collaborator
joansola commented Mar 28, 2025 •
edited
Loading

A SEn(3) element is like so:

T = [ R v1 v2 ... vn ; 0_{nx3} Id_{nxn}]

so it's a rotation and n vectors. they all interact with R in the same was as in SE(3).

This is NOT equivalent to a Bundle<SE3, R3, R3, ...> because in this case all the extra vectors do not interact with R.

Again, all formulae can be found in Sec IV.A in the paper, and they are composed exactly of the blocks of the SE(3) formulas (that is, the left-jac of SO3 and the matrix Q(rho,theta) defined for the SE(3) case).

I have the feeling that the operations should be able to work with an iterative process implemented by a for loop. This includes the exponential map, the construction of the Adjoint matrix, and the construction of any Jacobian matrix:

Inverse:

Image

Exp and log:

Image

Adjoint:

Image

Right Jacobian:

Image

NOTE: beware that these formulas may have a diffferent ordering of the tangent space that the one we use in manif.

@joansola
Copy link
Collaborator
joansola commented Mar 28, 2025 •
edited
Loading

Also, should this SEn(3) group be implemented, then the SE(3) and the SE_2(3) groups would be particular cases. They could perhaps be re-defined as typedefs of the first somehow:

SE_2(3) = SEn3<2>
SE(3)   = SEn3<1>

Just a thought...

Moreover, SO(3) would be a particular case

SO(3) = SEn3<0>

but I think this is utterly weird, I would not recommend it.

@joansola
Copy link
Collaborator

I am thinking:

The ordering of the tangent spaces for SE3 and SE23 are a little inconvenient to make them special cases of SEn3, because they start with rho:

SE3: rho, theta
SE23: rho, theta, nu

but SEn3 should be one of these two options:

Sen3: theta, u1, u2, ..., un
Sen3: u1, u2, ..., un, theta
  • The first option is incompatible with SE3 and SE23
  • The second option is compatible with SE3, but not with SE23.

so I think it's best to leave it as a separate design.

@artivis
Copy link
Owner
artivis commented Mar 28, 2025

Would there be any interest in having SEn(2) ? Would an SGaln(3) make sense ?
In short, should such new template class be completely generic?

@joansola
Copy link
Collaborator
joansola commented Mar 28, 2025 •
edited
Loading

I don't know if SGal(3) can be generalized to more than 2 vectors, since I dont know how time would interact.

As per SEn(2), I guess it would also be interesting. But dimensions other than 2 or 3 make no sense, at least for robotics.

As I said earlier, a SEmn<m,n>(D), with any m,n and with D in {2,3} makes also sense. But it's a different story. It is true that SEmn<0,n>(3) would be the same as SEn(3), but it's maybe an overkill.

NOTE: In SE_mn(3), we have 'm' vectors in the local reference frame, and 'n' vectors in the global frame.
NOTE: In SE_n(3), we have 'n' vectors all in the same frame, which is typically the global frame

@joansola
Copy link
Collaborator

Maybe we can check the formulas for SEmn(D) and see if we want to build one only template, and then just typedef the rest.

However, this could impact the order of the tangent spaces, thereby not being backward compatible with the current SE(D) and SE2(3)

I dont't know how to deal with changes that can impact current users of the lib in the community. I guess this must come in major revisions such as manif 1.0.0, 2.0.0, etc. In such occasion, we should reconsider harmonizing all the tangent space orderings.

@artivis
Copy link
Owner
artivis commented Mar 28, 2025

SEmn(D) would be more difficult to implement as it also requires a special handling of oplus/ominus (and I guess there are no more rplus/lplus, just plus) and possibly many other such considerations.

I would look at SEn(D) on its own, it might not be all that difficult to implement, and possibly consider SEmn(D) later on.

I propose we pick the option sen3: u1, u2, ..., un, theta for now.

As for the slight mess that currently is manif tangent spaces, yeah we should bring some order to that. Note that manif still hasn't made it to 1.x.x (the latest tag is 0.0.5) which usually means that the software is still in development and thus might break.
Now, we could release a tag (e.g. 0.0.6) after implementing SEn(D) and any other fix that might be necessary so that current users can still refer to it. And then plan for a 1.0.0 release for which we reorder the tangents (in the line of theta, u0, u1 ...?). We would make a clear disclaimer in the release note as well as in the README.

@joansola
Copy link
Collaborator

Sounds like a good plan to me, @artivis !

@joansola
Copy link
Collaborator

And yes, I think the best order is starting with theta. Many other authors do so, and I bet we would be compatible with more other papers and software if we put theta first.

@joansola
Copy link
Collaborator
joansola commented Mar 29, 2025 •
edited
Loading

Another comment regarding efficiency.

In the construction of blocks, we may have to compute the matrix Q and the matrix J_l. For Q, we have to multiply theta_x and v_x together in different combinations. So two ideas:

  • Many of these computations can be stored as partial results and reused throughout.
  • To simplify such expressions I have collected a series of properties of the products of 3D skew symmetric matrices. The current implementation of the matrix Q would already benefit from some of these properties ang get slightly faster:
Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@joansola @andre-nguyen @artivis
0