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?
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