Designing an Orrery

Preface

As this is part of a project portfolio, I wanted to define the problem for the project, show a logical design process, display my capabilities, reveal the outcome, and share what I learned.

At the same time, I also hope my design process, background research, and ideas can be a reference that helps others design their own orreries; this means the content is sometimes a bit technical. (If you want to skip the design process and use someone else’s existing gear ratios, you may want to instead just follow instructions from Instructables.)

Motivation

As a child, I remember attempting to build a Lego model of the solar system, but I was never fully satisfied. Having learned about mechanical design, I decided to revisit this aspiration in college.

Personally, I also find orreries beautiful, both for their mechanisms and for their artistry. I was particularly inspired by orreries from Ken Condal (Zeamon)¹, Staines & Son Orrery Makers², Paul Bambrick Finescale Modelling³, and a student team from the University of Colorado Bolder⁴.

Historical reasons for mechanical astronomical models

For centuries, as both an educational tool and as technical skill demonstration of a business or clockmaker, people have constructed mechanical astronomical models under a variety of names (orreries, planetariums, tellurians, and more).

Problem

My priority was to design an orrery with better accuracy of the relative motion of the planets through the application of modern computational and manufacturing tools.

I also wanted to make it easy to continue iterating in the future, creating newer versions of the system. This favored free and open source software, automation of design changes, and use of readily available manufacturing processes.

Project Constraints

• I was a student. It had to differentiate itself from the current state of the art and contribute to the field.
• I did not have
  • time to cut the gears by hand
  • the budget or access to CNC or manual machining equipment
• I had access to
  • my personal tools,
  • Open Hardware Makerspace
  • the NCSU Hunt Library Makerspace⁵
  • a great local hardware store⁶
  • online parts catalogs
  • online custom fabrication services (Shapeways⁷, etc) as I could afford.

Avoiding Feature Creep

With a self-directed project like this, I had to resist a tendency to explore and pursue “side quests”. ( “Yak shaving” refers to a related practice.) I enjoy learning and making a project even better, but this makes projects take longer. In this particular case, I had a hard deadline because I decided to turn the project into an academic one. Therefore, I deliberately left some paths untraveled:

• I used sidereal periods calculated by others, rather than deriving them myself for a particular date range from ephemeride data. The derivation of sidereal periods is discussed further in a footnote for a later section.
• All orbits were represented as circular and coplanar, rather than as elliptical with inclination.
• Planet tilt, moons, and rotations of the planets or sun were not addressed.
• Rather than creating a script completely myself, I used an existing OpenSCAD involute gear script to create my teeth profiles.⁸ (I did have to modify it to generate stub teeth profiles; stub teeth are less delicate with small numbers of teeth.) The number of possible gear ratios increases when the minimum number of gear teeth decreases.
• I manually packed the laser cut parts onto sheets rather than automating it.⁹
• Ornamenting the face of each gear with fractals or other generative art would have added work unrelated to the mechanical design, so I left them unadorned.

Gear Selection

Target Ratios and Significant Figures

I used the sidereal periods to calculate the desired ratios between planets. One key was finding sources with a large number of significant figures. The periods I used are listed below and are found in multiple sources. Some other orreries may be based on other sources and values.¹⁰

The fabricated system’s gear ratios are exact mathematical quantities, so they are not a limiting factor in the number of significant figures.¹¹ To avoid cumulative rounding errors, when computing the ratios between planets and the accuracy of the mechanical design, significant figure rounding was not done until after the calculations were complete.

System Design

The distribution of the list of available gear ratios (with various constraints) showed the frequency of unique gear ratios was greatest near 1:1. This is significant because the maximum error decreases when the available gear ratios are closer together. The distance between each next available gear ratio can can be used to predict the maximum error magnitude (at a particular gear ratio).¹²

This type of information also helped me strategize on how to structure the gearing. The gear system connectivity can be represented graphically. Planets (and, if present, auxiliary axes) are represented as nodes. A train of gears between a pair of nodes is represented as an edge. The edges are undirected because power can be transmitted along a gear train in either direction.

The graph should be connected and acyclic (no loops). The first requirement (connected) allows a single power source to drive all the nodes. Because a single path from a power source is sufficient to drive any node, adding a loop of intermeshed gears (a “constrained gear system”) would not drive a node better, but would add complexity, require more precision in manufacturing, and be more likely to jam.

This limits the possible gear systems to those that can be represented by a tree graph. The number of possible trees grows rapidly as the number of nodes increases, as defined by Cayley’s Formula (n^n-2). Because of the size of this number, I decided what trees to consider based on the distribution of gear ratios and a desire to limit the system size and keep fabrication and assembly simple.

It may be possible to construct a particular tree in multiple ways, several of which Michael Whiting describes in the Bulletin of the Scientific Instrument Society Number 94¹³. By adopting the traditional “telescoping tubing” construction, which separates the gears from the planets, a variety of possible trees could be considered. I knew that the fewer constraints I had on the gears, the more accurate I could get the gear ratios. This would also tend to favor gear trains with more stages (and larger gears), but I decided to limit the system size to fit on a desk so it would remain portable.

In our solar system, all planets have prograde orbits (they all orbit in the same direction as the sun’s rotation). This adds a constraint to the paths between each planet node in these trees. In my opinion, the simplest way to satisfy this constraint is to have an even number of gear train stages between each planet, but there are other options (like idler gears) that can be used to keep all planets orbiting in the same direction.

Gearing Insights

