Whoops! The title was supposed to be ServoSpeed Questions and Issues Unfortunately you can't change the title so we are stuck with "Questions and Questions", Sorry
@DJ_Sures Lately, I and Mickey666Maus have been working with recording the movements from a virtual robot in 3ds with the purpose of playing them back in ARC. This we can do. The problem comes in the timing. That is to say, the length of time it takes to perform a movement in the 3ds animation vs recreating that same timing in ARC. I can break up a given servo movement command into smaller increments and come up with an approximation of the time needed by fooling with the number of incremental movements and, if needed, add some sleep in between. But that tends to introduce jitter in the actual robot and it defeats the purpose of sending larger servo movement commands to the ARC to achieve smoother movement of the servo. For example:
#Assume we are starting at a servo position of 10 degrees.
Servo(D10,110) #Go to 110 degrees.
#The above command will move the servo smoothly.
#As opposed to:
Servo(D10,10) #Sending out many smaller servo movements.
Servo(D10,12)
Servo(D10,13)
Servo(D10,15)
|
etc.
|
Servo(D10,110)
The smaller increments solve the timing problem, but introduce jitter in the robot.
The obvious answer is to use the ServoSpeed instruction in EZ-Script. The current problem with that is the ServoSpeed has no fine increments between 0 and 1. You essentially go from full speed to less than 1/3 of full speed when going from ServoSpeed(D10,0) to ServoSpeed(D10,1). I did some time trials and found this relationship for the first 6 ServoSpeed numbers:
# To move 179 degrees
# -------------------
#Servo Speed =0 =550ms 1.00x (Base Speed) 3.07 ms/degree 0.326 Degrees/ms
#Servo Speed =1 =1940ms 0.28x (550) 0.28x (Base Speed) 10.84 ms/degree 0.092 Degrees/ms
#Servo Speed =2 =3880ms 0.50x (1940) 0.14x (Base Speed) 21.68 ms/degree 0.046 Degrees/ms
#Servo Speed =3 =5600ms 0.70x (3880) 0.10X (Base Speed) 31.29 ms/degree 0.032 Degrees/ms
#Servo Speed =4 =7400ms 0.76x (5600) 0.07x (Base Speed) 41.34 ms/degree 0.024 Degrees/ms
#Servo Speed =5 =9200ms 0.80x (7400) 0.06x (Base Speed) 51.40 ms/degree 0.019 Degrees/ms
#Servo Speed =6 =11100ms 0.83x (9200) 0.05x (Base Speed) 62.01 ms/degree 0.016 Degrees/ms
As you can see it goes from full speed to 0.28% of full speed at a ServoSpeed of 1. That's a huge difference. The difference is not so much between the rest of the number settings.
All this leads to my question: Would it be feasible to break up the allowed values between 0 and 1 (at least) into finer increments? For example allowing decimal fractional values such as ServoSpeed(D10,1.2). ServoSpeed(D10,1.6) ... etc. ? This, so as to achieve more possible speed values between 0 and 1.
Using decimal fractions would maintain compatibility between the new and the old so no old scripts would be broken by such a modification
Also, a more general question: Is the servo movement operation independent of what is going on in ARC at any given moment. That is to say, is it running on a separate C# thread such that the servo will move at a constant rate regardless of the load on ARC? Within reason, of course.
Thank you.
Quick inline responses:
Can't be done
Yes
No, it runs on the EZB firmware.
Next post more details.
Analog servos, don't have speed control.
When you have an analog servo attached to a micro-controller, the basic operation is to tell the servo to move to a specific position (microseconds).
The speed is implemented on the EZB firmware, something like this (pseudo-code):
each speed (1-10) has different values for speedMs and speedStep.
ARC transmits to the EZB the servo speed (byte): 0 to 10 associated to the digital port.
check my post #4: https://synthiam.com/Community/Questions/9081
@ptp Thank you very much for your reply. So the ServoSpeed thing is actually implemented in firmware on the EZB itself. Most unfortunate. For me that is. That leaves me with only couple of options. One, option being to implement it in a script. A method which will not be very accurate or repeatable. However, if the movements in the 3ds virtual robot can be constrained to a certain set of movement parameters, or made to fit those parameters as close to the desired movement as possible during post possessing, it may still work out. The trick will be coming up with those parameters.
The other option would be to write a C# program, either as a stand alone program or a Plug-in. At least that way I would have access to a real-time clock and interrupts. Choices, choices.
Thanks again!
I have a question for the question. The servo travel is 0 to 180 degrees ( approx. ) ( x resistance for 0 to full travel). If additional gear reduction was added or the potentiometer value was changed in the servo ( doubled ), would the servo have a reduced travel, but finer steps? The position values would then be able to be larger. Would the jitter decrease? I am a mechanical guy just throwing a question in the mix. This may be dumb, but was just a thought.
Ron
@Andy Roid.... No, same travel, same resolution only it will move slower.... As an example... My inMoov's joints go through a gear reduction gearbox or jack screw for mechanical advantage reasons... They can only travel the same distance (unless limited mechanically like inMoov's elbow) with the same 1 -180ish resolution... It's the potentiometer (and servo electronics) that control the resolution...
If you use a stepper motor instead you can get about 1600 micro steps per 180 deg rotation.... Over 8 times the resolution of a hobby servo
As long as we are throwing around questions, I have another, totally unrelated to speed.
It is my understanding that each script, while executing, is running it's own underlying C# thread. Is that correct?
I just thought the jitter would be reduced because the steps on the output would be finer. Thanks Richard
WB, I asked this question a while ago. The answer was yes. Each script runs on it's own thread. I don’t know how many threads are available to ARC to run on. My understanding was that the multi threading was handled by windows.