Add optional seed argument to CreatePoints::CreatePoints() constructor to fix randomness and gain reproducability in python scripts:

synthetic = mrob.registration.CreatePoints(N_points,N_planes,N_poses, 0.01, 0.0, T0) 

# now here every run result will be different
GTtraj = synthetic.get_trajectory()
target = np.array(synthetic.get_point_cloud(0)) 

May be can add overload for CreatePoints in C++ and add optional argument in python bindings:

#set seeds here if needed
torch.manual_seed(777)
np.random.seed(777)
...
synthetic = mrob.registration.CreatePoints(N_points,N_planes,N_poses, 0.01, 0.0, T0, seed = 777) 

# now results are the same every run
GTtraj = synthetic.get_trajectory()
target = np.array(synthetic.get_point_cloud(0))

Or do this in more global manner for all mrob modules in a single line:

mrob.seed(777)
...
synthetic = mrob.registration.CreatePoints(N_points,N_planes,N_poses, 0.01, 0.0, T0)
...

The current solution goes point by point. Either passing Q or a list of points (compatible with open3d?)

An implementation of the paper on BA plane matching.

to run tests during build can simply build all targets with turned on tests. need execute the following commands in build directory:

cmake .. -DBUILD_TESTING=ON
make all
make test

The result should be somewhat like this:

Running tests...
Test project .../mrob/build
    Start 1: test_SE3
1/2 Test #1: test_SE3 .........................   Passed    0.01 sec
    Start 2: test_SE3cov
2/2 Test #2: test_SE3cov ......................   Passed    0.02 sec

100% tests passed, 0 tests failed out of 2

Total Test time (real) =   0.03 sec

i guess during cmake lists refactoring this part was lost.
pytests are running

by default the optimize_levenberg_marquardt prints messages at each Iter till Converged. there could be option to not print.

To be able to print object into the python terminal or jupyter notebook, it is just required to add the __str__ or __repr__ methods to python bindings. As I see there are already the __mul__ operator defined, so, I think it would be straightforward.

Some notes for reference:
https://www.digitalocean.com/community/tutorials/python-str-repr-functions

center planes for a distance always close to zero
This is for numerical stability of the unit plane vector

Modify the function FGraph.add_factor_point2plane() to accept a list of points with normals for fister registration ( no need for calling the function point by point)

New method including hessian from 3x3 eigen decomposition. We look for numerically more stable solutions.

This is a weak initialization with centroids of planes and PC aligment.
It should be outside the regular solve, so a dedicated method should get this first solution to the problem, otherwise, convergence is not guaranteed if the IC is far from the optimum

Right now, all is included in PC registration, but clearly it is not a registration method, but a more general concept.

Nodes included should be camera model, Pose and Landmark position

sim(3) and PC alignment should follow the same logic as in PCregistration. It requires:

• Define a Sim3 class built from SE3
• A new node from Sim3
• A new factor point to point

Minor upodates to make LM more generalizable.

Also, python work 'lambda' is protected.

To remove some warning, removing the virtual on child classes, and override on destructor.
Param [[maybe_unused]] removed since this is a cpp'17 feature and generates some warnings

simple open loop integration of gyro data. This is for loosely coupled DF

To export and compare, this feature should be in the project.

it was early merged, but not fully finished, it needs tests (there is an example code in /test). Plus a review on the SE3covVel

Hi,

Could I ask how the below results are derived?

  // dr/dxi = sqrt(S)'* T' * G' * pi = sqrt(S)'* T' * [normal^ | 0 0 0  ]
    //                                                   0 0 0   | normal']

Based on barfoot_ser17.pdf eq(7.159), the results seem should be
sqrt(S)'* T' * [d, d, d, -normal^
0^T, 0^T]
where n is the plane normal and d is the distance to origin.

This branch has grown too much and need to get back. Most of its functionalities are there

It requires to evaluate methods and improve create_points.cpp to have more metrics

weighted_point assumes 1:1 correspondence between X and Y. This is true in the case of ( x, y ) are generated with the same number of points and known correspondence. since the algorithm runs for 20 iterations or convergence there is no chance to update correspondence.
Solution: add argument for number of iterations so you can set it to 1 and update the correspondence after.

Add Python package support for M1, M2 macOS cpu

For example:
https://mrob.readthedocs.io/en/latest/classmrob_1_1SE3Cov.html

In doxygen config file the flag USE_MATHJAX = YES. Local tests with running doxygen util and sphinx-build worked fine, but for some reason when formulas not rendered properly when documentation is generated on the readthedocs.io

Just for comparison. Then use the 4d plane for the new factor. All pieces are there

Efficiency

It requires to adapt current factors to the new problem building.
It will maintain current implementation of EF-center, pi-factor and Bareg.

return mask {0.1} when robust (of any kind) is active.

Building wheels shows some problems