Kim's Rambling | Dirty Tricks To Minimize FRC Downtime & Iterate Faster

So I won't beat around the bush. Some of this is very experimental, some of this may not go the way you expect it to for a few reasons. This really is intended to affirm the mediocre-technical to highly technical FRC mentors and students who know what you're doing. Don't do this blindly, please. It can make your competition experience wildly worse.

Not all FRC batteries are made the same. We legally have 18-20Ah 12V nominal, SLA batteries. This means they can, in theory, produce approximately 18-20 amps for an hour of normal runtime. We of course draw thousands of amps out of them lasting several minutes if we're lucky. For this reason we really want to choose some top notch batteries. This was true with 16 PDP ports, it'll be true in the 20 PDP slot era.

Some teams even had terrible experiences with the 2019 Kit of Parts battery, and many have echoed their experiences off site. Moral of the story? Call MK and get batteries from them. Beak all of them when in hand, and avoid using batteries used the most recently. Set aside the less good ones for practice (if your drive team can score with poorly running batteries, they can score with better running ones.) These batteries have a finite lifespan, after all.

This dumpsterfire of a radio has given plenty of teams problems over the past few years. They take forever to boot, so the big tip for these is to use redundant power. 2020-R47 says that your radio must be powered by the VRM 12V 2A port, and that doesn't preclude the use of redundant power. Using a PoE injector in conjunction with the barrel jack to connect the radio to the VRM's 12V 2A ports ensures a faster recovery in the event of a disconnect. How does this work out though?

If your Ethernet to the radio gets disconnected, the power stays on, so when it wiggles back or whatever it's already resumed. If your barrel jack wiggles loose and pops out, there's no interruption to use. The blue box on 2020-R47 specifically states that

"that this prohibits using any active POE Injector device to power the radio, but does not prohibit using any PASSIVE CONDUCTORS to inject the VRM power into an Ethernet cable plugged into the radio port labeled “18-24v POE”."

Static networking isn't recommended for a lot of teams. The need to understand field, and at-shop networking can result in difficult to manage situations. It can even result in inxperienced field staff giving you blatantly incorrect information if you don't know how to rebuke it. However, the ability to connect to the robot even faster in the event of a reboot, and skip the need to get a DHCP lease, as well as mDNS to re-connect to talk to stuff, is a speed boost that can mean the difference between winning and losing that stressful match.

The WPILib Docs outline the commonly used IPs for static networking here and here, but be wary that this isn't the reccomended configuration. In the event you set your roboRIO to an IP other than the suggested one (10.TE.AM.2) you can type an IP address into the team number box directly to connect to it.

The other issue for this radio involves the two Ethernet ports on it. The issue is that the radio doesn't physically have them on the same "switch", they're bridged in software, and as we all know, software isn't perfect. Sometimes the bridge between the two ports can fail, and with no easy way to reboot the radio itself on the field, it can be a recipe for disaster.

The easiest thing to do, is of course to do nothing. Many teams will never run into this issue as their entire "robot network" is the roboRIO and the radio; nothing else. In the age of Limelights and copious other piles of networked devices on robot though, a network switch is a good idea.

Placing a switch between the roboRIO and radio may impede the ability for FIELD STAFF to troubleshoot roboRIO connection issues on the FIELD. Teams may be asked to try directly connecting from the radio to roboRIO as part of troubleshooting efforts.

The easiest way to properly mitigate this is to purchase a stable, reliable network switch. Luckily, 900 has already pursued that knowledge in trying to connect Jetsons and Xaviers to their robot network galore. The ZebraSwitch paper covers basically all you need to know about their choice of switch, and their reasoning behind it.

Because the field network doesn't behave like your shop network, and you'd likely want your drive team to practice driving in hostile network environments that make scoring difficult, you want to recreate those to an extent.

Clumsy makes that possible, and has options to induce latency, drops, reorders, corruption, and more. Adding some latency and re-ordering should more than approximate the field network during those situations when you really should get a replay but won't.

If you're clever, you could even configure clumsy to only effect your Driver Station packets, your camera, or something else entirely. As a word of caution though, be sure this isn't installed on your real driver station laptop or you might leave it on by accident on the field network; a potentially disasterous scenario for your team.

NetworkTables is how WPILib and FRC hardware tends to move data around, for better or worse. That said, it can be an effective tool to change real-time variables on your robot for tuning control loops without needing to deploy more code, speeding up the iterative process itself.

WPILib has a PID widget for dashboard tuning, but this only really works if you're using the WPILib PIDController, not if you're using motor controller-side PID, like on the Falcon 500, or a Spark Max. What do you do then?

Through use of the SmartDashboard items of getNumber(); and putNumber(); you can check every loop if the stored local value is different from the remote NetworkTables one, and if so, change the PID value locally respectively, and configure your motor controller again. That also works for your setpoint so you can go between your test values fairly quickly. With that, a task that may have involved redeploying your code entirely now only takes a few seconds.

I'm not covering this super well, I'm not a mathematician. All I'll really say is to follow the docs, and in the event of any major robot changes (like adding / removing mechanisms) you likely want to redo the characterization of your whole robot, and for specific mechanisms, changes there probably want / need to be re-characterized.

The FRC landscape is changing lots every year, this may be inaccurate by the time it's widely circulated. But hopefully it's of some help to you.