I work for Amazon, and I noticed that throughout the process of getting a package from our Fulfillment centers to your door, there are a lot of QR and Bar codes along the way. Because at its core, Fuffilment and Shipping is a pick and place game (with a lot of extra steps) why don’t we see more Bar Codes in FRC?
I know here, our Drive unit robots use floor mounted Aztecs to tell where they are on the floor, and figure this could be quite useful in an FRC environment. Thoughts?
I think the AprilTags on this year’s field are an example of this, Some teams add their own to other parts of the field like the substation
While I think April tags are a step in the right direction, I think many more smaller Aztecs on game pieces or player stations, or the floor would be an interesting and exciting new way for teams to create ways to automate their robots.
I know it’s not the same, but I saw team 6328 use QR codes and later barcodes to track batteries, which is SUPER COOL.
That is actually super cool, I wonder what kind of inventory management system were they using in conjunction with the codes?
I believe it was pretty basic, just making sure they used the one that had been charging the longest. They also had a bit in robot code to flash a warning on the LEDs if the battery hadn’t been swapped.
You shouldn’t really need them is the thing, apriltags with multipoint solve is extremely robust for telling a robot where it is when you add a pose estimator to fill in the gaps, and for game pieces it would cause chaos when the labels get scratched scuffed and marked, ML models will likely continue to be the only robust method of finding game pieces with enough error tolerance to be reasonable usable in high automation situations.
This is why we need RFID.
We haven’t decided if it is good or bad yet, maybe we need a whitepaper
We manage an open source scouting system that uses QR codes for data transfer:
Basic, yes - we record the battery ID (typically it’s just a year and number, e.g. 2022-001) in the logged data for the match. That way if we see any possibly-battery-related issues, we know exactly what battery was in use for that match, without relying on the drive team manually recording it in the heat of match prep (which, realistically, doesn’t happen). And we can detect recurring issues with a battery that could indicate a failure.
Across the season we can also look at things like how often each battery got used, e.g. did we do a good job of rotating batteries through as we try to.
Yes, the LEDs are the most visible, but we also use our custom Shuffleboard alerts plugin to tell the drive team explicitly that the battery hasn’t been changed. In practice our crew is usually very much on top of making sure the battery is changed, but these help head off human error when something unusual is happening and folks get distracted.
Assuming we have sufficiently numerous and reasonably placed tags… which given the limitations of the chosen tag family is difficult.
The tags on the field this year were fine with the tag family allowing for far easier processing, not to mention if you want full localization you should have cameras in every direction but for most teams a front and back would have been fine with a pose estimator, it would only really be an issue if you didn’t blend any real time sensor data with the tags.
We found them lacking. The false positives were insanely high and their limited locations often meant occlusions or obstructions.
Teams shouldn’t need to run 2 or 4 cameras to make use of this stuff. I’m seriously hoping the feedback that FHQ received leads them to changing the tag family and add other options for landmarks to the field.
From what I’ve heard about apriltags, optimal placements would be around the field on the barrier / some other open location where teams can localize to the field right? To me in my, very much limited experience and observations, it looks like they were trying to use apriltags this year like retroreflective tape rather than, well, apriltags.
They were putting AprilTags where the highest precision of movement was needed. Which was fine for that purpose but not for full field localization.
Sorta, though the computational costs of that many cameras gets to be annoying quickly unless you’re distributing it across multiple processors in which case… it’s more involved.
But either way if you want to do full field localization the tags were inadequate. The big issue was that most of the tags were coplanar, the fastest way to increase pose accuracy is with multiple tags at different angles.
More tags in more places. Let us localize with them instead of the far more difficult version of recognizing field elements and localizing based on that and a particle filter.
6 coprocessors 
2 network switches and auxiliary power to keep systems running in case of brown out.
Floor Mounted seems very difficult to maintain, especially in a game like rapid react which was eating through carpet like mad (I don’t think this was as much of an issue this year although I may be wrong). However, even if robots aren’t burning through the tags, it would still be difficult to mount them securely enough to not get pulled up or move, but still be able to pull them up relatively easily at the end of an event. Of course if we went back to the regolith floor…
Look, if I wanted to run a data center I would. If you have more processing power than my car on a robot I question what’s going on.
Now back to my search for a reasonable cost large frame image sensor…