1. Home
  2. General Robotics Forum
  3. r/c servo internal pulses

r/c servo internal pulses

> I'll tested std servos with update periods of 15 and 10 msec, and they

> > ran fine, and "seemed" to have a lot more torque, but I didn't try it > > long enuf to notice heating. > > Try 4 msec periods. That equates to 250 Hz. Some digital servos run at > 300+ Hz. > > If you don't mind the hack, you can always cut away some of the

plastic

housing of the servo and stick a small heat sink onto the side of the > motor. > > > Alternately, I've used 40-50 msec update > > periods, and the servos went really wimpy. I'm not 100% certain whether > > the different effects are due to more/less torque per se, or just to > > different responsiveness in the internal feedback loops. > > It has to do with the period of time power is applied to the motor. In > an RC servo the motor inside is powered only when the servo receives a > pulse. Between pulses it receives no power. This is why if you remove > pulses from a servo (we're talking analog here, not digital) they simply > stop. > > Given a maximum 2 msec pulse every 20 msec means the motor is really > only receiving current 1/10th of the time. Going with a higher frame > rate may affect the PI loop in the servo, but different brands may > behave uniquely. I only tried it with some GWS servos, and there was > some overshoot (expected) in moving from one location to another. Given > a more intelligent controller, you could build acceleration ramps to > tackle most of this. This is what goes on inside a digital servo. > > When the torque isn't needed by the motor you could revert to a 50 Hz > frame. That would conceivably prolong motor life, and for sure extend > battery life. Digital servos consume a lot of amps. > > -- Gordon

Ok, Gordon, I pulled apart a servo and did some measurements. One of your favorites, GWS [S03TXF]. Found some interesting things.

  1. The internal electronics holds about 2v "dc" on both sides of the motor winding continuously, with external pulses on or off. At first, I thought this was like active braking, but it doesn't really have any effect, since the motor is stopped anyways.
  2. I dislodged the motor, so it would run open-loop. In this case, you do see pulses applied to the motor, but only when the pot is near the equilibrium point - ie, balancing the applied pulsewidth from the servo controller. For large offsets of the pot [akin to a modified servo running fast], the pulses go away and you see essentially constant dc voltage, with the average level proportional to the speed the motor is running. Acts like a normal dc speed control. There is some ripple on the dc.
  3. There is quite a bit of drift on the pot/electronics. If I set the pot to stop the motor, after a minute or so, the motor starts moving again slowly.
  4. With the motor pushed back in and operating closed-loop, there are no pulses across the motor, when the servo horn is at its holding-position. However, when the servo horn is torqued away from its holding-position a bit, you see fixed-voltage pulses about full +/-2v, and "constant" length = 2-msec long, regardless of update rate from the controller, or whtether it's sending 1, 1.5, or 2-msec pulses. The polarity of the pulse across the motor depends upon which way you push the servo horn.
  5. If you now push on the servo horn, the servo fights back by increasing the motor-pulses from 2-msec to as long as 10-msec, for really hard torques on the servo horn. This seems to be how it increases holding torque.
  6. I tried changing the update from the servo controller from 50-msec [20 hz] to 4-msec [250 hz]. Below about 4-msec or so, the internal loop can't stay up with the external pulses, and the control loop crashes. Also, if you push on the servo horn until the motor-pulse is longer than the time between incoming pulses from the external controller, the internal control loop turns bistable, and locks-up on the long pulses - and the servo horn loses its holding capability. This happens with the incoming updates at 7-msec [140 hz] or so, if you push hard enuf on the servo horn. This is obviously the limit for these servos. Beyond some point the internal electronics just can't stay up with the external pulses coming in, and the loop locks up. What fun.
  7. Unfortunately, it seems to cannot get more torque out of modified servos by increasing the update rate, since when they're open-loop, they're not being pulsed, but rather controlled with dc voltage. [#2, above].

Anything else I should try?

- dan michaels

formatting link
======================

Reply to
dan
Loading thread data ...

This is great sleuthing, Dan! Thanks for taking the time to do this, and especially for sharing your findings.

-Brian

Reply to
Brian Dean

Seems I also managed to overcook the servo in the process :). Now that it's back together, it's acting kinda funny. Groaning and having trouble finding its stable point.

Reply to
dan

Actually I used an S06. The S03 is a little different internally, and is designed to be a drop-in replacement for the Futaba S-148. In fact, mechanically it is nearly identical to the S-148.

Since the motor is not grounded, I assume 2v would be a floated ground, with reference to the servo ground. If both terminals are at 2 vdc, then to the motor that's the same as 0 vdc difference.

Prolly too short of pulses to do anything, right? What were their length over period?

I think you'll find the drift reduces over time as long as the servo is continuously running. The drift is most likely temperature-based.

Given this, this particular servo may not be able to be updated faster than 100 Hz (with safety margin). That's still double the normal frame rate, though. Any difference in apparent torque at 50 Hz verus 100 Hz?

I think this follows. The error signal never changes in an open-loop servo, though maybe you could do some on-the-fly pulse width hacks in the controller to simulate it. In any case, the torque increase is really more desirable for the walkers we've been talking about, which would use unmodified servos. Two 50-60 oz-in motors running a small wheeled robot is usually more than enough.

-- Gordon

Reply to
Gordon McComb

ground,

Exactly. I measured votage separately on both sides of the motor w.r.t. the black wire servo lead to get the resting 2v levels for item #1, and measured differentially to get the actual motor signals in the other items.

I am kind of surprised that they don't hold the levels at gnd, since it seems you have to have the h-bridges 1/2 turned on to hold steady 2v dc level. Why not just apply full 5v pulses each direction ????? =============

In the open-loop case, the pulses seen when the motor was almost stopped were the same as listed below, ie, standard 2-msec long. However, as the servo horn [ie, pot] was rotated and the motor started running faster, the pulses quickly got longer and then disappeared so just a montonically-increasing average d.c. level was seen across the motor. ================

faster

Not sure. I'd need some calibrated weights to figure this. However, as indicated, when you go to 100-hz from 50-hz, you get 2X as many pulses [of the same 2-msec length] across the motor windings, so they're being powered 2X as long, which should translate into about 2X more torque. Ie, looks like

50-hz (18-msec/off, 2-msec/on in 20-msec) ___________|-|___________|-|____

100-hz (8-msec/off, 2-msec/on, times 2/reps in 20-msec) ____|-|____|-|____|-|____|-|____

=================

modified

In the open-loop case, which reverts to controlling the motors with a d.c. level, it seems you do lose some of the low-speed torque advantages of the usual PWM-controlled h-bridge. For continuous rotation, it might work a little better to gut the electronics and use a regular h-bridge.

- dan michaels =====================

Reply to
dan

Exactly as predicted. So the thing to do is find some servos that allow for higher frame rates before locking up. My gut feeling is that, at least for the newer versions, servos from Hitec and Futaba will yield a little better result. They've been at the business for longer.

I think it's logical to assume that anything below 4ms frame will cause unpredictable behavior, because the pulses come faster than the longest pulse duration (figure about 2.5ms, with some margin for comfort). Shooting for a frame rate of between 100 to 150 Hz sounds like a good compromise.

-- Gordon

Reply to
Gordon McComb

longest

than 100-hz updates max, as I was able to get it to lock-up when pulses were coming every 7-msec [140-hz rate]. It's conceivable that, if you get too close to the freq where lock-up can occur, then a strong impact on the servo horn might push it over the edge.

And I'll probably not try this experiment with any of my other servos, as the GWS is acting a little flukey now. I think doing the lock-ups probably about cooked the h-bridge chip in the servo. To reiterate what happened during lock-up, pushing the servo horn hard enuf increased the length of the pulse across the motor to longer than the time between incoming pulses ....

|-|______|-|______ external signal pulses (140-hz rate) __|----------|_____ motor signal (long 5v pulse)

This caused the servo horn to lose its push and go kinda limp, so I assume the h-bridge was being triggered into some manner of shoot-through state, with all 4 switches turned on in some abnormal timing fashion. Which probably overheated it. Also, the servo wouldn't come out of lock-up until I shutdown the signal pulses from the external controller.

- dan =============

Reply to
dan

I did some rough and ready tests on a servo a few weeks ago and was quite surprised by the results. I too experienced odd behaviour with a command frequency of 100Hz. I did some comparative torque measurements and the results can be found here:

formatting link
And by no means are they scientific or absolute.

Paul Crouch

formatting link

Reply to
Paul

I can send you some other samples of servos if you're interested. You may have crunched up the pot in the GWS with all the torquing. (On these when the H-bridge goes, it just goes. The servo will then only go in one direction -- maybe -- and usually runs slow. You can test this by removing the output gear and running the servo in free mode. If the servo acts erratically as you turn the pot, the pot is bad.)

Also, what is the age of the GWS S03 you used? Does it have a "CE" insignia of any type on the bottom? Is the pot shaft brass or plastic?

-- Gordon

Reply to
Gordon McComb

Actually, if you have a couple of more servos of different types, like Hitec/Futaba/etc, that are a little oldish and you might not mind being wrecked by the super-thumb pushing on the servo horn, I'd be interested in jiggering them too - just to compare how different servos might work. Now, that I've got all the protocols down :). Be interesting to know if they all use similar control pulse schemes on the motors.

The way the jiggered-GWS is running now is basically that it grinds a little [possibly I warped some of the gear teeth], but more that when it goes to its set position, it moves over fast, but then does a little dance at the end before settling down. Might be pot or control-loop problem. It still goes both directions and the speed seems normal. ===============

plastic?

Well, it does have a CE on the bottom [whatever that means] and pot shaft is plastic, but I'm sorry to say that the particular servo I used had just arrived in the mail the day before I jiggered it :-(, so it's prolly fairly new-age. Should have used one of my 3-YO already flakey servos, but I didn't realize what I was doing to the poor GWS until it was already done, so !!! Who knew that pushing on the horn when running

140-hz updates would lock-up the control loop?

- dan ===============

Reply to
dan

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.