Questions I’m trying to untangle, things I’ve tried, and what I think now—mostly across physical AI, simulation, digital twins, and developer tools.
Years of MES work taught me where automation stops: at tasks whose decisive state cannot be written down or seen. Tactile input earns its place when it reveals that missing state; contact alone is not enough.
Every digital twin needs a usable digital starting point. CAD, LiDAR, photogrammetry and Gaussian splatting preserve different kinds of truth, so the representation should follow the decision. Part 1 of a three-part series.
A refinery valve operation shows why robot capture should begin with the task: preserve the motion, contact, timing and measurements the policy will need.
Robot foundation models are getting better at handling situations they were not shown. That makes the old commissioning questions more important: where is the model valid, how do I know it has left that range, and what happens next?
People keep asking me a version of the same question: what NVIDIA hardware should I be thinking about for a digital twin, from a developer build at my desk all the way to production? I always had an answer but no clean model behind it, just a pile of product names, three of which are confusingly all called DGX. So I built the model I wanted: NVIDIA develops one architecture family a year and expresses it across many kinds of computer, from a gaming card to a liquid-cooled rack. These are my rough notes, in case you're coming at it from the software side and asking the same thing.
When a general-purpose LLM (or an agent built on it) doesn't fit the problem, the reflex is to fine-tune it. I think that's usually the third thing to try, not the first. There are three ways to close the gap: grounding context, harness optimization, and fine-tuning, and which one you reach for should depend on the need in front of you: domain knowledge, agent behavior, or raw performance.
MES was never really about running the machines. It was about improving the operation, and it was limited by how much had to be modeled by hand and decided by people. Physical and agentic AI can change that, but only if the plant's systems are joined through shared operational context.
We finally have models that can watch the physical world, reason about it, and predict what happens next. Walk a real automotive parts-kitting task through what they actually solve, and the thing still standing between a demo and a working line isn't a smarter model: it's the policy you have to train for your machine, and the system that keeps it trained.
Kit and libraries used to be the same choice for building on Omniverse. They're not anymore, and that's a bigger change than it looks, with a real before/after from a Kit extension I built.
Since May 2026, Omniverse is free for production, not just development. It's a clean, sensible change, but it landed quietly, and I keep meeting customers and partners who don't know it happened yet. The paid-production requirement is gone; the license and optional enterprise support remain.
Someone asked me how you'd build a training center for industrial robots from scratch, and my first reaction was that it isn't one project, it's ten. What untangled it was seeing that they aren't ten separate things at all. They're five stages of one loop that turns real work into robot skills and feeds what happens back in. This is where I've gotten so far, still learning, sharing it in case you're walking the same road.
From the industrial systems I know, rendering is only one part of Omniverse. The harder job is connecting source data, giving teams a shared context, and reusing it for visibility, simulation, optimization and Physical AI.