Let's Make Robots!

Where is all this noise coming from?

Hey folks,

I am finally getting around to Walter's autonomous drive mode and have run into a noise issue. It seems that my motor driver (this one) is affecting my sharp IR sensors. I am still running the motor driver off of a 14.4V DeWalt drill battery as I can't afford proper batteries yet (I don't know if that makes a difference). The Picaxe 40x1 is powered by 5 AA's with a 7805 regulator (included with the regulator is a 220uf+ cap, a 10uf+ cap and a 100nf ceramic cap in a regular configuration). Of course, the regulator and motor driver share a ground. It seems, with the motor battery disconected, my sharps are a-ok spitting out a value of about 10 or so with nothing in front. However, when the motor battery is plugged in, they jump up to about 50 or 60 (on average) while fluxuating as high as 80 and as low as 1 in short bursts. Even more odd, when the motor driver battery starts going dead, the problem seems to be resolved. Is there a way to isolate the motor driver or can I get rid of this noise another way? Big caps somewhere, maybe?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hello ChrisTC,

Arties are cool, I think we all want to help were we can, the beauty of such forums is that it is the basis of a Collective Intelligence.

Being a techie, I thought I would throw a few more points:

Shorting unused pins, this is common practice on unused pins of various chips; the reason is if left unconnected, they can generate quite a lot, imagine say the input of an OR gate being allowed to float, the electrical noise would cause the out put to flap between 1 and 0, not good.

Now the caution, in many microcontrollers the ports can be configured as Input, Output or ADC, now shorting to ground or power should be ok for Input or ADC should be fine but if you accidentally configure the pin as an Output and you output a 1 (or the default value) with the port tied to ground (or vice a versa), the Microcontroller will probably burn the port out (over current); so the safest way of tying the ports is to use 1k resistor. If the chip in question does not support the pin as an output it does not matter.

Now PWMing, if your Pulse Width Modulation frequency is too low you get a buzz in the motors, the efficiency is not very good, as you increase the PWM Freq this buzz will go away however if you go too high the motor controller starts to burn power, I run at 10Khz with no problems. One approach to optimising the controller/motor is to measure the drive current (thru controller and motor) hold the motor speed constant (pwm width) and adjust the PWM Freq for the lowest current. Note very low PWM Freq and the motors will run erratically.

all the best

The object of PWM frequencies is first to get above the mechanical time constant of the motor, then to also get above the electrical time constant. The mechanical is pretty easy, something in the 100s of hz can do so for most motors, inertial reaction time being somewhat easy to overcome. The next, electrical, can vary quite a lot with different motors, based on the inductive nature of the devices. While 10 kHz may be adequate for some cases, in a couple decent quality Pittmans I have it will cause the motors to "scream". This is not an efficient operating frequency for those motors. For high quality coreless motors, PWM frequencies can be 60 or even 100 kHz. Industry standard to operate most (except coreless) motors is to go for 20 kHz, getting beyond human hearing range. The best way to ensure the drive controller is not burning power, is to use/design a high quality driver that can operate well at the frequency required.

Dude, please make more breaks in your text, like this:

Have you any unused analouge in's on your Pic? If so, I'd recomend shorting those, as I have experimented that not doing so causes strange readings in situations just like the one you describe.

From start here-robot:

how_20to_20start_20a_20robot_html_2805b34a.jpg

(read more on the page, you know where to find it :)

I'm not sure what hardware is on your picaxe board, but I'm pretty sure ai read in teh PIC manual that it's good practice to pull unused inputs to ground. For heaven's sake make sure you don't pull OUTPUTS to ground!

I have the exact same issue... and about 15% as well. Now to be honest, some of what you guys are suggesting/bringing up is a bit over my head. I do not have an osiloscope (or access to one) and really, I am an artsie not a techie. To give you a little background: First I am a builder but in my past I was a model airplane guy and more importantly, I was a huge car-stereo guy. In terms of electronics, I picked up most there (ohm's law and the like). For the most part, when you guys suggest something, I can test it (with clear instructions) and I figure out the lesson only after I have done it in a physical sense (any on-paper theory doesn't do much for me).

Now, riddle me this Batman... In terms of "brush timing" and running slower --also BOA mentioned his motors were themselves "PWMing". The only thing I can equate this to in my brain is harmonics in an engine. Without a harmonic balancer, the harmonics keep increasing on themselves untill failure. Is this even close to an analogy for the "reverberation" BOA speaks of?

In terms of my sent PWM, I am sending this:

pwmout 1,63,0
pwmout 2,63,0

main:

pwmduty 1,b5

pwmduty 2,b6

 

The b5 and b6 are controlled by either the auto-drive code or from the RC unit. To "straight-line" the unit, I am simply slowing the fast wheel with a b6=b6 max (X). For frequency, I used the picaxe wizard to figure out what frequency would lead to b5 and b6 going from 0 to 255. At different times I have changed this to go from 75 to 225 for obvious reasons.

 

As I sit now:

I have found that the pic and motor driver are happy (with no caps anywhere) when simply using RC drive code. I have done this with a pulsin (coming from the servo out on my RF RC unit) and also from another picaxe (with a  joystick) spitting numbers out serial to serial. The noise issue, and this thread, started when I started to code Walters auto-drive and that's when I noticed the issue with the sharps spitting out crap numbers. --I also noticed my SRF05 doing the same. I have taken the capacitor adviceand simply added one to each sharp across + and gnd. This seems to have solved all problems with the sharps (obviously going into  ADC channels). I have yet to play with my sonar, but my assumption is I will find the same. I have not yet added diodes to my relays, although I will probably do so as more protection couldn't hurt, and I have double checked that the flyback diodes on the motor-outs are a-ok and going the right direction per BOA schematic. 

I think that is it for now, my main problem of bad ADC data has been solved, and if I find a similar issue elsewhere my standard opperating procedure will be to add a .1uf cap. If this "noise" wants to rear it's ugly head again elsewhere, I will be sure to ask again. I am glad I am able to bring some fodder for geek brains out there to work on! Thanks for your help, folks.

Hi

 Is it more noisier with the motors running in one direction or the other, ie relay in or out.

Hi Chris,

That is a little weird, what type of motors are you using? Motors for RC cars often have the brush timing altered

to increase the performance in one direction (forward), I have never looked at this but I guess there might be a

difference in the noise produced. 

Do the motors run at the same speed in both directions? 

On thing which I would suggest you check is the  flyback diodes are soldered ok and are working

(use a multimeter with the power and motors disconnected). Another test is to run the motors for awhile and feel

the diodes if you have a hot one it is probably backwards but I would expect if this was the case the motors would

run noticably slower in one direction.

 all the best

 Cliff

 

This is defo the case with the wiper motors for which the original controller was designed. The speed difference between forward and reverse is phenomenal. It's about 15%. Which was really irritating because to get big chaser to go in a straight line, one of the motors needs to go backwards.

Actually, now I think about it, with my algorithm, one of the motors is always PWMing. That might be the key. Chris, are you using a fixed PWM frequency? I use a technique called "bit twisting" where the PWM frequency changes depending on the mark to space ratio. I would gess that if the PWM frequency is constantly changing, it acts as a filter, disallowing any "reverberation" from being set up which might amplify any interference.

Any of you electronics geniuses ever seen this before?

Now that you mention relays, I noticed that the problem seemed to be self-increasing. As the sharps were affected (and the code recognized an obsticle) a relay would click (per code) to turn the bot away. When this happended it seemed as if the relay click/ sharp affected/ more relay clicks pattern grew worse and worse.

Questions (or a little more clarity):

In terms of adding flyback diodes, I am to assume I can use the same units and configuration as the ones on the main motor connections, correct? 

In general, I really can't go wrong with 0.1uf ceramic caps on all power in and out of the picaxe. Thats a cap bridging + and GND.

Could I get a little clarity on the test with the 0.5k resistor on the PWM and rev. contacts? Just a little step-by-step on where-to-where the conections should be made.

One more: I looked at 4 channel optoisolators... Would this solve my problem entirely? Pros/ cons? And if this is a good direction to go, could you suggest a part number? All the ones I looked at did not support a 5V input and had a high in/low out set up which would require some transistors to switch it back.

 

Thanks in advance, guys -- I really appreciate your guidance and knowledge. 

Hi CTC,

 

Robologist has provided answers for most of your questions so I will just add a comment or two.

 First, do you own or have access to an Oscilloscope? If you do or can a photograph of the signal out of the Sharp IR distance sensors will tell us what is going on, flyback noise and switching noise have distinct traces compared to ground loop type noise.

There is a lot of software around to properly analysis this sort of problem but many older engineers just resort to one decoupling cap per TTL Chip. I ran in to a similar problem with the Sonar I am building, the transmitter put switching spikes on the power rails, two caps later and it was gone.

Optocouplers may resolve the noise but I doubt it, I think the noise is not coming back via the signal path (PWM/Relay control) but is being superimposed on the power or ground rails, if you use optocouplers you could completely separate the power supplies and ground rails.

Check your code and make sure you are not sending PWM to the relay control, if so you have just created a spark ignition system with no diodes (flyback voltages).

We will get there in the end.