No, we're not talking about hiding in bushes with long zoom lenses waiting to see what Tom Cruise is wearing today...
Like many people on Earth, I love stargazing and imagining all the possibilities that lie in the vast expanses of the universe. As a gearhead, tech nerd and maker I have taken that fascination and tried to express it through astrophotography. Until recently, I've been able to get increasingly clear, bright, and awe-inspiring shots just by improving my technique using tools I already have. Now, however, I have encountered a new foe: physics.
There's a lot of physics going on when you look at the stars. Fusion is releasing huge amounts of EM radiation from distant clumps of gas. Those waves travel through the vacuum of space, are bent by gravity, dispersed by vast clouds of gas and illuminate countless worlds. Our planet rotates on an axis while orbiting the Sun, which is caught in a milky whirl pool that floats lazily amongst trillions more. It's all quite messy, really!
Most of that stuff doesn't matter for astrophotography because exposures are typically short - from a few minutes to a few hours. The translation of the Earth over that period does not change the appearance of the sky, but one thing - the Earth's rotation - has a huge effect.
A lot of photons are needed in order to capture an image of a faint object in the sky. That means a lot of time spent photon-hunting (or gathering, whichever you prefer). And with the Earth spinning right round at 360 degrees per day, it won't be long until your star is smeared right across the image. This became my limiting factor, so I decided to build a solution.
Star trackers are devices used to counteract the rotation of the Earth so long-period observations of the sky can be performed. The concept is simple: make a platform that rotates against the Earth at the same rate. Designs for star trackers range from Ford Pinto to Rolls Royce, and there are plenty of resources online about how to make your own. My design is of the "barn door" type, and is inspired by these projects: Makezine: 6 DIY Star Trackers for Perfect Night Sky Photos
In my build I add positional feedback so that the tracker can correct its motion over time - allowing (in theory) for increased precision.
Usually my projects don't have a complicated mechanical aspect, but this one sure did. It was a good opportunity to try out some of the new robotics-focused parts that SparkFun offers like gears, axles, hubs, bearings, motors and encoders.
Here are the SparkFun parts that I used:
Two changes to this list are as follows:
I chose the RedBoard Artemis Nano for its small footprint, great support for interrupts (for the encoder) and, admittedly, because I am fond of it. To drive the motor I decided to try out the Qwiic Motor Driver because it would be easy to hook up and get going.
I also needed a few miscellaneous pieces/parts from a hardware store:
Figuring out how exactly to mount all these parts so that the gears would mesh correctly was perhaps the most challenging and time-consuming part of the project. I ended up making some rough 3D models of the main components and assembling them using OnShape (a very cool web-based 3D modeling application). Here are the public design files:
I tried to dust off some old carpentry/fabrication skills and more or less discovered that dust is all they were to begin with. That being said here was my general process:
To build barn doors:
To build the drive mechanism:
To make the drive rod:
Though currently a work-in-progress, I plan to continue updating this project on GitHub: StarTracker.
Star trackers of this style don't necessarily even need software - a simple voltage regulator to adjust the motor's speed is often enough. In this case, however, I wanted to have a little fun and aim for high precision/reliability. For me that meant adding a feedback loop.
Earth's rotational rate is very stable (over the periods of time used to expose film for astrophotography), so you might wonder whether a control system is really necessary. In an idealized case you could set a motor off to do its own thing and it would also run at a constant rate. Any mismatch between the rate of the motor and the Earth's spin would be a constant error and stack up over time predictably. In fact, if you could get that difference to be small enough, then one could effectively hide it with other techniques (such as image stacking).
What happens when dust/dirt clogs up the system? When the battery voltage sags in cold weather? When a heavy camera/lens combination strains the drive system? In those cases there may be error that changes over time and is much harder to predict and account for. Covering these scenarios is what an active feedback loop does very well.
This time, as the overall position error increases, a proportional "restoring force" is applied to bring it back to zero (in practice this means changing the speed at which the motor is set to run). You can see that the error now oscillates around zero rather than growing infinitely. This is good, but we want the error to settle down to zero - that's where derivative feedback comes into play.
Finally, the error is controlled to zero. This is done by adding a "force" that counteracts motion toward the target.
Overall this was a fun way to combine my interests in astrophotography and control systems. The role of the latter in this project deserves a much more in-depth and precise examination, but it had to start somewhere! Hopefully this rig will be out there tracking stars very soon.
I'm also using a stepper with an Arduino 2560, and a ramps board with a TMC2130 stepper driver. The ramps board plugs into the mega like a shield, so everything connects together solidly. However, I'm running it on my telescope, with an EQ-2 mount. All that I need to provide is a steady pulse stream.
I was looking at your code to see how the encoder was going to be used. I noticed in the comments that you were using 86,400 seconds as the length of a day. While true, this number doesn't account for the Earth revolving around the sun as well. This means that the earth turns an additional 360 degrees in ~365 days, nearly one degree per day. Therefore, sidereal time needs to be used to correlate the speed of the stars relative to the earth. A sidereal day equals 86164.0905 seconds per day, not 86,400. Here's a link that explains it way better than I can. https://earthsky.org/astronomy-essentials/what-is-sidereal-time
Aha! Yes, sidereal time. I have some major plans to keep refining this project and that will be one of the improvements. Thanks for mentioning it! (I'll even go make an issue on GitHub to help me remember)
Looks like a fun project. I'd like to point out that using a stepper motor with the appropriate gearing is a lot easier than an encoder and just as accurate without a lot of trial and error. It also costs less. I used an Arduino Nano, a little reprap style step stick (TMC2208 for super smooth stepping) and a custom PCB to tie it all together.
The biggest hurdle I had was finding a way to gear the curved threaded rod. Using 3D Printer belts and gears turned out to be easy. I was able to press-fit a bearing onto a timing belt pulley that I tapped for my curved rod. In the end, it turned out pretty good.
By the way, you will need a sight to be able to align the tracker with Polaris. This took far more head scratching than the gearing problem. I wound up CNCing a mount for a standard telescope spotting scope. Far more accurate than the straw method once properly aligned.
Thanks Phil - I considered using a stepper motor but chose the gearmotor / encoder for a few different reasons: 1. Mainly was interested in using a high resolution encoder since I haven't before, and so that I could potentially apply it to robotics applications in the future 2. Even with microstepping and large gear reductions I was slightly disturbed about the idea of discrete steps shaking the assembly. These are probably totally unfounded fears but hey, they influenced my decision.
I'm hoping to get one of the nice polar scopes that has an etched reticle to account for Polaris' misalignment with the true axis. I'd also like to use a better hinge with less slop, so at the same time maybe I can find a way to make the scope and hinge axis truly coaxial.
Your solution for the rod sounds interesting. Do you have pictures anywhere that you could share?
Check out the double barn door tracker by Dave Trott. Mechanically a little more complicated but it is more accurate (or is it precise?).
That is really neat, thanks for sharing! (Here's Dave Trott's Double Barn Door video) In theory this barn door solves tangent error completely by using the circular bend in the threaded rod. When it comes to actually bending the metal reality sets in and I'm not sure how significant those bending errors will be in the overall accuracy.
I'm looking forward to seeing a picture or two of the completed tracker...
Great point! Somehow this slipped past me. I just added a photo after the HW build instructions. I will definitely be giving it another go at some point - it turned out to be quite challenging to align those gears by hand.
One other minor point: what forms the hinge between the two doors? From the picture it looks like maybe some electrical tape, but I'm not sure. (I'm a tad bit surprised that a hinge isn't included in the stuff from the hardware store.)
Bingo! It's a simple 3" door hinge. I'll update the article. Thanks for catching that!
I'd like to share a possibly relevant idea. About 20 years ago a friend was tinkering with a microprocessor control for a telescope, and needed to communicate certain info to the user (typically a very simple message that could be represesnted by a single letter). Clearly, an LCD or LED readout was not appropriate, as it would affect "dark vision". He was thinking about a buzzer with a series of "long"/"short" buzzes for each possible message. I suggested to him that he make the "long"/"short" sequences standared Morse code for appropriate letters -- if you already know Morse code, "short-long-short" is easily identified as "R", and since he only had a handfull, if you didn't already know Morse code you could quickly learn to recognize it (in the dark) as the controller's signal for, say, "Right".