So here in Greenville, SC FIRST team 281 is trying to decide if we like jaguars or victors. So what I was hoping that you guys will help us decide. If you will say what you prefer and the pros and cons of that one. The electric team is leaning towards victors, the programmers like jaguars. I am personally sick of our CAN failures and at championships we heard teams tell us again and again tell us that victors never break EVER. In 2011 all 3 teams on the winning alliance used Victors this year I’ve contacted 180 and 25 who say victors while I havent been able to contact 16.
Victors appear to be much less susceptible to FIRST-level abuse than Jaguars. (That’s purely anecdotal – but we’ve killed a good number of Jags and very rarely killed a Victor.)
I’ve used both in the past, this year was 100% Jags because we used the CAN bus with no problems after we got it set up. Personally I like having the flexibility that CAN gives us and the closed loop being offboarded from the CRIO. The only failures I’ve had with Jags this year were due to human error (plugging in the power backwards or disconnecting the CAN cable).
The upside of Victors is that they are smaller, lighter, and a little less likely to shut off when pulling large amounts of current (the Jags have a cutoff limit that can be overloaded when going full forward to reverse).
My personal preference is Jags based on my love of CAN. If not for CAN I’d use Victors.
I’ll try to keep this simple, there’s been a few topics up here about this:
Pro Victor:
- Will pretty much provide power till they burn out.
- Smaller footprint than Jaguar.
- Graceful recovery from brownout.
- Their PCBs are sealed against SWARF!
Con Victor:
A. No warning about faults.
B. Response time could be longer (depends on what you actually do with it).
C. PWM connectors can slip out if you don’t hot glue.
Pro Jaguar:
- Response time could be faster (depends on what you actually do with it).
- I/O on the electronic motor control means some self-control.
- Limits currents before breaker at fixed limits.
- Built-in ideal PID (not ubiquitous in application).
- Might need to buy the 2CAN under the right circumstances (the folks that make the 2CAN are really…really…supportive).
Con Jaguar:
A. FIRST has an RFQ posted to find someone to keep making them.
B. Limits currents before breaker at fixed limits.
C. Built-in ideal PID isn’t always useful.
D. Sensitive to noise on encoders in some cases.
E. No ability to override the functions within it’s FRC firmware.
F. CAN bus may be just as much wire, and it’s a single point of failure.
G. Might need to buy the 2CAN under some circumstances (adds cost and parts).
H. Brownouts can be complicated and time consuming to recover.
I. Brownouts loose incremental encoder counts and might loose absolute encoder counts if the dead time is long enough.
J. RS232 - CAN bridge can be swamped.
K. Cables can be tricky to make, LinuxBoy is working on selling a nice little CAN terminator.
L. Some new Jaguars have manufacturing issues with the RJ connectors.
M. Beige Jaguars can melt off the current sense resistor.
N. Last years firmware could lock-up your whole robot under some conditions.
O. This years firmware could still lock-up your whole robot under a much smaller set of conditions.
P. I’ve seen once and heard from another mentor that there is a state you can get the Jaguar in that when FIRST disables them they go full on and stay there (oops).
Q. They have a physically larger footprint.
R. Their PCBs are generally not sealed against SWARF!
S. Do not remove the screws from the terminals…it’s easy to do and can make SWARF!
T. Internal inspection is more difficult, but they are not sealed so they might need internal inspection sometimes to check for problems.
Ugh…okay that’s all I can think of right now…alternates to either possibly look here:
We fried one or two drivetrain Jags last year, due to swarf that got inside them. They were mounted horizontally; i.e., flat side down. We could easily see the burnt mark on their circuit cards near where swarf had shorted two pins on one of the ICs.
This year, we used six Jags (drivetrain and shooter) and mounted them all vertically. This seems to have helped; no failures. Possibly the swarf (if any got inside) settled to the edge of the plastic case, away from the circuit card.
Anyway, I like Jags for their linear response and CAN interface. Victors are nice for their smaller footprint, and they might be more robust against swarf – because they have fans.
The Jaguars have an internal fan directly over the MOSFETs just like the Victors (it’s just smaller and anything that hits it will still be inside the enclosure).
Nice list of pros and cons, Brian.
Of course, as a software guy, I prefer the programability of the Jaguars, and the CAN bus. I just wish that we had a more robust solution with more knobs that we could tweak for any particular application.
Our due to the size of the fans in the jaguar are teams use a second slightly larger fan (KoP) over the top of the original fan.
*Jag: somewhat less motor heating for the same motor output torque, under stall conditions.
*
*
While most of what has been said is true, the Victor conformal coatings do not protect the MOSFET tabs and in some cases, FET leads may also be exposed. Most often neither are significant problems. The Victor has no internal fault conditions that affect the output.
The fault conditions in the Jags render the output disabled for about 3.5 seconds minimum. Faults are over current, under voltage and high temperature. The fan is controlled so it is not running all the time. The small amount of fan current is inconsequential in either device.
When not using the CAN bus please seal the CAN connectors so that debris does not enter the connectors.
In permanent fault, either can continue to produce output current when the robot is disabled. It seems that the Jags are more prone to this condition.
This is correct. I’d like to add that the situation I’ve seen with the Jaguar fully on but disabled was not a permanent fault (at least not one where it happened and the unit never recovered…I still have the unit and it still works…don’t know if it’s entirely uninjured but it can drive a CIM).
The other mentor had a specific process to inducing this failure. He indicated to me that he had forwarded his findings to FIRST and was distressed they did not apparently respond to it.
I’ve never been able to replicate the fault beyond a very small number of late night sessions where I was hot on the trail of an unrelated issue.
16 used jags on CAN. We had some issues with static early in the season, but the new 2CAN with improved ESD protection seems to have solved that problem.
Being able to monitor amps helps with motor protection and recognition of things like having balls in the beater bar (2010 & 2012).
Our team went over the past few years from Victors, to jags, to jags with CAN, and now back to Victors.
We haven’t had any Victors fail that I know of. Maybe years ago with a debris related failure, something like that. We have had at least a handful of Jags fail (especially the grey ones). And trying to get CAN working (reliably) was difficult. Also I don’t like the single-point failure of one CAN cable going bad and taking out all the rest of the Jags…
I would like to know the fault method, please. He can PM me.
Team 20 has been using Jags since 2009 and CAN since 2010. Let me tell you, we have been rendered useless in (and presumably have lost) a not insignificant number of matches over that period of time due to Jag issues. It’s frustrating to go back to the pits to find out that certain Jaguars browned out, or the CAN network timed out, or a Jag got burnt out. I will say that Jags are beautiful and elegant when CAN works properly, but oh so frustrating when you lose matches or can’t perform because they fail where a victor simply wouldn’t.
I’m not sure of this, but it seems like the tendency of a CAN to fail is proportional to the number of Jags. If you have 13 Jags in a CAN, you are more likely to have that single fatal failure than with 4 Jags in CAN. The problem is that if one goes down, they all go down.
All of that said, I think the plan for us moving forward will be to use victors in all applications except where a CAN would be particularly useful, if at all, but have a plan in place to switch to PWM on the fly. For applications like a turret or shooter wheels this year, the set position and set speed PID loops integral to the Jags in CAN was very useful. However, for other applications like a drive train or a collector system, the functionality of a victor will be sufficient. The idea is that victors will perform most functions, and then if we have any CAN Jags, a smaller network will be much easier to manage.
=programmers like jaguars.
Not all progammers like jags… you can cast 3481 and 148 programmers’ vote to those which prefer vics… and we use c++ do our own PID work etc… The vic has a little curve on its derivative of speed control to velocity translation, but I’m use to it and like it anyhow. 
I have to agree with this. If you’re not going to use CAN, stick with Victors. If you think CAN is imperative for your application, then add Jaguars to the mix. We had Victors for everything except our shooter motors, which were controlled with Jaguars running their infamous closed-loop PID.
One point that I’ve never seen mentioned before and I feel really needs to be said is that if you use CAN, make sure you have people in the pit crew who know how to troubleshoot it. There are many teams that never run into issues with CAN (and that’s great for them) but there are infinitely more teams who experience incessant issues with CAN. Jaguars are much more complex devices than Victors and have far more failure points. Familiarity with and knowledge of CAN is an absolute must, and there are only so many issues that can be caught during build season (like finding out that your CAN loop takes longer to execute than the allocated loop time).
We had one incident at our first regional where only after ten minutes of frustrated troubleshooting did we manage to isolate the issue to a bad Jaguar in the CAN chain (the traditional move-and-replace-stuff method just barely caught this), which for some (still unknown) reason refused to interact with other Jaguars on the network (no, it wasn’t a contact pin issue; later off-board testing yielded inconclusive results as to the source of the problem). If it wasn’t for my and another programmer’s familiarity with CAN (our lead programmer even had to step back, due to his unfamiliarity with the issues at hand), we may never have caught the problem in time. I eventually handed it off at CMP to a TI rep who hopefully will be able to get back to us with more concrete results.
If you want to get rid of it though(and many drivers perfer a linear drive), try 254’s 2011 code. It is open source, and it has a function to linearize the victors. If you want help with that you might try PMing Cory.
Our debugging process usually involves checking lights followed by checking the 2CAN via a web browser. If that is reporting the Jag as being connected we blame the software guys and fix it. If not we blame the electrical guys and make them debug it. 9 out of 10 times the error is that someone had decided to use the CAN wires as a place to zip tie the 2CAN to. (This only happened once but it’s too funny of a story) Using this process we are usually able to nail down an error fairly quickly.
Yeah that would be great… if you have a link that would be great as well.
Thanks!