FAST-Calib: LiDAR to camera extrinsic calibration without a starting guess

The transform nobody can guess

FAST-Calib is an efficient target-based extrinsic calibration tool for LiDAR-camera systems, and it comes from the same group behind FAST-LIVO2.

The problem it solves is specific and common. A LiDAR and a camera see the same scene from different places, in different frames, and any algorithm that wants to project a point from the cloud onto the image, or to fuse the two streams, needs the rigid transform between the sensor frames. That transform has six degrees of freedom, it is usually not written down anywhere, and it is not something you can eyeball. Worse, the usual manual procedure needs a rough initial guess of the transform, and that guess is itself a chore that involves moving the sensor around and iterating.

The stated highlights are aimed squarely at those two problems. It supports both solid-state and mechanical LiDAR, it needs no initial extrinsic parameters at all, and it aims to achieve highly accurate calibration results in just one second. The summary of the goal is worth quoting because it explains the intended workflow: it makes extrinsic calibration as simple as intrinsic calibration, which is a procedure a camera team already knows, since the camera intrinsics come out of a target and a tool.

The algorithm is described in a paper, FAST-Calib: LiDAR-Camera Extrinsic Calibration in One Second, available on arXiv, and the repository points at a workflow document for the algorithm in detail. The calibration target design is based on the velo2cam_calibration project, which the acknowledgements also credit.

The circular hole is what makes one target work on every LiDAR

The calibration target is the piece of engineering that makes the rest possible, and the README shows it as an actual board alongside a technical drawing with annotated dimensions, with the CAD model shared as a download.

The key idea is a circular hole. The README's own caption for the second figure says it plainly: circular hole extraction supports multiple LiDAR models.

That is the constraint being engineered around. A LiDAR returns points, and the density of those points on a surface depends on the sensor's scanning pattern. A mechanical spinning LiDAR and a solid-state sensor with a limited field of view produce very different point distributions on the same board, and a detector tuned for one tends to fail on the other. A circular hole is a shape whose centre can be recovered from a sparse or irregular set of points, because the edge points around it fit a circle robustly, whatever the sampling pattern is.

So the workflow for your own sensor suite starts with customising the target, with the CAD model available to download, rather than with any software configuration. The board is a physical object you print or fabricate, and the software is built around the assumption that you have one.

That is also why the target design is credited to another project. The design is based on the velo2cam_calibration target, and the acknowledgements thank that algorithm as well as the people who provided support and equipment.

One scene first, then a joint calibration over three

The tool is run in two stages, and the README is precise about the order.

The first stage is the single-scene calibration, launched with a ROS launch file.

roslaunch fast_calib calib.launch

The second stage becomes available after you have completed the first stage for at least three different scenes, and it is the joint calibration across those scenes.

roslaunch fast_calib multi_calib.launch

The three scenes are not three copies of the same picture. The figure showing placement for multi-scene data collection illustrates three orientations of the target, facing forward, oriented to the right, and oriented to the left. The reason is geometric. A single view of a planar target constrains the transform only partially, because a plane has a degeneracy that a second, differently oriented view breaks. Three views from meaningfully different angles remove it.

The data for each scene is a rosbag containing point cloud messages and a corresponding image, and it goes into the calib_data folder. The repository ships that folder, along with a launch/ directory, an rviz_cfg/ directory for the visualisation, an output/ directory for the results, config/ for the parameter files, src/ and include/ for the C++ source, and scripts/ for the helper tools.

The sample data the README points to is on Google Drive, and it is split into single-scene data from Mid360, Avia and Ouster, and multi-scene data from Avia. That spread is a good indication of the range of sensors the tool is expected to handle, and it gives you a way to check the pipeline end to end before you go near your own hardware.

The YAML file is where your sensor's specifics live

Running it on your own sensor suite is a five step list, and four of the five steps are about the data and the configuration rather than about the software.

