Final Project
For my final modifications, I added a bunch of different modes to my planet tracker. First, I allowed the stabilization to be turned on or off from the keypad. Next, I added a way to change the time from the keypad, so you’re able to see where planets will be at a different time. I also added a way to change the date, which can be used in tandem with the time-changing function to create a time machine, albeit one that can only be used for planetary observation. I then added a battery and a switch, which involved a good deal of working with circuitry. The battery, however, drains incredibly quickly, so in order to be more economically-minded I use computer power. I also added a laser pointer and a button that controls that. The biggest difficulty encountered was probably with the keypad input — in addition to the 3-digit codes used for settings, I added 1 digit codes for planets, and I needed to take 6 and 8 digit numbers for time and date respectfully. In order to do so, I expanded my makeshift password library — now, different keys tell it to accept different lengths, which are then used accordingly. I also added an indicator LED to show when the stabilization system is active, and a second one says when it’s getting a GPS signal. Lastly, I used a lot of electrical tape and shorter wires to make everything look nice and tidy.
Third Milestone
For my third milestone, I made a self-stabilization system, and I added an LCD screen and a keypad to make user interaction easier. I attached the MPU to my board, and I figured out how to write the stabilizing algorithm. Basically, I imagined the planet as a location on the surface of a sphere, with the altitude and azimuth angles being the spherical coordinates. The algorithm then converts those to three-dimensional Cartesian coordinates, which it rotates along the two axes of rotation. These coordinates are then converted back to Spherical, and the resulting Alt/Az angles are fed to the servos. I have the MPU taking a reading every 10 milliseconds, with every five readings being averaged and fed into the algorithm. The math behind this was fairly difficult at first, but once I figured it out the rest was straightforward. The main challenge that I encountered was that I had to essentially learn spherical coordinates on the fly as I was doing the math. I also encountered some problems with inverse trig functions not being able to recognize different quadrants (since cos135 = cos 225, the arccos of -0.707 will return 135 even though 225 is also a correct answer). I solved this by using absolute value for the trig calculations, and then once a first quadrant angle was obtained I figured out which quadrant an object was in and added/subtracted accordingly to get the right angle. I then added a keypad and an LCD, so now you can easily interface with the planet tracker directly instead of having to go through the Serial Monitor. The keypad also replaces the potentiometer, and allows me to add more than nine objects, so now I added a few constellations. The main problem that I had was that I needed to figure out a way to accept a multi-digit code from the keypad. I tried using a password library, but I wasn’t such a fan. Instead, I essentially wrote my own password library: my code adds every new key into an array, and when the array reaches a predetermined length it takes the code and checks if the code does anything.
Second Milestone
For my second milestone, I connected all of the hardware to my algorithm. First, I connected a GPS unit to get real-time location, date, and time values. I had some problems with the GPS because it wasn’t getting a signal indoors, so I had to sit next to the window or be outside in order for it to work. To get around this, I programmed default values for when there is no signal. I then had to attach the servos. I needed the bottom of the two servos to go 360 degrees, but the one I had only went 180. First I tried hacking that one to go 360 degrees, but the hack made it impossible to achieve the fine control that I needed for the planet tracker. Next, we ordered a 3-turn servo, but that one didn’t really work. As a workaround, I took two, smaller 180 degree servos, and I stacked them so they could go 360 degrees. I then configured the servos so that they went wherever the algorithm told them. I also hooked up a potentiometer that is numbered 1-9, and it’s used to select planets (1 is Mercury, 2 is Venus, etc.). Finally, I put everything onto a board of wood so that it looks nice, and when I add the self-stabilization I’ll need it all to be flat.
First Milestone
For this milestone, I completed the algorithm that plots where the planets will be in the sky. The first thing that the algorithm does is take the orbital elements of the planet in question and uses them, along with the date, to calculate where in its orbit the planet is. Next, the algorithm finds the heliocentric coordinates of both the Earth and the planet in question (Heliocentric coordinates are 3D Cartesian coordinates with the sun at the origin). The Earth’s coordinates are then subtracted from the planet’s in order to find the geocentric coordinates, or coordinates with the Earth at the origin. Once the geocentric coordinates are found, the algorithm adjusts for the Earth’s axial tilt and uses trigonometry to find where things are in the sky, measured in right ascension and declination. If you were to imagine a celestial sphere surrounding earth, with one circle parallel to the equator and another perpendicular to that running over the poles, right ascension is the angular distance between an object and the North-South circle, and declination is the angular distance between the object and the equator. Once right ascension and declination are found, the next step is to calculate altitude — the angular distance of an object above or below the horizon — and azimuth, which is the angular distance between an object and due North. This is done using the latitude, longitude, and time of the observer, along with a healthy amount of trigonometry. To demonstrate my algorithm’s accuracy, I plotted my results on a spreadsheet for observations made on an arbitrary date (AKA my birthday), time, and location (my hometown). As you can probably tell, the algorithm is very accurate, except for two values with a high percent error. One, however, only has a high percent error because the actual value is very low, and it is only off by 0.056 degrees. The other is very off, since for some reason the algorithm does not like Neptune. Overall, removing these two outliers, the average percent error is 0.12% (Alt) and 0.02% (Az), with an average difference between the real and obtained values being 0.041º (Alt) and 0.037º (Az). I’m very happy with this level of accuracy, and it should be more than sufficient going forward.
Starter Project
For my starter project, I built an LED scanner, which is essentially a row of LEDs that flash back and forth. The project is based off of a pre-programmed microcontroller, which contains the code that controls the LEDs. The microcontroller is connected to a button, which is used to change the speed of the back-and-forth movement and has three modes: slow, medium, and fast. The scanner also contains current-limiting resistors, which tone down the current coming from the batteries so that the LEDs are able to handle it (without these resistors, the LEDs would be fried). Additionally, the scanner contains a decoupling capacitor, which protects the LEDs from sudden power spikes. The power comes from two AA batteries, which are housed in a separate casing that I attached to the circuit board. In doing this project, I learned a lot about the various parts of a circuit and how they function. I also refined my soldering skills and learned how to desolder. The main problem that I encountered was that when removing a defective LED, the circuit board was damaged, so the new LED didn’t light up. In order to fix this problem I had to solder in a wire from another LED in order to bypass the damaged section.