With the robot's pose relative to the tag now estimated, I can proceed to convert it into global coordinates by combining the visually-obtained information from the AprilTags with known data about the scene.
Starting from the output of the solvePnP function — as detailed in the previous entry — I obtain the robot’s position (tvec)
and orientation (rvec) relative to a tag detected in the image.
After converting this pose into a 4×4 homogeneous transformation matrix (combining rotation and translation),
I use the known position and orientation of the AprilTag in the world, read from the apriltags_poses.yaml file.
From this, I build another 4×4 matrix representing the transformation from the tag’s frame to the world frame.
With both matrices constructed — robot to tag, and tag to world — I multiply them to obtain the transformation from the robot to the global coordinate system.
From this final matrix, I extract the robot’s translation (x, y) and orientation (yaw),
which is the final target of the estimation.
This estimated pose is displayed on the simulator map using GUI.showEstimatedPose, allowing for visual comparison
between the estimated pose (in red) and the real one (in green).
After running the code, I observed the following key issues:
solvePnP is not executed,
and no update to the estimated pose occurs. As a result, the red line only reflects isolated estimations when a tag is detected,
while intermediate motion based purely on odometry is ignored.
The video below illustrates all of the above: