[DFTF] Jags v. Vics...

This is part of a series of posts called Drinking From The Firehose on getting Dr Joe back up to speed on All Things FIRST.

Today’s topic:
Jags v. Vics

I know I risk of starting a flame war, but it has to be asked.

Victors or Jaguars?

I have asked a lot of folks and here is what I have been able to find so far:

  • Size:
    Victors Win - Cost:
    Victors Win ($89 vs. $119 – though I think there is a discount for FIRST teams, even after the discount, I think Victor remains lower cost) - Reliability:
    Victors seem to have the public on this one, but it is not clear if this data is tainted by “the early years” of the Jaguars - **Smarter: **
    Jaguars have an enormous brain inside that larger package – not sure what that buys you in FIRST circles because we are limited in what we can do with it but it is there. Also can be a negative because some say the controller resets in some cases and causes flaky behavior (forgetting PID controls and otherwise going insane) - More Features:
    e.g. Sensor and Switch Input, PID control (without the main controller even in the loop), current readings baked in (if you use CAN) - CAN interface:
    pro and con for Jaguar - CAN can be better but the implementation has caused some problems (blocking controller code from running in some cases) - Over Current Protection:
    Jaguars have baked in self protection (60A for 2 sec, 100A for 0.2 sec). Blessing and a curse. We already have a circuit breaker so we are double fusing in a sense but at the same time, not letting the electronics fry seems like a good idea too.
    Over all, I think I am in the Jaguar camp because I am excited to implement some of the features available via CAN but I want to hear other input.

Thanks all,
Joe J.

Linearity of Response: Jag - The Victors are incredibly nonlinear, see the discussion in the 254 code thread for some very pretty pictures on it.

Reliability Under Load: I can’t speak for overall reliability (I’ve used Victors since 2004 and never had a problem with one, Jags have only been around since 2009 and isolating Jag problems from NI problems has proved to be difficult for me). I can, however, speak about issues that arise when going from full forward to full reverse. Jags have, in the past, tripped a breaker during this action whereas Victors will do this all day. There are tricks you can do to fix it but if you want immediate response (within 3/4 cycles) you want a Victor in your DT. For most other places the Jag is probably fine though.

My money has been on Jags since 2010 because of CAN. In those two years we have never gotten it working as reliably as I desire on an FRC robot. Early reports I’ve heard have not been too positive of the CAN stuff for this year either. (High CPU load, not sure what the cause is)

As a result, I would recommend 884’s in the drive train (despite their nonlinearity) and Jags elsewhere. While this will mean whatever loops you use to control your DT will suffer (PID assumes linearity) but the rest of your loops (arms, shooters, elevators, whathaveyous) won’t.

IIRC Jags have much better low-speed control than Victors, which became very apparent to me with our latest robot. We got CAN running last year, it was 100% reliable until that obnoxious field firmware issue reared its ugly head. I hope that will be fixed this year.

On pricing, what I found last year was: Jags are $85 from DigiKey, and Vics are $90 from Vex. Not sure if this is out of date or not.

When we used the brown Jags in 2010 we blew a couple of them in competition, very disappointing. When we used black Jags in 2011 we never had a single issue.

*noise from CIM motors driven with Victor controllers - #4 by Ether - Technical Discussion - Chief Delphi

**

Context? What is this in response to?

FWIW, we’ve used the Jaguars with CAN the past two years, and once we got it working there were no problems (the programming team has seemed to struggle with them for the first few days each year, though).

This year, we had 7 Jag’s hooked up through CAN, and our only issue was a single bad Jag that had to be replaced at one of the competitions (we were using the limit switch inputs, and something went screwy with those and stopped working unless the contacts were held in a very specific way).

Jags vs Vics. Joe’s original post.

**

Ok, sorry I was just confused.

We’ve been using Jaguars since 2009. Since then, we’ve used approximately twice as many Jaguars as Victors. We’ve had 1 jaguar failure (in the regional finals) and one victor failure (in the championship division semi-finals). I think that just shows that things fail at the worst possible times. When choosing between them, the main thing we look at is whether we need control, and if we do, we use a jaguar.

I think that poor protection of the electronics while working is a major failure contribution. The Jaguars are not conformal coated, while the Victors are. NI has also said that a significant number of cRIO failures are due to swarf.

Every time we’ve had the jaguar over-current protection kick in, we were able to trace it to a loose wire somewhere in the current path or a very low robot battery. In that respect, it’s been helpful because it caused us to look for the root cause.

2815 has never been known for its advanced sensor usage; we use Victors for the reliability after going through a metric ton of issues during 2010’s collaboration effort with 1398 with the Jaguars. Your mileage, of course, may vary…but I’d need to be sold on my team actually using all of the Jaguar’s features before I blessed making the switch again.

We used 7 black jags on CAN in 2010 and were very happy with the results. Only two issues: died in one match because we had a piece of hardware fall onto the CAN connector and disconnect it (random failure, similar thing could have happened to the cRIO or any other single-point failure on the robot), and in one other match (in division quarterfinals, scarily!) we had a cRIO bootup sequencing issue (I believe since fixed in the image) that caused the CAN driver to not start. The Jaguars were mounted vertically along the edges of the robot, and we never had one die. We used current sensing (via CAN) on our ball magnet motor to detect possession, worked great.

