5
\$\begingroup\$

I have a Pololu Micro Maestro, and it's great. But when i tell the servos to move to specific positions, sometimes it makes a beeping-like noise. This only happens at specific positions. It's not because I'm trying to make it go farther than it can, it also happens when it is positioned around the middle.

This happens when I use a laptop to control the servos via an application written in .NET

I have only tried controlling them either via my own application or the maestro control panel.

Is there any way to avoid this?

I hope you guys understand what I mean. Thanks

\$\endgroup\$
3
  • 2
    \$\begingroup\$ Consider checking the output of the micro maestro and seeing if the pulse width at those positions varies. Also, swap the servos around, and use different models of servos to see if the problem moves with the servo, happens on all the ports, or just a few outputs. Additional testing should tell you if it's a problem with the servo, or the servo driver, or your software. \$\endgroup\$ – Adam Davis Jun 28 '11 at 19:45
  • \$\begingroup\$ How do you actually control the servo? A PWM Signal? How does it get outputted? Are you using a dedicated Hardware? \$\endgroup\$ – Marcel Sep 5 '11 at 21:51
  • \$\begingroup\$ I think the best answer you're going to get here is "It does that because hobby servos are crap". Have you tried different servos? \$\endgroup\$ – Connor Wolf Jun 6 '13 at 20:28
3
\$\begingroup\$

The R/C servo control signal is a pulse train. There are two parameters that describe a pulse train: pulse width (PW) and pulse repetition interval (PRI). PW is what controls the servo position. It is critical, and must be stable. PRI is not nearly so critical, at least with R/C servos: they will generally be happy with a PRI anywhere from 20 to 50 ms, and they don't mind if it varies some. (You will also see PRF, for pulse repetition frequency, usually in radar systems. PRI 20-50 ms corresponds to PRF of 50 down to 20 Hz.)

Any kind of instability in the pulse width (PW) will cause the servo to "buzz", as it chases the control signal. Such instability can be triggered by the HUGE current draw of a servo in motion, if the power supply AT THE CONTROL CIRCUIT has insufficient surge capacity. (A standard servo in controlled motion can easily draw 250 mA. A "buzzing" servo can draw half-amp spikes. Yes, this is from experience.)

Instability in the PRI is generally not a problem for an R/C servo.

The very first thing I'd do is hang about a 250 uF capacitor directly across the servo power leads. The second thing I'd do is scope the control signal, triggering on the rising edge, and looking at the problem ranges to see if the timing on the falling edge is varying AT ALL.

Anyone planning on playing with servos should start by wiring up a 555 and a one-transistor inverter, generating the servo control signal entirely in hardware, and playing with this. Watching a servo sitting there, buzzing, watching your power supply ammeter going all over the place, registering half-amp spikes, is INSTRUCTIVE. Taming that beast is even more so. Note: This circuit will also demonstrate the servo's tolerance of varying PRI: the simplest 555 pulse generator for this purpose will vary PRI as it varies PW.

\$\endgroup\$
2
\$\begingroup\$

Is the laptop doing the closed loop control? If so, it's probably due to trying to do real time control on a operating system that isn't real time. I've measured Windows going out to lunch for a few 100ms at a time just because the mouse was moved. If your control iterations are faster than that, such delay will make things unstable.

If the laptop is only sending high level commands to a dedicated controller that is doing the actual controlling, then it's hard to guess what's going on. How is the position feedback signal produced? If it's from a pot, it could be getting scratchy.

\$\endgroup\$
5
  • \$\begingroup\$ The Pololu Micro Maestro is a servo controller. I'm sorry i didn't mention that, but most likely you would still need to do a simple search since i can't provide all details about the device. I'm guessing that it's the second option you mention about sending commands to a dedicated controller. \$\endgroup\$ – Moulde Jun 27 '11 at 20:14
  • \$\begingroup\$ I doubt that Windows non-real time capability has anything to do with " This only happens at specific positions. " \$\endgroup\$ – kenny Jun 28 '11 at 0:56
  • \$\begingroup\$ @kenny if Windows was having to close the loop it very well could be the source of it even at specific positions. A filter/controller could end up having some odd poles or zeros that appear due to odd windows timing that only effect certain positions. But that doesn't appear to be the issue here. \$\endgroup\$ – Kellenjb Jun 28 '11 at 3:51
  • \$\begingroup\$ @kennny, I guess I missed the specific positions part. If that's really true, then bad feedback, like a scratchy pot if that's what they use, sounds like a more likely culprit. \$\endgroup\$ – Olin Lathrop Jun 28 '11 at 12:25
  • \$\begingroup\$ @kenny, there are two parameters that describe a pulse train: pulse width (PW) and pulse repetition interval (PRI). PW is what controls the servo position. It is critical, and must be stable. PRI is not nearly so critical, at least with R/C servos: they will generally be happy with a PRI anywhere from 20 to 50 ms, and they don't mind if it varies some. (You will also see PRF, for pulse repetition frequency, usually in radar systems. PRI 20-50 ms corresponds to PRF of 50 down to 20 Hz.) \$\endgroup\$ – John R. Strohm Jun 6 '13 at 13:51
2
\$\begingroup\$

Our experience with model remote control servos and Pololu cards is that some servos have positions that are noisy.

Its the servo, not the controller. Swap the servo if you must have better performance.

\$\endgroup\$
3
  • \$\begingroup\$ Yes, that's what @Moulde says. You give no explanation, nor suggestions to avoid it. -1 \$\endgroup\$ – Federico Russo Jun 28 '11 at 19:13
  • \$\begingroup\$ @Federico: added a solution. \$\endgroup\$ – Tim Williscroft Jun 28 '11 at 22:54
  • \$\begingroup\$ I don't understand that, because the servo is a pretty expensive Hitech HS-7950TH!? \$\endgroup\$ – Moulde Jul 5 '11 at 14:27
1
\$\begingroup\$

It's a single PIC doing more PWM channels than it has timers for. How well it manages to do this will depend entirely on what the program in the PIC does. For this design, I'd go with the timer to mete out pulse lengths, interrupts to do the output toggling, and software polling for the USB and serial so it cannot interrupt the timing of the servo outputs. Many other combinations will have interference between the timing of servo channels or external updates. It may well be the specific positions you're seeing coincide with the heartbeats on USB.

\$\endgroup\$
1
\$\begingroup\$

If your servo oscillates with amplitude of one encoder step size then check that feature named like "dead band something" is used correctly. If not enabled, then, your servo always has a chance to hit an uncertain spot near encoder position N and N+1, or N-1. Servo tries to eliminate smallest 1 step error and overshoots one more step, or encoder has sensitivity to magnetic field noises or light and keeps changing its mind between N and N+1.

Uncertain reading is unavoidable in any builds no matter how good and expensive are the parts. To fix it, PID setup must ignore position errors less or equal to 1 encoder step.

\$\endgroup\$
1
\$\begingroup\$

If this is a conventional R/C servo, it uses a potentiometer to sense shaft position and develop the internal error signal that drives the motor. Potentiometers can get dirty. You MIGHT try careful surgery on the servo and spraying the pot down with contact cleaning solution.

Or try another servo.

Depending on the math of your control law in your PC (.NET -> PC controller), you might have a mathematical instability that shows up in the commands to the servo.

\$\endgroup\$
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.