application-flow
High-level overview of a typical ovrtx application lifecycle. Use when user asks how to structure an ovrtx program, what the main…
Authoring and configuring OmniRadar sensor prims and radar PointCloud render outputs. Use when user asks to create a radar scene, configure an OmniRadar prim, choose radar output frame/coordinate behavior, configure radar scan outputs, or request radar PointCloud channels.
$ npx -y skills add nvidia-omniverse/ovrtx --skill configuring-radar-sensors --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/configuring-radar-sensorsContext preview
The summary Claude sees to decide when to auto-load this skill.
Authoring and configuring OmniRadar sensor prims and radar PointCloud render outputs. Use when user asks to create a radar scene, configure an OmniRadar prim, choose radar output frame/coordinate behavior, configure radar scan outputs, or request radar PointCloud channels.
# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. # SPDX-License-Identifier: LicenseRef-NvidiaProprietary # # NVIDIA CORPORATION, its affiliates and licensors retain all intellectual # property and proprietary rights in and to this material, related # documentation and any modifications thereto. Any use, reproduction, # disclosure or distribution of this material and related documentation # without an express license agreement from NVIDIA CORPORATION or # its affiliates is strictly prohibited. name: configuring-radar-sensors description: > Authoring and configuring OmniRadar sensor prims and radar PointCloud render outputs. Use when user asks to create a radar scene, configure an OmniRadar prim, choose radar output frame/coordinate behavior, configure radar scan outputs, or request radar PointCloud channels. license: LicenseRef-NvidiaProprietary author: NVIDIA ovrtx tags: - ovrtx - sensors - radar tools: - Read - Grep
Use this skill when the user asks to create a radar scene, configure an OmniRadar prim, choose radar output frame/coordinate behavior, configure radar scan outputs, or request radar PointCloud channels.
Resolve inputs in this order: existing repository files and referenced snippets, explicit user request, then broader agent context.
1. Identify the radar prim, RenderProduct, PointCloud RenderVar, requested channels, scan behavior, coordinate behavior, and output frame. 2. Read the matching USD, Python, or C/C++ source snippet before writing API usage. 3. Author the `OmniRadar` prim and `PointCloud` RenderVar channel set explicitly; do not imply channels are available unless requested or auto-enabled. 4. Combine configuration, reading, and interpretation skills only when the user asks for an end-to-end radar workflow. 5. When changing code, run the narrow docs test or example that owns the snippet whenever practical.
This skill has no scripts.
An ovrtx radar setup has two parts:
The same USDA scene pattern is used from Python and C; the language-specific code only loads the scene, steps the render product, and maps the output.
> **Source:** `examples/python/radar/radar_example.usda` snippet `configure-radar-sensor`
> **Source:** `examples/c/radar/radar_example.usda` snippet `configure-radar-sensor`
Use `OmniSensorGenericRadarWpmDmatAPI` for the generic WPM DMAT radar model. The schema automatically includes scan configuration `s001`; apply `OmniSensorGenericRadarWpmDmatScanCfgAPI:s002`, `s003`, and so on only when authoring additional scan patterns.
In Z-up scenes, keep the physical scene Z-up and rotate the radar prim so sensor `+X` points along the intended forward direction. Prefer authoring that transform in USD instead of relying on renderer settings that change the coordinate frame globally.
These output-defining attributes, among others, live on the radar prim with the `omni:sensor:WpmDmat:` prefix.
| Attribute | Values / Shape | Use | |---|---|---| | `elementsCoordsType` | `CARTESIAN`, `SPHERICAL` | Coordinate representation for detection coordinates. | | `outputFrameOfReference` | `SENSOR`, `WORLD`, `CUSTOM` | Frame of reference for outputs. Prefer `SENSOR` when downstream consumers expect sensor-frame detections. | | `customFrameOfReferenceTrafo` | `[x, y, z, roll, pitch, yaw]` | Custom transform used only with `outputFrameOfReference = CUSTOM`. |
OmniRadar prims expose many additional WPM DMAT sensor and scan attributes for wavelength, ray depth, CFAR behavior, range/velocity/angular bins, noise, RCS tuning, and antenna/aperture configuration. Preserve existing attributes when editing a tuned sensor, and author model-specific values from the schema.
For the full schema-derived attribute list, read `schemas/omni_sensors/schema.usda`.
The default scan is `s001`, and scan attributes use the `omni:sensor:WpmDmat:scan:<scanName>:` prefix. Use scan attributes such as max range, angular limits, resolution, bin counts, CFAR settings, noise settings, and RCS tuning to match the target radar model.
For concise examples, keep one scan unless the behavior being demonstrated requires near/far or otherwise distinct scan patterns.
> **Source:** `examples/python/radar/radar_example.usda` snippet `confi
ovrtx is a C and Python library for embedding Omniverse RTX sensor simulation and visualization directly into applications.
High-level overview of a typical ovrtx application lifecycle. Use when user asks how to structure an ovrtx program, what the main…
Asynchronous operation patterns including polling, timeouts, and non-blocking workflows. Use when user asks about async…
Replacing persistent ovrtx attribute bindings with reusable ovstage queries for repeated writes or maps. Use when user asks about…
Binding materials to prims at runtime. Use when user asks to assign a material, change a material, set material binding, or swap…
Available camera render outputs for Real-Time Path-Tracing (RT2) mode. Use when user asks what AOVs/render vars are available,…
Cloning USD subtrees to create copies at new paths. Use when user asks to clone, duplicate, copy a prim, or create instances of…