Project Logs

Collapse

• After 4 months, heaxgon wall is finished!

  Josh Cole • 04/14/2019 at 16:12 • 2 comments

  It's hard to capture the actual look and feel of this thing because in photos it comes out as a super vibrant blob of color. Which is pretty awesome, honestly. I finally finished piecing together everything, hot gluing it all, designing/printing some wall-mounts, and all that jazz. Detailed build instructions to come soon.

  Here are some thoughts for v2 / postmortem

  • Things that went well
    • Part interfacing. This worked, on average, surprisingly well. The faceplate connecting with a friction fit mechanism to the hexagon with enough slack to sandwich on the clearish insert - that was actually pretty awesome.
    • NodeMCU. My first time using it and wowzer, I've already bought a few more to have on-hand for future projects. The ease of accessing WiFi with it is definitely going to open up a whole new world.
    • Hot Glue. It's a hacky solution, but I've never seriously used hot glue in any project before. Mind=blown. Worked phenomenally for this.
    • Inside rail for wires. I didn't even have to iterate on that, it worked as expected.
    • Wall Mount.
  • Things to improve for v2
  • The snap-fit mechanism between each hexagon was not really that great. It was fun to design, and my finalized part did snap together. But it was physically painful to do so 80 times :-P next time I'll be sure to get that perfect before moving on.
  • Molds? Someone mentioned I could have made a silicone mold from one part instead of re-creating the same one a million times. This is definitely an interesting thought! I'd love to explore that next time.
  • Hiding the electronics. Although I think the solid black hexagon gives character, it's also visually jarring. I could have hidden the electronics without it.
  • Sensors?? Stretch goal! Would be awesome to have some kind of interactivity here.
  • Slimmer profile. I believe it can be achieved.

  What a journey! I'm really happy with how it turned out.

  As a bonus, I also made a tiny one for my desk at work.

• hcode

  Josh Cole • 03/17/2019 at 19:04 • 0 comments

  I began thinking about how I would make the hexagons change in-time to music. I quickly realized that in an ideal world, I would be able to generate a script which - if executed at the correct time - would apply time-based effects to hexagon units which synchronize with whatever song is currently playing.

  In order to prove this concept, I prototyped "hcode". Which, yes, is very very loosely based on "gcode" (the script for controlling 3d printers and cnc machines). I say very loosely because hcode only has 4 commands and pretty much has zero crossover with gcode except at the highest of levels. But the one takeaway from gcode which inspired this whole thing is the concept of interpolating variables over time. That is exactly what I need to do, just instead of controlling motors I'll be controlling the color of an LED strand.

  Here's how it works...

  There are two types of commands. Instantaneous and temporal. Each line in a script starts by identifying the specific subroutine and then specifying the hexagon index it will apply to. Lastly, you can specify the parameters needed for whatever routine you are invoking. 

  For each hexagon, the list of commands which impact it are collected - in order - and the "start time offset" is computed based on the duration for temporal commands. In this way, the interpreter can "play" the script and know exactly which command it should be at, for any given point in time.

  Here's the table of supported commands:

  Command	Effects	Arguments
  H00	Turn hexagon on/off	{index} {truthy value}
  H01	Delay	{index} {milliseconds}
  H21	Transpose RGB over time	{index} {target R} {target G} {target B} {duration}
  H22	Set RGB	{index} {R} {G} {B}

  So an example of making the first hexagon blink red 3 times.

  H21 0 255 0 0 500
  H21 0 0 0 0 500 
  H21 0 255 0 0 500
  H21 0 0 0 0 500 
  H21 0 255 0 0 500
  H21 0 0 0 0 500 

  It's quite verbose, but it also works really well for generating effects.

  The challenge with this design
  

  Two major things make this a bit of a headache. The first is that the NodeMCU controller which I am using does not have a lot of memory. So generating an hcode of sufficient size is impossible. Some solutions to get around that - chunk the file and apply it a few commands at a time. Or... use a raspberry pi :-P

  Another challenge I ran into is that analyzing the beat pattern for music is actually incredibly, frustratingly complicated. I'm still researching the best way to achieve this part of the system.

  But overall, hcode seems to work great. I wrote a little prototyping website where I can test out hcode and see what it would theoretically look like IRL.

• Nearing the final leg of this adventure

  Josh Cole • 03/17/2019 at 18:26 • 0 comments

  Hey all! I've been busily printing printing printing over these past few weeks. With nearly 80 hexagons completed, I have decided to adjust the scope of my final goal. Originally I envisioned a whole entire wall made out of these things - but with some triple checked napkin math, I realized I would need to produce 500 units... Which will take many months of additional time. That being said, the more hexagons I acquire, the more I'm convinced an entire wall will just look gaudy.

  Imagine instead a wall with these hexagons arbitrarily linked together to form either some meaningful shape (like the representation of a chemical compound) or just scattered about in a visually appealing way. After arranging a number of the hexagons together, I started toying with possible patterns beyond just "a solid wall". I'm really liking this direction and it also means that I can start finishing up this project sooner. Here's an example of what a random distribution could look like.

  Once i wrap up the additional 36 hexagons that I've got in the queue, I will be finalizing the shape and then putting it all together!

  More updates to come soon. 

