A small ESP32-based light.

Why build this?

This project was a small gift for two of my friends, Eris and Mimi. Each of them are programmers, and I thought they would enjoy a device to run light control code on without having to care about the hardware. I also make software to run on devices similar to this (pulse, randbeacon) and both of them expressed interest in running those programs themselves, but didn’t have a light to use.

The design needed to be something small that would both not be crazy to bring in my luggage, and also not take up too much space in a shared apartment. I also needed it to be fully enclosed and not have any crazy dances you have to do to use it, and ideally no exposed wires or other ways to fuck up. This is critical when giving projects as presents.

Design

My initial design revolved around a kind of circular shape that had some supports with the ESP32 in the center. However after a few hours of 3D modeling, I had the sudden and terrible realization that it looked like some kind of man-cave truck guy wheel wall art. Which was untenable for obvious reasons.

I then went on a feverish redesign. Everything I could think of was either phallic, yonic, or evocative of something I didn’t want (like the wheel)

I settled on the “dyson airblade” look, because it was the perfect ratio of phallic to yonic, and would also be pretty easy to make. I also played with the angles to make it less similar to the bladeless fans, so there was some uniqueness.

The circuit itself would be very simple - I don’t believe in level shifters, but I do believe in filtering capacitors. I wanted to do without another board, so all joints would be directly on the ESP.

Build

Access to one of the buttons on the ESP32. This button by default toggles the light on/off, which is very handy when you are right there on the light and don’t want to open up an app to control it. I am familiar with making trapped buttons, so a few careful measurements and test prints later I had something that worked perfectly.

I added some vents for some small amount of airflow. I know these devices generate a bit of heat, and fully trapping that would not be ideal. As always, this took way longer than it should because 3D modeling applications hate resizing stuff like this. I ended up using a boolean object so at least I could resize the vents in a different object and the dimensions weren’t linked. This was so effective, even if it was hard to make in the first place. It felt hacky though.

The radius that the lights can wrap around was also a consideration, as the 144 LED/meter strip actually had a wider radius than the normal like 60 LED/meter strips I buy. This ended up being like 18 mm.

For the print, I went back and forth on infill type. Obviously the main light diffuser would just be two perimeters (one would be too fragile for shipping, and two was still translucent enough). But the sides would also leak light - and I had to decide what to do. One option was to put some kind of opaque coating or tape like my plant light shelf, but I think that would make it less interesting. I the light transmission through the print looked cool, so I tried out gyroid infill. This gave really cool results, and I decided to keep it.

For assembly, I didn’t feel like using heat-set inserts, because the loads would be minimal. But I didn’t want to glue anything in case repairs were needed. I used some trusty M3 hex screws for the case, and then some M2 screws for holding the MCU in place.

The final touch was a sticker - something that describes what it is, how to use it, and some basic info in case everything gets messed up. I used the recognizable ST4R logo, even as I’m playing with the brand now.

Product

I ended up making one myself as a prototype, where I used cheaper lights. After testing, I made the two for gifts, and they worked great! Link to files on thingiverse. Let me know if you make one! The software is WLED which can be flashed from a chromium-based browser here.

Theres actually an article about this in the Mercury news?

Robots on Ice! is an event hosted by The Silicon Valley Ice Skating Association usually in the spring at Sharks Ice, San Jose. I think the primary focus is to do a fun outreach event and let the community see some fun robots built by local people.

I noticed a lot of AI and hype language used in the promotion and execution of the event. I think there was only like one or two people coordinating and running this, so I imagine they had a lot to take care of. The organizers also sent pre-formatted social media material for promotion. I don’t usually exhibit at stuff, so I was very new to this kind of material.

Our loadin was very uneventful. It did take Lucy and I a second to find the specific ice rink we were using, as we had never been to this complex and they had like 6 rinks. I also only brought a toolkit and the robot, so no huge bin or anything. Also while there, I went to the team store and bought hockey tape and an ice puck. Hockey tape is much like gaffer tape, but narrower and a bit thicker. I obviously bought the gay pride stuff, planning to use it for decoration. I put it on one of my forks, like it was a stick.

Who else was there

