0 Stimmen dafür0 Stimmen dagegen

18 Aufrufe9 SeitenReport of Square Gear

Oct 28, 2016

© © All Rights Reserved

DOCX, PDF, TXT oder online auf Scribd lesen

Report of Square Gear

© All Rights Reserved

Als DOCX, PDF, TXT **herunterladen** oder online auf Scribd lesen

18 Aufrufe

Report of Square Gear

© All Rights Reserved

Als DOCX, PDF, TXT **herunterladen** oder online auf Scribd lesen

Sie sind auf Seite 1von 9

The Problem

The first industrial application of gears appeared in the horizontal-shaft water mill, described by

the Roman engineer Vitruvius in 27BC. After the advent of Christianity, this mill type became

very popular throughout the Roman Empire, as slaves that had powered the mills were freed.

With the industrial revolution, the importance of gears rose significantly, as did the number of

materials from which they could be made.

Because standard circular gears have a long history and broad usage, their production is a very

well understood practice. Non-circular gears, on the other hand, are more exotic in their uses,

and mysterious in their production. While there is a sizeable amount of theory surrounding

gearing, it mainly concerns itself with the actual manufacture and design of circular gears.

My goal in this project was to design a piece of software for producing various square gears, to

then use that to generate computer descriptions of 3 distinct pairs for manufacture on the

Stratsys, and mount these gears in an interactive installation. As an additional goal, I wanted to

understand better how the theory of circular gears can be applied to non-circular gears.

Accomplishments

I used my software to produce three distinct pairs of gears:

two identical elliptical gears with eccentricity 0.65, major axis 1.0, 21 teeth

four identical oval gears with eccentricity 0.15, major axis 1.0, 30 teeth

an oval gear with eccentricity 0.15, major axis 1.0, 40 teeth, and its complementary gear

with 80 teeth

In order to write the software, I applied a good deal of circular gear theory to non-circular gears.

