Servo Control

Should this work?

You have the hardware. Does it?

I want to let go of the servo to save battery and stop any jitter or anything.

Will the mechanism hold still with the servo turned off?

I mean code wise can you attach and detach whenever/wherever in the code?

Because the servos don't work unless i attach in setup() and leave it attached.

The servos stay put when they are off, so yes.

There is nothing in the library that knows whether attach was called in setup(), in loop(), or in some other function. So, the code you posted should work. If it doesn't the problem seems to be elsewhere in the code.

Servos generally need a continuous stream of pulses to keep them on position - so normally attach() in setup and don't detach().

If you want to power-down the servos you'll need to see if this works (they stay put on power down), and then arrange for the power to be switched somehow (as well as detaching immediately before). But I'm guessing - someone will know more, but they might want to know which servos you're using.

They do stay in position when they are off. So you are saying use transistor to turn them off and on?

This is for a pan/tilt camera on a robot.

The servo are from dfrobot.com

DF05BB is the servo model.

If I don't attach till I need them, it still doesn't work.

They do stay in position when they are off.

In the overall context of servo usage, a servo is designed to be powered continuously and have a continuous ppm control signal applied. If a servo is powered off by removing it's Vcc voltage, or by detaching in software thus removing command pulses, the servo loses all ability to respond to external mechanical forces that may be trying to move it from it's present position. As long as it has power and control signals it can generate maximum torque to overcome mechanical forces that might be trying to move the output wheel. So un-powered or detached it only offers mechanical torque resistance equal to it's internal gear train friction, higher then that and it will move to a un-commanded position.

Easy test, take a unpowered servo and grab and turn it's output wheel, does it turn? Now power the servo up and give it a fixed continuous position command. Now try and turn the output wheel. Different, no?

So in many applications where there is little mechanical force working against the servo then you can unpower when not needing a change of position. I think the average current draw of a servo a rest with no external mechanical forces is around 7ma, but that of course varies on size and design of your specific servo.

That make sense?

Lefty

Yes it does but most of the time my robot will be idle, it won't matter where the camera is pointing when the camera is off. Either way shouldn't the software be able to attach as needed? I saw a example somewhere but doesn't work for me. There isn't much more to the code. I enter a command on the serial and it moves it that position.

I am using Arduino IDE 21.

Either way shouldn't the software be able to attach as needed? I saw a example somewhere but doesn't work for me. There isn't much more to the code.

Of course it would better if you posted your full sketch, my bet is that your is not allowing the servo time to reach it's new position before it performs the detach command. Servos don't move as fast as code does. :slight_smile:

As an experiment, try adding a delay(2000) command just before you detach command and see if that doesn't tell you whats going on.
Lefty

I tired 1000 delay after the attach, I should do that after the command to, didn't try that.

I will try thanks.

Thanks! It was the detach that needed more time, doh! Makes sense. I didn't do it because I had the attach and set to default position in setup and that worked. I didn't think of the delay needs to be after pos is set.

Thanks, we all live and learn.

Hopefully someone else can benefit from this thread.

Now I thinking it might use less power if I actually turn off the power. I will have to do some current testing.

Thanks! It was the detach that needed more time, doh!

Your welcome.

It's really not the detach command that needs the delay, but rather the servoPan.write(pos); command needs delay after starting, to allow the servo to actually reach the new postion commanded.

Lefty

Thanks, that was what I meant, I needed more time before I detached.

I am no expert on servo's, being a relative newbie, however my current project uses a fine little gear reduced motor sold by Pololu. My project is a marine Autopilot, moving the helm wheel by means of a gear reduced motor. The one I am using to test my program is a 131:1 reduction, and has a 64ppr encoder mounted on the motor shaft, with all the leads for the encoder brought out in a color coded bundle. In my testing, using several sketches copied from this forum, you can get the encoder count output, plus direction. With some clever coding, you could have a very precise, controllable axis motor position, and go back to it. The output shaft is 6mm, which is slightly less than 1/4", with a machined flat. They sell motor hubs, that mount to the shaft, as well as the motor mounts. You absolutely cannot turn the motor shaft by hand. Also, using their 18v25cs motor driver H-bridge, you can drive the motor with PWM, vary the speed, and brake to a hard stop, or freewheel stop.

Reading Richard's comments about servo's, and their flaky, jerky movement prompted me to add my two cents. I agree, a pan/tilt camera mechanism needs to be smooth, and solid as a starting point in the design. There will be enough problems solving all the unknowns, without fighting the fundamental mechanics of the system.

John

People really need to do a reality check on servo based cam pan/tilt systems. Nobody can expect to get a $15 hobby servo pan/tilt to compare to a $1.5k servo pan/tilt, or a $150k professional cam conrol system. As to hobby servo based pan/tilt systems, the quality of operation depends a lot on the quality of design and control used in the construction.

http://www.servocity.com/html/pt-2100_pan__tilt_system.html
http://www.servocity.com/html/pan_tilt_roll___accessories.html

MobileWill:
I tired 1000 delay after the attach, I should do that after the command to, didn't try that.

I will try thanks.

You should try to make your code a little smarter about how much delay it needs. All servos have an advertised speeds, typically in seconds per 60º (which has always seemed rather odd to me, but that's the standard). A bit of quick math can give you a value of say, milliseconds per degree.

So say your servo takes 0.17 second to rotate 60 degrees (that's fairly typical for a hobby servo, not too fast, not too slow). That is 170ms to rotate 60º or 170/60 = 2.83ms to rotate 1º. Round that up to 3ms per degree.

As long as you keep track of your current position, and your target position, you can easily calculate how long it will take for your servo to move to the new position.

I'd also recommend handling the pan & tilt together. That way it pans and tilts at the same time, one synchronous, smooth operation, as opposed to first panning, then tilting serially.

which has always seemed rather odd to me, but that's the standard

Given the typical use for a hobby servo, such as steering a car, positioning a rudder, operating as a throttle, etc., 60 degrees is generally the full range that the servo needs to sweep. How much throttle travel do you have, and how much servo movement is required to make the throttle travel that far?

PaulS:

which has always seemed rather odd to me, but that's the standard

Given the typical use for a hobby servo, such as steering a car, positioning a rudder, operating as a throttle, etc., 60 degrees is generally the full range that the servo needs to sweep. How much throttle travel do you have, and how much servo movement is required to make the throttle travel that far?

Well there you go. Makes more sense knowing that. Guess I've never used hobby servos in the manner they were designed for. :slight_smile:

Code wise; yes, it should definitely work. Servo.attach() and Servo.detach()
are often used that way because it leaves more memory, and so that you can work more efficiently with battery power and such. Physically, though, it would need to be placed in such a way that it would not move because of gravity, or the like.