think of this as something akin to an e-stop.
i have run into a situation, with the crunchlabs iturret. at power on, the turret attempts to pitch home. unfortunately, the force of that move can cause the turret to "spike" the magazine (because we don't know the power-on position of the servo, and we can't read it, either).
there are two ways to solve that problem (using this library):
implement #71
add servo.stop(). this command would act like an e-stop, cutting the signal to the servo, regardless of the .write() it is currently executing.
i suppose my code for homing the servo would then look something like this:
for ( int i = 0 , i < 5 , i++ ) {
servo.write (90);
delay (5);
servo.stop();
delay (10);
}
servo.write(90); // just to ensure that we finally make it to 90, if the previous five moves didn't do it
in this way, the move to 90 would be broken into five moves (depending on the starting position), reducing the change in angular momentum, and still not requiring us to know the position of the servo.
think of this as something akin to an e-stop. i have run into a situation, with the crunchlabs iturret. at power on, the turret attempts to pitch home. unfortunately, the force of that move can cause the turret to "spike" the magazine (because we don't know the power-on position of the servo, and we can't read it, either). there are two ways to solve that problem (using this library):
servo.stop(). this command would act like an e-stop, cutting the signal to the servo, regardless of the.write()it is currently executing. i suppose my code for homing the servo would then look something like this:in this way, the move to 90 would be broken into five moves (depending on the starting position), reducing the change in angular momentum, and still not requiring us to know the position of the servo.