Jaguar Cut-Out

Technical Electrical
1

Whee, Jaguar problems!

So here’s the gist of it: We have 2 Jaguars on CAN* (interfacing via serial) to control our two shooter motors. The problem is that after we throw our robot into action** - driving, acquiring, conveying, shooting, bridge tipping, the whole nine yards - we find that our top shooter motor tends to cut out (we had both shooter motors cut out towards the end, not long before we bagged). After they’ve cut out, the Jaguar LED stays a solid yellow; any further signals we send to it elicit no response. When they cut out, though, we’ve seen a number of patterns. I personally observed slow flashing yellow and slow flashing red, the latter which makes sense to me given our massive voltage dips, but I can’t make heads or tails of the former. Teammates have also mentioned seeing slow flashing red or yellow***. The Jaguars settle back to a solid yellow as soon as we stop moving the robot.

*We’re using serial to interface and setPID() to tune the shooter wheels. Our team uses Java. These are the only Jaguars on our robot; we use Victors to control everything else.

**We’ve found by monitoring battery voltage that this kind of activity easily incurs voltage dips to 6V, and on one occasion, 4V. We know the mechanical issues associated with this problem (overtensioned 8WD with pneumatic wheels - although interestingly, the fuses don’t trip when we try to turn in place; turning seems to stall the CIMs), but are still worried that fixing this problem may not be enough to fix the problem at hand.

***This was one incident, and he wasn’t entirely positive if that was the color pattern we were seeing.

We’ve found that a hard reboot (opening and closing the central breaker) as well as a soft reboot (rebooting the cRIO from the DS) both fix the issue. Pulling and restoring the corresponding fuse on the PDB (to power cycle the Jaguar, and only the Jaguar) does not rectify the issue (we didn’t check whether or not it can cause the issue), which is what led me to suspect that its configuration is what’s being reset.

Switching motor leads on the Jaguars (that is, whereas Jaguar 1 & 2 are connected to shooter motors 1 & 2, we tested Jaguars 1 & 2 on motors 2 & 1) found that the issue lay with our upper shooter motor in particular, but towards the end, we managed to reproduce the issue in both shooter motors, so I think that’s attributable to manufacturing tolerances (and that we somehow managed to increase the current draw of our drivetrain).

I suspect that the problem we’re having is that our voltage dips are power cycling the Jaguars, which in turn resets their configuration and is what makes them unresponsive. The responses to this thread in particular helped me to arrive at this conclusion.

Is my conclusion correct?
If so (and even if it isn’t, because I’d like to know), what effect will power cycling a Jaguar have on its configuration?
If not, what do you think the problem is?

2

Your conclusions seem reasonable.

The Jags are resetting and your code needs to be able to recognize when that happens and respond by reconfiguring the Jag mode and your PID settings.

You may benefit by special handling to recover speed by avoiding trying to go full bore right away after such faults.

3

The fact that power cycling the Jaguar doesn’t fix the issue but cycling the cRIO does leads me to believe your Jaguar is browning out due to the voltage dips.

This resets the Jaguar, so all of your configured settings are lost (except the ID). Even the mode switches back to Percent Voltage mode.

Look in the WPI libraries for a function that checks a “Power Cycled” flag or something similar. Using this flag you can tell if your Jaguar has reset and you can send the configuration data again.

-David

4

There is a getPowerCycled() method on CANJaguar. Though at this point I don’t even know if I would trust that, as the Jag software has been giving us too many surprises. We have encoders on both of these motors so we can tell when they’ve stopped moving and at that point re-send the config data. The power-cycled signal would come earlier than that (if it does actually come), so I guess we could re-send both after the power cycle AND speed dropping to 0.

5

Thanks for your prompt response.

Would this mean that we would have to reconstruct the Jaguars in code? or is there an alternative?

6

Call changeControlMode(controlMode), set the PID constants and sensor references as necessary, then call enableControl()

7

Bumping this thread just to report success!

Using the reset strategy suggested by dyanoshak, Mark, and RufflesRidge, we were able to re-engage speed control of the motors. However, instead of using getPowerCycled(), we simply reset the Jaguars every time a shooter speed setpoint button on our Operator Interface is pressed. This guarantees to us that the Jaguars will always be configured in time to turn their motors, whether or not they power cycled.

Of course, this also means that the Jaguars will not be reset if they cut out in the middle of shooting at an unchanged setpoint (i.e. no button on our OI pressed). However, we have identified the source of our massive voltage drop as lying in the drivetrain, and we do not drive while shooting, so I do not think the Jaguars will cut out from a low voltage condition while the robot is sitting still.

Also, we are reconstructing the Jaguar in our reset method too, although this may be unnecessary. However, the effect of reconstruction is negligible and the motors respond instantly after reconstruction and reconfiguration of speed control settings.

8

Our team has written a wrapper class for the CANJaguar which will auto detect power cycled and reset all the configurations. See the following thread. By using this class instead of the CANJaguar class, all Jaguars are protected by this recovery.

9

Hello slijin,

You should consider writing getFaults() to a file when you run into issues. That way if you have trouble during a match you’ll have data to troubleshoot later. We’ve found that the jaguars aren’t usually the first to fail in a low voltage situation.

If you continue having troubles at NYC, feel free to stop by team 846’s pit, we’ve been using jaguars exclusively on the CAN bus for a couple of years now and we can help you out.

Regards
Brian

10

I like that! Thanks for the suggestion; that would make for neat encapsulation and reusability.

Since we put data to the SmartDashboard, we have been saving the .csv of every robot run on our laptop. This helps with the troubleshooting you described above, as we also put data about commands being run on the robot and robot voltage.

Also, thank you for your offer to help at NY. This is our first year rolling on to the field with Jaguars installed; for three out of our four past years we have attempted to use them on some component and then returned to Victors after reliability issues during Build Season.