What seven months of manual C++ got us, and what it cost​

By May 2024, a small team — a handful of developers — had built an ESP32-S3 system with IMU-driven driving state detection, a working TFT display with animated faces, a custom PCB at Revision 4, audio output, touch sensing, and real in-car testing. Every driver, every state machine, every display routine, written by hand in C++.

It worked, but it was slow to extend. Adding a feature meant a deep C++ dive. Testing meant reflashing hardware. The iteration loop that felt fast in October 2023 had gotten heavy eighteen months later. Hardware stayed parked at PCB Revision 4.

Why ESPHome​

Near the end of 2025, unrelated to Kamoji at first, we started exploring whether our decade-old custom IoT stack — the smart home and office automation systems Originally US runs internally — could move onto established open-source platforms: Home Assistant and ESPHome. Maintaining custom firmware at scale is a tax on a consultancy's time, and the open-source ecosystem had matured enough that moving made sense.

That exploration fed straight back into Kamoji. If the goal was maker-friendly and open-source, ESPHome was the better fit than Arduino: a broader community, declarative YAML configuration instead of raw C++ for the basics, and built-in OTA, WiFi provisioning and sensor abstractions that Kamoji needed anyway. The decision was made: when Kamoji restarted, it would be rebuilt from scratch on ESPHome.

Writing firmware with an AI toolchain​

The other thing that had changed was how we wrote code. A few months before restarting Kamoji, the team had started using ChatGPT to help write ESPHome YAML for simpler IoT boards — single-file configs for basic switches and sensors. Low complexity, but it worked, and it was how we learned the ESPHome model in parallel with experimenting with AI-assisted development.

Then Google Antigravity launched, with the ability to reason across multi-file codebases and help design custom ESPHome components in C++. That made it possible to apply the same approach to something as complex as Kamoji — work that would have taken months by hand became tractable in days. The ESPHome migration and Antigravity as the tool for it are what unlocked the project's second phase.

What that pace actually looked like​

The new ESPHome repository was created on December 24, 2025. We set up auto-commit so that every file save during development pushed to git, turning the log into a continuous trace of the work rather than milestone markers.

469 commits in the first week. Multiple YAML configurations ran in parallel from day one — different display setups, different microphone configurations, experiments that would have needed sequential weeks in the manual era running side by side instead.

January 2026 was the busiest month in the project's history: 718 commits, including 91 in a single day — January 19, a Sunday. kamoji-production.yaml appeared on January 10, the first config explicitly labelled for production hardware. Two of the more complex pieces of the system, kamoji_fft_audio_processor and kamoji_gif_player, showed up by late January — the audio processor analysing microphone input in real time to detect music and sound events, the GIF player rendering animated sequences on the display at high frame rate.

By February 12, kamoji-core.yaml — the 2,781-line master configuration that became Kamoji's brain — existed. In April the codebase was reorganised out of that monolith into 19 discrete custom components, each with its own interface and independent testing: kamoji_imu, kamoji_gforce, kamoji_dynamic_eyes, kamoji_espnow, kamoji_ui_navigation, and more. That's the kind of restructuring you do when you expect other people to maintain, extend and contribute to the code — which was the point of moving to ESPHome in the first place.

This is the third post in a series on how Kamoji got built. Next: why Kamoji works the way it does — no touchscreen, offline by default, and where the ferrofluid visualizer came from.

No touchscreen​

This was decided early and never revisited. The reference point was cheap smartwatches with tiny touchscreens: imprecise, quick to pick up fingerprints, and a category that shows exactly why a touchscreen isn't always the right interface on a small device. Physical buttons are more reliable and more appropriate for something that lives in a car, where your attention should be on the road rather than on hitting a target on glass. It's also consistent with where automotive interiors are heading generally — manufacturers went from buttons to touchscreens and are now moving back toward physical controls.

Offline by default​

