Servo power cutoff?

[rrinker]

 Yes, I know. The proper way for a servo to work is that it constantly has power and the signal applied to hold it in position. But for the application I have in mind (model railroad point control), there is no need to maintain force on the servo to hold position. The linkage design results in an over center spring action. So in order to avoid any buzzing from the servo constantly pushing against the back pressure of the spring, I'd like to somehow have the power cut after some timeout. A commercial supplier of servo turnout controls has available a circuit that goes between the controller and the servo to accomplish this - but there are no details, and the circuit is shrink wrapped so in the photos you cannot see what is involved. I suppose I could buy one and open it up, but figured I'd ask and see if anyone has any ideas on how this can be accomplished. The commercial device is very inexpensive, so it can't be that complex, and since it goes in the servo cable between the controller and the servo, it does not involve code in the microcontroller. That IS another option though, since I am controlling my servos with Arduinos and I can do whatever with the code. There are some examples that mention using servo.detach() which stops the servo library from addressing the servo output pin, and this has somewhat worked. It may just be how my code is written, and I am continuing to experiment along those lines as well.

[packetbob]

Since you are using a microcontroller you could just use 2 pins to control each servo. Use one pin with the servo library to control the position and use another the other pin with a MOSFET (or other higher current driver) to turn the power to each servo on and off as you need to.

