Nvidia's COMPASS attacks the navigation rebuild that every new robot triggers

The person this is built for has a navigation policy that works in one warehouse and a second customer whose building has a different floor plan and a different robot underneath it. What happens next is rarely research. It is new data, new simulation assets, new software interfaces, then training and testing again, a loop that Interesting Engineering's account of the work calls time-consuming and difficult to reproduce ^[3].

Teams tell themselves that work is tuning. On the calendar it is a project, with an owner for the scene and an owner for the sim-to-real gap, and an estimate that is a guess because last time nobody wrote down which steps got reused. COMPASS goes after that estimate rather than after navigation quality. The pretrained X-Mobility policy stays in place, and reinforcement learning trains a specialist whose only job is to correct it for the physical characteristics and surroundings of the target robot ^[2].

Two details in the reference workflow tell you what kind of tool this is. The first is the smoke test, a small run to confirm the robot, environment, cameras and control system actually talk to each other before a long RL job burns hours ^[9]. Anyone who has watched a training run finish and then found the camera transform was wrong will recognise the motivation. The second is checkpointing: the workflow saves checkpoints so developers compare versions instead of taking whatever the run ended on ^[10]. That is a quiet admission that these runs do not improve monotonically, and it hands a human the job of choosing among policies they did not train.

The scene library is generous but not about you. SAGE-10K holds 10,000 generated indoor environments across 50 room types ^[7], which works out to an average of 200 environments per room type ^[15]. That buys variation inside a category. For the actual building, the workflow routes to Omniverse NuRec, which reconstructs captured spaces for simulation ^[8], and that is the step with a real bill attached, because somebody has to go and capture the site.

What the account does not contain is a result. Goal-reach rate, fall frequency and route time are named as the evaluation basis, and the pretrained and adapted policies can be run under matched conditions ^[11], but no figures are reported ^[16]. So what is on offer is repeatability, and repeatability is something you can measure at home: hours from new robot to promoted policy, and how many promoted checkpoints later fail on hardware.

A forcing function, two questions. Does the pretrained policy already behave roughly correctly on your embodiment? Can you capture your site? Both yes is the cell this was designed for, where the correction is a small job sitting on top of a small integration surface: camera images, odometry and a goal go in, movement commands come out, with cuVSLAM available when the robot has no usable odometry of its own ^[12][13]. Policy fine but site not capturable means tuning against synthetic rooms and budgeting for the gap on delivery day. Policy wrong for your embodiment means the residual is being asked to learn the whole task, and you have taken on a dependency on someone else's checkpoint for the privilege. Both answers no, and this is a paper to read rather than a workflow to adopt.

The approval gates are the part worth writing into your process before the first run, because they are where a name gets attached to the decision to promote ^[5], and that record is what gets requested after an incident.