@Brandon_Hjelstrom is there going to be an update prior to week 4? If not do you have an estimate?
We (I assume everyone else too? Please post if you got anything working!) are dead in the water doing anything except excluding the loading station tags! If there is nothing coming soon we may try harder on using the opponent grid tags to get a position but this seems like a huge hack given there is a tag right in front of the loading station.
Can’t you ignore the megatag pose by getting the pose of the tag directly? Might need to set up a separate pipeline just for the pickup station tags to do this. Complete NetworkTables API — Limelight 1.0 documentation
I am not exactly sure what the cause of the issues are but I don’t think any of the data in the table you linked will help. We weren’t seeing just the mega pose moving but all of them (though we have primarily been using the mega). The strange thing is it isn’t just jumps when the loading station is the only tag but also when two are seen like the issue above.
Have you or anyone else gotten things working this or another way? We might end up making a separate pipeline and going to 2D style on the loading station tag if we still get radio silence.
@jdaming @vargoose84 @kdschmitz @icemannie @RyanShoff @Clayton_Yocom
2023.5 is up for LL3. 
The 2+ image is almost done. There was a bug with certain non-planar layouts. Tags 4 and 5 will no longer break pose estimation - they should now improve estimation significantly.
Here is a video of tag 4 tracking pretty poorly with 0 movement, anything we can do to help this? Highest resolution and increased quality cutoff:
We also had a problem with the robot floating way up in the air. We were able to lock it to ground but something strange there.
What happens when you see two tags? Is it stable?
What values are you using for decimate? (Not sure what LL calls this)
Maybe it was more stable than just one but still seemed significantly less stable than seeing two grid tags which seems to work really well (which also meant it wasn’t stable enough to use our loading station approach code). To be completely fair our April tag setup is far from ideal as it is setting the loading station tag on a makeshift loading station and then positioning an additional tag in what we measured was the correct location taped to a box. So far from official but similar things seem to work fine for grid tags.
We are using 2 (which is the default) for the “Detector Downscale”. I did not try other values but will try this tomorrow.
We will try more testing tomorrow and will try everything on the field on Thursday.
I would try decreasing your detector downscale if you’re getting spotty detections.
@kdschmitz @icemannie @RyanShoff @Clayton_Yocom @vargoose84 @jdaming
2023.5.2 has been released. While the 2023.5.0 solver works well with complex layouts, it increased the rate of flipping in the single-tag case.
In 2025.2, the old solver is used for single tags, and the new solver is used for > 1 tags.
@jdaming Thanks for working with us.
@vargoose84 I want to personally test the new streaming on the field before we launch it. It requires a small Limelight desktop application and is not accessible via existing dashboards.
After working with Brandon on the new update everything is up and working for us. We will test at Central Missouri tomorrow and hopefully will be almost 100% autonomous unless defended.
I have seen 0 jumps behind the grid and the Loading station tags are now very beneficial. Looking at 2 tags is completely locked on and even just 1 tag has minimal jumping/ambiguity.
To get things working we are tossing any poses outside the field (shouldn’t be many/any) and anything more than 1ft from our odometry pose. Then we have buttons to override that limit.
^When ur behind-the-scenes-edit is still greater than anything I can make
Would you mind sharing the settings you are using in tour pipeline or are you ising multiple pipelines with different filters?
We are currently just using 1 apriltag pipeline. Here is the .vpr config file. You will need to rename the extension vpr.
MainTag.txt (1.7 KB)
We are using 960p and downscale of 2 since that is what we tested with Brandon. Haven’t tested if there are advantages to higher resolution or different downscale.
The last change I made to the code linked above to always trust the pose when two tags are seen really helped prevent the drivers from having to press the button to “recalibrate” (fully trust LL pose regardless off odometry).
For teams using Limelight’s MegaTag and Pathplanner with mirroring, what is the correct transformation to MegaTag WPILib Red so that it is compatible with Pathplanner since the field is not radially symmetric? Or is there another solution that is built into Limelight?
I haven’t tried it yet, but i think if you ise the blue version of pose it just works.
Yep, we just have a check when adding the vision measurement to choose either the red or blue pose based on DriverStation.getAlliance().