Servo pulse width to angle scaling

Lynxmotion Electronics & Software
1

In going over the BASIC Atom 'Bot code, and the SSC-32 manual, I came across this statement:

The positioning resolution is 0.09°/unit (180°/2000). From here on, the term
pulse width and position are the same.

And found these statements in the illustrations for normal and extended ranges:

1.5mS = 0° centered
0.9mS = -45°
0.5mS = -90°
2.1mS = +45°
2.5mS = +90°

If the resolution is 0.09°/unit, then shouldn’t -45° be 1.0mS, and +45° be 2.0uS?

Not a big point, but What I’d like to understand is why the angle (BASIC scaled) is not simply offset and multiplied by 0.09 (using an equivalent integer scaling) to arrive at the desired angle of the joint?

I understand the need to limit the “excursion” of the servo’s travel to what it and the attached hardware are capable of, but I’d expect the “scale” to be preserved.

I realize that the BASIC Atom program is NOT using floating point math. However the Pulse Min/Max constants could be calculated from the Angle min/max values to give accurately scaled pulse values. Or is this not necessary for some reason? Or maybe the above +45° and -45° position errors come into play somehow?

Of course this all assumes that the servo’s response to pulsewidth is linear. And obviously the servo’s overall accuracy is not that great. Mainly I’m just curious. I’m still trying to figure out what the /300 scaling in these two equations are for:

XPos2(Index) = -(DCoord * COS(DAngle + (Index * 43 + 21)) / 300)
ZPos2(Index) = -(DCoord * SIN(DAngle + (Index * 43 + 21)) / 300)

Maybe Luis has figured it out? Or Laurent Gay would care to comment?

Alan KM6VV

2

Hello Allen, I can’t comment on the other things, but I am responsible for the above anomaly. The first version of the SSC-32 was limited to 0.75mS to 2.25mS range. This was done on purpose to protect a servo from being commanded beyond it’s limitation. We later decided this limitation prevented the utilization of the entire available range of the servo. So we changed it to 0.5mS to 2.5mS. Somewhere in the process I measured the pulse required to get the +/- 45° and published it, but I never went back and defined the 0.5mS to 2.5mS range. Technically the 0.5mS to 2.5mS range is not 180° as one side or the other will be out of range. The problem is compounded by the fact that the extended range (beyond +/- 45°) is not as linear as the +/- 45° range. I will be updating the SSC-32 manual very soon. I will change it to at least be linear, even if it not completely accurate. :unamused:

3

Hi Jim,

No worries! Just a little confusing until I realized what was happening. Thought you might be interested.

I suppose I could attach some sort of protractor to a servo shaft, take readings at a score of points, and determine the linearity.

If I’ve got the intent right, one could use a few equations (mine are in C) to calculate the “Pulse Min/Max” for any servo, given the min/max angles recorded from setup using something like the Visual Sequencer.

[code]/* 10 x servo scale from BASIC Angle (L is LONG constant) /
LBservo = (10L * 360L * 2000L) / 256L / 180L; / = 156 */

/* 1/2 range of servo wanted (BASIC scaling, these would be BASIC Words)*/
Brange = (unsigned int)((HipH_AngleMax - HipH_AngleMin) * LBservo) / 20;

HipH_PulseMin = 1500 - Brange;
HipH_PulseMax = 1500 + Brange;
[/code]
I haven’t tried to translate into Atom BASIC, but you get the idea. 1/2 the range of the servo desired (Brange) is calculated (could be a preprocessor macro) and then simply added or subtracted from the center position of the servo.

This should work for the Hip Horizontal servos, where “center” is simply a right angle to the body, but what about the other two servos? Construction notes call for the HipV to be also at right angles, probably OK there as well.

Then there’s the Knee. If I understand the instructions, the knee servo is to be “centered” with the Tibia at right angles to the Femur. Or possibly the Tibia tilts a little (TibiaAngle). But, this is 90°, and not 0° for the Knee angle; so it must be “adjusted” somewhere in the code.

And Hip Vertical angle must also have a relation other then 0°.

No matter, I just need to work out the math a little more. I know it’s in there!

By the way, the website hints that the new SSC32 is out, is that correct?

Alan KM6VV

4

If you are referring to the RIOS and SEQ updates that are being done, it’s to handle the firmware updating for the new SSC-32. And so the programs know which processor is being used. There will be more updates to SEQ to take full advantage of the numerous new features. I am just starting to add the new commands into the manual. We are expecting the hardware in about a week. We will then still need to program the chips, and I’m still waiting for the “golden” version of the firmware to be finished and thoroghly tested. So it’s not out yet, but it’s getting close. 8)

5

Im slightly confused…I have the new V2 ssc-32, with the latest firmware, is the scaling still non-linear? the inverse kinematics module i just finished writing for my project assumes:

0.5mS = +90
1.0mS = +45
1.5mS = 0
2.0mS = -45
2.5mS = -90

ie the 180deg is evenly spread over the 2.5mS band. Is this correct or do I need to make a few changes?

6

If you want to be accurate, you probably need to test each servo to find the actual values that will place the servo at its max position in each direction of rotation. Also note that the deg resolution figures may be a bit misleading in that the resolution is actually in reguards to the position signal sent out by the controller, and may or may not result in the same deg resolution of the servo itself.