I am hoping the CD community can help my team with a pesky problem that popped up at the VA regional.
symptom: A drive motor will stop moving. Jag light will switch from green to solid red. The motor will stay unresponsive until roughly half a second after the drive command has stopped. Then resume normal operation. When put on blocks, all drive motors function normally.
What we have done to try and resolve the issue:
Replaced Jag. no change
replaced PWM wire. no change
Swapped PWM wire to another working drive motor on the robot. Problem went to that new motor.
changed PWM port via code. no change.
replaced DSC. no change.
replaced ribbon cable between DSC and CRIO. no change.
uploaded code that was working perfectly Friday morning. no change.
replaced joystick. no change.
The we have three things we can check now.
a.Replaced the motor on the drive, but that seems unnecessary because of results of #3 on the list above.
b. Replaced CRIO. This is a shot in the dark. Everything thing else on the robot is working as intended.
c. Bad snap action fuse. This is what I am hoping for.
Does anyone have any insights to this problem? We have one last event this week and would really like to resolve this issue quickly.
I can’t really offer any advice, but team 1058 had a similar problem throughout the 2012 season. We never really fixed the issue, and we did all of the same things you did. We’ve since stopped using jags (victors and talons have both worked perfectly for us).
How are you controlling the Jaguar? Have you tried to measure the current to see if the jaguar is hitting the over temp or over current conditions and shutting down?
When you changed to a different motor, was that motor on a different gearbox?
It sounds like you are tripping the overcurrent in the Jaguar. To test upload the default drive code (not a previous version of your code as it may also have the bug) and run it.
It’s very possible that somewhere in your code you are giving 1 motor (of a multi motor drive) a different speed command.
If the breaker opens, there will be no lights on the Jag, but it resets almost immediately. If the Jag faults for under volts, over current or over temp, it will fault by turning on the LED RED for 3.5 seconds if the fault has been removed.
Is it possible that the Jaguars are calibrated differently?
Rather than running it on a test stand, I would instead simulate pushing during a match by pushing the robot against the wall or some other immovable object (not a mentor) for 4-5 second periods, with a couple second break between pushes. Do it on a carpeted surface so that you have similar resistance to a field. Can you get the issue to happen by doing this over a 2-3 minute period?
Per Daniel_LaFleur’s suggestion, I’d look closely at your programming to see if you can figure out whether there’s a state where you’re having drivetrain elements oppose each other. If you don’t already have it, consider adding some debugging logic at the point where you are setting the motors. One obvious condition to log would be when the two motors on the same side of the robot are commanded to drive in opposite directions when your grippy wheels are down. Depending on the precise nature of the change you made in #3 this may or may not be the problem.
I agree that this sounds like it is hitting the current limit on the Jaguars, and that the automatic voltage ramp will likely work. VexPro Jaguars (and TI jaguars that have been upgraded with the v107 firmware) have a higher current limit. Is it possible that the working jaguars have the new firmware and the non-working one has older firmware? See http://www.vexrobotics.com/vexpro/motor-controllers/217-3367.html
IIRC, even brand new Black Jags ship with the old firmware. I think we had a student flash all of ours with v107 when they first arrived. While updating the firmware might treat your symptom and allow the Jag to function normally, it sounds like you may have some mechanical fault in that module.
I’d recommend swapping the motor leads (post-Jag) and see if the problem stays with the physical motor to diagnose this.
OP, with #3, are you saying you took a PWM line going into the Jag, put it in a different Jag connected to a different mechanism, and that new Jag had the same problem? In that case my best guess would be that you’re doing something odd in code like rapidly reversing the motor - this could cause Jags to current fault or otherwise misbehave.
If you do go to the trouble of updating the firmware, the good news is that you can read diagnostic info from the Jag via the BDC-Comm utility. You can manually drive the motor at varying voltage and watch for temperature or current spikes. If you have the cables lying around or can make them, having access to this can be helpful for diagnosing stubborn Jags.
Old firmware, new firmware, Jags shouldn’t be used for drivetrains (in my humble but accurate opinion). A CIM will pull a little over 60Amps at “ideal torque”, which is 150% above the rated Amperage of the 40A Snap-Action breaker. At that level, the breaker will draw that current for over a half-minute without issue. But the Black Jags with the OLD firmware will cut power at 60A after 2 seconds. With the NEW firmware, Black Jags will cut power at 93A. Okay, great, but old firmware versus new firmware doesn’t really matter; the Black Jag will STILL cut power if the current draw exceeds 50A “for a short period”. This is the “Progressive” software current cutoff in the firmware that isn’t really documented anywhere except briefly on the website. Understand that the Black Jag was originally designed for use in applications where you don’t necessarily have an external breaker protecting it!
We used Black Jags at Arkansas, and the robot’s drivetrain felt very sluggish when starting from a dead stop or when turning (we kept slamming into the current cutoffs). For LSR we’re dumping the Black Jags on our drivetrain in favor of Talons (who can handle 60A continuous and over 100A peak without the “progressive” cutoff), but we still are using Black Jags for other areas of our robot where we’re taking advantage of the built-in limit switch connections on the Jags themselves; we can protect the robot much faster by killing the Jag directly than waiting for the software to get the message and do it for us.
I had heard this sentiment expressed before (about Jags on drivetrains), but this is the first time I had heard it with such a good explanation. This makes sense.
I’m of the strong opinion that unless you’re using CAN, the answer to virtually every “problem with Jaguars” thread should simply be: “Don’t use Jags”.
They’re so much more trouble than their worth, and unless you’re using CAN, they provide virtually zero benefit over Talons or Victors (and they take up more space and fail FAR more often).
I don’t know if that’s fair. I’m not saying that isn’t correct, but I don’t think it’s necessarily “fair”. The Jag wasn’t specifically designed for FIRST applications, it was designed for broad use/appeal (but I’d assume its 90% use-case has been in FIRST Robotics).
We’ve had about even odds that a Victor or Jag would fail on us in a given situation (though to be fair the Victors were twice as old), but pretty much all of them were our fault (metal shavings in the device, reverse-driving the controller, etc.). We’ve only used Talons one season, and we had a bunch of Jags leftover from previous seasons so we used those this year. That’s where we ran into the “not specifically designed for FIRST applications” wall.
But the Jag has some very useful features, the primary one we use is the built-in limit switch connectors. Ramping is another very nice feature I wish other speed controllers had. CAN is another one, I guess, but we’ve not gone a full season without having CAN issues appear in FRC so I’ve not allowed my team to use CAN yet. Keeping my fingers crossed for the roboRIO.
The design of the Jag seems more geared towards hobbyists or those who would write their own firmware for the device. It doesn’t seem like it was really meant specifically for FIRST.
I just wanted to give the group an update on our findings. During QCR, we replaced the jags with talons. This solved the problem with the controllers going into a fault state. We found that the fault state the jags were going into was a low voltage state. This worried me more than an over-current, honestly.
During our matches in QCR, we noticed we were draining batteries VERY quickly. At first, I thought it was normal since it is common knowledge that mecanum drives take a lot of juice when strafing. In some of the later matches, we were barely functional during the last 20 seconds of a match. We got a warning from the FTA that our measured voltage was dropping to 7 volts at the beginning of the match. This sent up red flags to the team.
At the end of QCR, we sat down and came up with some possible causes of our voltage issues:
inefficiency of our octocanum drive train.
An main power line (6 gauge wire) that was too long for the application and was spliced/soldered together. We built a new main trunk with main breaker that would be a straight swap once we got to worlds.
At Worlds, we cleaned up the slop in the drive train by realigning the modules and lubing everything. No noticeable effect. The main trunk was swapped out after our first match Thursday. The total length of the trunk was over three feet. Once it was replaced, the voltage issues disappeared and the robot drove very well for the rest of the event.
TL;DR: Keep your 6 gauge wire runs as short as possible. Create your own anderson connections if needed to keep from splicing the main line together.
I’m curious - was the wire or your wire splices getting hot? I’d expect it to if you were losing that much power to a resistance or partially open circuit.