How exactly do (hobby) servo motors work?

Hi - can anybody explain how hobby servo motors work? I'm guessing it's something like this: during the high phase of the PWM pulse some sort of capacitor or something is charged, and then the voltage across that cap is compared to the voltage across the center terminal of the pot. Then the control circuitry sends out a current proportional to the difference between those two voltages until the next PWM pulse is received.
Or something like that.
Anybody know?
The reason I ask is simple: I am trying to measure the current going through my servo motors (Hitec HS-81MGs) as a very basic force feedback system. What I'm not sure about is when I should be measuring current across them. Right now I just have an RC filter across them that is averaging the signal somewhat - but it is not a perfect solution. Any suggestions as to when I should measure current to get the optimal force feedback, with respect to either the start or the end of the PWM pulse?
Thanks!
-Mike

Mike wrote:
  Quoted Text Here  
That's how they worked maybe 25 years ago, but today, they're much more elaborate. Many have a microprocessor inside.
  Quoted Text Here  
That servo has a motor PWM frequency of 1830 Hz. That's the rate you'll see if you connect an oscilloscope to the motor. It's completely independent of the control pulse timing.
If you want feedback, the Hitec HSR-8498HB servo has it, but it's more expensive and the protocol for getting feedback while the servo is working is undocumented. The "HiTEC Multi-protocol Interface" is only documented for the dumb bidirectional pulse width interface, but there may be a real digital protocol for talking to the thing, since Hitec claims force feedback capability. Nobody ssems to have figured out how to do it, though.
Then there's the AX-12 servo:
http://robosavvy.com/RoboSavvyPages/Support/Bioloid/AX-12 (english).pdf
This finally gets it right - all the servos are on a single 1mb/s digital data bus and you can get back info on current, position, velocity, and temperature. About US$70 each.
                John Nagle

  Quoted Text Here  
Ah - I guess they're a bit smarter than I thought. Any idea what kind of control loop they're running?
  Quoted Text Here  
How do you know this? Is there a chart somewhere, or are you just familiar with that specific part? Also, this seems wayyy faster than I had expected - I mean there's a very audible noise coming from the servo motors when torqued (and sometimes even visible vibration), so there must be something else going on there as well.
  Quoted Text Here  
Looks like an interesting part - but it really is too big for what I'm trying to do, unfortunately.
  Quoted Text Here  
Again - a very interesting part, but just too big for my needs.
So have you ever looked at the current going into a servo motor to see if there is any sort of signals in it at around 50Hz? Or is it all much higher frequency stuff?
Thanks!
-Mike

  Quoted Text Here  
You're shopping in the wrong places. :) CrustCrawler has them for $45, and I'm pretty sure I saw them for the same price someplace else, though I can't find that now. <http://www.crustcrawler.com/products/AX12/index.php?prodc
But I agree, this is one of the first servos I've seen that isn't as dumb as a rock, and at a really good price for the torque, too. Add in the smart feature set and it's pretty much a shoo-in except in cases where unavoidable constraints force the use of some other brand.
Best, - Joe

Mike wrote:
  Quoted Text Here  
There is a small squirrel in the motor that lives in a cylindrical cage. Changing the width of the pulses causes a cluster of nuts suspended above the cage to shift left or right. The squirrel naturally chases the nuts, and thus the motor changes direction as the nuts move. This is something of a highly scientific overview, but basically this is how it works.
  Quoted Text Here  
Seriously, I don't think it really matters how the servo works internally for you to measure current demand as a way of detecting force feedback. There are a couple of commercial systems that use this for better-than-crude measurement. One is the quite inexpensive servo controller from NetMedia. Maybe get one and see how it works. While the digital servos discussed by others in this thread offer more accurate results, unless you need the other features a digital servos provide you're just wasting your money. If nothing else you could crack the case of a standard $12 servo and tap off the motor leads inside.
FWIW, the typical analog servo has never had the "sample-and-hold" feature you describe. That's a function of digital servos, but in most analog servos current is not held between pulses. After the pulse is received, it powers the motor for a short interval, and if no other pulse is received, the motor stops.
-- Gordon

Gordon McComb wrote:
  Quoted Text Here  
The trouble with measuring current externally to the servo is that you don't get the sign of the error. You can tell how much current the servo is drawing, but not which way it's trying to drive the motor.
                    John Nagle

John Nagle wrote:
  Quoted Text Here  
Don't see how this is relevent for "a very basic force feedback system." Do you?
-- Gordon

Gordon McComb wrote:
  Quoted Text Here  
If you're trying to achieve a specific force, you need to know which direction of motion increases the force and which decreases it, so you can servo on force. For a gripper, it's usually fairly obvious, but for a leg against an obstacle, it's not.
                John Nagle                 Animats

John Nagle wrote:
  Quoted Text Here  
Again I think this is irrelevent for a "very basic force feedback system." Besides, if you are able to move the armature in either direction you can empirically determine which direction is meeting the resistance. Who says you have to keep blindlly applying the same pulses to the servo? You can change them 50 times a second, and some clever programming coupled with simple current measurement can readily determine direction of force.
-- Gordon

Gordon McComb wrote:
  Quoted Text Here  
All:
My experience with measuring the current draw from hobby servos is that that the current draw is very non-linear. When a servo is not able to get to the desired location (e.g. hitting a mechanical stop) it will draw a lot of curren as the servo motor stalls trying to to get to the desired location. Otherwise, the current is quite small and hardly noticable. Measuring the current draw of a hobby servo is not going to yield a very satisfactory force feedback result.
My $.02,
-Wayne

Wayne C. Gramlich wrote:
  Quoted Text Here  
Opposite experience. I've had very good successful on several projects measuring the current of low-end hobby servos (HS-311s, etc.) to get a gross idea of force. Enough that I know when the pads of a walking robot are touching the ground and the legs are lifting the weight of the robot. Obviously you're not going to get much current if the servo is at 62 degrees and you want to move to 64 degrees, but for 10 bucks what do you expect?
-- Gordon

Gordon McComb wrote:
  Quoted Text Here  
Gordon:
I guess we don't agree on the definition of "force feedback". For me, it means you are actually measuring the force. My experience is that I can get one bit of feedback from a cheap hobby servo (low current = at position and not moving, high current = off position and exerting substantial force.) I've never been able to get anything in between. Have you been able to get more than 1 bit? If so, can you share the schematic?
-Wayne

Wayne C. Gramlich wrote:
  Quoted Text Here  
See my earlier post re: NetMedia's servo board. It has a current sense on it that provides a fairly decent (didn't say always accurate) loading reading. Try here for details:
http://www.web-hobbies.com /
I used several of these boards for a couple of consulting-type projects and got fairly good results for my applications. Terrific for forty bucks, plus the cost of ordinary servos.
By definition, a servo holding position with zero or low load will not exhibit much current at all. You'd expect that. It'll only display current when moving or trying to move against some load or resistance, and when the output is at about 5-10 percent (give or take) away from the intended position. So the thing to do is try to move it, maybe in incremental steps. The servo will naturally decrease its current the closer it gets to its intended position, and this variance depends on the servo.
I'm not sure why you get only 1-bit resolution, and all I can suggest is to try different servos. My favorites for playing are ones like the Hitec HS-422, a good middle of the road model. Just to make sure I wasn't dreaming about all this, I just took my test 422, connected an amp meter inline of the red power lead, and plugged the servo into my Hitech HFP-10 programmer. (The programmer is simply a handy means of generating 900-1110 us pulses to any servo, including analog ones. You can use your favorite microcontroller, servo tester, or whatever.)
I dialed the programmer to 1500 us, locked down the servo shaft, then started to turn the dial. The current increase was so linear you could set you watch by it.
-- Gordon

Gordon McComb wrote:
  Quoted Text Here  
Gordon:
I'm not much into servos, so I don't have a lot of them lying around. I definitely got the 1-bit behavior out of my Futaba S3003's. My experience with force feedback was sufficiently negative, that I stopped putting current sense resistors into my servo controllers. For example, my old servo controller has them:
<http://gramlich.net/projects/robobricks/servo4/rev_k/servo4.png
and my newer one does not:
<http://gramlich.net/projects/rb2/servo4/rev_b/servo4.png
Given your experience, I will be rethinking that decision. I'll probably want to build a test rig and actually measure force vs. current for a number of differnt servos before I do so, however. Yet another thing to put on my "to do" list.
Later,
-Wayne

  Quoted Text Here  
Hi Wayne - I just had a quick gander at your schematic - and I saw something that I find very interesting. You're using a CAN transceiver, but that PIC doesn't have CAN. Are you bit banging CAN? If not, what exactly are you doing?
Thanks,
-Mike

Mike wrote:
  Quoted Text Here  
Mike:
For RoboBricks2 modules, we are running asynchronous serial protocol (1 start bit, 9-data bits, and 1 stop bit) at 500kbps using the CAN bus physical layer. We are *not* running any of the normal CAN bus protocol stack, just 1's and 0's on the bus. The purpose for doing this is because we want the high noise immunity provided by differential signalling with the simplicity of using the common UART's in embedded system microcontrollers.
The choice of CAN bus physical layer vs. RS-485 or RS-422 is because CAN bus is multi-drop (like RS-485) *and* we do not have to fiddle with a transceiver direction line. All RS-485 transceivers have a direction control line and it is kind of a pain in the rear to get the microcontroller to deassert that line after it is done transmitting. (For the PIC, you have to go into a tight loop checking the transmit buffer empty flag.) Other that that important little detail, CAN and RS-485 are pretty interchangeable.
For more information about RoboBricks2, the project home page is:
<http://gramlich.net/projects/rb2/index.html
If you want to talk further about RoboBricks2, it would probably better to start a new thread as opposed to hijacking this thread. I will be delighted to answer any questions you have about my pet project. ;-)
-Wayne

  Quoted Text Here  
<..>
This is a great lead-in to the question I was planning on posing anyway. My inquiry is:
Assuming I get the contract I'm hoping for, in about a month I'll be designing a robotic device with several on-board processors, which will be connected by a network of some sort. I'm wondering if anyone has any suggestions for the network, before I roll-my-own YANP (yet another network protocol). Significant design criteria are:
- Multi-master protocol: I'd prefer not to use collision detect, although with a CAN-like priority scheme this might be OK. Alternatively, some sort of token-passing scheme might work. One of the processors will be acting as a watchdog to kick-start things if the packet gets lost. However, I'd like the ability to dynamically add/remove nodes while causing only a transient disturbance to the network.
- Relatively low data rates: 9600 baud *might* be barely enough, although I'd feel much more comfortable at about 10 times that rate. There may be video, but if so the image processing will occur at the camera processor, so only object information needs to go over the network.
- A variety of processors on the net, ranging from embedded-PC power all the way down to 8051-class devices. In general, code space probably won't be too much of a problem, but available RAM probably will be. For ease of writing/debugging, I'd prefer a fairly simple protocol.
- The physical layer will be a CAN bus, probably using the same MCP2551 transceivers that Wayne selected. This limits my minimum data rate to 16.5 kbps before the transceiver decides the node is sick and turns itself off. If possible, I'd like to use something based on 8-bit bytes, so that I can use the built in UART in the 8051s.
So, any ideas? I need open-source of some sort, since I'll be porting it to a variety of processors. Just a description of the protocol itself is enough, since I can code it myself (see "ease of wiring/debugging", above!).
Thanks! -- Mark Moulding

LocalHost wrote:
  Quoted Text Here  
[snippage]
Mark:
Could you repost this query as a top level thread? The reason for starting a new thread is so that people who have already ceased reading the "How exactly do (hobby) servos work" thread can decided whether or not they want to read a thread entitled "Network Suggestions". I am very aware that for the small number of people that actually post in this newsgroup there are probably hundreds of people who just read them to glean useful information.
I will post my lengthy opinion on robotic network issues in the new top level thread. It may take while since I'll be down in LA (Irvine actually) tomorrow morning/afternoon and first HBRC meeting of 2007 occurs that evening.
Thanks,
-Wayne

Wayne C. Gramlich wrote:
  Quoted Text Here  
Yes, the current vs. position error behavior will be drastically different for different servos. Ones with a big dead band will tend to exhibit "1 bit behavior". Ones with gear trains that don't back-drive well will probably not exhibit good force feedback behavior.
  Quoted Text Here  
That tells you there's good mechanical backdrive ability, a linear P term, and no I term.
There are interesting things to do if you can get enough info to do force feedback reasonably well. You can make a servomotor help you as you manually move it. You can simulate springs. You can do compliance in software. You can tell if you have foot/ground contact, and how solid it is. You can implement control schemes which are based primarily on force and velocity rather than position.
                John Nagle

John Nagle wrote:
  Quoted Text Here  
The low-end Hitec 311's, 422, etc. all have about an 5-8us deadband, which is pretty common among analog servos. Any larger than that and the servo is not too useful. I've never seen a standard servo with more than a 10us or so deadband. (Retract servos may have a deadband >20us, but these are not suitable for the task anyway as they are not proportional.)
  Quoted Text Here  
Never encountered a standard servo that could not be back-driven, even the 400 oz-in large scale servos I use for some projects.
-- Gordon