Author: Sean Fish

In order to test the feasibility of CAN-based control for the WAM-V running up to RobotX 2024, we test CAN-BUS with the following hardware:

• CAN-BUS Shield
  • Resources
    • https://github.com/Seeed-Studio/Seeed_Arduino_CAN
• Vex Pro Victor SPX ESC by CTR Electronics
  • Relevant Specifications
    • Communication: PWM / CAN
    • Voltage: 6-16V
    • Continuous Current: 60A
    • CAN_H = Yellow; CAN_L = Green
  • Resources
    • https://github.com/CrossTheRoadElec/Phoenix5-Linux-Example
    • Want to Write CAN bus Communication Protocols, No Idea Where to Start - Technical - Chief Delphi
    • FRC CAN Device Specifications — FIRST Robotics Competition documentation (wpilib.org)
    • Third party CAN bus connector to Roborio - Technical / CAN - Chief Delphi

Before we get started - a bit of background - I am not an FRC alum. I know very little about FRC beyond what others tell me. I think the hardware is neat and think it would be cool to use it outside of the FRC ecosystem. I have some experience with using CAN and stepper motors and a fair bit of experience deciphering unknown data packets as of writing.

Also, I want to link a resource that was very helpful to me when I first learned about CAN: CANopen Explained - A Simple Intro [2022] – CSS Electronics

Part 1 - Basic Setup

The basic setup looks like this:

Pardon the mess of wires

First off, we try using the default shield library and set up the CAN bus. Uh oh, red alternating lights on the ESC. That means CAN isn’t detected. Now, we try measuring the resistance of the bus. It’s 60 Ohms, so all good there.

Now, the engineers building FIRST Robotics Competition (FRC) hardware have rather specific standards of their own. So we start testing using the library here ‣ from FRC. However, based on discussion of the devs themselves, we need 1Mbps and that means more than an 8Mhz setting. So, I change the 8Mhz initialization parameter to 16Hz, and now we’ve gone from red alternating lights to orange alternating lights. Hooray, we’ve gone from one error to another. This one means “CAN Bus detected, robot disabled” which is part of the FRC CAN specifications.

Part 2 - Configuring the Device

We don’t see any incoming CAN messages by default. We start printing CAN messages for unknown devices, and we get the CAN ID of our ESC. Cool.

With a few tweaks to the initialized CAN device, we get message data out. According to Wikipedia, 8 bytes is standard for the data portion of a CAN message, and that is indeed what we see.

First, we see from CAN ID 2164528128 the message 0 0 0 192 0 0 16 0

Let’s look at the CAN ID in binary: 1000 0001 0000 0100 0001 0100 0000 0000

Going back to FRC CAN documentation, there’s 29 bits in an identifier - extended beyond the typical 11 bits. The first 3 bits here are error codes. Let’s try to construct what we would expect the ID would look like based on the docs 00001 00000100 000101 0000 000000