Question: manif Bundle<> or other ways to support composite/compound state.

[slovak194]

Dear, @artivis

I followed your discussion here regarding the need for composite/compound state support. I also see that in the manif repo, there is a way to do so with the Bundle<>. But there is no example in this repository of how to do that. Are there any impediments invisible to me that prevent using composite states?

The idea is to use manif/kalmanif for a practical application with a heterogeneous state: SE(3) - robot pose(). SO(3), SE(3) - sensor locations, orientations. 1D vectors, or scalars - sensor biases. (Optionally) 2D matrix - more complex sensor calibrations, homography, maybe members of other groups such as SIM(3).

Looking forward to your answer!

Best regards, Alex

[slovak194]

Are there any impediments invisible to me that prevent using composite states?

No impediments found.

[artivis]

Hi @slovak194, My apologies for the late reply. The Bundle class was developed so that it has the same API as any other group so it should indeed be usable with kalmanif. The main 'issue' I can think of is that one has to write the models (system/measurements) with respect to the entire Bundle state which leads to a lot of zeros and thus inefficiencies. This also isn't great in terms of code reusability.

[slovak194]

Hi, @artivis , Thank you for getting back!

I think it is worth reopening this issue as @joansola has added valuable comments here: https://github.com/artivis/kalmanif/issues/10#issuecomment-1346174269

And I see now, that my statement above (No impediments found.) is not correct.

I have to admit, that even after reading the Micro Lie Theory paper my overall understanding of the topic may be too shallow. Please, consider my inputs as from the user/application point of view, which may not coincide with the strategy of the manif/kalmanif development.

From the practical point of view, I'd like to have a way to quickly specify real-world states, which are usually not just individual group members, but many heterogeneous fields. Here is a simple example, and in my case, I'm going to have a few times more.

using SFWA_StateVector = UKF::StateVector<
    UKF::Field<LatLon, UKF::Vector<2>>,                 /* Latitude and longitude (rad) */
    UKF::Field<Altitude, real_t>,                       /* Altitude above the WGS84 ellipsoid (m) */
    UKF::Field<Velocity, UKF::Vector<3>>,               /* Velocity (NED frame, m/s) */
    UKF::Field<Acceleration, UKF::Vector<3>>,           /* Acceleration (body frame, m/s^2) */
    UKF::Field<Attitude, UKF::Quaternion>,              /* Attitude as a quaternion (NED frame to body frame) */
    UKF::Field<AngularVelocity, UKF::Vector<3>>,        /* Angular velocity (body frame, rad/s) */
    UKF::Field<AngularAcceleration, UKF::Vector<3>>,    /* Angular acceleration (body frame, rad/s^2) */
    UKF::Field<WindVelocity, UKF::Vector<3>>,           /* Wind velocity (NED frame, m/s) */
    UKF::Field<GyroBias, UKF::Vector<3>>                /* Gyro bias (body frame, rad/s) */
>;

For that purpose Bundle looked great at first. But now I see, that what I (and may be other people) need - is the simple "set" which just applies box+- (and maybe other) operators to it's individual fields separately and the interaction between its components is carried only in the system/measurement model explicitly by the user (i do not bother referring to individual elements of a bundle) or through the cross-covariance update during the a_posteriory step. I take the risk to refer this repository ukf which I and my colleagues find very handy to work with. It requires the very minimum boilerplate code from the user side to implement complex real-world filters. However, nothing is ideal and the support of quaternions there is not correct from our point of view.

The main 'issue' I can think of is that one has to write the models (system/measurements) with respect to the entire Bundle state which leads to a lot of zeros and thus inefficiencies. This also isn't great in terms of code reusability.

That is not a big issue from my point of view, as in general, the state transition function takes the time delta, current state, and control input to integrate the state of the system forward.

The Bundle class was developed so that it has the same API as any other group so it should indeed be usable with kalmanif.

If I correctly understood the answer from @joansola in another issue, this is not the case.

1. For some bundles, e.g. SO3xR3, we want composition to work as in SE3

As for me, it brakes the statement written here:

Best regards, Alex

[slovak194]

It looks my initial understanding was correct.