• Quick update

  Josh Cole • 02/20/2019 at 07:04 • 0 comments

  I just wanted to share this quick update. Behold! An end to end implantation of my design. 

  All files have been uploaded to this project page, however, I may make some modifications as I iterate things just a tiny bit more.

  Mounting the lights inside is a bit unrefined. I'll update that a bit, however, I'm very pleased with how this is all turning out!! 

• Lights over WiFi!

  Josh Cole • 02/11/2019 at 03:18 • 0 comments

  In between the prototyping and the 3d printing and the sleeping, I've been working on an API to control the lights remotely. I may have gone a tiny bit overboard with the amount of features I ended up supporting, but I think it will be worth it.

  You can find all the code here: https://github.com/SharpCoder/wifi-neo-pixels

  (I'm working on documenting my code and adding a README. It'll be there eventually).

  Here is what that code gets you:

  • LED Management
    • Modes
      • The concept of "modes". You can think of a mode as sort of like a shader in video games. It is a bit of code which will execute each cycle for a given LED. Each LED gets some persisting contextual information about itself as well as the system in general.
      • I ported the Adafruit "Rainbow" code into one mode.
      • Added a "Pulse" mode which is basically fade in / fade out.
      • Added a "Blink" mode which - afaik - doesn't work for some reason. It's not that cool anyway...
      • In addition to these core modes, it's easy to write more. All you need to do is implement a straightforward interface and the sky's the limit!
    • Individual LEDs
      • You can set the color (r,g,b) for an individual LED
      • You can turn an individual LED on or off
      • You can adjust the delay with which the LEDs mode will be invoked
    • System
      • You can adjust brightness of the whole strand
  • Web API
    • Supported Routes
      • /led/{index}/color/{r}/{g}/{b}
        • Set individual LED to a specific color
      • /led/{index}/visibility/{value}
        • Set individual LED on or off
        • Value is numeric. 1 for on. Anything else for off.
      • /led/all/color/{r}/{g}/{b}
        • Set all LEDs to a specific color
      • /led/all/visibility/{value}
        • Set all LEDs on or off
      • /system/brightness/{value}
        • Set the brightness for all LEDs on the system
        • Value is a number between 0 - 255 inclusive.
      • /system/mode/{mode}
        • Set the mode for a whole strand. Modes include:
          • Rainbow
            • From the Adafruit NeoPixel example code
          • Blink
            • Blink on and off
          • Pulse
            • Fade in and out infinitely
          • Default
            • Solid color

  The device I have this running on is an ESP-12E (Node MCU). I picked up a 4-pack for a shocking 19$ USD. I'm pretty shocked at how cheap these things are because they seem to be amazing so far for my needs.  (Find them here on Amazon)

  Anyway, I'll conclude this update with a brief explanation for how to use my code.

  Step 1  - configure the port / SSID / password

     This is done in the file webServer.h - at the top, you can tweak the #defines.

  Step 2 - That's basically it. Just flash your 8266-compatible arduino (with supported Adafruit NeoPixel and relevant esp8266 libraries included) with my .ino file and the modifications made to the #defines and you should be up and running!

  As soon as your board connects to the WiFi, it will stage a server and expose the routes that I have listed above.

  I can't wait to see the neo pixels actually mounted to some panels! That's going to happen very soon. Stay tuned! 

  Here is a silly, uninformative video demonstrating the neopixel lights changing color as I click things on my browser.

