Arduino or Pi 4 Replacement for RoboRio?

Hey everyone! My team has been working on a marketing bot this summer with the goal of hosting little demo events. It’s just a chassis with some standard FRC electronics, PDP, SparkMax motor controllers, NEO 550s, etc, and we were hoping to control it via an Xbox game controller. However, we don’t currently have a Rio we can substitute for this bot and are looking for alternatives. We have a lot of not yet purposed Arduinos and Pi’s lying around, and were hoping to use them for this bot. What would be needed to replace the Rio, and how could we effectively make the chassis run on an Arduino or Pi?

1 Like

From my understanding you could use arduino with wifi or a pi in some way. I just don’t know how, but I do know you can connect in some way. Just make sure the logic voltage is correct and you will probably have to use the rest of the control system for everything else. I have also been looking into esp32s, but if you have the arduinos/pi you should use that. :slight_smile:

I have done this on one of our old robots the following way.

Use a rasberry pi as the controller. Hook up a servo hat to give PWM signals to the motor controllers.

Adafruit 16-Channel PWM / Servo HAT for Raspberry Pi - Mini Kit : ID 2327 : $17.50 : Adafruit Industries, Unique & fun DIY electronics and kits

I then used a wireless USB controller and plugged it into the PI. USB Wireless Gaming Controller Gamepad for PC/Laptop Computer(Windows XP/7/8/10) & PS3 & Android & Steam - [Black] (black) : Video Games

It does not have all of the safety bells and whistles of a real driver station. If it looses connection at a bad time when others are around then it may not act correctly. There is no e-stop button… So use at your own risk.


I’ve gotten the wpilib stack to run on an old Dell N3040 thin client, a Jetson Nano and an Atomic PI.

I am sure it could be made to work on a Pi.

I don’t have CAN working, but I do have serial so far. I just don’t have any CAN devices to check.

It has driverstation support.

Good for you. A few things:
(1) CAN bus is going to be the hard part of that. There are CANBus hats for the PI, but interfacing that with any CAN devices in the FRC ecosystem is going to be non-trivial.
(2) Raspberry PI does have I/O ports, but I would not use them for things that are particularly real-time intensive – things like counting pulses on an encoder. If you need that, I’d consider something like a Teensy. As long as you’re not doing something really computationally intensive like vision processing, a Teensy 4.1 is probably going to be more than enough.

My thought was to keep as much of the wpilib ecosystem as possible for small bots and demo bots. If people want to it another way that’s their choice.

Serial was first because it was easiest and would allow use of teensy/arduino/pi pico for encoders, PWM control etc.

I don’t have any CAN, but what I’ve seen it looks socketcan based. If I can get it working then that’d open up all the CAN devices that already have that built in.

They have a SparkMax, I believe you can use that in PWM, over the USB, CAN and use it as a SocketCAN adapter.

Our bot doesn’t really use any PWM or real-time DIO. It’s all CAN based for that stuff.

Do you happen to have a photo or similar of what y’all did so I could reference some of the connections? Thanks!

Look up the pinout for the PWM control for the sparkmax.

G=Brown, V=Red, S=Yellow?

If you really wanted to get very simple and all your controls mimicked servos you could get a cheap R/C radio.

1 Like

If you’re just looking for a tele-op rig, you don’t even need the robot to have a brain, right? RC cars & battlebots kits are worth a look just to understand the minimal pieces you can get away with (brushed motors, RC controller/transmitter, receivers, motor speed controllers - PWM).

I’d also be interested to hear what minimalist pieces like this teams have used… I assume it may be fairly common.

CAN bus actually shouldn’t be terrible from what I’ve seen from team 900. I’m no embedded linux expert but I know my way around the kernel, and socketCAN is absolutely a way to to talk to drivers (I believe it’s the way the RIO does it). I can also say that the IO is very fast if you avoid the python mappings and use straight /sys/class/gpio for gpio and ioctl for SPI I2C, and UART, although this requires you to have these somehow bound to your programming language of choice. No problem for us C/C++ users, but it may be a bigger issue for those of you who don’t have the time to manage your memory and type out a for() loop.

You might actually be able to adopt some of the Romi code to do this, but that’s a question for a WPIlib developer and not me.

Hope that at least provided some useful info!

edit: after thinking about it some more, CAN bus might be terrible. That is all.

Not quite. The niembcan Zynq stuff is a bit of a different beast. It is just CAN though.

interesting. Do you know if the Zynq has an CAN peripheral built in or is it an IP core on the FPGA?

Edit: it does in fact have two CAN interfaces built in, and I’m assuming that’s what NI is using.

1 Like

I do not believe it is using anything on the FPGA based on the various bits of data in the bitstream file.

I think our particular Zynq chips have two separate CAN bus interfaces if I recall. I think only one of them is used though based on what I recall.

Trying to change the device tree along with the startup scripts to use the native Zynq SocketCAN driver has been on my list of stuff to try for a while but it’s not a high priority. It doesn’t buy anything that just using a USB adapter wouldn’t buy for much less work.

I wonder why NI wouldn’t expose both CAN interfaces. It seems like that’s a pretty valuable piece of IO to leave out, especially given how easy it is to DMA a protocol like CAN. I’d definitely be interested in seeing if you have any success with that SocketCAN driver, as I find that SocketCAN is just a really dang good implementation of the protocol, which just makes me even more curious as to why it’s not being used in the first place.

1 Like

We need a shrugging react.

I could have sworn it was SocketCAN based so that the drivers could have non exclusive access.

I am probably wrong though.

It certainly does not appear as a normal SocketCAN interface.

This is on what is left of our stronghold robot.

Not the prettiest, but it is functional. It is using old Victor 888 motor controllers, but I think all FRC motor controllers can run off a PWM signal. You cannot use the fun can sensor info, but I’d you just need to spin a motor at varying speeds forward and backwards this setup will work.

For programming it uses python. More specifically pygame to get joystick values and the audifrit servo hat library to control the PWM signal.


There are lots of viable ways to control a mobile robot without using a RoboRio or any of the electronics that go with the RoboRio.

Basically the RoboRio is an ARM core with some FPGA logic added to it running Linux.

As others have noted how you approach this is very much up to your specific needs.

If you need lots of real time monitoring a Raspberry Pi alone is not well suited to the task, but couple that with an Arduino or a small FPGA and that can easily change. Even an Arduino alone can manage this task if you can over come how to get to it by radio, and again there are many potential options to that.

Just be sure to put safety first and have plans on how you will stop this creation if things do not go as planned.

Technically you could put a whole laptop with an SSD on a mobile robot with the battery inside it and attach an Arduino to it to get some real time sensors and time sensitive outputs. It would be massive over kill, but in so putting such a laptop on the robot you get a whole display, a sound card, storage, and maybe a webcam. A step below that might be something like the old Kangaroo PC.

I can think of a few reasons I might put a whole laptop on a mobile robot: one of them to use an entire building’s enterprise WiFi for streaming video or remote control. If I were to do this I would put a timer on the robot’s main power such that if I lost access to the robot due to it being very far away - it would turn itself off if it did not get instruction from me frequently.