Project Report: square Gears

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

I then mounted them:

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.

Python to the resuce

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

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

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.