PICAXE, improving servo control

edmunds

Senior Member
Dear all,

I have many picaxe projects involving one or several servo motors to control. All in all it is working. At the same time, the operation is somewhat jittery and not as precise, as I would like it to be.

I would like to improve reliability and stability of operation as much as possible. Fine-tune, if you want.

I have several commercially available boards that are performing better than my own creating that I have examined carefully to see what the main differences are.

By far the most stable and trouble-free decoder I have here is based on ATmega 28 pin chip and controls 8 servos. The board has three main areas - power supply, RS323 connection and servo control. The first two are no rocket science, nothing interesting there. The servo control is interesting, however and I would like to discuss it with you.

8 pins from the ATmega go to 8 servo data lines through SN74LS541 (http://www.ti.com/lit/ds/sdls180/sdls180.pdf). I read the data sheet of this thing, but I'm still puzzled as to what it does. The good part is "Hysteresis at Inputs Improves Noise Margins", which sounds like something I'm after. If anyone can help with why and how, would be greatly appreciated.

Another 8 pins go to 8 transistor switches that switch the positive terminals of the servos. The only reason I can imagine this would be for is to prevent the servos from the startup jitter. In other words, you switch the servos on through the micro controller, rather than just with everything else. Or could there be another reason?

Does the above makes sense? I could try and design a servo controller based on picaxe like this. Maybe there already are similar projects out there.


Thank you for your time,

Edmunds
 
Last edited:

Circuit

Senior Member
This is most interesting - servo jitter, especially at switch-on, seems to be a problem that crops up regularly on this forum. I wonder if you have tried the MERG (Model Electronic Railway Group) servo drivers? One of the recommendations is that the signal line is tied high or tied low with a 10K resistor depending upon the brand of servo. Have you tried this approach? You can reference a section on servos and their kicking problems in this book on model railway electronics that you can download freely (http://merg.org.uk/ebook.php) see page 133. A differentiation is made between "kicking" and "twitching"; the latter occurring after switch-on. It is suggested that twitching is managed by capacitance between the signal line and ground.

It would certainly seem sensible to bring up the power to the servo via the transistor switches after setting up the control line signal and ensure a bounce-free switch on of power. With reference to the SN74LS541, are the legs 1 and 19 connected to the micro-controller? Is it holding the signal lines high or low or high impedance prior to bringing on the power?

Anyway, given your interests that are visible to the forum, I think that you will enjoy reading the electronics book that I reference; useful to have on a tablet.
 

eggdweather

Senior Member
As a model aircraft flier I have much experience of servos, so this is what I would look for:
1. Assume all servos behave in the same way? i.e. they are all jittery?
2. If one does jitter more than another, swap it around and does the jitter follow it, indicating a servo problem.
3. Usual causes are supply voltage too high, nominally 4.8V is the standard for model aircraft, so not 6 for example.
4. Servo mechanical connections are too tight or restrictive, thereby not allowing the servo to get to an error free place, usually due to driving to the set position, then overshoots, but then can't pull the linkage back and so jitter ensues.
5. Servo supply voltage has not been smoothed, so add some de-coupling capacitors, perhaps 10uF near the servos.
6. There is noise on the input pulse. Often solved by adding small value capacitors on the inputs, usually 1nF is enough.
7. Try a servo tester to see if it's the servos or the PICAXE signal.
 

Circuit

Senior Member
Sorry to hear your issues. I have found the M2 series amazingly stable for controlling multiple servos (up to 6) using servopos and disconnect commands, no extra hardware required. Demo video at https://www.youtube.com/watch?v=kF6TwbIT384
Eric, what a delight your robot is to watch! Congratulations on such a fascinating device.
Yes, you make two very important points; using disconnect and using servopos to adjust the servo after initial set-up; this has been mentioned in previous posts on the subject. What I cannot see from your demonstration though is the power-on behaviour. Do you see any servo "kick" at powering on? Clearly, you appear not to suffer any "twitching" during operation.

Edmunds, I guess from your previous posts that you are looking to control servos for model railway applications; presumably points and signals?
It is the power-on "kick" that can be damaging with such applications; some people seem to have had signal arms ripped right off by the power-on kick. Obviously there are mechanical interventions that can be used to mitigate this behaviour; for example the uses of omega loops in the linkages, but an electronic solution is definitely best.
The type of servo that is connected also appears to be a significant factor; quite distinctly demonstrated by the need for either tying the signal line high or low depending upon the brand of servo.
 

edmunds

Senior Member
Sorry to hear your issues. I have found the M2 series amazingly stable for controlling multiple servos (up to 6) using servopos and disconnect commands, no extra hardware required. Demo video at https://www.youtube.com/watch?v=kF6TwbIT384
Fantastic project! Thank you for sharing! :)

Although my application is more sensitive to errors and erratic movements, I guess.

The kind of things I'm talking about is servos opening windows (i.e. 13mmx4mm) and doors (22mmx5mm) of 1:87 buildings, servos raising ladders of fire fighting trucks of scale 1:87 (say, 70mm bumper to bumper, packed with other electronics) and similar. A few millimetres is a great deal. Even tenths of millimetres. Of course, I'm using mechanical means to compensate for some inaccuracies, but you can imagine there is not a lot of space for these either.

By the way, for reasons I cannot explain, my experience shows M2s are better than X2s with servos, which causes further problems, since I often need some advanced feature of X2.


Edmunds
 

edmunds

Senior Member
This is most interesting - servo jitter, especially at switch-on, seems to be a problem that crops up regularly on this forum. I wonder if you have tried the MERG (Model Electronic Railway Group) servo drivers? One of the recommendations is that the signal line is tied high or tied low with a 10K resistor depending upon the brand of servo. Have you tried this approach? You can reference a section on servos and their kicking problems in this book on model railway electronics that you can download freely (http://merg.org.uk/ebook.php) see page 133. A differentiation is made between "kicking" and "twitching"; the latter occurring after switch-on. It is suggested that twitching is managed by capacitance between the signal line and ground.

It would certainly seem sensible to bring up the power to the servo via the transistor switches after setting up the control line signal and ensure a bounce-free switch on of power. With reference to the SN74LS541, are the legs 1 and 19 connected to the micro-controller? Is it holding the signal lines high or low or high impedance prior to bringing on the power?

Anyway, given your interests that are visible to the forum, I think that you will enjoy reading the electronics book that I reference; useful to have on a tablet.
Thank you for that great reference ebook!

I have heard quite a lot about MERG group, but never joined due to the fee to pay. Not that I'm not paying some other online memberships, but MERG never sold somehow :). This is a fantastic peace of book, though, so I might reconsider again.

Switches for railway tracks are not a prime problem here, although, they would, of course, benefit of a better design. When you build Car System "switches" though, you need to move the tip of the servo arm about 5mm to turn the car left, straight or right. And there is not much more space for the servo to move without breaking something. Also, as I wrote above, servos are the mechanisms of choice for other moving things on the layout where even smaller tolerances are available.

Edmunds
 

edmunds

Senior Member
Summary #1

Thank you all for your valuable inputs!

So I gather I should try the following before adding extra components:

1) tie the signal line high or low with a resistor of say 10k;
2) try to use DISCONNECT command in the beginning of the code;
3) check if there are "better" or "worse" servos in some kind of systematic manner, as to make valid conclusions;
4) try if there is a difference between bench power supply 5V and ~5.5V battery operation;
5) try to add a capacitor between signal line and GND(?);

