I have read a thread somewhere that if the motor gets stalled, it could draw down the voltage such that the Jaguar may get reset or power cycled. The thread has a concern that the Jaguar may lose it’s configuration (e.g. Encoder lines, mode, coast vs brake etc.) such that the Jag will no longer respond to Set() or does not behave correctly as a result. We haven’t hit this but is this a real concern? Because if it is, we will revise our code to anticipate and recover from it. For example, I assume we can call GetPowerCycled() to determine if the Jag has lost power temporarily and can “reinitialize” all the Jag parameters. We can do this before every Set() call.
If this is a real concern, ideally, the CANJaguar module should recover from it automatically. It’s a lot easier to do it there (may be for next year?). If we have to do it ourselves, we would define a new CANJag class that will inherit CANJaguar so we can keep track of (shadow) all the Jag parameters. And we will override Set such that we will check for power loss and reconfigure the jag before setting the motor output.
It’s a real concern if the motor and mechanism attached to the Jaguars can be overloaded.
It happens pretty easily actually, there are a surprising number of configurations that will limp along with the Victors but with the Jaguars the various safety cutoffs will effect you.
This is not to say that the Jaguar safety mechanisms are inappropriate. Considering that the Jaguars I’ve seen have less MOSFETs operating their H-Bridge within the speed control. The theory at work here is that the MOSFETs used on the Jaguar are better grade than those in the Victor. The problem is that the packaging of these parts is the same. The leads going in and out of those packages make a difference regardless of what the dies within the packages can handle. More leads in parallel, less resistance as a whole and the less current per package (though the more possible mismatch), less likely you’ll cook them off or damage the bondings.
If you can build your loads so they aren’t so power hungry the issues will get less (and I realize that’s not always as easy as I just made it sound).
If that’s a real concern, I wish the Jags could have those parameters in non-volatile memory so it doesn’t lose them when being reset or power cycled. Without that, the second best option is to recover in code.
I agree it would help if the Jaguars could remember their modes of operation after reboot, though it’s nice that the latest firmware at least doesn’t lock them out of communication forcing a power cycle probably system wide.
I actually have a little gizmo I made for the CAN bus with non-volatile memory that could probably reset them but I bet it’s not legal in competition. Nifty for debugging things however.
Mike,
The Jaguar manual lists the fault modes. As I remember the over current sense is 90 amps for more than a few milliseconds will trip the over current fault, turn the LED Red and wait 3-4 seconds before enabling the Jaguar output. There is also an under voltage fault, over temperature, loss of CAN, and limit switch reached in commanded direction.
Yes, the possible faults are listed below. But I am not sure which of the following faults will cause it to lose configuration. I figured that if it loses the state of the PowerCycled flag, it is a good indication that it has lost its configuration. It would be nice if somebody from TI can confirm it.
None of the faults “cause” a reset. However, the reason for the fault may lead to a reset. There is more detail in the 2012 Jaguar FAQ, but here is the summary:
Current spikes will dip the battery voltage. If the voltage drops too much (below 6V) then the Jaguar will brown out and reset. The FRC batteries are pretty good at dumping current without too much voltage drop IF they’re charged. If the battery is too low or if it is too old the voltage dips will be more severe.
If you are lucky, you will see a voltage fault before the brown out. Most likely, the voltage drop will be so fast that the Jaguar can’t indicate a fault before it browns out.
Checking the PowerCycled flag is the right way to determine if the Jaguar has browned out and reset.
Thanks for the info. My next question is: when detected a brown out, what configuration of the Jaguar will be lost? I know the Jag ID is non-volatile so that’s safe. Should I “reconfigure” everything else including Jag mode, encoder lines, position reference and speed reference etc?
I don’t consider myself an expert, but here’s what we learned and what we decided to do:
We found that our CAN-based Jaguars (we use Speed mode and PercentVBus mode) pull over 40+A (which doesn’t seem to trip the PDB breaker because it happens so fast there’s not time for the thermal switch to overheat) when we drive full speed (4 CIM motors, mecanum drive) one direction and then switch to full reverse. This causes a Jaguar “brown-out” b/c the voltage drops below ~6V. Polling the Jaguar to determine if it rebooted since the last time we asked is our proof of this.
We tried detecting the reboot (which works) and if so re-programming the Jaguars back into speed mode (which doesn’t work, may be a bug in our code). We couldn’t get it to work, not sure why yet but we had to move on (and we came up w/a solution that works for us, see below).
We found the Jaguars reboot pretty quick, and when they do they default to PercentVBus mode. The drivers don’t seem to notice when they reboot when the Jaguars are in PercentVBus mode.
The drivers really like the full power and quick response they get being able to drive the robot “full tilt”, so we decided against the recommended approach of having a “ramp” in software to soften the rate of change. Your mileage may vary on that decision…
We also tried the “automatic ramp” in the later Jaguar firmware. It didn’t seem to help us avoid the problem, I’m also not sure (documentation unclear) if it works only in PercentVBus mode or not (i.e, I’m not sure it actually takes effect in speed mode). We decide to leave this feature enabled (via the rotated jumpers on the Jaguar), thinking that it probably helps things - but it doesn’t eliminate all “brown outs”.
We decided based on all of this to use Speed Mode in Autonomous, PercentVbus Mode in Teleop, and we are working on an “end-game” (bridge-mode) where we transition back into Speed mode and have a virtual “low gear” mode which makes it easier to control the robot when on the bridge. When in speed mode, we avoid high-amp situations.
At this point, our solution is working pretty well. Our drivers are not complaining anymore about the drive system!
Scott et al,
It is not only the battery that can cause a brownout condition. Depending on the wire size and length, a considerable amount of voltage can be dropped during high current conditions feeding individual controllers.
The breakers may or may not trip above 40 amps. In general these breakers can sustain a 600% overload for a short period of time. They are also automatic reset. This occurs relatively quickly and you may not even notice where the trip occurs. However, the breaker makes a noticeable mechanical noise. When drawing well over trip current over a long time, the breakers will actually start to buzz. If this should occur, let the robot cool down for several minutes before allowing your students near the PD. When breakers buzz they become incredibly hot. Should someone touch them, they will likely receive a burn from the top of the breaker.
My apologies apparently a leap was made from my term ‘safety cutoffs’ to the idea that I meant the Jaguar fault conditions. I did not intend for that to happen and hadn’t noticed it after I lost track of this topic.
As said elsewhere in this topic, surely the Jaguar will start producing faults as the ‘safety cutoffs’ like the 40A auto-reset breaker exceed capacity but my point was more like this:
If a Victor and the electrical loads attached starts to overload a breaker the voltage will brownout rather rapidly causing resets that will pick up fresh referencing the PWM output. With PWM input the Jaguar will do the same eventually.
However, with the Jaguar in CAN mode the Jaguar under similar conditions might throw all sorts of faults visible over the CAN bus, but when it comes right down to it the cause is an electrical overload in progress. Eventually that electrical overload will get the better of you. When the overload exceeds the electrical limits that the Jaguar can tolerate you could see a brown out that causes you to loose your settings (Victors don’t really have fancy settings so it doesn’t matter to them), and if monitoring position, loose track of that (though there are other things that can cause you to loose some of these settings from what I’ve seen).
My point here is that the Victors being what they are neither report, nor have any other purpose but to start back up doing what they always do…monitoring PWM and responding with whatever brute force they offer. It’s all you expect from them and frankly it’s all you’ll get from them. Simple, cut and dry.
It’s hard to fault the Jaguars for the fact that the electrical systems involved are overloaded. It’s also hard to say that’s an optimal state of affairs (as the builder of the electrical and mechanical systems you have some control over it but that is a broad and complicated issue to itself). The Jaguar fault conditions on the other hand revolve around these transient overloads and that makes them often confusing (a case of too much information…because when you used to use Victors they never reported anything…even that they were starving for power). The thing is from what I see in the Jaguar firmware actions are taken like limiting the output which the Victors probably won’t ever consider doing and those actions are about protecting the components like the transistors. These additional factors further complicate the chaos of the overload conditions with the Jaguars and possibly if they had more tolerance for overload you’d see less of it. Between the faults and a system on the brink of overload the extra information and limits of the Jaguars can cause strange patterns of response from software controlling them if you’re not really careful.
As others have stated they’ve resorted to trapping the reboots. However, until recent changes in the firmware it was entirely possible to get into a locked up state within this chaos that forces a power down.
I wasn’t trying to say that the Jaguars are incapable of handing the loads at all, on the contrary, I hope that people will try to reduce the loads so that the overloads are less persistent. These overloads are not great for the Victors either…they’ll blindly push into them suffering reduced input voltages and electrical problems as well and they will reset, it’s just harder to notice it.
In short: the Jaguars are just responding to a complexity you don’t otherwise notice with the Victors, and they do it the best they can. The Victors just brute force it in a way that shields you from often noticing it. It’s not as cut and dry as Victors are simply better…better would be to stop drawing 80A from your 40A safety devices (given that many of the common drive system designs can manage to do that repeatedly I am suggesting something that I know is easier said than done).