Hi all! My students are experiencing some odd issues with the limelight. The limelight is losing track of the April tags when it can’t see them, defaulting the Robot Pos to 0,0,0. However, frequently doesn’t immediately switch TV (valid target) to 0, resulting in the robot thinking it’s in the center of the field rather than ignoring the value. I feel there is something I fundamentally am not understanding about what is considered valid or not.
Note, we have other ways of filtering out “garbage” values. I’m specifically curious about the apparent mismatch of valid targets, not “alternative fixes”
Tech notes: We are using limelight 3 with the most recent software updates. We had this issue on previous updates as well.
This is a good question though for @Brandon_Hjelstrom, I would think the Limelight might not have a stable enough frame of the AprilTag, but it still is sort of detecting it, so it’s technically detected, but can’t output a pose.
We had this same issue, and ultimately put a alternative fix on it (I know you didn’t want to hear about this…but just wanted to say we ran into the same issue!)
Our fix was to say if our vision measurement was off from where our odometry thought we were by over a meter to throw out the reading. This cleared most of our issues and made our vision more accurate. We also setup our limelight pipeline to filter out tags outside of the ones on the field.
I’d be interested in hearing more about the cause of this problem by the limelight though…hopefully Brandon will reply!
Because the Limelight uses separate networktables keys to send data, there’s no guarantee that the data from the various keys (“tv” / “tx” / “botpose”) are from the same image. You can read half of them from the previous frame and half from the new frame. I think this is the issue you are facing. Reading all the data from one single networktables key (a la the json dump) will make sure the data you read is actually synced.