Then about extra components:

1) try the idea of transistor switch to power the servo after the initialisation of everything else;

Regarding SN74LS541 - on the sample board, pins 1 and 19 are both tied to GND. This is probably the least interesting data sheet I have seen in my life. It says that if these pins are high, the outputs would be high impedance (whatever that means :)), but not what happens if they are tied to GND or left floating.

Edmunds
 

premelec

Senior Member
I'm not well acquainted with the hardware available to you - my experience is that if you only need two position actuation a solenoid or small PM motor with string wrapped around the shaft can work well - with a spring also if that is useful. Spring coupling also works well where you want to avoid overstress. Neither of these things works well if you need very slow motion unless you use a dashpot sort of unit as well. Good luck with it..
 

Circuit

Senior Member
Thank you for that great reference ebook!

I have heard quite a lot about MERG group, but never joined due to the fee to pay. Not that I'm not paying some other online memberships, but MERG never sold somehow :). This is a fantastic peace of book, though, so I might reconsider again.

Switches for railway tracks are not a prime problem here, although, they would, of course, benefit of a better design. When you build Car System "switches" though, you need to move the tip of the servo arm about 5mm to turn the car left, straight or right. And there is not much more space for the servo to move without breaking something. Also, as I wrote above, servos are the mechanisms of choice for other moving things on the layout where even smaller tolerances are available.

Edmunds
I am delighted that you find the book of interest. It really is a great contribution to the world of model railway electronics - as is MERG. I joined up several years ago and the benefits of membership far far outweigh the membership costs. The MERG kits are all open source and the schematics, firmware etc. are all downloadable for members. I would urge you to join. I really look forward to the MERG Journal dropping through the letterbox; it is a full-colour A4 journal with heaps of relevant articles, schematics and ideas in general. Once you are a member you have full access to all the back-issues as .PDFs on-line.

