Who's on the CAN bus? Who will be?

[bobbysq]

WPILib’s documentation contains a list of manufacturers who have been approved to have manufacturer IDs set aside for use when addressing CAN devices in the FRC control system. I thought it might be interesting to do a breakdown of who these companies are, and what they’re using the bus for - or what they will use it for.

1 - NI

We start off with NI, the company that makes the roboRIO. It’s fairly obvious what they’re using it for, given that it’s been required on all FRC robots since 2015. Also of note is the Digilent DMC-60C, which I assume used this ID as they’re owned by NI… assuming they bothered to change it from 4.

2 - Luminary Micro

Two in and we already have a bit of an interesting one. In 2009, Luminary Micro released a motor controller called the Jaguar, which was the first CAN motor controller available in FRC. That same year, they would be bought by Texas Instruments. In 2012, IFI would acquire the Jaguar design, making Luminary Micro’s ID doubly obsolete. Despite this, it seems that the Jaguar remained on Manufacturer ID 2 until CAN support was discontinued for the 2018 season, as evidenced by no entries for TI or IFI/Vex on this list and the WPILib Jaguar code from 2016.

3 - DEKA

Dean Kamen’s company. As far as I know, this is unused, and I’m not sure when it would be used seeing as DEKA doesn’t, and hasn’t to my knowledge produced any FRC electronics. Perhaps it would be used if FIRST themselves had made a CAN device? Maybe DEKA had some CAN stuff lying around at some point that they thought would be useful to donate?

4 - CTR Electronics

CTRE is the company behind the Talon SRX, Victor SPX, and Talon FX motor controllers, as well as the outgoing Power Distribution Panel and Pneumatics Control Module, introduced in 2015. Their ID has seen plenty of use over the years, and while their PDP and PCM will mostly be replaced next year, there’s certainly more to come using this ID in the future.

5 - REV Robotics

REV is best known for their SPARK MAX motor controller, which was their entry to the CAN bus in the 2019 season. Their upcoming CAN products include the Power Distribution Hub and Pneumatic Hub, the incoming replacements for the aforementioned CTRE control system components.

6 - Grapple

I can’t find anything about this company. I’ve only been able to find one FRC-related thing related to an organization called “Grapple”, and it’s this GitHub page, containing a single repository for an outdated fork of Jaci’s Pathfinder, the precursor to PathWeaver. I don’t know if it’s the same Grapple that requested the ID, but I guess it’s theirs if the other Grapple won’t use it.

Edit: It’s now been confirmed that the Grapple listed in the CAN spec is Jaci’s Grapple. She had planned to make CAN stuff but plans unfortunately seemed to fall through.

7 - MindSensors

MindSensors made the SD540C motor controller, legalized for the 2017 season. Their manual is in Comic Sans. That should tell you everything you need to know about it.

8 - Team Use

This is, presumably, open to any team putting their own CAN device on the network.

9 - Kauai Labs

Kauai Labs is best known for their NavX line of IMUs. However, they don’t use CAN. What they do have that uses CAN, is their VMX-pi robot controller, which supports WPILib and CAN. They released it in 2017 as an alternative to the roboRIO, and while it likely doesn’t see much FRC use due to that, it has its own little ecosystem under Studica, and should be compatible with existing FRC hardware.

10 - Copperforge

Copperforge has, so far, released one FRC product, the Lasershark LiDAR sensor. Currently, they have no FRC-specific CAN products, however they did plan to at one point release a CAN version of the Lasershark and have a USB CAN interface board available called the VulCAN, however it does not seem to have any FRC-related software at the moment, ultimately leaving this ID unused. As far as I know, they are still an active company, so there could very well still be something in the works for a CAN device from Copperforge.

11 - Playing with Fusion

Playing with Fusion released the Venom motor with integrated controller for the 2020 season. It supports CAN, as does their time-of-flight sensor, released around the same time.

12 - Studica

Studica is probably best known in FRC circles as a redistributor of FRC parts for the Canadian market. However, they also have a non-FRC control system based around Kauai Labs’s VMX-Pi controller as mentioned above. Included in this is their own motor controller, the Titan Quad. While it’s not FRC legal, it does have a library available for WPILib, meaning their ID is used.

I hope this breakdown of the currently used CAN IDs was interesting. Hopefully, this can provide some idea of what’s available now, what there may have been plans for, and what will be available in the future. This is my first time making a post like this, so please let me know if there’s something I could improve on formatting-wise or if I got something wrong.

[mdurrani834]

If I become a VENDOR what do I have to be to get on the can bus?

[CarlosGJ]

Basically? Email FIRST and convince them that you’re serious enough to deserve a CANbus manufacturer ID reservation. There’s nothing on the technical side that requires you to have your own ID. You could build a device that uses a manufacturer ID of, say, 100, and it’d work fine. The only thing that the official registry does is prevent address collisions.

[bobbysq]

@CarlosGJ

There’s nothing on the technical side that requires you to have your own ID. You could build a device that uses a manufacturer ID of, say, 100, and it’d work fine. The only thing that the official registry does is prevent address collisions.

Interesting. Do you know of any devices that currently do this or have done this (after making it to market) before getting a proper ID assigned?

edit: digilent moment

[john3928]

@CarlosGJ

You could build a device that uses a manufacturer ID of, say, 100, and it’d work fine.

Right up until (you/somebody else) had another device with ID=100 together with yours.

@CarlosGJ

The only thing that the official registry does is prevent address collisions.

