Skip to content

999. FRC Custom CAN Device Compliance Considerations

Jump to bottom
Nathan zhou edited this page Jan 22, 2026 · 41 revisions

Custom CAN devices are considered CUSTOM CIRCUIT under the FRC Game Manual; therefore, they must comply with all rules that apply to custom circuits.

This document serves as a guide for teams interested in designing and implementing custom CAN devices that comply with the FIRST Robotics Competition (FRC) Game Manual. It is important to understand that this guide does not replace the official FRC rules. The Game Manual is the only authoritative source for determining legality and compliance of any robot component.

This guide is based on the 2025 FRC Game Manual. Future manuals may introduce changes, so please always refer to and follow the most recent official Game Manual for the latest rules and requirements.

2026 QA 25

QA 25 answer some of the questions regarding Custmom CAN Sensor.

https://frc-qa.firstinspires.org/qa/25

1. Is team created CAN device allowed as custom electronics? 
2. Can team created CAN device (team fabricated PCB) include built in CMOS coin cell battery? 
3. If question to 2 is NO because team fabricated PCB is not considered COTS, can COTS RTC module (which require coin cell battery) be used with with team fabricated PCB? 
4. Can team created CAN device talks to motor controller (roboRIO heartbeat not altered) directly? 
5. Q4 but talk to PCM/PH. 
6. Can COTS CAN sensor be modified (ie, CANCoder)

