Talons, Jaguars and Victors - where do you stand?

[apalrd]

The update rate really doesn't matter if you are running code slower than the update rate you are running (e.g. we run our code at the relatively fast rate of 10ms/iteration, so the standard Victor update rate of 10.1ms vs a Jaguar or Talon at 5.05ms would make no difference)

I also played with (psudo-accidentally) updating the Victor 884's at 5.05ms and it worked fine. The new 888's appear to be spec'd down to 2.1ms cycle time (with a max pulse width of 2ms) but using a cycle time that isn't a multiple of 5.05ms requires some additional timing calculations (it's not hard, if I were to try to run my code at 7ms and update the PWMs at 3.5ms it would be possible).

BUT since the code still calculates the pulse width at 10ms the update frequency doesn't matter at all below that. In fact, the default code updates at somewhere around 20ms in the main loop in LabVIEW (not exactly sure, it's not timed well) so the 10.1ms vs 5.05ms update rate wouldn't affect anything.

We ran Talons on our test chassis in late December without fans and were so happy we ran them on all of our 2013 motors (there are 11 on our robot) without any fans.


Edit: I see absolutely no reasons to use a Jaguar in FRC. The reliability history is poor (in my time on 33 we've blown ~3x more Jaguars than Victors, yet used ~6x more Victors on robots), although the changes by IFI should help that, the CAN implementation is poor (synchronous blocking) and increases single point failures, and they're freaking huge.

[Ether]

Originally Posted by apalrd

the standard Victor update rate of 10.1ms vs a Jaguar or Talon at 5.05ms would make no difference)

The "standard" update rate of the Talon driver in WPILib is 10ms not 5.

At least it is in the 12/20/2012 version of Talon.java.

[ayeckley]

Unlike many new products, we didn't encounter any "gotchas" this season using 100% Talons (not the SRs, the original version) in fanless operation. We're running a total of nine motors each on both our practice bot and competition bot (WCD with two CIMs each side, everything else RS-550s). In two regionals and lots of driver practices so far we've encountered no issues that weren't of our own making. We took the risk because we had sufficient inventory of Victors we could fall back on if necessary; it was not.

[apalrd]

Originally Posted by Ether

The "standard" update rate of the Talon driver in WPILib is 10ms not 5.

At least it is in the 12/20/2012 version of Talon.java.

Interesting.

I assumed that since Mike Copioli said the Talon would accept a PWM to something around 3ms that it was set in the WPIlib to 5.05ms (1 DIO loop frequency)

I set ours to 1 DIO loop frequency (5.05ms) and have no issues, not even with practice bot Victors using the Talon output scaling and pulse period of 5.05ms. I'm not entirely sure why the output frequency was ever set to 2 DIO loops (10.1ms) to begin with, or why the DIO loop is 5.05ms instead of 5ms or something even faster.

[sanddrag]

Accidentally applied unregulated 12V to the output of a Talon, nothing happened. Eight Talons on each of two robots. We're happy with them.

[omalleyj]

Originally Posted by apalrd

Interesting.

I assumed that since Mike Copioli said the Talon would accept a PWM to something around 3ms that it was set in the WPIlib to 5.05ms (1 DIO loop frequency)

I set ours to 1 DIO loop frequency (5.05ms) and have no issues, not even with practice bot Victors using the Talon output scaling and pulse period of 5.05ms. I'm not entirely sure why the output frequency was ever set to 2 DIO loops (10.1ms) to begin with, or why the DIO loop is 5.05ms instead of 5ms or something even faster.

I am going from memory, I don't have the WPILibJ in front of me, but as I recall there were notes on the PWM class about compatability across all PWM devices (servos as well as motor controllers). The 5.05 results from a base rate in microseconds in the 6us range, times 770 or so. The particular devices get a multiplier of the 5.05ms and Victors and Talons were 2x (10.1ms) and Jags 1x. This is in the latest update of the Java libraries, but again its from memory, so check the PWM class to be sure.

In keeping with the original question: We used 8 talons and 2 jaguars. The jags were applied where we wanted HW limit switches.

We have did lose one talon during the season, the one controlling the front wheel of our shooter.

[Ether]

Originally Posted by omalleyj

We ...did lose one talon during the season, the one controlling the front wheel of our shooter.

What speed control algorithm were you using?

Did anyone else have a Talon failure while using it to control a shooter motor?

[omalleyj]

Originally Posted by Ether

What speed control algorithm were you using?

Did anyone else have a Talon failure while using it to control a shooter motor?

No feedback at all, we found the frisbees flight was not very speed sensitive. We used light wheels that recover quickly. The rear motor was set to 70% and the front to 100%. There was a 1.75 second delay between shots to allow recovery.

Motors are mini CIMs, banebots wheels (orange tread), about 3/4" compression.

[peirvine]

2175 has never really liked the Jaguars very much. They are big, and we have had sever release their magic smoke on us. In 2012 we decided to try Victors and loved them. They were smaller and simpler and worked 100% of the time. This year - 2013 - we decided to try the new Talons. We loved them even more and are planning on going with them next year. They are even smaller than the Victors and have no need for a fan. We still put fans on our drive Talons but that was because a team member touched them and overreacted... If we had to rate our order of choice for speed controllers it would be:
1) Talons
2) Victors
3) Jags

[Teamcodeorange]

Talons 100%. Our design did not call for electronics space (oops) so we had a very hard time fitting all the components. Talons saved us. We were forced to fit 9 talons in a 6"x8.5" space. None of them have failed, amazing.

[MikeE]

Originally Posted by apalrd

Edit: I see absolutely no reasons to use a Jaguar in FRC. The reliability history is poor (in my time on 33 we've blown ~3x more Jaguars than Victors, yet used ~6x more Victors on robots), although the changes by IFI should help that, the CAN implementation is poor (synchronous blocking) and increases single point failures, and they're freaking huge.

(My emphasis)

If you are careful about avoiding metal shavings raining down on the Jags, I'm not sure they are any less reliable than some lots of Digital Sidecars.
The DSC is also a single point of failure and disables all PWM controlled motors, whereas with a daisy chained CAN bus you may have several motors operational before the cabling failure point.

However I don't argue with your other points about size & CAN blocking implementation.

[MrForbes]

Originally Posted by MikeE

The DSC is also a single point of failure and disables all PWM controlled motors,

Not the way we've managed to break them. The just lose a channel or two.

[dellagd]

Originally Posted by MrForbes

Not the way we've managed to break them. The just lose a channel or two.

Has happened to us too. Now thats a problem we didnt expect.

[jblay]

I would do to our remaining jags what they will eventually do to themselves and burn them, if the students would let me...

[theawesome1730]

We used only Victor 888s and we were very pleased. Other than some slight issues when using "y" PWMs on drivetrain Victors, everything went very well. They are very robust and we haven't had to replace a single one yet (through 2 regionals and lots of practice). I would like to run talons for next year, game permitting (need of PID loops for shooter wheels or whatnot in an instance where very linear response is necessary).