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

[Ether]

Originally Posted by Jon Stratis

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

Yay! more data :-)

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

[Jon Stratis]

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

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!


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?

[nathan_hui]

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?

http://www.ti.com/lit/ug/spmu046b/spmu046b.pdf
http://content.vexrobotics.com/docs/..._Datasheet.pdf

See pg 11 for status light meanings.

[Mr V]

Originally Posted by Jon Stratis

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.

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

[nathan_hui]

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

[Richard Wallace]

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.

[Mr V]

Originally Posted by nathan_hui

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

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.

[dellagd]

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

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!

[Ether]

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.

[dellagd]

Originally Posted by Ether

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.

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

[Joe Ross]

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

[Ether]

Originally Posted by dellagd

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

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.