You may find that some servos can jump to a random position when first turned on if you don`t have a valid control signal attached. Seems to depend on the servo.

[Ian.M]

Its probably a tiny 8 bit MCU driving a P-MOSFET and intercepting and relaying the servo control pulse.  If the control pulse remains the same width for a certain time, turn off the MOSFET to cut the servo power and turn off the relayed pulse so it isn't driving an unpowered servo.

However its just possible the controller has to be smart enough to cut the servo signal, in which case it may be a CMOS 555 or  similar acting as a missing pulse detector, again driving the MOSFET to cut servo power.  This solution doesn't require a custom programmed MCU but the higher part count probably makes it more expensive, and adding missing pulse detection to the MCU solution would be trivial.

[rrinker]

 So I did some experimenting with the software method tonight, and it really seems like this is not practical, at least in my use case. It works - but you need massive delays (few hundred ms) before disconnecting the servo pin, or nothing happens. I found an example in the Arduino forums and they ran a full 1000ms delay. This sort of thing, I think, will be too much when I am doing the RS484 comms as well. I see 3 options:

  1. Do it in hardware - either buy the $4.95 commercial circuit for each servo, or buy one and see if I can reverse engineer it.
  2. Buy a commercial servo controller than can be trigged by an Arduino pin and leave the servo stuff to someone else (would get pricey)
  3. Make my own servo driver controlled by an Arduino pin. In this case, use a second Nano with the servo library in the program, say 8 inputs and 8 servo connections, and then drive that from the first Nano that has the RS485 - simple state change of a pin on the comm Nano, and the one driving the servos can have 1 second delays in the code or whatever works because it pretty much won't matter.

 I did do more hardware mockups of the servo and the linkage it will have, and actually it seems to work pretty well without any annoying buzz - the geometry of the linkage is such that it forms a bit of an over center spring and it takes a LOT of force on the music wire to apply enough force to the servo to make it try to back off, far more than would ever be applied when actually moving points. So I may not even need to kill the signal, just make sure I get the endpoints set correctly. I'm still thinking I would do #3 above, because the servo library uses interrupts and seems to be very timing dependent to generate the proper pulse train to each servo, so offloading that may be the better way to go - at $4 for each Nano, it's hard to say this is an expensive solution.

 One more option comes to mind. Since each servo will mount in the exact same geometry, the end points should be identical for all of them. I could build a pair of pulse generators with good old 555's (or one 556) and use the Arduino output to toggle which pulse train is fed to each servo. The single Nano could do this, again it's just switching outputs on and off, and then via a driver of some sort.

[Ian.M]

I think you *could* do the servo control with a single static AVR I/O pin and a 555 and a few discretes: 

I would suggest using a CMOS 555.  The reset circuit is a little complex because its designed not to reset during a pulse so that the servo wont get commanded to an incorrect position at shut-off.  I haven't breadboarded it so it may need you to fiddle with the reset circuit a bit. e.g. if it wont shut-off when you take the I/O pin low, add a 1N4148 between Q1,Q2 emitters, and ground to raise the base threshold voltage of Q2.   

It takes a few extra parts (Q3,D4,R10) to let you drive a P-MOSFET off the same I/O pin.  Again, if it doesn't shut off cleanly return the emitter of Q3 to the same 1N4148 as the other emitters

Its only known flaw is that the first pulse after enabling it will be approx twice the correct width as, coming out of reset, the timing cap has to charge from near zero rather than 1/3 Vcc.  Correcting this would be complex.

However you'd be far better off programming a job lot of ATtinys as slave servo controllers, as you'd only need four components for each slave including the MOSFET.  Yes you could do six in one Arduino Pro Mini - but its probably better to K.I.S.S. and only have to handle one channel + the control interface. 

LTspice simulation attached.

[chefkoch84]

Hi there,

Here is a tip:
I have a project running that just switches off the servo via software ... ( e.g. not sending pwm anymore... my (super cheap) servos stop regulating at that point).

I guess thats not guaranteed to work with every servo in a smooth way -
A fast way to test would be to just hook it to an Arduino and try
Servo.detach() after some time after moving it.


pro: you would not need additional hardware / and IOs for this.
con: could still use more power than shutting off the entire servo - but for your application that could be ok?

Greetings
Max

[macboy]

So I did some experimenting with the software method tonight, and it really seems like this is not practical, at least in my use case. It works - but you need massive delays (few hundred ms) before disconnecting the servo pin, or nothing happens. I found an example in the Arduino forums and they ran a full 1000ms delay. This sort of thing, I think, will be too much when I am doing the RS484 comms as well. I see 3 options:

  1. Do it in hardware - either buy the $4.95 commercial circuit for each servo, or buy one and see if I can reverse engineer it.
  2. Buy a commercial servo controller than can be trigged by an Arduino pin and leave the servo stuff to someone else (would get pricey)
  3. Make my own servo driver controlled by an Arduino pin. In this case, use a second Nano with the servo library in the program, say 8 inputs and 8 servo connections, and then drive that from the first Nano that has the RS485 - simple state change of a pin on the comm Nano, and the one driving the servos can have 1 second delays in the code or whatever works because it pretty much won't matter.

 I did do more hardware mockups of the servo and the linkage it will have, and actually it seems to work pretty well without any annoying buzz - the geometry of the linkage is such that it forms a bit of an over center spring and it takes a LOT of force on the music wire to apply enough force to the servo to make it try to back off, far more than would ever be applied when actually moving points. So I may not even need to kill the signal, just make sure I get the endpoints set correctly. I'm still thinking I would do #3 above, because the servo library uses interrupts and seems to be very timing dependent to generate the proper pulse train to each servo, so offloading that may be the better way to go - at $4 for each Nano, it's hard to say this is an expensive solution.

 One more option comes to mind. Since each servo will mount in the exact same geometry, the end points should be identical for all of them. I could build a pair of pulse generators with good old 555's (or one 556) and use the Arduino output to toggle which pulse train is fed to each servo. The single Nano could do this, again it's just switching outputs on and off, and then via a driver of some sort.

You don't need to insert a 1 second delay in order to do something after 1 second elapses. Try to stop thinking so linearly.

Create a function that performs the task that you want to do after 1 second. Let's call it:

Code: [Select]

void stopServo1()
Now use the SimpleTimer library to call it after a 1 second delay:

Code: [Select]

SimpleTimer mytimer;  // put this near top of file

...
mytimer.setTimeout(1000, stopServo1);
...
When the program reaches the call to setTimeout, it sets up the SimpleTimer library to call the function you specified stepServo1() after 1000 ms. Then the next line of the code is executed right away. After 1000 ms (or so), your stopServo1() function will be called.

[rrinker]

 Already tried it that way. It worked, cutting off the power after 1 second without having a bad form delay(). The problem is a bit more complicated than that, because what happened with the timer calling a servo.detach() function is that SOMETIMES the servo moved and then powered off, sometimes it did not - depends on the point in the timer it was at. Yes, I need to reset the timer when toggling the servo, so the count starts fresh.  That may indeed work as expected.

 Once I figured out that it needed a delay, and a plain delay() was NOT going to get the job done, that is the first thing I thought of, rather than disconnect as part of the toggle function, put in a timer for 1 second and call the detach.  I actually have more difficulty falling back on simple linear programming when its needed, anything outside of micros I've coded int eh past 20 years has been event driven with very little linear processing.

 I'm still leaning towards a separate servo driver. The idea of using an ATTiny85 is a good one - the majority of these nodes with the RS485 port will need no more than 2 servos connected, so building all of them with the support in place for 8 is a waste of parts. At like $1.50 each the Tiny85 is just the ticket. I've even already found some servo libraries so I don;t have to try and come up with that one my own, and each one can drive 2 servos with 2 control inputs. Perfect! For ones that need to drive 4 or 6 servos, I just add a couple extras of the same circuit with the same code running in it. Next step, acquire some 85's and give it a go.