How Delta Robotics uses Protoboard to design artificial muscles
At Delta Robotics, we've been building artificial muscle technology for three years — and for the past year, we've been integrating AI agents into our hardware design toolkit. This post is about what that actually looks like: how we use Protoboard, the platform we build, to design the hardware we sell.
We're a hardware startup with two sides. We build robotics components — pneumatic and SMA (shape-memory alloy) artificial muscle products, and we also build software tools to manage hardware ecosystems, because building the muscles taught us, expensively, that those tools didn't exist.
The lessons that started it_
Nitinol artificial muscles are an unforgiving R&D project. Two stories from our own shop, out of many:
1. The MOSFETs. Our SMA muscles are current-hungry. During development, they pulled more current than our drive electronics were specified for and burned out our MOSFETs. Every number needed to catch that — the ThermoFlex muscle's current draw, the transistor's limits — was printed in a datasheet somewhere. Nothing in our workflow ever put those two numbers next to each other.
It took three board revisions to get the drive electronics right. The first prototype failed. The second worked well. The third ThermoFlex Controller was a refinement after overcompensating on the second. If the current mismatch had been caught at design time, the first spin would have worked, and the middle prototype would never have existed: a full cycle of design, order, assemble, and test, cut out.
2. The pressure sensor. We built a pneumatic test rig with a piston to exert force against the muscles under development. The parts were ordered, mounted, and wired before we discovered the pressure sensor spoke a language our microcontroller couldn't hear: a variable current output that an Arduino's analog input can't read directly. Not a broken part. Not a bad design. A protocol mismatch between two components that each worked perfectly on their own. It cost us three weeks.
Here's the rig in action once we got it working:
Neither failure was exotic -- we caught many others early. But a real hardware project spans 50 to 200 components with specification surfaces running to thousands of pages. One Texas Instruments part we use ships a 254-page datasheet on its own. No engineer holds that in their head, so the truth fragments across CAD, datasheets, spreadsheets, and memory, and the mismatches surface after the parts are bought. That's the problem Protoboard was built to close, and we are its heaviest users.
How Protoboard fits into our design loop today_
Planning products, not just projects. Our muscle ecosystem — actuators, drive electronics, sensors, test rigs — lives in Protoboard as structured, validated system designs with embedded context. When we plan a new product revision, we start from the real parts and real constraints of the last one, not from a blank schematic and tribal memory.
Validating internal projects as we design. Every component in a Protoboard project carries actual manufacturer data, compressed into a structured definition the engine can check (that 254-page datasheet becomes ~42 KB, with every value traceable to its source). The engine validates connections continuously and refuses with a reason: "that sensor is 5V logic, your MCU is 3.3V only." "That output is a current loop; this analog input can't read it." The exact mismatch that cost us three weeks now gets caught on the canvas, before anything is ordered.
Agents that can't hallucinate the hardware_
Over the past 2 years, agents have completely changed how we work. The obvious use case is for software devlopment, which we use them for religiously. But AI agents are also genuinely good at hardware design work — reading datasheets, proposing parts, drafting wiring, writing firmware. But language models are non-deterministic: ask the same hardware question a thousand times, get a thousand slightly different answers, sometimes not even citing the datasheet page it came from. Point an agent at a complicated part and it will hallucinate — plausible pinouts, invented compatibility. Some of it is the training data missing structured representations of hardware in a simalar way to code, and a lot of it is because there aren't as many methods for validating hardware setups like there are compilers, type checkers, and debuggers for software.
Protoboard's validation engine is what makes agents safe to use. It gives the agent a verified baseline to model hardware against: our agents (Claude, Codex, or Gemini, connected through the Protoboard MCP) work from the real system — every pin, rail, and protocol — and every proposal they make has to pass the same deterministic checks a human's work does. Same inputs, same constraints, same result, every time. AI suggests, selects, and proposes; the engine enforces, checks, and refuses with reasons. The agent writing our muscle-controller firmware matches the validated system instead of guessing at it. We find ourselves having to fill fewer and fewer context gaps when the Protoboard hardware diagram is at the center of development.
Dogfooding_
We didn't build Protoboard as a product idea and then look for a use case. We built the muscles first, hit the wall every hardware company hits — no source of truth for what works with what — and decided to build platform we needed. Three years of artificial muscle development is now the reference implementation: our parts library, our product plans, and our validated integrations all live on the platform, and every lesson from the shop feeds back into the engine.
Our hardest case is our Ryzers project — a pneumatic-powered exoskeleton that lifts you a couple of feet into the air, powered stilts for hanging drywall, cleaning gutters, or reaching anything high without a ladder. It's a multi-domain machine where electronics, pneumatics, and mechanical linkages all have to work together, so in Protoboard it becomes the connector layer between the mechanical CAD and the control-PCB schematics. Validation earns its keep hardest in the pneumatic chain, which steps a paintball tank at roughly 1,200 psi down through a series of regulators and fittings to the 60–100 psi the muscles run on — a chain where one wrong fitting or misread pressure rating is the difference between an exoskeleton that lifts you and one that fails.
More than 1,100 engineers now design and validate on Protoboard, from a Texas Tech engineering program to hardware companies running commercial pilots. They're hitting the same wall we did. That's why we keep building.
Try it yourself_
Whether you’re building your own project or running a hardware team, there’s a way in.
Validate before you fabricate.