CAN Bus in FIRST – a history lesson

In preparation for the 2015 FRC season, CTR-Electronics and National Instruments worked together to provide the first integrated CAN bus interface to the FRC community. This became the roboRIO single DW CAN 2.0 bus which is used today.

This was released simultaneously with the first CAN-based control system for FIRST (CTR-Electronics), demonstrating how empowering and useful CAN bus can be in the FRC space. Additionally, the first sealed CAN-bus motor controllers were also made available by CTR-Electronics and VEX Robotics via the Talon SRX.

Since then, CTR-Electronics has released a flurry of CAN-bus peripherals that have continued to raise the bar for what is possible.

As the years flew by, teams have begun to hit performance limits as the demand for higher bandwidth and total CAN node count has increased.

The announcement of the roboRIO2 confirmed that additional integrated CAN buses are unlikely in the near future. As a result, CTR-Electronics decided to take on the challenge of solving how to add robust additional CAN buses to meet the needs of modern teams.

This effort has taken form in the CANivore USB-to-CAN adapter. A complete CANFD solution to FIRST Robotics. This is a “from the ground up” USB-to-CAN solution catered specifically for FIRST team use.

CAN Bus 2.0 – Challenges

The major limitation of the CAN bus is that is uses the older CAN 2.0B protocol.

This protocol peaks at 1 Mbps and allows for up to eight data bytes per frame. Because of this, CTR-Electronics spends a great deal of time optimizing frame designs to allow for the best results for common use cases. Much of this effort is a result of the limits of the protocol itself.

Furthermore, having a single CAN bus for all nodes means robots are typically cabled in a “head to toe” fashion, with the CAN bus starting at the drivetrain and reaching the top of the robot. This can make wire management more difficult than need be.

What is CAN FD

CAN FD is the next iteration of the CAN bus data link layer. The FD stand for Flexible Data-Rate, meaning that portions of the frame is transmitted at higher data rates (up to 10Mbps). This means less bus time for more data. Additionally, a single frame can now hold up to 64 data bytes.

This is critical for many reasons:

  • Lower bus utilizations because of less frame overhead and higher bitrates.
  • More devices before hitting maximum bus utilization.
  • Less time spent designing how to split signals across multiple frames
  • Larger frames mean potential firmware features that were not previously possible with CAN 2.0B.

Performance - So how much better is it?

Calculating the improvement can be tricky since it depends on frame design and which CAN FD bitrate is used. Our research and testing indicate the bus utilization will drop from using CANivore vs the original CAN 2.0 bus by 2X to 8X depending on these details. This improvement will also increase over time as framing changes are made to take greater advantage of the new bus across the product line.

Current testing with the 2022 release firmware (CANivore and supported devices) has shown that a typical bus at 80% (as reported by the driver station) will be 35% when used with a CANivore (as reported by Phoenix Tuner). That’s an effective gain of 2.3X. With each season this will continue to be improved with newer device firmware.

What devices are supported?

Currently the following products support CANFD, and therefore can be used with the CANivore

Shown below are 35 devices operating on Tuner! Note that status frames rates were not reduced for this test.
This is not possible when using the roboRIO CAN bus as this would require ~120% bus utilization.  But using CANivore and 2022 firmware, this only uses 51% bus utilization.
Additionally, this utilization will continue to decrease as frame changes are made in future seasons to take greater advantage of CANFD, without reducing status rates! 



What is Socket CAN?

SocketCAN is a commonly used set of drivers and networking stack that allows for sending/receiving CAN frames in Linux. Because the roboRIO is a Linux system, we opted to bring SocketCAN into FIRST Robotics. In fact, CTR-Electronics has supported SocketCAN with Phoenix Framework for years (particularly with industrial customers) using various hobbyist style SocketCAN-USB products.

However, while supporting our industrial customers with SocketCAN, the list of problems we’ve encountered with existing USB-to-CAN hardware solutions grew to the point where developing the CANivore became the only solution to ensure a quality experience, in industry and in FIRST Robotics.

Some of those limitations are:

  • No way to name each network to ensure network name is the same after boot up. User applications must specify “can0” vs “can1” vs “can2”, and the numbers are not the same each time.
  • SocketCAN hardware does not work on power up. They require configuration every time they are inserted.
  • Disconnect/reconnect events will cause CAN bus stream to stop.
  • Poor quality firmware – lost frames,
  • Field-upgrade not robust – devices rendered “bricked” or require button-on-boot recovery.
  • Confusing LED sequences not tailored for troubleshooting wiring.
  • Termination is often not selectable or requires mechanical jumper.
  • Performance issues

CTRE-Electronics has solved these common problems by providing:

  • CANivore USB-to-CAN Adapter
  • Phoenix Framework (API supports picking CANivore by name)
  • CANivore’s SocketCAN compatible kernel driver integrated into 2022 roboRIO Image.

Why USB? Why CAN FD over other networks?

When considering the various communication methods that we could bring to FIRST, many alternatives were considered.

  • Ethernet (and Ethernet derivatives) for device interface.
  • RS485 (or similar half-duplex serial) for device interface.
  • Ethernet instead of USB for robot controller interface.

But it became obvious that CAN FD was the best choice for the following reasons

  • CAN FD could potentially support older CAN 2.0 products by switching to a legacy CAN 2.0 mode. *
  • USB allows up to two CANivores without a USB hub, whereas Ethernet will effectively always require a hub.
  • RS485 is incomplete as it only implements a physical layer. A custom implementation is unlikely to be as robust as the modern CAN FD protocol (which is already used in commercial vehicles).**

    * The 2022 release for CANivore is CANFD only. Depending on support effort, and testing – legacy CTR-Electronics CAN devices may also work in future releases.

    ** A great comparison of the two can be found here

Is CAN FD wired any differently?

Since CAN FD is an extension of CAN 2.0, the wiring requirements are similar.

  • CAN bus must still have 120Ω of termination at each extreme end.
  • CAN bus stub lengths must be short (typical maximum of one foot).
  • Daisy chaining still recommended as this reduces stub length to near zero.

In the past with CAN 2.0, teams with very short CAN buses may have been able to get some degree of success without ensuring the above requirements are met, such as with star or ring topologies. However, as transmission frequencies increase (such as in CAN FD), it is more important to ensure proper bus topology (daisy chain or short stub lengths).

This is the reason CTR-Electronics incorporates true daisy-chaining* in all modern CAN bus products.

    *True daisy chaining means bridging the CANH and CANL lines within the product, and not inside a connector (critical failure point) or inside of breakout far away from the devices.