Entering our 6th season our team is contemplating what new knowledge to pursue this year. We have never used CAN. From research of the new control system components, and motor controllers, I surmise that it is now easier to employ CAN, whatever it is.
I would greatly appreciate a 2015-oriented tutorial on the subject that is targeted toward those of us who are looking to wade in from the shallow end.
Specifically:
What is CAN (from an FRC perspective)?
Why would an FRC team use it?
How would a team use it with 2015 components?
What specialized skills/knowledge is necessary to implement it?
Basically a CAN bus allows bi-directional communication at about 1 Mbps between multiple devices. Until the 2015 season, the devices were limited to Jaguar speed controllers and you needed a bridge (2CAN or a Jaguar acting as a serial to CAN bridge) for the Jaguars to talk to the cRIO.
With the new control system, the RoboRIO has CAN built right in, and a number of the new control system components also use CAN. The new PDB has CAN-based current monitoring. The pneumatics module is controlled via CAN. New Talons also have CAN built in.
The implementation of CAN in the 2015-19 control system uses 2 wires (I believe they’re Transmit + and Transmit -). One set of those wires connect from the RoboRIO to one of the CAN components. Another device connects to the first device and so on. You need a termination resistor at each end of the system; the RoboRIO has one, and the PDB has one as well, but it can be bypassed if necessary. (I don’t see any reason not to have the PDB at the end of a system.)
As for programming, all the necessary libraries are in WPILib and are nothing like the CAN libraries from years past. I don’t know much more than that, but hopefully someone on a beta test team can explain further.
What is CAN? Basically, a way to daisy-chain components together. They will all have firmware, and CAN, among other things, allows you to see the status of various components.
Why would an FRC team use it? With the 2015 components having built in CAN on everything, I would recommend it.
How would a team use it? It has been made easy, trust me. It’s no different than wiring anything else now.
What specialized skills/knowledge is necessary? Nothing you don’t already know, really. There will be some new code you may need to learn if you want to utilize the more advanced features of CAN, and you need to know how to start IE to connect to the components. You can change the ID of various components (which will allow teams to use more than one PCM, although I don’t know if that’s legal or not) from there, and also update firmware.
Since I’m beta testing, I can answer any other questions too.
So every team using pneumatics will be using CAN by necessity, is what I gather.
And some of the new motor controllers, should they be approved, will use it.
If CAN is built into the power distribution panel does than mean every team will be able to monitor current on the driver station, whether or not they have other devices set up in a CAN network? (“CAN network” I assume is redundant like “ATM machine” is redundant…)
And by monitoring current, do we mean the current of individual circuits that connect to the PDP?
Perhaps a dumb question, but I’ll ask it: Is CAN limited to monitoring/gathering/sending data? How does it differ from PWM in terms of controlling devices?
From what I know, which is not a whole lot, I can answer…
CAN is a way to control motor controller/relays. Unlike PWM, CAN sends information, rather than just a “signal”, if you kind of get what I’m going at. You can send raw numbers/information over CAN whereas PWM can only send a number (very basically stated) 0%-100% (yes I know its 0-255, or 1023 on some systems). You can, for example, send a setpoint for a PID loop where the motor controller is running the PID. You can also collect sensor data. Everything is done over 1 CAN system, where each device is connected to each other, rather than every device is connected to the RoboRIO.
FRC is really pushing CAN because everything uses it. Every car, uses it, airplanes (I’m pretty sure), and a whole bunch of other systems use it. To get to know it in FRC is a MAJOR advantage for students going into the real world. CAN is a very good skill to have. Also, beside education, CAN can be useful for organization. Instead of running PWM cables everywhere, you have a CAN cable running to each device from another. CAN devices also sometimes have PID controllers, so you can save some processing power.
A team would use 2015 components as normal. The motor controllers are still control the motors, teams just send the information a little differently. Teams could also make use of the PID functionality in the motor controllers, although if you have more than one motor controlling things, then I don’t think the integrated PID controller is of much use. Teams could also monitor the power consumption of each device, and limit it if the power consumption is too high to avoid tripping the breaker or resetting the RoboRIO and D-Link. This is especially useful if they allow even more motors than they have in the past.
CAN, from what I hear and experienced, is both easy and hard. It’s easy to hook up and program, but it’s also hard to not screw up. I have heard that if a cable is loose, it can be really hard to detect and fix. As long as you somewhat know what you are doing, I think you will be fine. I have used CAN on Arduino and it is actually pretty straight forward. This can also be used to put external sensors that may need pre processing on the robot.
There’s nothing in the system that prevents using the relay outputs on the RoboRIO to control Spikes to drive a compressor and solenoids. I expect the rules will require using the PCM for the compressor, though.
And some of the new motor controllers, should they be approved, will use it.
Jaguars already use CAN, but they’re discontinued and sold out.
If CAN is built into the power distribution panel does than mean every team will be able to monitor current on the driver station, whether or not they have other devices set up in a CAN network?
That’s the goal.
(“CAN network” I assume is redundant like “ATM machine” is redundant…)
“CAN network” really isn’t used to describe the system; “CAN Bus” is the preferred term (and it isn’t redundant).
And by monitoring current, do we mean the current of individual circuits that connect to the PDP?
Perhaps a dumb question, but I’ll ask it: Is CAN limited to monitoring/gathering/sending data? How does it differ from PWM in terms of controlling devices?
PWM is unidirectional and for one type of data only. CAN is bidirectional and can send multiple types of data.
PWM speed controllers only respond to the pulse-width that tells them what proportion of input voltage to send to the motor/load. CAN speed controllers can receive different types of commands (voltage vs. current control or whether or not to use closed loop sensors) and send various types of data back to the robot controller, as well.
CAN is a digital serial data bus. Somewhat like USB but also a lot different. Each device on the bus has a node number between 1 & 63. 1 is generally reserved since a lot of devices come out the box addressed as one. If you car has an OBD-II port on it, it uses canbus.
The advantages of using can is you can control multiple devices from one pair of wires & transmit multiple fields of data to & from each device.
What does that mean for FRC? More complex motor control with the right controller. You can implement the PID control inside the motor controller. With the 2015 system you will have to run CAN for the compressor. (Even if your code does nothing, the module still gets its enable over the bus). You can get power monitoring from the PD over CAN. Admittedly this includes some presumption about the 2015 rules
What are the disadvantages of CAN? 2014 & earlier, there was some programming gotchas that could take the canbus down. Wiring errors on the bus including the sometimes flaky Jaguar connectors would take the bus down. Power brown outs on the Jags could take the bus down.
Having 64 devices on the CAN bus is an artifact of the way the CAN MessageID field was partitioned for Jaguar, it isn’t really a CAN thing.
A packet on the CAN bus has a number of fields including the MessageID field. The MessageID field is either 11 or 29 bits long (29 bits in our case). CAN devices sync up on the bus… if a node determines it wants to transmit a packet and one is being transmitted it must wait for the prior packet transmission to complete before all nodes with a packet may transmit their packet. The CAN bus signaling and the field ordering in the CAN packet handles arbitration, basically, the lowest-valued MessageID wins.
When defining Jaguar and how it would use CAN, the Luminary Micro team had to consider how the MessageID field would be partitioned. They created a number of subfields and field values to arbitrate important messages (safety related), provide a framework for motor-controller functions, provide a firmware update mechanism, and provide for future expansion (CAN being used by other vendors). The fields defined include a vendor value, device type, function class, function sub-class, source node, destination node, etc. The encoding of 0 for most fields indicated a system or safety function (e.g. MessageID = 0 was “halt” if I recall correctly).
As it turned out, the node fields ended up at 6 bits, each. Node 0 was reserved for broadcast (all nodes accept), node 1 was the factory value for a Jaguar (so it was recommended that 1 not be used), and so node values 2…63 were available for use.
Having 64 devices on the CAN bus is an artifact of the way the CAN MessageID field was partitioned for Jaguar, it isn’t really a CAN thing.
Presumably the RoboRIO CAN bus will be compatible with the Jags… Hanging 64 nodes on a CAN bus wouldn’t be a First thing anyway. :] Is anybody testing what is the practical limit with the new control system? We have run 6 Jags successfully with the old system.
We’ve Beta tested 15 Jags in a CANbus chain (plus the roboRIO/PCM/PDP) and a couple of PWM driven Jags as an aside.
They weren’t all on a robot, but were powering different motors as a group exercise…
Used about 20% of the available CAN bus bandwidth in %V mode.
