No Twitch Servos

[AndyID]

Having just taken the plunge to use servos to operate three semaphore signals on my new layout I was interested to see this topic. When I first connected the servos, and signals, to the megapoints controller for testing I was a little surprised by the twitching from the servos. They were set up on my kitchen table, under fluorescent lights with a CD player working in the background and my bluetooth enabled phone close by and powered by a supply system recommended by Megapoints Controllers.

As I have never had an interest in electronics I'm afraid I didn't understand many of the concepts being discussed, though I did pick up on the potential for twisting the wires, so please excuse my ignorance and the following question;

Is there anything I can do (as a relative simpleton) to prevent/reduce the twitching?

Thanks for your help.

Cheers,

Ben.

 

Hi Ben,

 

Sorry to hear you are having a bit of bother. You are not alone, although some people report that they don't see any problems at all.

 

I've done a fair bit of mucking around with servos (the SG90 variety) and I'm afraid the method I've described in this thread is the only "cast iron" solution I've been able to come up with, and so far that's only on a test rig rather than on a real layout (that's "coming soon" )

 

I was hoping someone will take this idea and run with it as a commercial product. It's not complicated or expensive and they might be able to come up with something much better (hint to MERG and Megapoints.)

 

I'll post some pix later that show how I did it. If you can wield a soldering iron you can do it too.

 

Cheers!

 

Andy

[Junctionmad]

The issue of servo twitching has been discussed over time ad nauseous on the MERG forum. The issues are often quite diverse, and include interference coupled into the servo directly, couple onto the lines, generated at the microcontroler end, etc. There is also the issue of layout startup twitching who is often power related as well as situations where digital servos are used and attempt to drive up against a end stop ( say a point fully home etc ) 

 

 

The general view is that analog servos should have the power removed to prevent further twitching 

[Crosland]

The general view is that analog servos should have the power removed to prevent further twitching 

 

Turning off the control pulses is the usual way although there are die-hards who do not believe that the friction in a servo mechanism will hold it in place.

[Moggs Eye]

Turning off the control pulses is the usual way although there are die-hards who do not believe that the friction in a servo mechanism will hold it in place.

 

Hi,

Again, forgive my ignorance, but what does that mean in simple terms? I'm operating my signals/servos via an analogue system.

Thanks,

Ben.

[AndyID]

The general view is that analog servos should have the power removed to prevent further twitching 

 

That may be the general view, but unless the power is really removed, it's not going to help much. Interrupting the pulse stream during idle periods does not remove the power and that leaves the servo susceptible to further interference.

 

I'm pretty sure the nausea will continue until someone comes up with a solution that recognizes servos (SG90 and the like) have very little noise immunity. I did find a data-sheet for the controller chip that shows the input to the servo is actually the base of a common-emitter NPN transistor! Unfortunately I can't find that data-sheet on the web now. A copy may still be lurking somewhere on my PC. I'll post it if I find it.

[Junctionmad]

That may be the general view, but unless the power is really removed, it's not going to help much. Interrupting the pulse stream during idle periods does not remove the power and that leaves the servo susceptible to further interference.

 

I'm pretty sure the nausea will continue until someone comes up with a solution that recognizes servos (SG90 and the like) have very little noise immunity. I did find a data-sheet for the controller chip that shows the input to the servo is actually the base of a common-emitter NPN transistor! Unfortunately I can't find that data-sheet on the web now. A copy may still be lurking somewhere on my PC. I'll post it if I find it.

 

 

SG90 servo schematic 

 

datasheet on the chip http://datasheet.eeworld.com.cn/pdf/ETC/24676_AA51880.pdf, The inout resistance of pin 14 is not specified , but its obviously relatively high impedance.

 

The view is that power should be removed ( not just the drive signal ) , mods got various servo boards do this 

Edited January 10, 2018 by Junctionmad

[AndyID]

 

SG90 servo schematic 

 

