Wrangling Automation
OF Robots, Reality, and Repeatability
It’s a cold, quiet winter morning in the American midwest. I’m sitting at the head of a long gray conference table, tucked into a cramped factory office room between reams of printer paper and cases of Cup-A-Noodles, and like the rest of the crew, I’m trying to warm up my hands and make sense of what I’m seeing. Spread out on the table before us is a 2-foot by 3-foot printed paper stack being held flat by our many hands, plus a few tape measures. We’re all sipping our coffee and nodding our heads, eager to build the thing that it represents.
This is the CAD, and it’s what shows up first, of course. A clean, bloodless proposition. Thin lines of measured delineation, obedient angles, a kind of corporate séance scroll. “Behold the automation cell that shall be!”, summoned out of bézier curves and splines and the unspoken desperation of project deadlines.
And then we all get up and head into the factory proper, where the air has real weight.
If you’ve never walked onto a manufacturing floor with a “finished design” in your hand (and one however fuzzy in your head), you might still believe in repeatability the way some people believe in sports-betting. You might even think a robot cell is a thing you simply install, like a bathroom sink. But in the real world, where the concrete slab was poured by a guy who “eyeballed it,” where the mezzanine was added after the fact, where the forklift lanes are sacred and the coffee machine has more uptime than the plant Wifi network, CAD is less blueprint than suggestion. It’s a polite letter to physics, asking if it wouldn’t mind stepping aside for a moment to allow perfection to exist.
In my experience, physics never steps aside.
This is where I live. This is where Studio Compute lives. I’m the founder and CEO, sure, but titles are just the thin plastic sleeves over the machinery. When the build starts, I’m also the one on the ground, hands on, sleeves up, leading by example. This is not out of branding necessity. It’s because the cell doesn’t care what my email signature says. It cares whether the E-stop chain behaves, whether the network pings, whether the vision system can see through the factory’s particular mix of light color temperatures, whether the tooling does what the sales team promised in the meeting, and whether the whole production line can keep moving without the robot turning into a very expensive statue.
People ask how I got here, as if there’s a clean line from past to present, a career ladder, a tidy narrative. The truth is messier, and more interesting. A twenty-something-year baptism in data center operations taught me that everything is physical, even the stuff people insist is “in the cloud.” That experience collided with a personal history of filmmaking, mechanical tinkering, and hybrid audio-video production.
Those worlds all share a secret language.
“If you can build a bike, you can build a robot.”
Filmmaking teaches you systems thinking under pressure. A set is a living machine with too many moving parts and not enough time. In film school, and in life, I learned to coordinate people who have different vocabularies but the same creative goal. I learned that the plan, while entirely necessary, will fail, and that you must adapt without losing the plot, literally or otherwise.
Assembling, customizing, and riding bicycles teaches you mechanical tolerance in your fingertips. Inheriting the obsession from my dad, bicycles taught me how load moves through material, how a small misfit becomes a big problem six miles down the road. They taught me how steel doesn’t care about your intention; it only cares about your execution. Frankie Ochoa, the man who’s known me for years and introduced me to robotics, famously said, “If you can build a bike, you can build a robot.”
Audio production teaches signal discipline. It taught me about noise, be it electrical, human, or environmental. It taught me that a clean feed is earned, not assumed (and is sometimes undesired). It taught me that the tiniest bad connection can ruin an entire project. Shift your outputs and you are basically in manufacturing.
And data centers, those temples of perpetual uptime that have suddenly become household names, teach you that the most expensive problems are often the simplest ones in disguise. A looped cable. A power budget that looked fine until someone turned on the wrong row. A cooling pattern that behaves until the season changed. A dependency nobody documented because “it always worked before.”
Now put all of that into an industrial robotics build. Mechanical, electrical, pneumatics, safety, networking, controls, chip-level processing, vision, sensors, rails, guarding, interlocks, protocols, operators, supervisors, maintenance crews, vendor firmware, and the ghost of every “temporary fix” that became permanent three years ago.
It sounds like chaos. It kind of is chaos.
But it’s all familiar.
When I’m building an automation cell, I’m not just “integrating a robot.” I’m translating between domains that don’t trust each other. I’m turning a computer drawing into a living, breathing, money-making (and money-saving) organism that can survive in a factory with a unique footprint, one that refuses easy repeatability like a cat refuses its bath.
Because that’s the actual job. Not the demo, or the render. Not the slide deck with the robot arm posed like a Russian ballerina. The job is making the thing work when a dropped flashlight rolls across the factory floor like a spindle, when the parts show up in the wrong order, when the air line hisses at you, when the “standard” cycle time is based on optimism, and when the human beings who run the line need the system to be understandable at 0600 on a Tuesday.
A robotic cell must be more than clever. It must be durable, legible, and serviceable. It must tolerate the unglamorous reality that manufacturers live in. Dust, vibration, snow, heat, production pressure, shift changes, imperfect inputs, and the kind of improvisation that keeps a plant alive.
So I approach it the way I’ve approached every real system I’ve ever had to make behave. Start with the constraints, identify the failure modes early. Respect the physical layer, you’ll probably be making blood sacrifices to it. Speaking of which, you need to treat safety like a first-class citizen, not an afterthought. Label everything, and do it with the contractor in mind. Document the stuff you’ll swear you’ll remember later (you won’t). Assume things will break, and build so the breaking doesn’t become a catastrophe.
And I stay close to the work. Not because I don’t trust a team. Studio Compute is full of capable people. I do it because leadership in this world is not a remote job. The cell doesn’t need a visionary in a suit on a Zoom call telling the team they’ll circle back after lunch. It needs someone who can put a hand on the chassis, hear the relay chatter, smell the overheating motor before it becomes a safety shutdown, trace a bad ethernet cable, and make the call: is this a software problem, a wiring problem, a mechanical problem, or a “we designed this in a room with purified air” problem?
In the end, automation isn’t about replacing people. It’s about making the work more consistent, safer, and more scalable. It is about freeing skilled operators from the repetitive, punishing tasks that grind morale into powder. It is about turning variability into throughput, and unpredictability into quality. It is about building a system that pays for itself not in theory, but in the only metric factories truly worship. The line keeps moving.
The CAD will always show up first, clean and confident, like a venerated prophecy.
My job, our job at Studio Compute, is to take that prophecy into the loud, imperfect, dirty world and make it true.
Afterword
The visuals accompanying this article are AI-generated illustrations. I’m under NDA on client work, so I can’t share photos from the actual builds, but I still wanted to give you something that captures the feel of the environment and the work.
