Robots don't usually fail because of bad instructions. They fail because good instructions arrive too late. Out in rough terrain, with a signal that drops in and out, even a brief delay between command and action is enough to send a machine off course. One of our clients is tackling exactly that problem, building software that predicts the lag and corrects for it in advance, so the robot acts on what's happening now, not on what was happening a moment ago. Our job was to give that work the data foundation it needs on Databricks.
Early models are rough, and nobody wants to measure a first draft. "We'll track it properly later" sounds reasonable when you're moving fast. The trouble is that later, you can't prove anything got better. You only remember that it did, and memory isn't much use when your product is a prediction people rely on.
So tracking started on day one. The first version was a simple physics-based model, nothing fancy, and every trial was logged against it: real-world runs and simulated runs, side by side, so the two could be compared directly.
It paid off fast. Digging through those early records, the team found a flaw in the model's core logic. It wasn't the kind of bug that crashes anything. It just added a little error on every run, until the robot's predicted position drifted noticeably from where it really ended up. They fixed it, and because every trial had been recorded, they could show exactly what changed: the gap between predicted and actual position dropped from roughly two footsteps to about a finger's width, and stayed there across every trial on record.
That became the rule for every version after. Nothing gets left to memory.
Seeing the fix, not just measuring it
A static number in a spreadsheet is convincing, but seeing it happen in real time paints a picture that can really help diagnose issues as they trickle in. Seeing this, we built a tool that plays back each trial in 3D, letting anyone, no technical background required, pull up a run and watch the robot's real path next to the path the model predicted, unfolding frame by frame. You don't need to understand a single metric, you just watch the two paths, and see whether they match.
Databricks was the platform of choice, but naturally didn’t come with a built-in robot-path visualizer out of the box. One of the key strengths of the platform is to give you a flexible enough workspace to build exactly this type of custom tool directly on top of your own data, without needing to buy or maintain a separate piece of software, just for visualization. Most teams tend to stop at running standard reports. But there’s a lot more you can do with that same platform if you’re willing to build for it.
Now the result sits right next to the raw numbers: the same trials, the same accuracy figures, except now anyone can actually watch them happen, real-world and simulated runs side by side, both telling the same story.
Most partners show up with this kind of rigour once a client finally asks for it. We'd rather show up before anyone thinks to ask.