datasheet on the chip http://datasheet.eeworld.com.cn/pdf/ETC/24676_AA51880.pdf, The inout resistance of pin 14 is not specified , but its obviously relatively high impedance.

 

The view is that power should be removed ( not just the drive signal ) , mods got various servo boards do this 

 

Thanks, yes, I have that one and the KC5188 datasheet too. They seem to be derived from the original Signetics servo chip.

 

Powering down does reduce the probability of a disaster, but there is still a window when noise can send the servo into the weeds. It also creates some other potential issues.

 

Which controllers disconnect the 5 volt supply to the servo? I'm sure others would like to know. The Megapoints controller does not appear to do that. Does the latest MERG do it? I know the original versions didn't.

[Crosland]

Which controllers disconnect the 5 volt supply to the servo? I'm sure others would like to know. The Megapoints controller does not appear to do that. Does the latest MERG do it? I know the original versions didn't.

 

Not the MERG one, that just turns off the control pulses. I'm not aware of any that turn off power, and had never heard of it until this thread. It would add considerably to the cost of the controller if each servo's power were switched individually.

[Junctionmad]

Not the MERG one, that just turns off the control pulses. I'm not aware of any that turn off power, and had never heard of it until this thread. It would add considerably to the cost of the controller if each servo's power were switched individually.

Switching the servo power is easily accomplished and not costly ( ie s mosfet ) the view on various discussions was the only way to protect the servo against twitches was to power down the servo

 

Personally I don’t have a problem , but I have a custom MERG board and custom software.

[AndyID]

Not the MERG one, that just turns off the control pulses. I'm not aware of any that turn off power, and had never heard of it until this thread. It would add considerably to the cost of the controller if each servo's power were switched individually.

 

Some people have the impression that interrupting the pulse train is the same as "powering down" the servo. That is definitely not the case.

 

I was going to post a quote from Megapoints on the subject but the website seems to be down at the moment.

 

Powering down the servos seems like another band-aid fix to me. My personal preference is to attack the root cause of the problem (the susceptibility of the interface to interference). It might be possible to locate opto-couplers at the controller end rather than at the servo end. Then they could be incorporated into the controllers themselves. In theory it would just be a form of digital current loop signalling which some of us might remember. I have not tested that configuration but I might try it when it's warm enough for me to use my workshop again.

 

BTW, has anyone tried running a test where each servo has its own floating battery? They seem to work quite well that way in RC aircraft and cars. Maybe I'll try that too.

[AndyID]

Update:

 

The most logical place to put the optocoupler would seem to be close to the servo itself but it seems to work just as effectively if it's at the pulse source. I have a servo connected by a 16 foot long slightly twisted-pair cable to my pulse source. Without the optocoupler I can make the servo go bananas every time I turn on or off a fluorescent tube above my work-bench. With the optocoupler at the pulse source I can't even make the servo twitch at all.

 

That makes some sort of sense. In both configurations there is no galvanic connection between the pulse source and the servo. They do not share a common reference plane. As long as the cable is twisted sufficiently to cancel or diminish the effects of EMI impinging on it the effect is pretty much the same regardless of where the optocoupler is. It's almost as good as connecting them via a fiber-optic cable.

 

In practical terms this means that optocouplers could (personally I think "should") be included in servo controllers to eliminate problems caused by interference from other sources, and there are plenty of them on model railways. Optocouplers are really inexpensive, so why not?

 

 

[Suzie]

What you are seeing by adding the optocoupler is that you are generating a source with a source impedance of 1K or less (assuming that you are using a 1K resistor). This will overcome problems in the controller. These problems occur in two situations:-

 

1. When you first power on and the controller has not configured the output to be a bipolar output. On many microcontrollers input is the default setting so it is important in the controller design to set the pin that is used to generate the servo pulses as an output. You don't need an optocoupler to fix this problem - just adding the 1K resistor should sort it.
2. When a controller is configured to stop sending pulses or is designed to be used with a pull-up resistor that is not fitted.

