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)
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.
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.
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.