I think that we are working on similar applications; I also use PICAXE for model railways/Faller Car System - I have followed a number of your threads with interest. I have played with servo drives also, but when it comes to a simple two-position movement I resort to using limit switches on motor-driven cranks. I fire up the motors through an H-Bridge (L293D)with diodes across the limit switches, so a simple reversal of polarity activates the change. I drive the L293Ds with a hex inverter (74HCT04) so I only use one pin from the PICAXE chip for each unit - and there is no limit on the number of outputs that I can use on each chip. I make up my own mechanisms and they work without fail or error. I am switching my Faller Road system vehicles around the circuit with total reliability; as well as all the other bits and pieces that need a two-position drive. Somehow the servo approach just seemed too dodgy. I also found that trying to make the servos start up without throwing a convulsion, hold their position for hours on end without twitching and then switch off without a dying spasm was rather challenging - achievable ...just, but really not worth all the effort.

I take note that you are switching the Car System with three-position points; I have limited my system to two-positions; straight-on or turn-off. Three position can be achieved with an intermediate limit switch, but I do see your interest in servo drives for this purpose. I do wonder what sort of junctions require such turns; if a vehicle is at a cross-roads (assuming you are driving on the right) it will either turn immediately right or move forward to turn left into the appropriate lane; two two-way turnouts accomplish this very well. What sort of turn-outs are you using? The Faller electromagnets seem to work rather well, but are you using some sort of moving guide-wire?

Model railways present a very different set of problems to model aircraft or robots; usually we have fairly long leads that often travel parallel to lots of other leads, some of which transmit quite high currents and are very noisy indeed. I have a friend with a layout that exceeds 10 m x 10 m and all the points (more than 60 of them) fire up with truly massive 24 volt capacitor discharge units. The radiated noise is simply incredible. Old locomotives, many of them fine etched-brass jobs of great value, run around with their open-frame motors sparking away enthusiastically, the rails providing most effective antennae. This provides a truly hideous environment for small-signal cabling.

Another issue with servos is the speed of operation; in many instances I want a smooth and slow movement; for example, the opening of doors on loco houses and the garages of buildings. I tried code to move the servos slowly, but most of the time a degree of jerkiness could be seen. My own mechanisms now work really smoothly and reliably without any great complexity and at the speed that I design them for.

It is worthy of note, though, to see that PECO have just launched a servo-drive for point motors and signals. I was considering buying one just to get an idea of what they are doing, but I now so content with the limit-switched micro-motors that I have rather lost interest in the servo approach.

Anyway, you have started an interesting discussion which I hope will attract other comments.
 

Circuit

Senior Member
Regarding SN74LS541 - on the sample board, pins 1 and 19 are both tied to GND. This is probably the least interesting data sheet I have seen in my life. It says that if these pins are high, the outputs would be high impedance (whatever that means :)), but not what happens if they are tied to GND or left floating.

Edmunds
A signal line can be high (driven voltage on the line) or low (connected to ground). Either of these states "drives" the line connected to the output. "High Impedance" is effectively a disconnect; it means that the output is not driven high or low and therefore the line can be driven by another chip on the same circuit elsewhere. The main application of "three-state line-drivers" is where several chips are connected to a single set of data lines or "signal bus" - it allows any chip on the bus to take control and not find that the line is being shorted to earth by another drive chip on the same circuit. I was interested to find if the "disconnect" state was being used, but clearly from what you say it isn't. I would imagine therefore that this driver chip is being used simply to isolate the outputs of the microcontroller and to ensure a consistent drive current on the signal wire. It probably isolates the microcontroller from any interference on the signal lines as well. I am guessing that interference on the signal line would be blocked at the line driver and would not so easily spook the microcontroller.
 

edmunds

Senior Member
A signal line can be high (driven voltage on the line) or low (connected to ground). Either of these states "drives" the line connected to the output. "High Impedance" is effectively a disconnect; it means that the output is not driven high or low and therefore the line can be driven by another chip on the same circuit elsewhere. The main application of "three-state line-drivers" is where several chips are connected to a single set of data lines or "signal bus" - it allows any chip on the bus to take control and not find that the line is being shorted to earth by another drive chip on the same circuit. I was interested to find if the "disconnect" state was being used, but clearly from what you say it isn't. I would imagine therefore that this driver chip is being used simply to isolate the outputs of the microcontroller and to ensure a consistent drive current on the signal wire. It probably isolates the microcontroller from any interference on the signal lines as well. I am guessing that interference on the signal line would be blocked at the line driver and would not so easily spook the microcontroller.
Well, thank you for that explanation, confirms my guess then that this helps to protect mcu from the noise created by servos themselves. I believe this must be the number one problem, why my picaxe projects show less stability than the unit in question. The chip happens to be in a socket, so I'll just drag it out and try to copy the arrangement with PICAXE chip at some point. Seems well worth the experiment by now.

