Rover CAN Architecture

Owned by Former user (Deleted)
Last updated: May 12, 2021
2 min read

2021 Rover CAN Architecture

Nodes

The rover's CAN bus consists of the following nodes:

  • Arm: Custom PCB that interfaces with encoders, servos, motor controllers, current sensors, and other sensors within the robotic arm subsystem.
  • Science: Custom PCB that interfaces with encoders, servos, motor controllers, moisture sensor, and other sensors within the science mechanism subsystem.
  • Gimbal: Custom PCB that interfaces with an encoder and servos within the gimbal subsystem.
  • Power Distribution Board (PDB): Custom PCB that monitors the power rails of the rover and interfaces with the LED matrix and ultrasonic sensors.
  • Roboteq Motor Controller: COTS brushed DC motor controller module that controls each of the drivetrain motors.
  • Jetson: Nvidia Jetson AGX Xavier compute board that runs all of the rover's software.

Dual CAN

For redundancy, the rover uses a dual-CAN system where each node is connected on two separate CAN buses: CAN1 and CAN2. Only one bus is used at a time, with the option of manually switching to the other bus in the case of unreliable message reception on the current bus.

Message Reception

A node will broadcast messages to the entire CAN bus, but only the intended recipients of a particular message will process it. This is achieved through hardware filtering of CAN IDs (which will be explained in a bit).

A standard CAN ID is 11 bits long. For our rover, we use bits 5:10 as an "address identifier", meaning that all messages that are meant to be received by the same node will have the same address identifier bits. For each incoming message, the address bits of the CAN ID are compared with the configured hardware filters for that node - if there is a match, the message will be retained for processing by software, otherwise it will be discarded without disturbing the software. Bits 0:4 of the CAN ID are used to specify the type of the message, which determines how the message data should be interpreted.

Streamed vs. One-Shot Messages

Streamed messages are transmitted periodically. These include streaming sensor readings, actuator commands, and any kind of signal that would get continuously updated. For our rover, all streamed messages are sent at 100Hz. One-shot messages are event-based - they are transmitted only when needed. These include commands to change control modes and PID gains, and ACK messages (acknowledgement messages that are transmitted to the Jetson whenever a one-shot message is received by a node).

FW/SW CAN Rearchitecture