There are a variety of other sources that provide methods for selecting gears for a desired ratio (like continued fractions), but having a computer provides a huge advantage. I instead generated and selected from a list of every gear ratio possible given constraints on the number of gear teeth and the number of gears in the train.

I wrote a script to do a depth-first search, trying different gear trains for each edge, and backtracking when the error for the system exceeded the previous best design.

A More Complete Picture of Accuracy

I cared not just about the ratio of Earth’s speed to the speed of other planets or the accuracy of a planet relative to its neighbors. I cared about the accuracy of the movement of every planet relative to every other planet.

From a list of gear ratios and an incidence / adjacency matrix representing a particular tree, I had a script that would complete a matrix with the effective ratios between any node and any other node. There was a similar matrix with the desired ratios, allowing an error to be computed for each planet pair. I found that heatmaps were an effective way to visualize the location and size of those errors.

Accuracy Heatmaps & Comparison to Reference Designs

I found a number of other designs¹⁴, some of which had documented gear ratios. In a small number of cases, it appeared like a gear ratio was accidentally inverted; in those cases, I gave them the “benefit of the doubt” and corrected it for them to improve their accuracy. The names I gave to each design and their sources are in the below table.

The orrery names are shown by hovering your cursor over the heatmap images.

Some designs only include a subset of the planets I included in my orrery, which is why their heatmaps have fewer regions. Clicking on any heatmap should open a larger version of that heatmap.

Cubehelix Heatmaps

This is sort of an extension of the linear grey colormap. Dave Green created the cubehelix color scheme¹⁵ which is based primarily on saturation (black to white), onto which a cycle of colors is added. If it is printed greyscale, a continuous gradient is still present. Personally, I find it is easier to differentiate between close values with this than with greys because the color supplements the brightness information. Although cubehelix heatmaps have significant advantages, the rainbow heatmaps do a better job showing that the main diagonal does not contain meaningful information.

Rainbow Heatmaps

The predefined rainbow colormaps commonly available (like “jet” in MATLAB) can distort how the data is perceived. For the rainbow colorations, I used a color map¹⁶ developed by Peter Kovesi at the Center of Exploration Targeting which is designed to have a perceptually uniform color space.

Greyscale Heatmaps

I also produced a set using one of Kovesi's linear grey color map options^endnote to make sure there is a good option for colorblind people. Note that the main diagonal does not contain meaningful information, which is not as obvious with this color map as with the rainbow version.

From Ratios to Parts

I considered several manufacturing options, but decided to laser cut the gears because it was cost-effective, precise, and fast (efficiently going from CAD file to usable part with minimal post-processing). I also had access to the necessary equipment and it gave me considerable flexibility in the design and options for gear ratios.

Some of the gears were large in size so I used ¹⁄₈ inch thick acrylic to limit how much they flexed. (Thinner sheets were tried initially.) The thicker material plus spacers along the shaft between each gear, enabled the gears to mesh successfully even with some flexing or inclination.

I also anticipated this approach would have the added advantage of being aesthetically pleasing. Clear acrylic was attractive and made the mechanism both visible and ethereal. By keeping everything visible but not too visible, it would provide some sense of the layers and complexity of the mechanism but also be somewhat mystifying and magical at the same time.

The majority of the cost of the system was the acrylic sheets and 3d printing.

OpenSCAD Model

OpenSCAD had two major disadvantages.

1. It is slower to design with than commercial modeling tools, leading me to simplify some modeling (omitting details like the threaded rods and nuts and cotter pins). Some unmodeled hardware nearly caused problems during assembly, but I thankfully included enough clearance that things did fit.
2. Any changes required the entire model to be recomputed; this was annoyingly slow.

OpenSCAD had five primary advantages:

1. It ran on my Linux computer.
2. It was free.
3. It works well with git, which allowed easy diffing and change tracking.
4. There were community-contributed online resources to build upon.
5. I could control it programmatically.

Build Automation and Version Control

Using a Makefile and OpenSCAD’s command line interface, I could create a model of just the gears (suppressing everything else), take slices at various heights, and export these slices as vector files to be layed out for laser cutting. The Makefile could also generate screenshots of the OpenSCAD model and update the LaTeX project report.

During much of the project, I also used git for version control. I tracked changes to the MATLAB / Octave scripts, the draft of my project report (written in LaTeX), and a variety of other files. Below is a screenshot of a graphical interface showing some of the revision history of the project’s git repository.

Fabricated System

Lessons Learned

Below are some observations from this project that apply to more than just orreries:

1. I enjoy investing making things and being able to refine their design.
2. It is tempting to spend a lot of time on things I enjoy. To keep a project on schedule, it is important to have a defined project scope and to break projects up into smaller deadlines.
3. Version control is incredibly useful. Using Git, I could track my code and documentation as it evolved, comment on those changes, and easily see differences between versions. When I started my job after graduation, this experience helped me to appreciate and quickly learn SolidWorks PDM (a proprietary version control solution from Dassault Systèmes).
4. I should have used Octave or Python for development instead of MATLAB. MATLAB was free as a student, but GNU Octave and Python are always free and would have sufficed for this project.
5. Although the laser cutter made fabricating parts easy, assembly could be improved. Soldering was done before the gears were added. However, this increased the difficulty in keeping the gears straight during assembly and risked damage to the planet arms.
6. A project will never be perfect, but it can complete an objective. If the project is well documented, it makes it easier to pick the project up again.

Footnotes

• orrery
• 3d printing
• laser cutting
• open source
• creativity
• NCSU
• MATLAB
• Octave
• OpenSCAD
• LaTeX
• miscellaneous