Buttons

[truher]

We use the RoboRio reset button because rebooting the RoboRio is much faster than rebooting the old radio. Would it be illegal to add a switch to allow power cycling the system core by itself? Does the new radio boot faster than the system core?

[Kevin-OConnor]

No, SystemCore boots much faster than the VH-109. What are the use cases for needing hard reboot (button or power cycle) vs a soft reboot triggered from DS (or something we could add to the web interface)? Our internal discussions so far have not come up with a ton of cases where this should be necessary?

[truher]

Well, I admit this isn't a topic we've really investigated. Sometimes the DS "reboot" button wouldn't work, so we'd push the hardware button, which would work.

IMHO it would be really good for there to be just one user-action that achieves one very simple thing 100% of the time. The current situation involves two buttons in the DS ("reboot" and "restart code") and two hardware buttons ("reset" and "user") and TBH nobody really knows what any of them really do, and nobody wants to.

[truher]

I was reminded by the CD thread that the most common scenario for us is e-stop recovery.

[j0n5m1th]

The Roborio reset button is sometimes used on the field to troubleshoot getting a robot connected to the field. Situations like this are time constrained and usually don't permit a full robot power cycle / the DS can't reasonably trigger a reboot in this scenario.

FTA(A)s / CSAs may have some more thoughts on this.

[gerth2]

Our internal discussions so far have not come up with a ton of cases where this should be necessary?

Our usage as a team varied over the years. The two main usecases I know of are accidental ESTOP recovery, and user code having functionality in robotInit() that really should have been elsewhere.

Estop recovery: Since the driver station estops even if not active, it does mean that someone multi-tasking on the driver station laptop will trigger it. This is less likely during driver practice, but fairly common while doing software development.

How frequent it happened to us over the years actually depended on Software team size - if you're on a "one student" scale, it's highly likely the same laptop is being used for sw dev and driver station, so accidentally triggering an estop is pretty common (drive a bit, forget to hit disable, flip back to vsCode, type a space). On the other hand, it's less frequent for bigger teams - as long as you always have the person driving being different than the person typing the code (and two different laptops), it's less likely to be needed.

User code issues: These are theoretically fixable, but even with 10+ professional software mentors it took us a long time as a team to get disciplined to write code to robustly handle re-enabling autonomous many times during runtime, as well as handling all possible paths code paths between disabled/teleop/auto. There is theoretically always a solution here, but it took a lot of thought and investment to handle this as a development-only requirement. For a more resource-constrained team who is just starting to get more advanced features, they'll likley only hit the minimal requirement of handling disabled->auto->disabled->teleop->disabled . Which, in turn, implies that robot code has to be restarted each test run of auto. Or possibly before enabling teleop, every time. If there was no code redeploy, the reset button was the easiest way to do this. Especially if you had mechanical team just standing around watching - "Hey, want me to reset the code?" "yea sure!" was a common exchange.

To be clear - I'm just putting sample points out there. Both of these pain points that a physical reset button happened to address - but there's other ways to address the pain point.

Estop recovery: "Redeploy code" is a "reduces occurrence" strategy, but not a general solution (think, during driver practice or while at a demo event - possibly no software person there actively deploying code). Power cycle whole robot might be feasible, but it assumes there are no other components on the robot that take longer than the systemcore to boot up. Possibly true today, maybe not true tomorrow? Just a probabilities game :).

User code issues: "Fix your code" is probably unrealistic, your developer base is perpetually a group of high schoolers who just learned to code a year or two ago :). Same note for full-robot power cycle above. A robust driver station button to at least reset user code might also work.

[bherbst]

My primary use case as an FTA (particularly in 2025 for some reason) was resetting rios that simply weren't booting correctly on the field. There was a somewhat more common than expected failure mode this year where the rio simply didn't seem to boot correctly which would make using the web UI to perform a reset impossible. Really happy to hear the boot times for SystemCore are much faster (and excited to see that in action myself once my team gets it set up), but in these types of scenarios doing a reset would require a full robot power cycle including the radio (which is of course not as fast).

I also acknowledge this was definitely some sort of bug so in an ideal world this wouldn't be a necessary use case. But things happen.

[kenschenke]

Longtime FTAA here, adding to @bherbst. The physical reset button can be a huge time-saver on the field. The typical scenario is that we are on the field with the drive team and the robot isn't booting correctly, won't connect, code not loading, etc. It is much quicker to hit that reset button than to walk back off the field to behind the driver wall and reboot the robot from the laptop and much quicker than power-cycling the robot.

[kevinwang]

As a data point, I tested the reboot time of SystemCore via the "reboot roboRIO" button on the DS and consistently got 35-36 seconds with a blank project. Not sure off the top of my head how this compares to the roboRIO.

[cpapplefamily]

After my first look at the SystemCore hardware last night I wonder if it would be at a minimum possible to add a paper clip reset button to the LCD board. If so, then as a CSA a SIM card tool may become a standard tool on my keychain

[FletcherS7]

The reset button on the roboRIO is extremely useful when troubleshooting connectivity issues in cases where the robot radio is linked, but the roboRIO is not. Its also helpful to in cases where code is hard crashing preventing the DS software from talking to the roboRIO.

The main reason to include a reset button on SystemCore would be to avoid full robot power cycling in cases where a reboot cannot be preformed from the DS software.

In additional I think the inclusion of a user button on SystemCore would be also be valuable, I am aware of several teams who use the user button on the roboRIO to set the robot for a match as an alterative to a full power cycle to re-zero everything.

[juchong]

@Kevin-OConnor:

What are the use cases for needing hard reboot (button or power cycle) vs a soft reboot triggered from DS (or something we could add to the web interface)?

• Rebooting the controller requires an active connection to a PC. Any lock-ups, connectivity issues, or misconfiguration (changing a port, firewalls, etc.) will impede low-level command & control.
• Accounting for all corner cases is extremely challenging. The hardware button is a failsafe that will always put the controller into a known state.
• Hard-rebooting the robot (turning the main breaker off and on) will always incur at least a 60 second field delay since it takes about that long for the radio to boot and all the robot subsystems to reestablish communication. If, for some reason, a full robot reboot is required to put the controller into a known state, many events will wind up woefully behind schedule.
• Forcing a reboot of all robot subsystems also increases the likelihood of subsystem networking issues. LimeLights, RPis, QuestNav, etc. may not recover after a reboot.

Our internal discussions so far have not come up with a ton of cases where this should be necessary?

?!?!