Jaguar vs Jaguar CAN vs Victor vs Talon. whats the difference?

Just as the tittle says. What is the difference? Which should be used on what use and why?


There are definitely differences… our electrical team is working on some testing and a white paper to help other teams understand those differences better.

Until then, you might want to check out the excellent tests Ether did here:

Yay! more data :slight_smile:

Can you give us a sneak preview of the test plan ?

It’s similar to what the Fighting Pi did - run the motor with a load on it, and see what happens. While they used a window motor (I think), we’re running ours with a CIM motor, and we’re applying a load by coupling that to another CIM motor that’s hooked up to a Victor in break mode.

We also have the option of directly copying their method of providing a load with an existing robot we have setup to run a RS550 through a clutch to power a rollbar. Maybe in a future version of the paper, to help analyze the validity of each approach.

We probably won’t have enough time to set up for speed measurements this season, so we’ll only have Voltage here in V1 of the paper. Ideally, we’d also like to test the other functions of the speed controllers, like the break function on each to see if there are any significant differences (assumption: no, the break modes are close enough to identical for each one). It would be nice to include some tests analyzing the performance of closed loop feedback with the Jaguars running CAN versus PWM and running the sensors into the DSC.

As you can see, we’re giving ourselves room to grow and build onto this white paper :slight_smile:

Unfortunately, not all of us have access to a dynamometer to do the testing with, although my students did ask if I could find one for them! :frowning:

While we’re talking about this though, a question to pose to the group. We got through most of the tests last night, but the Jaguar was giving us trouble. The status LED indicated it was getting a signal just fine (it stopped flashing and turned solid orange), but it wasn’t doing what the code was telling it to do - the motor never moved. We scoped the PWM signal, and everything looked correct there… we tried replacing the Jag with another one we know worked, and hooked it into the BDC-COMM application to see what the Jaguar was “thinking”… any ideas?

I assume you mean solid yellow. According to the datasheet, that indicates 0 value on the PWM (1.5 ms peak time). Can you make sure that the peak time isn’t 1.5 ms?

See pg 11 for status light meanings.

No need to hook the driven CIM up to a Victor in brake mode, connecting the wires together will have the exact same effect.

Wouldn’t placing a resistor across the leads create a poor man’s dynamometer?

That’s basically what Mike Copioli (developer of the Talon) did to create his test rig. You can see his results in the Talon doc available on the Cross The Road Electronics website.

I think the resistor value Mike used was zero Ohm – i.e., he shorted the leads of one CIM motor on a CIMPle box, and drove the other CIM motor using the Talon.

Edit: Mike also did some testing with infinite Ohms (open circuit) on the leads of the test rig motor, to check linearity of the speed response vs. input pulse width. This is indeed a “poor man’s” version of the testing that Ether did later using a Magtrol dynamometer in my lab at Whirlpool.

You could use other values of resistance across the test motor leads; i.e., more than zero and less than infinity, but please check that the rating of the resistor is enough for the power the motor controller will be supplying.

If you want less load, then yes put a resistor (that can handle the current) across the leads, but if you want maximum load connect the leads together.

To get back to the oigional question, we on 2607 like to use CAN for our motor controllers. CAN allows you to actually get live stats from the Jaguars as they are running, which was actually a unique aspect of our robot last year. Our bridge tipper (Bridginator) was powered by a plastic gearbox to a banebots motor (I think it was banebots). Anyway, if we flung the arm down at full speed, the plastic would break. But, if we hit the bridge at half speed and THEN increased to full power we could crush any ball that was beneath the bridge and still get on.

Being on Controls, we made the code to poll for the arm’s motor amperage draw, a stat available over can. When the amperage spiked (e.g. hitting the bridge and the arm stopping) the motor was increased to full power.

So dont knock CAN till you try it! It can be quite useful :slight_smile:

Though, it is a more complex system with more protocol to get from set motor speed to motor driving, which makes it a little more prone to problems. Just test it out and see if you like it!

*You could achieve the same thing without CAN by using a micro switch. Yes, there are ways to mount the switch so it doesn’t get damaged.

My team has tried to use CAN every year from 2010 to 2012, and each time it’s caused us massive problems. Whether it’s the physical connectors or the 2CAN Ethernet to CAN Gateway not booting properly and leaving us essentially disabled the whole match, it just hasn’t been worth it. This year we’re planning on using Talons for every thing that’s high-load or requires more precision, like the drivetrain and shooter. We’ll probably use leftover Victor 884s and new 888s for other stuff. On our practice robot we might use some leftover Jaguars instead of Victors.

There’s many ways to do lots of things on a robot. I was simply saying it is an advantage of using CAN

When used with the cRIO control system, the CAN Jaguar will have the highest resolution, followed by the the Jaguar, then the Victor/Talon.

My point was not clearly stated. There are advantages to using CAN that cannot be easily replicated if not using CAN. Listing a couple of those would bolster your argument.


This should never happen to a 2CAN, it is running embedded code. Most likely your problem was elsewhere. If you apply power it will boot or not run at all. If the later is true it is most likely a hardware issue.