• Two SRI Robotics people, who like hockey and curling.
• The skating robot guy
• that dalek team
• like three FIRST robotics teams
• That ROS rover startup team
• That moddable animal toy team
• That hexapod guy
• Random kids with toys
• Audience of mostly kids and people who were already at the rink that day

People who I think would have fun but werent there

• more bot hockey people
• rc drift people
• humanoid robot people

Phases of the event

• Drive around in open play area, collect the balls the first teams were releasing
• Race
• Play hockey with a kickball

What was hard

So obviously the biggest challenge was traction - our robots have 60A hard rubber wheels, which are very much optimized for coarse, hard surfaces. This speaks to our strength and dominance on parking lots. However the amount of friction was so low it was hard to manage. I attempted to keep traction and stay in the static friction regime by accelerating very slowly, but even with low braking on my ESCs it was very difficult to slow down or turn without losing traction inadvertently. I attempted to put some tape on my wheels to see if it would change anything, but i couldnt really tell. The tape just got wet.

The second issue was running into piles of snow on the ice. These were surprisingly sticky and would fully immobilize our robots, requiring someone to hit the robot with some object, or to just wait for someone with hockey skates to give them a nudge.

Me, Lucy, Victor, and Scott.

Another issue was water. The bots were not meant to be watertight, and moisture was not an anticipated issue. We ended up taping up all likely ingress points, which saved our internals. However, the annoying issue came months later - Scott’s robots specifically ended up rusting their black oxide bolts after not drying them fully before storage.

Another annoying issue was how our robots weight distribution and contact patches contributed to spinning out. All of our fork bots weight is in front of our drive wheels. This lets our forks ride on the ground, to get under opponents. But when sliding on the ice, the forks drag more than the wheels - something about the material, edges, etc. and they spin to face backwards. This almost made it better to drive backwards, but this was generally hard to control.

An issue that affected some peoples robots but not our own was radio range/channel usage. There were on the order of 20 robots on the 2.4 ghz band, and many transmitters were on BLE - I didn’t have an SDR to take a look at the airwaves, but many people were having issues with connections dropping out - to the point where victor had to follow his robot around the arena to stay connected.

Lucy and Scott focusing on driving.

What was great

Our robots were the only ones that could really handle a puck at all. Most people were just using toys that were either too small or too big to handle the specific size of a puck. I would love to see a full hockey match here on the ice. This was where a kickball, which was large enough to be just bumped into full speed, ended up being the hockey puck for our game.

The FIRST robots were very skilled at driving on the ice. I think the two most mobile teams had swerve drives, and it helped that they were likely heavy - more static friction. I wonder if adding weight would improve grip at the cost of more momentum to pull through turns? I also wonder what their tires were made of.

Notes

I’ll probably try to go again next year - this was pretty neat. I’ll put more thought into some tires that could really chew up the ice, maybe something with some metal. Theres also no weight restrictions like bot hockey games, so adding a bunch might be worthwhile.

This one is a fast one. Problem: I’m running out of shelf space for plants on my glass shelving unit. Solution: shine light on plants from above one of the glass shelves, while also being a platform for more plants to sit on top of.

Design

I have an A19 bulb that I bought a while ago for putting in a lamp in my bathroom and keeping a plant alive. However, the lamp I bought for that was too short and ended up cooking the plant I used at the time. So with no other real use for it, the bulb has been sitting in a box.

I didn’t want this to take up too much space, so the footprint is just big enough to get the bulb centered in the square. The height is also the minimum for holding the bulb horizontally.

I put a small ledge around the top to prevent stuff from sliding off. This did result in suboptimal print orientation for finish quality, but I think it’s ok.

The aluminum tape reflects all the light back down to the shelf below, and prevents the PLA from heating up too much.

Build

I used as few custom parts as possible because I didnt want to do this project any longer than I had to.

I just used zip ties to hold the socket and cable because they won’t melt, wont slip, and are easy to design for.

Link to the 3D model on thingiverse

What even is nexus knockout?

Basically check out the Robot Combat Events website for a rundown. Its at Maker’s Nexus in Sunnyvale, CA. Its full combat up to 3lbs, plus bot hockey. This was the same event, two years prior, that I learned about the sport and got inspired to try it myself (See that blog post here). This time, I had my own bot.

