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.
We appreciate the notes about CANIVORE, though that is slightly orthogonal to the question of understanding what is currently on the bus. We’ll likely use this in some capacity in the future.
For reference, we’re headed into first comp with a drive base (swerve 8 Falcon + 4 CANcoder) using about 40% utilization plus manipulators (8 more Falcons + 1 CANcoder) adding up to ~75% utilization.
Yes, considering that Rev and CTRE have their desktop apps, I presume it isn’t top of the list to make a unified CAN DBC. Maybe that’s too be crawled through in the off season. Thanks!
There’s a bit of info at a very high level here FRC CAN Device Specifications — FIRST Robotics Competition documentation but it’s all closed source on the vendor-specific side. The Jaguar was really just a demo product to show off a TI IC so it was more open and is described at that link.
The Comma.ai Panda/Cabana looks like a cool system for cheap CAN debugging but I’ve never used it.
I think Vector tools (CANoe / CANalyzer) have a larger market share, but they’re also really expensive. Vspy is probably what CTRE uses internally based on past employment history.
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.