Exactly. If you’re not going to be registered, you should at least document your ID and ideally make it configurable.

I had a similar issue when tweedle dee and tweedle dum came to install my cable Internet. Their router was hard-coded to be 10.0.0.1 which for some reason they didn’t know. Well I already had a 10.0.0.1 on my home network. They fumbled around for hours.

[Starlight220]

I’m interested how this will affect the new control system in 2023, as regular CTRE Talon status frames would have higher priority than the REV PDH etc. Will they swap between CTRE’s and REV’s listings (is that even possible?) or perhaps move REV (or only the new control system components) to a higher manufacturer ID (2 or 3 are most likely)?
Unless they change the spec/scheme… which they won’t.

[bobbysq]

I don’t believe these IDs give any manufacturer “priority” over another, it’s just a part of the full CAN address in addition to the user-defined ID. If it does, the current PDP already has a lower priority than all motor controllers anyway - see the section on “Device Type”.

[jtrv]

Is 70% CAN Bus Utilization Bad?

There is not. That’s one of the flaws with FRC’s CAN addressing scheme: the vendor packet priorities are essentially ordered by vendor ID, so all of CTRE’s PDP messages preempt REV’s motor controller messages, as an example (I forget the exact vendor assignments). It’s a legacy partitioning scheme that originated from the CAN Jaguar; existing vendors have had to conform to it. REV, CTRE, and some other people were looking into improving this at one point, but idk if it made it past the dra…

[Will_Toth]

On the CAN bus, any ID with a lower number will have priority over any ID with a higher number when the messages are set at the same time (or if they are queued at the same time and the queue is correctly implemented as a priority queue).

So if you look at the diagram of the CAN ID bit fields from the frc docs:

The further to the left the field is, the more it impacts the priority of the message. So the device type field has the highest impact. For example, any motor controller frame will be higher priority than any Power Distribution frame. So a CTRE Talon frame will always have priority over any PDP frame by any vendor. But it does mean any CTRE frame for the same device type will have a higher priority than a REV frame for that same device. So a Talon FX will have higher priority than a SPARK MAX, which has higher priority than a PwF Venom. Also a SPARK MAX with device number 1 will have a higher priority than a SPARK MAX with device number 4.

This doesn’t have too much of an impact unless you are trying to do things real time or if you start overloading your CAN bus.

[auscompgeek]

@bobbysq

Digilent DMC-60C, which I assume used this ID as they’re owned by NI…

Ooh boy, do I have a surprise for you.

Digilent have, uh, helpfully documented the DMC60C CAN frame protocol (or at least most of the frames) in a PDF linked from the DMC60C reference page. There, we can see on the first page (highlighting mine):

… that Digilent arbitrarily decided to use manufacturer ID 6, without asking FIRST. IIRC, at the time of release, Grapple had already been assigned ID 6.

Suffice to say that there was a lot of controversy around the DMC60C.

[auscompgeek]

@bobbysq

Victor SPX

On this note, the astute may have noticed that you can actually have a Talon SRX and a Victor SPX with the same device ID on the same CAN bus, despite them being both CTRE motor controllers. What’s up with that? A bit of trivia…

By my understanding, the Victor SPX does use CTRE’s manufacturer ID, but does not use the motor controller device type ID (2). Rather, it appears as though they use the robot controller device type ID (1).

I guess this means we won’t be seeing a roboRIO replacement from CTRE any time soon?

[bobbysq]

@auscompgeek

I guess this means we won’t be seeing a roboRIO replacement from CTRE any time soon?

They do have the HERO board, which would fit into the category of a “Robot Controller”. I guess they must use an entirely different CAN protocol for HERO stuff if that’s not a problem, then. I know they don’t use FIRST’s heartbeat system, so that wouldn’t be too surprising.

[bobbysq]

We have a development!

13 - The Thrifty Bot

Added 3 days ago, The Thrifty Bot, distributor of bearings, elevator kits, and shaft collars now has a CAN ID! Currently, their only electronic product is the Thrifty Absolute Magnetic Encoder, an analog absolute encoder, but this could indicate a CAN device is coming from them eventually. Perhaps a CAN version of the encoder? Either way, it looks like exciting things are ahead for TTB.

[gdefender]

Kauai Labs was acquired by Studica over the summer

[s1900ahon]

Some additional detail:

The first version of the Message ID format and vendor assignments were made in the summer of 2008 during Jaguar’s (v1) development by Luminary Micro. The CAN features were not allowed for use in FRC in 2009.

DEKA was provided an assignment in the first version due to their involvement in the control systems components introduced in 2009 (PDB, digital and analog interfaces). These were designed by DEKA employee Eric VanWyk. There was hope DEKA could contribute to the FRC CAN ecosystem.

Note that the Message ID format was defined in the sprit of FIRST coopertition. The vendor field did not need to be included if one was Jaguar-centric. Rather, the format was defined recognizing the benefit that CAN could provide in the future, but it would need cooperation among suppliers.

More than 10 years from definition, less than 16 vendors of a max 255 are assigned. And one of the assignments is for team use.

[bobbysq]

14 - Redux Robotics

A newcomer to the supplier realm, Redux Robotics has just launched with two CAN products currently announced - the HELIUM encoder and BORON gyroscope! From what it sounds like, there may be even more CAN products to come from them in the future.

[jnicho15]

Happy to see they are open with their CAN protocol (although it looks like their dbc link is broken CANandcoder — Redux-Documentation 1.0.0 documentation).

[techplex]

Looks like a few more additions:

Add CAN IDs for AM and VH