Repository navigation
Add OneRobotics A1 asset and Isaac Teleop example #1291
Description
Summary
We would like to add OneRobotics A1 assets and a joint-space Isaac Teleop
example to Isaac Capture.
The initial integration targets the OneRobotics A1 7-DoF right arm and provides:
- URDF and MJCF assets
- STL meshes
- License and provenance records
- SHA256 asset manifest
- Isaac Teleop joint-state mapping
- A runnable MuJoCo demonstration example
Motivation
The A1 asset is needed for validating joint-space teleoperation and simulation
integration with a 7-DoF OneRobotics arm.
The proposed example uses the existing Isaac Teleop retargeting pipeline:
JointStateSource -> JointStateRetargeter -> OutputCombiner("action")
Proposed Scope
- Add the OneRobotics A1 asset package under the Teleop examples.
- Add a right-arm joint-space mapping for the seven A1 joints.
- Add a MuJoCo demo that exercises the packaged right-arm MJCF.
- Add a live mode that consumes A1 joint states from a DeviceIO source.
- Install the asset package with the Teleop examples.
- Preserve asset license, attribution, and provenance information.
Joint Mapping
The right-arm joint order is:
joint1-a1_rjoint2-a1_rjoint3-a1_rjoint4-a1_rjoint5-a1_rjoint6-a1_rjoint7-a1_r
The proposed collection id is:
onerobotics_a1_right
Asset Provenance
- Source repository: https://github.com/katazen/onerobot_h1
- Source revision:
ecf530911284ba0e559f7a24dc222fd8e60d31ed - Asset license: CC BY 4.0
- Attribution: OneRobotics A1 robot assets © 2026 OneRobotics
The package includes the license text, third-party notices, and SHA256
verification manifest.
Validation
The following validations have been completed locally:
- A1 right-arm MJCF compiles successfully in MuJoCo.
- The model contains seven joints.
- MJCF joint names match the Isaac Teleop mapping.
- A1_2026 SHA256 manifest passes.
- STL files are managed with Git LFS.
- Ruff, REUSE, Git LFS, and documentation checks pass.
Open Questions
- Is
examples/teleop/assets/an acceptable location for this asset? - Should the A1 assets be moved to a separate asset repository?
- Should the live example remain a generic JointState consumer, or should an
A1-specific DeviceIO plugin also be added? - Is the included MuJoCo MJCF acceptable for the initial integration?
- Should the example target only the right arm, or also expose the bimanual
A1 configuration?
Checklist
- Asset provenance documented
- License documented
- SHA256 manifest included
- MJCF load validation completed
- Isaac Teleop joint mapping implemented
- Runnable demo added
- Maintainer feedback received
- Final PR opened
Activity
ivany-nv commentedon Oct 21, 2026
Hi @WangXuechun-woan,
I'd like to agree on the integration shape with you, because it decides most of what that PR should contain.
Where the A1 fits in Isaac Teleop
Isaac Teleop's extension points are on the operator side: an input device (XR hands or controllers, a leader arm, a glove) streams data through DeviceIO, and retargeters turn that data into commands for a robot.
JointStateSourcewithJointStateRetargeter(mode="joint")is the path for joint-space input devices. The SO-101 and reBot DevArm leaders are the reference instances, and each ships a plugin with a synthetic backend so the path also runs without hardware.In #1292 the A1 is wired as the input device and mapped onto itself. That only works if an A1 leader streams its own joint states, so the key question for you is:
Is there an A1 leader device, now or planned?
src/plugins/with a synthetic backend (likeso101_leaderorrebot_devarm_leader), plus a small config. The robot meshes are not needed for that.JointStateRetargeter(mode="ee_pose"), and the A1 follows those end-effector targets in your Isaac Lab environments or your own controller.Your open questions
examples/teleop/assets/acceptable? We'd prefer not to store robot meshes in this repository. Other third-party arms are fetched from a pinned commit and checksum-verified at runtime (seesrc/python/isaaccapture/viz/robot/assets.py), and the A1 assets are already going through NVIDIA hosting and legal review in feat: add OneRobotics A1 assets and Reach environments isaac-sim/IsaacLab#7446. Ideally Isaac Teleop uses that same copy, so there is one A1 model and one review.A1_2026revision that Isaac Lab uses.Once we know which side the A1 is on, I'm happy to review it deeper.
WangXuechun-woan commentedon Oct 21, 2026
Hi, thank you for clarifying the intended integration shape.
There is currently no A1 leader device, and we do not have one planned. The A1 is the robot being teleoperated, rather than an operator-side input device.
Based on your guidance, I will revise the integration as follows:
examples/teleop/assets/.JointStateSourceandJointStateRetargeter(mode="joint").SE3 retargeter or an existing leader arm through
JointStateRetargeter(mode="ee_pose").OneRobotics A1 Isaac Lab environment or controller.
available, rather than maintaining another copy in Isaac Teleop.
Therefore, an A1-specific DeviceIO plugin is not needed. The revised PR will
focus on a thin integration/configuration example connecting Isaac Teleop
operator inputs to the A1 right-arm end-effector target.
Would you prefer that I revise #1292 after the hosted Isaac Lab asset is
available, or should I first submit the operator-to-A1 target configuration
without visualization and robot assets?
Thanks again for the detailed direction.