Jaguar Meltdown

[dyanoshak]

Originally Posted by Dad1279

We bricked one tonight just updating the firmware.

Check this thread out: http://www.chiefdelphi.com/forums/sh...884#post906884

If you accidentally load the Gray Jaguar firmware on a Black Jaguar, or vice-versa, they will not operate. The post I linked to describes how to fix the problem.

It is a good idea to download the latest firmware from www.luminarymicro.com/jaguar to make sure you have the right ones.

-David

[Phoenix.14]

We experienced this with two of our jaguars in close succession; one of them burned and produced smoke, and had a similar melted plastic piece when we opened it up. The other stopped working just after and produced similar behavior to that of the burned one (running at full speed nonstop, even when the PWM wasn't plugged in), but we haven't opened that one up yet.

Fortunately we still have four working jaguars, so barring another failure we'll be fine.


There is a possibility that there could be metal shavings in the jaguar as we drilled holes in the metal board they were mounted to that day, but they were mounted upside down on the bottom of the board, so I find it doubtful that they would have gone into the fan opening.

[Dad1279]

Thank you David.

Phoenix - Shavings are the death of speed controllers. They are the last thing mounted on our robot.

[DonRotolo]

Originally Posted by Phoenix.14

There is a possibility that there could be metal shavings in the jaguar as we drilled holes in the metal board they were mounted to that day, but they were mounted upside down on the bottom of the board, so I find it doubtful that they would have gone into the fan opening.

I have proof that metal shavings can defy gravity.

Make sure the gorillas in Mechanical understand the impact to the electronics of their work with their stone knives, axes and drill bits.

[3286]

While we are a rookie team and we make it a point to search posts and threads for information, we have noticed a kind of disconnect in some of the documents and references regarding the entire build process, especially in some of the seemingly more important DO's and DONTS! The mechanical and electrical side of building are of course easier for many, since they are not as abstract as programming and electronics for a lot of people, but this is the second time I have seen reference to calibrating Jaguars. Yet I did not notice this in any of the quick build or First provided reference.

We aren't complaining or throwing stones here even though it may seem as such, just stating an observation that may be taken for granted by more experienced teams since they have already been thru the steeper parts of the learning curve.

Probably everyone is getting a bit tense and anxious with only about 3 weeks left in the build season!

Good luck everyone, hang in there

Mike

[Al Skierkiewicz]

Mike,
Calibration of both Jaguars and Victors is a step that many teams do not take. The assumption is that the controllers are shipped pre-calibrated from the factory. In reality the calibration procedure matches your joystick travel to the maximum output of the controller. This step can be accomplished in software or a simple procedure in the controller. Without this step, your robot may not meet full throttle at each extreme of the joystick (or whatever you use to drive) or more importantly, it may not be matched for both forward and backward motion. In extreme cases the motors may not be at zero throttle when the joystick is at rest.

[Dad1279]

Originally Posted by dyanoshak

Check this thread out: http://www.chiefdelphi.com/forums/sh...884#post906884

If you accidentally load the Gray Jaguar firmware on a Black Jaguar, or vice-versa, they will not operate. The post I linked to describes how to fix the problem.

It is a good idea to download the latest firmware from www.luminarymicro.com/jaguar to make sure you have the right ones.

-David

Worked.

[Joe Ross]

Originally Posted by Al Skierkiewicz

Mike,
Calibration of both Jaguars and Victors is a step that many teams do not take. The assumption is that the controllers are shipped pre-calibrated from the factory. In reality the calibration procedure matches your joystick travel to the maximum output of the controller. This step can be accomplished in software or a simple procedure in the controller. Without this step, your robot may not meet full throttle at each extreme of the joystick (or whatever you use to drive) or more importantly, it may not be matched for both forward and backward motion. In extreme cases the motors may not be at zero throttle when the joystick is at rest.

This is probably straying off-topic for this thread, but I don't think calibrating the speed controllers is wise in most situations.

Ever since autonomous started, joysticks haven't been the only thing controlling the robot. If you calibrate the speed controller to match a bad joystick, you will adversely affect the performance in autonomous mode.

Furthermore, the centering of the joysticks should not be an issue with the NI control system. Modern joysticks automatically calibrate the center position. Thus, you should not plug the joystick or enable the robot with joysticks off center. Any students should be familiar with this, as video game systems have had the same limitation since the N64.

If you really do want to use a particularly bad joystick, I think you're far better off compensating in software only during teleop.

If you have a speed controller with calibration that doesn't seem right, you should calibrate it with an autonomous routine that outputs -1, 0, and 1. Additionally, WPILib (in all languages) has it's own calibration values for min, max, center, and deadband, so you can adjust those for a particular speed controller. In java, it's the setBounds function.

[Darkknight512]

Just had a jag blow today, looks like the same problem from the picture. We are a rookie team, a little behind havent cut a single peice of metal except the original frame but when that happend the electronics board was not even assembled yet.

[Mike Copioli]

Originally Posted by Darkknight512

Just had a jag blow today, looks like the same problem from the picture. We are a rookie team, a little behind havent cut a single peice of metal except the original frame but when that happend the electronics board was not even assembled yet.

There are several possible causes for the failures occurring with the Gray Jags. The obvious afore mentioned causes are a result of conductive particulate (metal shavings) entering the housing and shorting across one or more legs of the H-bridge. This is an issue with both the Jags and the Victors. The Victors however have additional protection from this debris in the form of conformal coating. While this conformal coating protects the device at the surface component level it provides little or no protection to the FETs that make up the H-Bridge. This is unavoidable in both brands of speed controller and the major contributer to failures. These failures can be prevented by adopting practices and mounting techniques that reduce the risk of foreign body intrusion.

Other failures that I have observed can be attributed to ESD. There are a couple key elements to switching the H-bridge circuitry safely. The switch must occur in a way that prevents the high side of the bridge from saturating (switching on) while the low side of the bridge is saturated. This would cause what is called shoot-through and is basically a direct short between battery positive and battery negative through two legs of the bridge. This switch timing is controlled by a microprocessor inside the device. While the timing of the switch is most likely not the cause of the shoot-through, the driver circuitry that allows the NFETs to switch the positive side of the bridge failing is. This device is called a charge pump and what it does is very simple. A charge pump takes an input voltage and steps it up to a higher voltage. This higher voltage is what drives the gates of the High side NFETs. Why am I explaining all of this? very simple. One should understand how the device works in order to understand how it fails. After examining several Jags that have failed I have made a few discoveries, first and foremost the charge pump chip that is used in the gray Jags appears to be sensitive to ESD. In a one instance the chip had a hole blown through it. This happened shortly after a lightning bolt jumped from the bot to a desk. A charge pump chip that fails to do its job and or latches up can and does cause shoot-through. A second discovery revealed that the fans used in the gray Jags do not tolerate shock and vibration very well. Two of our failures are attributed to the struts breaking off of the fans after traveling over the bumps a couple of times. A loud rattling sound soon followed. In all cases the devices were free from debris and foreign body invasion. Many of these issues claim to be resolved in the Black Jaguar. Some of the changes that I have noted between the black Jaguar and the Gray are increased input voltage range, more ESD protection, and 4 less FETs (one per leg). The FETS used in the black Jags also have a higher continuous Drain current rating. This year our team is using Black Jags primarily due to these hardware changes. We have used the Victors in years past but made the switch to the Jags because of the legality of CAN in this years competition. Most of the failures can be repaired if you know what you are doing and have the ability to solder and remove surface mount and through hole components. I am not sure how legal this is but we are only using the gray Jags for the practice bot so it is irrelevant to us.

[T3H_K3YM45T3R]

My team has had 3... 4 jags fail now, and we're going back to victors. I don't think we will be using jags again. We fried 1 last year and this year we fried 3, they replaced the one we fried last year at the Greater Kansas City regional last year... we didn't burn it up at the competition, but had it with us for no reason.

the first one that fried this year "Popped" when it went out, I think the capacitor (big blue thing in the middle, for those that don't know) might have blown. It sounded like a capacitor shorting or "firing"

... I don't know if that helps or anything

[Liu_yiang]

Ours had the same problem. This seems to be a continuing problem with Jaguars. One can only go in reverse, one can't go at all. Last year, we had all four of them go out at once. We love our victors...

[boomergeek]

Team 241 had 3 Jaguars short out this year:
All resulted in the circuit breaker on the associated Jaguar breaker trip continuously that made the rest of the robot uncontrollable- (caused variable lag time of one to three seconds on all other functions on the robot).
We guessed that the failure mode was caused by voltage spikes caused by attempts at wide voltage swings too quickly.

One failure occurred at BAE unveiling event ; (less than 5 minutes total use prior to failure)
One at the Granite State Regional ; (less than 10 total minutes use)
One at the Connecticut Regional ; (less than 40 minutes total use)

The first two were on our drivetrain (CIMs).

The last on was on our ball magnet roller (Fisher-Price).

At Manchester, we added a software control to limit the rate of voltage change so that the Jaguar would not be swung from +12V to -12V too quickly (and vice versa).
Since we make that change, no more the Jaguars blew on the drive train- Because we had 2 blow out of 40 minutes total use (10 minutes times 4 CIMs) and we have not had any more blow after 240 minutes total use- we think the workaround helped.

But due to an oversight, our software workaround to baby the Jaguars did not get put on the Jaguar driving the fisher-price until after we blew another Jaguar.
After we put the software workaround on the roller, we have not had another Jaguar blow. (16 minutes use without a failure).

[eugenebrooks]

That your mitigating measure resolved your problem is consistent with the Jaguars being sensitive to the high currents produced when the motor is turning in the opposite direction than the polarity of the voltage drive. When this happens, the motor is effectively a generator aiding the battery to drive the current, instead of opposing it as is normal, producing a current surge while the condition persists. Victors are subjected to the same current assault upon sudden reversal of the drive, but are perhaps more hardy.

As opposed to limiting the "rate" of the "voltage change," it might be useful to account for the fact that the control of the victor is pulsed, on or off with a direction, and that there is a braking option selected via jumper when it is off. What you want to do is put in a short delay on "reversal" of the control signal, holding it at zero during this time, so that the braking will slow the motor down a bit before the drive reverses. This measure would help protect victors as well. Your slowing down of the rate of the change in the drive is having a similar effect, but the currents during the "on time" of the jaguar while the motor is reversed are still excessive.

Eugene

Originally Posted by boomergeek

Team 241 had 3 Jaguars short out this year:
All resulted in the circuit breaker on the associated Jaguar breaker trip continuously that made the rest of the robot uncontrollable- (caused variable lag time of one to three seconds on all other functions on the robot).
We guessed that the failure mode was caused by voltage spikes caused by attempts at wide voltage swings too quickly.

One failure occurred at BAE unveiling event ; (less than 5 minutes total use prior to failure)
One at the Granite State Regional ; (less than 10 total minutes use)
One at the Connecticut Regional ; (less than 40 minutes total use)

The first two were on our drivetrain (CIMs).

The last on was on our ball magnet roller (Fisher-Price).

At Manchester, we added a software control to limit the rate of voltage change so that the Jaguar would not be swung from +12V to -12V too quickly (and vice versa).
Since we make that change, no more the Jaguars blew on the drive train- Because we had 2 blow out of 40 minutes total use (10 minutes times 4 CIMs) and we have not had any more blow after 240 minutes total use- we think the workaround helped.

But due to an oversight, our software workaround to baby the Jaguars did not get put on the Jaguar driving the fisher-price until after we blew another Jaguar.
After we put the software workaround on the roller, we have not had another Jaguar blow. (16 minutes use without a failure).

[boomergeek]

Eugene,

Thanks for giving a more accurate description of the surge from the reversal of directions being better described as a current surge rather than a voltage spike. I believe our Jaguars had been set up for "brake" instead of coast option from the beginning of the season. (Before the two failures).
We have been using CAN control signaling.

I'm relatively new to FIRST (my second year). And I was kind of surprised that neither the speed controllers themselves nor the standard software for driving the speed controllers had sufficient defensive measures for preventing a full speed motors in one direction (with the momentum of a robot traveling 10 fps) being instantaneously subjected to full voltage in the reverse direction.

Overly sensitive joysticks can excite this problem ... as well as novice drivers that have no concept of electrical and mechanical stresses that occur when they forget the concept of the momentum for a 135 lb robot and instead try to reposition a robot as quickly they would an avatar on a video game.