A 90 degree servo shaft rotation is highly appropriate for driving the ailerons on a model aircraft. The motion produced at the aileron through a crank linkage will be proportional to the rotation of the servo shaft, but if the servo were to even approach 180 degrees of rotation, the motion would no longer be proportional and the mechanism would tend to lock.
In the case of points, we don’t really care about proportional motion. In fact, if we can make the servo rotate through 180 degrees and convert that rotation into linear motion at the point tiebar, when the servo reaches the extremes of its travel (we could call them Top Dead Center – TDC, and Bottom Dead Center – BDC) the tiebar will not be able to exert any rotational force (torque) on the servo shaft. This is the same effect you see in any sort of engine where the pistons drive a crank of some sort or another.
Also, as the servo approaches TDC and BDC, the mechanical advantage increases (less linear motion for a given change in rotational angle), so the force exerted can increase at the extremes of travel.
At TDC and BDC, because no torque can be transmitted to the servo shaft, the servo is able to reach its desired position. As the error is effectively zero, the drive pulses stop and there is no buzzing.
Obviously this means that the connection between the servo and the tiebar must allow the servo to rotate through 180 degrees, and to make the connection without a lot of precision engineering, there probably needs to be some compliance (spring) in the connection. Compliance in the connection is a problem when the servo only rotates through 90 degrees because the spring exerts a torque at the servo shaft at the end positions, but that cannot happen with 180 degrees of rotation. I will post more on the mechanical connection later.
To produce 180 degrees of rotation I am using an Atmel ATiny44a microcontroller programmed to continuously produce short and long pulses. The short or long pulse stream is directed to the SG90 servo through a single pole (no center off) changeover switch. I should be able to connect a large number of servos to the same microcontroller each through its own switch, but I have not actually tried that yet. In some situations it will probably be a good idea to insert some sort of logic buffer between the microcontroller pulse outputs and the switch inputs.
The short pulse width is nominally 0.56 milliseconds and the long pulse is nominally 2.448 milliseconds. These are nominal because the ATiny is running on its own internal clock. (An external crystal might not be a bad idea.) To slow the servo’s travel, the pulse repetition interval is 74 milliseconds. At that interval, the motion is still quite smooth, although there is a slight pulsation during the rotation. It’s quite practical to use an even longer interval, but the motion will not be very smooth. I have tested this with ten SG90s, and they all rotate through 180 degrees, but that’s not exactly a very large test sample.
If we were prepared to alter the values of some of the components in the servo’s pulse-stretcher circuit to shorten the pulses it would be possible to slow the servo even more, but as the components are surface mounted on a teensy-weensy circuit board, I’m not even going to try it!
There is a servo connected to my “pulse generator” on the table beside me, and every so often I can hear it “tick”, and sometimes there are a few “ticks” in sequence. There is no perceptible rotation at the servo shaft when this happens. From time-to-time, the servo is detecting a small difference between the input pulse width and the internal monostable pulse width. Consequently, it tries to correct that error by sending a very short pulse to the motor.
I think this effect is a consequence of a small amount of “jitter” in the internal monostable pulse, and it seems to only happen when the servo is receiving long pulses. That tends to reinforce the theory. It may well happen during short pulses too, just less often. The clock source in the ATiny might also tend to wander around slightly so that could also be a contributing factor.
Personally, I don’t think it’s a problem, but some people might be less tolerant. If I get around to testing with a crystal oscillator, I will report whether it makes any difference or not. There is another solution, but that would mean surgery on the servo’s circuit board to increase the servo’s “dead band”. Braver souls might try this; I don’t plan to.
Going very tangential for a minute, I have actually “hacked” a couple of SG90 servos to operate as point motors by throwing away the electronics and only using the motor and gear train. The trick is to add a microswitch driven by a cam on the servo shaft. The switch is positioned to take advantage of its hysteresis such that it only changes polarity at the “ends” of the cam.
It works really well, and it’s 100% immune to noise. It only needs a single-pole changeover switch to operate it, but it’s not all that simple to make a cam that won’t interfere with the servo’s actuator horns. I also found that it works best from a 1.5 volt power supply. If anyone is interested, please let me know.
I was not sure whether to post this as a topic or a blog. As it's probably going to be a bit "long winded", I thought a blog might be best - so here goes!
Like many others I have been messing around with servos to control the points on my OO layout. In the process I've discovered a few things that might be helpful to others who plan to do something similar. There are some advantages associated with using servos, but there are also some challenges that must be addressed to obtain the most reliable operation.
Probably the greatest advantage is the cost of the inexpensive servos available. For that reason, all my experience is based on the least expensive servo that seems to be available, the SG90.
The Advantages:
Low cost
Slow/smooth operation (no seismic events)
Can produce large amounts of torque (turning force) relative to their size
Control by simple single-pole changeover switch
Switch position indicates point setting (no additional indicators required)
Not difficult to interface with automation and interlock circuits
Can be connected in parallel for crossovers, slips etc.
One inexpensive driver circuit can drive almost any number of servos (this might take a bit of explaining)
Low power consumption (when working properly)
The Challenges:
Can produce intermittent or even continuous "buzzing" sounds
Electrical interference (particularly with long connecting wire runs) can temporarily drive servos "bananas"
Can be a bit tricky to make a reliable connection between servo and the point tie-bar
While there are not that many "challenges", they can present some serious problems that might discourage modelers from taking advantage of these inexpensive devices. Bear in mind that we are trying to use these devices in a manner that is quite a bit different from their intended application in radio-controlled aircraft, cars, etc. Both the application and the environments are quite different from a typical model railway, so it should not be a surprise that we have to account for these differences.
There is not a great deal of information available on the internals of these servos, and it's probably best to try to explain what I've been able to find and figure out for myself. The better we understand the beast, the more likely we will be able to tame it.
The next post will go into the internal operation in some detail.
The SG90 is a PWM (Pulse Width Modulation) controlled servo, so the width of the pulses applied to its control input determine the position that the internal controller drives the servo to. Pulse widths are between 1 and 2 milliseconds, and are applied every 20 milliseconds (50 pulses per second). The servo assumes a nominal center position when the pulse widths are 1.5 milliseconds. The nominal extremes of position are plus and minus 45 degrees at the maximum and minimum pulse widths (1 and 2 milliseconds.)
At least, that’s the usual information about how to use these devices in their typical RC (radio- control) applications, and that makes a lot of sense. Radio-control requires proportional displacement of rudders, steering etc. applied through various rods and cranks, and the servos need to be able to exert approximately constant forces (torques) throughout their expected range of travel. They also need to be able to respond as quickly as possible to the signals received - any delay or sluggishness is not a good thing when you are trying to fly a model aircraft.
Neither of these are particularly important for controlling the points on a model railway, and in some respects, they actually make it difficult to apply these devices as point motors. We need the servo to operate in a much more sort of “binary” mode. In reality, it’s possible to achieve plus and minus 90 degrees of travel (180 degree rotation), and there is no particular reason why it is necessary to apply a pulse as often as 50 times per second.
The SG90 incorporates a KC5188 control chip. There is a data sheet for this device available on the Web, but it does not say too much! However, it seems to embody the same features as the old Signetics NE544, so I think it’s not unreasonable to assume that it’s a close functional equivalent, and the KC5188 data does seem to confirm that. The NE544 provides a bit more information, but it is not exactly comprehensive either.
Here’s a brief word description of how the things work (as best I can understand):
When the control input pulse goes “high” it triggers a monostable that produces a nominal 1.5 millisecond pulse when the servo is in its center position. The servo has a potentiometer on its shaft that alters the duration of the monostable pulse so that it is either greater or less than 1.5 milliseconds in proportion to the displacement from the center position. Over the expected 90 degree rotation, the pulse width adjusts from 1 to 2 milliseconds.
The servo motor is driven when there is a difference between the duration of the input pulse and the monostable pulse, and the direction that the motor is driven in depends on whether the input pulse is longer or shorter than the monostable pulse. The particular direction is stored in a flip-flop. So far, so good (I hope).
The sneaky bit is that there is a “pulse-stretcher” that produces a pulse to drive the motor. That drive pulse is proportional to the difference between the monostable pulse width and the input pulse width. If there is no difference, or only a very small difference, the motor does not receive any drive pulse. When the difference between the durations is at a maximum, the motor receives a substantial drive pulse to accelerate the motor rapidly. The smaller the difference (sometimes referred to as the error) the shorter the drive pulse.
Based on what I have seen, I believe the “going bananas” problem and the “buzzing” problem result from two different effects. The first is caused by electromagnetic interference/radiation (EMI/EMR) and the second is more commonly to do with the mechanism that transmits force and motion to the point tie-bar. Unfortunately, if we are not careful, in trying to solve the one, we might make the other worse.
From the description of how the servo controller chip works, if enough EMI energy is coupled into the servo input, the internal monostable will trigger and launch the servo into a cycle. During the cycle it will attempt to reduce, or eliminate, any error between its current position and the latest demand position it “thinks” it just received. If, by a complete fluke, the EMI happens to produce an input pulse width that is about the same as the monostable pulse width, the servo might just “twitch” slightly. The more likely result is that, thanks to the pulse stretcher, it will swing wildly through many degrees, and as EMI often comes in a burst of events, several cycles will launch and the servo will attempt to cancel the error for each one and swing erratically until the EMI subsides.
To make matters worse, the servo does not have a large amount of noise immunity while the input is in the “low” state. That’s not a criticism of the device. In the environment for which it is intended, its noise immunity is quite sufficient. The problem is that model railways can produce a lot of EMI from many sources, and if there is a long wire connecting the input of the servo to the servo controller, it will act as an excellent antenna and collect all the EMI energy it can.
The buzzing problem that many people have encountered isn’t really so much a problem with the servo itself. Buzzing occurs, either because the widths of the pulses driving the servo are not stable enough (which, in most cases, is not very likely), or (much more likely) the servo can’t quite get to the point of cancelling out the error because of mechanical “back pressure”. When that happens the servo will try valiantly to get to the position demanded, and it won’t quit trying until it does.
It’s very desirable to set the servo up so that it maintains pressure between the selected point blade and the stock rail. Unfortunately, maintaining that pressure means that the servo has to keep trying to get to a position it can’t quite get to, or does get to but is then repelled slightly because of compliance (springiness) in the mechanical connection. Even over-center springs won’t necessarily help because they can drive the servo beyond the precise position required.
It’s not difficult to observe this situation. Just connect a servo to a stable pulse generator and try to force the servo to a slightly different position with some finger pressure. (Not too much; you don’t want to strip the gears.) The servo will keep fighting back, and if the pulses are set to arrive 50 times a second, you will hear and feel a 50 Hz buzz.
To overcome this we could adjust the input pulse widths very precisely for each point so that the servo positions the blades at the “just right” position where there is almost no gap between the blade and the rail and there is no pressure exerted on the rail. There are a couple of snags with this. It’s a bit of a pain to have to customize the settings for each point, and it assumes that everything will stay constant over time.
Unfortunately, as the monostable in the servo is not clocked from a highly stable crystal circuit, it is susceptible to the effects of temperature and component ageing, and random noise within the servo itself. This means that, even if you precisely set the pulse widths at the controller to prevent a servo buzzing, there is no guarantee that it won’t start buzzing at some point in the future.
Another possible solution to the buzzing problem is to have the controller only send pulses to the servo for a limited time after the point direction has changed and rely on the considerable mechanical friction in the servo’s gear train to maintain the desired position. The problem with this approach is EMI. Should EMI launch a servo cycle, the servo won’t return to the desired position. It can remain in some indeterminate position indefinitely until the next real position update. Consequently, this method of eliminating the annoying buzzing problem can lead to a much more serious functional problem.