As a friendly reminder, the Q&A is not a place for overly broad, vague, and/or questions that include no rule references. Please consult [Section 1.9](https://firstfrc.blob.core.windows.net/frc2026/Manual/2026GameManual.pdf) for guidance on asking questions.

1. There are no rules that prohibit this.
2. No, [R602](https://frc-qa.firstinspires.org/manual/rule/R/602) only permits "batteries used to power CMOS/RTC features may be used to power COTS computing devices and any peripheral COTS input or output devices connected to the COTS computing device".
3. Yes, a COTS RTC module may be considered a "computing device"
4. Yes, please see the Blue Boxes below [R701](https://frc-qa.firstinspires.org/manual/rule/R/701) and [R714](https://frcqa.firstinspires.org/manual/rule/R/714).
5. Yes, while [R715](https://frc-qa.firstinspires.org/manual/rule/R/715) does not have the same Blue Box as [R714](https://frcqa.firstinspires.org/manual/rule/R/714), the same idea would apply.
6. There are no rules that explicitly prohibit the modification of devices which would be classified as CUSTOM CIRCUITS.

⚠️ Safety Rationale

All these rules exist to ensure that every robot on the field operates safely and can be immediately disabled in the event of a fault or emergency.

The most critical part of this system is the roboRIO heartbeat, which is used by all legal motor controllers (and other power-regulating devices) to determine whether the robot is enabled or disabled. This heartbeat is continuously transmitted by the roboRIO when the robot is in an enabled state, and it stops instantly when the robot is disabled by the Field Management System (FMS), the Driver Station, or the E-Stop button.

This mechanism ensures that:

  • All motors and actuators cease power output immediately upon disable.
  • The robot cannot move or actuate until the DS allows it.
  • Field staff, referees, and other teams remain protected from unintentional motion.

It is therefore illegal and unsafe to tamper with, replace, or replicate the roboRIO heartbeat in any form. Doing so bypasses a fundamental FRC safety feature and can create a runaway robot — one that continues to move or operate after being disabled.

In addition, teams must not send any CAN frame that could enable or simulate enabling of a motor controller under any condition. For example, some vendor utilities (such as the REV Hardware Client) include their own internal heartbeat used for bench testing; if such a frame is transmitted while the roboRIO is not present (for example, MCU usually startup faster than roboRIO's RT Linux), it can unintentionally enable a motor controller. Sending any frame that re-creates or substitutes the roboRIO heartbeat is illegal and unsafe, as it bypasses FRC’s required disable system and can result in a runaway robot, violating R203 .

Prepare for robot inspection

Firmware source or configuration should be documented and be provided upon request during robot inspection. Teams creating custom CAN devices should maintain a clear and accessible copy of firmware or configuration files, including:

  • Firmware source code

  • Description of device function and CAN message types used

  • Default CAN ID, manufacturer ID, and device type

  • Any configurable parameters that affect robot behavior

Inspectors may ask teams to describe or demonstrate what messages their device sends on the CAN bus. Teams should be able to explain:

  • How the device identifies itself (e.g., manufacturer ID and device type)

  • What data is transmitted (e.g., sensor readings, diagnostic info)

  • How it ensures it does not send heartbeat frames (R714, R715)

All firmware and software used on the robot must comply with FRC safety principles: no self-enabling outputs, no persistent control signals when disabled, and no communication outside of legal channels (R905).

Most Important FRC Rules for Custom CAN device Design

In addition, a Custom CAN device might not be considered a COTS device under FRC rules. (Section 8)

COTS (Commercial Off-The-Shelf) is defined in the Game Manual as “a standard (i.e. not custom order) part commonly available from a VENDOR for all teams for purchase.” Because a custom CAN device is typically designed, assembled, or programmed by a single team, it does not qualify as a COTS product. There are some clear lines and gray areas in determining whether a device is considered COTS under FRC rules.

For example:

  • Off-the-shelf Arduino, ESP32 development boards, or CAN controller/transceiver modules (e.g., MCP2515 breakout boards, commercial CAN shields, or dev kits sold by major electronics vendors) are considered COTS, because they are standard products commonly available to all teams for purchase.

  • However, any custom PCB, team-designed circuit board, or modified version of a commercial module might not be considered as COTS.

What You Can and Cannot Do with a Custom CAN device

Category Allowed (✅ Can Do) Not Allowed (❌ Can’t Do)
CAN Communication The roboRIO may send and receive data to and from the custom CAN device as part of normal robot operation. This includes exchanging configuration frames, sensor readings, and status information necessary for device function. The custom device may read the roboRIO’s heartbeat and control messages for its own use. Modify, spoof, or resend the roboRIO heartbeat signal used to enable/disable motor controllers ([R716]). Teams also must not send any CAN frame that could enable or simulate enabling of a motor controller under any condition (for example, vendor tools with their own heartbeat). Doing so creates an unsafe condition and risks a runaway robot, violating R203.
Sensors Read data from sensors (e.g., IMU, color, distance) and send it over CAN to the roboRIO. Use any sensor or wiring that causes interference with other robot or control system ([R203]).
LED / Indicator Devices Control addressable LEDs or indicators based on CAN messages (status lights, diagnostics, etc.). LEDs or sound effects must not interfere with other robots or create strobing, flashing, or loud/annoying patterns or noises that could cause discomfort to participants or field staff ([R203]).
Wireless & Radio Use RFID or NFC modules within the robot for tracking, identification, or data logging ([R707]). Bluetooth in the pit may be tolerated for debugging, but remains a gray area — always confirm with your LRI ([R905]). Wi-Fi or Bluetooth must be completely disabled on the ESP32 or any board during matches. No unapproved wireless communication of any kind is allowed in the venue ([E301]).
Motor, Servo, and Pneumatic Control If you understand a motor controller or PCM/PH’s CAN protocol, you may send control frames to it directly from a custom CAN device. This is technically legal as long as the roboRIO heartbeat is not modified ([R714]). Custom CAN devices can read or report PWM sensor or pressure sensor values. This does not eliminate the need for a legal pressure switch/sensor connected to the PCM/PH ([R812]); if implemented, it must be on an additional sensor and not replace the required one. You cannot send roboRIO heartbeat frames or alter the enable/disable control system. PWM to Motor Controller, servo, or pneumatic control signals generated directly from a custom CAN device are not allowed ([R504]). If using a relay for solenoid, it must be driven by the roboRIO, not by a custom CAN device. Controlling vendor CAN motor controllers or PCMs/PHs from non-roboRIO devices is unsupported by vendors (CTRE, REV, etc.) and may lead to unpredictable behavior.
Power & Voltage Power your device through a regulated 5 V or 12 V source such as the VRM, PDH aux, or a built-in/external buck converter. ([R625]) Use or generate high voltages beyond FRC limits ([R614]).
Batteries Use power from the robot’s main system (PDP / PDH) ([R602]). Having a built-in battery, even a coin-cell RTC battery, using power bank with custom CAN device may violate ([R602]) because a custom CAN device might not considered as a COTS camera or computer. Avoid internal batteries unless explicitly approved.

Reference Checklist for Robot Inspector

  • Device is securely mounted and poses no safety hazards (no sharp edges, exposed wiring, or excessive heat). R203

  • Device does not create distracting light or sound that could interfere with other robots or participants. R203

  • Device is powered from a legal low-voltage source — such as the VRM, PDH auxiliary output, or an external/buck converter connected to an approved branch circuit. R625

  • Power wiring follows R625 : no direct taps into the main power path (Battery → Breaker → PDH/PDP).

  • Operating voltage complies with R614 (<24V)

  • Device contains no internal battery unless it is a COTS computing or camera device (R602).

  • Device is properly connected to the robot’s CAN bus.

  • Device may read the roboRIO heartbeat for status but does not send, modify, or replicate it (R714).

  • Device does not send any CAN frame that could enable or simulate enabling a motor controller (even if it's not roboRIO heartbeat) — doing so would be unsafe and violate R203.

  • Device outputs must not connect to any relay, motor controller PWM, or servo motor that controls a solenoid, motor, or servo. (R504, R712)

  • Wi-Fi must be disabled at all times on all custom devices (E301). Bluetooth must be disabled during match (R905).

Bluetooth use is a gray area — it may be used only in the pit for debugging or configuration, and must be fully disabled before entering the field (R905). Teams must be able to demonstrate or describe how Bluetooth is disabled before each match, such as with a firmware setting, jumper, or compile-time flag.

Custom CAN devices may read the roboRIO heartbeat for match data (for example, alliance color or match number) to detect whether the robot is on the field or enabled and disable Bluetooth accordingly.

  • RFID/NFC use is within robot only (R707).

  • Firmware or configuration is documented and can be provided to inspectors on request. Team can explain what CAN messages their device sends and confirm it does not affect robot enable/disable behavior.

  • Device powers on and off correctly with the robot’s main power.

  • Robot disables safely when commanded — no outputs remain active.

Clone this wiki locally