A camera calibration session in ROS fails more often at the build step than at the checkerboard: you clone the image_pipeline stack, run the build, and cmake stops inside depth_image_proc with a find_package error for stereo_msgs, before a single frame is captured. The message reads like a CMake path problem, but the cause is almost always a missing Debian package.
This guide is for engineers bringing up camera calibration on a ROS workstation. It shows how to read the error, install the distro-matched package, rerun the build, and fix the commit failure that surfaces later when the calibrator cannot reach the set_camera_info service. It ends with a prevention list for the next workspace you clone.
Why does cmake report "Could not find a package configuration file provided by stereo_msgs"?
The build fails because depth_image_proc declares stereo_msgs as a required catkin component and the message package is not installed, so find_package cannot locate stereo_msgsConfig.cmake anywhere on CMAKE_PREFIX_PATH and cmake aborts at configure time.
The decisive lines look like this:
CMake Error at /opt/ros/kinetic/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
Could not find a package configuration file provided by "stereo_msgs"
with any of the following names:
stereo_msgsConfig.cmake
stereo_msgs-config.cmake
catkinConfig.cmake walks the component list that the package's CMakeLists.txt requests through find_package(catkin ... COMPONENTS ...). Every component must resolve to a package configuration file, and message definitions such as stereo_msgs ship as their own Debian package. Cloning image_pipeline fetches its source, not its dependencies, so the first build on a fresh workstation stops here.
The tail of the output confirms the ordering. The isolated builder had already processed camera_calibration and was chaining its environment through env.sh under devel_isolated when depth_image_proc failed. That ordering helps: the error always names the first package whose dependency is missing, and later packages stay untouched until you fix it.
How do you install the missing message package for your ROS distro?
Install the package whose name the error prints, prefixed with your release — on Kinetic that is sudo apt install ros-kinetic-stereo-msgs — then rerun the build.
The pattern of a lowercase release segment between ros- and the package name holds for every message package the error may name, and the segment is lowercase — kinetic, melodic, noetic — because apt package names are case-sensitive. After the install, the file cmake was hunting for exists under your release's share/stereo_msgs folder, for example /opt/ros/kinetic/share/stereo_msgs/stereo_msgsConfig.cmake, and confirming that path takes ten seconds before you rebuild.
A driver package absent from the install entirely is the same failure one level up; the article on ROS camera package availability and setup walks that variant.
What if stereo_msgs is installed and cmake still cannot find it?
Then the prefix holding stereo_msgsConfig.cmake is absent from the shell's CMAKE_PREFIX_PATH, and the repair is environmental: open a fresh terminal, source the environment you build with, and confirm the file exists under your release's /opt/ros prefix.
Work through the causes in this order of likelihood:
- Wrong release sourced. A workstation with two ROS releases exports one release's setup while apt installs into the release named in the package. Print CMAKE_PREFIX_PATH in the build terminal and check that the prefix containing share/stereo_msgs is on it.
- ROS built from source to a custom prefix. Debian packages land in /opt/ros while your build searches another install space. Either add that prefix or, as the error itself suggests, set stereo_msgs_DIR to the directory containing stereo_msgsConfig.cmake.
- A stale configure cache. The failed run wrote its cache into build_isolated/depth_image_proc. Delete that folder before rerunning so cmake reconfigures instead of remembering the old, empty search.
The error's own lines map to those causes:
| Error line | What it means | Action |
|---|---|---|
| Could not find a package configuration file provided by "stereo_msgs" | The message package is not installed |
sudo apt install ros-kinetic-stereo-msgs (match your release) |
| Add the installation prefix of "stereo_msgs" to CMAKE_PREFIX_PATH | Installed, but this shell's environment misses the prefix | Fresh terminal, source the matching release, rerun |
| set "stereo_msgs_DIR" to a directory containing one of the above files | Manual override for a non-standard install location | Point it at the folder holding stereo_msgsConfig.cmake |
| Failed to process package 'depth_image_proc' | The isolated build stopped here; earlier packages completed | Fix the cause, rerun the same build command |
The same configure-time logic — one missing build dependency stopping a whole configure — exists outside ROS; the guide on missing OpenCV headers in a camera SDK build covers that case.
How do you rerun the build after installing the package?
Rerun the identical command that failed — catkin_make_isolated from the workspace root — because it reconfigures depth_image_proc and continues through the rest of image_pipeline, each package building against the devel_isolated environments before it.
You do not need to retype the long cmake invocation the error prints; catkin_make_isolated regenerates the env.sh chain and the -DCATKIN_DEVEL_PREFIX and -DCMAKE_INSTALL_PREFIX arguments itself. Keep one build tool per workspace: switching between the plain and the isolated builder mixes two devel spaces and produces a second class of configure errors that looks similar but is not.
When the rerun gets past depth_image_proc, the remaining packages of image_pipeline build the same chained way. A configure failure with the package found but interfaces wrong is a different problem; the article on diagnosing a ROS camera SDK API mismatch at build time handles that variant.
Why does the calibrator save samples but fail on commit?
Commit is a service call, not a file write: the tool stores /tmp/calibrationdata.tar.gz either way, but only Commit uploads the result to the camera's set_camera_info service, and it fails when the driver exposes that service under another name such as /camera/rgb/set_camera_info.
The calibrator derives the service name from the camera remap: camera:=/camera makes it call /camera/set_camera_info. Drivers that run separate heads — an RGB stream beside a depth or stereo pair — namespace their services per head, so the real service is /camera/rgb/set_camera_info. ROS remaps services exactly like topics, so the repair is a remap on the command line, shown next. After a successful fit the tool prints the matrices D, K, R and P before attempting the upload, and without a reachable service you can add --no-check-service to collect samples and leave the commit for later.
If the calibration window never fills because no frames arrive, the build is no longer your problem; the diagnosis of a camera configuration revision mismatch with no frames covers that separate failure.
Which command calibrates an RGB camera and commits in one pass?
Run rosrun camera_calibration cameracalibrator.py --size 8x6 --square 0.108 image:=/camera/rgb/image_raw camera:=/camera /camera/set_camera_info:=/camera/rgb/set_camera_info: it watches an 8x6 inner-corner target with 0.108 m squares and sends the finished calibration to the RGB head's service.
rosrun camera_calibration cameracalibrator.py --size 8x6 --square 0.108 image:=/camera/rgb/image_raw camera:=/camera /camera/set_camera_info:=/camera/rgb/set_camera_info
The three mappings do different jobs. image:=/camera/rgb/image_raw points the tool at the raw stream, camera:=/camera sets the namespace it works in, and the final entry overrides the service name the commit calls — the piece that turns a save-only session into a committed calibration. --size counts interior corners, 8 by 6, not squares, and a wrong corner count is the classic failure once the build clears; the fix guide for checkerboard grid pitch errors covers that in detail.
A stereo pair is its own procedure with its own target handling; the guide to stereo camera calibration from paired checkerboard images covers the two-camera case.
Do the printed numbers describe a healthy calibration?
Commit prints the matrices, and a ten-second read catches most bad fits. Take an output with fx = 546.63 px, fy = 549.63 px, cx = 332.34 px and cy = 226.02 px.
- Square pixels: fy / fx = 549.63 / 546.63 = 1.005. A mono camera should land within about 1% of 1; a value far from it means the optimizer did not converge on real corners.
- Principal point: those cx and cy values suggest a 640×480 stream, whose centre is (320, 240). Offsets of +12 px and −14 px are normal; a principal point hundreds of pixels from centre means the samples never covered the frame edges.
- Field of view: with W = 640 px and fx = 546.63 px, FOV_x = 2 × atan(W / (2 × fx)) = 2 × atan(640 / 1093.26) = 2 × atan(0.585) ≈ 2 × 30.3° ≈ 60.7°. Compare that angle against the lens specification; a large mismatch means the committed calibration belongs to a scaled or binned stream, not this one.
The atan runs in degrees and the formula assumes a rectilinear lens, so treat 60.7° as an estimate, not a datasheet figure. If depth and color drift apart downstream, the calibration itself is fine and the transform use is not; the guide on fixing stereo depth-to-color alignment errors picks up there.
How do you prevent missing-package errors on the next build?
Install declared dependencies before the first build: run the ROS dependency installer against your workspace (rosdep install --from-paths src --ignore-src -r -y), and this class of find_package failure disappears.
- Clone, then run rosdep before the first cmake, so every declared dependency resolves early instead of surfacing one error at a time.
- Keep one release per terminal: the distro segment in package names must match the environment you source.
- Build with one tool per workspace and rerun that same tool after any fix.
- Before calibration day, confirm the exact set_camera_info service name your driver exposes and put the remap into the launch file rather than into somebody's memory.
- Measure the target and count its inner corners before the first sample; bad geometry costs more time than any missing package.
The discipline carries across stacks: message-package and environment errors dominate ROS 2 driver builds too, and the guide on troubleshooting ODrive CAN package builds in ROS 2 works that case end to end. Tooling that wraps a workspace in a container fails on its own environment rules; the fix for the unexpected package size error from Isaac ROS run_dev.sh is that article's subject.
Prevention also means asking whether the pipeline needs building at all. If the end goal is depth data rather than the calibration exercise, a packaged 3D sensor replaces the stereo stack you were assembling.
- Type
- Stereo / structured light
The 3D sensors category spans laser profilers, structured-light stereo cameras and ready-built 2.5D inspection systems, so matching a sensor to the part is a selection problem rather than an integration problem.
The camera behind the calibration matters as much as the stack. Browse the area scan cameras or filter the camera finder by interface, resolution and shutter, and start the camera configurator if you are specifying a new station. More build and integration fixes sit on the systems topic page, and if a build still fights back, the /contact/ page reaches an engineer — free expert support comes with every order.
Questions
What is stereo_msgs and why does depth_image_proc need it?
stereo_msgs is the ROS message package that defines stereo message types, including the disparity image type that depth_image_proc publishes and consumes. Message definitions live in their own package so pipelines can depend on them independently of any node code, which is why a fresh image_pipeline clone needs the release-prefixed stereo-msgs package installed before its first build succeeds.
Does the same fix apply on Melodic or Noetic?
Yes. Replace only the distro segment in the apt name: ros-melodic-stereo-msgs or ros-noetic-stereo-msgs, always lowercase. The find_package failure and the cure are identical on every release. Kinetic itself has passed end of life, so if you can rebuild the workstation, moving to a supported release removes a second layer of expired-package problems.
Why does --size 8x6 describe a board with more squares?
The flag counts interior corners, not squares: an 8x6 corner grid sits inside a board of 9x7 squares, so a target with more squares than eight by six can still be correct. What breaks the fit is a corner count the physical board cannot produce, because the optimizer then assigns coordinates to wrong corners.
Where does the calibration go after clicking Save?
Save writes /tmp/calibrationdata.tar.gz, an archive with the computed values and the sample images. Because /tmp is wiped on reboot on most systems, copy it somewhere permanent if commit keeps failing. The remap in this guide remains the proper fix; the tarball is the backup that saves you repeating the session.
What do the printed D, K, R and P matrices mean?
D lists the lens distortion coefficients. K is the intrinsic matrix: focal lengths in pixels on the diagonal, the principal point in the last column. R is the rectification rotation, identity for a single monocular camera. P is the projection matrix the rectified pipeline uses. Once commit succeeds, downstream nodes read all of these from the camera_info topic.