I think I now understand some of the complexity moz4r was trying to deal with in Servo.

setAutoDisable is a great function, and it has saved many Servo lives from blue smoke and 21 gun funeral salutes

But with autoDisable comes a "new" servo State.  

Requirements :
if a servo has been disabled by setAutoDisable(true) .. it means the servo started an inactivity timer, and it reached the a time limit with no moveTo commands and has de-energized.

This state is very different from the "user manually setting" servo.disable()
This function when called is supposed to de-energize the Servo and KEEP IT THAT WAY until "manually" calling servo.enable()

If the servo was disabled by the autoDisable timer  -  the expectation is that its re-enabled auto-magically when the next moveTo command comes.

Is this correct ?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
hairygael's picture

Hello Grog,That's

Hello Grog,

That's correct.

But sometimes we also want to override setAutoEnable for a gesture period. As i explained to you the other time by message regarding rollNeck when the head is doing tracking.

Moz4r added the override because the function setAutoEnable(False) wouldn't work within a gesture.

If setAutoEnable(False) within a gesture would work properly, it could be used for exemple with the gesture DaVinci. This way the selected servo(omoplate) to be overriden could stay powered when the other servos would be de-energized. In this exemple gesture, we would override omoplate.servo to keep the arms up until the gesture would be timer finished via delay.