Only one flaw (besides the bugginess of the software on shapes beyond what I've shown here)

remains: something is wrong with the ellipses. The shape is slightly off. The teeth don't quite

mesh properly. In some places, they barely keep together and in others they are jamming

together. The flaw is quite minor, as I only learned of it once I nailed the gears down to the

board. In cardboard (or even nailed loosely to the board) they worked fine. My first hunch was

that the tooth design was flawed, but after look further into that, I'm still not convinced that's the

problem. They do rotate, but the imperfections are detectable. It may also be a phasing issue

(even though the number of teeth used was odd).

Rapid Development. I only had a few weeks to do the project, so there was no reason to

spend time pouring over fickle C code for unnecessary performance increases.

Extensibility. Foremost, I did not want to have to write seperate code for each of the three

pairs of gears. Additionally, I wanted the software to be able to produce any reasonable

gear, that could be described according to certain mathematical constraints.

matter of seconds. Waiting more than a minute for generation of a SLIDE file for a 1 inch

square gear with 20 teeth would not be acceptable.

Keep mandatory proprietary software to minimum. The software would produce SLIDE

files, but could be reworked to produce other formats (STL or SIF) relatively easily.

Furthemore, no tools (except perhaps SLIDE) that aren't widely available would be

necessary.

Stay as far away as humanly possible from TCL. I've had dealings with frustrating

languages, but this one certainly takes first prize for the worst.

From these goals, I decided to write the software in Python, a powerful, highly object-oriented,

interpreted scripting language, originally developed at the Stichting Mathematisch Centrum,

Amsterdam by Guido van Rossum, but now under free license. It is available on virtually all

modern UNIX flavors, Windows, MacOS, and certainly others.

The object-oriented nature of Python made the extensibility simple. I only wrote one distinct

piece of code, which took locations of the teeth (as well as some other information, such as

tangent values) and produced the slide file. Currently, there are three different top-parent classes:

one for generating simple shapes, one for generating pairs of gears with different phases, and one

for generating two complimentary gears from the description of just one of the gears.

The user only needs to extend one of these classes and add functions describing the shape of the

desired gear. The following functions with no explicit parameters are needed: estimated width of

the gear (used only for centering on the screen) and estimated perimeter of the object (used as a

starting point for the refinement process that determines tooth placement). The following with

the parameter are needed: the outer radius, the inner radius, and the first and second derivatives

of x and y with respect to .

However, the inheritance heirarchy is not as simple as it could be. There is common code that

has been cut-and-pasted and then further developed. One top-parent class could be created, but

I'm concerned that modification at this point in time could result in broken software, unable to be

fixed by the deadline.

As mentioned above, certain functions are needed for the description of the gear shapes.

Examples of these functions can be seen in the software itself. On an important note though,

many of these functions were difficult to calculate. Of course, the inner and outer radius

functions are given and usually quite simple. However, computing first of second derivatives of

such functions proves to be tedious. It is concievable that these values could be approximated by

the program, instead of requiring the user to input them by hand. The current method is not so

horrible, in that mathematics software packages can compute these for the user. I used the GPL'd

Maxima.

Algorithm: Teeth Locations Approximation

When placing teeth around a shape defined by a polar equation (which must be periodic by 2),

ideally we would want to have equations describing the partial perimeter (the arc length from =

0 to the current = t, referred to as pp(t) from here on) in terms of . Using such an equation, the

exact perimeter could be computed (by pp(2)) and divided by the number of teeth to give the

circular pitch ( * module). The inverse of this function could then be used to compute the

location of tooth n (by invpp(circularPitch * n)). The points then could be used to generate the

teeth and the entire gear.

However, this ideal is far from practical. The first difficulty stems from the fact that ellipses do

not have a closed form for the description of their arc length. While there are equations for

approximating the total perimeter of an ellipse, they are of course not completely accurate.

Furthermore, these approximations cannot be directly used for arc length. This fact led me to

design an algorithm for producing my own approximations.

The algorithm is fairly straight-forward:

1. Choose a starting point for the perimeter.

2. Divide it by the number of teeth to get an estimated circular pitch.

3. Walk along the ellipse, by taking small steps (user configurable) of , compute the

cartesian distance between these points**.

4. When the cartesian distance becomes larger than the estimated circular pitch, place a

tooth there.

5. As long as is less than 2 repeat steps 3-4.

6. Compute the error: amount of summed cartesian distance left over when t reached 2 +

(actual teeth - desired number of teeth) * circular pitch. Adjust circular pitch linearly (or

possibly through other interpolation methods).

7. Repeat steps 2-6 until amount of error is small enough (user configurable).

** Some consideration for the dedendum size of the gear must be taken into account here. I

subtracted the dedendum from the radius at each point and used that to compute the cartesian

distances. This slightly distorts the shape, but has the effect that all the teeth are equally far on

the base line from their neighbors. Another approach could be taken to subtract the dedendum

value from the gears at a later point (during tooth placement), but the above property will no

longer hold. I have the hunch that certain shapes react to one method better than others. For

example, because ellipses have an off-center axis of rotation, pulling the teeth towards the axis

(by reducing r by the dedendum distance) results in teeth which are not equidistant from their

neighbors.

This algorithm seems to work fairly well for the shapes I dealt with. It is by no means perfect in

that in has difficulty with certain shapes, probably due to precision not being high enough.

For the generation of the pair of offset gears and the two conjugate gears from the description of

just one, the algorithm was slightly modified. Instead of dropping down a tooth when the circular

pitch distance is reached, a tooth is dropped down when half of that distance is reached. The

alternating points are then stored in seperate tooth location lists: one for actual teeth, one for the

gaps between them. The gap locations can be used to generate the offset gear or the conjugate

gear (depeding on the desired gear pair).

Algorithm: Geometry Generation

After the teeth locations are computed, they are sent to another function that creates the actual

points, faces, and SLIDE object for the teeth and the entire gear. Care has to be taken to orient

the teeth properly according to the tangent of the surface. The values of dx/dt and dy/dt can be

stored during computation of the teeth locations or computed on the fly during generation.

Similar care needs to be taken to create teeth with a proper involute. For circular gears, a fixed

involute equal to the radius of the circle is used. In ideal non-circular gears, a non-circular

involute would have to be generated from the entire shape. This is a seriously complicated

undertaking. I avoided it by approximating the involute curve with a circular involute, created

from a circle with a radius of the radius of curvature at that given point. Litvin recommends this

as a reasonable approximation. In physical gear construction, tools don't exist for generating noncircular involutes, so this is a necessity in the industrial world.

Algorithm: Conjugate Gear Generation

It is highly desireable for the user to be able to specify a gear shape, have the software produce

that known gear, and then produce a conjugate gear that will mesh with it, even if the actual

mathematical description of it is not explicitly known. This algorithm is similar in nature to the

one, I showed in my initial presentation. It has, however, been modified to work properly.

As mentioned above, the algorithm for teeth locations can be modified to run in a mode that

produces a list of teeth locations and gap locations. The teeth locations (from the known gear) are

turned into a gear using the same methods as if this gear were not part of a conjugate pair. The

gap locations are used to produce the actual teeth locations for the conjugate gear. When a tooth

on the known gear meshes with a tooth on the conjugate gear, the tooth from the conjugate gear

will occupy the same position as the gap neighboring the known gear tooth.

The general equation for describing the relation between a known gear (defined by r() and its

conjugate (r'() is,

r() + r'(') = E (1)

where E is the distance between the two axes of rotation. ' is equal to - , because if there are

two meshing gears, a tooth on the known gear at = 0 will be meshing with a tooth on conjugate

gear at = .

Because these two gears will be meshing, we know that the distance between the teeth on both

gears must be equal (d in the diagram below).

We also know from (1) that,

r1+r1' = E (2)

and that

r2+r2'= E (3)

We also know the values for r1, r2, from the polar description ofthe gear shape, r1' from (2)

r2' from (3).

Therefore, the only unknown value is ', which we can solve for by using the law of cosines,

(r1')2 + (r2')2-2(r1')(r2')cos(') = d2 = (r1)2 + (r2)2-2(r1)(r2)cos()

which becomes,

' = acos( ((r1)2 + (r2)2 - 2(r1)(r2)cos() - (r1')2 - (r2')2) / (-2(r1')(r2')))

Only one quantity remains unknown: E. It cannot readily be solved for, so a progressive

refinement procedure (as was done in the tooth location computation) was employed here to

solve for it.

I Learned ...

that even something as seemingly simple as a gear can take up many lines of code to

generate, and even more polygons when actually generated.

that the FDM machine does really strange things sometimes. I still don't know what

happened to the first run of the black two-period oval. It looks like they burned and

warped! See the log for more information. The red oval gears in the final mounting were

never fully completed because the FDM machine ran out of filament, but did not realize

it. I ended up adding them because they are colorful and still mesh properly with the

complete green oval gears.

as an axiom of the previous line, to budget lots of time for production and re-production

of FDM parts due to machine or design faults. The first set of elliptical gears could not

mesh because they contained an even number of teeth. With an even number of teeth, the

symmetry is not quite right. To resolve this problem, the number of teeth must be odd, or

the second gear must have a different phasing of teeth than the other. This was

implemented in the generator for the elliptical gears (el-gear.py).

that approximations can be fussy to work with, but when they do work, they can be

perfectly good at achieving a goal.

as mentioned in my last presentation, that I don't know as much about math as I would

like to. While doing a lot of the background research for the project, I was intrigued by so

many of the various mathematical topics. It still amazes me how everything seems to

connect somehow to everything else.

that I'm much better at working with computers than power tools. That big hole in one

gear was the result of drilling to deep with the 1/4 inch bit. But it was great to actually

produce a real object in a computer science class. That's certainly something I had never

done before.

Many of the algorithms need to be more generalized. For example, creating conjugate

gears with a large amount of concavity or a large eccentricity causes teeth to collide.

Some of the buys may not be able to be overcome: some shapes just are not good for

gearing. Others are errors of precision or too specific assumptions.

It would be nice if the software could generate STL files directly. It takes some time for

SLIDE to parse the large files that are being generated. For example, the 80-tooth gear

requires about 1700 points, which are generated using the standard SLIDE text syntax. I

still would like to stay away from TCL, but it would still be useful if a small amount of

TCL could be generated to create the points. More compact code could result.

Of course, more gear shapes could be added to the system. This would probably require

some debugging of the existing code for certain shapes. Others would no doubt work fine

as is.

Software

The relevant source code is available here.

And here's the documentation.

Log

Throughout this report, I kept a log of all the developments and happenings of this project.

There's some more detail (and photos) of problems that were overcome on that page.

Bibliography

Encyclopaedia Britannica, topic heading: "History of energy-conversion technology,

Waterwheels"

Mathworld, topic headings: ellipse, involute, curvature, radius of curvature, law of cosines

Gear Geometry and Applied Theory by Faydor L. Litvin, 1994, published by Prentice Hall.

## Viel mehr als nur Dokumente.

Entdecken, was Scribd alles zu bieten hat, inklusive Bücher und Hörbücher von großen Verlagen.

Jederzeit kündbar.