You customise the calibration target, using the shared CAD model. You collect data from three scenes, with the placements described above, and record each into the corresponding rosbag. You provide the intrinsic matrix in qr_params.yaml. You set the distance filter in qr_params.yaml for the board point cloud, and the note says extra points are acceptable. Then you calibrate.

Two things about that list are worth pulling out. The first is that the camera intrinsics are an input, not something the tool estimates. This is an extrinsic calibration tool, and the intrinsics are assumed to be known already, which is a sensible division of labour, since the intrinsics come from a much easier procedure.

The second is the distance filter, and the README gives a helper for it. You can run scripts/distance_filter_tool.py to quickly obtain suitable filter parameters. That tool exists because the filter is a fiddly parameter. The filter selects the points near the board in the cloud, and a value that is too tight loses the edges of the hole, while a value that is too loose includes the wall behind the board, and both give a worse estimate. The note that extra points are acceptable tells you the safe direction to err in.

So the configuration work is: find the distance filter with the helper, write the intrinsics in, and make sure the two refer to the same camera that produced the images in the bag.

What the tool needs from the system

The prerequisites section is short, and it names two libraries and implies a third.

PCL at 1.8 or newer and OpenCV at 4.0 or newer are the stated requirements. The third is ROS, which is implied rather than listed, because the package is a ROS package. There is a package.xml and a CMakeLists.txt in the repository root, which is what makes it a catkin or colcon package rather than a standalone binary, and the launch files are the entry point you saw earlier.

The build is therefore the usual ROS build, and the interesting dependency is the version floor on PCL and OpenCV. Those are the two libraries the detection depends on, and both have had significant API changes over the years. A floor rather than a ceiling is the right way to state it for a research tool, and it does mean the code is tested against old versions of both.

For an organisation that already has a robotics stack, none of this is unusual. The calibration package sits alongside the rest of the workspace, and the output is a transform you can drop into the rest of the system.

Paper claims, licence and who to ask

The headline number is in the title of the paper and in the project name, one second for the calibration. The README puts it as a highlight, alongside the support for both LiDAR types and the absence of any need for initial extrinsic parameters.

Read that as a property of the algorithm on the authors' setup rather than as a specification for your hardware. The pipeline is fast because the whole approach is a direct geometric solve on a small point set rather than an optimisation with many iterations, and that is a real structural advantage. But the accuracy claim and the timing claim both come from the paper's own experiments, with the sample data from Mid360, Avia and Ouster, and the right thing to do is measure the residuals on your own bags.

The licence is GPL-2.0, which is a strong copyleft licence, and the practical effect is that if you embed this in a product you distribute, the obligations of that licence apply to the derivative.

There are no GitHub releases, and the last push was on 2026-05-12, so the tool is maintained in the repository rather than shipped as artefacts. That suits a research tool where the input is your own data and the output is a YAML file, but it means there is no version to pin in a delivery.

For anything the documentation does not cover, the README names a contact, Chunran Zheng, with an email address at the HKU domain, which is the fastest route to an answer about your particular sensor combination.

Editorial conclusion

FAST-Calib fits a robotics team that has a LiDAR and a camera to be fused and does not want to solve the initial extrinsic problem by hand, and that is willing to print or fabricate the calibration target and collect three scenes of data. It does not fit a setup where you cannot present the target at three different orientations, since the joint calibration depends on that data, and it does not fit a project that needs a supported, released tool with a published accuracy benchmark on your hardware. Verify three things before you trust the output: that the distance filter in qr_params.yaml is set from the actual board, using scripts/distance_filter_tool.py, since a wrong filter changes which points are used, that your camera intrinsics in the same file are the ones for the camera in the bag, and that you evaluate the residuals on your own data, because the one second figure in the paper is a property of the algorithm on their setup rather than a guarantee about your sensor pair.

Frequently asked questions

Official sources

1. hku-mars/FAST-Calib on GitHub
2. Issues
3. License: GPL-2.0
4. README