Ultrasonic Interference

[ajlapp]

A few weeks back we added a Vex ultrasound sensor to our bot to help us close the loop on our absolute distance form the driver's wall during auton.

The system works great but suffers from extreme interference when we run our rotation joint. The joint has two Banebot 775 motors.

Even the slightest input into the motors causes erratic feedback from the sensors.

What's my best bet for eliminating the interference??

Thanks in advance.

[The Lucas]

First of all check for case shorts on the RS-775.

If that is not the problem, the simplest solution is to only pulse (enable) the ultrasonics when the RS 775 is off.
For a more in depth solution more info is needed. Where are the motors mounted in relation to the sensor? Are the sensors on the arm (ie moving)?

[ajlapp]

The are no case shorts. The sensor is not moving. The sensor is not near the motor.

We did a series of tests to isolate the sensor from the robot including holding it in fixed relation to a surface off the robot.....the interference was still present.

[The Lucas]

Hmm that is interesting, havent seen that before. Couple ideas for additional tests.

Have you tried placing a shield between the motor and the sensor (and any wall the sensor is using) to reflect or absorb any interfering sound?

Have you tried running a different RS-775 directly off a separate battery (using a breakout box or something) while using the sensor on the robot? (if you don't get interference in this case the RS-775 are likely interfering with the electrical system on your robot)

This is an interesting case to investigate, but ultimately I would just pulse the ultrasonics a couple times to check/adjust my distance (at the end of an encoder segment) and not run the RS-775 during these readings.

[Jared Russell]

We found this to be a problem as well. Even when the wires for the VEX Ultrasonic sensor were physically moved >1 foot away from any RS775s or wires for these, we would get erratic readings. This was unacceptable for the application (keeping the robot from slamming into the wall), so we gave up and used other options (using light sensors to detect the line at the end of the zone, and using encoders to dead-reckon).

[ajlapp]

We also have a similar workaround which uses encoder distance....but now we doing two tubes in auton. We need a fixed reference in order to determine or distance from the wall.

We cannot look for the end of line marker because of our arm geometry.

Perhaps we can take a series of snapshots on our way down....essentially halting the program and commanding zero pwm out of our arm joint so we can take a reading. We can then use encoder distance once we have a reference point.

Thanks for the help.

[The Lucas]

Originally Posted by ajlapp

We also have a similar workaround which uses encoder distance....but now we doing two tubes in auton.

I assume this is for 27 and you are grabbing the second tube by flipping your arm around (hence the RS775 needs to running most of the time). Have you considered trying 987's 2 tube path starting at the Y with periodic line checks. It is the most consistent and creative 2 tube auto I have seen. The periodic line checks & encoders give them all the field reference they need.

We use a whole bunch of sensors (ultrasonics, light, etc) for positioning on some of our single tube auto modes. But for our double tube only uses gyro and encoder because we don't have time (1 sec to spare) to check/adjust for the others. It is my understanding that most of the 2 tube teams (33, 1114, 148, etc) use only gyro & encoder.

Good luck with that double uber auto!

[Kevin Sevcik]

This is most likely just a big noisy motor causing electrical interference on your bot. There's a few quick and easy things you can try to filter the noise down to an acceptable level. It'd be great if you had an oscilloscope to measure things and see just where the noise is coming from, but if you did, you wouldn't be posting here, so...

First, put a 1 microfarad (uF), non-polarized capacitor across the leads of the 775, as close to the motor as possible. This should make the biggest difference.

Second, connect a pulldown resistor from the signal line of your ultrasonic to GND. This should probably be in the 1k ohm range. I don't have specs on the Vex ultrasonic handy, so I can't say what it will tolerate here, but 1k seems safe. You'll know if it's too large because you won't get anything back from the ultrasonic even with the motor off.

[Al Skierkiewicz]

Tony,
there are two possibilities here. One is electrical noise and the other is acoustic noise. Since the sensor is only putting out 40kHz it is possible that the motors generate enough acoustical energy in the desired band to swamp the sensor input or to modulate the body of the sensor. You can try to wrap the sensor in some foam, fiberglass or a chunk of pool noodle and see if that effects the interference. If it does then the motors are making significant noise on frequency. The other possibility and the more likely one, is that the sensor amplifier is not shielded and so therefore receives all of the generated electrical noise and boosts it along with the received acoustic signal. Without a scope and some controlled tests it is hard to tell exactly what is the problem. Considering that the output is a 5 volt digital signal, it is unlikely that the cable is picking up enough noise to be a problem. You can try shielding the sensor in a steel box but will need to tie the shield to something to drain away the charge. Robot frame or battery common might work but not both please. 3M sells a nice product that is a copper foil with a conductive adhesive available from Digikey. It is expensive and it comes in various widths. An 18 yard by 1" wide roll is about $50. You can solder to it with care but it may not take care of all of the interference.

You didn't mention it, but are you using Jags in this application? It is possible that the third harmonic of the switching frequency is close enough to produce significant in band noise.

[ajlapp]

We are using Jags...so this could be a factor.

At this stage we'll probably just read the sensor without moving the offending joint. This should give us a chance to calibrate our encoders without needing constant feedback from the ultrasound. i.e. we'll take a distance snapshot then track our encoders from that point.

We'll hopefully get a chance to dig into this in the post season.

Thanks for all of the quick responses.