Add OSMO AMR Navigation test case

[KeitaW]

Summary

• Adds a new NVIDIA OSMO test case under 3.test_cases/osmo/AMRNavigation/ for warehouse AMR (Autonomous Mobile Robot) navigation synthetic data generation and training
• 6-stage pipeline orchestrated as an OSMO DAG on Amazon EKS: scene setup → occupancy mapping → trajectory generation → multi-modal rendering (parallel RGB/depth/segmentation) → domain augmentation → X-Mobility foundation model training
• Uses heterogeneous compute (G-series for rendering, P-series for training), KAI Scheduler, and S3-based inter-stage data passing via IRSA

Contents

• 3 Dockerfiles: isaac-sim (stages 1-4), cosmos-transfer (stage 5), xmobility (stage 6)
• 6 pipeline scripts (src/): Full Python implementation for each stage
• 4 OSMO workflow YAMLs: data pipeline (combination), training (single-task), full sequential (reference), smoke test (CPU-only)
• 4 numbered shell scripts (kubernetes/): setup, build, verify, submit
• 2 config files: default pipeline settings + per-stage parameters
• 2 READMEs: top-level overview + detailed Kubernetes instructions

Key OSMO features demonstrated

• DAG task dependencies via inputs:
• Combination workflows with parallel task groups (Group 4: 3 render passes)
• KAI Scheduler integration
• Priority scheduling and checkpoint/reschedule semantics
• Heterogeneous NodePool targeting (rendering vs training)

Test plan

• E2E validated on EKS cluster with OSMO v6.2-rc6 (smoke test passed, full AMR data pipeline submitted and ran)
• Verify README instructions are reproducible on a fresh cluster
• Validate all 6 stages complete with GPU capacity available

[bluecrayon52]

I'm getting a page not found error in the NVIDIA OSMO installation guide link provided in the AMRNavigation/kubernetes/README.md.

It looks like Nvidia provides an AWS Infra with Terraform guide, did you use something like this to deploy the EKS cluster?

I'm ok with the Terraform infrastructure being outside of the scope of the test case and externally referenceable to a stack that Nvidia maintains.

Does it make sense to also include:

• Links or Helm commands for installing the in-cluster prerequisites (GPU operator, KAI scheduler, Karpenter, OSMO)
• YAML manifests for the required Karpenter NodePools that the 4.verify-osmo.sh script checks for with instructions on how to apply (osmo-rendering, osmo-gpu-training, osmo-cpu-batch, osmo-cpu-system)
• Instructions for loading the nvidia/X-Mobility dataset from HuggingFace to S3

If you plan to cut another PR to provide architecture setup automations, then perhaps we can link to those resources in the prerequisites section of this test case?

[yoosful]

Suggested change

	--data_dir {{output}}/data \
	--dataset_dir {{output}}/data \

[yoosful]

Suggested change

	The pipeline requires OSMO control plane components. Follow the [NVIDIA OSMO installation guide](https://docs.nvidia.com/osmo/) to deploy OSMO on your EKS cluster, then verify readiness:
	The pipeline requires OSMO control plane components. Follow the [NVIDIA OSMO installation guide](https://nvidia.github.io/OSMO/main/deployment_guide/index.html) to deploy OSMO on your EKS cluster, then verify readiness:

[yoosful]

Reproduced on EKS (OSMO v6.2.10, L4 GPU); a few issues inline.

[yoosful]

stage4_render.py has no --render_mode arg. This task fails with unrecognized arguments: --render_mode rgb. Same for render-depth and render-segmentation.

The script uses BasicWriter which emits rgb+depth+seg in one pass, so splitting into 3 tasks re-renders the same frames 3x for identical output. Either add real --render_mode filtering to the script, or collapse Group 4 to a single render task.

Minimal unblocker (just removes the unknown arg; doesn't fix the 3x re-render):

Suggested change

--render_mode rgb \

[yoosful]

--s3_bucket / --run_id missing on every stage, but all stage*.py scripts declare them required=True. Workflow argparse-fails on stage 1.

Suggested change

	--output_dir {{output}}/scene \
	--s3_bucket ${S3_BUCKET} \
	--run_id ${RUN_ID} \
	--output_dir {{output}}/scene \

Same missing args on stages 2-5; apply the pattern there too.

[yoosful]

On Replicator 1.11, CosmosWriter takes output_dir only. rgb / depth / semantic_segmentation kwargs raise TypeError. The except Exception silently falls back to BasicWriter every run, so this branch is dead. Either fix the call or drop the Cosmos path.

Suggested change

	writer.initialize(
	output_dir=output_dir,
	rgb=True,
	depth=True,
	semantic_segmentation=True,
	)
	writer.initialize(output_dir=output_dir)

[yoosful]

stage5_domain_augment.py reads raw-v1/ and writes augmented-v2/ (via make_stage_path), not rgb/ / augmented/. README's S3 layout example has the same mismatch.

Suggested change

	--input_dir {{input:0}}/rgb \
	--output_dir {{output}}/augmented
	--input_dir {{input:0}}/raw-v1 \
	--output_dir {{output}}/augmented-v2