There's a category of product that's essentially an open-source AI assistant in small-robot form — always-on cloud connectivity, voice recognition, the works. We looked at that category and decided against it: always-listening microphones raise real privacy questions, and depending on a cloud service means depending on its uptime, its latency, its API costs, and its continued existence. Kamoji is designed to be a fully standalone, offline experience — plug in power and it works, no WiFi setup, no account.

That doesn't rule the option out for people who want it. Kamoji's architecture is open-source and the hardware can support it — makers who want to build an AI assistant on top of the board can, and we've published a tutorial showing how: XiaoZhi on Kamoji: voice assistant firmware, end to end. We just don't think it should be the default for everyone.

The ferrofluid visualizer​

Ferrofluid is a magnetic liquid that forms spikes and flows in response to sound and motion — a niche product most people have never encountered, because ferrofluid displays are expensive and rare. There isn't a digital ferrofluid simulation that does the effect justice, so Kamoji doesn't try to simulate the fluid itself. It uses a metaball simulation instead, which produces visually similar organic, flowing forms in real time on the display. Most people who see it won't know what they're looking at technically. That's fine — the effect is the point.

Takumi's Cup Challenge​

The metaball work proved what the display could do with particle effects, which led to a full fluid simulation driven by the gyro sensor: the Cup of Water Test, run inside the device itself. We started with a flat water surface that tilted with the gyro reading, then kept pushing toward more realistic fluid behaviour — under one constraint throughout: the water had to look and behave like liquid and be fun to watch, not just physically accurate. Getting both at once took a lot of iteration.

G-force, without pretending to be a lab instrument​

G-force sensors show up almost exclusively as factory-fitted systems in high-end vehicles — there's no real aftermarket accessory market for them. Kamoji has one, and it isn't lab-grade: the reading depends on where the device sits in the car, how it's oriented, and other variables that aren't controlled for. It doesn't need to be scientifically precise to be useful. It's accurate enough to compare meaningfully between vehicles and to show how a driving style changes the numbers on the same car — which is essentially what it's for. We expect owners to compare scores and argue about them.

OTA updates, without a mandatory app​

Kamoji works fully without a phone, an app, or a cloud account. OTA firmware updates exist and reach every unit in the field, but they're opt-in, with no subscription attached. The OTA system itself isn't new: it's the same deployment infrastructure that already runs across hundreds of Originally US's own IoT installations, refined over more than a decade of keeping those systems running in production. That's an unusual decision for a mobile app company to make — an app that's genuinely optional — but it's the one that matches how Kamoji is supposed to work.

This is the fourth post in a series on how Kamoji got built. Next: learning industrial design from scratch, to get the helmet right.

The bar we set​

We're used to designing technical components — PCBs, structural frames, sensor mounts, assembly tolerances. None of that translates to designing a product's outer form: curved surfaces, a silhouette that communicates personality, a shape that invites touch. That's a different discipline, and we had none of it going in.

The requirements were deliberately demanding. The helmet needed to be timeless rather than a trend that dates itself in two years. It needed to read across cultures and age groups. It had to be clearly its own thing, not a derivative of a competitor's shape. It had to be swappable, the way competing products let you customise the shell. And — for the maker and open-source angle — it had to be printable on an entry-level consumer 3D printer, no exotic materials or equipment required.

Where external designers didn't work, and where sketches did​

We brought in external industrial designers to explore concepts first. It didn't go well — the results either missed the timeless, cross-cultural brief, the character didn't read right, or the geometry didn't work with the inner frame's physical constraints. We came away with a clear list of what we didn't want, which is something, but not what we needed.

The actual breakthrough came from hand-drawn sketches on paper, fed into AI image generation tools to produce polished visual concepts from the rough gesture of each sketch. It worked immediately — a range of directions to react to and choose between, at a pace no single designer could match on their own.

