The Future of Onboard Realtime Communications

At first there was nothing; motor commanding was unidirectional, and without form; and darkness was upon the face of FRC.

And then Luminary Micro said, Let there be CAN: and there was CAN.

And FRC saw the CAN, that it was good.

Those of us who were around in the ~2011 timeframe remember how revolutionary it was to be able to run control loops on motor controllers, to set parameters on them, and to retrieve telemetry.

Fast forward ten short years, and the FRC CAN ecosystem has exploded: not only are nearly all legal motor controllers CAN-capable, but many sensors and an increasing number of coprocessors have CAN interfaces. This, of course, leads to increasing congestion. CAN is, after all, a bus, and whenever any device sends a message, it occupies the whole bus for a millisecond or so. These days, approaching 100% CAN bus utilization is a real possibility for some teams.

I’m interested to see what the community thinks is the best way forward. Bear in mind, when I say “best”, I don’t just mean “most technical capability”, I mean the whole cost vs. capacity vs. complexity vs. reliability trade.

  • CAN (it’s fine as it is)
  • CAN-FD (5 Mbps)
  • Multiple CAN busses (one safety-critical bus for commanding motor controllers etc., plus one or more for noncritical data)
  • Multiple CAN busses (all the same)
  • RS-485 or derivatives (Profibus, etc.)
  • 100BASE-T1, or some other variety of Ethernet
  • Other (explain in comments)

0 voters

1 Like

Me, I’m gonna vote Spacewire. There’s not a chance in heck of it happening, but it’d be so cool if it did.


I don’t really think it matters as long as it supports as much bandwidth as teams want to use. I’m a bit surprised we’re already at the 1mbps ceiling of CAN personally, but it can be hard to nail down why. That said, I’m also a little surprised we’re limited to 1mbps still.

I personally vote for anything other than CAN, just so we don’t have to keep reading CAN topology threads every week.

Ideally, I’d like a RIO with 24 USB-C ports. Realistically, we’re probably not getting that.

My thought is - we are already plugging all our speed controllers into a central device. And then we are plugging them all into each other. This seems redundant. Simplify it. There’s no real upside.


Just gonna throw out my hot take: I wish we had used some sort of connection that could be run individually to each motor controller instead of CAN, especially with the two legal CAN brushless motor controllers requiring a more distributed approach to electronics. As it stands, you need to run a CAN wire all across your robot and all the way back to the PDP (unless you have your own terminating resistor) in order to use brushless motor controllers to their fullest potential, unless you make design compromises to either keep all motors where they can’t be hit, lose out on motor-saving current limiting by running PWM, or lose the weight advantage by using a brushed motor.

CAN’s nice, but it’s clear we would have been better off if we had more of a “Super PWM” of sorts that would allow all the features of CAN without the drawback of having your whole robot at risk if one part of the wire goes down.


Without throwing away every device we already have, or active CAN “filters” to separate the live/non-live into separate buses, two-bus isn’t adequate. CAN-FD for 5Mbps could work sure, but do the devices we already have support it?

The only sensible solution in my mind is encapsulation and mitigation. Put existing CAN traffic over discrete sub-buses using any significantly faster / lower latency bus as the transport method, and then re-transmit. That’ll keep sub-bus latency and utilization low, but not make every CAN device we’ve invested thousands of dollars per team into, useless.

The obvious methodology is RS485 based (and encapsulating the 29-bit CAN packet within 4-5 RS485 8N1 packets) on the new REV Control System but they’ve said:

Even as-is it’s possible to hit near 90% CAN utilization and the reflectance of poorly wired buses will cause latency and retransmissions. CTRE and REV will probably want to get those CAN status frame tuning guides going sooner rather than later :stuck_out_tongue:


No love for MIL-STD-1553B? Oh, future, not past…

EtherCAT would be pretty sweet, but I bet the transceiver price points are much higher than CAN.


Combine the RIO and PDP into one, beef up USB PD, and you can power and control all motors with USB C. Forget everything else, USB is all we need.


