We’re working on an automated battery tester for offseason. One thing I’d like to explore is automatically identifying the battery (both in the test stand, and in the robot).
I’m thinking that RFID is the way to go: does anyone have any advice on some cheap reader/card combinations?
This was our first thought too, but it is in violation of R707 (“No other wireless allowed”). Short-range though it is, RFID is still, inarguably, wireless communication.
A passive NFC tag should not violate that as it doesn’t “wirelessly communicate” unless it’s in a pretty specific electromagnetic field (that’s very limited in power and range). Using the colloquial names here, an RFID tag similar to a key fob should be allowable.
Rules of course are rules, on the practical side the frequencies used by these devices are very very far away from interfering with FMS/ radios.
I think it’s because their system has a scanner installed on the robot to check the battery on startup. If you wanted to use this system then you would have wireless communication on your robot, so it would violate the rule.
That is correct, our goal was to track battery usage on-robot automatically, which requires that the system be on-board. While I agree that it’s unlikely RFID would interfere with anything, the rule sadly doesn’t have any exception for it.
QR/bar codes worked well, though do require a bit of thought to arrange in a way where the tags are visible to the scanner.
Just a question, why QR over bar codes, I know they support more data and are easy to set up with any random camera and a cheap potatoe but wouldn’t a bar code scanner be more space efficient and be able to be put close r?
The scanner we have does both and plugs directly into the Rio. Last year QR at a fairly large scale worked well because of where the battery was & available space to mount the scanner above it. This year with a 25x25 frame we were VERY tight on space and could only just squeeze in the bar codes in a place where we could point the scanner. In practice we had more bar-code read failures this year than we had QR scan failures last year even after we embiggened the bar codes as much as we could. That may be a function of still-not-optimal positioning or it may be that QR codes are just more error tolerant. Regardless, both clearly are viable solutions since all we need is a unique identifier per battery.
There’s a micro-USB port on the bottom side of the board. We cabled it directly into a Rio USB-A port. The scanner can be configured to present as a serial-over-USB device so it was pretty trivial to interface to in software. Our interface code is here.
The scanner is a little quirky to set up - it’s configured by scanning sequences of QR codes from its manual.
Fun fact: the board is just small enough to slip into a length of 1/16"-wall 1x1 tubing, which makes for an awfully handy way to mount and protect it. Just requires carefully drilling some holes in the tube for the pre-mounted threaded studs to slip through. We stood it off with an extra nut on each stud on the inside, so as to have the bottom-mount USB clear the tube.
We too would like a passive way to id the battery that does not require optics or any user input. I plan to follow up with the FIRST inspectors team to see if there is any way to allow “Near Field Communications” In my opinion and this could be wrong the R707 seems to be there to eliminate other remote controlled sources to our robots. If more people begin to request this then it could gain attention.