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 througout 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 non-circular gears, to then use that software to generate computer descriptions of 3 distinct pairs for manufacture on the Stratsys FDM 1650 machine, 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).

How it all works

My primary goals for the software were:

• 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.
• Relative Efficiency. I wanted the program to be able to make a normal-sized gear in a 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.

Note on the Description of the Gear Shapes

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).

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 non-circular 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')² + (r2')²-2(r1')(r2')cos(Δθ') = d² = (r1)² + (r2)²-2(r1)(r2)cos(Δθ)

which becomes,

Δθ' = acos( ((r1)² + (r2)² - 2(r1)(r2)cos(Δθ) - (r1')² - (r2')²) / (-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.

Possible Future Improvements

• 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.