This is the third time I'm trying to write a post to this forum, because previously the process of writing out the issue in detail highlighted the mistakes I was making - so thanks for inadvertantly helping me along with this project already!
I'm trying to build an orrery that demonstrates correct (or at least a close approximation of) Kepler's laws of planetary motion, roughly summarised (for bodies orbiting the sun) as 1) bodies orbit as ellipses with the sun at one focus , and 2) the line from the body to the sun sweeps out a constant area per unit time - the implication being that a body on a noticably elliptical orbit will move noticably faster at perihelion (the closest approach to the sun) as it does at perihelion (the point where it's furthest from the sun). Anyone who's played Kerbal Space Program will know exactly what all this means, but if you're having trouble visualising it, here's an animated gif of the orbit of Halley's comet; note the increase in speed as it passes the sun.
Most orreries assume circular orbits, which isn't actually so bad an assumption for the major planets since they all have fairly low eccentricity. Hence to show the effect properly, I'm trying to model a comet. My initial thought was to model Halley's comet, but the eccentricity is so extreme (0.967) that I'm worried it would jam up rather than turning smoothly, so I chose Tempel 2, with a much more moderate eccentricity of 0.537. I've worked out a fairly simple way of tracing out the elliptical path using a modification of a Tusi couple , but creating a system for turning the mechanism at the correctly varying speed has proven to be quite a head-scratcher; the relationship between the input rotation (the Mean Anomaly in astronomical terminology) and the output rotation (the Eccentric Anomaly, which can be used to drive the Tusi couple) is given by Kepler's Equation, which is non-trivial to solve to find the Eccentric Anomaly. I won't bore you too much with the details, but after several months of tearing my hair out, poring over spreadsheets and writing increasingly complicated python scripts, I've finally managed to put together a rough approximation of a gear pair that should give the correct speed ratio:
Unfortunately, I anticipate this gear having (at least) one major problem - as the egg-shaped input gear goes from about 12 o'clock to 2 o'clock, it seems like it's in great danger of coming unmeshed from the apple-shaped output gear and leaving it behind. So I'm casting around looking for a way of keeping the gears meshed and turning throughout the cycle, and preferably in a way which will also allow the mechanism to run backwards. My first (and enduring) thought was to have pins strategically placed on the gears, and having an elastic band between them, so that there's tension in the output gear pulling it into that part of the cycle and keeping the teeth meshed. However, in order to be reversible, I think it'd need it to be at apex of the gear, which might result in it getting pulled back in the wrong direction. Plus, you'd have to drive the band to it's maximum tension at the point where the gear ratio is at it's worst, and I'm already a little concerned about the uneven input torque. An alternative might be to mount one pin on the output gear, and another pin on another gear driven from the input shaft, but rotating in the same direction as the output gear, so that it's always going to be pulling the gear in roughly the right direction.
I've also considered some other ideas, like having a set of circular gears driven by the same input, connected to the output by a pre-tensioned drive shaft that would be able to cope with the varying position of the output gear but would keep enough tension to have it chase the input gear when it's at risk of coming unmeshed; the big problem with that is that it's pre-tensioned, so will only drive the gear in one direction, and will tend to pull the gears free if it's run back.
I also feel like all of these solutions will necessarily mean that it will be hard to "pause" the orrery in a set position; the tension in the system will try to pull it (forwards or back) to a particular resting point, but I guess that's just something I might have to live with. Although another idea might be to have some kind of structure along the rolling line of the gears (i.e. the shape without the teeth where the two gears meet) and then have a set of rollers under tension to try and hold them against each other. I'm not sure how easy that would be to make, and whether it would risk catching or jamming the mechanism.
Again, if it's relevant, the technology I'll probably be using will be some form of stereolithography or laser sintering to make the pieces, so not as rough as FDM prints but also not as precise as hand-tooled metalwork.
Any other thoughts or suggestions? Problems with the solutions suggested? Obvious solutions I've missed? Other things that would make this kind of gear untenable?
