Skip to main content
DimOS supports the OpenArm v2.0 bimanual platform as one robot with two 7-DOF arms and two grippers. Physical operation uses one Linux SocketCAN interface per arm. Start with fake hardware, verify the arm-to-bus mapping, and keep an E-STOP within reach before enabling motors.

​
Install

From a DimOS source checkout, install the manipulation dependencies:
skip
Physical OpenArm support is Linux-only. Fake hardware and planning can run on other supported platforms.

​
Prepare the CAN interfaces

Bring up both interfaces and verify their status:
skip
The default mapping is left arm on can1 and right arm on can0. Linux names USB CAN adapters in enumeration order, so confirm the mapping whenever adapters are reconnected. A swapped mapping can command the wrong arm.

​
Run with fake hardware

Run keyboard teleoperation in simulation mode:
skip
The Quest blueprint is fake-hardware-first and needs no simulation flag:
skip
Open https://<host-ip>:8443/teleop in the Quest browser. Accept the local certificate warning if prompted.

​
Run physical hardware

The keyboard blueprint selects physical hardware when --simulation is absent and uses the default CAN mapping:
skip
Quest teleoperation selects physical hardware only when both bus mappings are provided after the blueprint name:
skip
Providing only one port is rejected. These are blueprint options; the global --can-port option does not configure OpenArm. Other OpenArm blueprints do not currently expose per-arm remapping options, so use the Quest blueprint when the machine’s interface names differ from the defaults.

​
Controls and runtime behavior

Quest uses one bimanual IK task for both arms. Hold both controllers’ primary buttons to engage it. Releasing either button stops arm and gripper output and clears both controller references. Each controller trigger operates the gripper on the same side. Stale controller input, task preemption, E-STOP, or coordinator shutdown also clears the teleoperation session. Planned trajectories have priority 20 and preempt the Quest task at priority 10. Planning commands the fourteen arm joints; the grippers remain under Quest control. Keyboard teleoperation currently jogs the left arm while the right arm holds its anchor pose. The keyboard blueprint does not bind gripper controls.

​
Available blueprints

​
Troubleshooting

​
The wrong arm moves

Stop the blueprint immediately. Confirm which USB adapter Linux assigned to each interface, then pass the corrected left and right ports to the Quest blueprint. Do not assume can0 always identifies the same physical adapter.

​
One arm does not connect

Check both interfaces with dimos hardware can status. The Quest blueprint requires both explicit ports for physical operation and rejects a partial mapping.

​
Quest does not connect

Confirm that the headset can reach https://<host-ip>:8443/teleop, accept the certificate warning, and check that the host firewall permits the connection.

​
Quest runs but the arms do not move

Confirm that both primary buttons remain held. If the model moves in Viser but hardware does not, inspect command-tracking and joint-limit warnings before raising any safety threshold.

​
Motion is slow, unstable, or stops near a limit

Do not change the canonical startup pose to hide the symptom. Follow Pink IK Configuration and Tuning to verify the model, tune objective weights, and bound streaming commands. The shared Damiao hardware gate derives each angular joint limit from the robot URDF and clamps encoder feedback that is no more than 0.05 rad outside it. A larger excursion indicates a calibration, model, or encoder fault. The adapter disables the motors, rejects further activation, and logs the affected joint and bounds. Inspect the arm, then restart the blueprint or reconnect the hardware before resuming motion.

​
Further reading