Team having major sporadic operation, need fix ASAP, not sure if this belonged in Electrical forum…
Drive would periodically have lag and when idle, make pop corn sounding noise on its own (solenoids)?
I stopped believing it is code at this point (LabView). Moved everything out of Teleop except TankDrive and setting Globals
from JoyStick. Intstalled Elapsed Time VI, teleop will jump all over, 10mS as high as 400mS, without operation, just hit enable.
I believe it must be electrical interference at this point, not much code in teelop, not even driving robot (I know teleop
has to be <20mS). Error indicated something can be hogging it’s resources, but verified no other motors assigned to Tank Drive
PWM.
Electrical Static: This Robot does build up a lot of static. read several threads about putting wire from chassis to ground
Several opinions if legal this year, has anyone confirmed this is legal with documentation
Static build up also from belts, using over counter antistatic spray, I believe there is a better industrial
liquid spray to use on belts, has anyone found best antistatic spray to use on belts
Grounding: What is best way to Ground, here many opinions in links… and what is legal… Ground motors to chassis?
Need to isolate supply ground and Rio from chassis?
Caps?: Does anyone use capacitors across motor terminals? Has this helped? What value do you use?
Power Supply: Does anyone ad addition caps on power supply line? I do not have an Oscope to see
noise on supply line possibly getting on Rio supply, but thought this could cause sporadic problems?
Any other suggestions? Did try and comment out sections of code to eliminate problem, did have some improvements but
never 100% repeatable commenting out same section of code
Try running the robot with a wired network connection and see if anything changes. If you have a way to scan for wireless networks (e.g. inSSIDer), see if your robot has chosen a channel already occupied by another access point.
I spent a little time last night helping a local team experiencing “glitchy” robot control. The Charts tab on the Driver Station showed lots of clusters of lost packets. It got better when the D-Link DAP was moved out from underneath a motor at the bottom of the robot, but the problem didn’t clear up completely. We sort of correlated it with the direction the robot was facing, with packets disappearing more often when the radio was on the other side of the robot from the Classmate they were using for the Driver Station. Replacing the Classmate with my Gateway laptop resulted in nice, smooth control and very good communication. Putting the Classmate back brought back the problem.
They are using some newer lap tops, windows 7… Initially had hard time for Windows 7 recognizing the Robot wireless, after many changes, finally recognized it. It initially did come up wit IP conflict when put wireless IP in with team id… I thought is was because when run driver station, it automatically sets LAN to team/computer IP, that is what I thought conflict was… I am not use to Windows 7 or very experience with computer networks, can you point me to any help, papers that would help see if there are other conflicting addresses as you suggest?
I believe they did at one point try tether, but will have them try again
BTW: Do you add caps on your motor terminals? What value/voltage rating suggest? Do you add caps on supply lines?
Depending on what you mean by popcorn noises, it could be:
Circuit Breakers popping. Watch the PD for red flashing lights.
Spike Relays firing. Watch their LEDs.
Solenoids firing. Watch the LEDs on their controller (solenoid breakout or Spike), or feel them.
Static discharge. This is more of a crackly noise.
YES. You must isolate the cRIO from the chassis per R38. If your motors are are experience case faults, they too must be isolated from the chassis.
Capacitors are unlikely to help with the types of issues you are describing. Teams occasionally place small caps across motors to clean up with noise couple into their analog sensors. I wouldn’t add capacitance to the cRIO’s supply, it is already sufficiently bypassed.
As a side note, sometimes adding capacitance to a supply can make it unstable, as it tweaks the control loop unexpectedly. Current Gen PDs don’t have this issue, but a 2009 PD might not respond well if you added e.g. an a large electrolytic cap near the 24V output. Unfortunately, usfirst.org has the old schematics up for some unknown reason.
Theck your power and current return paths (it’s not really a ground) for your CRio, your D-Link and it’s power supply and your Digital Sidecar. Do a “pull test” on all crimps and terminals. We had a bad crimp on the power connections making a Victor behave very strangely.
Definitely see what happens with the direct ethernet connection and take the radio out of the equation. The commutators on the DC motors function as wideband noise generators and sometimes the noise ends up in the band that your radio is trying to work in.
Is your D-Link mounted on a metal plate? Sometimes, that can be beneficial and sometimes it can block the signal to the antenna. You can also try mounting the D-Link in a different orientation. The antenna performance was probably compromised to allow them to fit it inside the plastic box so it probably needs all the help it can get.
It is doubtful that the popping noise is the actual ESD. An ESD simulator, used for testing the immunity of industrial equipment, cranked all the way up only makes a soft crackle that is easily drowned out by the motors and other mechanical noises on your robot. It is more likely to be your relays cycling on and off or the PWM signals going to your motor controllers being corrupted and causing them to “change speed” suddenly making your motor(s) jitter.
Unless you have someone familiar with high frequency probing techniques available to help you look at noise with an oscilloscope, you may end up wasting a lot of time barking up the wrong tree.
Eric is correct that you can really mess up the power supply by indiscriminately adding capacitance to it. You would have to know how to use an oscilloscope well to check for this properly.
Are you using 2CAN? Our 2CAN Ethernet ports would drop when hit with static. It has something to do with the new CRio ports running on 100 MBS network vs 10 MBS last year. We solved it by adding an old 10mbs hub to the network until we got the new 2CAN with improved ESD protection.
Mark,
You may not “ground” any electrical components on the robot. If static is the actual cause, a “drain” might help pull some of the static from the belts to the robot frame. This usually takes the form of a flexible metal brush that wipes on the belt and is connected to the frame of the robot.
However, what you describe really sounds like a power problem. Often there is a whisker (a single strand) that pulls out of a connector either at the PD or at the Crio. This can add noise to the power supply that might interfere with Crio operation but often causes Crio reboot. Are you using the power convertor to power the radio? This is essential. Check that all wires are properly terminated (any hardware is tight and all crimps are correctly crimped) and insulated. The Dlink also needs to be mounted away from motors. While brush noise does produce interference, most motors are closed enough to shield the noise. The robot rules do allow you to place a 1mfd (or less) non-polarized cap across motors input terminals to help eliminate any other RF that might be generated.
There is one last item you can add for static. You can drag a bare wire underneath the robot that is connected to the robot frame. In most cases this does nothing as the carpet has no conductive fibers. If you add this wire, it may not extend outside the frame perimeter at any time.