Assume I do a slow servo move from 0 to 100 which takes a few seconds. How does this work "behind the scenes" ? Am I right that the PC will sequentially send each individual position over wifi, and spread their timing to achieve the desired speed, rather than offload the entire instruction sequence to the EZB to be executed locally? If so, is there any feedback from the ezb controller to the PC to acknowledge it received the last command and does the PC wait before sending a new one? Or is the pc just sending each position on the assumption it will be received for as long as the board is connected?
Reason Im asking: Im seeing some occasional violent jerking where the head of my inmoov moves at full speed, despite all my attempts to limit the speed. My theory is that this is due to the EZB being busy or the wifi being unresponsive/briefly encountering a high latency spike for a short while, and the EZB software just keeps sending its sequential positions assuming they are executed, but when they are not for like half a second or so, this results in a full speed movement to "catch up".
If my assumption is correct, is there anything I can do about this? Like offload the entire slow movement sequence to the ezb so it can execute it autonomously without help and without persistently low latency connection to the PC?
Also, still based on the same assumption, stepper motors would be out of the question without a separate microcontroller?
Can you clarify ?
ex:
The code above sets the servo D0 position to 1, then sets the speed to 10 (slowest) and then sends the servo to the extreme position.
EZB firmware handles the movement from position 1 to 180, ARC is not involved.
The code above is handled by ARC and is non deterministic (no real time) depend if ARC is busy processing other scrips, if there are other EZB commands on queue e.g. (ADC/I2C/UART etc).
Sleep(100) can take 150 ms or 200ms or whatever.
Thanks, I meant the first case, the second case is obvious that the code will be run entirely on the PC.
So if what you say is correct, then my assumption above is incorrect. And that would be a good thing, because clearly thats a better way to handle movements. Better yet, it seems to be interruptible, as a new move command cancels the old one, even if it didnt finish yet.
But then I dont understand why my servo seems to jump around at full speed occasionally. It could have been my code, but even when I disable everything and only use the servo pad, this happens. You might think a flaky servo, but it appears to behave normally when I loop forever left/right moves at any speed, slow or fast.
hmmm.. thanks anyway for clearing up the above.
Slightly related question; is there a way to get the current servo position from the firmware? When I do Servo(d0, 180)
then getservo(d0) will return 180 immediately, even if the servo has barely begun moving.
The position of a normal servo is maintained in a closed loop, there is no feedback given to the controller. Only serialized servos can report back position information. In scripting you can place a wait command after the servo movement to wait until the servo has had a chance to perform its function. That’s all i can think of off the top of my head without seeing it.
Except for Dynamixel and similar, Servos have no way of reporting back their current position (and th current Dynamixel plugin does not take advantage of the ability) so all ARC can tell you is the last command it gave, not whether the command was successful.
I know the servo cant report it, but the ezb controller in theory could, when it is controlling the (slow) servo movement. Or at least it could report the last position it instructed the servo to move to
@vertigo This is the only way to get the current servo position instructed by ARC
Try posting your scripts so everyone can see what your putting in , a short video a few seconds long might help