Concept images aren't CAD models, though — no tolerances, no wall thicknesses, no assembly logic. The next step was a human designer taking the chosen direction and turning it into real geometry: a file we could pull dimensions from, iterate on, and eventually send to a printer.

Kodo as the filter​

For the CAD refinement stage, we used Mazda's Kodo — Soul of Motion design philosophy as a reference: no sharp edges, surfaces that flow into each other, lines with direction and tension, as if caught mid-movement. Every decision in refinement ran through that filter — a hard transition got softened, a line that broke the flow got rethought. Having a named design language to check against kept the iteration focused instead of open-ended.

Fitting the shell to what's inside it​

The visual design being finalised was only part of the problem. The helmet also had to physically fit over the inner frame, align with the display window, and click into place with a precise, satisfying snap. That took its own round of iteration — print a prototype, check the fit, adjust tolerances, print again. Most prototypes had at least one thing wrong. Each one told us something.

Everything was finalised in May 2026, about two months after the industrial design work started.

This is the fifth post in a series on how Kamoji got built. Next: scaling from 200 hand-checked units to a manufacturing partner, and what changed along the way.

Settling on beige​

The final weeks of April tested multiple colorways side by side — red with a yellow visor, white and beige rounded forms, grey and black with red touch pads — alongside rubber display gaskets at different tolerances.

The beige/cream body is the one that stuck: compact enough to sit in a palm, with the display showing an animated face looking back at you.

Scouting for scale​

With the design locked, we visited a manufacturing partner in Vietnam to talk through what the next phase of production would need — not a vendor for the first small batch, but a factory that could take Kamoji into the thousands: sourcing, assembly, packaging, export documentation and compliance certification, end to end.

The floor was in active use — assembly lines running, component shelving along the length of the space.

The warehouse held floor-to-ceiling racking, organised stock and logistics infrastructure already in place.

A dedicated assembly line sat idle, ready to be brought online for a new order —

— and, notably, an in-house SMT room behind clean-room doors, meaning PCB assembly at scale without outsourcing the most technically demanding step to a separate vendor.

What 200 real units taught us that no prototype could​

April 2026 also brought the first small manufactured batch: 200 units. Not hand-assembled one-offs, not 3D-printed proofs of concept — real units through real manufacturing, with the design fully committed.

We design everything in-house, but turning that design into a physical product means coordinating vendors who each own a piece of the process: PCB fabrication and assembly, structural 3D printing, the helmet shell, packaging. Nearly every one of them produced a surprise.

The sharpest one: a fabrication issue during PCB manufacturing altered part of the primary circuit path on the whole batch. We didn't have to scrap it, because we'd already designed for exactly this possibility — Kamoji's PCB deliberately includes duplicate and backup components on certain circuits, the kind of redundancy that never makes it into a textbook-efficient board layout but exists for moments like this one. When the primary path broke, the backup held, and the batch shipped. It's the sort of design decision that looks wasteful right up until it isn't.

With 200 boards to validate, manual testing wasn't realistic, so we built a test rig: a fixture that loads firmware onto each board and runs a semi-automated sequence checking that every sensor works before the unit clears for assembly. A unit that ships with a dead IMU or microphone isn't just a faulty product — Kamoji's whole personality depends on what its sensors tell it.

Education before conversion​

With manufactured units in hand, we stood up a dedicated marketing effort to introduce Kamoji properly. In-car accessories and dashboard companions exist in quantity already, but a character-driven, sensor-integrated, open-source companion that actually understands what the car is doing is not a category most people have encountered yet. That makes the first challenge education, not conversion — showing people what it does and how it feels to have one, before asking them to want it.

What this project actually is​

Kamoji is the product of accumulated experience: a decade of Originally US running its own IoT infrastructure in production, and a CTO whose background spans mechanical design, electronics, firmware, software, animation and video production, with a hand in every part of this device.