Did you do anything to prep since open sauce 2025?

One massive change: I ordered laser-cut aluminum panels for my robot. Exact same design, but more able to take a beating than the acrylic.

The alternate battery covers, with the clean robot behind them. I didn’t want to lose the clear battery cover…

I reprinted a lot of the robot for fresher, stronger parts than immediately after open sauce. I also got rid of the last internal PLA parts and replaced them with TPU.

Night Practice near Scott’s house

The Games

This time, rallying under the unified team Scottbot, we had a full 6 bots - Scott with 1 and 2, Orion with his 3, and me with my single competitor. Lucy was also there to get some experience driving. We were also lowkey cracked.

Morning

Group stage. We lost to No-Ice (just by two points - very close game) and crushed the hockeymaniacs.

We knew No-Ice was going to be tough, and our team was still getting our footing. Hockeymaniacs had some good bots, but I think they were having some hardware issues.

Lunch Break

My friend Bree showed up to hang out, and brought her RC drift cars. They got a bit torn up on the parking lot, but were a lot of fun.

The rest

Smashed The Party Animals, but theyre always fun to play. Met team No-Ice in the finals, and had one of the lowest-scoring matches I think I’ve ever seen. Defense was extra good here.

My bot managed to stay mostly cool, but at the end of the last match the motors were hotter than I had ever seen them. Definitely was driving hard, in direct sunlight.

Next Step

So we won! Next up is open sauce.

The damage to my robot with the aluminum panels was very minimal.

If you don’t want to google “how many days since august 30 1993”. If you don’t know what I’m talking about.

Made as a secret santa for Rusty as part of the 2025 Ebro gift exchange. I made lo-poly models of the space probes his OCs are based on, and attached them to an LED string light. I also modified the light to be powered from a USB plug, rather than AA batteries.

Juno, 2011 mission to Jupiter.

MESSENGER, 2004 mission to Mercury.

CHIPSat, 2003 mission orbiting Earth observing UV emissions from interstellar gas clouds. Launched in the same rocket as ICESat.

ICESat 1, 2003 mission orbiting earth measuring elevation for ice sheets and atmospheric measurements. Launched in the same rocket as CHIPSat.

I made a battery-powered LAN network setup to carry with me.

While working on my randbeacon project, I wanted to manage my WLED setups at OpenSauce with an ethernet interface - so I could use my laptop’s wireless card to connect to the venue’s network. As you can see, the initial setup with this raspberry pi was a little clunky and annoying. The core parts are there, a usb-ethernet adapter and a phone charging battery pack. I tried carrying this around outside while getting photos for that project, and it was the worst.

The core is a RPi3 running OpenWRT, a fast and straightforward network router firmware. I also picked up a Gigabit network switch, which is throttled by the RPi3’s 10/100 ethernet port - but this isn’t primarily for speed, this is for when nothing else would work.

Another critical piece is that the switch is powered off 5V DC. This way I was able to make a dead simple cable that connects to a phone charger battery, which is way easier to integrate into a project than naked Lithium batteries and charge controllers. Regulating voltage is annoying, and more expensive anyway if the usecase doesn’t call for extreme current draw.

The acrylic was scrap cutoffs from TAP plastics here in the bay area. They go for a dollar a sheet and are great value if the stuff you are making is small. I did round the corners and cut some holes, so the QL laser cutter came in handy again.

This setup fits perfectly in a backpack.

Another good thing to know is battery life. Mathematically, the 10 Ah pack could provide about 3 hours and 20 minutes of operation for the rated max of 2.5A (RPI 3B+) + 0.46A (Switch). In my own test of letting everything idle, the battery lasts about 12 hours. With these bounds I know the rough capacity and I’m pretty happy with this.

This is a classic example of “taking an exit ramp” from a project. I wanted to make my own version of an electric wind instrument (EWI) but also wanted to involve my friends in a fun group project.

The Idea

The Akai EWI is a really cool. A novel method of MIDI interface with a computer, that makes you play differently than if you were playing on a keyboard. I don’t know how to play saxophone, so I also think this would be a novel approach to music. Sure, you can buy one for $900, but that’s stupid. Its fairly common practice for internet weirdos to make their own ones.

