Being a controls guy who was converted from Mechanical, can someone explain what “CAN” is and why it is so beneficial?
Intelitek Uses CAN on our industrial line of CNC products.
Short Version: CAN is basically a serial communication standard that allows devices to be daisy chained.
Controller -> Device -> Device -> Device -> Device -> Terminator
Long Version: http://en.wikipedia.org/wiki/Controller_Area_Network
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:
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.
CAN is why it takes so long to feel comfortable driving a hybrid electric vehicle.
Nothing is connected to what it controls! :ahh:
-q
(oh yeah and it carries control signals about airplanes and farm equipment, along with the occasional power plant, generator set, etc… the company I’ve worked for for the past three summers makes (among other things) CAN enabled industrial control modules)
Through the private beta test channels, I asked these types of questions. They just released some test data publicly, which show a very nice linear response without any slow starting when driving a CIM motor. http://forums.usfirst.org/showthread.php?t=10182
I’m bumping this thread to link to the Luminary Micro’s Jaguar Motor Controller Characterization thread on the First Forums and attaching a copy of the excel sheet (for those who are not FIRST Forum members). This is obviously very important data for everyone to consider when controlling their robot and I am glad they can provide it to us so early in the process (thanks Joe Hershberger ).
EDIT: I started writing this post before Joe Ross posted (beating me to it) but got side tracked. I guess we think alike for where to post this data in this older thread.
A few comments: I am impressed with the linearity of the CIM Speed vs Pulse Width. However, I am not sure (and not qualified to speculate not a ME) how well this will linearity will translate to speed of a motor under load (normal 4 motor drive of 130 lb bot). In my experience, at lower powers on the victors the drive motors just hum so will the jaguars just hum (depending on gearing obviously) for a the lower portion of these graphs. Maybe a fast rise like the victors is better in this case?
Jaguar_Transfer_Characterization_Data.xls (56.5 KB)
Jaguar_Transfer_Characterization_Data.xls (56.5 KB)
[quote=]
A few comments: I am impressed with the linearity of the CIM Speed vs Pulse Width. However, I am not sure (and not qualified to speculate not a ME) how well this will linearity will translate to speed of a motor under load (normal 4 motor drive of 130 lb bot). In my experience, at lower powers on the victors the drive motors just hum so will the jaguars just hum (depending on gearing obviously) for a the lower portion of these graphs. Maybe a fast rise like the victors is better in this case?[/quote]
The linearity (assuming that it holds under load) makes it easier to build a table replacement for a custom response curve. Define the dead zone, fast rise to first motion, low slope at low speed for precise control, steeper slope to get to full speed.
Brian, Joe and Dr. Joe,
These functions are more attributable to the segment spacing of the commutator vs motor speed vs PWM switching frequency. Each motor type will respond differently and the overall inductance of the windings will play a part as well. Often linearity is affected as much by the mechanical frictions within the motor and the load at low RPM as with any of the other variables. The “hum” in motors controlled by Victor controllers, I believe, is directly attributable to the low PWM frequency and short pulse duration. I have often observed teams who failed to calibrate the controllers and were supplying minimum pulse widths to their motor at rest. These short pulses were sufficient to bump the motor armature but could not supply enough current to overcome the friction in the drive train. One of the advantages to using 12 volt PWM is to get the motor moving while giving some speed control at low RPM. I expect the higher switching frequency to produce less hum in future systems. The upcoming season will give us some data on linearity under real world loads, stress on the motor in forms of heating, brush and commutator arcing, RF interference, etc. It will be interesting.
Hey, he was a sponsor of team 1507 for two years…
According to an NI video on the RIO, its dimensions are: 11.3" x 3.5" x 2.3", and it weighs 2.2 lb.
It will also withstand a 50g impact, so it sounds like it could do double duty as a bumper.
As the Chief Inspector, I feel obligated to point out that bumpers (per the 2008 robot rules) are only allowed to weigh up to 3 ounces per inch of length. Unfortunately, the cRIO weighs 3.12 ounces per inch.
Sorry. You can’t use the cRIO as a bumper. 
Russ
I’m very distressed because they’re very large. Victors were tall but didn’t have a very large footprint.
Jaguar footprints seem to be more than twice that of Victors’.
Here is the key to relieving your stress. Consider the size of the Jaguar as just another design constraint. :rolleyes:
Just for the heck of it, I found the specs for the speed controller that was used before the Victor, the Tekin Rebel. It is 1.8x1.4x1.1 inches. That makes the Victor (2.7x2.2x2.1 in) approximately twice the size of the Tekin Rebel.
I then searched the 1999 and 2000 forums of chiefdelphi, and didn’t see a single person complaining about the size of the Victor.
The Victors were so much better then the Tekins that no one cared that they were bigger. Based on the data and specs of the Jaguars, I think they will be so much better that in 2 years, no one will care that they are bigger then the Victors.
from what i can tell (i’m mostly mech) the pro’s of this new controller should be a big enough improvement for the extra space to be worth it to design around. The response and smoothness that apparently is there will be really nice for drivers as it should smooth out the low speed precision maneuvers that are often required.
(i still love victors though)
The jump to from the Victors to the Jaguars is small compared to the change from the Tekin to the Victors. The Tekin’s used to constantly suffer from spontaneous combustion, it was extremely frustrating how often they would go.
The Victors have been very solid throughout their tenure. For non PID related control I don’t think we really need much more. But, for control loops the Jaguars sound like a godsend. Allot will also depend on the cost of one vs the other.
Ok. Now you have me interested. Could you explain your logic?
The Jaguar has several interesting features aimed at tighter control loops. Unfortunately, only some of these will be useable this year.
-
The speed vs input command is linear. The Victor is highly non-linear, which prompted many teams to wrap a linearizing function around it.
-
The update rate is faster.
-
The chop rate is much faster.
- Features not yet accesible to teams *
-
The processor in the Jaguar is about an order of magnitude more powerful than the entirety of the old control system in terms of raw math throughput.
-
Direct quadrature encoder input
-
Analog input - for POTs?
-
True voltage control - This translates to direct speed control.
-
True current control - This translates to direct torque control.
-
High speed serial (CAN) communication to the cRIO which will allow you to send higher level commands
-
On-board PID loops.
http://www.reuters.com/article/pressRelease/idUS144446+05-Aug-2008+PRN20080805
I’m excited.
Not to mention:
- integrated limit switch inputs
- instantaneous current monitoring (this feature would have saved our team several $100 Victors)
- instantaneous temperature monitoring
It looks like we are going to get 4 jaguar’s in the kit, and their cost is 92.50 before the FIRST discount.