Running arbitrary programs on the RIO

How can I run an arbitrary executable on the RIO by default?

Say I have an executable, compiled for arm-unknown-linux-eabi, ready on the RIO. Where can I place it so the DS tries to run it automatically?

I have been reading the Gradle deploy script from WPILib, and it seems that it:

  1. /usr/local/frc/bin/ -t
  2. Deploy the program to /home/admin/myRobotCpp (if it’s dynamic, my executable is)
  3. sync, ldconfig, chmod +x

But I have tried this on my own executable, and the DS still says “No robot code”, and my RIO’s comm light is solid red.

I can SSH in and run the executable successfully. Any thoughts?

I just ran the WPILib VSCode template Java RobotBase. I slightly misunderstood what it was doing so I complained to the developers. They were kind enough to explain what was the design and discouraged me from using it. But it does work fine and you find out all the good stuff iterative or commandBase does for you and now you have to do it.

@Peter_Johnson or @Thad_House maybe?

1 Like

Sorry, just to clarify, I’m not running a program written in Java/C++, nor is it from the help of WPILib’s Gradle tooling system. Let’s say it’s an arbitrary “hello world” that compiled to the RIO’s architecture.

Yes they are they helpful gang!

You might need to write to /home/lvuser/robotCommand. This is how we are doing it with bazel:

This may be outdated, YMMV. What roboRIO image are you on?

1 Like

You could look at that template and see the statement that enables the robot. Maybe you can call WPILib stuff from your program. That’s assuming you want to do the easiest way to run an arbitrary program which is what I wanted.

If you are blowing up the framework that WPILib/NI has provided then others will have to help. I only know how to use the robot base which does solve the problem of communicating with the DriverStation and keeping the WPILib motors and actuators going.

Thanks, but I tried this previously, too :slightly_smiling_face:. I’m on 2022_v4.

Thank you, but I’m moreso interested in the deployment process rather than the architecture of WPILib.

Try bash -x /usr/local/frc/bin/ - should show you what the robot is trying to do.

Note that your executable will have to do specific stuff to convey to the DS that it’s running; the Robot Code light means “the robot is communicating with the driver station using the expected protocol”, not just “some code is running on the RIO”. I think the comm light is controlled by FRCNetComm, but I wouldn’t swear to it.

The bottom line it, if you’re not even using FRCNetComm, you’re going to have to do a lot of groundwork to make the RIO and DS behave like you want them to.

1 Like

I get a handful of unrecognized characters for my terminal emulator. But, it exits successfully.

Interesting, I didn’t know that. Fortunately I have access to all of WPILib, including FRCNetComm. I’ll keep this in mind, but I still don’t know where the executable should properly go.

The RIO is a Linux variant, so you can run any program you want to. The robot code program is started by LVRT running, which runs a deployed shell script (/home/lvuser/robotCommand), which runs the deployed executable. Deployment is generally done to /home/lvuser instead of /home/admin. However, you can alternatively use an Linux init.d script instead if you want to just independently start it at startup and not be hooked into the rest of the standard robot code deploy/startup infrastructure.

As Carlos stated, if you want the “Robot Code” light to turn green, you must use the NetComm API to do so (NetComm is a separate daemon process that talks to the DS to tell it that code is running).


When you deploy a robot project normally, it shows all the ssh commands that are ran on the device and which files are copied. That can be used in the future to help you figure out files.

But as said above, Peter is correct about the directories, and Carlos is correct that you have to tell the ds robot code is actually running though netcomm. There’s apis in the Hal to do this.


Thank you, that answers my question.

What can I call in the HAL to do this for me? Just out of curiosity, because in this program it’s more sensible to use the HAL than directly interface with NI’s libraries.

That’s the full sample with everything that needs to be called. Note we don’t guarantee Hal api or abi stability, so you will need to recompile every update, and potentially change your code every update (this rarely happens, but we can and will without warning)