apriltag_ros: Node does not work with galactic?

First of all, thanks for the ROS2 port!

I’ve pulled today the current version and noticed, that apriltag_ros cannot be build any more. I’m using ROS2 Galactic on Ubuntu 20.04.5 LTS on virtual machine and I got the following error:

--- stderr: apriltag_ros                         
CMake Error at CMakeLists.txt:25 (find_package):
  Could not find a configuration file for package "apriltag" that is
  compatible with requested version "3.3".

  The following configuration files were considered but not accepted:

    /opt/ros/galactic/share/apriltag/cmake/apriltagConfig.cmake, version: 3.2.0

In the Galactic central index there isn’t still apriltag 3.3: https://github.com/ros/rosdistro/blob/master/galactic/distribution.yaml so I wonder where can I get it?

Until then, I found out, that I can remove the version from CMakeLists.txt line 25 like that: find_package(apriltag REQUIRED)

Only then I got other errors on launch. The initialization of the ROS2 parameters “detector.refine” and “detector.debug” fails even when I do not set the parameters and wrong parameter type error appears. Here the one for “detector.refine”, they are both identical:

[INFO] [launch]: All log files can be found below /home/mihail/.ros/log/2022-09-27-22-53-49-985567-myVB-20693
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [component_container-1]: process started with pid [20705]
[component_container-1] [INFO] [1664312030.711422719] [apriltag.tag_container]: Load Library: /home/mihail/thermalcamerafaultdetection/ROS2_Workspace/install/apriltag_ros/lib/libAprilTagNode.so
[component_container-1] [INFO] [1664312030.884578613] [apriltag.tag_container]: Found class: rclcpp_components::NodeFactoryTemplate<AprilTagNode>
[component_container-1] [INFO] [1664312030.884656263] [apriltag.tag_container]: Instantiate class: rclcpp_components::NodeFactoryTemplate<AprilTagNode>
[component_container-1] [ERROR] [1664312030.917002066] [apriltag.tag_container]: Component constructor threw an exception: parameter 'detector.refine' has invalid type: Wrong parameter type, parameter {detector.refine} is of type {bool}, setting it to {integer} is not allowed.
[ERROR] [launch_ros.actions.load_composable_nodes]: Failed to load node 'apriltag' of type 'AprilTagNode' in container '/apriltag/tag_container': Component constructor threw an exception: parameter 'detector.refine' has invalid type: Wrong parameter type, parameter {detector.refine} is of type {bool}, setting it to {integer} is not allowed.
^C[WARNING] [launch]: user interrupted with ctrl-c (SIGINT)
[component_container-1] [INFO] [1664312600.778612133] [rclcpp]: signal_handler(signal_value=2)
[INFO] [component_container-1]: process has finished cleanly [pid 20705]

I managed to fix the error by reverting the data type back to int, as it was before commits on Aug 28, 2022. Does this has something to do with the fact, that I’m not using the newest version 3.3? The parameters are being initialized from the “apriltag_detector_t* const td”.

Then as a side question, I was wondering why the more precise pose estimation from the apriltag library is not implemented. The pose estimation from the homography has very low precision that is almost unusable, isn’t? I’ve took the time to implement it as an optional setting that is turned off by default and I think it could be useful to others as well. I can gladly contribute it if you want: https://github.com/MihailV1989/apriltag_ros

Only I cannot guarantee there aren’t any hidden bugs and that the code is optimized well as I have no experience with C++. The more precise pose estimation can be turned on by the “refine-pose” parameter that I saw in a very old launch.py file few months ago.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 20 (10 by maintainers)

Most upvoted comments

I would say that it would be inconvenient if you are stuck with the original calibration resolution. If you’re using a third party camera image publisher and you calibrate the camera at say full resolution, then you have to manually scale the intrinsic parameters every time you change the resolution. In my case I’m starting a third party publisher node and I have to give the path to a .yaml file where the intrinsic camera parameters are saved and I could edit the file according to the set resolution. But this is only possible at start and with time a calculation error will accumulate. So I don’t find it a good solution as you won’t be able to experiment easily with different resolutions.

I am still not sure what the exact problem is. What do you mean with being “stuck with the original calibration resolution”? Every camera setting, such as image dimension, zoom, lense, etc. will have a dedicated set of intrinsic parameters.

When a ROS node publishes images, it also has to publish the corresponding intrinsics. When this node publishes a scaled version of the image, it also has to scale the intrinsics accordingly. You will see this with cameras supporting different image resolutions. Most of them will have dedicated intrinsics for every setting. Otherwise, you will have to calibrate them manually for every setting you use. It’s the responsibility of the “sender” (e.g. a camera or generic image publisher) to make sure that image data and intrinsics are correct and match. The “receiver” (e.g. this apriltag node) cannot know how the images are scaled. It just relies on the image data and intrinsics.

Then about the decimate function. In the case that you’re interested in the pose estimation capabilities, it does not make sense to reduce the resolution only for the quad detection that is then used for the pose estimation and still use the full resolution for decoding the binary payload.

It depends on your application of course. If there is only a single image consumer/subscriber then publishing at a lower resolution makes sense. But if there are multiple consumers, you force them all to use the lower resolution, even though a higher resolution would be possible. So this is entirely up to your setting and you cannot easily generalise this. Some people will only want to reduce the resolution for the AprilTag detection, some will want to have a lower resolution for their entire setup. In any case, you have to provide the corresponding intrinsics.

Maybe all this is not a big deal, but scaling the intrinsic camera parameters when the actual image resolution differs from the calibration resolution is even less problematic and makes the node more foolproof, isn’t?

If the image source is publishing scaled images it also has to scale the intrinsics accordingly. It’s not the responsibility of the receiver to figure out scaling and adapt the intrinsics. It is much more foolproof when the image data and correct intrinsics are published by the sender.