frame_id: /systems/apriltag-on-demand
Trading continuous detection for a service call
Converted a continuously polling AprilTag detection node into an on-demand ROS 2 service, then chased down an unrelated camera-streaming regression it exposed.
Problem
The AprilTag/ArUco detection node was continuously accessing the camera to detect tags even when no detection was needed, adding constant CPU and network load to the vision pipeline for no benefit outside active pick/place operations.
Investigation
Replaced the always-on detection loop with a ROS 2 service — `/detect_apriltag` — that grabs a single camera frame on request and returns the tag ID and coordinates, with support for querying a specific tag or all visible tags in one call. Separately, production camera streaming was dropping under 6 Hz; debugging was hard because the lag was intermittent, appearing in some sessions and not others. After ruling out system load and network stability, the ZED camera's QoS reliability policy — set to Best Effort, which permits packet loss — was identified as the root cause once compared against an unaffected RealSense stream on the same rig.
Outcome
On-demand detection removed constant camera polling load from the pipeline. Switching the camera topic's QoS policy from Best Effort to Reliable resolved the frame-drop issue, restoring stable streaming.