Teams
・
.
.
Hardware never behaves ideally
A conversation with Ethan, AI engineer — MODI Factory
A circuit that appears flawless in simulation often runs into unexpected obstacles—such as noise and thermal hotspots—once deployed in the physical world. Ethan, an engineer on the MODI Factory AI Team, doesn't rely solely on theoretical calculations. Moving back and forth between custom test boards and thermal imaging cameras, he bridges the gap between theory and reality.
Ethan simplified complex thermal simulations that once took commercial tools over 10 minutes down to a lightweight algorithm running in under a minute. We sat down with Ethan to hear how he blends hardware intuition with algorithm design to build the MODI Factory simulator.
Read Ethan's interview if you are:
✅ A developer curious about the technical thinking behind combining PCB design automation with physical simulation
✅ An engineer working to tune models and close the gap between math and real-world hardware physics
✅ A hardware student or engineer who wants to understand the practical mechanics of PCB thermal analysis and heat-dissipation design
Part 1. Hardware at the core
Could you introduce yourself and tell us about your current role on the MODI Factory team?

Ethan, developing the simulator on the MODI Factory AI Team
Hi, I'm Ethan from the AI Team. Currently, I'm developing thermal simulation algorithms for automated PCB circuit design at MODI Factory.
You studied robotics as an undergraduate and control systems in graduate school. How does that hands-on hardware intuition help when designing algorithms for MODI Factory?

A drone Ethan built during his undergraduate studies (Source: Ethan)
Studying robotics and control systems taught me firsthand that physical hardware never behaves as ideally as mathematical formulas suggest. When controlling a robot, for instance, you start with a mathematical model like "one wheel revolution translates to X meters of forward displacement." But in the physical world, there are countless hidden uncertainties and sources of noise: wheel slip, variations in the friction coefficient of the floor, and sensor measurement limits.
Even if you calculate a theoretically optimal gain value through simulation, it rarely works right out of the box in the field. In the end, you find yourself manually tuning the parameters — adjusting values from 2.0 to 2.1 to 2.2 — iterating until the system stabilizes in its actual environment.
That's why, when designing algorithms for MODI Factory, I don't jump straight to mathematical formulas. Instead, I first identify which physical phenomena are critical on a real PCB and which conditions need to be reflected in the model. That hardware-grounded intuition helps me simplify the model appropriately while keeping the algorithm closely aligned with real-world behavior.
Among many hardware companies, what attracted you to join LUXROBO?
When I joined, what stood out to me was that LUXROBO doesn't just build hardware — it develops software and algorithms in tandem. I wanted to experience firsthand how those two worlds connect in actual products and services. Today, I work in an environment where I can directly order custom validation boards and run empirical measurements myself.
You've worked across a wide range of domains — from IoT parking systems and autonomous golf carts to circuit design automation. What's your secret to ramping up quickly in unfamiliar fields?

The diverse domains Ethan has navigated: an integrated parking system (left) and an autonomous golf cart (right) (Source: Ethan)
Whenever I dive into a new domain, I start by distilling the system down to its core: its inputs, outputs, and overall data flow. From there, I implement and test small modular pieces, expanding my understanding by continuously comparing the results against real-world data. Parking systems, autonomous vehicles, and circuit simulation are worlds apart, but identifying the core architecture first and validating it with real data has always been my approach to adapting quickly.
Part 2. A deep dive into the thermal simulator
If you had to define the thermal simulator you're building in a single sentence, what role does it play within MODI Factory?
It's an engine that predicts temperature distribution and thermal risk based on design data before the PCB is physically fabricated, and feeds that prediction back into the layout.
Just as a smartphone overheats when running high-end games, excessive heat can be fatal to electronic products. What happens during mass production if thermal issues aren't resolved during the design phase?
If a specific component runs hotter than intended, its performance can degrade or it can malfunction, and over time the product's lifespan shortens. If a thermal problem like this only shows up at the mass-production stage, you have to redesign and retest the PCB, which delays the production schedule and drives up cost significantly.
Theoretical simulation results often diverge from what thermal cameras measure in reality. How are you calibrating the algorithm to bridge the gap between theory and empirical data?

