Forrest O. Interactive

Tactile Labyrinth

2025-06-10T00:00:00Z

Presentation

presentation.mp4 – on the fabacademy.org archive
presentation video mirror – on youtube

Inspiration

One definition of labyrinth is a winding path with no branches, so if you keep walking in one direction, you cover the whole path and end up back where you started.

I like this aesthetic, and think it would be nice as an object designed for touching.

Noomorph is a made-up word, consisting of noo (thought) and morph (shape). So noomorphology could be a design process that gives shape to thought.

Evaluation questions

Document a final project masterpiece that integrates the range of units covered, answering:

What does it do?

The tactile labyrinth is a 3D path around a ball that can be traced and followed with the hands. Lights along the path are programmed with animations that react to the motion of the ball.

Who’s done what beforehand?

Michael McGinnis: Perplexus
Nervous System: coral cup
Carl Bugeja: Building a Mini Vegas-Sphere
Ancient: The Fibrovisor

Mood board – interactive version with video embeds and links.

What did you design?

Parametric design app that simulates a tiny planet and rope loop with self-collisions and gravity.
Once the path is solved, sockets for the LED wires are added, and holes are subtracted, using Boolean operations. The sockets are oriented towards the center of the ball.
The app exports positive and negative space STLs that are combined in Blender or Prusa Slicer before 3D printing.
The parts snap together securely, mostly without glue.
The LEDs are inserted into each socket. The wire loops through the inside of the ball.
A platform sits between the halves of the ball. It was designed to keep the accelerometer at the center of the ball, and the battery close to the center of gravity.
Arduino code interfaces Adafruit accelerometer and FastLED libraries.

What sources did you use?

3D Singh VFX Blender Geometry Nodes tutorials
Claude Sonnet 3.5, 3.7, 4 via readme-based development
Adafruit accelerometer library
FastLED library, especially the "rainbow" balanced color functions

What materials and components were used?

Where did they come from?

How much did they cost?

maker and part	part number	source	cost
Seeed Studio XIAO RP2040	102010428	Digikey	$4.68
Adafruit LSM6DSOX 6 DoF Accelerometer and Gyroscope - STEMMA QT / Qwiic	4438	Digikey	$11.95
Texas Instruments 3 V to 5 V Level Shifter	TXB0104DR	Digikey	$0.92
Horizontal SMD 2.54mm pitch pin socket connector (01x04) ($0.67 * 3)	BG300-04-A-L-A	Digikey	$2.01
Horizontal SMD 2.54mm pitch pin socket connector (01x03)	BG300-03-A-L-A	Digikey	$0.51
7 Position vertical header ($1.08 * 2)	NPTC071KFXC-RC	Digikey	$2.16
Omron push button switch	B3SN-3012	Digikey	$0.71
YAGEO 4.99 kOhms resistor 1206 ($0.10 * 2)	RC1206FR-074K99L	Digikey	$0.20
TDK Corporation 0.1 µF Ceramic Capacitor 1206 ($0.23 * 2)	C3216X7R2A104K160AA	Digikey	$0.46
Bantam Proto Board Copper Clad FR1, Single Sided ($67.53/25)	MT1004	Digikey	$2.70
BTF-Lighting WS2812B 10m / 100 LED String	btf-5v-100l-t	Amazon	$16.99
Filalab transparent PCTG filament ($28.50/kg, 537g)	4779051441044	Filalab	$15.30
Filalab Galaxy Blue PLA filament ($22.80/kg, 351g)	4779051440993	Filalab	$8.00
Clas Ohlson 5000mah battery bank (generic versions of the product exist)	39-3976-1	Clas Ohlson	$28.46
Baltic birch plywood, 3mm (128mm square, from offcut)		Fablab	$2.00

Total: $97.05 USD (€85.06 EUR)

What parts and systems were made?

3D printed parts for the inner case (opaque) and LED path (transparent)
Laser cut mounting platform for circuit boards
Custom circuit board

What processes were used?

3D printing
Laser cutting
CNC milling for the circuit board

What questions were answered?

Can I make a path from a physics simulation, embed addressable LEDs into the path, and program a microcontroller to make interactive color animations on the object? Yes, I can do those things now.

What worked? What didn't?

See LED strip drama in the build log for something that did not work. Also the first attempt at soldering the circuit board (Week 08) did not go well.

The fit between in the inner outer parts worked better than expected. I thought it would require more iteration, but the first version worked as the final.

Otherwise, things worked out pretty well.

How was it evaluated?

Local and global evaluators for my weekly documentation.

Friends and family birthday party, play-testing with folks young and old. Their hands are in my presentation video.

Helsinki Media Lab Demo Day, passing around the labyrinth and speaking with people involved in new media art. It was nice to run into former teachers and fellow students, and to just place the object into their hands to see their reaction. One described the gameplay as "homeopathic" which I appreciated.

At demo day. Playful spontanious combination with a 360° audio installation.

Fab Academy final presentation comments. Thank you all. 😊

Neil suggested that I add more about the physics simulation.

This version is 180mm in diameter and 800g. In my next steps I have been thinking that a target for the next version would be half the size and weight, to be easier to pick up, transport, and manipulate. But at least two play-testers said that they appreciate the size and weight as it is. It certainly feels substantial.

To share with the wider web I posted my presentation on YouTube, Mastodon, Bluesky, Instagram, and linked back to here. I didn't get a lot of feedback on those sites. I think it's more interesting in person... considering the title of the project, that makes sense.

What are the implications?

My goal in joining Fab Academy was to expand the tools and processes in my digital fabrication toolbox. Coming in to the class, I was comfortable with 2D design and laser cutting. Taking an earlier project that was static and 2D, and making it interactive and 3D, is a good reflection of all that I have learned in this class.

Build Log

The rest of this page was updated through the course as I worked on the labyrinth.

Previous work

╔══════╗╔╗╔╗╔════╗
╚═╗╔══╗║║║║║║╔═══╝
╔╗║║╔╗║╚╝╚╝║║╚═╗╔╗
║║╚╝║║║╔═══╝║╔═╝║║
║╚══╝║║╚═╗╔═╝║╔╗║║
╚═╗╔╗║╚═╗║║╔═╝║║║║
╔═╝║║║╔╗║║║╚══╝╚╝║
╚══╝║║║║║║║╔════╗║
╔╗╔═╝╚╝╚╝╚╝╚═══╗║║
║║╚═══╗╔╗╔╗╔╗╔═╝╚╝
║╚════╝║║║║║║║╔══╗
║╔╗╔══╗║║║╚╝║║║╔═╝
║║║║╔═╝║║╚═╗║╚╝╚═╗
║║╚╝║╔═╝╚═╗║║╔══╗║
║║╔═╝║╔═══╝║║║╔╗║║
╚╝╚═╗║║╔╗╔╗║╚╝║║╚╝
╔═══╝║║║║║║╚══╝╚═╗
╚════╝╚╝╚╝╚══════╝

