Until yesterday, my only experience building hardware was playing with crocodile clips in high school physics. I had never stripped a wire, soldered a component, or used a Raspberry Pi. In the last 24 hours I built a mechanical remote control for my Instax Polaroid camera from scratch. It’s not anything spectacular, but it works and solves a real problem in my life.

I set myself the challenge of not searching the internet once during this process. Everything was done through a single long conversation with Gemini. It helped me scope the project, find and buy the right components, plan the circuits, write the code, and debug my (numerous) mistakes.

Although I use coding agents to build software every day, it was really cool to see them guide me through a domain I knew almost nothing about.

If you want to read the full conversation, you can find it here.

---

The 365 Day Polaroid Project

I’ve been taking a polaroid picture every day since the start of the year. It’s been a fun way to document both the exciting and mundane moments of each day. Some days it’s a group selfie or a photo of a friend, others it’s just some food or an object I find interesting. Either way, it’s nice to have a physical record of each day.

One issue I’ve had, though, is that I often want to take a photo of myself without anyone else around. My camera is a point-and-shoot Instax with a single button to trigger the shutter. This makes it impossible to take a photo from a distance. I wanted a way of pressing the button remotely.

It turns out this isn’t something that you can just buy online, so I decided to build my own. How hard could it be?

---

Getting Started

I started with a vague idea of what I wanted: a small device attached to the camera that, when triggered by a remote button, would press the shutter button on the camera:

I want to create an electronic device that I can attach to my instax polaroid camera so that it can take photos remotely. It will work like this:

On the device, there is a ‘trigger’ which includes a servo motor and mechanism for pushing the ‘take photo’ button at the front of the camera (I will figure out a good way to attach this to the camera) 1.

A small handheld button that fires the trigger and presses the button. These two things communicate wirelessly.

What do i need to buy to build this? Bear in mind the devices should be pretty small (no more than 2cm x 2cm)

It came back with a high level plan involving two ESP32 microcontrollers (the brains of the operation): one for the handheld remote and one for the receiver that would press the button. The remote would include a simple button and the receiver would be attached to a servo motor that would rotate a few degrees to apply pressure to the button. The two devices would communicate wirelessly through a simple radio protocol based on their MAC addresses.

A small servo motor connected to an Arduino.

Before proceeding, Gemini told me that it needed to know the amount of torque required to press the button. I didn’t know how to test this myself, so it instructed me to put the camera on a zeroed scale, then slowly press the button down until it clicked. I recorded the weight on the scale, gave it back to Gemini, and it instructed me to buy a 3.7g servo motor that would a) provide enough torque to press the button and b) be small enough to fit on the device.

From here, I was given a full ‘shopping list’ of components that I needed to buy, complete with links to AliExpress:

• ESP32-C3 Super Mini (x2)
• TP4056 Lithium Battery Charger Module (x2)
• 3.7V 250mAh LiPo Battery (x2)
• GH-S37D Digital Servo
• Mini Slide Switch
• Tactile Push Button
• Connecting Wires

I got a few other things such as a soldering iron, solder, and flux. Gemini looked around on YouTube for reviews of cheap AliExpress soldering irons and found a good one for $20. I then waited 4 weeks for the components to arrive.

---

Building the Device

Once the components arrived, I wanted to start simple: Connect the ESP32 to the servo motor and get it to move. This involved soldering the components together and uploading a simple program to the ESP32.

To reiterate, I had no idea what I was doing. But Gemini guided me perfectly through setting up the Arduino IDE, soldering the components in the right order, and uploading the code.

After that, I decided to go for it and build the entire device. This took two full attempts. The first one was a complete disaster - I didn’t know how to solder accurately, crossed some wires, and ended up frying a couple of ESP32s. Luckily, Gemini had suggested buying a few spares of each component 😅.

Before starting my second attempt, I wanted to be crystal clear about the design. I had a vague idea of how it worked, but it involved around 10 components and some of finicky wiring so I needed clarification. I asked Gemini for an HTML diagram of how everything works and wires together. The result wasn’t great but, together with the written instructions, it crystalised the design in my mind.

This diagram could obviously be improved, I half-assed the prompting here

So I just went for it and started building again. After a couple of hours, I had most of it working. There were a few issues where I soldered wires to the wrong pins, but Gemini guided me through this after I sent a few high-res photos of the devices. After a few more hours, I had a working system!

I won’t go into all of the twists and turns of the build / debugging process now. You can read a summary of the conversation in the appendix below.

The receiver attached to the camera - a complete mess

---

Some Reflections

This was mostly just a fun project to learn some basic electronics whilst building something I actually needed. I don’t have any mindblowing insights, but here’s a few observations:

