We’re wondering if anyone has a CAN DBC file, or equivalent format, for the FRC CAN bus? We have mostly CTRE motors and sensors on bot with the Rev PDH. We haven’t tried to snoop on the bus with cantools yet, but would like to.
This has come up as this is the first year we’ve used the SDS swerve modules and associated software release, so we are less familiar with the lower level control parts of our software. There’s a regular peak of CAN utilization (nearly 100% for a moment) in the drivers station logs every 250ms that we don’t know the source of. Our previous bots with west coast drive and CTRE PDP had much more stead CAN utilization, but lots has changed since then. Any thoughts on that are also appreciated.
I would also like a CAN database of FRC electronics, however I’m sure for safety reasons there isn’t one available.
You can probably reduce the utilization of you can bus by modifying how often each message is sent. I know CTRE has some good APIs for limiting the message rate. However, with swerve (8 motors + 4 encoders) I’m sure it’s very difficult to lower the utilization.
You can also use CTRE’s new CANivore which adds CAN FD (3-8x faster/more bandwidth than regular CAN). This will lower your CAN utilization by a lot.
5572 can vouch for the effectiveness and awesomeness that the CANivore provides and definitely recommends. We have 16 motors and 6 CANcoders on our bot this year and we’re so overloaded, our compressor wouldn’t run properly.
It’s probably less safety and more wanting to hang onto proprietary info (see: Spark MAX following Talons in 2019). Anyone who knows that the CANbus can be hacked also knows that there are many ways to bypass the disable state or inject their own CAN packets. Having a database file for encoder feedback, for example, would be pretty helpful for low-level debugging at times. Less of a problem now than it was before the REV and Phoenix desktop apps existed.
REV advertised Spark MAX following of Talons in early 2019, so that you could make use of the Talon path following algorithms or CTRE API while using NEOs. The feature was mysteriously broken a couple weeks later when CTRE made a firmware update that changed the CAN traffic coming from Talons.
Having competed in EcoCAR in college, I’ve seen my fair share of CAN DBC files (from GM, MobilEye, etc) and have used my fair share of CAN Bus tools from Kvaser, Vector, etc. These things are usually kept secret because of safety reasons as well as confidentiality.
In EcoCAR, the competition organizers often would install sniffing tools on GMLAN to make sure we weren’t injecting CAN traffic in places that could be seen as a safety hazard.
I wouldn’t expect CTRE, REV, or NI/FIRST to release DBC files. It probably wouldn’t be terribly difficult to decode CAN traffic though, since you have the tools to send known CAN messages.