Latest / Hardware Startups with Fexingo: Devices, Robotics, and Manufacturing Tech Companies / How Hardware Startups Use Digital Twins to Prototype Faster
Transcript
- Lucas: If you are a hardware founder and you are still building five physical prototypes before you get to a version that works, you are leaving months and probably hundreds of thousands of dollars on the table. The alternative that more and more startups are adopting is the digital twin. Luna: I have heard the term digital twin thrown around a lot — usually by software people who think it means a 3D model with some arrows on it. What does it actually mean for a hardware startup? Lucas: Fair question. A digital twin is a virtual replica of a physical device that mirrors not just its geometry but its behavior in real time or near real time. The key word is behavior. It is not a static CAD file. It is a living simulation that ingests data from sensors on the actual hardware and uses that data to predict performance, identify failures, and suggest design changes. Luna: So you need both the virtual model and the physical sensors talking back to each other. That sounds expensive for a startup still figuring out product-market fit. Lucas: It can be, but the economics are shifting fast. I want to talk about a specific case: a startup I will call Motive Robotics — they make small autonomous material-handling robots for warehouses. In 2024, they used a digital twin to cut their development cycle from 18 months down to 9. They were able to validate their drive train, battery thermal management, and obstacle avoidance algorithms in simulation before they ever ordered a single PCB. Luna: Nine months instead of eighteen — that is huge. How did they get the twin accurate enough to trust? I have seen startups burn money on simulation because the model was wrong and they ended up building prototypes anyway. Lucas: They layered the twin. That is the framework I want to walk through because it is practical. The first layer is geometry — the CAD model with correct mass, moments of inertia, and joint constraints. The second layer is physics — material properties, friction coefficients, thermal conductivity, all validated against a small set of real-world measurements. The third layer is data — telemetry from the first physical unit, which feeds back into the twin to correct the model. Luna: So the first physical unit is not a prototype in the old sense — it is more like a calibration device. Lucas: Exactly. Motive Robotics built one physical robot, instrumented it with about forty dollars worth of off-the-shelf temperature and vibration sensors, ran it through a few dozen test cycles, and used that data to tune their simulation parameters. After that, they ran thousands of virtual test cycles — different payloads, different floor surfaces, different ambient temperatures — in about two weeks. They found a motor overheating issue that would have taken them another three months to discover through physical testing. Luna: That is the kind of story that makes me want to ask: why is not every hardware startup doing this? What is the catch? Lucas: The catch is that building a useful twin is hard. Most founders I talk to start by either buying a tool like Simulink or Ansys without knowing what they want to simulate, or they over-invest in visual polish — making the model look pretty — when the real value is in the physics and the data loop. A good rule of thumb is: start with one subsystem. Do not try to twin the whole product at once. Pick the riskiest subsystem — the drivetrain, the battery, the thermal management — and twin that first. Luna: I have heard founders say their investors pushed them to digital twin because it sounded cutting edge, but then they spent six months building a model that nobody trusted. That seems like a real risk. Lucas: It is. And that is why the data layer matters so much. A twin that has never been calibrated against real measurements is just a simulation — and simulations can be wrong in spectacular ways. The Motive Robotics team did something smart: they published their twin predictions alongside their physical test results in their internal design reviews, and they tracked the prediction error. They required that the twin predict the motor temperature within plus or minus two degrees Celsius before they would let it drive a design decision. Luna: That is a concrete standard. Two degrees. That gives the team confidence without blind faith. Lucas: Right. And that discipline paid off when they scaled. They are now running a fleet of about 200 robots in three warehouses, and each robot streams telemetry back to the twin in near real time. When a robot starts drawing more current than expected, the twin flags it and suggests a maintenance routing or a control parameter adjustment. That is the holy grail — a twin that not only helped you design the product but helps you operate it. Luna: That is a long way from a CAD render. So for a hardware startup listening right now who is maybe in the early prototyping phase, what is the one concrete step they should take this week to move toward a digital twin approach? Lucas: Pick the single most critical failure mode for your product. If you are building a drone, it might be motor overheating or battery sag. If you are building a medical device, it might be force accuracy or thermal limits. Write down the physical parameters that govern that failure mode — things like thermal resistance, coefficient of friction, stiffness. Then go buy a sensor that measures one of those parameters. Run one test. Compare the sensor data to a simple analytical model. That is the seed of a digital twin. You do not need fancy software at first. Luna: I like that. Start small, validate early, and only invest in bigger tools once you have proven the loop works. It is the same build-measure-learn cycle, just applied to the simulation itself. Lucas: Exactly. And if you are finding these conversations useful for what you are building or running, it is worth mentioning that listener support is what keeps this show independent and ad-free. A couple of dollars a month is genuinely what keeps these going — buy me a coffee dot com slash fexingo, if you have gotten something out of them. Luna: Yeah, it really does make a difference. Every contribution helps us keep digging into topics like this. Lucas: So back to the practical side — once you have that seed twin working, the next step is to formalize the feedback loop. Motive Robotics used a simple Python script that grabbed sensor data from their robot every ten seconds, pushed it into their simulation environment, and re-ran a short prediction of the next five minutes of operation. That let them detect deviations early. Luna: That is almost like continuous integration for hardware. I know CI/CD is standard in software, but it is rare to see it applied to physical products. Lucas: It is becoming more common. There is a term for it: hardware-in-the-loop continuous testing. The idea is that every time you update the firmware or change a component, you run a battery of simulated scenarios against the digital twin before you commit to a new prototype run. That alone can catch regressions that would otherwise slip through until the next physical test. Luna: But this requires some investment in test automation and data infrastructure. What is the minimum viable stack for a three-person hardware startup? Lucas: A Raspberry Pi or an Arduino for data acquisition, a few sensors — temperature, current, maybe an IMU — and a free or low-cost simulation tool like OpenModelica or even a spreadsheet for simple systems. The hardest part is not the tools; it is deciding what to measure and how often. Do not try to measure everything. Measure the three variables that directly relate to your critical failure mode. Luna: So for a startup making a robotic arm, they would measure joint torque, motor temperature, and maybe vibration at the end effector. That is three sensors. That is maybe a hundred dollars in hardware. Lucas: That is exactly the scale I am talking about. And then you start collecting data. After a week of testing, you have enough data to build a simple regression model that predicts temperature as a function of duty cycle. That model is now a very basic digital twin. It will not be perfect, but it will tell you when the arm is running hotter than expected, and that is actionable. Luna: And you can improve that model over time as you run more tests and add more sensors. That is the point where it starts to pay for itself. Lucas: Yes. And the payoff compounds. Once you have a twin that you trust for one subsystem, you can extend it to others. You can also use it to simulate field conditions that would be hard to replicate in your lab — extreme cold, high humidity, dust. That is where the real ROI shows up: avoiding failures that only happen in the field. Luna: I have seen hardware companies lose millions on warranty claims because a seal failed in high humidity and they never tested for it. A digital twin could have simulated that in an afternoon. Lucas: Exactly. And that is the long-term vision: a twin that lives with the product throughout its lifecycle, from design through manufacturing through field operation. The startups that get this right are going to have a massive advantage in speed and reliability. Luna: So the question for a founder listening today is probably: where do I start? I think you gave a great answer — pick your riskiest failure mode, buy a sensor, run a test, build a simple model. But I would add: do not try to impress your board with a flashy simulation. Start boring. Start manual. Let it grow. Lucas: That is the best advice I have heard on this topic. Start manual. The first digital twin does not have to be digital — it can be a graph on a whiteboard. The important thing is that you start closing the loop between prediction and measurement. Luna: All right, good place to leave it. Thanks, Lucas. Lucas: Thanks, Luna. See you next time.