Problem: Pneumatics randomly fire when on wifi. Problems stop when connected via ethernet
Preliminary diagnosis: Wifi interference
Other details: The only problem is with the solenoids, the drivetrain and other motors are completely unaffected.
Any ideas how to fix this?
Patrick Barone
Do you have any strong electromagnetic fields near where this happening. We have had issues with our welder being used and having the crio wiped, encoders blown, and wifi jump, even laser mice stop working. Just something to check don’t know if it well help you.
If they are single solenoids, then the symptoms could be caused by a momentary watchdog from an intermittent WiFi connection.
Does anyone know how to make the connection more reliable?
Excluding the other issues keep your bridge as exposed as possible on the robot, and if you are using in conjunction with a router try to keep a clean line of sight between the two. Try to keep the wifi network used for just robot operation as well
We had a similar problem with our robot in 2010 and it turned out to be the cRio losing it’s isolation with chassis the because of a misplaced screw. Once it was fixed the problem went away.
The only thing we could figure was the pneumatics and cRio are the only things on the 24vdc power and that somehow created problems with the ground.
Sam et al,
We have found that electrical issues occur when the Crio finds a common point on the frame and another electrical component also finds a common point somewhere else on the frame. Often this is a shorted motor or motor wire that has become frayed. When the device is powered, it is possible to subtract from the Crio power supply through the frame of the robot. The result is generally a reset of the Crio, an event that can last from 20 seconds to nearly 50 seconds dependent on software loaded. In your case it sounds like the Crio chassis was connected to robot frame while one of the pneumatic valves +24 volt was touching the robot frame. A pneumatic command would then short the +24 volt power to the Crio. The negative lead of the power supply on the Crio is connected to the chassis. It is for this reason that the Crio must be insulated from the frame of the robot.
Why would the problem go away then if I change from wifi to ethernet?
If it is not a WiFi issue but rather a cRIO short, ethernet shouldn’t make a difference as the cRIO is still going to have issues with rebooting or unresponsiveness.
If it is a WiFi issue ethernet should solve the problem from my knowledge.
Our team has also experienced this, but I have not had it tethered to see if it goes away. From our experiences, it is actually the Cypress PSoC losing connection to the Driver Station for whatever reason, and re-initializing, setting everything to a “false” term for a split second. In our code, we have latching variables, so we sometimes see both our claw and our minibot deployment activate randomly. Once, it nearly took a teammate’s knee out because it fired randomly… Would like to see a fix to this also.
We had an issue with interference from our school’s local WiFi system. The radio was scanning and attempting to use one of the same channels that were being used by the schools network. This was identified by connecting a default reset bridge to a web browser and scanning for all networks. This identified the issue by showing two systems attempting to use the same channel. I just changed the radios in the robot link to use a different channel and the problem went away.
-Hugh
Do the lights on the cRIO module blink when the solenoids misfire?
If yes, it is a software issue.
If no, it is a hardware issue.
I’m 80% sure it is software.