Enabling autonomous on the roboRIO over SSH (without a driver station connected)

As an offseason project, our team has created a electrical “testbench”, effectively an entire FRC electronics system so we can prototype and run motors directly off it. It has been working great, but the only caveat is that we have to connect a laptop and enable it through driver station.

I would like to enable the robot code over SSH so it will automatically start when it is powered on. It does not have to be FRC legal - I am not intending to use this on the actual robot. I have already located the batch script (/home/lvuser/robotCommand) that starts the code, but it still will not enable the code.

Does anyone know if this is possible?

Around work we like to say “It’s just software, anything is possible!”.

The key is that to remain in a nominally functional state, the driver station must continually send control packets to the robot. Getting around this would be problematic.

Have you tried to put your code in disabledPeriodic()? You won’t have control of motors and solenoids, but that would be by design.

Your robot code is already running on the roboRIO whenever it starts.
The problem is that the FIRST image requires periodic communication with a Driver Station app and an explicit Enable from that app. to get out of the Disabled state.
In the Disabled state all motors and actuators (PWM/CAN) are set to neutral.
So you can use sensors and other inputs, but no controlling motors without a Driver Station app.

That kind of defeats the purpose:

Your best bet for a workaround is to ditch the roboRio and replace it. The built-in safety checks are pretty deep, to prevent run-away robots… you probably aren’t going to be able to get WPILib running on the roboRio without a driver station.

as long as this isn’t going anywhere near a competition robot could you flash the offseason / HERO versions of talon firmware and achieve something close to what he wants?

What is your goal? Is it to do benchtop test of robot code e.g. with unit tests? I’m assuming the motors aren’t hooked up to anything so there’s minimal safety concerns? What we do for the WPILib hardware test platform is generate just the DS enable signal on the Rio itself. Code we use for this is here.


Hmm that code is interesting. I think I could compile that as its own thing to mimic those packets

Whoops, thanks, I jumped straight to the bold text.

My solution will not work toward the intended purpose.

TBH, I’d be at least a bit concerned about any configuration that energizes motion-causing devices without someone actively pushing a button to make it happen. OP, trusting you’ve covered the safety issues with this.

1 Like

Update: I was able to make it work by injecting some of WPILIB’s java code into Robot.java to simulate driver station enable packets upon the robot startup. I can link my code if anyone’s interested.


I’m interested, if you could provide the link.


@Mark_McLeod Did the hair on the back of your neck just stand up like mine did?


@dblitt, thanks. If I can key off what others may be hinting at…and I think I just realized myself…

Other than “against the rules”, what mechanism is there from preventing a team from starting the robot a second or two before the others, or keeping it going for a bit after the match?

And/or, is this a known vulnerability?

I suppose there’s always the point of “well it’s just software, of course there’s a way to do it”, but now we have a simple example of doing so. “An exploit is technically feasible” versus “Here are thirty lines of code that exploit a vulnerability” are two very different things.

We may or may not have just opened a can of worms.

This is nothing new. When we built an all-terrain wheelchair with FRC components in 2012, we had a similar thing running on the cRIO. Basically, it was just a subVI that constantly sent “driver station” packets to localhost that kept the cRIO in autonomous mode.

Ultimately, without some fancier security techniques (like signing each packet), there’s really no technical way to prevent this.

I believe that such an exploit would be obvious in the FMS logs, though, and obviously a team doing it in competition would be in very deep trouble.

Heck, QDriverStation has developed basically the same code, just not intended to run on the RIO itself.

The primary mechanism for preventing doing something like that is that it’s against the rules, and operating outside the time limits of the match is pretty visually obvious and will get a lot of attention paid to the team/robot very quickly. As Carlos mentioned, the ability to do this has existed since the inception of the cRio system in 2009, both at the DS side and the robot side. Cheating of this sort has not been a problem to date, and I would hope we have not changed so much culturally that teams would be tempted to break safety protocols to cheat so obviously and egregiously in a high school competition with no prize money at stake. There are many other, more subtle ways teams can break the rules to gain a minor advantage, and they choose not to do so not only because it’s against the rules but it’s also at odds with FRC culture (gracious professionalism).

In case it wasn’t clear, I want to reiterate that this should ONLY be used for things like benchtop testing setups when there are no moving parts/pinch points. If you implement this, the only way to stop motors from turning is by physically unplugging their signals or power. A safer way to do this would be to run the code on a separate processor like a Raspberry Pi with a simple switch to turn it off and on.


Thanks @Peter_Johnson - super reasonable response.

This is where I was going in my head. Security would require having some component of the valid enable packet be impractical to generate during a match (Not-open-source portion of code? Generated dynamically at match time?).

I had used qDriverStation before, just hadn’t thought through the implications of putting that inside the RIO. In any case… thanks for entertaining the discussion!

By allowing open programming, especially on a standard Linux system, it’s basically impossible to block all (or really even any) methods of bypassing the security mechanisms. I can think of probably 10 different mechanisms for bypassing security, especially with CAN controllers, all without any source code access, or even needing to reverse engineer any of the security mechanisms. But, as said above, anything done would be extremely visible on a real field, and I hope that teams understand that the security features are both for safety as well as fairness.


I can imagine there are some uses that are not exactly obvious on the field. One that comes to mind is keeping motors or other actuators/pneumatics active when the robot is in its end game climbing state. If done well, the only really obvious thing would be the difference in the RSL. (edit: even the RSL is quite easily bypassed with a relay and a lazy robot inspector or a quick change after inspection and before the elims inspection.)

Code is at https://github.com/Team-5176/testbench. I added the FakeDS class and call it in Robot.java

1 Like