Is it possible to control CAN motor controllers from a coprocessor?

I have been experimenting with running CTRE’s Phoenix Java library on a Raspberry Pi with a CAN bus adapter, and I was wondering if it is possible and/or legal to control CAN motor controllers with it on a robot (for something like path following)? I know the signal that enables/disables the motor controllers would still have to come from the roboRIO to be competition legal.

Yes. Very legal and very cool.


Suggest that you read and re-read the rules.
You can have the coprocessor you are suggesting; however all motor commands are requried pass through the RoboRIO!

There may be a way that your coprocessor can pass commands to the RIO, and the RIO can then pass to the motor drives. I don’t think that is what you intended.

I think there is a distinction between providing a setpoint to a motor controller and “enabling and disabling” it. I believe it can still be enabled and disabled from the roboRIO.


^ another relevant rule.

The way I’m seeing it, it’s fine for a coprocessor to “inject” commands into the CAN bus, as long as the RIO is the device controlling the heartbeat. I may be wrong about this, since I don’t know the specifics of the CAN bus, but I’m pretty sure that any device can send a signal to any other device. As long as the RIO can send a “STOP” signal to the motor controller, and the motor controller complies, I think you’re within the rules.

Cool beat me to it …
… I think that the key is the last statement , “operating point for all CAN motor controller closed loop modes fit the intent of R57”

As far as learning the ins and outs of CAN, I think you have a great exercise.
I still don’t suggest attempting this for a competition legal robot.

Then again, reading R68 makes me doubt myself. “They shall not be controlled by signals from any other source” makes me think that that’s their intention with R70 as well.

It is definitely competition legal, as long as the CAN devices are running FRC firmware and the enable signal is coming from the Rio, the control commands can come from any device. Team 900 did it last year using a Jetson (which is why Marshall responded the way he did).


I’ll stand down then.

Even though it is legal, it would be nice if they cleaned up that section of the manual so there wasn’t any confusion. Just a blue box saying that it’s legal to send commands from a coprocessor, as long as the enable/disable comes from the RIO, would be nice.

Since the roboRIO and the coprocessor would both be running Phoenix, how would I ensure that that the enable signal is coming from the roboRio?

I think you missed the “PWM” distinction in the motor controllers, combined with a dash of “you think long, you think wrong”.

1 Like

The enable signal doesn’t come from Phoenix, it comes from the NetComm process on the Rio that talks to the DS.

Cool. Just out of curiosity, how would the motor controllers be enabled in a non-FRC application since there is no longer any non-FRC firmware?

We would have done it this year too if it hadn’t been for that meddlesome virus.

OP, we have several papers out talking about this, both for competition and not for competition:

1 Like


1 Like

More specifically, it is the RIO failing to send a “safe to go” signal. A subtle difference, but if for example the Rio crashed we’d want motors to stop right then and there.


How do you assure the robot inspector that there isn’t any way that your custom controller can’t spoof the “safe to go” signal? I’m not meaning to imply that you would, but it seems the architecture would invite the question.

While possible, I don’t think that this is much of a concern because it would require reverse engineering the CAN protocol that the NetComm process uses.

There are more ways to break the rules and be undetectable to an outside observer than could ever possibly be 100% covered. Spoofing the enable signal is likely very easy, there are even exploits to tell the Rio that it’s enabled from user code. There’s always ways around barriers, there has to be some level of trust.

Spoofing the enable signal won’t provide you a competitive advantage and it’s a safety measure, so teams wouldn’t do it. If anyone noticed your robot moving before or after the buzzer, there would probably be a very long chat with an FTA and inspectors in your future.