Recently our team ran into an issue at competition with MegaTag pose estimation. We initially calibrated our camera offsets based on the 2 tags on the blue speaker. We did this by placing the robot in a known location and adjusting the transform until the resulting robot pose matched our known position. This worked very well for most of the build season testing on blue side only. Then when we went to competition, we found that blue side estimations worked well, but the red side estimations were off by over a foot in the Y direction (guardrail to guardrail dimension).
When doing a postmortem, we found out that the error seems to be due to the limelight’s internal pose estimation. We came to this conclusion by displaying the returned wpilib_blue botposes without any transforms in the limelight (all set to 0). This is the result we got:
For reference our team was running 2 limelight 3s on the front of our bot, both equidistant to the center and slightly angled inwards. The robot was staged to be flush and centered on the subwoofer. With all this in mind, the above picture shows that the returned limelight pose estimate is clearly off in the positive Y dimension. There is also a similar offset with the same setup on a red speaker, but the offset is negative instead of positive like on the blue side.
Our team is kind of scratching our heads as to how we could resolve this issue. We also tried to re-create the tag map from the 2024 Field Marking and Diagram document from first to see if it was an issue with the built in April tag map and got similar results. Anyone else out there encounter an issue like this?
To me, this just seems like the limelight positions relative to the robot haven’t been set. I haven’t played with the limelight since last year but I remember there was a place to set the limelight 3d position on the robot in the 3d pose estimation. You may have accidentally not saved after you added this or may have went back to a save where these were all 0. I’m guessing that it was off on the red side since when flipped, what ever manual fix you or someone else made without addressing the real problem was giving a field relative offset and not a robot relative offset so it cause it to be off only on one side.
We have noticed a similar shift as well this year, to the point that we stopped using limelight for absolute pose estimation and only use it for aiming and distance calculations for shooting angle. We saw a similar roughly 5in position shift in +Y on the blue side, and the opposite (or no shift, depending on camera offset parameters) on the red side. This made PathPlanner auto-flipping unusable.
We did set our limelight offsets on the robot, however, this caused the robot pose on the red side of the field to be considerably different to the real pose
The quick fix we’ve implemented was to find limelight relative positions for both red and blue sides, allowing us to use the auto-flipping without any major issues, pose estimations look good enough now but the underlying issue still remains unresolved.
This I believe is the exact issue we were encountering, we saw a shift of about a couple inches on the Y axis as well on the red side as we derived our limelight’s position offsets based on the blue side.
We are also having issues with pose estimation. For us it shows up in where our robot aims at the speaker. When using the tags for the red side it is off considerably. I’ve looked at the fmap file we downloaded from limelightvision.io and the x and y values are off. I’m now trying to figure out how to confirm the rotations.
