Project Logs

Collapse

• Field Test Results

  Josh Cole • 07/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.

  Deployment

  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.
  

  Firmware
  

  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 Cole • 07/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
  updateShadow(shadow)
  
  shadow["alt"] = 0
  shadow["az"] = 0
  updateShadow(shadow)
  
  shadow["alt"] = 120
  shadow["az"] = -90
  updateShadow(shadow)
  
  shadow["alt"] = 0
  shadow["az"] = 0
  updateShadow(shadow)

  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 Cole • 06/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.

  Findings:

  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 Cole • 06/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