VR teleoperation on OpenArm v1 hardware: what is supported today?

[gunyarakun]

Context

We received this question from a user who bought an OpenArm v1 follower arm.

We are trying to teleoperate the arm with a VR headset following
https://docs.openarm.dev/tutorial/data-collection-vr/
but the code and instructions appear to target v2, and we are having
difficulty getting it working on v1 hardware.

Posting it here rather than answering directly, so the answer is public and searchable for other v1 owners. I will answer it myself below and mark it as the answer.

Questions

1. Which repositories, branches and configuration files are usable for VR teleoperation on v1 hardware today?
2. What specifically differs from the v2 instructions (kinematic description, CAN / motor configuration, gripper and end-effector definition)?
3. Do we intend to document a v1 VR path, or should v1 users stay on leader-follower teleoperation?

[gunyarakun]

Short answer: "there is no officially tested VR teleoperation path for v1 today", but the gap is smaller than it looks.

The /tutorial/ pages are versioned, and the current version is 2.0. The dora-rs based stack behind them (dora-openarm-data-collection, dora-openarm-vr, dora-openarm-webxr, dora-openarm-kinematics, dora-openarm) is developed and tested against OpenArm 2.0.

The v1 documentation lives at https://docs.openarm.dev/1.0 and is no longer actively maintained. Its Teleop section covers leader-follower (unilateral and bilateral) control only. VR teleoperation for v1 never went past a simulation prototype.

What you can do with v1 hardware

Most of the pipeline is arm-version agnostic:

VR device -> pose / trigger -> IK -> joint targets -> CAN -> arm

Motor IDs and motor models are the same on v1 and v2, so the CAN and motor configuration can be used as is. The only version-specific layer is the kinematic description, and it differs in three ways.

1. URDF / MJCF: The IK node and the MuJoCo scene must load the v1 description, not the v2 one. See assets/robot/openarm_v1.0/ in
   enactic/openarm_description. Check that the end-effector frame names match what your IK node expects.

2. Joint zero conventions: Joint 5 has a 90 degree offset between the two descriptions. Everything else (joints 1, 2, 3, 4, 6, 7) uses the same zero and the same sign.

right arm:  q5_v1 = q5_v2 - pi/2
left  arm:  q5_v1 = q5_v2 + pi/2

The end-effector frame convention also differs by a constant rotation [[0,1,0],[1,0,0],[0,0,-1]], applied to the IK target orientation. Positions need no correction.

3. Gripper: v1 uses a parallel gripper, while v2 uses a pinch gripper. The trigger-to-gripper mapping has to be rewritten, not just rescaled.

If you get those right, the rest of the dataflow should run.

Recommended starting point

Use the WebXR path rather than the Quest APK path.
https://docs.openarm.dev/tutorial/data-collection-webxr

Suggested order:

1. Get it running in MuJoCo first, with the v1 model loaded. Command a few known poses and confirm the simulated arm matches what you expect on the real one. Never go to hardware before that matches.
2. On hardware, hold the trigger and let the initial alignment finish before any large motion.

A caveat, and a request

To be upfront: none of the above has been tested end to end on v1 hardware.

If you try it, please report back in this thread: what worked, what did not, and anything you had to change. That is genuinely useful to us and to the next person who asks.