Validating Robot Walking in a Shipyard Digital Twin

1. "Buy the Robot First, Figure It Out Later" Is Too Late

A shipyard is one of the harshest workplaces a robot can face.

Inside hull blocks such as double bottoms, spaces are cramped, stiffeners (longitudinals) rise from the floor at regular intervals, and temporary scaffolding and ladders are mixed in at height. Lighting is dim, cables snake across the floor, and welding fumes hang in the air. On top of that, block shapes change from ship to ship and from process to process, so this is not a world where you "program it once and you're done."

At the same time, the shrinking pool of skilled workers and the labor shortage are pressing problems that cannot wait. What is expected of robots here is not "welding faster than people," but keeping the shipyard running longer and more safely: operating at night and across shifts, and taking over work in hazardous confined spaces.

But if you only discover after bringing a robot on site that "it couldn't climb the ladder" or "it couldn't step over the stiffeners," you have already lost too much time and money. That is why we are working on the following kind of validation:

Turn the entire site into a digital twin and use simulation to confirm whether a robot can walk it, before the real robot ever gets there.

2. The Big Picture: From Point Clouds and CAD to a Simulation Environment Robots Can Walk In

The pipeline consists of four main stages.

① Measurement ── Scan hull blocks with a mobile laser scanner (point cloud)
   Design data: export meshes from shipbuilding CAD
      ↓
② Conversion ── FBX / DXF → USD / USDZ (correct units, axes, and origin)
      ↓
③ Physics ── Set collision, friction, and restitution; build the Isaac Sim scene
      ↓
④ Validation ── Deploy RL-trained walking policies; evaluate reachability, time, and falls

We compared several approaches, including models derived from point clouds, from CAD, and from a combination of both, and ultimately built 11 scenes that reproduce actual shipyard blocks. We also created 46 general-purpose testbed scenes that isolate individual elements such as walls, steps, trenches, gratings, and openings, so we can pinpoint exactly which element trips the robot up.

Examples of our self-built generic testbeds (from top left: stairs between walls, a longitudinal-style grid, a wall with an opening, and a slope-and-step combination)

3. A Model That Looks Good Isn't Necessarily Usable by a Robot

This was the first lesson we learned the hard way. Even a 3D model that looks beautiful to the human eye starts spewing problems the moment you drop it into a physics simulation.

The most impactful fix was a problem where the map the robot "sees" and the floor it "steps on" didn't match. The mesh used for collision and the mesh used for the height map (which the robot uses to read the surrounding terrain height) were managed separately, and the floor was missing from the map. Simply adding the floor to the map side raised the stair completion rate from about 4% to about 38%, without changing a single line of the policy.

In addition, because the height map was implemented by casting rays down from above, the robot was mistaking the overhead deck for the floor when inside a block. We fixed this by lowering the ray origin to around the torso and discarding points that were too high. At the same time, we cut height-map computation from about 12 ms to about 2 ms per cycle, which also improved training throughput.

4. Reinforcement Learning: Breaking Terrain Down into a Curriculum

The main subjects of our validation are commercially available quadruped robots: the Unitree A2 (large) and the Unitree Go2 (small). We chose quadrupeds over humanoids because, given the uneven terrain inside blocks and the need to carry loads, they are currently the most realistic option.

Training runs on NVIDIA Isaac Sim / Isaac Lab using PPO (rsl-rl). Rather than training on the shipyard environment as-is, we broke the site's difficult spots down into individual elements and generated terrain from them.

• 7 terrain types: flat ground, trenches, steps (stairs), slopes, longitudinals (stiffeners), and two types of manholes
• 5 difficulty levels: as the robot improves, it automatically advances to harder terrain
• Each terrain can be generated in about 0.15 seconds, allowing thousands of environments to run in parallel

For the Go2, we trained a policy that builds a height map of the ground at its feet (17 × 11 points) from the point cloud of a head-mounted LiDAR and outputs target angles for its 12 joints. By analyzing sensor logs from the real robot, we reproduce real-world "messiness" during training, such as missing points, height variance, and latency. The policy is exported to ONNX and shares the same runner as the real robot.

