SSC-32 controlling non-servo motors

Hi,

I was wondering if it was possible to control a non-servo DC motor (Such as those planetary motion motors).

I’m asking this because I am in need of a motor that has full positional control AND can move 360 degrees.

If that is not possible, I guess I can just sandwich 2 servos back to back but then it gets a bit bulky…

Thanks,
Stephen

You may want to check into sail wench servos as they may be capable of more than 180 deg rotation. If the load isn’t heavy, you could make or buy a gear/pully setup for a regular servo to make it turn the desired gizmo 360 deg.

Does anyone know just why servos are so often limited to 180 degrees?
I understand that there’s the stoppers on the gears that physically limit the rotation, but what then is the reason for having those stoppers limit it to around 180 degrees?

Can it just be that the potentiometers that they use are only 1/2 turn pots?

What about GWS S06/CRS, these are factory modified continuous rotation servos ([email protected]).

All servos (at least, all that I’ve ever heard of) that are modified for continuous rotation lose their ability to hold a position.
They effectively become a really convenient (and cheap!) package of speed controller, motor, and gear reduction.
Great for small rovers, pretty useless for servo robots.

The position feedback is usually the reason for limiting the rotation degrees. You could make a continuous rotation digital servo using a position encoder instead of a pot. You might even be able to use just a quadrature encoder if it has an index pulse, the bigest problem there being when you first apply power the servo has no idea of its absolute position until it sees the index pulse. Generally speaking position encoders however are expensive so bear that in mind.

Another approach that might be worth looking into is using a pair of analog output hall sensors 90 degrees out of phase and a small cylindrical or bar magnet. Since you can determine north or south polarity you can get sine/cosine functions to compute the position. I don’t know how accurate it would be. Nothing prevents you from using more than 2 sensors though either. I think 10-bit positional resolution would be tough to do without 6 to 8 sensors, or some clever metal work with laminates to focus the magnetic fields. Might be an interesting project for school or science fair or something.

Ooooh…
Why settle for the accuracy of an optical encoder when we’re dealing with the low speeds of a servo and don’t have any real size restrictions?
Why not further itterate to an decaencoder, or greater?

                            *
|█ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ |row6
|██  ██  ██  ██  ██  ██  ██  ██  ██  ██  ██  ██  ██  ██  ██  ██  |row5
|████    ████    ████    ████    ████    ████    ████    ████    |row4
|████████        ████████        ████████        ████████        |row3
|████████████████                ████████████████                |row2
|████████████████████████████████                                |row1

The optic sensors would ideally be a phototranstor for each row, positioned one on top of the other, like so:
() Phototransistor 6
() Phototransistor 5
() Phototransistor 4
() Phototransistor 3
() Phototransistor 2
() Phototransistor 1

The above would produce a 6-bit resolution of position (a resolution of , one bit for each row).
I’d have shown an 10-bit setup, but that wouldn’t fit on the width of this screen.
:stuck_out_tongue:
Methinks that upon startup, the controlling micro would be able to easilly tell where it is within the resolution of it’s readout.

// Note the star in the topmost code window.
// Let's imagine that's where this bugger would be upon startup.
// Here's how I'd find out where it is:

// A return of 0 = unshaded area; a return of 1 = shaded area.
// Get row6 first, since it'll be changing the fastest.
Row6 = IsRow1Shaded();
Row5 = IsRow1Shaded();
Row4 = IsRow1Shaded();
Row3 = IsRow1Shaded();
Row2 = IsRow1Shaded();
Row1 = IsRow1Shaded();

// Zero out a variable to hold the servo position.
Degrees = 0;

// If the row 1 transistor is over a non-shaded area...
If Row1 = 0 Then
// Then the position must be greater than 180 degrees.
Degrees = 180;
// Otherwise, if it's over shaded area, then the value is between 0 and 180, and so Degrees will stay = to 0, for now.

// And so on for the other ones:
If Row2 = 0 Then
Degrees = Degrees + 90;
If Row3 = 0 Then
Degrees = Degrees + 45;
If Row4 = 0 Then
Degrees = Degrees + 22.5;
If Row5 = 0 Then
Degrees = Degrees + 11.25;
If Row6 = 0 Then
Degrees = Degrees + 5.625;

With the star representing the position of the servo in the example, the 6 rows would be shaded as follows:
Row 1 = 1;
Row 2 = 0;
Row 3 = 0;
Row 4 = 1;
Row 5 = 0;
Row 6 = 0;

Which means, Degrees would turn out to be:
90 + 45 + 11.25 + 5.625 = 151.875
The actual position with only 6 rows, though could be up to 5.625 degrees greater than that.
So the position is somewhere between 151.875 and 157.5 degrees.
With 10 bits, the position could be read to about a third of a degree, which should be fine.

