Camera Calibration (or not...)

This weekend I wanted to see if I could calibrate the camera for ROS. I’ve done this before on a different robot in the past (during a course I took). Ultimately I was not successful. But figured I’d document a few things here for the sake of others.

  1. The raspicam_node by default only publishes compressed images. Turns out you can’t run the calibration program with compressed images.
  2. You can change the flag in the launch file so that it will publish raw images.
  3. I ran the calibration program on my laptop (see the camera calibration tutorial for steps). I got a very distorted image.
  4. Running rqt_image_view I was not getting an image when subscribed to the raspicam_node/image topic (whereas the picture looked fine subscribed to image/compressed). In the shell I was getting error messages ImageView.callback_image() while trying to convert image from 'bgr8' to 'rgb8' an exception was thrown (Image is wrongly formed: height * step != size or 308 * 1230 != 399360)
    A couple hours of googling and looking at ROS answers did not find a solution.

So no joy there. But…

  1. the raspicam_node actually comes with calibration .yaml files. I don’t know how good these generic files are, versus calibrating for one’s specific camera. Perhaps the Raspberry Pi cameras are consistent enough that this suffice’s. I hope so since that’s what I’m stuck with for now. These files are in the raspicam_node/camera_info folder
  2. the launch file has a url that ostensibly points to the appropriate file, but it doesn’t seem to be configured correctly - I’d always get messages that the file wasn’t found. I changed the line to
    <param name="camera_info_url" value="file://$(find raspicam_node)/camera_info/camerav2_410x308.yaml"/>
    that seemed to work OK - the startup [INFO] messages would say the file was found and the camera was calibrated
  3. even after that, the startup would still go on to say that it was looking for the default URL for a calibration file. I ended up copying all of the generic calibration files to /home/pi/.ros/camera_info. With that done, I no longer got messages saying that the calibration files couldn’t be found.

I don’t know yet if the generic calibration files are good enough. I want to use the camera to recognize AprilTags. Will update this thread once I’ve tried.


“What’s a cubit?”

And why is an “April” tag any better or worse than one done in March or May? :wink:


I’ve heard AprilTags are much better than QR codes. I was unimpressed with Carl’s results with QR codes.

@jimrh - see:


Don’t know if you’ve been watching what is going on with respect to the camera on raspberry pi. Ubuntu, and now PiOS Bullseye are changing how the picamera is accessed. I haven’t tried to get the raspicam node up in ROS2/Ubuntu 20.04 since they broke the Python picamera module. We’re all supposed to learn how to use the standard debian libcamera.

1 Like

For certain cases of “better” - they are simpler, so I’m sure they’re less computationally intensive for recognition.

The node is clearly working, at least somewhat - the compressed images come across fine. Not sure what library is being used by the node. There seems to be an issue with interpreting the image. Instead of 410x308 it thinks it should be 308x1230 (which is 410 x 3; so not sure if this is an issue with how the channels are interpreted???), and I’m not at all clear where the expected 399360 came from. There may be configuration settings to fix that. I was just too frustrated to work on it yesterday.

As an aside - I’m also doing an online OpenCV course - the whole need to convert back and forth between bgr and rgb is irritating in and of itself.



New story on that today:

But I’m running on Bionic, so I don’t think I’ll be impacted (???).

1 Like

There are some benefits to fixing at Bionic and ROS (1).

Be sure to keep backups before doing any updates. I have a (regretfully non-automated) suite of tests of motors, servos, encoders, distance sensors (IR and US), TTS, Speech Reco, and Camera that I run before and after updating. It makes updating even more daunting.

Carl stayed on R4R Stretch for almost a year after the R4R Buster appeared. Even some in-release updates have had to be reverted for a while to keep sound apps working due to Linux architectural decisions that the Raspberry Pi Foundation could not fight.

The once little, low-cost Raspberry Pi for education has taken its place among the processors a non-small portion of the world is counting on to work strong and consistent.