We used 7 black jags on CAN in 2011, and 2 victors. We had a lot of electrical issues, we believe mostly due to our control board placement (belly pan style) which led to lots of metal debris falling onto the control board. We did switch our drive motors to PWM control halfway through championships because of a couple of control issues (we believe traceable to CAN synchronous updates).

In future years we’re still planning on using jags and CAN, but being more careful with our electrical board placement to avoid the debris issues we saw in 2011.

We used 4 Black Jaguars and CAN for the first time this year. We used them for our drive train. We had no issues with them in voltage control mode.

While we didn’t exploit any advanced functions in the Jaguar last year, but we do plan on trying to use some this year. (we must learn to crawl before we can run).

As with all things electronic, metal shavings will be the death of it.

A few points of note:

  1. We used the 2CAN device instead of serial. 10MB of bandwidth versus 128KB as well as using the 2CAN dashboard wirelessly to analyze, monitor and debug.

  2. Correct cabling and proper termination are critical. There were numerous teams that I assisted with all kinds of CAN issues and 98% were solved by correct cabling and proper termination.

  3. This is my personal viewpoint only. Having no basis in fact, I personally believe that the days of the Victor are numbered in FIRST and Jaguars will be the only speed controller allowed in the future. So you might as well start using them now.

Burned by that issue also. It will take alot of convincing (or a mandatory rule) to use CAN again. Issue disappeared with PWM. We have had good results with the newer Jags the last two years, and will likely continue to use them.

We blew up a few Jags during testing the first (Lunacy) year, and switched to vics before ship, but post season testing proved they were static-electricity issues. Slick wheels on Regolith built up a charge like a Van der graaf generator.

This is only true during build season; the Jaguar discount is implemented, I believe, immediately following kick-off. To my knowledge, there has been no discount on Victors since 2010.

We have used Jags for the past 3 years, and haven’t had too many problems with it. Last year, we tried to implement CAN using the 2CAN system, but we couldn’t work out the bugs with it. Something with a packet read error. Nobody could figure it out, and we even tested every cable with an electronic tester. The error would slow the code down to the point where there was a 2-3 second lag between moving the joystick and the robot moving. We switched back to PWM’s, and everything worked fine. So far, I think we have only lost 1 Jag to actual failure (was a tan Jag someone pulled the screws out all the way on). We currently have 2 sitting in the closet that may be dead, but we aren’t sure. Eventually, they will (hopefully) be re-flashed with firmware, and will (hopefully) work again.

As for Victors, yes, they are still smaller in design. The PWM connectors on them sometimes don’t line up with the cable, and there is no way to keep them in once they are there other than gluing them in some way. The Jags have a nice clip to keep the wire in place. Also, I don’t think I will ever miss reaching my hand into the robot somewhere and jumping when I hit the fans on the Victors… I know I’m not the only one who has done that…

Ah, I see. I haven’t purchased Victors since 2005… :slight_smile:

That’s a big price advantage to the Jags during build season then.

We prefer the smaller weight and footprint of the Victors, although I understand that isn’t a concern to many.

We’ve used Jags in various applications, but what always worries me is the 100-amp fault mode. We’ve triggered this when we drove defensive bots at home with jags in drive over and over.

Can the 100 Amp reset be removed if you use CAN?

I’ll just never feel comfortable with them in drive powering a motor that will draw 133 Amps routinely.

Someone please correct me if I’m wrong, but I don’t think so. However, you can reduce the time it shuts off after a fault is detected – I think the minimum is half a second.

I’m not sure if this change is persistent – maybe you don’t need to use CAN on the robot, but rather connect as a one-off configuration step (then you can use PWM on the robot). Does anybody know if it’s persistent?

That is an inadequate solution. I don’t really understand the point of this feature, one would assume the designers of the Jaguar are aware of what motors we use?

To be fair, bringing the Jaguars to voltage fault, from personal experience, is very difficult. Last season, we did mecanum for the first time; believing that the potential for better control Jaguars offered was worth the departure from Victors, we set up a test drive base with Jaguars on a serial-to-CAN interface.

We ran into a number of issues with Jaguars; one in particular led us to do a number of stress tests to see how easily voltage faults were induced. Although the testing was relatively casual and we recorded no quantitative data, the only way we could ever induce voltage faults was by rapidly shifting from full forwards to full backwards multiple times within a few seconds.

To elaborate on other problems we had, I have to say that the issues began the moment we took them out of the box; I believe 3 out of an initial order of 9 were defects (configuration could not be accessed, did not respond to signal control, etc). More died after we put them onto an actual drive base; the most notable example was one that released magical blue flame in the middle of a driving tryout.

Other issues we ran into include CAN issues that could not be properly debugged because of issues possibly related to the proprietary code (as we could not effectively isolate said issues).

One point that I’d like to raise, non-performance related, is the encoder I/O interface on the Jaguars. One of their selling points is that they can be configured to run their own individual PID loops with encoder input, but that feature is somewhat tedious to utililze. The encoder input is a 5-pin PWM setup, whereas the USDigital optical encoders have a 4-pin output (Jaguars can take an index signal that these encoders don’t). Most teams would have to cut up the KoP 3-pin and 2-pin PWMs and solder them to the encoder wires, which I personally find to be a tedious implementation. The alternative, however, requires teams to own the tools and materials necessary to produce their own 5-pin PWMs.