"Wave Form Collapse" seeded random labyrinth, 2018.

"Folding powers of 2" labyrinth, pen plotting, 2021.

Stickers made during fab Week 03.

More Sierpiński curve projects: snow walking, wall lamp, web animation, 3D print.

2D wooden labyrinth, 2018.

Sketch for a 3D wooden labyrinth.

Simulation

Both the Blender and web versions of the simulation include a center of gravity, a ground sphere, and a loop of beads. Each frame of animation can have many physics cycles, that advance the time a fraction of the animation frame time. I use Verlet integration to solve the positions of an velocities of the beads that make the rope.

One challenge was smoothly adding beads to the rope. If you just add a new bead between two existing ones, the new bead will be overlapping, and the collision constraint will "thrash" the rope as the beads jump away from their overlap. By adding a new bead with a small radius and then smoothly growing it, the rope can grow without this thrash.

Blender geometry nodes

Ropes simulated in Blender. I have a Blender journal that documents that simulation.

With this simulation, I can grow irregular paths around any shape, with various paramters like center of gravity.

3D embed, union of simulated ropes and base icosahedron.

I've printed 3 versions of the same simulation result: ropes only, union with icosahedron, and difference (carving into the polyhedron). There is a pleasing contrast between the regular polyhedron and organic ropes.

Web

I ported the Blender geometry nodes rope simulation to the web, with help from Claude 3.7. I structured the prompt as a readme file, but it took a bunch of iteration to reach parity with the Blender version. I lost Blender's fancy rendering, but gained live parameter tweaking and more direct manpulation and interactive possibility.

Interaction

Idea for a game-like interaction, where a character, represented by one LED of the string, walks along the path, all around the sphere. You have to turn the ball to keep them on top.

Maybe the bottom hemisphere stays blue and sloshes around a bit, to represent water.

Large scale prototype

I bought an addressable LED "rope" with USB power, animation controller, and silicone and nylon diffuser.

By wrapping it around a ball, we could start to get a sense of how it would feel to hold an animating light orb. But I needed a better structure to attach the rope.

Everybody should have a stack of cardboard hexagons handy. This is actually the third life of these hexagons. They started as offcuts of a laser cutting jig, then became prototype game pieces, then became apriltag tokens for Folk Computer.

Cardboard soccer ball ready, a.k.a. truncated icosahedron.

With some zip ties to attach the LED rope. Getting a feel for the form, imagining a mag sensor driving the light motion.

Circuit design

Documented in week 10's post.

Future iterations ꩜

Mirror image prints, to trace with fingers in each hand.

3D modeling: learn how to split shape to be printed as triangles flat on the bed.

CNC carving: translate that design to be carvable.

Electronics: make it possible to insert LED rope, design animations that fit the form.

Open questions

What is the interaction?
If I end up with an unconventional display, what will it show?
Could it be the base of the "calm timer" idea?
Can I keep the tactile inspiration while adding electronic interactivity, or are those exclusive?

Midterm plan

Desmos graph with approximate LED path. Time to "eat the frog" and do some integration. The step I've been a little stuck on is mapping the LED indexes to positions. By making an formulaic approximation, I can get something on the microcontroller to get unstuck, and finesse the strategy later.

2025-04-23: Week 13's post.

Prototype integration

It's important to get my hands on a working version, the integrated cardboard prototype, to better understand how to budget the rest of my time. What are the most important improvements to make in each area of the build?

Sensor and animation

I really want to get the sensor and battery in position now!

Battery and sensor position

Wireless and handheld at last.

(Re)calibration app

2025-05-07: Once I had a version with the accelerometer in place, I reworked the calibration flow. Week 15's post.

Wood side quest

Four axis milling for wildcard week 17.

Final integration

Material choice

Material and LED socket tests in week 16.

Boolean workflow

Internal structure design and printing the major parts.

Aesthetic

I'm committed to the "3D print of medium poly count geometry" aesthetic now. Other processes and sanding didn't enhance the tactile or translucent qualities that are important.

3D print snap-together

An accident, but my test parts became my production parts when they snapped together real nice. But why did it work out that way?

Hemisphere coupler

Blender setup for the part that holds the two hemispheres together. Part created with several Boolean modifiers.

Circuit mounting platform

The platform is designed to put the accelerometer at the center of the sphere, and the 18650 battery compartment near the center of gravity.

Week 18: documenting these final parts.

RIP LED index 0

After feeling lots of momentum at the lab getting the parts produced and integrated, I took everything home to finish the integration. I was distrought when none of the LEDs worked. I tried various controllers and power supplies, and they worked with another LED strip, but not my wire. I couldn't find a local source of the LEDs, and it would take too long to get a replacement. I thought my schedule was shot. I wouldn't be able to finish the course on time.

Kris mentioned that if something happens to the first LED, it might not forward the signals needed to the rest of the strip. Instead of cutting it out, I tried jumping the 3 wires with sewing pins. I was shocked and elated when it actually worked.

What a roller coaster. 🎢

One LED can make the whole string not work, and the string not working made me think that the whole project wouldn't be done. In that way, it was a self-analogy of dependency failures.

Software integration

The gist of calibration:

Light one LED at a time
Turn the ball to put that at top
Record the gravity vector for that LED

I also had to make an array mapping the outer path LED order to the internal index, because the order is different.

readme.md for the final software.

Source

forresto-tactile-labyrinth-v0.zip

.
├── dev_board
│   ├── dev_board.kicad_pcb
│   ├── dev_board.kicad_pro
│   └── dev_board.kicad_sch
├── print-and-cut
│   ├── internal-join-v2.stl
│   ├── internal.blend-bottom.stl
│   ├── internal.blend-top.stl
│   ├── labyrinth internal support - cuttle.xyz.svg
│   ├── rope-3d-print-complete-2025-05-27T10-48-23-285Z-negative.stl
│   └── rope-3d-print-complete-2025-05-27T10-48-23-306Z-positive.stl
├── TactileLabyrinthFinal
│   ├── PixelBallLedMap.h
│   ├── readme.md
│   └── TactileLabyrinthFinal.ino
└── web
    ├── lib
    ├── pixel-ball
    │   ├── index.html
    │   ├── pixel-ball-initial.js
    │   ├── pixel-ball-viz.js
    │   ├── pixel-ball.js
    │   └── readme.md
    └── rope-simulation
        ├── generated
        │   ├── main.js
        │   ├── Physics.js
        │   ├── Print3D-worker.js
        │   ├── Print3D.js
        │   ├── Rope.js
        │   ├── RopeVisualizer.js
        │   └── TubeSDF.js
        ├── index.html
        ├── lib
        ├── readme.md
        └── rope-148-16.json

fab license

