Quick inline responses:

Quote:

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.

Can't be done

Quote:

Is the servo movement operation independent of what is going on in ARC at any given moment.

Yes

Quote:

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.

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):

for pos=currentPosition; pos<requestedPosition; pos+=speedStep
begin
  moveServo(pos)
  sleep(speedMs)
end

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.

Ptp is correct - however I would like to reference how the Auto Position control works to aassist in this question. Move every position like you said, but increment larger positions when faster speed is necessary. To smooth out jerkiness, use a servo speed value of 1.

@DJSures We were also figuring that driving the servo movement with ARCs AutoPosition opposed to using EZ-Script might have some effect on getting better results. Would it be possible to make an import function, just like the export function within the AutoPosition of ARC? To generate the code that is needed for import should not be a problem on our side!

Just something that crossed my mind...

There already is an import - you can use an export to save as an .autoposition file and see the format. Then you can generate the xml to have it import.

@DJSures Thanks....I was not aware it is already build in! Sweeeeet!

Let me know if you have any questions regarding the XML .autoposition file. I can help you create an exporter. Or you can simply use the EZ-SDK in your app and populate the AutoPosition Action and Frame classes and export them as XML like so...

*where config == EZ_B.Config.Sub.AutoPositioner

          using (FileStream fs = new FileStream("myfile.autoposition", FileMode.Create, FileAccess.ReadWrite)) {

            System.Xml.Serialization.XmlSerializer xs = new System.Xml.Serialization.XmlSerializer(typeof(EZ_B.Config.Sub.AutoPositioner));

            xs.Serialize(fs, config);
          }

@Dave_Schulpius Thank you for your response. Good to confirm that since it answers a question I had on using a counter as a timer instead of the Sleep instruction.

@DJ_Sures Thank you as well for your posts. The information you provided opens some new and intriguing possibilities. Likewise thanks for your offer to assist on an exporter.

Quote:

Move every position like you said, but increment larger positions when faster speed is necessary. To smooth out jerkiness, use a servo speed value of 1.

Thanks again!

WB, that servo setting info for the auto positioning control helps me also. I sometimes have jitter problems with my B9 robot arms if I try to move them to fast. I've been dealing with servo speed for years now and still struggle at times. Some things just don't come to me easley sometimes.

Servo jitter can mostly be the cause of over powering after market servos (not ezrobot servos). Ezrobot servos are designed for 5-7.4 volt cells. Where aftermarket servos will not generally not support more than 6v. The jitter may be caused by over voltage - which is the most common symptom of aftermarket servos.

If your servos and voltage is within spec, disregard this post - however, keep it in mind for future reference.

Humm, very good to know. Generally I try not to overvolt my servos but I do take them up to max ratings. Thanks!