multisensor_calibration

An actively maintained universal calibration toolbox for assisted, target-based multi-sensor calibration with ROS 1 and ROS 2 support. It provides a variety of methods and applications to calibrate complex multi-sensor systems, e.g.

• Extrinsic Camera-LiDAR Calibration,
• Extrinsic Camera-Reference Calibration,
• Extrinsic LiDAR-LiDAR Calibration,
• Extrinsic LiDAR-Reference Calibration, and
• Extrinsic LiDAR-Vehicle Calibration (prototype).

The software is licensed under the new BSD 3-Clause license. If you use this project for your research, please cite:

@inproceedings{
    ruf2025_multisensor_calibration,
    title={Multi-Sensor Calibration Toolbox for Large-Scale Offroad Robotics},
    author={Boitumelo Ruf and Miguel Granero and Raphael Hagmanns and Janko Petereit},
    conference={German Robotics Conference (RIG) 2025},
    year={2025},
} 

The multisensor_calibration is released as an official package for ROS 2 and can be installed with apt-get. Since ROS 1 is soon end-of-life, there will be no official release for ROS 1. However, there is a version of the source code available for ROS 1 under the branch noetic.

Acknowledgement: This software was developed as part of the projects AKIT-PRO (grant no. 13N15673) and ROBDEKON – Robotic Systems for Decontamination in Hazardous Environments (grant nos. 13N14674 and 13N16538), funded by the Federal Ministry of Education and Research (BMBF) under the German Federal Government’s Research for Civil Security program.

Continuous Integration:

Service	devel	main
GitHub

Contents:

• multisensor_calibration
  • Continuous Integration:
  • Contents:
  • Getting Started
    • Requirements
    • Build
    • Run
    • Documentation

Getting Started

Requirements

Basic catkin requirements can be installed by calling following command from the top of the catkin workspace:

rosdep install -y -r --from-paths src --ignore-src

Further requirements:

• PCL
• OpenCV
• Qt
• small_gicp: This is included as git-submodule and will be cloned and built on the first build. It is licensed under the MIT-License.
• OpenMP (optional): This is used to parallelize and speed up the processing of each point in the point cloud. If not found by CMake the processing will be done sequentially.
• Doxygen (optional): If available, this Doxygen documentation will be build automatically.

Build

1. Clone repository:

    git clone https://github.com/FraunhoferIOSB/multisensor_calibration.git
    

1. (OPTIONAL) Clone and build ‘small_gicp’.
   If this step is omitted, it will be executed as part of the first build.

    cd multisensor_calibration && ./thirdparty/clone_small_gicp.sh && ./thirdparty/build_and_install_small_gicp.sh
    

1. Initialize rosdep and install dependencies:

    sudo rosdep init
    rosdep update
    rosdep install --from-paths src -y --ignore-src
    

1. Run colcon to build from source:
   To build in ‘Debug’ mode add -DCMAKE_BUILD_TYPE=Debug to catkin command. If ‘CMAKE_BUILD_TYPE’ omitted, multisensor_calibration will be build in ‘Release’ mode.

    MAKEFLAGS='-j 8' colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release
    

Run

ros2 launch multisensor_calibration multi_sensor_calib_example.launch.py

Documentation

See the user documentation for basic usage, tutorials and workflows.

CONTRIBUTING

We are using the Feature Branch Workflow, and prefer contributions as merge requests.

There’s only one rule: anything in the master branch is always deployable.

Create a feature branch:

git checkout -B feat/<feature_name>

Recommended workflow

1. Fork the repository if your are not a collaborator and have direct access to the repository
2. Checkout new branch (branching of devel)
3. Make changes
4. Run tests
5. Commit those changes
6. Push
7. Create a pull request (targeting devel)

Branching Recommendations

• Try to keep two main branches main and devel .

• The devel -branch should be the default branch in which all developments are done and from which new branches are created.

• Each new release with a version tag should be merged into main . Intermediate merges can be made if there is a feature which is to be made available in the default branch prior to an official release.

Commit Conventions

We aim at concise and yet descriptive commit messages. In this, we suggest the following:

Each top line of a commit should be made up of a type and a subject

<type>: <subject>

Allowed types:

• feat: A new feature
• enhance: An enhancement to the current feature set
• fix: A bug fix
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, newline, line endings, etc)
• refactor: A code change that neither fixes a bug or adds a feature
• perf: A code change that improves performance
• test: Adding missing tests
• chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
• release: Committing changes, e.g. to CHANGELOG.rst, for a new release

You can add additional details after a new line to describe the change in detail or automatically close a issue on Github.

Example:

docs: create initial CONTRIBUTING

This closes #73

Versioning Conventions

This repo adheres to semantic versioning: http://semver.org/. Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards-compatible manner, and
• PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format