Future Of Servo Speed Control

This will be the future !  Please be part of it .. thumbs up or thumbs down - if thumbs down state why.. WHOOHOO ! - this is what I have so far....

ServoControl comments range default
value		 units
setSpeed(double speed)   0.0 - 1.0 1.0 relative - based on 
1.0 == full speed -  which is in this case "no" speed control
setVelocity(double velocity) gone ! - setSpeed is king - I method to rule them all !      
setAbsoluteSpeed(double speed)

There has to be a "convention" to follow to make absolute & relative speed work - I can't find anywhere on the Servo service page where this is specified.  I think calamity made some calculations - but I can't find them at the moment.  So until it become more clear I found these are the "specs" for HK15298.

0.13/ 60deg @ 6v, 0.11 / 60deg @ 7.4v

Which means what ?  0.13 secs to travel 60 degrees @ 6 volts ?

461.58 degrees/sec

     degrees per second
setLegacySpeedControl(boolean legacy)  to support all gestures currently using old speed control

Although I'm on the edge of setting the default to false, I believe most people who have an InMoov would disagree with that - so I'm willing to default it to true with a grace period of 1 release version, afterwhich it will be defaulted to false and/or removed completely

 true/false true  

History Of Servo Speed Control

     
100000000 BC There was no speed control. Dinosaurs did not have much fun with servos. No wonder they were grumpy.
100000 BC GroG thinks, "Hey, controlling a servo's speed would be fun".   And makes Servo.setSpeed 
Its based on some modulus of an incrementing counter in Arduino's loop.  
The input interfaces is a range between 0.0 to 1.0 because he thinks that is the common output for many analog devices like joysticks.

The implementation is non-linear.
100 BC People start using the strange non-linear setSpeed. They make lots of scripts with this bizarre non-linear, changing scale. 
100 AD Calamity attempts to fix setSpeed.  The best part is he makes it based on "Time" which is pretty constant and universal, not the number of clicks a counter counts (which can vary alot between environments).
1000 AD Fixing the speed control breaks scripts.  There is much confusion and sadness.
2000 AD setSpeed setVelocity setMaxVelocity .. Breaking scripts.. Propegating bad interfaces .. GAH !   What do we do ?
2016 AD Much civil debate and proceedings continue..
Until..
Future .. The best interface and implementation was chosen.
It was simple and robust and the future was bright..

So I think we are in 2016 ..
and still debating .. which is good..

My opinion is there should be 
Servo.setSpeed(Double speed)
where the speed variable is 0.0 - to - 1.0  where 1.0 is full speed and 0.5 is a best attempt linear implementation of 1/2 speed

It "might" be useful to have a variable affect the speed as a constant offset.  Where the situation is you want two inmoovs to move in unison, yet they have different servos with different speed characteristics.

I would prefer to fix scripts so that they are onboard with Calamity's implementation.

If absolutely necessary, Kwatters had an iteresting idea of overloading setSpeed(Double speed, boolean oldStyle)

Where the old scripts could use non-default oldStyle speed control until they were converted.

Yes

I't will set the speed to 6 degrees/second for whatever joint you use it for. It doesn't know about the ratio, so it will actually always move at full speed. The way it's implemented is that it will send new servo positions to the servo at a constant rate and the potentiometer feedback will be handled by the servo. So the measurement is from the potentiometer that inmost cases has been extracted and set in the joint. So it will measure the potentiometer rotation speed. If there is a gear with some other ratio than 1:1 between the potentiometer and the joint the value has to be adjusted.

So moving from 90 to 108 degrees in 3 seconds at 6 degrees per second would:

moveTo(90) 

sleep(1)

moveTo(96)

sleep(1)

moveTo(102)

sleep(1)

moveTo(108) 

Just that the new positions will be sent more often ( like once every 100ms ) and in smaller steps to make the movement smoother.

 

sorry Mats but this creates more confusion at my end.

I had learned to understand that with our class of servos we use we do not know the potentiometer value and would need a double poti and analog reads to get the actual position of the poti. And we also do not have a feedback from the servo to tell us we are at the requested position.

So how can the service do anything based on potentiometer rotation?

 

hi juerg, Mats explain it the right way

 

the servo do not feedback the potentiometer value, but it still use the poti and know it's value

so it alway base it's position on the pot value.

When we extract the pot and put it at a joint, we make it measure the joint angle instead of the horn position. So when we ask him to moveTo(90), it will turn until the pot is in position 90. Independantly of the gear that are in between. 

Because of the gear on the shoulder, the servo may turn like 150° to raise the shoulder by 10°. So it only care about it`s pot position

setSpeed is doing the backward compatibility. It's fine to still use it, but I really think you should get used to use velocity setting in place of setSpeed

setSpeed can easily bring confusion about it's value. It's easy to think that setSpeed(0.5) is 1/2 the maximum speed of a servo, it is not. 

for info, setSpeed(0.5) = setVelocity(11)

setSpeed(0.9) = setVelocity(54)