I’m currently investigating whether I can get a custom CAN device running on the RoboRIO’s network. It seems fairly easy to get a CAN transceiver receiving frames, however I’m having trouble tracking down a spec that defines the partitioning of the ID fields and other related comms info which I would need to make sense of the information of transmit my own. After doing some digging I found a whitepaper that NI published for a protocol called “CANOpen”, but I can’t manage to find anything that says definitively whether the RoboRIO’s network implements that protocol or something else.
Can anyone give me some insight here? In particular, I’m looking for a specification and/or reference implementation and – if possible – a link to the implementation that the RoboRIO or one of the commot CAN motor controllers uses. My next order of business is figuring out how to access the custom node’s data via WPILib, but that’s not my immediate concern.
R78-A says it’s legal (blah blah blah “last year’s rules may change for next year”). I would suggest starting with CTRE; as they design all but about two or three components commonly seen on an FRC robot’s CAN bus (though I’d argue Jaguars and SD540Cs are pushing the limits of “commonly seen”), they probably know the details you’re looking for.
I was looking through the WPI library for LabVIEW, and I didn’t see anything that references CANopen. The context help for the WPI_CAN_Send.vi mentions that the VI only supports extended frames (so it should be using the Extended Frame Format).
In terms of implementation, the WPI CAN VIs look pretty simple. The send VI takes an arbitration ID, an 8-byte array of data, and a period. The receive VI takes an arbitration ID and a mask for the ID, and returns an 8-byte array of data. Those two VIs, along with the VIs for the TalonSRX, use a VI called NetComm_CAN_Send (and Receive). It looks as simple as supplying an arbitration ID, the data, and timing.
CTRE also has a github page for their code. They have the C# code for their HERO board available, and I think it includes their CAN implementation.
I hadn’t realized that the HERO code included their CAN implementations! I think this PCM code is the most clear reference: https://github.com/CrossTheRoadElec/HERO-SDK/blob/master/CTRE/LowLevel_Pcm.cs. I haven’t yet found the details of their “CTRE.Native.CAN.*” methods, but I haven’t spent much time looking into it yet. The important bits are what it does to produce the arbitration IDs and format other data, which seems to be there in the file I linked to.
It would certainly be nice to have a technical spec, but this is a good start. It definitely seems quite simple (fingers crossed!). I also sent them an email this morning, so hopefully they’ll be able to provide me with some details of the protocol spec. Regardless, this should get me most of the way.
I’ll post back here once I have an implementation working.
I asked a few more follow-up questions, but I think this tells me pretty much everything I need to know to implement a custom CAN device. I’ll try it over the next few days (time permitting) and report back my findings in case others come upon this thread in the future.
I finally found the Message ID field mapping defined back in 2008. They are:
28:24 - Device type (0=broadcast, 1=controller, 2=motor controller, etc.)
23:16 - Manufacturer (0=broadcast, 1=NI, 2=TI, 3=DEKA, 4-255 reserved)
15:6 - API (divided into 2 sub fields, API Class and API function)
5:0 - Device number
Since CAN arbitrates primarily per message ID, lower valued message IDs are prioritized before higher number ones. This is why broadcast is encoded with 0 and it appears in all fields. We need broadcast to stop or reset all nodes (and not be delayed by other CAN bus traffic).
I found this information in the Reference Design Kit (RDK) materials on the CD that was part of the releases for the Jaguar. TI used to have two products based on Jaguar… the motor controller (module) and a version for developers to do a deeper evaluation and may might want to use it as a reference design (included motor controller, motor, an interface board that connected to Jaguar over CAN).
The CD can be found from the TI web or other archives. The RDK part number was: RDK-BDC24-CD-### (many releases, so ##s may vary). Inside the CD, find SW-RDK-BDC24-UG-####.pdf.
