SparkMax Controller + Raspberry Pi CAN


I am trying to interface a Spark Max motor controller via CAN bus on Raspberry Pi 4. I have a CAN shield on the RPi that is communicating with a Pigeon IMU using the Phoenix-Linux-SocketCAN-Example code without issue. I am also able to configure the SparkMax via the Windows client which uses USB to CAN.

The SparkMax SDK (v1.5.2) comes with static libraries for RPi that are dependent on WPILib libraries for which there does not seem to exist a Raspbian port. As a result, my understanding is that I cannot use the SparkMax API on a Raspberry Pi at the moment. Is this correct?

I’m assuming the next best option is to send raw CAN frames to the motor controller, but it seems others have had issues getting this to work. What is it going to take to get raw CAN control of a SparkMax device from a Raspberry Pi.


1 Like

Which libraries? We do publish Raspbian artifacts for WPILib, e.g. wpilibc.

It is another piece of hardware, and it does not yet run the 2020 library, but The Vmx-Pi does exactly what you are trying to do. You will still need a power supply and some sort of PDP, but it is incredible.

Kuai Labs is sold out, but Studica has them. We just purchased one, and they are incredible.

1 Like

I see the frc headers required by the SparkMax API in the link you posted but the SparkMax API also requires hal headers (I’m guessing Hardware Abstraction Layer). Any idea where those live?

I actually ordered the Vmx-Pi just prior to posting this, I agree it’s a very cool piece of hardware either way (should arrive today!). Was just curious if there was an easier/cheaper way for just the SparkMax CAN communication.

1 Like

@Will_Toth might have something on this, we were emailing a few weeks ago about controlling Sparks from a Jetson Nano.

I also know that @RyanShoff has done some similar work with limited success but I t think he was on a Nano as well.

Found HAL on the same level as wpilibc: HAL. I will try the SparkMax API again now that I have these dependencies and report back with results. Still curious to hear if anyone else has already gone through this process.

1 Like

I’m attempting to do something similar, though im using an Intel NUC rather than a Raspberry Pi. I have a USB to CAN bridge, but have been unable to figure out the CAN communication. Just wondering if you ever made any progress on this project.

Rev is developing a CAN driver specifically for this purpose, but it currently only supports windows. They are adding support for linux (you can view the SocketCAN branch) but they don’t have a timeline for when.

Did you manage to get the libraries working otherwise?

I was able to hunt down the missing dependencies in order to compile a C++ program on the Pi that included the SparkMax library headers. However, when I run this code to connect to the SparkMax device via the API, it gives me a ‘device not found on CAN bus’ related error.

I ended up using a Python script to dump/send raw CAN messages from/to the SparkMAX. So far, I’ve figured out how to set the motor speed and direction with this method and am now working on trying to decode the raw CAN frames coming periodically from the SparkMAX.

Make sure that you have a terminating resistor on your CAN bus.

That’s the funny part, I’ll run the C++ program that uses the SparkMAX API and get the CAN bus error. Then I run the Python script immediately after and I can dump and see all CAN messages from all devices on my bus, including the SparkMAX. So it’s definitely not a connection/termination issue.

I have also successfully done this with CTRE’s Phoenix library. I don’t know much about REV’s libraries, but I would make sure that you are using libraries that are meant for non-FRC use. This is because on the RoboRIO, all of the libraries access CAN through the NetComm process ( i think). On a Raspberry Pi with Linux, you will need to use SocketCAN. Phoenix has another library for this. I believe a link to REV’s version of the library was linked above. Also, you probably need to configure which CAN interface you want the library to use when you start your program. I know that Phoenix just has a function for this.

Like @anon52548577 said, your issue is (probably) stemming from the library attempting to use the RoboRIO NetComm process, which your linux system doesn’t have. I came across this repository which may act as a HAL for SocketCAN and the official FRC libraries, but I haven’t tested that. I will have access to hardware tomorrow to do some testing.

Can you send me that Python script you’re using? If you get the motor to spin at all, you’re already farther than I am. I would love to work on this with you, I could help decode those CAN frames as I have a decent understanding of CAN, the FRC CAN protocol, and the Rev status codes.

Has anyone made any recent progress on this topic? I’m very interested in using a USB-to-CAN adapter and socketCAN to control a NEO with a SPARK MAX.
For non-FRC use.

I have a project where I want to control a Falcon 500 with an Arduino uno. I know I can just use the Pwm command to control the motor. I want to control motor position with pid loop using the motor controller internal PID function
. I understand this is controlled by the CAN bus with some protocol that is buried in the controller API. Has your usage of the Phoenix library given you any insight as too it’s possible use with an Arduino with a CAN shield?
Also I assume using the usb controller client Is a dead end for setting PID configuration, right.

CTRE has provided prebuilt libraries for the jetsontx, x86_64 and raspberrypi platforms in their linux socketcan repo: Phoenix-Linux-SocketCAN-Example/lib at master · CrossTheRoadElec/Phoenix-Linux-SocketCAN-Example · GitHub

They would need to provide an arduino-compatible set of dependencies for you to include in order to use their APIs. It doesn’t hurt to ask :slight_smile:

@wheelhead, it’s been a few months since you got you vmx-Pi, did you get the CAN bus to work? Overall how do you like the vmx-Pi?

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