Building a RIOless bot

Technical Programming
1

Mars/Wars has a preseason tradition of a 6 week minibot build and competition. We started with tethered sumobots years ago. Last year we used the Romi code as a base to building actual wpilib bots. This year we wanted to run wpilib bots on real hardware. We don’t have enough roborios and aren’t going to invest in them now. This post is to document what it takes with 2023 versions to use a RPI or NVidia Jetson to make a wpilib robot. This will probably change with 2024 versions. Hopefully REV, CTRE and other vendors will consider this use case.

Let’s try to build a CAN-only wpilib bot that supports both REV and CTRE devices. Wpilib has a HAL (hardware abstraction layer) system which targets athena, athena2 (roborios) and simulation. There is vague language about adding a custom HAL, but zero examples. VMX-pi does this but I didn’t realize it was open source. I think it was Peter Johnson who pointed out that the simulation HAL has an extension system to support actual hardware. So really, the simulation HAL is a universal HAL.

Off we go down the simulation HAL path. NI provides us with a closed source binary blob that provides DriverStation comms and CAN comms. It turns out the wpilib simulation HAL also provides DriverStation comms via an extension. Simply set an environment variable, and they will be loaded. export HALSIM_EXTENSIONS=“libhalsim_ds_socket.so”

There are a bunch of cheap Canable-type usb to can converters. Using the candlelight firmware, they work great with linux SocketCAN. CTRE has examples on how to use these with their hardware GitHub - CrossTheRoadElec/Phoenix-Linux-SocketCAN-Example: Phoenix API example for Linux-Desktop and Raspberry Pi

REV has a another promising repo. GitHub - REVrobotics/CANBridge: Generic CAN Bridge emulating FRC netcomm CAN driver for connecting a PC to the CAN Bus with WPILib 2020+ and SPARK MAX (FW 1.5.0 or higher) or other drivers, currently only supported in Windows. But there is an old branch on github called “SocketCAN”. This could work. I fixed up the bit rot. Now we have a simulation HAL CAN extension for SocketCAN. GitHub - FRC-Team-4143/CANBridge at 4143

We are getting there. So far we are using a RPI or Jetson with a canable, wpilib compiled with simulation HAL, DS extension, CAN extension, REV drivers for linuxarm64 and CTRE drivers from the Phoenix-Linux-SocketCAN-Example repo.

The CTRE drivers implement their own socketCAN extension. It is great they did this, but excludes all other vendors. SocketCAN doesn’t care if you have multiple users of an interface. We can let the CTRE traffic go through their library and all other vendors go through the canbridge extension. They do need a call to FeedEnable() periodically.

There is another problem though. The REV linuxarm64 drivers check to see if they are working in a simulation HAL. If they are, they don’t enable. That seems reasonable for a simulation HAL, but remember, the “simulation HAL” could have been called “universal HAL”. Not a huge problem, we’ll just lie to the REV drivers and say that we aren’t in a simulation.

Now we have a working wpilib CAN bot with DriverStation support. PWM outputs and digital/analog inputs could be implemented with simulation HAL extensions for specific hardware.

It would be great if vendors published linuxarm64 libraries that did the exact same thing as the libathena target libraries. It would also be great if REV published the CANBridge for Linux with SocketCAN and SparkMax support. (I think SparkMax are almost the same as candlelight fw devices but something makes it not work (might be tx checksums)). I’ve only tried this so far with CTRE Phoenix5 firmware.

Here is a working proof of concept repo for a C++ bot that actually makes motor spin. GitHub - FRC-Team-4143/jetsonNative: native C++ FRC wpilib robot code running on a Jetson

Edited: to say VMX-PI hal is opensource

21 Likes
2

Now THIS is the wild engineering content I came here for.

5 Likes
3

It is very much open. :slight_smile:

2 Likes
4

Thanks I hadn’t found that.

1 Like
5

CTR actually does publish binaries for quite a few targets. The full list is available at Installing Phoenix 6

2 Likes
6

I’ve done this before on Jetson with canable. It works well, just remember to flash and add the custom firmware on the mcs. I forget so many times and just grab a frc imaged one by mistake and then sit there confused wondering why it doesn’t work anymore. If you follow the CTRE docs thoroughly it works

On the Jetson we also ended up enabling i2c and SPI for trying to get closer to what the RoboRio can do. The digital IO on the Jetson is all gpio 3.3v so you need signal level converters for stuff like color sensors, etc if they were rio compatible or 5v based.

Notes: we used an original Jetson nano because it’s 5v power and was cheap. The gpio is true on any Jetson boards(Tk1-Tx2, Orin, etc), the newer ones have can built in but are $$ and I don’t know if you’d be able to leverage that anyways.

1 Like
7

Aw, no Shermanator?
This looks very cool according to my limited knowledge of whats being discussed!

8

From 2019 but might help: ZebROS Nano

EDIT: We’ve been running robots without RIOs for a while… though for competition purposes we still have the RIO onboard and doing what it is supposed to be doing.

3 Likes
9

SocketCAN-attached simulation is of interest to me at Redux because it’s a way to run integration tests on our vendordep without a Rio or even actual devices — since you can make virtual SocketCAN interfaces too.

I actually had my own go at the CANBridge idea by forking a repo from Thad in 2019 that adds a SocketCAN backend for the HAL CAN functions while in sim and also modernized it to 2023.

It’s definitely not super elegant (as I haven’t figured out how to register it properly as a HAL extension, and I should probably tag a Maven binary release), but notably it also supports Java.

2 Likes
11

Well this is neat!

It was only recently that I have found myself wanting to brush up on my programming skills and learn WPIlib. I was not a part of the programming group when I was still a student, and my hands were too busy with CAD/electrical/build that I didn’t have much time to study programming for FRC. I did take comp sci classes, so I’m familiar with reading code and documentation and can limp though the rest. I’m happy something like this exists such that I could put together a drive train for much cheaper to practice with. (I understand simulators are a thing, but nothing beats seeing the physical thing drive.)

12

I wish I had known about that earlier. I would have used it.

1 Like
13

In fairness, I only wrote it last month…so the timelines wouldn’t have worked that well.

14

This commit got this working for me: halsim extension registration · FRC-Team-4143/CANBridge@2930b9b · GitHub

1 Like
15

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.