Prior art

Had to give a search for some classic, non-product, EWI constructions.

• The guy who invented the EWI Nyle Steiner has his own page of novel instruments.
• MiniWI by @Trasselfrisyr is a classic minimum viable product, simple construction with conductive copper pads.
• Haxophone by @cardonabits is a good modern design with mechanical keyboard switches. Also uses fluidsynth.
• BeatJazz Controller by Onyx Ashanti has a radically different form factor. He uses PureData for non-ADSR synthesis and processing of the raw input data.
• Gordon Good has been in the game for years, and also fun fact does projects at CCRMA at Stanford. Has a bunch of blog posts about non-ADSR synthesizers.
• There were also several builds at Opensauce 2025 that were generally similar to these builds.

Our Build

First we have to talk about who the team was. I gathered a few friends; Harry, Ian, and Brooke. The first consideration we wanted to make was who the device was for. Each of us wanted to play one, and knew maybe 1 or 2 other people who might find them interesting if they worked.

This led to a batch size of maybe 3-6 devices, which is a weird number. Its low enough that custom PCBs are still annoying and expensive, and any annoying processes in the construction steps would have to be somewhat repeatable. We also had no delusions that we would be making any money off this, so using like a $200/ea bite force sensor would probably not be a worthwhile inclusion. Goal was cheap, repeatable, and functional enough.

The gang went back and forth but we ultimately decided to separate the input management from the synthesizer part - use an arduino with its many input channels on one side of the versatile MIDI interface, and then connect it to anything downstream, a full computer or some embedded synthesizer. This also gave us a few off ramps to consider.

We also decided that using capacitive pads would be simpler to wire and easier/faster to play, so we decided to look into soldering to pads or tape or something. This would result in a less tactile device, which could be a downside, but that was deemed an acceptable tradeoff.

Side note: Off Ramps

Sometimes you realize you are done working on a project. Not that the project is complete, but that the remaining work is not novel or compelling. This is where the “off ramp” comes into play - a point where the project is presentable and demonstrates something interesting, even if the full vision is not complete. As my projects grow in scale, I find it more useful to build these points in from the very design and planning phase. I also want to note that this doesn’t make me any less motivated to go through and finish a project - it maybe makes it even easier to approach large goals, because I know failure will still leave me with something.

I want to credit this idea and phrasing to Brooke, who really demonstrated it with her quilted jacket project. Link will be added here if she ever posts about it.

Build - Part 2

Parts List

This is for the MIDI instrument part. The synth part would be connected over USB to this component.

I got all the parts a few weeks later, and started breadboarding them together. Simple circuits with the example code to get things working. Around here I think I accidentally broke one of the breath sensors, either by blowing too hard or maybe soldering it too hot. Not sure, I just kind of expect those things to have a failure rate. There is a flexible diaphram in there somewhere, and I think its possible for a human to overpower it.

Software Design

As I said, I don’t know how to play any woodwind instruments. I decided that the engineers at Akai probably know a thing or two about how to map keys to notes - and great engineers steal.

I then just made sure I had enough IO channels to match the button setup.

This diagram outlines multiple useful values for me to keep track of.

• Most prominent is a number prefaced with a K. This maps them to keys in Akai’s manual.
• the number in the pattern bxpx is the IO board index and channel index. There are two boards with 12 channels each.
• the number prefaced with an L indicates where in the flat array of booleans I place that value.

I wanted to use this project to practice some boolean operators. This was mostly just for love of the game. Here is an array I used to mask input values and translate them into the right spot in the array. During testing I noticed that the first two pins on one of my capacitive boards weren’t working, so I just rewired it on the spot and kept the naming the same (if you are trying this project out yourself, I hope you notice and change this if your boards work properly).