If you are seeing this fix work it suggests there is a problem in the design of the controller. It does not need an optocoupler to fix it, better firmware or a resistor will do it.

[AndyID]

3 hours ago, Suzie said:

What you are seeing by adding the optocoupler is that you are generating a source with a source impedance of 1K or less (assuming that you are using a 1K resistor). This will overcome problems in the controller. These problems occur in two situations:-

 

1. When you first power on and the controller has not configured the output to be a bipolar output. On many microcontrollers input is the default setting so it is important in the controller design to set the pin that is used to generate the servo pulses as an output. You don't need an optocoupler to fix this problem - just adding the 1K resistor should sort it.
2. When a controller is configured to stop sending pulses or is designed to be used with a pull-up resistor that is not fitted.

If you are seeing this fix work it suggests there is a problem in the design of the controller. It does not need an optocoupler to fix it, better firmware or a resistor will do it.

 

What I'm doing is eliminating any galvanic connection between the controller and the servo and at the same time making the signal differential so that I can operate servos at considerable distances from the controller without any possibility of EMI making the servos twitch.

 

By inserting an optocoupler at the controller I can drive a servo sixteen feet (and probably much further) from the controller and I cannot induce any twitching whatsoever from an EMI source that will produce twitching in servos that are directly connected to the controller without any extension leads. Playing around with the input resistance can make some minor improvements but they are quite insufficient for long distances or electrically noisy environments.

 

We can also eliminate the firmware. It isn't doing anything. All it does is programs the counter/timers in an ATTiny44A to produce continuous pulse streams then it goes into a do nothing loop.

 

Anyway, why all the resistance to optocouplers? They are highly effective for increasing noise immunity and they are also cheap as chips. I imagine most people would want a solution that works all the time rather than one that sort of works some of the time.

[Suzie]

If you put the optocoupler at the servo end of the wire, yes it will make a difference electrically - but put it at the controller end? It should not make a difference. If it does it is well worth investigating why.

 

I know that opto-isolators are cheap - but they are not necessary at the controller end - the microcontroller can easily drive the signal wire with an impedance much lower than the 1K source impedance you get with your opto-isolator circuit.

[AndyID]

1 hour ago, Suzie said:

If you put the optocoupler at the servo end of the wire, yes it will make a difference electrically - but put it at the controller end? It should not make a difference. If it does it is well worth investigating why.

 

I know that opto-isolators are cheap - but they are not necessary at the controller end - the microcontroller can easily drive the signal wire with an impedance much lower than the 1K source impedance you get with your opto-isolator circuit.

 

Yes, but it's not simply a question of impedance. Optocouplers eliminate the effects of ground shift between the sender and receiver and if they drive into a twisted pair a differential signal arrives at the receiver with a lot less interference from sources of EMI.

 

But I have been doing a bit more testing and I get the best results by putting the optocoupler at the servo end rather than the controller end.

 

BTW, I'm using cables more than 30 feet long, so it is a bit extreme

[Crosland]

16 hours ago, AndyID said:

 

Yes, but it's not simply a question of impedance. Optocouplers eliminate the effects of ground shift between the sender and receiver and if they drive into a twisted pair a differential signal arrives at the receiver with a lot less interference from sources of EMI.

 

Ground shift is a wiring issue.

 

It's not a differential signal. One wire is still 0V, the other only ever switches between 0V and 5V.

 

16 hours ago, AndyID said:

 

But I have been doing a bit more testing and I get the best results by putting the optocoupler at the servo end rather than the controller end.

 

I'm with Suzie, it shouldn't make any difference if everything else is OK, but I can't explain why

 

[Grovenor]

Andy,

Just saying that you insert an optocoupler is open to an awful lot of misinterpretation.

Could you perhaps provide us with a copy of your circuit showing what you are putting between the 3 pin header on the driver board and the 3 pin connector on the servo lead.?

[AndyID]

