Help with weird problem.

Competition Regional Competitions
#1

Hello guys, I’m a college student mentor for team 1230 and we are currently competing in the NYC regional and we seem to be encountering a serious problem in the pits and i wanted to know if anyone has been having the same problem and/or any solutions. So here’s the problem, when the robot is tethered in the pit all of its functions preform properly but when a specific component is used for an exes of 7 seconds the system shuts down and all of the speed controllers report no signal including the driver console. after about 4 seconds the system turns back on but when the component is used again it kills the system about half a second into its use.

a couple of experiments have been preformed

  1. the motor (cim) was unloaded from the belt it is driving and it was able to drive as long as we wanted.

  2. certain metal points around the belt were grounded to see if it was static electricity causing a excessive current output

  3. the 40 amp breaker was changed to the victor that is controlling the cim

  4. the belt was slowed down in an attempt to lower the current draw from the system from the cim

  5. A system gauge (i do not know the name of it) connected between both ends of the battery and system input voltage connectors and the current draw read at the time of system shut down was no more then 16 amps at a given time

a clue to this problem may lay with an event that occured durring inspection, the inspector put an ohm meter to the system and measured an impedence of 40 Mega ohms and he said that we should have about 100 mega ohms. this may help a little

also this problem does not occur on the field during play

#2

did you happen to notice the temperature of the CIM?
and the voltage of the battery?

A low battery would seem to be the most obvious reason based on my knowledge.

#3

yea, the temperature of the cim was cold, what we did see is that if we let the cim sit for about a minute it would let it run again at a constant 7 seconds again then it would continue to fail. the voltage input of the battery was a clean 12.7 volts and we constantly changed the battery also since its been happening all day in the pit. we had the jaguar rep and the National instruments guy come over to help, they stayed about 40 min and watched a match of ours and came back to diagnose the problem and they couldnt figure it out, also a FRC volunteer came also to look at it and still nothing.

#4

CIM temperature and battery voltage are the only things I can think about, since those are both fine, I have no idea…

#5

What might be that component?

#6

You may want to try running the CIM after disconnecting its drive from the belt. Running it free will help you identify if it’s a problem with the motor (which is potntially faulty) or the belt, which may be binding or causing static buildup in some way. You can also check the free speed current draw of the CIM which should be relatively low if the motor is in good shape.

Another possibility is that you are actually shorting and vibrations/motion of the belt are causing the short. Make sure all of your control electronics are properly isolated from the chassis and triple check all connections that power the CIM or run anywhere near the CIM/belt assembly.

I hope you figure out what is causing your troubles. Good luck!

#7

Yea, we did run it without the drive belt attached and it ran fine, for as long as we wanted. we didnt check the free speed current draw of the motor but of the system as a whole and it never went above 16 amps during the shutoff. as far as the static guess, we tried that also by connecting a wire from a nut near the belt of the motor to the negative lead on the battery but it still shut down anyway. the connections are fairly far away from the chassis also because the electrical board is vertical in the front of the robot. the motor drives a rubber belt that runs a cloth belt that runs the height of the robot. from the given experiments we can safely say that the physical load on the CIM has to do with the problem considering it runs fine unloaded, but the issue is why does it only occur in the pit while teathered

thanks for the help btw :slight_smile:

#8

Since it does not happen in the field of play, I’d (just about) discount an electrical issues.

What it sounds like to me is that either your ethernet cable is damaged or your ethernet ports are making poor contact to your ethernet cable. Let me ask you, does your system that the CIM is attached to create a lot of vibration? If your system loses communication then the cRIO watchdog will disable all ports and your jags/victors will be disabled. These (I believe) will be re-enabled when communication is re-established.

I’d suggest you replace your ethernet cable and inspect your ethernet ports for foreign debris or damage.

#9

Hi,

This is team 3017 from the NYC regional. Come on over to our pit on sunday, and we will be glad to help you. I’m only a manufacturer, but our programmers have been through a whole lot of similar bugs. It just doesn’t make sense, because you said that you tested the motor when it was disconnected from the mechanism…just doesnt make sense. The last resort could prbably be faulty wiring. I’m already guessing that it has worked perfectly fine before…and if the motor works fine by itslef, and the battery is charged, then I would have to resort either to the wiring, or general temp of the motor. Maybe it overheats too easily when it’s put under the pressure of operating the mechanism. Thus, if you guys come on over, we may be able to help you guys out. Btw, you guys should try multiple motors, if you don’t have that already, since the mechanism wouldn’t become over-pressured.

#10

make sure your belt isn’t too tight. you may be stalling out the cim right away by haveing a belt that is either too tight or doesn’t move freely. This could cause your cim to stall and draw its stall current (100 amps about).

Then depending on your electrical set up you could be tripping a breaker that controls the electricity to your control system. This then could cause a reset of your entire control system.

to check this just put a multimeter on the cim and make sure your not drawing to many amps

#11

well, we did change the Ethernet cord with a better one that we borrowed and made sure both ends were snaped in, um let me ask you , does it mater which port is being used on the watchdog? because if the ports do have a potential to go would i be able to use the other and have the problem fixed (even though i believe we tried both). but the disconnection is an interesting tid bit and may help to solve this mystery. the motor drives a rod that is surrounded by a cloth belt that spans the width of the robot the cloth is tensioned by another rod at the top of the rod that has a bearing in it to allow it to spin along with the driven rod. something that does not support the disconnection / vibration possibility is that the wheels that shoot the balls out at the top of our robot vibrate alot and do not affect the robot at all, plus the belt does’nt really vibrate at all, it slides

#12

Could this post be of any help?

#13

