Hilbert Curve Desk Toy (Part 2)

They say the last 20% of the work takes 80% of the time.

Getting this thing to work was BRUTAL, mostly on the firmware side. In the last post, I talked about how I needed 3 functions in the software: flip, rotateCW, and rotateCCW - easy enough, right? I think by the end of this, I went through 4 full rewrites of my code and in the end, my final firmware is only around 130 lines. The saga begins with my trying to procedurally code the path for the ball, starting with mapping out the fractal.

I started out trying to create a sequential path using the Lindenmayer system representation which is

A → +BF−AFA−FB+

where + is turn CCW, - is turn CCW, F is move forward, and A and B are ignored. This was my first time using Lindenmayer systems so implementing the movements based on it was tricky. At several points I gave up on using this system and convinced myself it would just be easier to map the pattern myself. Pages of senseless scratching later, I was no further than I started.

Eventually I was able to generate an array of segment directions in a N/S/E/W format with respect to a reference side. I ended up going toward cardinal directions to try and move towards absolute positions that I thought might be easier to control in the firmware (that was a wrong assumption too).

To sequence the movements I just read the next value in the movement queue array, and made the appropriate movement corresponding to the value. Now the problem with this, is the absolute positions don’t jive with the AccelStepper library. Take for a example situation where East = 0, North = 1, West = 2, South = 3, my current position is 3, and I’m moving to 0. Because I’m using absolute positions, instead of rotating 90º clockwise, it runs 270º counter clockwise which causes erratic ball behavior. Given that, I had to switch to relative movements where I would compare the current and queued position to decide which direction to drive. This opened up a whole bunch of logic that ended up being much more confusing to implement than I thought. In the end my program ended up going from 50 lines in the first iteration (that didn’t work), to 400 lines (which also didn’t work), to 130 lines in its final working condition.

The final form of the code has a complete move queue array with movements going to the endpoint and back. The positions are set on the diagonals of the 4 sides (this helped the ball not get stuck on certain corners) and I added in some plant delays which I think make the movements more interesting. I also redesigned the look of it and moved towards a cleaner design where the maze lifts in and out of plane with the box. I whipped up a quick PCB with an Arduino nano, some power and motor I/O’s and a leftover stepper driver from my blinds project.

With the electronics wrapped up I’ll be putting together the full build guide and posting it shortly.