Five NVIDIA resources were suggested at kickoff, each pointing at a part of this problem we hadn't solved.
Committed: PeopleNet · To test next: Replicator Agent, build.nvidia.com · Ready, unproven on the board: Isaac ROS nodes · Belongs on the GCS: nvblox · Gap we own: BodyPoseNet
Committed as a deployable edge baseline, one of two off-the-shelf reference arms our own detector is judged against. What earns it the slot is that it ships TensorRT-optimised and INT8-ready — it runs on the Orin as-is, so the comparison is against something that could actually deploy, not a lab-only model. The open licence is a bonus on top (NVIDIA Open Model License, against the AGPL our detector carries onto the board). The consequence is declared in advance: if PeopleNet as shipped plus a ten-line posture rule matches ours on real frames, we switch. First measurement is queued — see the B0 vs B1 comparison.
We have the dataset the Agent was meant to produce — 17,172 upright frames across six pose classes (kneeling, crouching, seated, bending, standing, walking), each split by hi-vis vest so the vest's own contribution to recall stays measurable. But we built it by hand: plain Replicator, authored poses, one character per vest colour — which is exactly the pair of limits our dataset card admits, and exactly what the Agent is built to fix. So it is worth a real test, not just a note: regenerate those pose classes with the Agent and measure whether the added variety actually lifts detector recall on real frames — synthetic variety that doesn't transfer is only more render time. Two conditions on that test: pair it with the multi-control Transfer fix, or the new poses shed their labels the way segmentation-only did (13% kept, 0% of the vest); and run it after the judge set and the B0/B1 baseline, since it shares the one render-bound card with everything else.
We used it as suggested — for Cosmos prompt design before committing the render batch — and, honestly, kept no record of that session, which we should have. Its sharper use now is as a check we cannot run on the board: the same model at full precision, to see whether the output-schema failure comes from the quantisation or from the model itself.
We already run ROS 2 — a bridge package (image, lidar, translate), a ROS 2 motor backend, a --backend ros2 mode that drives a ROS 2 robot on the same wire, and a ROS face on the lidar service streaming /scan — and the motor service was built as the coexistence seam on purpose: ROS 2 arrives as one more client, never a replacement. So adopting Isaac ROS would be an integration, not a rewrite. The platform is no longer the blocker either: 4.6.0 re-added Jetson Orin for JetPack 7.2 / CUDA 13, and the board now meets it (L4T R39.2, CUDA 13.2). What holds us back is narrower — Orin Nano is not enumerated as its own supported row, NVIDIA staff called 4.x unsupported on it as late as mid-July, and one attempt on our exact config failed before 4.6 — so the first install is an experiment, not a dependency. The DNN inference nodes are a real fit, but for the detector — PeopleNet or YOLO, not the reasoner: the TensorRT/Triton pipeline turns an image into tensors and tensors into boxes, which is a detector, not a multimodal LLM (text-plus-image in, autoregressive text out, KV cache, custom plugins). And the reasoner already has its serving shim — deliberately not a ROS node, but an OpenAI-compatible endpoint, so the model behind it can change without touching the brain.
nvblox belongs on the ground-control station, not the robot. The robot has no room for it: the full VLM already peaks at ~4,830 MB of the 7,485 usable, before the detector, the ROS/GCS stack and the recorder even load, and the co-resident figure that would settle what else fits is not yet measured. The GCS is where it earns its place — stream depth and pose up while comms are healthy, fuse the 3D reconstruction on the workstation GPU, and use it for operator situational awareness of unknown sites (site status, change between passes) and goal-level re-tasking ("clear the NE room", "avoid that corridor"). It sits off the robot's critical path, so a comms cut stops the map, never the search.
Never examined — the gap on this list is ours. And it may be the most relevant item on it: the task is fixed as "does this frame contain a person lying on the ground?", and our free-detector arm resolves posture with a bounding-box aspect ratio (w/h ≥ 1.3, picked from geometry). Keypoints answer lying versus upright directly rather than by proxy, on the same TensorRT-ready footing as PeopleNet. Either it becomes a third baseline arm, or we owe a reason why not.