David Minkler wrote:
> Olin Lathrop wrote:
>> David P Harris wrote:
>>
>>> I hadn't realized this is how they worked... very elegant.  So, if I
>>> want to get to another position quickly, I could exaggerate the position
>>> to maximize the error to increase the movement per pulse, and then sent
>>> the correct position to zero in on it.  This would have to take into
>>> account the characteristics of the servo, but could give better
>>> performance.
>>
>> Probably worse performance.  The servo control mechanism is presumably
>> already optimized for the servo characteristics.  Unless it's a poor
>> implementation, the best thing is to tell it directly where you want the
>> motor to be, and let it decide how to get it there. 
> 
> Without independent feedback of position information, you would almost 
> certainly get worse performance.  I think the key here is 'could'.  You 
> could also increase the frame rate or the supply voltage (within limits 
> in both cases) and achieve improved performance.  Too much of a good 
> thing isn't a good thing.
> 
> Dave

Given that my application required all the performance
we could get from a cheap servo (least latency),
I ended up running it at 300 hz, which was near the upper
bound for the electronics seeing the pulses.

Fortunately the duty cycle (changes) was fairly low so the servo
stayed cool. And we also tried raising the supply voltage,
and it helped, but not enough to warrant the extra
regulator (frame rate made a bigger difference).

Robert


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist