Skip to content

Calibration Workflows for Mobile Robots

Source: Kalibr, camera_calibration docs, and diff_drive_controller Jazzy docs

Why This Matters

Robots are often tuned in the wrong order. Teams adjust filters, planners, and controllers while the robot is still carrying bad camera intrinsics, wrong wheel geometry, sloppy IMU assumptions, or stale sensor extrinsics. That wastes time because the downstream stack is being asked to compensate for errors that should have been removed earlier.

Distilled Takeaways

  • Calibration is a workflow, not a single step. Camera intrinsics, wheel geometry, IMU behavior, and sensor extrinsics affect one another.
  • Effective values matter more than nominal values. Tire wear, mounting drift, focus changes, and real hardware tolerances all beat CAD purity.
  • The right sequence usually starts with physical mounting truth, then single-sensor calibration, then cross-sensor calibration, and only then fusion and autonomy tuning.
  • Calibration artifacts should be versioned like code: YAML files, parameter values, frame assumptions, capture procedures, and validation notes.
  • A clean optimizer result is not enough. The robot still needs validation in RViz, simple motion tests, and end-to-end behavior checks.

Practical Order of Operations

  1. Confirm the physical build: frame names, sensor orientation, rigid mounts, and measured placement.
  2. Calibrate camera intrinsics and distortion so CameraInfo is trustworthy.
  3. Calibrate wheel radius and wheel separation using controlled straight-line and spin tests.
  4. Sanity-check IMU axes, resting bias behavior, covariance realism, and mounting orientation before fusion.
  5. Calibrate cross-sensor extrinsics and timing when cameras, IMUs, or other sensors must agree in one geometric model.
  6. Only after that, tune EKFs, localization, mapping, or navigation behavior.

What Usually Goes Wrong

  • Intrinsics are recalculated, but old camera YAML files keep getting loaded at runtime.
  • Odometry uses ideal wheel dimensions even though the controller already exposes radius and separation correction multipliers for real-world adjustment.
  • IMUs are fused before anyone confirms axis conventions, gravity handling, or whether orientation output is actually trustworthy.
  • Extrinsics are written once in URDF and never revisited after a bracket, mast, or enclosure change.
  • Timestamp issues are mistaken for spatial calibration issues, or vice versa.

Practical Value

  • Use ROS camera calibration tools for monocular and stereo intrinsics when you need a reliable CameraInfo baseline.
  • Use diff_drive_controller wheel multipliers and measured odometry tests when the robot drives plausible arcs in simulation but wrong arcs on the floor.
  • Use a tool such as Kalibr when camera-IMU or multi-camera alignment and timing need to be estimated together instead of guessed.
  • Keep calibration results close to bringup config so hardware replacement or field repair does not silently invalidate the stack.

Corroborating References

When to Read the Original Source

Go to the original sources when you want the exact camera-calibrator options, the diff-drive correction parameters used in Jazzy controllers, or the deeper visual-inertial and multi-sensor calibration workflows that Kalibr is built to solve.