1. Gemini smashed it. From planning the project, to finding the exact components on AliExpress, to helping me assemble the device, I really have no complaints. I understand that this is the hello world of electronics, but it was still awesome to see it work so well as a genuine mentor. I’m sure ChatGPT or Claude could have done well here (there’s a really interesting benchmark here 👀).
2. Feedback loops are harder. Compared to working with coding agents on software, it was much harder to debug issues with my implementation quickly. I learned to rely on images for feedback, but it was still a bit of a pain to explain the current state of my solution. I’m sure some of this is down to my lack of experience, but it’s still a fundamental issue that an AI assistant can’t "see" hardware in the same way it can software.
3. I was vibe hardware engineering. Obviously. It was a paint-by-numbers project. I had no experience and had to learn by doing. I clearly learned a lot and managed to complete the project, but felt incredibly reliant on Gemini at all times and would have struggled to a) follow my own path and b) accurately explain the details what I was doing. There’s a clear parallel here to novice software engineers who ‘learn’ through vibe-coding projects, rather than practicing the fundamentals. A hybrid approach is probably best here.

All in all, I had a great time and am looking forward to doing more projects like this in the future.

Next step: learn Blender to 3D print the cases.

The first polaroid taken with the remote control. Success!

---

Appendix: Conversation Summary

If you’re interested in the full conversation, you can find it here. Here’s a point-by-point summary of the process, generated by Gemini:

Phase 1: The Concept & Shopping List

• The Goal: You wanted a remote trigger for an Instax camera with a tiny 2cm x 2cm footprint.

• The "Brain" Selection: We identified the ESP32-C3 Super Mini as the only board small enough to fit the constraints while offering Wi-Fi/Bluetooth.

• Torque Math: You needed to know if a tiny servo could push the button.

• The Twist: You used a kitchen scale to measure the force required (350g).

• The Physics: We calculated that a standard 3.7g servo using a 1cm arm provides ~600g of force, making it viable. We ruled out using a longer 3cm arm as it would stall the motor.

• The Hardware: The final list included the ESP32s, 3.7g servos, tiny LiPo batteries (250mAh & 110mAh), and TP4056 charging modules.

Phase 2: Software & "Hello World"

• Environment Setup: You are a Python programmer but new to Arduino/C++. We set up the IDE and libraries.

• The "Super Mini" Quirks: You encountered connection issues (red light, disconnecting).

• The Fix: We used the "Bootloader Mode" (holding BOOT + RST) and enabled "USB CDC On Boot" to stabilize the serial connection.

• The "Blink" Confusion: The standard blink sketch didn’t work because the Super Mini uses GPIO 8 (inverted logic) for the LED, not the standard pin.

• First Motion: You successfully wired the servo directly to the board and got it sweeping 45 degrees.

Phase 3: Wireless Communication (ESP-NOW)

• The Protocol: We chose ESP-NOW over standard Wi-Fi or Bluetooth. This allows the remote to "shout" directly to the receiver’s MAC address without a router, resulting in near-instant triggering.
• MAC Address Discovery: You ran a scanner script to identify the unique hardware ID of the Receiver (8C:FD:49:49:56:88) to hardcode into the Remote.
• Proof of Concept: You successfully tested wireless triggering using a jumper wire to simulate a button press before soldering.

Phase 4: The Hardware Build (The "Sandwich")

• The Layout: To fit the 2cm footprint, we designed a vertical stack: Battery → Insulation → TP4056 Charger → Insulation → ESP32.

• The Short Circuit Scare:

• The Incident: You accidentally bridged the 5V and GND pins while the battery was connected. The boards got warm.

• The Recovery: We successfully revived the boards using the Bootloader sequence and confirmed the chips weren’t fried using the "Touch Test" (checking if they got painfully hot).

• Flux & Soldering: You learned to use flux to prevent "cold joints" and bridge connections.

Phase 5: The Wiring Saga (Troubleshooting the TP4056)

This was the most complex technical hurdle.

• The Integration: You wanted the charging module (TP4056) built into the unit.

• The "No Power" Issue: You wired up the receiver, but it wouldn’t turn on via battery, only via USB.

• Visual Analysis 1: You shared a photo of the receiver.

• Diagnosis: The slide switch was physically in the OFF position, and the TP4056 needed a "USB Jump Start" to wake up the protection chip.

• Visual Analysis 2: The device still wouldn’t run on battery power alone.

• The Discovery: I analyzed your high-res photos and found you had soldered the positive wire to IN+ (which is USB-only input) instead of BAT+ (Battery Rail).

• The Fix: You moved the red wire to BAT+, creating a bridge that allowed the battery to power the ESP32 directly.

Phase 6: Power Management & Final Polish

• The Remote Strategy: We decided to remove the physical ON/OFF switch for the Remote unit to make it sleeker.

• Deep Sleep: We wrote code that keeps the Remote in a "coma" (Deep Sleep). Pressing the button wakes it up, fires the signal, and puts it back to sleep in milliseconds.

• LED Management: The red power LED stays on permanently (hardware limitation), but we added code to flash the Blue LED (GPIO 8) to confirm the signal was sent.

• Mechanical Mounting:

• We discussed using 3M VHB tape to mount the servo to the camera to withstand the upward force of the button press.

• You calibrated the servo angle to exactly 45 degrees to press the shutter without stripping the gears.

The Final Result

You now have a two-part system:

1. Receiver: Attached to the camera, powered by a switch, rechargeable via USB-C.
2. Remote: A tiny, always-ready fob that lasts months on a charge, communicating via a high-speed, router-free protocol.