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
Maybe I misunderstood, but your post 4 says after you give a command to move to position 180, ARC reports it at position 180 even if it is still moving, which is correct because it is the last position command it sent. If you do the step by step movement you described (which I use in some projects for preciseanual control, adding 1 or 2 to the previous position) then it will give a more accurate location, but as you have seen the movement is more jumpy.
Clearly from your posts you have a good idea of how servos work, so DJ's video tutorial is probably a waste of your time, but I think it does cover some info on how ARC specifically interacts with servos, so might be useful. Posting from my phone so I'll let you search for the link :)
Depending on how many you want to precisely monitor and how much you want to spend, there are probably other solutions of mounting sensors that can provide some feedback.
Also, will post here while I am thinking about it, but there is a thread somewhere here where Jeremie provided a script for controlling steppers without a seperate controller board. I think it would have similar issues with potential lag since the software is giving the step commands though. I have a bookmark to the thread somewhere. I'll post after the weekend if you are interested.
Indeed, but when doing slow moves, its apparently the EZB controller sending out each individual intermediate step, and for debugging/troubleshooting it would have been useful if I could query the last position it sent out. Apparently that cant be done, so be it, no big loss for most stuff.
Yes, I would be interested. I havent looked in to stepper motors on the EZB yet, but Im pretty sure that would require support from the controller firmware to handle the stepping on the controller itself. Doing that in ez script and sending each step over wifi is just not going to work as timing is truly critical there, particularly when doing fast microstepping.
Hardware wise, the microcontroller of the EZB should be up to the task, but it may already be doing too much other stuff to maintain proper timings. And of course, there needs to be software support...
Your question is similar to one of my first questions regarding the inner details and almost everyone jumped on me with servo tutorials and lessons.
So I'll assume you are familiar with servos, otherwise you know the rule, check the tutorial :)
Let's start with inner details:
The communication between ARC and EZB is serialized and sync: ARC sends a command and some commands (not all) expect a fixed number of bytes (response), and is serialized (queued) because only one EZB instruction/command is in execution.
An async system allows the remote system to send the result later, releasing the caller. You could do something like monitor ADC port A0 and send me a notification when the value is below < 100.
EZB firmware does not support async results neither notifications.
Whatever logic you do, you will need to pull or push commands, this can become an issue if you have a few scripts pushing and pulling data from EZB. Windows Applications are not RTOS this means when you tell the script to sleep 100 ms the reality is more than 100ms and there is no guarantee the sleep value is constant.
Looking to the scenario below:
Q) IF the servo takes 10 seconds to reach 180 degrees can i read the real servo position value (while moving) e.g. 10, 20,100, 180 ? R) NO If you do GetServo you will get 180, although the servo is not there yet.
This is a EZ-Robot firmware limitation, because there is no instruction to read the EZB servo position from the controller, is nothing related if the servo is smart or not.
And this becomes more annoying when ARC disconnects from EZB. If you run the above code and you disconnect from EZB. The controller (EZB) knows the last position sent to servo D0 is 180.
If you connect ARC to EZ-B and you run GetServo you will get zero.
This is the reason why you need to initialize your servos every-time you connect to EZB.
This is a firmware (software) design decision.
I don't like those limitations, unfortunately there is no way to change so you need to live with them and understanding them forces you to adapt your code to get the best from this controller.
Yes although I just read that you have the 4/1. The 4/2 responds much faster.
Alan
If is possible yes... I don't think is practical to send Digital commands to control the steps, first you need to switch them fast, second you don't have a way to control the timing.
in the context of stepping, the issue isnt so much the cpu speed of the controller, (although that may become a bottleneck especially on arduino class controllers when doing IO in parallel); the killer of doing this in ezscript is the latency and variability of the response time of the entire software stack and especially the wifi part. You are talking milliseconds here, possibly dozens of milliseconds . Which doesnt sound like a lot, but its an eternity when doing (micro)steps, where you may need microsecond level intervals to get decent speeds and smooth motion.
@ptp
Thanks for the detailed explanation. You read my post well, and I agree with you. I foresee that at some point I will need to start using separate, dedicated microcontroller(s) to handle servos (things like acceleration and deceleration) and/or stepper movement. Thats not a terrible compromise IMO, a single microcontroller doing video, audio, wifi and high speed servo/stepper control is a tall order anyway.
Vertigo, to be on the same field as the other forum contributors, consider upgrading the communication board to a EZ-B v4/2 Comm Upgrade. There are significant upgrades in that latest comm module, which we released in 2015.
As for the sudden jerkiness of the servos, that may be due to the servo brand and manufacturer. The incentive of ezrobot spending half a million usd on developing our own pwm style servos was because the terrible experience people received with other brands.
Regarding feedback servos, such as Dynamixel from Robotis, we’re one step away from bidirectional reading of positions - as demonstrated in the last ARC update.
Lastly, regarding the communication between ARC and ezb, it is 3,333,333 bytes per second. With the ezb binary protocol, that’s a huge number of commands which can handle more than enough for streaming audio and moving servos at the same time. The camera video stream is on a different port of 3,333,333 bytes per second as well, which is unaffected by the i/o communication.
Take a look at the Benchmark control for testing. You will find the 2013 version of the ezb comm that you have is underwhelming in your projects required performance vs the 2015 comm that I mentioned earlier in this post.
Ok, I just did.. LOL, nice one :)
But slightly missing the point when it comes to steppers. "infinite" digital writes per second are not much help when then it takes around a million clock cycles and sometimes several million clock cycles between issuing a command from EZB and the controller receiving it, and that is what wifi inevitably causes even if the rest of the software stack achieved zero latency. Maybe the v2 board is better latency wise, but you are not going to get under 1ms consistently (if at all), which is still too much for some stepper applications. So for (micro)stepping, you need at the very least software support for buffering and timing or interrupts on the microcontroller, you cant do that with EZB scripting on the pc side alone.
Anyway, this thread can be marked "solved", but if there is a button to do that, I cant find it :)
My response isn’t regarding steppers. I didn’t mention steppers because you’re already on the right track by offloading the work to a more appropriate micro that accepts instructions from the ezb - via uart is a good idea.
Ezb wasn’t designed to be a PID
On threads that are marked "need assistance" when created, you can mark them solved and credit who solved it. That person currently gets $10 in EZ-Robot store credit, which is nice, but for obvious reasons DJ removes the Needs Assistance flag for some threads that don't fit the criteria or are incredibly simple to answer. You certainly don't need to flag the threads to get a lot of responses and discussion.
Alan
Why not though? If the hardware is up to it, and I think it is, and you can afford an extra interrupt, then a minimum working solution could be the firmware accepting a command like "send x pulses with y duration at a Z microsecond interval ". Ok, and probably two extra parameters to ramp up/ down the interval to achieve simple linear acceleration/deceleration control as most steppers cant be run at speed instantly. If we have that, then latency is no longer a concern, and for most stepper applications the rest could be done in ezscript or using plugins.
Similar code might also be useful for servo control in some situations and probably for other stuff...
Here are a couple of threads about stepper control. First is the one I was thinking of, 2nd has some additional ideas. https://synthiam.com/Community/Questions/5028
https://synthiam.com/Community/Questions/6183&page=2
Alan
Not designed for that. No need to burden an expensive ezb to repeatative boring tasks that a $2 Arduino can do
Thanks, but that thread just kind of proves the point that you cant properly use stepper motors without ezb firmware support, unless you want choppy movement and/or single digit rpm speeds, and you can wonder why you would use steppers then in the first place. And I bet even that setup would fail if any significant load was put on that stepper because it lacks any speed ramping.
To give you an idea, here is a project I did last year with a tiny (micro) stepper motor :
To achieve that level of acceleration and smoothness, I had to use 12x microsteps per step, times 315 steps per turn for the motor which means almost 4000 microsteps per turn. At, say, just 60 RPM that means ~4000 steps per second or 0.25ms between steps. Of course, many stepper motor application will not need to be so fine, but they will often need to achieve much more than 1 turn per second so the timing issue is similar and you can imagine that becomes problematic when network latency is 10 to 100x higher than the step time, and if you dont have control over interrupts ensuring the steps are delivered at exactly the right time.
That’s a perfect usecase for a $2 Arduino. Love it! Have it receive commands to move via uart from the ezb
Arduino stepper sub controller :)
I actually could not do that with an arduino, not in combination with an eink display at least. The display driver couldnt be run asynchronous or be interrupted, and each refresh took long enough that I would lose steps. So I had to use multithreading on a dual core esp32 for that... yes, 2 arduinos would have worked too, and I even did that initially but thats rather a pita to manage.
Similarly adding arduinos to a ezb project may be cheap, it also means more cable clutter, two different code bases, two different languages, two different IDEs, USB connections every time you need to modify the code... if all you want to do is control a single stepper, that all seems unnecessarily complicated and puts stepper motors out of reach of many/most? ezb users.
Of course, thats your call, but given the abundance of cheap stepper motors and the cool things you can do with them, Id call that a missed opportunity.