Legality of Motor Controlled (Entirely) by Coprocessor in Official FRC Competition?

Would it be in violation of any rules to have a motor that is controlled by a coprocessor (such as a RaspberrryPi) that is not connected to the RoboRio? The motor would respond to the robot enabling/disabling, however the RoboRio won’t be able to directly control it.

For example, a motor controlled through PWM with a RaspberryPi. The motor is not connected to the RoboRio, and the RaspberryPi is not connected to the rest of the robot’s radio. The only communication between the RaspberryPi and the RoboRio would be through a wire that is either receiving current or not (boolean true/false) which tells the Pi if the robot is disabled.

Simple diagram of this:

Or with CAN bus:

The Pi would use the single-bit communication to determine if the robot is disabled or enabled (The RoboRio will switch off current after disabling and back on while enabled), so that the motor can be stopped without completely turning off power to the Pi.

With this, the robot would still obey the RoboRio’s enable/disable commands. The communication between the Pi and the CAN Spark Max would be PWM or CAN bus (hosted by Pi, not RoboRio).

Would this be legal, as the motor is not directly connected to the RoboRio? The purpose of this wiring system is to minimize the amount of data being transferred between this and the rest of the robot (notice all wires go to PDH and do not carry data, besides single-bit communication wire).

Edit: Many people are saying this is illegal. Is there another way of controlling a motor like this that minimizes communication/data between motor controller and the rest of the robot?

Definitely illegal, you are going to have to go through the rio as FIRST wants you using the mandated FPGA image which handles enabling/disabling hardware. When you circumvent the FPGA you are introducing more points of failure - ie what if the enablement pin on your pi gets stuck high?

1 Like

To add specific rules onto this. R712 requires that all PWM controls happen through the roborio, and R714 requires that any CAN motor controllers are hooked up to a CAN bus that is also connected to the roborio.


See R712 and R714.

You are allowed to have a CAN motor controller respond to CAN commands sourced from the Raspberry Pi, but it has to be on the same CAN network as the roboRIO, so that the roboRIO’s enable/disable works.


Based on your diagrams, this is illegal.

However, with CAN, the only signal that needs to come from the roborio is the enable heartbeat signal- all other commands can come from any device, including a raspberry pi. As long as the roborio is on the CAN network (and you have a spark max initialized in code to get it to start sending the heartbeat), you can configure and operate the motor controllers entirely from the raspberry pi.

Sniped by all the above

1 Like

@connor.worley @Thad_House @Joe_Ross @Ryan_Blue thank you for your response.

Is there any other way to control a motor that minimizes data/communication between the motor controller and the rest of the robot?

You can control a motor with PWM. Then its pretty much independent of all other devices. But if you need CAN, your options are the built in CAN bus, or a CANivore. No other legal for FRC option exists currently.

1 Like

What problem are you trying to solve?


What might cause this to occur?


literally anything

poor programming to cosmic radiation bit flip

The reason for occurrence isn’t important here from a legality standpoint.


Shorts circuits due to metal shavings making their way into your robot are a real possibility. Depending on your IC, you might accidentally run all your outputs high when resetting (@josesantos throwback to mechatronics class). Bugs in the code that reads the pin are also possible.

1 Like

Can’t speak for OP but the question isn’t unreasonable. We all seem to trust the RoboRIO more than a pi. There are some good reasons for this and some that don’t make a lot of sense to me.

That being said - the rules are the rules until they get changed. Some of us remember vividly the time before it was legal to connect a co-processor to the same CAN-bus as the RoboRIO (and the complex conversations and wrangling it took to get the rule changed) so it can tickle the electrons to make things move.

@Joe_Ross hit the nail by asking what problem is trying to be solved.

Knowing that would probably lead to some additional suggestions and who knows, rules can change. They aren’t as static as some in this community like to believe. Just a year ago, SocketCAN on the RoboRIO was a fun experiment and not legal either.


Agree with the above generally - this six word questions is crazy deep actually, hitting on the reliability and failure analysis that goes into being able to say, with great confidence, something is “Safe”.

If the intent is to learn why the rules are the way they are (and if there’s a valid reason to advocate for changing the rules), it’s a great question to dive into.

If it’s more of “how to build a robot in 2023”, I’ll admit it’s not quite the right question… the rules are what they are.

Another +1 for “what are you looking to accomplish”. @OP it “smells” like you might be one or two steps too far down your current line of thought - a quick backtrack might set you on a more viable path for FRC purposes.