4 hours ago, Grovenor said:

Andy,

Just saying that you insert an optocoupler is open to an awful lot of misinterpretation.

Could you perhaps provide us with a copy of your circuit showing what you are putting between the 3 pin header on the driver board and the 3 pin connector on the servo lead.?

 

Good point Keith.

 

I'll produce a better diagram and some pics.

 

I've been testing some other configurations this morning but I still get the best result with the optocoupler at the servo end. I think it probably does do some good putting it at the controller end too but if it does I have not been able to quantify how much. My test rig is pretty basic and rather brutal. It's not much use for anything other than go/no-go testing.

 

Andy

[AndyID]

Here's the schematic.

 

 

There are four wires rather than three. Two are +5V wires between the controller and the servo end. You might be tempted to think you can eliminate one of them but doing that will seriously compromise the noise immunity of the circuit and result in servo twitching. I've tested this configuration with thirty foot cables and a very aggressive interference generator. I can't make the servos twitch. Other configurations might provide satisfactory results for some but I'm looking for a solution that is solid enough that I'll never have to worry about it.

 

If you supply power to the servo with a remote five volt PSU you can eliminate the lower twisted pair cable.

 

The twisted pair cables I'm using have a "lazy twist". A full twist is about two inches. I think CAT 5 cable would work quite well but I have not tried it yet.

 

 

 

Edited August 9, 2020 by AndyID

[Trofimow]

Declaring an interest here...

 

I also have a number of servos, arduino controlled, over twisted wires between 10 and 25 feet long.

 

Servo twitch , though not a show stopper, is a nuisance.

 

After following this thread, it seems worth a try, so I've ordered the necessary bits and pieces to trial this proposed solution.

 

I'll report the results in due course....

[Grovenor]

Thanks Andy, looks interesting. Should work fine.

[AndyID]

Of course there's also a way to eliminate the long wires between the controller an the servo.

 

 

If you don't mind adjusting the point throw by mechanical means you can use a simple pulse generator to drive as many servos as you like. The pulse generator continuously outputs pulses of two widths and you simply select which one to drive the servo for the two servo positions. I've programmed an ATtiny44A as my pulse generator. (Code available on request.)

 

Here I'm using one pole (RLa) of a two pole changeover relay to select the servo pulse width. The other pole (RLb) provides a convenient means to control the point's frog polarity.

 

Obviously the point control switch can be as far away from the point as you like. ATtiny44A's are very inexpensive (about $1 here) so they can be distributed liberally around the layout to keep the servo leads short. The relays are not expensive either (less than $1)

 

 

 

RelayVersion1.pdf

[Junctionmad]

As I mentioned elsewhere  here’s my circuit , positioned close to the servo 

 

personally , and testing the configuration there are two benefits 

 

(a) the major benefit is the reduction of input resistance of the servo control line. This to me is the single biggest issue that is resolved 

 

(b) the introduction of a floating servo pwr , as far as the servo is concerned , ie no local GND , this means we get some additional noise immunity from induced noise shifting gnd or 5V or the signal line to the opto. 
 

the other area to take care off is the configuration of the drive signal , or a pull down resistor is useful for this ( for positive logic ) , this handles the issue of inadvertent transitions on the io line   

 

 

 

 

Edited August 21, 2020 by Junctionmad

[Grovenor]

Did you perhaps attach the wrong circuit?

[Trofimow]

Well, the parts arrived, so I've done a test using AndyID's drawing in the first post.

 

I use the servos in question to mount CCTV cameras for fiddle yard monitoring, controlled via arduinos. ANY unwanted servo movement is immediately noticeable on the picture.

 

Preliminary results are that servo twitch is not completely eliminated, but is greatly reduced, probably by better than 80%, certainly enough of an improvement to be worth fitting to all the cameras.

 

I'm wondering if it would be worthwhile doing the same between the control output and the long wires, so having the opto isolation at both ends. I'll give this a try when time permits.