The team operates on one non-negotiable principle: no deadline, no compromises. Kamoji took as long as it took — a 19-month pause included — because shipping something we weren't proud of wasn't an option. Going fully open-source from day one reinforces that by removing anywhere to hide: every line of code, every schematic, every component choice is visible to anyone who knows what they're looking at. That's uncomfortable in a useful way. No shortcuts, no "fix it later" — every custom component and every redundant circuit has to be something we're willing to defend in public.

The device isn't finished. It's real, it runs, it has a face, and people can buy it.

Where things stand now: the R8 board finished full testing in late July 2026 and is moving into FCC certification.

This is the last post in our series on how Kamoji got built. If you missed the earlier ones: origins, the PCB and open hardware, the ESPHome rebuild, and feature philosophy.

The first task wasn't building a prototype. It was picking a screen.

The screen comes first​

The display is the single most important electrical component in Kamoji. Every reaction the device has — its personality, its expressions — comes through that screen. Get it wrong at the start and you're rebuilding from the wrong foundation. So on September 26, 2023, before any firmware existed, we ordered five LCD modules spanning different sizes, resolutions and screen technologies.

They arrived two days later.

• 0.96" 80×160 RGB IPS — the smallest
• 1.3" IPS 240×240 (GMT130-V1.0)
• 1.44" TFT SPI 128×128 (red PCB)
• 1.8" TFT SPI 128×160 (red PCB)
• 2.0" TFT SPI 240×320 (GMT020-02) — the largest

One by one, each went on a breadboard, got firmware flashed, and was judged on how it rendered.

The 1.3" IPS 240×240 (GMT130-V1.0) won — the highest pixel density and the most vibrant color of the five. By 1:33 PM the next day — September 29 — the prototype was already in a car. Not for a proper drive: the IMU was wired in, reading pitch, roll and yaw, and the display sat on the seat showing the live numbers as the rig was tilted by hand. The gyro was being tested in a real car on day one of wiring anything up.

The firmware said "Originally US v0.10". It wasn't Kamoji yet. But the display was chosen, and it was already in a car.

From sensor readings to a driving state machine​

October 2 was a full day of firmware work — display iteration, IMU tuning — now that the screen was settled. By October 5 the firmware had grown from raw sensor numbers into a real driving state machine: "Cruising" when the car moved, a braking state when it registered braking, "Stopped" when it stopped. The whole rig — wires hanging off a breadboard, the display held up with nothing, a power bank on a USB cable — was strapped to the center console and taken out on an actual drive, early morning, near Ang Mo Kio.

By that evening, the firmware was at v0.99.

What we learned from taking the competition apart​

Before and during this early build phase, we did what we always do when sizing up a product space: bought the competition and took it apart. Not reviews, not product pages — we disassembled the closest competing in-car companion devices and character accessories down to the component level, identified the chips, read the PCB layouts, ran their firmware, and tested how they actually responded to inputs.

Most of them contain no sensors at all — they're character displays, not responsive devices. A few claim a motion sensor that barely registers a violent shake. None had OTA firmware updates worth the name, and none showed an architectural commitment to community contribution.

Kamoji samples its IMU 100 times a second and reacts to lean, brake and bump in real time. We hadn't even made full use of that bandwidth yet, and the gap to what was already on the market wasn't close.

The chip that would carry the rest of the project​

Two weeks in, on October 14, audio got added and tested — literally plugging full-size headphones into the breadboard rig to check the output. Around the same time we mounted an early rig on a 1/12-scale RC kei truck to test IMU response on a moving platform without needing a real car every time.

That's also when we started looking at the ESP32-S3 as a replacement for the ESP8266 we'd started with — dual core, more memory, Bluetooth, native USB. It's the chip Kamoji still runs on today.

By this point the driving states — Cruising, Stopped, Hard brake — were each triggering their own display output on our own firmware, on our own hardware. Three weeks after five screens arrived on a bench, Kamoji had the beginning of a personality.

