A 3d printed, motorized, and hackable telescope base with star-finding capabilities built on a raspberry pi zero.

Similar projects worth following

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"

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:

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 :)


Eagle schematic for "pisolaris-zero" circuit

sch - 260.96 kB - 07/19/2018 at 03:11



Eagle board design for "pisolaris-zero" circuit

brd - 66.09 kB - 07/19/2018 at 03:11


  • 1 × raspberry pi zero
  • 2 × nema 17 motor
  • 3 × LEDs Electronic Components / Misc. Electronic Components
  • 4 × Screw Terminals (0.1" pitch)
  • 3 × Resistors for the LEDs

View all 13 components

  • Field Test Results

    Josh Cole07/16/2018 at 03:50 0 comments

    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 snag of 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!

    Star Finding

    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...

    Read more »

  • We are 'go' for mission 1!

    Josh Cole07/12/2018 at 01:26 0 comments

    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.

    Mission 1

    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!!

    Scripting test!

    Last but not least, here's a video of pisolaris running a script. The exact code looks like so:

    local shadow = {}
    shadow["alt"] = -120
    shadow["az"] = 90
    shadow["alt"] = 0
    shadow["az"] = 0
    shadow["alt"] = 120
    shadow["az"] = -90
    shadow["alt"] = 0
    shadow["az"] = 0

    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.

    Next steps

    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.

    Until next time, friends!

  • Off-by-one error

    Josh Cole06/30/2018 at 23:26 0 comments

    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.

    Cheers! Until next time.

  • Once more, without feeling!

    Josh Cole06/29/2018 at 03:51 0 comments

    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.

View all 4 project logs

Enjoy this project?




[this comment has been deleted]

Josh Cole wrote 07/12/2018 at 01:59 point

Hi @manta103g 

My firmware will (very soon, once I fix a bug) accept angles for both motors. This means I can tell it to do things like "rotate to 145 degrees vertically" or "90 degrees horizontally" etc. Because I use stepper motors and then add a further gearing mechanism on top of it, I am expecting reasonable positional accuracy.

With this kind of input, tracking celestial bodies should be doable.  I wrote a math library ( which is based on polar coordinates. It can convert "right ascension" and "declination" into "altitude" and "azimuth" coordinates. If you go outside and face north, then look straight up at the sky, your altitude will be 90 degrees and your azimuth will be 0 degrees. So from that "home" position, you can navigate to any destination that is in the field of view.

There is another repo I discovered which has many many celestial objects encoded in the polar coordinates.

Using the math library I made, the thought is that I should be able to convert any one of these objects into local altitude/azimuth coordinates at any given moment in time.

It's all very confusing though. The best resource I found which explains this stuff was actually a book (Astronomical Algorithms)

I hope this helps at least a little :) I'm not entirely sure what would be involved in tracking the sun, but I imagine it's similar conceptually.

  Are you sure? yes | no

Josh Cole wrote 07/19/2018 at 03:32 point

@manta103g I took a peek at my astronomical algorithms book, and it does have a chapter on solar coordinates. The algorithm is pretty complicated, but the astronomy math library I wrote already has most of the components necessary to implement it. Perhaps I'll give a go at updating my library to see if I can add sun tracking to it :) I will let you know if I get around to doing that!

All that aside, it looks like there is actually an algorithm with quite reasonable accuracy. But it has 10 separate variables you have to calculate in order to derive the correct position.

  Are you sure? yes | no

RandyKC wrote 06/30/2018 at 02:31 point

This is awesome!

Having a network of these scope around the globe could be very useful for NEObject tracking.

Feedback:Both of your mounts(base and scope) don’t look balanced. This will cause friction and the “grabbing” I think you were describing. For the base a counterweight would do. For the scope body maybe just a bearing mount on both sides in a “Y” mount? Again a balanced scope will move easier.

  Are you sure? yes | no

Josh Cole wrote 06/30/2018 at 07:34 point

Thank you!! I really appreciate the feedback. 

I've often thought about the merits of having a counter weight because you are absolutely right, it would greatly simplify the stability. I will think more on how to incorporate better weight distribution to fix the center of gravity.

I'm avoiding the notion of having a second y-axis mount (at this time) because I get the first one for "free" with the natural design of the telescope, but adding a second one would require a whole other level of design. Currently I'm banking on the fact that this particular scope is very lightweight. But then again, the perfectionist in me really hates knowing that the center of gravity (no matter how lightweight) is so far off to the side, hah :)

  Are you sure? yes | no

RandyKC wrote 07/01/2018 at 01:11 point

I wonder, if you mounted the tube of the scope between the uprights and put the whole drive mechanism inside the uprights your balance issue would be much easier. Then you could move the axis of the base to where the crosshairs meet at the base. It would make your geometry easier as well since you wouldn’t have to calculate the offset from centerline.

  Are you sure? yes | no

Mike Szczys wrote 06/29/2018 at 14:07 point

Wow, looks great. Well done!

  Are you sure? yes | no

Josh Cole wrote 06/29/2018 at 14:52 point

Thank you!! 

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates