No speed control and ease on ESP32-C3

[santonum]

Hi,
I would like to control a 9G servo with a Lilygo T-Zigbee ESP32-C3 board, on GPIO08.
I use
myServo.writeServo( ciServoPin, gfPos, gfSpeed, gfEase);

Target positionning is OK, but I can't change speed nor ease.
Did you try parameters #3 & #4 of writeServo on ESP32-C3 ?
Thanks

[Dlloydev]

Here's an example using an ESP32-C3 and GPIO8 where you can change the easing.
This example uses millis() for feedback,, but its possible to use the returned normalized position (see examples).

• (ke=0 is linear ke=0.5 is normal curve, ke=0.8 is a steep curve).
• speed units is degrees/second.
• parameters 3 and 4 need to be float type.

[santonum]

OK thanks for the answer.
So in all examples, to get easing, you need to loop and call pwm.servoWrite at each loop with same args, and with a pause of a few milis (6 to 10?) ? Is it to control easing or just to get back the position ye ?
If I write myServo.writeServo( ciServoPin, gfPos, gfSpeed, gfEase); delayu( 2000);, wouldn't it work ?

[Dlloydev]

Yes, you call pwm.servoWrite at each loop iteration with same args (until ye becomes 1.0, which means the servo has reached its new position).

The delay isn't a requirement for real hardware, however using a millis() timer would be a good approach if you would like to set a "sample period" for getting the returned position ye.

The delay in the examples is for improving the the simulator performance. You can run the loop at full speed you'd like or limit the calls as mentioned above.

The maximum speed can be determined from the datasheet, so for this servo it would be 600 degrees per second.

If you set a higher speed, then a call to a new servo position would occur before it finished moving to its previous position setting. Its easy to slow down the servo by setting the speed to a lower value. For example, speed = 300 would slow down this servo by 50%.

The easing parameter (ke) changes the motion where 0 is linear and 0.99 is very steep response when the position reaches near half way. A ke value of 1 turns off the easing and speed control.

If you write myServo.writeServo( ciServoPin, gfPos, gfSpeed, gfEase); delayu( 2000);, , I don't think this would work because the servo would have already completed its movement before your next call to writeServo. The speed is set by the speed parameter ... adding delay won't control the speed. To get a good easing, I would suggest calling writeServo at least 20 times (or more) with the same parameters. Internally, this ramps up (or down) the pwm pulse width determined by the ke setting. Have a look at the effect of changing k (ke) here. The green trace is when setting a lower position value, orange is for setting a higher position value. The straight lines show a linear response when ke = 0.0

[santonum]

"You can run the loop at full speed"
My question was on the over hand, to be sure to understand.
Do I definitely need to call writeServo at each loop ? Or is it enough to call once and it works with interrupts ?
It seems to be necessary at each loop, as often as possible.

I started from your example 👍 It works.
I decreased the speed to 20. OK
Then I increased the delay from 10ms to 200. And now the movement is made of different steps, with the 200ms period, the movement is... "jerky" (correct word?).
So I think that speed and easing are not totally controlled from one unique call of servoWrite, but the intermediate positions are re-calculated at each call.
If it is right, we need to know it to write our program.
(or is it a problem from -C3 ?)

[Dlloydev]

writeServo doesn't work with interrupts yet, but this would be a good feature to add. I tried using ESP32's core0 to call writeServo and it worked OK (example) and was unaffected by a large delay in the main loop. Unfortunately, the C3 is single core. Therefore, using an interrupt or perhaps a callback procedure would resolve the jitter, but I haven't tried these methods yet with any ESP32.

Yes, the intermediate positions are re-calculated at each call, so multiple calls are needed

[santonum]

"Yes, the intermediate positions are re-calculated at each call, so multiple calls are needed"
No real need to implement interrupts, just do explain that calls are needed for intermediate positions, because in the examples, we can thinks that calls are just to read the intermadiate positions, not to calculate them.

[Dlloydev]

Here's a Wokwi example that works quite smoothly.
I've added comments to the sketch.

[santonum]

The servo has reached its programmed position when ye = 1.0 if the new setting is larger than
previous and also when ye = 0.0 if the new position setting is smaller than previous.

OKAYYYY ! I was blocked on the rear way, because I thought that 'ye' was the movement completion ratio, so I was waiting for 1.0 even in reverse movement, so always reached...