In 2016 FIRST gave us a new radio which has a caused significant issues for teams in both Stronghold, and Steam works this petition: www.change.org/p/don-bossi-new-radio-for-first-robotics. Together we can help FIRST find a new radio for FRC. Listed below are some of the issues with the old radio and the requested features of the next radio.
The Problems with the OM5P-X radio:
-Reboot takes more than half a match
-Only has two Ethernet ports
-Power plug falls out too easily
-OM5P-AC radio has a spectrum issue where some events almost required teams to use only last years radio (OM4P-N).
-Runs on 12 Volts
New Radio request features in order of significance
– FIRST’s mission & vision statements describe how they are about more than robots. I do see your point about how the loss of a match is non-trivial, but the specific dollar example may not be the best way to make your point. Perhaps hitting more on how the loss of a match due to frustrating problems can be a deterrent to inexperienced teams and students alike, which limits FIRST’s scope?
–Does anyone have ideas of what specific radio model they would like to use? I see the suggestions from years past - do any of these apply?
I think we should move away from Wi-Fi as a primary communication channel for robot signals. Keep it as a secondary channel for camera communication or something, but not for drive commands.
Wi-Fi routers as COTS products are not designed for the shock loads FRC robots regularly experience. They are not designed to quickly boot as they have no need to in their intended application. Configuring these radios is time consuming. And obviously, they are to some extent vulnerable to hacking and abuse as anyone with a phone has a device that can communicate with them.
There are numerous fast and robust solutions (but not cheap) for mobile vehicle wireless communication in the industry. Many of the companies that make them sponsor FRC. A serious effort should be put in to come up with a system with more robust communication that meets the actual requirements of an FRC robot.l
We were ranked 3rd at District Champs until our radio half died (would work for a minute or so, then start rebooting). We lost the next 2 matches and dropped to 19th until we figured out we weren’t browning out and the cable wasn’t loose. It took 2 matches and help from the FTA to figure out the radio was partially working. Bought a new one and it went through Worlds just fine. But it cost us going to playoffs at District Champs.
We also had a radio die last year when we hit one of the defenses. Robot was dead in the water and we had to buy another one.
When my kids make a mistake, or luck bounces a ball out of the goal, these things happen. It’s part of life that sometimes things don’t go your way. But when we lose matches because of crappy hardware, where FIRST requires this single manufacturer, it is extremely frustrating as a team. I have heard many first hand reports of broken radios. FRC is plenty hard, we shouldn’t have substandard parts that fail at random intervals.
For the record, “Clip based power jack” and “PoE” and the same thing. I still don’t understand why some teams are still using that crazy unreliable barrel connector when the radio has PoE.
Also, I don’t see that you have added any suggestions for new radios. As some wise man said, “Don’t complain about a problem unless you have a means of fixing it”. Anyway, just thought I’d bring that up.
Signed. A petition delivered to Don probably isn’t the best way to get this change enacted, but it can’t hurt.
I think it’s important to note that a lot of the robots that die on the field are actually caused by problems upstream from the radio (e.g. main power wiring, weidmullers not connected correctly, breakers not seated correctly). That being said, fixing the listed problems with the current router would help with the problems that are actually caused by the router and allow teams with other problems to reboot faster and still spend less time not moving. My comment along with my signature:
Though I know a lot of the dead robots on the field are directly due to faults with the radio, having a faster boot time, a better-secured power connection, and radios with at least 2 working ports (OM5P-AC only had 1), if not 3+, would definitely help resolve these issues.
A lot of these problems would be solved with either a way for the RoboRio to inject POE for the radio or putting wifi in the RoboRio. If changing it would be to difficult, having CTR or someone come up with an approved POE injector that could go inline would work as well.
Its definitely a discussion we have had as mentors on my team, and Id love to see an improvement. I have a few ideas but they have some costs associated with them
I haven’t heard of any teams having issues with weidmuller connectors when they were used per manufacturers instructions (i.e. properly stripped wires or properly crimped ferrules). I did see issues with improperly terminated connections, i.e. tinned wire, over-gauged wire, or ferrules smooshed with pliers instead of crimpers. What issues have you seen/experienced with weidmullers that were implemented properly?
More features, presumably more rugged construction (why would you leave this out?), and better performance at a lower cost? Come on…
Although you may never have problems with those Weidmuller connectors, other teams do. Mainly through making mistakes with them, pushing too hard, poorly stripped wire, etc.
Why defend the crappy Weidmuller connectors when we all know that the Wago-style connectors have been significantly more reliable, and have been in use in FRC since 2009. Obviously there’s cons to both solutions.
But the Weidmuller connectors just are not designed to take 18AWG properly, it really is the max wire size you can put in, and it’s required by the rules.
You can always make the argument that people don’t use the Weidmuller connectors as instructed, which is true. But even if you follow the instructions, they are extremely fragile, and easily broken.
Considering this topic is about a less crappy radio, let’s keep the Weidmuller talk for a separate thread.
I am all for a better radio, I really don’t like Open-Mesh or their products.
Generally speaking, the roboRIO takes slightly longer to reboot and get code running than the radio does. If you move the wifi to the roboRIO (ignoring this requires a rework of the roboRIO), you’ve only solved the problem if the radio is the sole problem.
In many cases, it’s upstream. You’ve asked for a large R&D rework and shifted the problem. In reality, a minority of the problems would be solved with this implementation.