u/3E8_

Been thinking about this with robotic cells that have already been commissioned.

You can build a pretty accurate simulation of the cell initially, but the real environment obviously doesn’t stay frozen forever. Fixtures move, tooling changes, new equipment gets added, layouts shift, different parts start running through the line, etc.

How are people actually dealing with that over time?
Do you actively keep the simulation/digital twin updated as the physical cell changes, or does it mostly get updated when something breaks or a major change is made?

And for anyone maintaining them regularly, what’s the most painful part of keeping the virtual and physical environments in sync?

Curious how this works in practice rather than how it’s supposed to work on paper.

Feels like a new robotics company is coming out of stealth every day right now and I’m definitely missing some.

I’m specifically looking for newer teams building and deploying their own physical robots in real-world environments. Especially manipulation, humanoids, warehouse/logistics, manufacturing, home robotics, construction, food production, labs, or other robots that have to operate across different customer sites.

Not really looking for robotics software, foundation models, simulation platforms, sensors, or component companies. Mainly teams building the actual robot and moving from demos toward pilots or real deployments.

Bonus if they’re already working with simulation, robot learning, or testing across different deployment environments.

Who should I have on my radar? Drop the company + what they’re building below.

Been digging into this recently and curious how people here actually handle it.

Once you’ve built a scene in Isaac Sim, how are you checking that it behaves close enough to the real environment?

Are you comparing task outcomes, object behavior, trajectories, or mostly tuning until things look right?

Would love to hear what people are actually doing in practice.

Could use some help from people doing this regularly.
Say I reconstruct a real object for Isaac Sim and get the geometry, scale, collisions, mass, inertia and friction reasonably close.

How do you actually prove the simulated object behaves close enough to the real one?

Are you comparing trajectories? Contact outcomes?
Object motion? Measuring properties directly?

I keep coming back to the idea that generating the asset is probably the easy part. Knowing whether you should trust it seems much harder.

This is something I’ve been working on, so I’m trying to understand where the actual pain is before assuming we know the answer.

For people working with Isaac Sim regularly, where are you still burning engineering hours?

Asset creation? Collision geometry? Physics properties? Scene assembly? Articulation? Validation? Getting everything into the right format?

I’m especially curious about work that feels like it should already be automated but somehow still isn’t.

I recently released the first few interactive Real2Sim assets we’ve been working on, and rather than choosing the next objects ourselves, I thought it might be more interesting to ask here.

What everyday object would actually be useful or technically interesting to reconstruct for robot interaction?

I’m especially interested in things where geometry alone isn’t enough.

Could be an articulated object, something with unusual contact behavior, or just an object that is consistently annoying to model correctly.

Drop an object below. I’ll pick a few of the most interesting suggestions and see what we can build.

Say you build a simulation of a customer facility before deployment.

A few weeks later, someone moves a workbench, replaces a conveyor, changes the shelving, or introduces new objects.

Does your team manually update the simulation, rebuild the scene, or simply accept that the digital environment is now outdated?

I’m curious whether maintaining the environment becomes a larger problem than creating the first version.

A render can make almost any reconstruction look convincing. That does not tell you whether the scale, collision geometry, articulation, or interaction behavior is useful inside a simulator.

That is why I released an interactive asset pack instead of only posting videos and screenshots.
You can test it here: https://diracrobotics.com/asset-pack

That is the workflow I recently built.

Instead of beginning with architectural plans or manually recreating the entire environment, the input is video of the real site. The pipeline then reconstructs it as a simulation-ready scene.

The longer-term direction is to help teams test robot behavior against the environment where the robot will actually operate. That evaluation layer is still being built.

For an industrial team, what would stop this from fitting into your deployment workflow?

Importing a USD file into Isaac Sim does not necessarily mean the asset is ready for robot training.

Beyond visual geometry, a useful asset may require:
• Correct metric scale
• Clean collision geometry
• Mass and inertia
• Appropriate friction
• Joint limits and dynamics
• Semantic labels
• Validation against real behavior

Which of these creates the most friction in your current workflow?

I’m also curious whether teams usually build these properties manually, inherit them from CAD, or estimate them through real-world testing.

When preparing a robot for a new customer environment, how does your team create the corresponding simulation?

Do you usually:

• Start with CAD or architectural plans
• Build the environment manually in Blender
• Scan the real site
• Modify a generic environment
• Skip site-specific simulation and test on hardware

I’m curious how common site-specific simulation actually is outside research labs, and which part of the workflow takes the most engineering time.

Hey all, I wanted to share what we’ve been building since it’s directly relevant to a lot of what gets discussed here.

Dirac Robotics takes single-camera video of a real object or site and reconstructs it into a physics-accurate simulation, mass, inertia, friction, and joint behavior resolved alongside the geometry, not just visual accuracy. Output is USD, ready for Isaac Sim. Works across rigid, articulated, and deformable objects.

There’s a public interactive asset pack if you want to poke at it directly rather than take a claim at face value, worth two minutes if you’re curious what “physics-accurate” actually looks like in practice.

Happy to answer questions on how the pipeline works, and genuinely interested in hearing how people here currently handle this problem, whether that ends up being a useful conversation for us or not.