Problem with Jags stopping unexpectedly

[wilsonmw04]

Greetings,

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:

1. Replaced Jag. no change
2. replaced PWM wire. no change
3. Swapped PWM wire to another working drive motor on the robot. Problem went to that new motor.
4. changed PWM port via code. no change.
4. replaced DSC. no change.
5. replaced ribbon cable between DSC and CRIO. no change.
6. uploaded code that was working perfectly Friday morning. no change.
7. 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.

Help is Chief Delphi. You are our only hope.

[Jay O'Donnell]

Greetings,

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:

1. Replaced Jag. no change
2. replaced PWM wire. no change
3. Swapped PWM wire to another working drive motor on the robot. Problem went to that motor new motor.
4. changed PWM port via code. no change.
4. replaced DSC. no change.
5. replaced ribbon cable between DSC and CRIO. no change.
6. uploaded code that was working perfectly Friday morning. no change.
7. 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.

Help is Chief Delphi. You are our only hope.

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).

[kevin.li.rit]

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?

[Daniel_LaFleur]

Greetings,

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:

1. Replaced Jag. no change
2. replaced PWM wire. no change
3. Swapped PWM wire to another working drive motor on the robot. Problem went to that new motor.
4. changed PWM port via code. no change.
4. replaced DSC. no change.
5. replaced ribbon cable between DSC and CRIO. no change.
6. uploaded code that was working perfectly Friday morning. no change.
7. 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.

Help is Chief Delphi. You are our only hope.

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.

[Al Skierkiewicz]

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.

[wilsonmw04]

When you changed to a different motor, was that motor on a different gearbox?



Yes. We are running an Octocanum with one cim per wheel pair.

[Ether]

This doesn't fit all the symptoms you described, but since it's so easy to do:

Try installing the voltage ramp jumper on the Jag that is giving you the trouble.

[wilsonmw04]

This doesn't fit all the symptoms you described, but since it's so easy to do:

Try installing the voltage ramp jumper on the Jag that is giving you the trouble.




voltage ramp jumper? I didn't know it had such a feature, I will look into it now.

Edit: wow, that might just do it. I will swap those first thing Thursday. It's worth a shot.

[MrRoboSteve]

1. Is it possible that the Jaguars are calibrated differently?

2. 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?

3. 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.

[Michael Hill]

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).

We also had the same issues in 2012. We've vowed to never use Jags again and we've never been more happy!

[Joe Ross]

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

[Electronica1]

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

We are running 4 VexPro jags, and we tried to switch to a brand new jag fresh out of the box and the problem persisted.

[Nuttle89]

We are running 4 VexPro jags, and we tried to switch to a brand new jag fresh out of the box and the problem persisted.
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.

[Danny Diaz]

IIRC, even brand new Black Jags ship with the old firmware.

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.

-Danny

[geipel]

Danny,

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.

Thank you!

[cbale2000]

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).

[Danny Diaz]

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.

-Danny

[wilsonmw04]

Greetings,

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:
1. inefficiency of our octocanum drive train.
2. 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.

[Tom Line]

Greetings,

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:
1. inefficiency of our octocanum drive train.
2. 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.

[wilsonmw04]

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.

Yes, wires were getting noticeably warmer.

[Danny Diaz]

Yes, wires were getting noticeably warmer.
It seems to me that you were having issues not related to the length of the wire, but likely the quality of the splicing.

When splicing wire, I generally tend to never allow soldering wire gauges larger than 16. The reason is that with large wire gauges you effectively have two large heat-sinks drawing the heat away from the connection, and it's incredibly easy to end up with a cold-solder joint. In those situations, the joint (and subsequent wire) will be prone to internal arcing, heat buildup, and poor connectivity.

I don't think the actual length of wire had anything to do with your problem. Generally speaking, #12 wire has 4 times the resistance of #6 wire. As a general rule of thumb, if your battery and your motors are in fixed positions but your PDB can be moved around it's always best to use more #6 wire to allow your PDB to be closer to your motors than to use more #12 wire to allow your PDB to be closer to your battery. "Big Al" has, on many occasions, talked about the per-foot resistance of #10 and #12 wire, and has proven that there are "noticeable" and "non-insignificant" voltage drops that can be avoided by using #10 wire for motors (instead of #12) and reducing the length of that #10 wire as much as possible.

