Can you share any details about how the limelight 3 factory calibration works? Are units individually calibrated? If so, what’s the test setup for that like?
Hello,
I have been having issues working with one of my team’s new Limelight 3s. We have two on our robot, one is working well, detecting april tags normally the other is extremely blurry with no april tags being made out by the algorithm. I have tried all of the settings and tried cleaning the lens to no avail. This unit may have been dropped or hit something, I am unsure. I was wondering if there was a way to refocus the camera or if this symptom is indicative of another, deeper issue. Below are images attached of both the bad and good cameras. Any help would be appreciated.
My apologies if this post needs to be moved to a new thread, I am inexperienced here.
Thank you,
sckzor
The poorly performing camera:
The normally performing camera:
My limelight v1 looks like that and I can’t recall it being dropped, but yea I think the camera or wire going to it might be damaged…
That looks like the lens is out of focus - you could try moving it closer or farther from the camera to see if it makes a difference
@Robosquatch76 Yes, I should have an update on Monday.
@sckzor We will overnight a new one. Sent a DM.
We are running the newest OS on our limelight 3 (limelight 2 had the same issue) and when we see ID 5,the megapose suddenly moves into the driver station. As you can see from the image, the pose derived from 5 (the right green cylinder) and the simply derived botpose are both accurate, whereas the megapose is nowhere near them and it flickers around.
This only happens when ID 5 is being used, megapose works well with any combination of IDs 6,7, and 8. The problem only gets worse if we move farther from the targets. Any help is appreciated!
It happened with ID4 at the opposite end of the field for us. Does megapose require tags in the same plane and not offset back like these 2 are?
We are currently excluding tags 4 and 5 from the filter list until this gets fixed.
Google Coral is now supported by all Limelight models.
I believe so.
@Brandon_Hjelstrom FYI we’ve seen this behavior too, especially prevalent when doing hp load side autonomous modes.
@Robosquatch76 Friday 11AM PT
@kdschmitz @icemannie @RyanShoff @Clayton_Yocom working on it!
How does one utilize this? When I navigate to limelight.local:5800 does it default to h.264?
FYI SeeedStudio is starting to accept backorders for Google Coral USB Accelerators. Available early May?
@Brandon_Hjelstrom bumping this.
Also wondering if there’s an ETA for the fix for this jitter
Also interested in an ETA? We are seeing okay results with just the grid tags but a lot of wild results when we don’t disable the loading station tags. It seemed like 973 had things working at CVR at the loading station, but maybe that was just really good driving.
@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.