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?
Upgrade to ARC Pro
Experience early access to the latest features and updates. You'll have everything that is needed to unleash your robot's potential.
Code:
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.
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
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...
http://www.ez-robot.com/Community/Forum/posts.aspx?threadId=5028
http://www.ez-robot.com/Community/Forum/Thread?threadId=6183&page=2
Alan
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.
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.