Skip to content

Conversation

@peci1
Copy link
Contributor

@peci1 peci1 commented Oct 13, 2025

This PR adds several improvements. They are mostly independent, but for simplicity, I've chained them all on a single branch. However, each improvement is a separate commit, so it should be easy to cherry pick if you only want some of the improvements.

Improvements:

  • This also includes Added support for Ouster scans with uint16_t ring fields. #40.
  • Allow optimizing IMU nonlinearity.
  • Fix for cases when RefIMU is given as Sen1 in SpatTempPriori (the RefImu extrinsics should never be optimized)
  • Allow specifying priors on gravity direction.
  • Allow specifying lower bound on visual scale for pos cameras
  • Allow specifying weight for intrinsics priors so that the optimized values do not diverge too far
  • Added the option to load already computed knots from a previous run and use these knots either as just initialization, or also as a constraint.

This PR brings a few changes to the config and spat-temp-priori YAML files. They have all been documented and all YAMLs in this repo were fixed.

It also changes the format of knots.yaml by adding the initial timestamp so that the knots can be successfully merged with different knots (this is mostly needed because of topic alignment).

Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
The optimization of nonlinearities will only be enabled in the last batch opt.
If the priors of all extrinsics and time offset are given for a sensor, there is no need to initialize the extrinsics and time offset using visual odometry or other approaches.

If you want the priors to be non-absolute (i.e. still allow their optimization), set them as RefImu-Sen2 or Sen1-Sen2 priors. If the priors should be absolute (non-optimizable), set them as Sen1-RefImu.
This speeds up optimization and prevents wrongly estimated visual scale if you know the optimization sometimes tend to squeeze the camera using 0.001 scale.
This can be used e.g. for a multi-stage optimization if you know that adding a sensor will confuse the optimization. You can first optimize with other sensors, save the splines, and then run a second stage with the confusing sensor, fixing the splines so that they cannot be confused.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant