Skip to content

Rework of camera-lidar calibration, point picking, optimization - #488

Merged
JanuszBedkowski merged 5 commits into
mainfrom
mp/extrinsic_solver
Aug 15, 2026
Merged

Rework of camera-lidar calibration, point picking, optimization#488
JanuszBedkowski merged 5 commits into
mainfrom
mp/extrinsic_solver

Conversation

@michalpelka

@michalpelka michalpelka commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

So:

  • moved from Euler to matrix in calibration JSON (for tools that consumes calibration).
  • I've reused BA Jacobins from observation equations (needed to add offset matrix to avoid gimbal lock, since Jacobins are TaitBryan angles for rotation) to create optimization for extrinsic calibration.
  • Vibecoded point picking logic, seems to be useful - will record video.
Screenshot 2026-08-14 at 23 28 26

michalpelka and others added 5 commits August 14, 2026 05:31
Signed-off-by: Michal Pelka <michalpelka@gmail.com>
…is offset

Extrinsics' om/fi/ka now represent a small rotation away from a constant
kCameraLidarAxisOffset (the camera/LiDAR coordinate-convention alignment),
instead of the full rotation directly. This makes the all-zero default
already a physically sensible starting pose and keeps a real calibration's
solved values far from the om/fi/ka gimbal-lock point (fi=+/-90 deg),
which previously sat right on top of the default and made the very first
solve of a session start on a rank-deficient normal-equations block.

CameraCalibrationSolver threads the offset through the LM solve via a
one-time point/translation rotation, so the vendored observation equations
and the solve loop itself are untouched. Camera.h/.cpp now reuse core's own
pose_tait_bryan_from_affine_matrix/affine_matrix_from_pose_tait_bryan for
the om/fi/ka<->matrix conversion instead of duplicating that math.

Saved calibration JSON now stores rotation as a matrix only
(camera_rotation_matrix_in_world) -- convention-independent and portable --
instead of also carrying an om/fi/ka angle key; camera_lidar_calibration and
camera_lidar_trajectory_viewer both decode it back into om/fi/ka on load.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
TrajectoryViewer only ever reads a saved calibration; it had no reason
to decode the file's rotation matrix into Extrinsics' om/fi/ka and
reconvert back to a matrix at every use site (coloring, frustum draw,
COLMAP export, ROS TF export). Store the loaded R_wc directly and use
it as-is, dropping the omFiKaToMat3/omFiKaFromMat3 round trip.
AppleScript's choose-file-name only accepts a folder for default
location; appending the filename broke it before any dialog showed.
Signed-off-by: Michal Pelka <michalpelka@gmail.com>
@JanuszBedkowski
JanuszBedkowski merged commit 153d3a4 into main Aug 15, 2026
7 checks passed
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.

2 participants