Thank you for your ongoing support of Isaac Sim. Your feedback in 2025 was invaluable, and we’re eager to hear more as we enter 2026.
We’ve opened a new discussion thread on this forum to gather your insights. Please share:
Challenges you face when using Isaac Sim
Improvements you’d like to see
Your input directly shapes our product development. We appreciate your time and look forward to your thoughts.
Are there any plans to integrate a wider range of path planners directly into Isaac Sim?
Currently, CuRobo is managed separately, and this sometimes leads to compatibility or collision issues depending on the version. It would be highly beneficial if Isaac Sim could natively support a path planner that handles mesh-based obstacles, such as CuRobo, without these version-related concerns.
Additionally, I would love to see support for multiple path planning frameworks, including the Open Motion Planning Library (OMPL), to provide more flexibility for different robotics applications and research scenarios. Expanding the built-in options for path planners would greatly enhance usability and reduce integration complexity.
Isaac Sim seems like it largely focuses on smaller sized scenes for indoor robotics. My lab wishes to use Isaac Sim for outdoor field robotics with large maps. I’ve noticed a great deal of lag when importing outdoor scenes from Unreal Engine, especially scenes with foliage and fauna. I suppose this discrepancy is because of Unreal Engine’s nanite foliage optimizations. Could there be considerations to make Isaac Sim work with fast performance for large scale scenes that simulate the outdoors and outdoor foliage?
When I used the Isaac sim, I published the cmd_vel through ROS2, and my ROS2 program set a time. The result of v*dt differed by a factor of 0.33 from the differential controller in Isaac
Hi @425532859, thanks for reporting this. The 0.33x factor is likely caused by a mismatch between the physics simulation rate and your ROS 2 publishing rate, or a unit discrepancy in the wheel parameters. Could you file a separate issue on GitHub (https://github.com/isaac-sim/IsaacSim/issues) with your robot’s
wheel_radius, wheel_base, physics timestep, and ROS 2 cmd_vel rate? That will let us diagnose the exact cause. For reference, the DifferentialController expects wheel dimensions in centimeters, while ROS 2 cmd_vel uses meters/sec — please double-check that your values are consistent.
I am currently working on setting up Isaac Sim inside a Docker container on an Ubuntu 24.04 host (RTX A5000 GPU, Driver 580.173.02). I am trying to connect Isaac Sim to ROS 2 Jazzy on the host, but I am encountering persistent issues.
What I have done:
Initially used nvcr.io/nvidia/isaac-sim:2022.2.1. The GUI works fine, but when I enable ROS2 HUMBLE BRIDGE in the Extensions, I get a Segmentation fault and the error: Error getting RMW implementation identifier / RMW implementation not installed.
I suspect the crash is due to the ROS version mismatch (Foxy inside the container vs. Jazzy on the host). To fix this, I tried building a custom image based on ubuntu22.04 and copying the local standalone Isaac Sim (likely 5.1.0) into the image, while installing ros-humble-ros-base inside.
However, the custom build fails with pull access denied for nvidia/cuda (even after switching to nvcr.io sources).
Logs & Errors:
(Please copy and paste your terminal output and the crash logs here. The crash logs show [Fatal] [carb.crashreporter-breakpad.plugin] and Segmentation fault (core dumped))
Detailed questions:
Is there a known workaround for the ROS2 bridge Segfault in Isaac Sim 2022.2.1 inside Docker?
For the custom build, what is the correct base image to use for Isaac Sim 5.1.0 that supports ROS2 Humble? I encountered pull access denied on both nvidia/cuda and nvcr.io/nvidia/cuda.
Has anyone successfully run ROS2 Humble/Jazzy communication with Isaac Sim 5.1.0 in a Docker container?
Feedback from someone who uses Isaac Sim to produce numbers that other people are supposed to be able to reproduce.
The single most valuable thing you could ship is a documented, testable determinism contract. Not “it is deterministic”, but: given this seed, this physics config, and this reset sequence, these are the guarantees, and here is the test that proves it on your hardware.
Right now reproducing an evaluation across two machines is an empirical exercise. That is fine for research, and it is not fine the moment a result is meant to be evidence for a regulator, which is where this whole field is heading by January 2027 in the EU.
Second, smaller: expose the autoreset semantics explicitly in the vectorised API. Silent resets on episode boundaries change which initial states a policy sees, and that shifts benchmark numbers in a way nobody attributes correctly.