This is the first post in a series on how Kamoji got built. Next: the ten PCB revisions it took to get to a board we could ship, and why we designed it to be open hardware.

No battery, on purpose​

One decision got made early and never revisited: Kamoji has no internal battery. That's not a cost cut, it's a safety call. Kamoji lives on a car dashboard, and a dashboard in direct sunlight gets hot enough that putting a lithium cell there is a bad idea. Kamoji draws power from the car instead, over USB. Clean, safe, and one less thing that can fail over years of daily use in a hot car.

A display that stopped breaking during assembly​

Up to Revision 7, the display's flex connector was soldered directly to the board — no connector, just a permanent joint. That was fine on a bench. It was not fine once full assembly started: the tight fit inside the helmet was cracking screens during assembly, and a broken screen soldered straight to the board meant desoldering the flex cable and soldering in a new display by hand, every time. Slow, and easy to damage something else in the process.

R8 replaced that joint with a removable FPC connector, so a cracked screen during assembly (or later, in the field) is a matter of unclipping one and clipping in another — no iron required.

Staying awake just long enough to say goodbye​

Having no battery raises an obvious question: what happens the instant you unplug it? On the R8 board, the answer is a supercapacitor — not a battery, and not meant to run the device independently, but enough charge to keep Kamoji powered for a few seconds after USB power is cut. That's enough time to save trip statistics and play a short goodbye animation before shutting down cleanly, instead of just going dark mid-frame.

R8 also added a pogo-pin connector on the underside of the board — magnetic, in the same spirit as Apple's MagSafe, so an accessory snaps into alignment rather than needing to be plugged in precisely. It's unpopulated today. It's there for future expansion — additional sensors, or an external battery pack for people who want to run Kamoji off the dashboard entirely, say sitting on a desk. Nothing ships on that connector yet. It's board real estate reserved for later, on purpose.

Two boards, one board, two boards again​

The production board is labelled R7.2, which undersells it — the actual count is at least ten distinct iterations. Version numbers don't increment neatly when you're learning fast and reversing decisions.

Revision 1 split the electronics across two PCBs in an L-shape. That wasn't arbitrary: at that stage there was still real uncertainty about which sensors would survive contact with reality, so committing to a single compact board would have meant locking in answers we didn't have yet. Two boards also left room for the debug headers and test points that early-stage hardware needs — real estate you don't want competing for space on the board you eventually ship.

Revision 2 combined the two boards into one flat PCB, on the logical assumption that simpler is better. It introduced two problems we hadn't anticipated. The USB-C port stood vertically proud of the board surface — mechanically fragile, a bad fit for a device that gets handled often. Worse for the product direction: a flat board is geometrically hostile to a rounded enclosure. There's no elegant way to wrap smooth, curved surfaces around a rectangular slab.

Later revisions went back to two boards, but better than Revision 1: the USB-C connector redesigned into a recessed, more robust mount, and the L-shape replaced by a stacked arrangement that worked with the helmet geometry instead of fighting it. The two-board split also opened a future the single board had closed off — the lower board can be revised independently, so future hardware can add sensors or connectivity without a full redesign of the main board.

The lesson: don't simplify for simplicity's sake. Simplify when the trade-offs are actually better, not just when there are fewer parts.

Building a board other people can actually work on​

From day one, the plan was to fully open-source Kamoji once it shipped. That's a product philosophy, not an afterthought — Originally US has a long history with open source, and we wanted the firmware platform to let people hit the ground running. That's the reasoning behind starting on Arduino: the most established maker platform, with the largest community and the least friction to get started.

The same philosophy runs down to the components on the board. The rule was: good enough for production, small enough to keep the board compact, but never so small that the maker community can't source or hand-solder a replacement. The smallest component on the board is 0805 — we deliberately stayed off 0603 or 0402, sizes most makers aren't comfortable soldering by hand. Most of what's on the board is popular, well-documented, and easy to buy.

