Haven’t seen a post about this, but I’m curious to hear everyone’s thoughts on the mods. I’m particularly interested in hearing past inspector’s comments on the modifications.
Obligatory IANARI (I am not a robot inspector), but at this point I think a print out of this should be included with the kit of parts, and teams strongly encouraged to perform both of these modifications.
There is nothing less inspiring than watching your robot sit idle waiting for the radio to reboot during a match. We take care to mount our radio to prevent these issues, and ensure the use of redundant power to the radio (both barrel and POE power sources), and have avoided these issues, but every time I see a radio killed robot, I feel for the kids who worked so hard to get to the field only to have to deal with a required part of questionable suitability for this application.
This is legitimate. Internal shorting is a known cause of radio reboots in rare circumstances (although a dodgy barrel jack / bad mounting is multiple orders of magnitude more common), but I can’t say I’ve encountered the reset button one
I enjoyed the legality discussion. I will pose a counterargument.
Exception M of the R72 allows these components to be repaired “provided the performance and specifications of the device after the repair are identical to those before the repair.”
The strange behavior of the radio to trigger its own reboot when the enclosure is pushed a certain way is not a design feature. The behavior is certainly not described in the manufacturer’s performance specifications. Instead, it is a serious flaw to be corrected via a repair. Our repair restores the functionality of the device and enables it to perform per the manufacturer’s performance specifications. In this way, our repair meets the R72M exception and is legal per the 2018 FRC rules.
MB’s argument claims that the behavior is not described in the manufacturer’s “performance specifications.” Let’s separate that. “Performance” is different than “specifications” (note the AND in the R72-M quote.) Let’s start with “specifications.” The datasheet does not mention that the radio reboots when pressed a certain way. It also does not claim that the radio should not reboot when pressed a certain way.
From the OM5P-AC product page:
this access point is ideal in dense environments with a large number of access points, such as hotel rooms, apartment complexes, dorm rooms, care facilities, restaurants, retail stores and offices.
I think with the intended use cases (note that they do not list “robots” as an intended environment) a certain amount of instability in dynamic environments can be reasonably foreseen. I conclude that “does not reboot when pressed a certain way” is not a part of the expressed or implied specifications of the device. Because the specifications have changed (are not identical), the device is no longer legal.
The “performance” of the device is a separate issue (recall that both performance AND specifications must be identical to the product in its original state.) I think you would have a hard time arguing that the performance is the same as before the “repair,” given that the purpose of the “repair” is to improve the performance under dynamic conditions. I conclude that the performance of the device is not identical to before the repair. Because the performance is not identical, the device is no longer legal.
What about case flexing, though? I’ve seen many radios mounted on polycarbonate sheets that are much more susceptible to bending and flexing rather than when mounted on aluminum (as an example). It’s easy to envision a scenario where the radio is tightened using zip-ties and becomes much more likely to reset itself due to the stresses imparted on the case. A single zip-tie around the center of the radio would significantly increase the chances of brushing up against that reset button. The same goes for stresses imparted on the RJ-45 connector end of the radio. If the Ethernet cables are constrained in just the right position, it’s very easy to envision a scenario where the contacts would short to the heatsink material in the radio.
I’m all for preventing radio resets, which is why I bring a stock of POE cables with me to events. I would want to see official verification (Q&A?) before implementing such a change, though. As an LRI, I wouldn’t want to fail a team that did this, but at the same time I don’t completely buy the legality argument. There is no doubt that this is a modification, and no doubt that it changes the behavior of the device, given the ease of repeating the issue across numerous off the shelf, unmodified devices, even if that behavior isn’t documented. Showing up with this change would put me in a very difficult spot, if there was no prior ruling from the GDC on it.