CAN == Controller Area Network. It's a multicast serial network protocol and bus specification. In this case CAN 2.0A/B, which is a little more flexible and faster. The Jaguar flyer declares a 1Mbit/s rate, but doesn't bother us with piddling details like what application protocol they're planning on using.
In practical terms, it's a 3-6 wire bus that you'd connect all of your speed controllers and other CAN devices to, either daisy chaining through devices or branching out from hubs, but avoiding loops. Then the cRIO would talk to EVERY device on the bus, sending it commands and receiving data back at a reasonably good data rate. It's all digital, so you worry much less about noise mucking with your analog signals or interrupts or speed controller frequency drift mucking with your commands to the motors. Plus, you could get feedback from the speed controllers if they're equipped to sense current, etc.
Primary downside would be that you're now running (probably) 5 wires to each speed controller, sensor, etc. Plus every new device on the network reduces the speed you can talk to the others. And finally, bus termination, addressing, and a host of other details become pretty important to keeping communication fast and stable.
If you want a slightly technical description in more MechE terms, a CAN bus is something like if you had an intercom system in your house, where your only option was to talk to all the stations at once. Since it's a multicast bus, you have to announce just who your messages and replies are intended for so a conversation would go something like: "Hey Tom, I need your credit card info to pay for this spiffy new FRC controller." To which you might reply, "Hey Kevin, I'm still broke from the last FRC gadget you had me pay for!" And so on.
Also, since it's a multicast bus, you might get two people trying to talk at once. This could obviously cause confusion, which CAN solves in a few different ways, depending on the physical implementation. The simplest is that some messages have a higher priority than others and basically talk over the other messages. If a speaker hears someone talking over them, they wait till the end of that message then try again. There's various other methods, but the upshot is that everyone gets their say eventually, but some people have a higher priority than others.
The downsides I listed above equate to problems like trying to talk to two people with the same name, throughput problems if 40 people are all trying to talk at once, and physical problems like someone falling asleep with his finger on the Speak button and snoring over everyone. Of course, it's still better than the tin-can phones and telegraphs we're currently using.
Response to Adam:
Quote:
Short Version: CAN is basically a serial communication standard that allows devices to be daisy chained.
Controller -> Device -> Device -> Device -> Device -> Terminator
|
Other network topologies are possible if you're using repeaters. Industrial versions can admittedly get a little pricey, but if FIRST is making us a bunch of other stuff anyways it'd make some things a little easier.