• Snap-Fits in 3d! (a bazillion ways not to do it)

  Josh Cole • 02/09/2019 at 18:07 • 0 comments

  After printing a few more hexagonal pieces, I quickly learned that joining them with bolts was simply unsustainable. Aside from physical injuries due to pieces snapping when I can't get them positioned just so, I realized that snap-fits are something I haven't tried before. So this seemed like a great opportunity.

  If I wrote a story about this, it would be titled "a bazillion ways not to snap-fit". But that's how we learn, right?

  I started firstly by reading everything I could on snap-fit joinery. A lot of it seemed unapproachably complex, and also technically difficult to get right. These are a few of the resources I pored over:

  • How to Design Snap Fit Components
  • How to Design Snap-Fit Joints
  • Plastic Snap-Fit Joints
  • Snap-Fit Design Manual

  
  

  A few things which didn't work

  My initial test included trying to create a cantilever snap-fit mechanism. Which appears to be a traditionally accepted approach to joining plastics. Unfortunately, this failed miserably for me. In addition to the tolerances being too multi-dimensional for me to iterate over reasonably, I also discovered a very important side effect of the hexagonal shape...

  Hexagons need to be able to seamlessly join along multiple faces at once.

  In addition to that fact, I also realized that any extrusion along the outer surface of my parts will add further complexity to the final shape. In order to get the insert and receiver faces to mesh correctly, I found it much easier to design joints that connect inside the wall of the part.

  All these findings led to the following rules:

  • The joint mechanism / receiver cannot extrude anything beyond the maximum wall thickness unless it's going to be fully enclosed within the part.
  • Alternating receive / join inserts does not seem to be possible, due to the geometry of the part
  • Tolerances must be really tight

  Here is an example of one prototype which does not work. It violates pretty much all the rules. Because the wall thickness is not 100% consistent between the insert and the receiver faces, if I were to connect multiples of these together, there would be a triangular space between each edge which looks really unprofessional.

  But that could never happen because it also violates the second rule :-) so connecting too many of these together is physically impossible.

  I realized that a rail system like this is nice in theory, and the tolerances did get to "snapping together" stage. But the shape of the faces and the inconsistent extrusion needed to make this work led to an unsuitable prototype. I decided to go back to the drawing board...

  Something which did work
  

  With all those findings in mind, I decided to look at how people solve this problem on thingiverse - just to understand the general geometry required.

  The design which really helped me understand what a solution might look like came from this particular print: (thingiverse) Hex Stackers

  How they solved the geometries problem was to enforce a rule:

  • All inserts must point down. All receivers must point up.

  That simple rule makes thing so much easier. If you follow that pattern, it's fairly easy to join hexagons provided you have some kind of mechanism for doing so.

  The conclusion
  

  After many prints tweaking tolerances (in 0.05mm increments...) and a few iterations on the shape of the inserts, I came up with a working piece! The current prototype looks like this:

  And so far it is working quite well! I will continue to iterate a few more times and then I think I'll finally be ready to mass-produce the hexagonal tiles.

  (Apologies for not recording in the proper wide-screen orientation :P I always forget to do that...)

• Designing an LED enclosure

  Josh Cole • 02/05/2019 at 06:33 • 0 comments

  This morning, I started the day with a basic vision for what I intended the final faceplate to look like,. My next logical step was to prototype said faceplate and then design a way to mount LEDs to the translucent bits so the light can be diffracted evenly. I really wanted to get a feel for what this thing is going to look like in its final form.

  As a courtesy, let me just point out right now that I am deciding to not use my custom LED enclosure as a final solution. Instead, I'll be sourcing the NeoPixel strand from amazon, as they come pre-packaged in a format which is exactly what I was trying to design myself... www.amazon.com/gp/product/B01AG923GI/ref=ppx_yo_dt_b_asin_title_o01__o00_s01

  That being said, I did not discover this gem until I had already designed my own solution :) read on for more details about the home-made variety.

  My LED enclosure goals were as follows:

  • For now, let's just support a 2-pin LED. If this works, future me can go ahead and figure out how to make it work for the NeoPixel 4-pin model.
  • The design should be 3d printable, like all my other components.
  • Ideally the construction process should be as simple as possible.
  • Lastly, this enclosure needs to interface directly with the light diffracting shroud so that I can accurately position the light source.

  With these design constraints in mind, I first set about measuring the LED and coming up with a bare-minimum chamber necessary to enclose a 5mm LED. 

  (as an aside, after a failed attempt to solder a wire directly to the LED leads, I took this opportunity to agree with myself that the design should be built around the concept of attaching jumpers to the leads and then locking all that stuff in place, probably through friction)

  The only remnant I have from that design session is an awful drawing which I won't bother to post. The dimensions that I derived included the following:

  • The LED has a little ring around the top which can be used to secure the bulb in place. This ring is 5.4mm +/- 0.1mm tolerance
  • The bulb itself is 5mm +/- 0.1mm tolerance
  • The final length of the leads should be around 13mm

  The last question I had was what interface I might use to plug this LED into the translucent panel. So for that, I decided I'd just use square pegs at 3mm X 3mm X 5mm , one in each corner. No tolerances. It's... definitely a "one way door". Once this thing is installed, good luck getting it out :-P But we're here to prototype, not dawdle.

  The full dimensions for the part ended up being 12mm X 25mm.

  Taking all these observations together yielded the following design.

  Okay, it didn't immediately yield this design. I had to iterate a few times before I landed on this particular shape. I'm sure it could use further improvement, but shockingly, it actually worked as I intended!

  After making a quick modification to the light diffraction panel, I was able to create the reverse interface for these square pegs. The final result? (okay the part in this picture has a little side handle not shown in the design above. It was a further iteration which ended up not being useful, so... disregard that)

  Aaaaand then I discovered the pre-built one from Amazon :)

  c'est la vie
  

View all 7 project logs