Jiwenc nv/robot viz - #995
Draft
jiwenc-nv wants to merge 1 commit into
Draft
Conversation
Contributor
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueComment |
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
jiwenc-nv
force-pushed
the
jiwenc-nv/robot-viz
branch
2 times, most recently
from
August 21, 2026 23:51
7e638fd to
f5de61f
Compare
jiwenc-nv
force-pushed
the
jiwenc-nv/robot-viz
branch
from
August 23, 2026 22:10
124b2f0 to
bce10b7
Compare
jiwenc-nv
added a commit
that referenced
this pull request
Aug 23, 2026
The follow-up half of #995, which carries the twin with every test stripped out. All 20 files land here: src/viz/robot_twin_tests, examples/robot_viz/tests, the four src/viz/python_tests/test_robot_*.py, test_engage_gate.py and test_robot_twin_session.py, plus the CMake that registers them and the example README's Tests section. test_symbol_isolation.py runs against the shipped _robot_twin rather than a test-only extension carrying a second private MuJoCo. Review asked why the tests reached MuJoCo directly, and they should not have: that probe's two unique assertions exercised its own reimplemented longjmp handler rather than mj_guard.cpp, and its ELF assertions were the weaker copy of ones the shipped module already gets -- --version-script has nothing to hide in a module linking no static archive, and the shipped one links cudart_static. Two replacements do cover shipped code: that install_mujoco_handlers() wrote the twin's own mju_user_error and not the wheel's, and that an unguarded mju_error reaches mj_guard.cpp's abort rather than MuJoCo's exit(1). The example's tests are keyed on TARGET robot_twin_py, which says the actual dependency instead of restating where the twin gets built. Signed-off-by: Jiwen Cai <jiwenc@nvidia.com>
jiwenc-nv
commented
Aug 23, 2026
jiwenc-nv
added a commit
that referenced
this pull request
Aug 24, 2026
Review feedback on #995. Scene::forward called mj_forward -- full forward dynamics, including collision, constraint solve, CRB inertia, actuation and sensors -- once per rendered frame, and nothing read any of it. It is now mj_kinematics + mj_camlight, the position stage mjv_updateScene actually needs. A scene using tendons or rangefinder sensors would render those wrong under this; ours has neither, and the joint map already rejects anything but hinges. The build cannot shed the rest: upstream ships one libmujoco with no renderer-only target, so the ~40 s is the whole library either way. Also drops ISAACTELEOP_MUJOCO_VERSION and the Mujoco.cmake references to robot_twin_tests -- the tests read the isolation off the built artifact, not off a CMake variable -- the GIT_SHALLOW essay, the two build-doc paragraphs, and the robot_twin/CMakeLists.txt stub whose whole body was add_subdirectory(cpp). Signed-off-by: Jiwen Cai <jiwenc@nvidia.com>
The MuJoCo-backed digital twin was buried in examples/mujoco_xr -- compiled as part of that example, reachable only by installing it, and gated on the developer having a matching mujoco wheel. It is a Televiz capability, not an example. The backend moves to src/viz/robot_twin and its Python surface to isaacteleop.viz.robot, both shipping in the wheel; the app left behind is renamed examples/robot_viz and is pure Python. deps/third_party fetches MuJoCo and builds it under a private name, reached through dlopen/dlsym so the extension carries no undefined mj* for a foreign libmujoco to answer. Mujoco.cmake states that contract. Users may pip install mujoco at any version, or none. The twin poses and renders and never integrates, so it runs mj_kinematics + mj_camlight rather than mj_forward. EngageGate ships in viz.robot beside it: its reference operand is measured off the SceneTwin, and the affordance needs something drawing the arm. Two calls for a reviewer: the wheel now redistributes MuJoCo binaries, and every BUILD_VIZ build compiles it with no opt-out (~40 s, needs libegl-dev). Tests are #999, one commit on top of this. BREAKING: isaacteleop_examples.mujoco_xr is gone. Signed-off-by: Jiwen Cai <jiwenc@nvidia.com>
jiwenc-nv
force-pushed
the
jiwenc-nv/robot-viz
branch
from
August 24, 2026 18:33
2166718 to
641d331
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The MuJoCo-backed digital twin was buried in
examples/mujoco_xr— compiled as part of that example, reachable only by installing it, and gated on the developer having a matchingmujocowheel. It is a Televiz capability, not an example. The backend moves tosrc/viz/robot_twinand its Python surface toisaacteleop.viz.robot, both shipping in the wheel; the app that is left behind is renamedexamples/robot_viz.deps/third_partynow fetches MuJoCo and builds it under a private name, reached throughdlopen/dlsymso the extension carries no undefinedmj*for a foreignlibmujocoto answer.Mujoco.cmakebeside it states that contract. Users maypip install mujocoat any version, or none.Two calls for a reviewer: the wheel now redistributes MuJoCo binaries, and every
BUILD_VIZbuild compiles it with no opt-out (~40 s, needslibegl-dev).No tests here — they are #999, one commit on top of this branch. This alone drops six test files that exist on
main, so the two should land together.Type of change
isaacteleop_examples.mujoco_xris gone; the docs that referenced it are updated.Testing
cteston Linux aarch64 (Jetson AGX Orin), Release, CUDA, Python 3.12: 316 passed, 0 failed. #999 on the same machine is 330 / 0.readelfon the built artifacts confirms the isolation: one export, nolibmujocoor EGLNEEDED, private SONAME,SYMBOLICset.Checklist
SKIP=check-copyright-year pre-commit run --all-filesgit commit -s) per the DCO