// define input to keys
// this should match the wiring you make.
uint32_t io_keys_map[NUM_IO] = {
    // board 0
    0b000000000000000000,
    0b000000000000000000, //p0 // the first two pins are broken?
    0b000000000000100000, //p1
    0b000000000001000000, //p2
    0b000000000010000000, //p3
    0b000000000100000000, //p4
    0b000000001000000000, //p5
    0b000000010000000000, //p6
    0b000000000000010000, //p7
    0b000000000000001000, //p8
    0b000000000000000100, //p9
    0b000000000000000010, //p10
    0b000000000000000001, //p11 
    0b000000000000000000, //x12 unused
    0b000000000000000000, //x13
    0b000000000000000000, //x14
    // board 1
    0b000000100000000000, //p0 
    0b000001000000000000, //p1
    0b000010000000000000, //p2
    0b000100000000000000, //p3
    0b001000000000000000, //p4
    0b010000000000000000, //p5
    0b100000000000000000, //p6
    0b000000000000000000, //p7 unused
    0b000000000000000000, //p8
    0b000000000000000000, //p9
    0b000000000000000000, //p10
    0b000000000000000000, //p11
    0b000000000000000000, //x12
    0b000000000000000000, //x13
    0b000000000000000000, //x14
    0b000000000000000000  //x15
  };

All you need to do to start with an array of physical “buttons” and create an array of “keys” is to AND and then ADD the bitmasks.

// read from inputs
touched_b0 = b0.touched();
touched_b1 = b1.touched();

// turn into logical values
m_allbuttons_held = touched_b0 + ((uint32_t) touched_b1 << 16);

m_allkeys_held = 0;

// map the IO to the keys in order
for (int i=0; i<NUM_IO; i++) {
  testbit = (uint32_t) 1 << i;
  if (m_allbuttons_held & testbit) {
    m_allkeys_held += io_keys_map[i];
  }
}

Then I just copied from the manual to make the fingerings.

// define EWI fingerings
// write in binary which buttons are pressed and associate with a note.
const uint8_t NUM_FINGERINGS = 18;
int32_t keys_notes_map[NUM_FINGERINGS][2] = {
    {0b1011010111011, pitchB2b},
    {0b1011010111001, pitchB2},
    {0b1011000111001, pitchC3},
    {0b1011100111001, pitchD3b},
    {0b1011000111000, pitchD3},
    {0b1011000111100, pitchE3b},
    {0b1011000110000, pitchE3},
    {0b1011000100000, pitchF3},
    {0b1011000010000, pitchG3b},
    {0b1011000000000, pitchG3},
    {0b1011100000000, pitchA3b},
    {0b1010000000000, pitchA3},
    {0b1010001000000, pitchB3b},
    {0b1100000000000, pitchB3b},
    {0b1000000000000, pitchB3},
    {0b0010000000000, pitchC4},
    {0b0000000000000, pitchD4b},
    {0b0000100000000, pitchD4}};

As you can see, there are invalid fingerings, that could be possibly triggered while transitioning between notes. I just hold the last note, but it would be interesting to get into semitone world. That would be a whole different model though.

int16_t getNote(uint32_t keys_held)
{
  for (uint8_t i = 0; i < NUM_FINGERINGS; i++)
  {
    if (keys_held == (uint32_t) keys_notes_map[i][0])
    {
      return keys_notes_map[i][1];
    }
  }
  return m_last_valid_note;
}

From here, I had the breath cause both a NOTEON/NOTEOFF effect when it crossed a threshold, as well as mapping to two different CC channels. One for positive pressure and another for negative pressure. The pitches are sent every cycle that NOTEON is active.

Whats Next

I have like zero desire to build or design the rest of this thing, so I just finished the breadboard test. I don’t think this project is particularly groundbreaking in the world of electronic breath synthesizers, so only if other members of the team pick up the effort will I continue.

Entering the world of combat robots.

Introduction

In fall 2024, I went to Nexus Knockout 1 to watch my friend Scott play bot hockey. It looked cool, but I wasn’t sure if I would get myself involved.

I went again, and at the second Nexus Knockout in March 2025 I subbed in to drive Scott’s second robot. We won!

For winning, our team got tickets to the finals at Opensauce 2025. I also got laid off around this time, so I suddenly had a lot of free time to bring my own custom bot to the competition.

Construction

I talked to Scott about his design, because I liked it and thought it was simple but also adaptable. I made a model in FreeCAD.

To make sure I got sizing and stuff right without spending too much money, I lasered it out of particleboard at work, and printed parts out of PLA.

This gave me a platform to start doing electronics work on the robot.

