RTX Radar azimuth/FOV to enable 360-degree coverage

Omniverse Isaac Sim
, ,
1

Isaac Sim Version

5.0.0

Operating System

Ubuntu 24.04

GPU Information

  • Model: NVIDIA GeForce RTX 5080
  • Driver Version: 580.95.05

Topic Description

Question about adjusting RTX Radar azimuth/FOV to enable 360-degree coverage in Isaac Sim

Detailed Description

Hello,

I am currently using RTX Radar in Isaac Sim (Full 5.0) and have a question regarding the azimuth field-of-view limitation .

At the moment, while I use the standalone example in standalone_examples/api/isaacsim.util.debug_draw/rtx_radar.py, the radar appears to observe only ±90 degrees in azimuth (180° total forward-facing FOV) .
Based on point cloud analysis and azimuth statistics (atan2(y, x) ), no returns are generated from the rear hemisphere, which suggests that the radar scan is limited to a forward fan configuration.

My goal is to simulate a 360-degree radar , similar to a rotating marine radar or surveillance radar.
I would like to clarify the following points:

  1. Where is the azimuth/FOV limit defined or constrained?
  • Is it controlled by a specific USD attribute , Radar prim parameter , or scan configuration (e.g., rotating vs fan scan)?
  1. Is true 360-degree azimuth coverage supported by a single RTX Radar sensor , or is the intended approach:
  • a rotating scan over time with accumulation, or
  • multiple radar sensors (e.g., front + rear)?
  1. If 360° coverage is supported:
  • Which parameters should be modified (e.g., azimuth start/end, scan mode, rotation rate)?
  • Are there example scenes or documentation references demonstrating this setup?
  1. Are there Pulse-type radars in addition to FMCW?

I have already verified that parameters such as raysPerDeg , rBins , and vBins affect resolution but do not appear to control the azimuth coverage itself.

Any guidance on how to properly configure or extend the radar azimuth range would be greatly appreciated.
(Describe the issue in detail, including what you were trying to do, what you expected to happen, and what actually happened)

Steps to Reproduce

  1. python3 standalone_examples/api/isaacsim.util.debug_draw/rtx_radar.py

  2. Select the radar sensor and set the Z rotation to 0.0.

  3. Increase the MaxAzAngDeg value to greater than 90 degrees (which implies a forward FOV larger than 180 degrees).
    After doing so, it can be confirmed that no radar points are generated in the rear hemisphere, i.e., beyond the forward 180-degree region, even though the azimuth limit is set above ±90 degrees.

This indicates that radar returns are still constrained to the forward 180-degree region and do not appear in the rear area, regardless of the MaxAzAngDeg setting.

(Add more steps as needed)

Error Messages

(If applicable, copy and paste any error messages you received)

Screenshots or Videos

Screenshot 2026-01-06 14:18:00
Screenshot 2026-01-06 14:18:001436×930 161 KB

(If applicable, add screenshots or links to videos that demonstrate the issue)

Additional Information

What I’ve Tried

(Describe any troubleshooting steps you’ve already taken)

Related Issues

(If you’re aware of any related issues or forum posts, please link them here)

Additional Context

(Add any other context about the problem here)

3

Let me reach out to the internal team about your question

5

Thank you for the reply!

I also wanted to ask whether the following information can be provided by the radar sensor:

  1. A validity flag indicating whether a hit point is valid or invalid based on the maximum range constraint
  2. Availability of signal strength values, such as intensity or amplitude
  3. Whether relative velocity or Doppler information can be provided for each detected point or target

Please let me know if these are currently supported, or if there are plans to expose them in future updates.

6

About 360 FOV RTX Radar:
TL;DR: No, that’s unfortunately not supported

The RTX Radar is designed for automotive radars, not surveillance/marine radars. The architecture assumes forward-facing operation (as in the EM waves are sent out to one side, not 360°). Furthermore, we focus the simulation on FMCW (frequency modulated continuous wave) radars and while we think FMCW radars are starting to see adaption e.g. in marine applications, most radars in this field will not be FMCW models, but e.g. pulse radars.
Our implementation is currently hardcoded to reject any simulated rays that have an azimuth angle > 90° or < -90°.
The easiest workaround is to use 4 radar sensors positioned at 0°, 90°, 180°, 270° to get full 360° coverage.
However, using 4 sensors would likely be an oversimplification for most tasks. Automotive radars will provide all points at once in a single scan, while rotating radars provide more and more points as the radar antenna continues to rotate. This behaviour is therefore not modelled in our implementation and poses a fundamental difference in how the points are being output. If a user wants to simulate a marine radar, it’s important to model the continuous output of points as well.

As for your questions about validity flag, signal strength values and relative velocity, please refer to GenericModelOutput — Isaac Sim. The GenericModelOutput Annotator, when attached to an OmniRadar prim, will generate a GenericModelOutput struct containing the radar point cloud, signal strength as RCS, and a validity flag. If the omni:sensor:WpmDmat:auxOutputType attribute is set to BASIC (can be passed in as a keyword argument to any of the RTX Radar creation methods), the struct’s auxiliary data will also contain radial velocity for each return in the point cloud.

7

Thank you so much for your answer.

I have one more question. I couldn’t find the explicit value for the radar’s max range, so I’m checking it manually. Could you please let me know if there’s an officially specified value for this?