Precision Motor

[Psawhn]

While trying to make turrets and things, I've often lamented the difficulty of making a rotating base that works under all conditions, and rotates to the precise angle specified.

The system I've come up with uses only hydraulics and an expression gate. It does not include any angle-measuring tools for self-correction. It should work in any position: right side up, on its side, upside-down, or any oblique angle. It will return to its position if you spin it with the physgun, no matter what position it was originally in, and what position you physgun it too. Its accuracy and performance decrease under imbalanced heavy loads, but that is more of a gmod problem. (You may be able to use the weight stool to help with that.)
Attached are both the advanced duplicator save, and the expression gate.

To use, simply attach an output, in degrees, to the 'Angle' input of the expression gate. That's basically it.

For advanced users:
The motor rotates counterclockwise, with its initial position as zero. I've included a red rope for reference - if you want to delete it, just select the rope stool then reload on the disc. If you want to add your own self-correction, set a correcting value to input to 'Offset.' Finally, you may also need to reset the constants - either reset the expression gate using the expression gate stool (reload on the chip), or set an input of 1 to 'Reset.' This will reset the constants and the offset.

To try it out:
Create a camera and parent it to the rotating disc. Create a pod or a chair, and an advanced pod controller. Link the adv. pod controller to your pod. Wire up the input 'Angle' on the expression chip of the motor to the 'Bearing' output of the pod.
Now enter your pod, and activate the camera. Your view will react smoothly to your horizontal mouse movements - in fact, the view will respond to your mouse movements almost exactly as normal.

How it works:
There are four hydraulics connected between the four 'corners' of the rotating disc and one spot on the base plate. As long as each hydraulic is set to a certain length, the disc will have only one position it can remain in. To calculate the needed lengths, I used a single hydraulic to find what length is needed to rotate the disc to positions of 15 degrees, 30 degrees, etc. I then performed a cubic regression on these data points to find a cubic function that approximates the exact lengths needed. Next was the simple task of programming the expression gate to output the needed hydraulic lengths based on this function.

If people ask I can make a tutorial, but be warned that 50% of the effort going into this is just data collection and math.

Accuracy:
I haven't done any detailed analysis yet, but the motor, as supplied while oriented horizontally, appears to stay within one degree of the target angle. Using a quartic function may lessen that, but gmod constructions in themselves are rather springy and such extra accuracy may not be significant. Also, adding off-balance weight (put a heavy prop on one side while rotating the motor sideways) will obviously affect its accuracy.

If extra accuracy is needed (such as for artillery), then the offset parameter may be used as a self-correcting value. Internally, the offset is simply added to the target angle, so positive offsets rotate the disc counterclockwise.

What's next:
While I'm at it, I might as well make a smaller version and a larger version.

Edit: Using hydraulics for the motor is not a new idea, but I think experimentally finding a function for the hydraulics this way is a different way of doing things.

[Bull]

All the hydraulics seem to be attached to one point.

I've seen the same setup but then a wheel in the middle of a plate with hydraulics to each corner. That seems a much better force distribution along the hydraulics.

[3dfactor]

Two hydraulics with sin() and cos() applied should make a perfect spin in precise angles.

[Psawhn]

I don't exactly know what you mean by better force distribution. Could you explain?
And is this the setup you mention? The only one I can find is here: http://www.wiremod.com/forum/wiremod...sed-motor.html
Our designs are practically identical, except inverted. His hydraulics all attach to one point on his wheel, but four corners of the base plate. Mine attach to one point on the base plate, but four corners of the disc. If anything, the difference is that his design puts more strain on his axis constraint than mine.

The advantage of meeting up on a single point on the base plate is that of size. I could replace that plate with a harpoon, and move my expression gate and hyd. controllers somewhere else, and the motor would work exactly the same.


Two hydraulics might work, but they must be set up carefully. In certain setups, there exist rotations such that the hydraulics do not exert any rotational force on the disc. In this case, the disc might begin to turn in either direction. Ideally, the hydraulics would be attached to the same point of the base plate and attached to the disc 90 degrees apart, or attached to the disc at the same point and attached to the base plate 90 degrees apart.

Two hydraulics also run into the problem of placing strain on the axis constraint.

The equation needed is not a simple sinusoidal function, either. It's more like:
h = sqrt((s-rsin(a)^2 + (rcos(a))^2 + t^2)
Where:
h = hydraulic length
s = distance from the hydraulic root to the disc center
r = radius of disc
a = angle of rotation
t = thickness of disc (for my setup)
Replace (a) with (a+90) for successive hydraulics.

One problem with this is that it assumes measurements are perfect, and I don't trust gmod that much.

I'm also not sure, but I think cubic functions are quicker to evaluate than trig functions. I should try with a quartic function to see how much more accurate it gets.

[Bull]

Ohh now I see.. Sorry, I only looked at your picture. I don't download dupes often.

Was busy with a assuming post, but no, guess I'll need to download first to not be a complete idiot.

brb

[Psawhn]

I see how you'd get that conception from the picture. The hydraulics just go through the disc. Maybe I should add a diagram of my contraptions from now on.

Here's a diagram of the setup, minus the hyd. controllers and expression gate.

[Bull]

Wow.. very nicely done.

Only the offset static as it is doesn't work very well.

Is it possible to add beacon sensor on the disc, linked to a locator between the hydraulics-controllers which output the current angle.

As example desired angle is 90, beacon sensor detects current angle is 86.

That difference of +4 is added to the angle fed into your expression as offset.

Problem is that when it actually reaches 90 degrees, nothing is fed as difference, angle is just 90 again and it drops back.
So it should "Remember" it needs the 4 degrees offset to get to actual 90..

Hope you can understand my explanation.. I've got a hard time understanding it myself

[Psawhn]

The offset simply adds a static value to the target angle. In the expression gate, it goes like this:
X = angnorm(Angle + Offset)
Which means that the offset is simply added to the target angle.

The problem is that the error changes based on the angle of the disc. At 0 degrees, the error might be +1 degree, but at 45 degrees, the error is -1 degree.

That means that whatever self-correction that is used must constantly evaluate its difference between true and desired angle, and then adjust the offset input based on that. A method like you describe would be exactly how it's done, but there are other ways. (Such as using the beacon sensor with a target finder, instead, for turrets.)

The problem you describe of it forgetting the offset is fixed by changing how you modify it. If your expression goes like this:
Offset = TargetAngle - TrueAngle
Then you would get that effect where it 'forgets' it needs the offset to remain at 90. However, a simple change fixes that:
Offset += TargetAngle - TrueAngle
That way, the offset 'notices' that it's already at 4, for example, then simply thinks "I have to add 0 to myself to reach the target angle."


And the reason I did not include such self-correction was because I wanted to make this device as simple as possible.