How exactly do (hobby) servo motors work?

     That's how they worked maybe 25 years ago, but today, they're
much more elaborate.  Many have a microprocessor inside.


     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

Ah - I guess they're a bit smarter than I thought. Any idea what kind
of control loop they're running?


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.


Looks like an interesting part - but it really is too big for what I'm
trying to do, unfortunately.


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

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

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.


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

     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

Don't see how this is relevent for "a very basic force feedback system."
Do you?

-- Gordon

    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

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

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

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:

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

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:

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

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:

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

<..>

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

[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

    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.


    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

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.)


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