I got the ESCs set up, the receiver bound, and made sure I wasn’t drawing too much current. 20A max using this clamp ammeter was great to see. I was using 80A ESCs and had a battery that could do 170A burst, so I was totally overspecced. The capacity would likely last me multiple matches before fully depleting a battery, which would take the strain off only owning two of these.

I made a few tweaks to the design that involved shockmounting the motors in TPU, and this time I was ready for a laser. I had an idea for a porcelain-style floral pattern on my robot, and took a small detour to write a script about it. Check out the GitHub page for more on that.

After that, I was ready to take it for a test against real robots. Scott and Kyle were able to meet up for some practice in a nice shaded parking lot.

It was super helpful! I discovered a few major, game-breaking problems.

1. I couldn’t keep the puck in my forks, it would just bounce over.

Solution: build raised walls onto the rails.

1. Due to my weight distribution, I couldn’t push other robots.

Solution: move the battery behind the wheels, move the rails closer to the center.

1. The way my wheels were mounted caused massive amounts of friction in my gearboxes, and also caused them to slowly disassemble themselves. This heat buildup also started melting my motor isolator sections.

Solution: mount the wheels differently. Also, add airflow and heatsinks to the motor enclosure.

Each of these was solvable, and any one of them would have made game day a nightmare. This resulted in a redesign, which resulted in a more balanced bot.

So shiny! I had time for one practice the night before Opensauce with my team for this competition - Hock Stuff! Orion and Nick were able to get their bots driving and we had a quick practice, and I made a last minute discovery that I needed a wheelie bar - a quick print the night before the competition. Unfortunately, our practice was also late at night, and I didn’t get any good photos of the robots.

Bunny, who helped run and organize the tournament, also drew a cartoon of my bot!

Competition

Maidbot shows her stuff on the rink during practice. Its okay! Shes just delicate.

Friday was loadin and systems check. We all got to make sure things were working and do last minute assembly and testing. I was mostly relaxed once I got everything set up, as we had no battles.

It was fun to get the whole bot hockey gang together!

POV the first match is about to start

So focused…

Our team:

• Orion Beach, also engineering lead of Offbeat Robotics, and their bigbot Hijinx
• Nick Hom from bigbot team Ribbot
• Me :) its my first time lol

We had three guest drivers over the course of the competition. This was super fun and Orion and Nick have some cool friends! IT was also helpful because Orion hadn’t let the loctite dry on the wheel nuts and they kept falling off during the compeition, requiring quick bot swaps. This also kept the energy high and got more people involved, so thats super cool.

• Bam Singhasaneh from Team Valkrie helped us defeat team Magic Smoke in the qualifiers, as well as subbing in periodically through other matches.

• Lisa Winter, who is normally judging these kinds of matches, helped us beat Royally Pucked in the qualifiers.

• Matt Vasquez from Team Fast helped us defeat Royally Pucked again, in the first round of the elimination bracket.

We did pretty well in the qualifiers. Second-highest seed. At the end of the last match on Saturday, somehow the rear panel of my robot was completely shattered. I only noticed because my wheelie bar was knocked out and I had a bit of a controls issue - the team sticker was the only thing keeping my battery compartment closed. Acrylic is not a good choice for bot combat, and everyone I talked to expressed this - but I made it work somehow. Definitely something I’ll fix before the next compeition.

Luckily I had a spare! I also spent that night printing a cover that allowed me to stuff some foam between the outside of the robot and that panel. It probably saved my ass a few times (literally!)

That brought us into day two, where we entered the elimination bracket.

Honestly the vibes were really cool. Cheering, struggling for victory, but also knowing that these are just toys and everyone is here to have some fun.

We got second place! Team (No) Ice is just…really good. Their drivers are top notch, and their bots are incredibly efficient. We had a lead in both matches, but in the second half they were able to create a massive lead in the last few minutes of the game.

My robot got pretty beat up, but most of it was just on the tape I slapped all over the panels to keep them from shattering! Also, after the finals match, my motors were the hottest I’ve ever seen them, almost 80C. That’s crazy!!!!!!

Thanks to the tournament runners, Bunny, Alex, and all the other teams. It was a great time and I plan to keep playing this fun game with all of you.

https://bothockeyleague.com/bot-hockey-info/