USB PD is limited to 5A. Maybe for FTC-sized robots, but not FRC (even at 48V, that’s the equivalent of a 20A limit at 12V, and FRC motors go well in excess of that).


I’ll bet the 1553B transceiver price point is much higher than CAN as well :slight_smile:


Speaking of USB, at some point I want to try a CAN version of this test: (language warning)

I have a feeling it won’t go over quite as well, but it might be interesting to see - and if it does go over well it may alleviate some people’s concerns (including my own) about running CAN in non-standard configurations.


Yes and no. It’s technically limited to 100W with a current draw maximum BUT that’s not the full story. The USB-PD spec has provisions for vendor specific mitigations and it’s like all of the USB standards in that everyone is doing their own thing with it. Dell actively sells chargers that hit like 120W today.

That’s also not the full story. It’s an evolving standard and the current (no pun intended) working groups have met on a 240W standard: USB Charger (USB Power Delivery) | USB-IF

This will get higher or we might see a derivative connector specific to high power draw applications come along soon. There are a few use cases for this that are industrial but align with FRC.

Current implementation is pretty darn near optimal if you ask me.

But I like ethernet. Ethernet all the things. Cheap transceivers, abundant COTS, fairly flexible cabling at lower data rates. Lots of debug tools.


Plus unless there is some alternate USB-C connector that I’m not aware of, I’m not sure I would trust it to not work loose on a robot from vibration and collisions. At least Ethernet has the little locking tab.

Multiple CAN busses has a lot going for it. Mapping out a future path to something like BroadR-Reach might make sense, but CAN-FD capability is a no-brainer here. Personally, I’d like to see the radio become the locked piece of kit on the 'bots, with compute opened up. This would mean the replacement radio would have Ethernet ports, CAN ports, and perhaps BroadR-Reach (or similar) ports. This would make it fairly central, as is the PDP – so an external antenna might also be a good addition. In this model, the radio handles the safety stuff and the compute only gets access to CAN via the radio.

There is. Haven’t used it myself though.

Anyway, all of this is moot if NI doesn’t buy in. You can hedge your bets on what they’re gonna do with the RIO 2.


Reverse-engineer ambitiously.


At risk of a tangent, you should consult some of the numerous other threads regarding CAN connectors and topologies. There are ways to better protect the CAN bus.

Depending on the safety mechanism used on CAN, CAN messages wouldn’t necessarily need to pass through the radio, the radio might just need to be on the same bus to send the proper enable messages.

Also, this only works if all actuators are CAN devices, it would disallow traditional relay or PWM actuator controls. One option to address this could be to allow certain approved compute devices (e.g. the Rio) to control via PWM (and they would have approved software that would listen to the CAN messages for enable control assuming the above implementation).

It shouldn’t be that major of a barrier, but note this approach would also mean radios would be required for all benchtop setups for programming testing, etc.

There are some downsides to moving to an open compute system, namely that a standardized processor enables greater reliability (most cheap COTS things are much less reliable than a Rio), spare parts, teams to more easily help each other with issues, a standardized library stack (WPILib), etc. Teams today pretty much already have the ability to go open compute (e.g. Jetson, Pi, etc) and drive CAN motors from those other devices (with the Rio providing the safety controls), but most teams just use the standard setup because of support reasons and they don’t really need something more powerful.


Agreed. Another possibility is more (approved) things like PCM or CANifier, except with the safety/disable logic and able to control things like relays.

The point about the ability to use other compute today is a good one. I know some teams would be really impacted if that were to go away.

The points about the downsides are also valid. But, there are also upsides.

The radio is pretty clearly the weak link in the control system, so it needs updating in any case. Getting all the regulatory approvals can be a huge pain/expense, except there are modules that can be used (internally) that are already certified. Putting a small battery or supercap into the radio would be helpful as well.

WPILib is great, and it gets better each year. There’s a ton of good stuff in there, and it is wonderful that it is open. If the compute H/W were opened up, I suspect most teams would choose to stay on whatever hardware was supported by WPILib (and/or LabView). This would apply to the H/W as well I suspect.

1 Like