review of servo concepts - walking through the math
prof_braino
Posts: 4,313
Servo questions here:
This work is done in FORTH, so I'm trying not to cheat and look at the spin code in the OBEX just yet. I want to see if I'm getting my head around the concepts.
Since each servo wants a pulse every 20ms, and the maximum pulse for servo control is 2.25ms,
we can time-slice eight servos on a cog's counter. 20ms / 8 times is greater than 2.25ms
Since there are two counters per cog, it appears that one may control 16 servos on a single cog;
also one might control 32 servos using only two cogs.
Question: Has anyone found a way to control more than 16 servos per cog?
I only have a couple servos, I was thinking I would put a servo on a pin, and a second servo on another pin, and move the second servo through all the pins to verify that they both work together in all combinations. But this isn't the same a testing 32 physical servos at once. Also, If I did hook up 32 servos, I wouldn't have any lines left for command input.
Question: Any suggestions on how to test 32 servos at once?
Or at least a better way to verify that it works without 32 physical servos?
The Max time required to output a pulse is 2.35-2.39 ms due to processing. Since the Absolute allowable limits are 0.75 to 2.25 (1.5 is always middle), the processing time should not interfere with servo operation. Has anyone found evidence to the contrary?
In the interest of simplicity, the servo number equals the i/o pin number. The servo is enabled using a bit mask.
Question: Any comments on the impact of this?
Could somebody check my math? The calculation for smallest noticeable change was:
Smallest detectable pulse change is 12.5ns
Pulse range - Max pulse 2.25ms - minimum pulse 0.75ms = 1.5ms pulse range = 1,500,000ns
1,500,000ns / 12.5ns = 120,000 discrete values.
Also, a typical servo was spec'd with a deadband of 4 microseconds or 4000ns.
So 4000ns / 12.5ns = 320 positional units for deadband;
that is, the sevro must be commanded to move greater than 320 positions before it responds.
Therefore, the test can be set up so that
1. the servo is commanded position X
2. the servo is commanded to any position X +/- N greater than 320
3. the servo is commanded back to position X (to verify repeatability)
and:
1. the servo is commanded position X
2. the servo is commanded to any position X +/- N greater than 320
3. the servo is commanded back to position X+1 (to verify unique positions)
Any comments/suggestions on this?
This work is done in FORTH, so I'm trying not to cheat and look at the spin code in the OBEX just yet. I want to see if I'm getting my head around the concepts.
Since each servo wants a pulse every 20ms, and the maximum pulse for servo control is 2.25ms,
we can time-slice eight servos on a cog's counter. 20ms / 8 times is greater than 2.25ms
Since there are two counters per cog, it appears that one may control 16 servos on a single cog;
also one might control 32 servos using only two cogs.
Question: Has anyone found a way to control more than 16 servos per cog?
I only have a couple servos, I was thinking I would put a servo on a pin, and a second servo on another pin, and move the second servo through all the pins to verify that they both work together in all combinations. But this isn't the same a testing 32 physical servos at once. Also, If I did hook up 32 servos, I wouldn't have any lines left for command input.
Question: Any suggestions on how to test 32 servos at once?
Or at least a better way to verify that it works without 32 physical servos?
The Max time required to output a pulse is 2.35-2.39 ms due to processing. Since the Absolute allowable limits are 0.75 to 2.25 (1.5 is always middle), the processing time should not interfere with servo operation. Has anyone found evidence to the contrary?
In the interest of simplicity, the servo number equals the i/o pin number. The servo is enabled using a bit mask.
Question: Any comments on the impact of this?
Could somebody check my math? The calculation for smallest noticeable change was:
Smallest detectable pulse change is 12.5ns
Pulse range - Max pulse 2.25ms - minimum pulse 0.75ms = 1.5ms pulse range = 1,500,000ns
1,500,000ns / 12.5ns = 120,000 discrete values.
Also, a typical servo was spec'd with a deadband of 4 microseconds or 4000ns.
So 4000ns / 12.5ns = 320 positional units for deadband;
that is, the sevro must be commanded to move greater than 320 positions before it responds.
Therefore, the test can be set up so that
1. the servo is commanded position X
2. the servo is commanded to any position X +/- N greater than 320
3. the servo is commanded back to position X (to verify repeatability)
and:
1. the servo is commanded position X
2. the servo is commanded to any position X +/- N greater than 320
3. the servo is commanded back to position X+1 (to verify unique positions)
Any comments/suggestions on this?
Comments
http://obex.parallax.com/objects/51/
There are several servos that *can* operate outside this range, though not to manufacturer's specs. After some discussion by the Arduino folks and testing various servos, they arrived at the following mins and maxs as representative of the bulk of servos available today:
min 544
max 2400
Might be typical for analog, especially cheaper servos. Many of the newer digital servos have tighter deadbands. The deadband can be programmed on Hitec servos, and it can be as low as 0. Factory default on these is closer to 3 us.
-- Gordon
Thanks for the response, maybe you didn't notice
Thanks for the response. I'm assuming the min max are milliseconds.
So a deadband of zero? WOW! So if I did the math right and there are 120,000 discrete positions, can the servo move from position x to position x+1?
I would image that the play in the gears would not have moved enough?
How do we test / observe the minimum motion?
would help to see the minimum Motion?
Bear in mind that deadband comes down to the size of the error signal, so it's also relevant beyond incremental motion. I don't think most people would actually program their digital servos with 0 deadband. I mentioned it only in case you were designing your system around a 4 us deadband, which is actually fairly coarse even for an analog servo (at least the good ones).
Approaching this from a practical standpoint, most servo controllers use serial commands to set position, and limit the resolution to 255 steps -- with 0 turning the servo off by removing its pulses -- so they can use convenient byte-sized commands.
That's adequate for most applications, but a 16-bit position would be better for the more demanding task. That would give you 65535 steps (0 turning the servo off). From that you can arrive at the practical resolution, which is still going to be under one degree given a 500 to 2500 us range. This is better than the mechanical tolerance of the servo (gear backlash, linkage slop, etc.), which in the end is the limiting factor on how accurate the motor will position.
(Note that the trick of removing pulses to de-energize the motor applies to analog and some low-end digital servos. It doesn't work with most digital servos, which will continue pulsing the motor using the last good signal that was received.)
I've seen servo controllers with 32 outputs, but I've not found that the more the merrier. A 4DOF hexapod would only use 24 servos, and besides costing more than a used car when equipped with high-torque digital motors, the battery requirements for keeping this thing in motion are scary enough.
Apart from the two lines you'll need for serial communications, at 24 servo outputs, you could have some left over for other neat tasks. Example: it's not unusual to also need some form of absolute or incremental encoders even with servos, and especially with servos modified for full rotation. You'll have some I/O and cogs free for a couple of quad encoder inputs. For mobile applications, a battery monitor would be helpful, as well as SPI or I2C for communications with a sub processor.
I know you're trying not to cheat by looking at other examples, but merely on a form-factor level take a look at the Devantech SD21. He even thought of being able to put a BS2 directly on the board, in addition to I2C. It would be great to have a version for a PropStick and/or SpinStamp.
-- Gordon
You could use a second prop to measure the pulse widths. Of course if you use all 32 pins for servo signals there would not be any way to communicate the results so 2 props may be required.
Minimum motion is from position to position +1, so +5 won't do it. The dead band is listed as 320
I was thinking of setting up mirrors and a laser pointer so I could have a really long radius and measure the angular change.
I still have to figure out how long a radius is needed for .03 seconds of arc to make a cord of 1 cm. But I haven't dusted off my old math books.
I'm thinking the test would be to move from position to position + 45 degrees, then back to position, and measure for repeatability.
The next test would be to move from position to position + 45 degrees, then to position + 1, and measure for accuracy.
But, I would like to see the Mirror and Laser measuring setup, sounds like you could get some very fine measurements.
I see a Compass, a Protractor, and Calculator in your near future prof_braino... :thumb:
-Tommy
This was done with old chart recorders and photosensitive paper for (relatively) high speed signals. The "pen" looked like an overweight ball point pen refill with a small mirror on it. If you can find one of these chart recorders you should have most of what you need to do this.
This is a good way to test the accuracy of the motor, but will it test your code? No doubt you'll see errors in most any hobby R/C motor. I think the thing to check is the waveform on a scope. Assuming a specified 1 us minimum deadband, you want jitter no greater than that.
Whatever system you use, remember not to pulse all the servos at once (then turning them off at specific times, depending on the pulse duration needed for that servo). That's been a problem with some of the servo drivers people have created. Remember that analog servos are actually powered each pulse. The power requirements of 16 or 32 motors turning on at the same time is enormous. You have to service the motors in an effective round-robin fashion. Sounds like you're planning on doing that, but I thought I'd mention it.
-- Gordon
Thanks for the tips. I'm doing testing for the author of propforth. As I understand it, the design is like this:
Since there is a maximum pulse width of 2.5ms every 20ms, there can be eight servos serviced by a single source with no interuption of service.
The counter is is used to output a pulse of .5 to 2.36ms (due to overhead) on eight servos, each in turn using one counter. Since there are two counters on a cogs, a single cog can totentially control 16 servos. Two servos, one on each counter, will see their pulses starting at (perhaps) the same time, per cog. Potentially, two cogs can control 32 servos, the code is configured this way by default and the user sets bits in a control word to enable or disable individual cogs. So worst case, Four servos can see their pulses at the same time, one controled by each of two counters on two cogs.
My protoboard is connected to a standard issue Parallax wall-wart. Does it look like I will see smoke doing this? Will the board or the wall-wart or the servos smoke more? Would it be worth it to catch it on video? (mad scienntist laugh Muhuhahahaha!)
Four is probably okay.
Most any wall wart with 1000mA output at 6VDC ought to be enough for four standard servos. Put a big o' cap (200 uF to 470 uF, or thereabouts) across the power supply for the servos.
Thanks! Hopefully I will start testing this weekend. If they work individually and in groups of four, I will be able to justify buying a bunch more servos.