For the A2, we took the approach of separately training a "teacher policy that excels at stairs" and a "teacher policy that excels at stepping over longitudinals," then distilling them into a single student policy (multi-teacher distillation). After about 20,000 iterations, a single policy can traverse everything from stairs to longitudinals in one continuous run.

Here is a rough guide to what our latest all-terrain policy can clear in simulation:

We also built our own runner that can execute the same policy in both Isaac Sim and MuJoCo, and use it to check whether behavior stays consistent across physics engines (sim-to-sim). The goal is to make sure the policy hasn't overfit to the quirks of one particular engine.

Go2 traversal tests on the generic testbeds (Isaac Sim, 2x speed). From top left: stairs, a grid of longitudinals (red dots are height-map sample points), grating stairs, and a slope

5. Results: Can the Robot Overcome the Shipyard's Toughest Spots?

Now for the real test. In scenes reproducing actual blocks, we had the robot walk the routes that workers use every day. Each scenario was tried 8 times.

Looking at the numbers alone, you might think there is still a long way to go. But the value of this validation lies in the fact that we now clearly understand why the failures happen.

Existing ladders are angled on the assumption that a person climbs them while gripping handrails. For a quadruped robot, they are simply not workable. By contrast, a temporary gangway with wider steps and a landing at the top, even at the same height, starts producing successes. The same goes for the longitudinals: just having a flat work platform on the far side where the robot can reposition its body turned 0 successes into 2.

In other words, what made the difference was not so much the height of the obstacle itself, but

whether there is "enough width to climb" and "somewhere to regain balance after climbing."

6. Train the Robot, or Change the Site a Little?

The recommendations that follow from this are simple:

• The hull structure itself (longitudinals, etc.) cannot be changed → Train the robot (improve learning and control)
• Temporary structures (gangways, scaffolding, work platforms) can be changed → Propose robot-passable specifications to the site (e.g., step height of about 20 cm × tread depth of about 30 cm)

Discussions about robot adoption tend to focus on how far robot performance can be pushed, but small changes on the site side can greatly expand a robot's range of operation. We believe the greatest value of a digital twin is being able to demonstrate this quantitatively in simulation, before a single piece of scaffolding is put up.

That said, we are not trying to solve everything with reinforcement learning. For situations that require precise movements, such as passing each leg through one at a time over a high manhole sill, we have switched from reinforcement learning to designing joint trajectories directly. Choosing the best control approach for each situation, without being wedded to any one method, is also part of our role.

7. Next Steps: Closing the Loop Between Simulation and Reality

We are currently running the following cycle to bring the simulation closer to reality.

sim-to-sim  (cross-check behavior between Isaac Sim ↔ MuJoCo)
   ↓
sim-to-real (validate on the real robot in order: suspended test → flat ground → steps)
   ↓
real-to-sim (feed discrepancies observed on the real robot back into simulation)

For example, on the real robot we expect the sensor height map to arrive several hundred milliseconds late. At a walking speed of 0.75 m/s, that means the robot moves about 30 cm in the meantime. We are steadily working through evaluations that perturb this kind of latency and noise across about 15 conditions, then running additional training only on the conditions where weaknesses appear.

Another challenge has also emerged: the 3D models do not retain attributes such as material or plate thickness, so we have to infer which part is which from shape alone. We have recommended a common schema that links geometry and attributes via part IDs, and we are also testing the use of USD custom attributes to carry design information forward.

8. Conclusion

"We want to bring in robots, but we don't know whether they will actually work on our site." This is a concern shared not only by shipbuilding, but by construction, plants, logistics, and every other kind of work site.

Open Reach Tech provides end-to-end support for:

• Building simulation environments from on-site point cloud and CAD data (USD conversion and physics setup)
• Developing reinforcement learning policies and evaluation infrastructure with Isaac Sim / Isaac Lab
• Quantitatively assessing deployment feasibility from both angles: "training the robot" and "changing the site"

If you consult with us from the early stages of considering robot adoption, we can work with you starting from confirming whether a robot can walk your site, before you buy any hardware.

For our work on transferring motions learned in simulation to real robots, see "Taking Reinforcement-Learned Motions from Simulation to Real Robots."