• I'm back...

    Matt Finch • 05/17/2020 at 02:28 • 1 comment

    Wow...I can't believe it's been 5 years since I started this project.  I'm tempted to write that "life happened" after that, but that's just an excuse for not finishing what I had started.  I'm not sure what got me thinking about the Clock Clock again, but here I am.  I'm going to see if I can pick up where I left off.  I still have all of the parts that I bought.  The code must be lying around here somewhere.  

    A quick browse around Hackaday shows that others were able to get this thing made.  I haven't looked into the details of their implementations, yet.  I'll use as much information as I can from successful projects to make this one successful as well.  I'm excited to see how their approaches differed from mine, as well as how they were similar.  But, I'm mostly excited about the prospect of having this project hanging on my wall instead of in my regrets.  This post is meant to serve as a public commitment device that will nudge me to follow through.   I welcome any advice.

  • ​​Getting Up-To-Speed

    Matt Finch • 02/11/2015 at 21:09 • 3 comments

    Intro

    ( Disclaimer: I'm no writer. I apologize in advance. )

    I'm going to try and post a log around weekly, if for no other reason than to ensure I attempt to make some progress each week between posts. This first entry will (edit: begin to) summarize what I've done to date.

    I am software developer with no prior electronics experience. Tooling around with these things is something I have wanted to get involved with for some time. When I saw the Clock Clock in action, I immediately thought "I have to make one of those". So, here I am. I understand that this project is ambitious for a neophyte, but I intend to take my time and see it through. Much of the time I have spent so far has been developing a basic level of understanding of the tools I intend to work with. (What is Ohm's law? How does this Arduino thing work? etc...)

    Then, it was time to think about the specific technical details of the project. I browsed around the web for ideas and I ran across Hackaday for the first time through the page that I've linked to this project, which was (lucky for me) a discussion about how to do exactly the thing I wanted to do.

    The Approach

    There are 24 clocks in the piece and two hands on each clock. My first concern was how to make the hands go around. I decided to use 48 small stepper motors ( the little 28BYJ-48 ) to drive them. My reasoning:

    • The steppers are cheap.
    • Continuous rotation is a requirement, eliminating all (most?) cheap servos from contention, as far as I can tell.
    • I figured I'd want to power down the motors in-between movements. Initial testing showed me that they have plenty enough torque to maintain their position even when they are not powered.

    After some quick proof-of-concept sketches, I went ahead and ordered 50 of the little steppers from China for less that $2 each with the drivers, partly because of the long lead time on delivery, and partly as a commitment device to encourage myself to get cracking on the project.

    I'll be controlling things with an Arduino Mega. I initially thought that I'd need the Mega to help handle all of the IO, but the extra pins may be moot.

    I'm still green and unsure about best practices for communicating with a large number of devices (unsure of everything, really). With that said, my current plan is to use a bunch of chained SIPO shift registers (74HC595). Since each of the 48 motors requires 4 pins to drive and each shift register has 8 outputs, I'll need 24 of the registers to drive all of the motors. Somewhat conveniently, each register can drive the two hands of one clock, so I'll probably put the registers inside the clocks with the motors. The whole chain will only use 3 pins on the 'duino.

    I have the software side of that sorted. I modified the AccelStepper library so that it would manage a collection of steppers and communicate with them through the shift registers. It will send the output values to all of the steppers at the same time, only once for each iteration of the arduino's loop() (or each time I want 1 or more of the steppers to take a step). The drawback to this shifting approach is that driving N steppers through the shift registers in this way requires ~3N digitalWrite() calls for each step. When I tested a sketch to tell the arduino to pretend that I had 48 steppers running it was initially very slow. However, including the DigitalIOPerformance library to improve the speed of each write has been a big improvement. I am confident that things are moving fast enough now, but I still have plans to integrate 48 inputs (which I will detail later). That may push the system over the edge back into tediously slow territory. In fact, my next bit of work is to test exactly that. If someone with more knowledge than I recognizes that shift registers are simply the wrong approach to take here, please let me know. I still have time to reverse course.

    This is running long, so I'll bore you with the rest of the technical details of my tentative approach in the next post.