This is the project page for pisolaris - a thing I've been working on for about 2 years now. In short, it is a programmable telescope made accessible by the fact that almost all the parts are 3d printed. Although it's photogenic, there is still so much to do before I can enter phase-2!
I have many ideas for expounding on this technology and hope I will be at a point to pursue some of them in the near future. Imagine a world where kids (and adults!) can get DIY telescope kits and learn the basics of astronomy + programing. Imagine an array of telescopes, each with a separate lens attachment allowing you to perform various types of photography or science. Imagine writing custom software to detect near-earth-objects. These are just some of the possible directions I can go with a completed pisolaris.
Feel free to follow along with this journey to change the future of astronomy and education all at once :)
Pisolaris is a 3d printed telescope platform designed specifically for the Celestron "First Scope" http://a.co/4xyHqx0
Although I have not released the STL files, I am planning on doing so in the near future once my iterations become more stable.
In addition to making a motorized telescope base, I also wanted to write my own star finding software... which I have done, in theory :) You can find the math library I made on this github page: https://github.com/pisolaris/astro-math
The general concept for star finding is to first develop firmware which can accept destination angles and translate those into motor steps. Then develop the software which can take the current time + gps coordinates + target celestial body and translate that information into angles for the firmware.
At this time, my firmware is not public because it uses AWS IoT and I do not have a good way to provision new telescopes with the current software stack. Making a version of the firmware easily accessible is on my to-do list though.
Stay tuned as I plan to release files soon! I'm nearing a stable iteration which should be good enough to begin sharing complete build instructions :)
Hello everyone! This weekend I took pisolaris out to my friends summer home in the middle of nowhere for a field test. It had internet, clear super dark no-moon skies, lots and lots of stars. The perfect environment for our first voyage!
Yeah, pisolaris dwarfs in comparison to my friends nebula-seeing 12" dobsonian telescope. But at least I had the ability to track stars automatically :)
My project performed admirably and it was a really fun experiment, but I had many takeaways. Let's break down each major component with a detailed explanation of what worked and what could be improved.
This was the first time everything was in a more-or-less polished and finished state. So having the motor cables covered with a cable wrap and plugged into my custom raspberry-pi zero hat mounted seamlessly into the base... It looked great and there was no fuss with the electronics. This is definitely a win!
All you need to do is plug it in to a power bank of some kind and pisolaris will automatically connect to the internet. Which brings us to the very first snagof this field test... Internet connectivity!
Using AWS IoT is all great and well. In fact necessary for most of the things I plan to do with pisolaris as part of phase-2. Unfortunately, relying on internet connectivity to simply use the telescope is a huge disadvantage. Technically the firmware should not require internet connectivity, but then actually sending commands to the telescope will become very cumbersome without some kind of interface device.
A few ways to solve this:
Have a bluetooth mode
Make pisolaris a wifi hotspot that you can connect a laptop to
Still rely on network connectivity but instead of requiring internet, just use a local protocol or web interface if there is no external access.
I am honestly leaning towards bluetooth right now. I think controlling it through a tablet or any kind of portable computer would be a great boon for anybody as it provides a large amount of flexibility. But what exactly that looks like is still up for debate.
The day before my field test, I found the "sweet spot" of necessary offsets in order to correctly calculate the amount of steps needed for any given angle. In the field, this totally seemed to work. I was able to issue angles and pisolaris would very consistently navigate to them. My only question is - were the angles actually correct? Eyeballing it, they seemed to be more-or-less accurate. But I am going to work on developing a more scientific method for measuring the rotational position. This will greatly assist in debugging any star-finding problems and help verify the authenticity of the final position.
There was a minor problem on that first day of testing which I quickly fixed. If my horizontal position was 0 degrees and I told it to go to 359 degrees, pisolaris would make a near-complete circle to arrive at that destination angle instead of simply going backwards by 1 degree. With that fixed, the movement was exactly as I expected and quite consistent. Yay!
I have not discussed this mechanism much, so let me describe how it works. With the telescope setup to accept angles and translate those into motor steps, theoretically you need only figure out which angles a given celestial body is currently at, then issue that positioning information to the telescope.
To achieve this end, I wrote a little utility where I can query a database of stars and use some math + pre-recorded gps positioning to calculate instantaneous "altitude" and "azimuth" positions which, in theory, correspond to angles along both of my telescopes axis.
In all cases, it was generally off by a few degrees when I told it to navigate to a specific star. I was absolutely thrilled that it was only a few degrees, because that means it's got to be doing something right! But that's not quite good enough, so I will need to investigate this further. There are many possible sources of...
Hello new and old followers alike! I've got a mega update for y'all. In this update you will see the video proof-of-concept for the scripting engine as well as finalized wiring of all components. I'll also share some pics of the revised circuit board.
I'm going to take pisolaris out on a "field mission". This weekend I'll be going to a friends summer home in the middle of nowhere and I plan to tote #pisolaris along with me! This deadline gave me the motivation I needed to push really hard for wrapping up the loose ends of this first prototype. I'll be sure to provide an update with initial findings.
Oshpark board - v0.2!
The first board that I designed had some major flaws. Through-pin holes were too small and even some connections were completely backwards... So I dedicated a lot of time to make sure I got it right. Sent out my Eagle boards to oshpark and bam! Here's what it looks like, all soldered and working. pisolaris-zero version 0.2!
And what's even better? This beauty works!! All that planning actually paid off.
Horizontal movement dilemma
In my previous log, I had mentioned the woes of horizontal movement issues and trying to figure out how I should attach the drive pulley to the main shaft. Well the solution turned out to be rather simple and it's not what I want to do forever, but it works enough at the moment. I grabbed a D-Shaft and printed all the holes just a smidge too small which helped keep everything nice and snug. That pretty much was all I needed. It's infinitely more secure than any previous attempt I had made using bolts and what not.
I'm sure it will degrade over time but that's a problem for another day :)
Vertical motor-mount component
I went ahead and did a minor redesign of the vertical motor-mount component so it no longer uses threaded rods. This increased the vertical stability by... a lot. It kinda looks ugly, but I have some plans in my mind for creating an outer ''vanity" shell to hide the unseemly reality of how it all clicks together. It's so exciting that I can finally think about the polish of some parts!!
Last but not least, here's a video of pisolaris running a script. The exact code looks like so:
It's lua code and I'm still working on the final definition for what globally accessible functions will be exposed to the scripting engine.
Worth mentioning that these are supposed to be angles. Right now the step-to-angle ratio has not been fully defined so that's why it doesn't look quite right in practice.
I'll be fixing the step-to-angle ratio issue tonight, then doing a field-test on Friday with software tweaks as necessary. The next major kind of iteration that I plan to do will revolve around fixing that oh-so-minor jittery thing the motors do and then doubling down on finding out just how many steps I can get out of one of these nema-17 motors.
A lot of things have happened in such a short amount of time. The most exciting is that my oshpark boards arrived!! But as the title suggests, there is a minor problem with the through-hole size for the two stepper drivers... Which coincidentally were the only components I made custom footprints for :abashed: That being said, I should still be able to get this all soldered together for prototyping purposes :)
Ok it wasn't actually off-by-one. It was more like 0.5mm.
Also I realize that I completely missed out on the opportunity to add trendy silkscreen text. I guess the v0.2 board will be my grand stage for circuitry art.
A challenge for another day however...
Today, I am actually spending my time on prototyping a new base design which allows for "adjustable" belt tension. It uses the advanced technique of "jamming a bolt against the motor so I can adjust the distance"... Not something I plan to use as a final design, but it should help prove once-and-for-all whether the belt tension is actually the source of error in overall accuracy problems. Huzzah!
*6 hours later*
The new base design finished printing!! It didn't work out like I thought, but it provided me some valuable insight and a new direction.
The belt causes tension in weird places. If it is pulled tight enough, the whole assembly bends awkwardly. This is of course fixable with more infill and stronger designs, but I think it is unnecessary and can be vastly simplified by simply driving the gear directly - sans pulley.
Edit: I will have to prototype this concept but I'm no longer so sure it is "better". There are some advantages to the belt driven mechanism which I would miss out on. Primarily among them, belts seem easier to mount and setup. But it's something to think about. My next update should be all about how this problem is fixed and no longer a thing to worry about.
Last night I was finally able to piece together my most viable prototype yet. It was so viable that I also got a chance to test out my firmware code! Many bug fixes later, I was greeted by this awesome display:
The problem I'm currently running into is that both motors experience too much friction and therefore aren't producing consistent steps. I believe the friction coupled with loose belts causes the stepper motors to essentially skip arbitrarily. I'm going to tackle this one axis at a time. After some brainstorming this evening, I have a plan to solve horizontal movement so I will be prototyping some new components within the next few days.
Many good things happened too! For one, the fact both motors are running at the same time proves that my molex power supply is capable of handling the load (previously this was purely hypothetical). And today, my custom oshpark boards shipped!! It's my first time designing a circuit board, so I'm taking bets as to whether it works out of the box or not :)
Another great win is that my firmware is more or less working now. Yesterday I added a bunch of parallelism, bug fixes, and math - all of which culminates in the ability to send the telescope an angle for each motor and it calculates that into delta steps for the motors while keeping track of current state and updating an AWS IoT device thing. Currently I am implementing the ability to send .lua scripts to the telescope which have full control of the "device state" and can execute AWS Lambda functions for online processing of information.
I'm really excited with how things have turned out and will keep y'all posted as I make more progress on fixing this gear friction issue.