Also, I generally tend to prefer crimp connections (even for lengthening wires) over soldering the wires together. For the same reason it's done in home electrical systems, crimp connections tend to be less prone to mistakes and can be done relatively quickly. If you're concerned about the crimp connection, you can very often also solder the mating location of the crimp connector to ensure it won't go anywhere.

One last piece of wisdom, I generally tend to not trust screw terminals, especially for large-gauge wire (anything larger than 20AWG). Most of the screw terminals in this class I see used in FRC are the ones used to connect the batteries to the 6AWG battery wires - they have a ring terminal on one end to connect to the battery, and a screw connector on the other to create a press-fit onto the 6AWG wire. Wire tends to "spread out" and settle, and this means your connection will eventually become loose - this creates voids between your wire and the connector causing arcing, heat buildup, and poor connectivity. When teams tell me their batteries aren't keeping a charge or are taking a long time to charge, or their wires are heating up (and obviously the robot isn't using some 6-CIM beastly transmission), I usually check the batteries and have them tighten/maintain/replace the connector to the battery and that usually solves the problem.

Be well.
-Danny

[Al Skierkiewicz]

Guys,
The terminals that Danny describes are really meant for low strand count stranded wire or solid conductors. Thomas & Betts STC0414 4STR CU LUG terminals have a wire clamp. I prefer these or equivalent for stranded wire. It is important that you strip the wire such that at least 1/8" of wire extends beyond the clamp when you terminate the wire. If not the wire will simply be pushed out of the connector when you tighten the hardware.

[MrRoboSteve]

3081 has had good success with the KOP Burndy YAZV6CTC14FX lugs, using this procedure.

1. Carefully strip the #6 wire so that the bare wire is long enough to fully fill the barrel of the lug, and leaving about 2mm of bare wire showing between the lug and the insulation. You can tell that the barrel is completely full by looking through the inspection opening of the lug. Finally, inspect the insulation you removed to ensure that you did not cut any strands of wire off of the #6 wire. If so, try again.

2. Cut a piece of larger shrink tubing to cover the barrel end of the lug plus 1/2" of the wire. Slide that on the wire.

3. Slide the wire into the barrel of the lug. Ensure that there are no stray strands outside of the barrel.

4. Crimp the wire into the lug. We use Vice Grips to do this. It usually takes three passes of crimping before the wire is physically attached to the lug. You should crimp in the long direction of the barrel, in the middle of the barrel. If you can pull the lug off of the wire at this point, it is not crimped enough. Grab another lug and try again.

5. Using a high powered soldering iron or brazing torch, heat the lug in the middle of the barrel. We use a Weller WEL8200PK gun to do this.

6. Insert solder into the inspection opening of the lug, and load the inside of the lug with solder. You can easily put 12-18" of fine solder in the barrel.

7. Allow it to cool a bit.

8. Slide the shrink tubing into place and use a heat gun to shrink it.

[adciv]

Can you give us the wattage of the "high power" soldering iron? Given what I've come across, that could mean 100W or 1kW.

[Al Skierkiewicz]

We use the same terminal but we crimp using a vise. Place the terminal in the vise such that it is at a 45 degree angle with the corner of the jaw and crimp only half of the terminal. Turn the terminal and repeat for the other half. You are left with an "X" mark on the terminal. Do a tug test to make sure you have a good mechanical connection. Then use a 50 watt or higher iron (with a large, flat tip) with solder on the tip to heat the terminal. Using .031 solder, at least 6" of solder should be used. Be careful, if you add too much solder, it will wick under the insulation giving you a very stiff wire coming out of the terminal. If you add solder to the tip of the iron it will help conduct heat to the terminal. Finish with 3/8"-1/2" heatshrink. You can also bend the terminal to a right angle it that helps you terminate on the battery, PD or main circuit breaker.