I was thinking about the possibility to put a NFC tag on each battery and a NFC reader on the robot battery area to track the usage of each battery. However, it is my understanding that NFC uses RF. Even though it only has a few inches, if even, of range, R707 seems to state that this would be disallowed. Am I interpreting this correctly?
Could you not use the battery beak?
Are you thinking about using NFC on the robot to read what battery is installed? Or having a tag on the battery that gets scanned at your charging station to track data?
The first I don’t think would be legal because of R707 (like you pointed out). However the latter I think would be. The tags themselves aren’t powered/communicating until a scanner is in range to provide said power, so nothing would actually be communicating wirelessly during a match.
I think as long as the NFC tag is passive / unpowered on the actual battery this is probably fine. That said, consider using something like bar codes or QR codes or some other system if you can, as those would be more likely to pass.
What’s the use case?
Do you want the bot to automatically recognize and log the battery used?
6328 uses a QR code reader and a QR code on each battery. Here’s a brief summary of how it works and how it’s been used from our build thread (towards the bottom of the post):
The overall goal of this thought was to log the wear of the battery on the robot
The original thought was to have it on the robot.
This is pretty cool, thanks.
At one time I think @marshall was interested in having the robot identify the battery by the battery’s discharge characteristics, which I thought was a neat idea. Not sure if feasible.
Ehh… kinda. We wanted to identify the battery onboard the robot. The best method I could come up with that is competition legal is some kind of barcode scanning camera setup (note: not a barcode scanner that would contain a laser that is not of the legal variety).
We are definitely still investigating battery charge/discharge characteristics but I don’t have much to share at the moment.
I wonder how using something like a colour sensor and a large sticker of varying colours on each battery would work? How many unique colours/stickers could you make (one colour per battery) while maintaining a reliable detection rate from the colour sensor?
Seems like it would be a rather simple option without the need for a camera/barcode scanner. Again though, just a thought. I have zero idea on the real world feasibility of said idea.
That is what ours is. It’s a packaged scanner that talks serial-over-USB and has a built in white LED to illuminate the QR code. It is small enough to tuck into a scrap of 1x1 tube for protection. We read the battery tag at startup with our handy BatteryTracker class and store it in our log. In combination with other statistics that we collect, this has enabled some interesting analysis.
The advantage of this approach is that no one has to remember to scan the battery. And if the installed battery doesn’t have a tag, or it is blocked, or anything else goes wrong with the scanner, the code continues with startup anyway (of course).
A recent enhancement tracks the “last used” battery and will warn the drive team (through our on-robot LEDs) if it has not been changed before the next match. While we normally have pretty good process around between match activities, this is just one more mechanism to avoid a mistake.
How many distinct colours can you have?
With one sensor, you have N combinations. With two sensors, you have N^2 combinations. With three sensors, you have N^3 combinations.
With just a few distinct colours, you can track quite a large number of batteries if you are willing to install more than one sensor. The sensors can be spaced and the top of the battery is pretty big so it should be possible to space out the stickers and sensors so they don’t interfere with each other.
I have seen this scheme used on an FLL robot to detect the manipulator mechanism that was installed during a “pit stop”. Thus, it would choose the appropriate program/routine to run. Usually, the operator has to manually choose the proper program to run after installing the corresponding mechanism.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.