We also left deliberate room for advanced makers to wire in their own sensors and attachments beyond what Kamoji's own firmware uses. That's an intentional invitation, and it's the reason we're planning a tutorial and video series under the name "Made with Kamoji" — projects that use the Kamoji board as a development platform for things that have nothing to do with Kamoji itself.

This is the second post in a series on how Kamoji got built. Next: the 19-month pause, and rebuilding the firmware from scratch on ESPHome.

Put a full, open cup somewhere in the car. Drive. If you arrive with the cup still full, you drove smoothly. If you arrive wearing it, you didn't.

It sounds like a party trick. It's actually a fairly precise instrument, and it's the idea behind Takumi's Cup Challenge in Kamoji.

Where it comes from​

The test is best known from Initial D, the street-racing manga and anime.

Takumi Fujiwara spends his mornings delivering tofu up Mt. Akina in his father's Toyota Sprinter Trueno — the AE86 — starting at four in the morning. His father Bunta puts a cup of water in the car and tells him not to spill it. Tofu is delicate cargo, and the water stands in for it.

Takumi does this every morning for five years, in every kind of weather, believing he is just delivering tofu. He is in fact being taught weight transfer, braking control and how to carry momentum through a corner, by a father who never explains what the cup is for.

It's a good story. It's also good engineering, because the cup is measuring something real.

What the cup actually measures​

A liquid surface always settles perpendicular to the total force acting on it. Standing still, that force is gravity, and the surface is level. Under cornering, braking or acceleration, the water tilts — and the angle is not arbitrary:

tan(θ) = a / g

Where a is the acceleration the car is pulling and g is gravity.

The dashed line is where the surface sits at rest; the gold line is where it sits under cornering. That gives you a direct readout:

The cup isn't a vague indicator of niceness. It's an accelerometer with a tilt display.

Why it's harder than it sounds​

Whether you spill depends on the cup as much as the driving. The surface pivots about the centre, so the water climbs by r × tan(θ) at the outer edge, where r is the cup's radius. It goes over the side when that climb exceeds the freeboard — the gap between the water and the rim.

For a cup about 8 cm across:

Fill it to the brim and you're being graded at around a tenth of a g, which is stricter than most people drive on a motorway slip road. Leave a couple of centimetres and you have room for genuinely brisk cornering.

Here is the same corner — the same 0.30 g — in three cups filled to different levels:

This is why "don't spill the cup" is a difficulty dial, not a pass/fail. Bunta chose the fill level.

One more wrinkle: it's not only about peak g. Water sloshes, and a cup has a natural sloshing frequency. Two corners taken at the same peak g will produce very different results depending on how quickly you loaded and unloaded the car. A slow, deliberate input the water can follow beats a sharp one it can't — which is exactly the habit the exercise is trying to build.

Driving to keep the cup full​

The technique that keeps water in a cup is the same one that keeps passengers comfortable and tyres working:

• Squeeze, don't stab. Brake and accelerate progressively. Jerk — the rate of change of acceleration — is what throws the water, not acceleration itself.
• Do one thing at a time. Finish braking before you turn in. Combining braking and cornering adds the two forces together diagonally.
• Straighten the corner. A wider, smoother line through a bend needs less lateral acceleration than a tight one at the same speed.
• Look further ahead. Almost every sharp input is a late reaction to something you could have seen sooner.
• Release as carefully as you apply. Coming off the brake abruptly unloads the nose and sloshes the water back the other way.

None of this is about going slowly. A smooth driver can be quick. That was rather the point of Takumi.

Where Kamoji comes in​

Kamoji reads acceleration with its own sensors, so it can show you how many g the car is pulling in real time — and it runs Takumi's Cup Challenge, the same test without the mopping up.

You can see both in the feature reference. Setup is a USB Type-C cable and nothing else; the Getting Started page covers it.

Bunta would probably say the real version builds more character. He's not wrong. But the water never told anyone what it measured, and Kamoji will.