This work may be reproduced, modified, distributed, performed, and displayed for any purpose, but must acknowledge "Tactile Labyrinth by Forrest Oliphant". Copyright is retained and must be preserved. The work is provided as is; no warranty is provided, and users accept all liability.

Example acknowledement link in markdown:

[Tactile Labyrinth by Forrest Oliphant](https://www.forresto.com/fab-academy/tactile-labyrinth.html)

Next steps...

Hardware upgrades:

Break out small panel for external access for power switch, charging, programming
Improve the joinery of the halves of the sphere
Fancy compound hinge?
Vibration motor with satisfying feedback for the gameplay

Software:

Gameplay improvements, make the motion more connected to physics
Persistence of vision, show images when spinning or throwing the ball

Week 18. Final Labyrinth Parts

2025-05-28T00:00:00Z

This week I continued the materials tests from week 16 for the tactile labyrinth. I also refactored the rope simulation web app to export STLs for the internal structure of the labyrinth.

Inner parts

As booleans on organic shapes are heavy in the browser, I continued with the positive/negative STL export process that I outlined in week 16.

When slicing the second half of the internal structure, I ran into a bug with Prusa Slicer that would discard some of the geometry. I had to recreate boolean operations in Blender, but now I have actual STLs for the parts that don't depend on Prusa Slicer.

This design is a callback to an earlier version that combined the geometric lines of an icosahedron with the organic path of the rope simulation. The main purpose is to be a structure for the outer parts and electronics, It also hides the wires and prevents accidental poking from the outside.

Renders

3d embed.

New Three.js materials for preview.

Parts imported to Womp to play with their rendering. I thought that it might be good for some final modeling on the parts, but they can't import editable meshes with full fidelity. I'm committed to the "3D print of medium poly count geometry" aesthetic now, so Womp's SDF modeling would be a step away from that.

Outer parts

Because I adopted an internal structure, I made a physics constraint tweak is that the rope should not merge into itself. This will make the rope parts individually printable, and keep light from leaking through the unioned areas.

I continued the material tests of week 16 by trying Formlabs Transpanent Resin v4, and Fiberology Transparent PCTG. The resin print is the most transparent, but I'm depending on the light diffusion of the filament 3D printer and infill, so I'll continue with that.

21 hour print.

Could experiment with more-efficient bed placement of the rope parts.

3D print snap-together

An accident, but my test parts became my production parts when they snapped together "real nice".

Somehow these two prints with similar settings and different materials and no "kerf" compensation snapped together in a really sturdy-feeling way.

But why did it work out that way?

Will it work for resin printers, or do we have less wiggle room with that process? When Adam Savage set up his Formlabs Fuse nylon SLS printer, their first snap-together parts did not work because there is no flex in that material. (I appreciated them sharing that ~~fail~~ learning experience.)

It makes sense that the angles of the hole collars around the ball make the rope into a big clip. This is also why the bigger parts are harder to coax into place.

LED wire is threaded through the inside like this.

Hemisphere coupler

Blender setup for the part that holds the two hemispheres together. Part created with several Boolean modifiers.

Base shape: Icosahedron sized to fit within walls of the inner structure.

Intersect: wide cylindar with desired height
Subtract: inner structure, so the part fits within the inner structure
Subtract: 32-sided cylindar through-hole to leave room for battery and access the bottom wires
Subtract: cylindar placed so that the platform is centered in the sphere
Subtract: several icosahedra to leave room for wires to go up or down

Note: it would have been more reusable to build these shapes with parameters in the web app, but Blender proved good enough to make the one part that I needed.

Electronics platform

Cuttle project link.

This is the platform to hold circuits, switch and battery. It was satisfying to use the laser cutter with the newly-replaced tube. I started with a cardboard version to test the fit, and then moved to 3mm plywood. I included extra holes in the platform to make it easier to deal with known and unknown unknowns.

Todo

Next on my mind...

😅

Week 17. Four Axis Milling

2025-05-21T00:00:00Z

Wildcard week! I thought it would be interesting to carve my design in the Roland mill with the additional rotary axis installed.

3D labyrinth in oak. 40mm diameter.

Design with Womp

I started with my webapp's model as a GLB file.

I imported this to WOMP and added a sphere on the inside.

I increased the "goop factor" on the sphere until the sphere melded with the inside of the labyrinth path. This smooth union was helpful for the milling process, to match the size and range of the tools that we have available.

CAM with DeskProto

6mm ballnose mill roughing path preview. Estimated time 50 minutes, actual time ended up closer to 3 hours.

3mm ballnose mill finishing path preview.

Milling with Roland MDX-40 and ZCL-40

The first version was milled from SikaBlock M600 N material, as a practice run and test of the toolpaths. It is a polyurethane foam designed for millability and mold making.

Foam first roughing pass with 6mm tool.

Foam detail pass with 3mm tool.

I installed the cutting tool tool low, so the tip hit the base of the piece when going to the home position. Fortunately nothing broke, and I was able to install the mill at the correct position and recalibrate. I paid much more attention to this step with wood.

Completed test carving.

At this point I went back to CAM and added a tab on the right, so that the pin on the right would keep contact through the process.

First pass with 6mm mill. That's a lot of work to make a dowel. Next time I'll try to match the design and stock a little better, for example by starting with a round dowel. But it was satisfying when the mill finally started to move in the Z dimension, and the rough form started to emerge.

10x and 120x timelapse of the finishing pass.

Done, phew.

Conclusion

The rotary stage takes a lot of the vertical space in this desktop mill, so the maximum stock size is about 42mm. The ideal scale for this design would be 80mm. The process was pretty noisy and mind-numbing to supervise... a more positive spin would be that it was meditative.

If I do another wooden version of the design, I think it would be cool to break the design into several parts that can be milled with a 3 axis process. That would let me create a version with the proper scale.

But I like my brain bead knob for what it is.

References

Aalto Wiki: 3D Milling with DeskProto and MDX-40 (4th axis) – Shoutout to Jonas Tjepkema for documenting this so thoroughly! Every issue that I had, like the mill end hitting the foam part, was a result of skimming a section too lightly. All the info is in there.

Week 16. System Integration

2025-05-14T00:00:00Z

Chipping away at the final steps to make the Tactile Labyrinth.

Hand scale test print

I wanted to hold a version of the design made with the web app.

Prusa Mini, 24 hour print, generic white PLA.

One idea is that this will become the "nucleus" of the soft version of the pixel ball. Electronics and battery.

Another idea is to scale this so that LEDs can be embedded on the inside.

Design with positive and negative space

The mesh that my design app outputs has overlapping shapes where the ropes rest against each other. Prusa slicer doesn't have a problem with this. It makes the perimeter and infill as if the shape is unioned. But trying to do any other Boolean modelling on the shape in Blender or JS made a lot of broken and sad meshes.

I found a workaround: export positive and negative space as 2 separate STL files, then combine them with Prusa Slicer.

Rope simulation and mesh generation works as before.

LED positions and rotations calculated and previewed.

Slice the rope mesh and preview the LED positions with it. Export positive and negative STLs.

(Possible enhancement is to do this all with SDF modeling.)

Load the positive STL in Prusa Slicer.

Right click the positive and choose Add negative volume > Load… to subtract the negative STL from the positive.

The rectangle in the both positive and negative STLs is for registration. They import with the correct orientation relative to each other, as they are saved. When they are lined up correctly, the registration tabs negate each other.

Click "Enter 3D Print Mode" on the rope simulation web app to try the new LED socket parameters and multiple STL generation.

Test print

Smaller test print, with the sockets scaled for some bigger LEDs that I wanted test.

The white filament absorbs more if the light than I hoped. I need to experiment with clear filament.

Transparent PLA test

I have been experimenting with Womp again. It's not parametric CAD, but there are some nice features for quick 3D modeling with Booleans.

Womp's cross-section view mode, where you can move the plane to preview the cross-section of the model.

Transparent PLA, 1mm outer shell, 20% infill with gyroid pattern, Ultimaker S3.

The socket design works. The pre-wired LEDs can bend to about 12.6mm, so that will be a base parameter for the final model. For light diffusion, I think it's good to keep some space for infill between the socket and the outer edge.

This test print is designed with LED sockets of varying sizes and spacings to see if the premade LED wire can fit. I'll print it with transparent PLA to test how the light looks from the outside.

Sanded on left and raw on the right. Unsanded feels nicer, and the sanding doesn't enhance the light diffusion enough to be worth it.

Test print as small lamp

Building on the version that I milled in week 17, I subtracted a cavity to make a small lamp.

Future nightlight.

Integration

With material and LED mounting questions answered, it's time to go on to the rest of the integration plan.

Plan A

Continue tweaking the 3d design and testing prints.
Hinge and clasp design
Electronics platform, battery holder
v1 of Arduino software

Plan B

If I talk myself out of embedding the LEDs on the inside of the ball, and thinking that I'll go back to the soft design. I can still use the generated 3d print as the internal case for the electronics.

Hinge and clasp design for internal case.
Battery holder
Sewing soft outer case
v1 of Arduino software

Plan C

A gimbal like this for the middle of the softball-sized labyrinth ball. Instead of compass, a single focused LED shining up ▲ with battery down ▼ for weight. It will always shine up, so you could manually make the light follow the path. Throw out the microcontroller and LED strips. Done.

Week 15. Interface and Application Programming

2025-05-06T00:00:00Z

Building an interface for calibrating a ball of addressable LEDs.

Pixel Ball Calibration App

💡 Note that this "readme driven development" development strategy fits well with "document as you go." By having this markdown file as well as the html, js, and ino files in the LLM context, it becomes easier to debug issues across these boundaries. Then it is one step to commit and publish changes.

Intro

During week 13 I iterated on two methods for mapping positions of an LED string around a ball. The first version used a math function to estimate the positions of the LEDs. The second version involved making a list of key positions, moving a white pixel around until the index was close to the estimated position, and then having the code interpolating the LED positions between those mapped indexes. This involved more manual work, and ended up being more accurate, but still ended up with some funky pixels.

As I was working through these versions, I had the ball stationary on the desk, and I moved the accelerometer independently to test the calibration. Only once I had a mapping that seemed correct did I integrate the cardboard prototype.

Once I had the wireless version in my hands with the central accelerometer, and through a conversation with Kris, I thought of a new way to do the calibration process.

For every pixel, or every nth pixel:

Send a serial message with the LED index.
Blink red for 3 seconds.
The person moves the ball until that pixel is on top.
Shine green for 1 second.
The accelerometer value (which is the ball's orientation) is then stored for that pixel.
Once the whole LED string is calibrated, a list is sent via serial message, that can be hardcoded into the positioning library and used in other Arduino programs for the ball.

This calibration program will be more flexible than the previous versions, and will be better suited for the organic simulated shapes that I hope will be the final form. Redesigning the LED path, or accelerometer position, will require another calibration pass. But I think it will be easier and more enjoyable than my past versions. This will let me iterate on the design.

Spec

A web app will listen to the serial messages via WebSerial, as in week 12's machine interface. The accelerometer's orientation will be visualized, and each LED position as it is mapped. The webapp will be able to query the device for any existing mapping, and be able to skip to any index.

Previous code

For reference. Don't change these files.

This version

Initial prompt

Without writing code, help me fill out subsections of this markdown spec. We have a working version, but want to redesign the calibration flow entirely. We also want to make a web visualization to make the process more interactive. Once all of the sections are filled out, we will have enough of a spec to start implementing.

Conclusion

readme.md: the whole readme initialized and edited through the development process.
index.html: the calibration app

Building on my short experience with "readme driven development" I can see that this development flow is allowing me take on larger chunks of work. This app and documentation took 5 hours.

My modus operandi with maker projects in the past has been to relentlessly simplifiy. Does it really need to be wireless? Let's make it easier by just using a wire. Does it really need a microcontroller? Let's just wire the buttons to the output directly.

I still think simplification is a valuable maker skill, but now when the concept does demand a certain level of complexity, I'm feeling more ready to take on the challenge.

Week 14. Molding and Casting

2025-04-30T00:00:00Z

Using openly available 3D data for Helsinki, I set out to make an ice version of a neighborhood.

Side track, 3D print

The 3d files that are downloadable from the city have come with separate terrain and buildings. I did some work in Blender to combine and prep these files, but I'm not fully satisfied with that workflow.

Using the same model, I started a 3d print at the same scale, to be able to compare the process.

This was inspired in part by Fab Lab Ísafjörður's Days of darkness project. I really like the concept of simulating the sun's path on a miniature model of buildings and terrain.

Mold making

Calibrating the Roland mill's XY position to the corner of the wax blank.

We use carving (jeweler's) wax, which machines well and the chips can be collected and recycled by melting them down to make new blanks.

After the 6mm tool's roughing pass, we did one finishing pass with the 3mm tool. Each pass took 2 hours, so I'm glad that the milling process succeeded.

By filling the negative space of the mold with water, we can measure how much silicone we'll need.

Wooden stirring sticks, vacuum chamber, and Smooth-On molding and casting supplies in the molding and casting room at Aalto Studios.

Mix each of the 2 parts in their own jar for 2 minutes, using different sticks. Be sure to scrape sides and bottom.
Combine the two parts in the measuring cup, using 50% of the volume that we measured with water of each. Plus a little bit to account for what will be lost on the stick and sides of container.
Mix the 2 parts together with a new stick for 2 minutes, scraping sides and bottom.
Put the cup in the vacuum chamber and pull a vacuum until the mixture starts to bubble out. When it looks like it will overflow, slowly release the valve until the level goes down in the cup. Repeat until the bubbling is done.
Pour into the mold with a thin, steady stream. This prevents the flow from trapping bubbles.
Tap the table to encourage any bubbles to come to the surface.

The blob! Video is sped up 4x.

At this point it was the end of the day. I debated bringing the mold home with me on the metro, but decided to let it cure at the Fablab.

The next day, it looked and felt like a success. I pulled the edge of the silicone a little bit, and blew compressed air in to encourage it out. I was a little worried that the thin buildings might break while removing the casting, but it came out without issue.

Mold Star™ 15 SLOW is not food safe, so I will not eat the ice neighborhood.

Video is sped up 120x.

Files

mh.stl.zip – 3d data that was used for both the print and mold. I would do some cleanup work before 3d printing it again.

Reference

3D data for Helsinki
Roland Modela MDX-40 – Aalto Fablab wiki

Week 13. Midterm Plan

2025-04-23T00:00:00Z

Tactile Labyrinth remaining steps.

Project Overview

A tangible spherical object with LED lights forming a labyrinth pattern that responds to physical interaction (turning, tilting, etc.).

Hardware Requirements

Seeed Studio XIAO RP2040 microcontroller
6DoF accelerometer and gyroscope – Adafruit LSM6DSOX with STEMMA QT
LED rope with 250 addressable RGB LEDs – WS2812B chip
Power supply (USB/battery considerations)
Tactile housing/structure to support the LED rope in a spherical pattern
Button input (existing in current code)

Libraries

FastLED - For controlling the LED string
Wire - For I2C communication with the accelerometer
Adafruit_LSM6DS - For the specific accelerometer/gyroscope
Adafruit_Sensor - Required for the LSM6DS library

Core Functionality Requirements

Map the physical layout of the LED rope around the sphere
- How is the rope physically arranged? Linear mapping or something more complex?
  - It starts at one pole, wraps around the sphere in a coil to the other pole, then doubles back and goes between the first coil, without overlapping, back to the first pole. So it starts and ends at the same place.
  - I think that I can make a sparse array with polar positions at arbitrary indexes, and the other positions interpolated.
- Does the LED indexing follow the actual labyrinth pattern logically?
  - Yes. As the LED rope wraps around the ball, that path (index 0 to 249) is the path of the labyrinth in animations.
Motion-based interaction
- How should the sphere respond when tilted in different directions?
  - For the first step, color the bottom of the sphere blue, and the top green.
  - This should work at any orientation.
- What data from the accelerometer/gyroscope is most relevant (orientation vs. movement)?
  - At first, orientation.
- How quickly should the LEDs respond to movement?
  - Should feel very responsive, like turning a ball filled halfway with water. But it's a little planet. :)
Animation patterns
- What types of animations should be implemented?
  - Simple to start. Maybe the animation code could feel like shader code. A function of the index, polar position, and time returns a color. The function called once per pixel.
- Should different areas of the labyrinth behave differently?
- How to implement the "character" moving along the labyrinth path?
  - Later, our "pilgrim pixel" will walk along the rope, and goal will be to keep him on top.
  - We don't need to program an error or game over. Just keep the one pixel moving at a slow steady pace.
Game mechanics – think about this section later
- How does the "character" (represented by one LED) navigate the labyrinth?
- What are the winning/losing conditions?
- Is there a time element or challenge?
- How does the "water" concept integrate (mentioned in the blue hemisphere idea)?

Technical Questions to Resolve

Power requirements and optimization
- How to manage battery life if portable?
  - Integrate a battery bank that has its own charging. Make sure case has sufficient airflow.
- How to optimize brightness vs. power consumption?
  - Single BRIGHTNESS in the code
Memory considerations
- Will the RP2040 have enough memory for all animations and states?
- How to efficiently store and access the LED mapping?
Performance concerns
- What's the optimal refresh rate for smooth animations?
  - Try 100hz
- How to handle multiple simultaneous processes (reading sensors, updating LEDs)?
  - By adding a setup1() and loop1() function to your sketch you can make use of the second core. Anything called from within the setup1() or loop1() routines will execute on the second core. setup() and setup1() will be called at the same time, and the loop() or loop1() will be started as soon as the core’s setup() completes (i.e. not necessarily simultaneously!).
Calibration process
- How will the device be calibrated for orientation?
- Does it need a "home" position?
  - Position at startup will be defined as up.

UX Considerations

Feedback mechanisms
- How does the user know their actions are affecting the system?
- What visual cues indicate progress or state changes?
Intuitiveness
- How can the interaction be made immediately understandable?
- Is there a learning curve, and if so, how to minimize it?
Engagement
- What makes the experience engaging beyond the initial novelty?
- How to encourage continued interaction?

Physical Design Questions

Structure
- What material for the final sphere structure?
- How to ensure the LEDs stay fixed in the labyrinth pattern?
- How to provide access to components for maintenance?
Tactile elements
- Beyond the LED rope, what other tactile elements could enhance the experience?
- Should the surface have texture or relief?
Size considerations
- What is the optimal diameter for handheld interaction?
- Weight considerations for comfortable handling?

Future Development Paths

Connectivity
- Could it connect to other devices or installations?
- Potential for multiplayer or social elements?
Customization
- User-defined patterns or games?
- Different difficulty levels or modes?
Additional sensors
- Would other types of sensors add meaningful interaction?
- Proximity sensors, touch sensors, etc.?

Implementation Plan

Prioritized feature list
- Core functionality vs. "nice to have" features
- Minimum viable product definition
Testing methodology
- How to test different aspects (hardware, software, user experience)
- What metrics define success?
Development phases
- What's the logical order of implementation?
- Key milestones and dependencies?

Planning prompt

> Here's my concept for a tangible labyrinth.
> ./tactile-labyrinth.md
> And here's the very early Arduino code that I have.
> ./tactile-labyrinth/TactileLabyrinthByForresto.ino
> Help me make a structure for a readme.md file to fill in all of the unknowns for the project to make a full spec. Add sections as needed, and bulletpoint questions to answer. Don't write code until the readme is ready.
> ./13-midterm-plan.md

Sent to Claude 3.7 "Thinking" via Zed.

Prototype integration progress

LED Mapping

Arduino test code: TactileLabyrinthMappingTest.ino

Desmos graph with approximate LED path.

// Function to calculate position for LED along the double coil
void getPosition(float s, float& x, float& y, float& z) {
    const float a = 3.75;  // Controls number of turns

    // Determine which half we're in
    float sign = (s < 0.5) ? 1.0 : -1.0;

    // Map s to t (0-1) for each half
    float t = (s < 0.5) ? 2.0*s : 2.0*(1.0-s);

    // Calculate position using the formula
    x = sign * sqrt(1.0-t*t) * cos(a*PI*t);
    y = sqrt(1.0-t*t) * sin(a*PI*t);
    z = sign * t;
}

Should I precalculate all of the indexes (bigger program memory, smaller startup cost, same running memory) or do this calculation on board on startup?

Analysis of Tradeoffs (Claude 3.7)

Factor	Precalculated in Flash	Calculated at Startup
Program Size	+3,000 bytes in flash	+150-200 bytes in flash
RAM Usage	Same (3,000 bytes)	Same (3,000 bytes)
Startup Time	Immediate	~5-10ms on RP2040
Flexibility	Must recompile to change	Can modify parameters easily

Why Runtime Calculation Is Better for This Project.

Memory is not a constraint here
- The RP2040 has 264KB RAM and 2MB flash
- 3,000 bytes is only ~1% of available RAM
RP2040 has hardware floating-point
- Floating-point calculations are relatively fast
- The startup delay will be imperceptible to users
Development advantages
- Easier to experiment with different patterns
- Can modify parameters without recompiling
- Code is more self-documenting
Future flexibility
- Potentially store parameters in flash or read from sensors
- Easier to implement different patterns or animations
- Could allow for dynamic reconfiguration

Rethinking mapping

Let's remake this into an interactive process. Using serial commands, we can skip to any LED by index. Then I can find LEDs at key points on the sphere, and create an array. These key points will use polar coordinates, because these are easier to estimate on the ball. Then positions will be calculated from those key points, and interpolated for the rest of the LEDs indecies.

How to Use This Interactive Mapping System (Claude 3.7)

TactileLabyrinthManualMapping.ino

Connect to Serial Monitor (115200 baud)
Navigate to LEDs:
- led 123 - Jump to LED #123
- next - Go to next LED
- prev - Go to previous LED
Store Key Points:
- Find a LED at a known position on your sphere
- Use key index theta phi to store it (example: key 0 0 0 for North Pole)
- Theta is the longitude (0 to 2π), phi is the latitude (0 to π from North to South)
Other Commands:
- list - Show all mapped key points
- reset - Clear all key points
- interpolate - Calculate all LED positions from your key points
- mode - Toggle between mapping and display modes
- display - Cycle display modes (all cardinal points, or individual points)
Recommended Key Points to Map:
- North pole: theta doesn't matter, phi=0
- South pole: theta doesn't matter, phi=π
- Points around the equator (phi=π/2) at various theta values
- Some points between equator and poles

The button on the device toggles between mapping mode and display mode.

Abstracting mapping

Now I want to abstract the positioning logic so that it can be reused between arduino projects. What's a good strategy for that?

Simple Header File Approach (Claude)

Perfect, let's create a simple, ready-to-include header file with your key points built in. This is a faster approach and makes sense when you're working with the same physical object across different projects.

Here's a complete, standalone header file that you can include in any Arduino project:

SphericalLEDMap.h

How to use this in your projects:

Save the above code as SphericalLEDMap.h in your Arduino project folder or libraries folder
Include it in your sketch

Integration with motion detection

Arduino test code: TactileLabyrinthGravityTest.ino./tactile-labyrinth/TactileLabyrinthGravityTest/TactileLabyrinthGravityTest.ino)

Which sensors would be cooler, accel and mag, or accel and gyro? Eventually it would be cool to toss and spin the ball, and have the lights react fast enough to do a persistnace of vision effect, keeping colors locked in space as the ball spins in the air. Will latency be fast enough with these chips and sensors?

Latency Analysis for POV Effects (Claude 3.7)

For persistence of vision effects where colors need to stay locked in space as the ball spins (especially during tosses), an accelerometer + gyroscope combination is significantly better:

Why Gyroscope is Crucial:

Rotation detection: Gyroscopes directly measure rotational velocity - exactly what you need
Speed: Much faster response time (400Hz-1.6kHz) compared to magnetometers (10-100Hz)
Precision: More accurate for fast motions and spins
Less interference: Magnetometers are affected by nearby electronics and metals

For POV to work, your system needs to update faster than the human eye can perceive the change in position:

Component	Time	Note
Sensor reading	~2.4ms	At 416Hz data rate (LSM6DSOX)
Processing	~2ms	Vector math for 250 LEDs
LED update	~7.5ms	Time to push data to 250 WS2812B LEDs
Total latency	~12ms

Is this fast enough? Yes, with some limitations:

A ball spinning at 2 rotations/second (fairly fast) rotates 7.2° in 10ms
Human visual persistence is roughly 1/30 second (33ms)
Your system should be fast enough to maintain the illusion

Matching accelerometer orientation to LED map

XYZ on the mapping don't match XYZ of the accelerometer data. Make a simple way to configure the orientation in software to match the physical layout.

Accelerometer Configuration Solution (Claude)

You need a way to match the physical orientation of your accelerometer with the XYZ coordinate system you're using for LED mapping. Let's implement a solution that allows you to configure the axis orientation in software.

// Configure these to match your physical orientation
AxisMapping ACCEL_X_MAPS_TO = AXIS_POSITIVE_X;  // Which sensor axis maps to your X
AxisMapping ACCEL_Y_MAPS_TO = AXIS_NEGATIVE_Z;  // Which sensor axis maps to your Y
AxisMapping ACCEL_Z_MAPS_TO = AXIS_POSITIVE_Y;  // Which sensor axis maps to your Z

(Took some trial and error, but they are matched now!)

Add the walking pixel

Let's add the wandering monk. A white pixel that steps along the LED rope with a rhythm. Step, step, step step step. The person holding the object will be responsible to keep the monk on the top of the ball. They'll stop walking and if they enter the bottom of the ball. Or maybe it turns into a black pixel and keeps going, since the bottom of the ball is always lit up. This will be added to the existing Gravity mode, and be renamed Monk Pixel Mode. Keep the current gravity colors, just add the monk pixel.

Response

// Monk pixel variables
int monkPosition = 120;
unsigned long lastMonkStep = 0;
#define MONK_STEP_PATTERN_LENGTH 5
int monkStepPattern[MONK_STEP_PATTERN_LENGTH] = {500, 500, 500, 250, 250}; // step, step, step step step timing in ms
int monkStepPatternIndex = 0;

// ... the rest of the file

The monk now walks along the LED strand with the specified rhythm pattern. When it's on the top half of the sphere (according to gravity), it appears as a white pixel. When it enters the bottom half, it turns into a black pixel, which creates a visual effect of disappearing (since the bottom is always lit).

Animation detail idea

Make the total time of the step pattern change over time. As fast as 20 pixels per second, and as slow as 5. Move smoothly to a new pace every 20 seconds. Explain this code heavily in the comments.

When black, make the neighboring 2 pixels black as well.

Dynamic Speed Control System (Response)

I've implemented a sophisticated speed control system for the monk pixel that gradually changes speeds over time. Here's a breakdown of how it works:

Speed Range Definition:
- The monk's speed is defined in terms of pixels per second.
  - MIN_SPEED = 5 pixels per second (slowest)
  - MAX_SPEED = 50 pixels per second (fastest)
Step Pattern System:
- The base step pattern (monkStepPatternBase) defines the relative timing of steps
- The actual step pattern (monkStepPattern) scales these times based on the current speed
Two-Tier Speed Control:
- Long-term changes: Every 20 seconds, a new random target speed is selected
- Smooth transitions: The speed gradually changes toward the target in small increments
Updating Process:
- updateMonkSpeed(): Called regularly to handle speed transitions and target selection
- updateMonkStepPattern(): Recalculates the actual step timings based on the current speed

04-24 integration status

04-27 integration status

Wireless and handheld at last.

I decided to leave it on today as a battery test, and the 10k mah battery is still going after 8+ hours. Now I'm thinking that halving the battery capacity could be worth the weight savings.

Week 12. Machine Building

2025-04-11T00:00:00Z

Our group machine building project is distributed between Helsinki and Istanbul. My focus is on making a web-based control panel that will communicate with the machine over WebSerial.

Live control app. Requires Chrome for WebSerial, but you can control the machine visualization in any browser.

Readme based development

(aka vibe coding but that's a bit cringe)

Using "Claude 3.7 Thinking" via Zed. The first prompt:

Read the readme, and suggest where clarification is needed before writing any code. I will then edit the readme and we can iterate.

And then I filled in the open questions that came back. By keeping the generated code in a subdirectory, I can throw things out and regenerate files if things go off the rails. The LLM chat log and generated code is less precious, but prompts for changes need to be copied to the Readme, which becomes an important source of truth for the project.

Link to the full Readme.

LLM limitations around spatial relationships

Claude did the GUI and WebSerial machine communication code in "one shot" meaning I didn't need to give further guidance after filling out the clarifying points in the Readme.

One area where LLM code still falls short is geometric relationships. As a language model this makes sense, there is only so much reading and writing about geometry can take our knowledge. At some point we need to see (and ideally touch!) geometric forms to root our understanding in the real world.

These limits were reflected in my evaluation of Zoo Modeling App.

Claude's attempt at making the gripper. The parts are there, but orientation is off by 180° for the shells and 90° for the rim.

The transition to the closed state seems like it will be correct once the initial orientation is correct.

After manually fixing the rotation code, I was interested to see Claude's take on my fix.

> see how i fixed the rotations of the parts. i don't blame you because you can't see, but maybe you should work on being able to see.

> js fab-machine-building/public/generated/gripper.js

You're absolutely right about the rotation fixes - thank you for pointing them out! This is an excellent example of the limitations I face when working with 3D visualization code.

## Your Key Fixes:

1. **Hemisphere Rotation Direction:**
   // Changed from:
   leftHemisphereGroup.rotation.y = Math.PI / 2;  // My incorrect version
   rightHemisphereGroup.rotation.y = -Math.PI / 2;
   // To:
   leftHemisphereGroup.rotation.y = -Math.PI / 2;  // Your correct version
   rightHemisphereGroup.rotation.y = Math.PI / 2;

2. **Edge Ring Rotation:**
   // Changed from:
   edge.rotation.x = Math.PI / 2;  // 90 degrees (incorrect)
   // To:
   edge.rotation.x = Math.PI;  // 180 degrees (correct)

## On Visualizing 3D Code

You've touched on an important limitation in my capabilities. While I understand the mathematical principles behind 3D transformations and can write the code, I can't actually see the rendered output to verify that hemispheres are properly oriented or that parts connect correctly.

This is where human expertise is invaluable - being able to see the result and make precise adjustments based on visual feedback. For 3D graphics work, this collaboration between my code generation and your visual verification produces the best results.

Working on "being able to see" would indeed be transformative for my ability to handle spatial and visual tasks. In the meantime, I appreciate you taking the time to correct these visual details that I couldn't verify myself!

I guess it is nice that a human with code / geometry knowledge (me) is still needed in the loop.

It's hard to capture that subtle difference in the Readme, so at this point I've broken the contract of being able to throw out all of the generated code to regenerate it.

Using Three.js DevTools to inspect the structure of the scene.

Refactoring iterations

Talking with the team, we realized that the X and Y axes were switched. I asked the LLM for a refactor:

> I'm changing the X and Y axis, so let's refactor just the rendering.
> - Y movement is the gantry moving along the frame.
> - X movement is the spindle along the gantry.
> js fab-machine-building/public/generated/rendering.js

I also updated the Readme with those bullet points, since that will be good info for any human or machine that's reimplementing this in the future.

The "think" step is new to me, and somewhat interesting. It is hidden in the UI, but available to inspect.

<think> contents...

<think>
I need to refactor the rendering.js file to switch the X and Y axes based on the requirements:
- Y movement is now the gantry moving along the frame
- X movement is the spindle moving along the gantry

Let's break down what needs to change:

1. The data structure and movement logic stays the same, but the visual representation and what each axis controls changes
2. We need to remap the rendering of the axes to match the new convention
3. The gantry (previously X carriage) now moves along the Y axis
4. The spindle (previously Z axis) now moves along the X axis within the gantry

Here are the key changes I need to make:

1. Rename variables to better match the new system
2. Update the creation and positioning of machine components
3. Modify the updatePhysics function to map the X, Y, Z coordinates correctly to physical movements

Let's go through the code and make these changes:

* Rename "xCarriage" to "yGantry" since it now moves in Y
* Update the creation functions to reflect the new axes convention
* Adjust how we update the machine position

For the XY frame, nothing changes physically but we should rename for clarity.

For the carriage, we need to change how it moves - now it should move along the Y axis (depth) instead of X.

For the Z axis, it should now be mounted on the yGantry, but move along the X axis.

The update physics logic stays the same, but we need to map the coordinates differently to the visual elements.
</think>

After the think step, it gives a quick introduction, the refactored code, and a summary.

I'll refactor the rendering code to reflect the new axis arrangement. Here's the updated code with Y axis controlling gantry movement along the frame and X axis moving the spindle along the gantry:

...

Key changes:
1. Renamed `xCarriage` to `yGantry` to reflect that it now moves along the Y axis
2. Renamed `zAxis` to `xSpindle` to reflect that it now moves along the X axis on the gantry
3. Updated the `createFrame()`, `createYGantry()`, and `createXSpindle()` functions to better represent the new axis arrangement
4. Modified the `updatePhysics()` function to map the coordinates correctly:
   - X position now controls the spindle movement along the gantry
   - Y position now controls the gantry movement along the frame
   - Z position still controls vertical movement

This refactoring maintains the same physics and basic movement but changes how the axes are visualized to match the desired convention.

I did have to fix one positioning bug, but I was impressed that it almost got it in one shot.

Conclusion

From a blank slate, total time spent coding, syncing with the machine team in Istanbul, and documenting the process in this post: 5 hours. Most of this time was ironing out visual quirks.

The models and tools for this kind of augmented development are changing rapidly. I like having this basic protocol that can be used with the tools that I'm already comfortable with. They are not tied to a specific code editor or LLM. Documentation is important, whether collaborating with machines or people, and Readme driven development is a good way to practice those skills.

I would like to try bringing in sketches and screenshots with a multi-modal modal. Also, there is a lot of room to experiment working with a group, and integrating a wider system. What if we were doing the CAD, machine control code, and system documentation in the same repo, with the whole team?

This machine visualization didn't hint how much the grabber swings when the cable (Z axis) is extended. Since I was remote from the team building the actual machine, that's not something I thought about until I saw their video. I wonder if there is a 3D physics sandbox with machine-building basics, that's as easy to use as Phun.

Deliverables

Week 11. Networking and Communications

2025-04-09T00:00:00Z

Web Radio

One of my final project ideas was a web radio with token bookmarks to streams and playlists. For this week I wanted to see if I could get the web stream → ESP → I2S → speaker part working in an afternoon.

Using XIAO ESP32C3, Adafruit max98357 I2S mono amp, and lofi speaker.

There was contention on the XIAO forum if XIAO ESP32C3 supports I2S, but it seems to work without any audio issues. I started from the arduino-audio-tools' streams-url_mp3_helix-i2s example. The only trick to get it working was to configure the I2S pins correctly.

// LRC
config.pin_ws = D0;
// BCLK
config.pin_bck = D1;
// DIN
config.pin_data = D2;

Using the arduino-audio-tools library feels like cheating a bit, since it abstracts away most of the networking.

I'm struck how much can be done these days with off-the-shelf breakout board components, without needing to do circuit design or fabrication. This wall plotter has clever software and case design, but most of the electronics are stock boards.

The audio streaming and decoding takes 90% of the XIAO ESP32C3's memory, so if I want to add NFC reading to the project I might have to use a microcontroller with more memory, or move to an external mp3 decoding board like the VS1053.

(That's a funny answer if the question is "what is North Carolina?" but ok.)

I set up the radio to play my alma mater's college radio station, WXYC. The UNC school of library science hosts serveral North Carolina public radio station streams with a directory at ibiblio.org. If I continue the audio player project I'll make tokens for some of these.

Arduino audio libraries

Group Work

Wireless Networking with XIAO ESP32C3.

We looked at the board design and programming to make two boards that can communicate over wifi. Pressing a button on one board sends a request that vibrates the other board.

server.on("/on", HTTP_GET, [](AsyncWebServerRequest *request) {
  localState = true;
  updateFromLocalState();
  request->send(200, "application/json", "OK");
});

server.on("/off", HTTP_GET, [](AsyncWebServerRequest *request) {
  localState = false;
  updateFromLocalState();
  request->send(200, "application/json", "OK");
});

A server that takes requests for /on and /off to toggle a vibration buzzer on the board.

The server code looks quite familiar to me, compared to basic web servers written in Node.

Networking libraries

Machine week planning

For the machine building week, we're planning a distributed project with Turkey. I'll be doing some UI work that takes websocket messages from a 6dof stylus controller, shows a simulation of the x/y/z gantry machine, and sends WebSerial messages to the machine.

Final project progress

Ported my Blender simulation to the web for added interactivity.

Week 10. Output Devices

2025-04-02T00:00:00Z

Group work

Characterizing the power consumption of my addressable RBG LED rope.

LED rope with battery bank and supplied controller, power meter showing 5 volts. I did not make this board; it came with the LED rope.

With only a some of the rope lit up, the power meter shows 0.3 amps.

With the rope fully lit up, the the power meter shows 1.5 amps.

Setup to probe the data line with the Salaea and supplied controller.

Probe UI showing 5v data signals.

Probe UI zoomed in to a data signal.

Using an existing dev board with a level shifter. I did not make this board, it was available in the lab for group work. I did program it to test the Arduino libraries that I want to use on the XIAO. FastLED working!

Circuit fo_v3

Since the XIAO RP2040 data pins have 3.3v and the LED rope data line needs 5v, I knew that my breakout board needed a level shifter. We added a LevelShifter_Texas_TXB0104DR_SOIC-14 from the fab inventory. We also added a power-only USB connector.

fo_v3 KiCad schematic.

PCB design. I have to say that the routing is quite satisfying and I can see it being addictive.

📝 Capacitors should be as close as possible to the chip.

The USB-C power breakout requires a 0.3mm clearance. We have 0.3mm routing bits, but the Bungard mill started breaking them. After breaking a few, we switched to a v-bit, which worked.

fo_v3 circuit assembled. Better than last time! I'm tempted to encase it in hot glue.

Big thanks to Kris' soldering tips videos. The key tip for me was the surface mount chip order of operations:

Put a little solder on one corner pad.
Place the chip with tweezers, make sure the rest of the feet are aligned.
Melt the one foot into the solder blob, again make sure the rest of the feet are aligned.
Solder the opposite corner foot and pad.
Do the rest. Go slow.

📝 The level shifter is symmetrical and the data sheet didn't give a clue as to which way the text is printed. The printed dot on the top is closest to pin 1.

XIAO to LED rope working on fo_v3 board. 😅

Next steps

Make a light animation to go from 0 → 250 with full brigtness white, to see the real max amps of the LED rope.
Connect 6dof sensor and start programming lights reacting the the ball movement.
Iterate on the electronics enclosure and light ball design. 🌀

Files

kicad_fo_v3.zip
HelloLEDRopeColorPalette.ino – this was a FastLED example program with configuration changes to match my LED rope and board.

Forrest O. Interactive

Tactile Labyrinth

Presentation

Inspiration

Evaluation questions

What does it do?

Who’s done what beforehand?

What did you design?

What sources did you use?

What materials and components were used?

What parts and systems were made?

What processes were used?

What questions were answered?

What worked? What didn't?

How was it evaluated?

Social media

What are the implications?

Build Log

Previous work

Simulation

Blender geometry nodes

Web

Interaction

Large scale prototype

Circuit design

Future iterations ꩜

Open questions

Midterm plan

Prototype integration

Sensor and animation

Battery and sensor position

(Re)calibration app

Wood side quest

Final integration

Material choice

Boolean workflow

Aesthetic

3D print snap-together

Hemisphere coupler

Circuit mounting platform

RIP LED index 0

Software integration

Source

fab license

Next steps...

Week 18. Final Labyrinth Parts

Inner parts

Renders

Outer parts

3D print snap-together

Hemisphere coupler

Electronics platform

Todo

Week 17. Four Axis Milling

Design with Womp

CAM with DeskProto

Milling with Roland MDX-40 and ZCL-40

Conclusion

References

Week 16. System Integration

Hand scale test print

Design with positive and negative space

Test print

Transparent PLA test

Test print as small lamp

Integration

Plan A

Plan B

Plan C

Week 15. Interface and Application Programming

Intro

Spec

Previous code

This version

Initial prompt

Conclusion

Week 14. Molding and Casting

Side track, 3D print

Mold making

Files