Wpilib and alternative platforms: stripped HAL running on an AtomicPi

Got a stripped down HAL / wpilib running on an AtomicPi and got the driverstation to connect.

Why did I do this? I wanted a couple of cheap bots for summer programming and challenges using “real” wpilib programming. AtomicPis are powerful enough, have builtin ethernet and wifi, have a built in IMU (Gyro) and have some limited GPIO.

Also, most importantly, they are available on Amazon for $40.

It’s just running and the HAL is completely stripped. All it can do is report system time and versions to the driver station.

Next steps:

Get PWM outputs working so I can get a bot to drive around with some cheap BTS7960 controllers or regular sparks.

Get the Gyro to work and mimic the “AnalogGyro”

Get an I/O board to work based on an Arduino 2560+a sensor shield (https://www.amazon.com/KEYESTUDIO-MEGA-Sensor-Shield-Arduino/dp/B0169YXYEY)

I also may create some mqtt/copa/ipv6/mdns/arduino based encoders/sensors to work with the system.


Neat, but… links?


It’s way alpha. Parts of simulator, parts of VMX-pi.

You looking for a GitHub fork?

Some assumptions were made in allwpilib that made it difficult. The base code disables tests if it’s a cross compiler. It assumes if it’s not a cross compiler it should run the sim hal tests.

Also peppered through the Gradle was checking for Raspbian / roborio etc.

Another bump was I could never get local repos to work for opencv etc. I ended up pulling wpilib-repositories and change it to a pass through Nexus instance.

Once I get PWM working and driving a bot I’ll post the fork and start documenting it.

1 Like

Gradle definitely makes some decisions that are a bit more hardcoded for our specific platforms. Its hard to make it work otherwise.

For alternate platforms, we usually suggest starting with CMake. It actually has options for specifying a completely separate HAL cmake file and directory. This is usually the easiest way to begin with other platforms, since cmake trivially allows building for alternate platforms, and is a much more standard build system for C++ code.

1 Like

Lovely. Two build system to maintain. Is this the result of the mono repo?

Normally I’d see this implemented as smaller repos with builds that produce artifacts that get referenced by other projects.

Renovate or dependabot would be used to automatically rev component versions.

Nope. It’s a result of having to build for such a large matrix of platforms, and having to build jni and ship packages. The monorepo does not affect the choice of multiple systems. Before we had a monorepo, each individual project also had 2 build systems.

1 Like

This is really cool!

Looking forward to where this is headed!


Of course marshall likes this…

Keep in mind that the monorepo is older than these things (even if one could write it by hand with the tech at the time) :slight_smile:

Yep. Was looking for history. We used to have complex Jenkins chains to avoid the mono repo. That was it’s own unique nightmare.

With a monorepo we used to have too much “drift” between projects resulting in some circular depencies.

A monorepo is perfectly ok with a little discipline.

Ok. Got a test car to “drive” on a stand. Not happy with how I did it.

I only implemented the serial port in the alternative HAL.

Then I loaded figmata on an arduino (Inland Plus Control Board) and implemented a basic motor driver class that extends motor controller and implements motor safety. Its connected through the HAL with the USB serial in the arduino.

This class right now uses the outputs on the arduino connected to a L298N motor driver.

I was surprised at how well figmata works. Next time we have a sensor or i2c device in a weird spot I might suggest it (at least for prototyping)

Anyway, it’ll serve our purpose of having a small bot that you can use wpilib/driverstation.

1 Like

Tangentially related: CANivore New Features - CTR Electronics.

1 Like

Neat… but if a team was worried about the extra $450 of a roborio, they are also probably not in the market for a $300 CAN device either.

I am going to try to one of those $40 usb-can devices that supports SocketCAN, or maybe see if I can couple the AtomicPI to a hero board.


They work. We’ve been using them on our robots for years at this point. Granted, not CAN-FD, just plain old CAN.

1 Like

I’m trying to find a CANable to see if I can expand the Romi to control CTRE motor controllers - the only place I can find them in stock is https://www.aliexpress.com/i/33003931570.html at a pretty decent markup - is any USB-to-CAN adapter equally compatible or are there specific ones known to work best/easiest?

Component shortages are very real - anything automotive is getting harder and harder to come by, specifically CAN stuff.

In theory, anything that can talk/interface to the kernel via socketcan will work. There’s quite a few things out there, including SPI based devices.

1 Like

I’m seeing several CANables for sale on AliExpress for around $23: https://a.aliexpress.com/_msDKwEO

1 Like

I bought this one that claims SocketCAN support.

I haven’t tried it yet.

1 Like

Can the Romi do CAN? If I read correctly the Romi runs the simulator with a websocket extension.

Then there is a websocket app running on the Romi.

I think there is a project to run the robot code on the Romi directly, but I am not sure how along it is.

I did pick up a ESP32 module with ethernet. I’ll try some network based sensors in a couple weeks. Any suggestions on what sensors they’d like to see?

I have a IMU module I was going to try first.

The Romi can’t natively, I was hoping to extend the websocket app running on the Romi to control a CANable. I haven’t dug too deep into this yet as my first steps were just going to be getting a mini-bot working with the Romi control board and PWM motor controllers, but eventually I’d like to extend that to CAN motor controllers as well.