Measuring test board temperatures using a thermal imaging camera (Source: Ethan)
First, I validate the calculation logic against an established commercial simulator. Then I fabricate a real test board and compare the results directly against thermal-imaging measurements. When there's a discrepancy, rather than arbitrarily tweaking the final numbers to fit, I go through every variable one by one: input power, material properties, environmental conditions like natural convection to ambient air and surface radiation, and the measurement setup itself.
On speed, while a commercial tool typically takes around 10 minutes for a thermal analysis, MODI Factory finishes the computation in roughly 30 seconds to a minute—about 10 to 20 times faster. On accuracy, the results hold up well too, with an error margin within roughly ±5°C compared to empirical measurements and reference models. Right now the algorithm is tuned for specific PCB conditions, so my ongoing focus is generalizing it so it stays consistently accurate across a wider range of circuits and environments.
Even a commercial simulator gives you the wrong answer if you feed it the wrong inputs. That's why I treat physical measurements as ground truth while also double-checking the measurement conditions themselves. That's how I trace each error back to its root cause, refine the model, and keep improving accuracy through repeated verification under the same conditions.
We heard you personally design and fabricate test boards to validate the thermal simulator. What does the hands-on testing process look like when evaluating power components?

Running empirical validation by applying power to a custom test board built to verify the algorithm
For heat sources, I use components whose power dissipation is easy to calculate and measure — LDOs (low-dropout regulators), LEDs, and resistors — and I measure voltage and current directly to pin down the actual heat output first. I'll also place identical resistors on spots with and without copper pour, side by side, so I can directly compare how effectively the copper spreads the heat.
Then I run the simulation and the thermal-imaging test under the same conditions and compare not just the peak temperature but the whole heat-spread pattern. That's the only way to distinguish between errors from the simulator and errors from the test setup the simulator itself and error coming from the test setup.
The MODI Factory AI Team is largely divided into three tracks: [placement / routing / simulation]. Using a simple analogy, how do these three parts work together like interlocking gears to deliver a finished board?
In our previous interview, Hugo compared PCB component placement to city planning. Building on that: placement is zoning the city and deciding where buildings go, and routing is laying down the roads and power grids connecting them. The simulator is the forecast map you run before the city is actually built.
Right now, it flags the spots where heat will build up and overheat. Down the road, it'll also flag signal congestion bottlenecks and power-starved zones. Designers take what the simulator finds and feed it back into placement and routing to build a more stable board — and automating that whole feedback loop end to end is my next goal.
Part 3. Roadmap and final thoughts
We heard the simulator's roadmap is planned in phases: [thermal → power integrity (PI) → signal integrity (SI)]. Why did you prioritize "thermal" as the first milestone among so many physical problems?
Thermal wasn't the plan from day one — it grew out of a question the team kept asking: "could we calculate heat from just the placement and routing results?" It became the first milestone because it's a problem where the output of the layout algorithms can be fed straight back into the design. Once I actually built it, I found that low-current signal traces generate almost no heat — the real driver is component heat and how it spreads through the copper and the board, and that's what shaped the direction I'm on now.
Power integrity and signal integrity come next, but for now I've only locked in the order. As I did with thermal, I'll validate each one, flesh out the details, and build it into a structure that feeds back into both placement and routing.
What was the most difficult part of translating complex physics like thermodynamics into an algorithm?

Ethan, MODI Factory AI Team
It was a struggle from the very start. Thermal engineering wasn't my academic background, so I first had to figure out which model to use and how far to take it. Instead of calculating the full airflow around the board, I simplified it down to a scope that could give fast feedback during the design phase, then refined it by benchmarking against a commercial simulator.
The next challenge was the input data. You can't tell a component's actual power draw from the layout data alone, so I had to lay out a step-by-step process: read it from the datasheet, estimate it from the circuit connections, and fall back to a conservative estimate when neither works. I'm still tightening that accuracy against real test data today.
Early on, I assumed that routing thicker traces would lower resistance and let heat escape more easily, since heat calculations involve resistance and current squared. But it turns out real signal traces carry such a small current—well under 1 A—that trace thickness barely affects the temperature at all.
Another realization: the real bottleneck isn't the chip's surface temperature, it's the internal junction—the semiconductor die inside the chip. If the junction gets too hot, the component itself breaks. So the real fix isn't just surface cooling; it's widening the copper pour and designing a good thermal path so heat gets out of the chip quickly.
What does the "ideal MODI Factory simulator" look like in its final form?
The vision I'm working toward is a simulator that communicates its results clearly to whoever's using it. For non-experts, that means simply handing them a verified, thermally reliable circuit. For experts, it means giving them the full analysis, like a temperature distribution map. Ideally, those results feed straight back into placement and routing so the design keeps improving on its own. There's still a lot to build, but I think we just tackle it one piece at a time.
Lastly, what advice or encouragement would you give to students and junior engineers who are currently placing components and routing boards by hand?

Flight-testing a drone Ethan built during his undergraduate studies (Source: Ethan)