Edmunds
 

edmunds

Senior Member
I take note that you are switching the Car System with three-position points; I have limited my system to two-positions; straight-on or turn-off. Three position can be achieved with an intermediate limit switch, but I do see your interest in servo drives for this purpose. I do wonder what sort of junctions require such turns; if a vehicle is at a cross-roads (assuming you are driving on the right) it will either turn immediately right or move forward to turn left into the appropriate lane; two two-way turnouts accomplish this very well. What sort of turn-outs are you using? The Faller electromagnets seem to work rather well, but are you using some sort of moving guide-wire?
It just saves a lot of space :). Similar to 3-way turnout. Some day I will publish some pictures, but I 3D print a ~80x40 plastic "road insert" that contains a servo with a piece of 3mm magnetic band on the arm and an IR receiver (cars have digital decoders that transmit the type of vehicle downwards among other things). Depending on the data received on the sensor by an approaching vehicle and physical configuration of the crossing, the servo routes the vehicle appropriately and makes the vehicle indicate the turn signals if necessary. The judgement about the route takes place in about 20mm of travel of the vehicle and takes into account the rest of the vehicles approaching the crossing. The "road insert" is placed about 50mm from the crossing itself, so you can pack a lot of traffic management in a small space. These "approaching lane control units" are connected to the "central control unit" (one per crossing) that is the brain of the whole thing. I will be able to further reduce 80x40 footprint when I redesign the board for a smaller SMD package of the chip. It all works quite nicely on a test layout - just some time for extensive real-life testing is needed and other matters have taken priority lately.

Edmunds
 

edmunds

Senior Member
I'm not well acquainted with the hardware available to you - my experience is that if you only need two position actuation a solenoid or small PM motor with string wrapped around the shaft can work well - with a spring also if that is useful. Spring coupling also works well where you want to avoid overstress. Neither of these things works well if you need very slow motion unless you use a dashpot sort of unit as well. Good luck with it..
Well, most of the times I do need slow motion. Never heard of a term dashpot and now googled it to learn something new :). Now I understand how the automatic railroad crossing from Viessmann works. I had suspicion that there is some hydraulics type of thing at play, but never new quite what and given the cost and fragility of the unit, never dared to take it apart.

Since then, however, I have learned to make my own crossings at a fraction of the cost driven by servos. A servo like this: http://www.mikromodellbau.de/Shop/artikeldetails.php?aid=946 does not even need to be hidden under the layout. It easily fits into the mechanism of the barrier itself.

Edmunds
 

techElder

Well-known member
Sorry to jump in here, because I'm only interested on the periphery of your project.

I'm curious whether you have (or intend to have) feedback from your servo activated switches? In other words, if you command your switch to change tracks, but a big pigeon lights down and gets a claw in the track right before it switches, how would your command system know the train is about to derail at that point? Or, perhaps just run into the back of a train already at the station?

Its an interesting problem, and would add some complication to your system (even without the pigeon's involvement.)
 

edmunds

Senior Member
Sorry to jump in here, because I'm only interested on the periphery of your project.

I'm curious whether you have (or intend to have) feedback from your servo activated switches? In other words, if you command your switch to change tracks, but a big pigeon lights down and gets a claw in the track right before it switches, how would your command system know the train is about to derail at that point? Or, perhaps just run into the back of a train already at the station?

Its an interesting problem, and would add some complication to your system (even without the pigeon's involvement.)
Well, not into rail problems at this point, but at least for now I don't have a solution for pigeon like problems. The way TrainController (a PC application of choice to run the railroad part of the thing) is built, is that it switches things expecting they would actually work and always remembers the last position. You can add feedback about if that has actually happened, but I think for vast majority of situations, the pigeon problem would be a rare occurrence. For these places it could be some sensor feeding a "switched" signal back or something. My experience with mid-sized layouts shows this is rather a theoretical problem and does not deserve allocating much investment of money and time. It is better to spend your time on making sure the "pigeon" does not happen than try to report and handle the fact it has happened.

Edmunds
 
Top