Decouple AprilTag detection & pose/tf calculation.
Closed this issue · 4 comments
I have an application where the AprilTag detection has already happened, and I can post the AprilTagDetectionArray without the video stream (as an optimization, to save on constrained bandwidth). I do have access to the camera camera calibration, as well. Since this node does everything sequentially, I can't take the detections and turn them into poses.... but I think that's something I should be able to do.
Is this something anyone else cares about? If not, I'd be happy to just hack my own together (as its a small part of the node), but I'd also be happy to "do it right" (IMHO) and contribute it back.
Proposals (in order of invasiveness):
A) As mentioned above, the application is too niche for anyone to care, so I hack my own... and we go our separate ways. :)
B) Add a boolean parameter which toggles between taking a video stream in and performing the AprilTag processing (default) , or just subscribing to an AprilTagDetectionArray, but always doing the pose estimation (or make that optional too? )
C) Split AprilTagDetection & AprilTagPoseEstimation into 2 different composable nodes, connected by an AprilTagDetectionArray topic. Example launch file could have a container with both. Maybe keep the exiting one around too (but mark it as deprecated) so as to not break peoples' existing setups.
D) Do "C" above, but also split these into different packages, because they would now have totally different dependencies, with a 3rd "bringup" package depending on both. (footnote: I package my nodes into containers and pay a lot of attention to image size, so I'm always trying to comb out unnecessary dependencies).
Thoughts?
Your "pose" branch seems like it has done some refactoring along this line (by splitting the pose estimation out into its own source file), but it doesn't look like the intended purpose is the related to this decoupling.
Is it likely to get merged into main, or is it a dead end? If I fork and start this, I wouldn't want to set up an eventual a merge-hell by choosing the wrong starting point (should you want this merged back).
If this is something sought after by many people, I would go for option C, i.e. splitting the node and composing it again.
The main task of this AprilTag node is to use the AprilTag library and decode/encode the input/output of the library functions to ROS messages. If you are not using the node to decode ROS images and input them to the AprilTag library, then most of the node's functionality would be redundant for you.
For you, I guess, only the getPose method (or the alternative methods in the AprilTag or OpenCV) would be of interest. So why don't you just them instead of going through the "hassle" of running a ROS node and serialise/deserialise ROS messages?
Is it likely to get merged into main, or is it a dead end?
I created this branch to let others experiment with the pose-estimation results from different methods in order to find a method that would address the reported pose inaccuracies in #11 and #14. If there would be a clear advantage of using one over the other, I would replace the current getPose implementation with that one. I did not intend to merge this and to keep multiple pose estimation methods as an option unless there are different scenarios where one would work better than the other. However, I haven't heard back from the original issue authors so I don't know if there is a preferred candidate.
Thanks @christianrauch , I think I'll go with "option A" until someone else expresses interest...