Either port on the DS can be used. The watchdog is on the cRIO and will disable all ports if more than 5 packets (~100ms) are missed. This is hard programmed into the FPGA on the cRIO. When the watchdog is tripped (not fed) then ALL outputs are disabled (This would explain ALL of your speed controllers shutting down), this is a safety feature to prevent a runaway robot.

You might want to look for shavings or debris inside the cRIO ethernet ports (or damage to the pins) as that (with vibration) would cause communication corruption.

Daniel Krastev & Creator Mat,

I doubt it’s an electrical issue because he states that it works on the playing field but not (Tethered) in the pits. Therefore I suspect the tether system (ethernet ports and cable)

#14

well it does help a little, there is actually dipit on the cloth itself (oddly enough to try to gain some friction for the orbit balls) but we did try the static theory out by connecting a copper wire to the closest metal contact to the rollers and the moter speratly and connecting the other end to a ground, the negetive lead of the input voltage.

with the current theorys brought forth, they all have their counter points

  • current draw spike
    *when the motor was disconected from the belt it was driven fine as long as we wanted, but when conected again to see if the current did spike, the device we used to measure the current draw on the system did not spike above 16 amps, with the occasional 20 amp reading for a split second

-static theory

  • the combonation of the metal rods making a vandergraf generator causes the static charge to spike and discharge resulting in a system failure.
    this was tested against multiple grounds connected to key points on the system and still the problem accurs

-vibration theory

  • the vibration of the robot results in the disruption of the ethernet cord and therefore forces the watchdog to shut the speed controllers down.
  • the motor and belt in question does not vibrate more then the other components that do vibrate alot more and can run for as long as we like.

Temperature theory

  • the motor did not heat up at all through out the days use

Dead battery theory

  • the battery was changed multiple times

if i missed one please help lol. this problem is really stumping alot of people and im glad everyone is helping

#15

You should also make sure that your DSC is connected to a red/black WAGO pair on the PD with a 20A breaker. We’ve seen teams used the camera power port instead (which is only 5V and therefore causes the DSC to brown out very easily).

Also make sure that you’re getting a full 12V to the DSC. All 3 power LEDs near the power jack must be fully lit. If not, you’ve probably crimped some insulation instead of copper at the PD’s WAGO connections and are being intermittently powered via the 37-pin ribbon cable to the cRIO (which can provide a couple of milliamps and fool you into thinking everything is fine until you try to drive a larger number of speed controllers or spikes).

Russ

#16

Xeno,
There is a good possilbity that your battery wiring is faulty. Check to see that all hardware is tight and all crimps are secure. Pull and tug on the wiring from the battery to breaker to PD. The 120 amp breaker may also be defective. With the robot on, try lightly tapping the red button, if the lights on the robot flicker, replace the breaker. You may also try tapping the body of the main breaker with a screwdriver handle to see if it is intermittant. We had a bad breaker in KOP this year that failed when tapped on the body. Double check your voltge readout on the DS, does it stay at 12 volts when you try things out? A small variation is normal when the robot is not running on the floor.
There are a few things that would point me to change the CIM motor. Although highly unlikely, there is a possibility that there is a defect in the CIM such that once the temperature starts to rise internally, the motor shorts. When you run it with no load, the temperature doesn’t rise nearly as fast as when you you load it. To isolate, remover the breaker for that motor and run the robot. Does the condition reoccur? If not, that points to the motor or the motor wiring.
Finally, the resistance reading to chassis is fine if it is over 100,000 from any terminal on the PD with the battery disconnected. You can have a 40 meg ohm reading with someone touching the chassis.

#17

Sorry this is likely too late for you, but on another thread I described some strange behaviors generated by static. I’ll copy it below so you don’t have to go look for it. Hope it helps.

Hey folks,

Not sure if all your static issues are wheels and airlocks; our (1391) experience at Jersey was something else altogether. Almost all of us are spinning some sort of insulator (rubber, plastic, urethane, etc.) around - quite often - another insulator (PVC or ABS rollers) and when they aren’t enough alike … whoops. We have created VanderGraf generators that send spike charges from the rollers into someplace or another that finds its way to where we don’t want it to be.

During practice rounds, we watched our robot run for 25 seconds, then stop as the CRIO rebooted, then run another 10 seconds, reboot, etc. This was early on and no one else had run into this, so we began from ground (no pun intended) up back in the pits. Curiously, static wasn’t considered early - we looked at current draws, 24V supply, voltage differentials, code, etc - anything that we thought might stop he processor cold. Eventually, at 7:45 in the evening, I disconnected everything, including motors, ancillary code, and hand manipulated our belt collector - bam! same behavior as all day. We could shut off the CRIO with me as the motive force.

By next morning we had: 1. rubberized our PVC rollers with DipIt spray paint (to make the roller more similar to our belt); 2. put a 3/8" aluminum rod across the frame that touched the roller (to dissipate charge rather than having it build up and spike), and 3. begun to spray our belt prior to each round with Static-Guard (yep, the grocery store solution.)

No more problems. Ends up the static spikes were traveling through PWM cable connections - can’t expect any processor to handle that, other than to reboot. We built the static generator, after all. All the ideas mentioned previously won’t deal with the delivery of an internal spike to the processor, so think through your observations carefully. I really don;t think frame charge is the issue - you did insulate your processor board after all, right? The processor was just doing what it was designed to do to avoid damage. The clue we finally had that it was PWM was that even when the camera was turned off, and we had disconnected the wires to the Victors (but not the PWMs), the camera’s servos were ‘twitching’ the camera for a couple spikes before the CRIO cut out.

Hope this helps.
Reply With Quote