The only hurtle for this would be size.
The outermost row would have 2^10 = 512 shaded sections which makes the sections really small or the ring really large.
Either way, it’d only be a problem when the servo is moving, and even then, only when it’s moving at a rapid pace.

If a very rapid pace is required (faster than the above code can run) then the PID code will just have to switch over to using the messier analog value of the rapidly-switching transistor.
That’ll tell it the speed of rotation, which it can use to pretty accurately estimate position.
When the position becomes close to the target position, the servo will be braked and then the accurate low-speed digital positioning can be used to tweak it into just the right spot.
And all that might not be necessary, if the servo is slow enough, which it very well may be.

Thanks for the replies.

I remember seeing a servo motor that can only do 4 full rotations. I don’t understand how that is possible? But if it is (and contains positional control), I might try to look into that.

The reason why they can turn four turns is that the gearing inside is made for four turns in stead of half a turn so the internal pot doesn’t hit the end of its physical travel range. Using RC servos for robots is a hack in itself, as most RC servos are really designed for 90 deg rotation. Below is a servo that might be of interest.

www2.towerhobbies.com/cgi-bin/wt … XGZU3&P=FR
servocity.com/html/hs-785hb_ … tions.html
rcmart.com/catalog/product_i … s_id=10508

The middle servo looks like it would be perfect if you could settle for an analogue one. I’m assuming the others being sail servos can also do at least one full rotation also? Nowhere in the specs seem to show that. Just like to know since I may need a 180+ servo for something in the near future.

Sail servos are probably 180 deg. max. They are high torque servos equiped with long arms. The below link shows the types of setups.

amya.org/sailservo.html

So what I can deduce from these facts is that the gearing down of these servo motors will actually cause it to lose a precision factor equal to the number of gearing down? Is that correct?

So for instance, if a servo says it can do 2 full rotations, the precision loss (when compared with the same 180 degree servo without the gearing) will be equal to +/- 4 degrees per degree?

From the below info given on the servo page, the best accuracy would probably be 12.6 deg for the servo (400usec divided by 8usec deadband is 50, which divided into 630 deg. results in 12.6 deg.). This may depend on weather the dead band is actually +4usec and -4usec from a center point, which might result in 6.3 deg as the smallest controllable movement.

Operating Angle: 630 Deg. one side pulse traveling 400usec
Dead Band Width: 8usec

I think they limit it to 180. is because they (servos)where intended for model airplane and such. and 180 is a full throw on a control rod,
all hitek has to do is change the stops and gear on the pot and u got ur 360 degree servo(bet they already got em in japan) :imp:

Not exactly… The servos are really designed for only 90° rotation, but you are correct about the control rod thing. If you connect a servo to an RC radio you can only get around 90° range from them. If they removed the stops on the final gear, the potentiometer still only has about 270° range.

This is probably a stupid question… but I don’t understand the calculation too well.

Deadband is the amount of time required before the motor begins moving after seeing a pulse right?

So what does dividing the 400us pulse by the deadband width mean?

deadband is the positional slop around the destination point. it is a lack of precision, the ability to hold a consistent grouping of samples. with servos you send a commanded position ad the servomechanism attempts to move to that position. due to things like inertia in the motor and gear train, mechanical slop in the geartrain, and tolerance in the electronics hitting an exact position and holding it is an exercise in futility. thus you get a deadband where the servo considers its current position close enough and stops trying to get closer.

I am not certain if there is a specific term applied to the time between a servo receiving a commnd and starting to act upon that command. perhaps it is acceptable to borrow from the networking world and call it lag, if you need to refer to the effect.

I was wondering how do we calculate the resolution of the motors and the precisional error of the motors?

I think Eddie might have explained that a bit too technically.
Sorry, Eddie!
:stuck_out_tongue:

Well, theoretically, you have a maximum precision of 400 (one for each microsecond).
But, an 8 microsecond “slop” means that any value you input might actually be up to 8 values away from it.

In other words, you could input 300us and actually get a position of 305us.
You could also input a 305us and get a position of 305us.
In essence, any values that are closer than 8 values appart are (or at least could be) the same value.

So the total amount of guaranteed-to-be-different positions that you really can get out of it is 400 / 8 = 50.

I’m assuming that you mean servos (“motors” includes planetary, gearheads, encoded, servos, linear and a whole host of other actuators).
In that case, you take the total number of degrees of motion, divide that by the total number of possible input values, and multiply that by the deadband value.

In your case: 630 / 400 * 8 = 12.6
That’s assuming, as Eddie wondered, that the deadband is 8us total (4us in either direction).

That gives you the maximum resolution in degrees.
If you instead want a percentage, then you can just divide that by the total degrees:
12.6 / 630 = 2%

2% sounds pretty accurate, but 12.6 degrees is certaintly a very visible deadband!

Meh, I chose to just explain what was meant by the word deadband since he did not appear to know, and lacking that bit he was not going to correctly understand what had been stated previously. :confused: