Skip to main content
Version: 2.0

Questions

Where is the OpenArm 1.0 documentation?​

This site shows the latest documentation (OpenArm 2.0) by default. To view the OpenArm 1.0 documentation, use the version dropdown in the top right of the navigation bar, or go directly to the 1.0 documentation.

Is there a mobile base?​

The OpenArm project does not currently have any short-term plans for a mobile base. Please consider integrating it with another project, for more information, refer to this GitHub issue.

The motor is not working.​

See the troubleshooting section.

The arm stops moving or doesn't communicate.​

Turn off the power, then check the following. See also the safety guide.

  • Loose connectors and broken wires: a loose connector or a broken wire can stop a motor from moving or block communication. Check the connectors and wiring first. The wiring from the elbow (J4) to the gripper (J8) moves a lot during operation, so it wears out and comes off easily. Check it carefully.
  • CAN bus-off: long wires or some cable routings can cause signal reflections that put the CAN bus into bus-off. This is rare, but it stops the arm. Bring the CAN interface down and up again to restore communication. See Setup CAN Interface.
  • Termination resistors: the arm can stop working if a termination resistor is removed. Make sure the termination resistors are connected. See also OpenArm CAN CLI troubleshooting.

A connector comes off during operation.​

Wrap the L-shaped connector with cable ties or tape so that it doesn't come off. Turn off the power before working on it.

The arm wobbles or its motion is unstable.​

Turn off the power, then check the screws.

  • Vibration during operation tends to loosen the screws around the wrist.
  • Loose screws around the elbow can cause play in the joint and make the arm's motion unstable.

The arm doesn't reach the commanded position or the end effector sags.​

The default control gains are set low for safety. With low gains, gravity leaves a steady-state error in each joint, and the error grows at the end effector when the arm is extended.

Increase the position gain (Kp) first. This fixes most of the steady-state error and the sagging.

We recommend tuning in the following order:

  1. Kp
  2. Kd
  3. Gravity compensation
  4. Friction compensation
  5. Integral gain (Ki) and disturbance observer (DOB), only if still needed

OpenArm software controls the arm motors only in MIT mode (PD control with feedforward torque). It doesn't provide an inner position or velocity loop with integral control or a disturbance observer. If you implement them yourself, we don't recommend combining Ki and DOB because they can interfere with each other and cause oscillation.

For reference, see the gains used in our software:

See Control Gains for how to change the gains. Start with low gains and increase them gradually. With high gains, a command far from the current position can move the arm dangerously fast.

The joint positions match the command, but the end effector is off.​

Check which frame you are controlling. The planning groups of the MoveIt2 integration end at J7, so MoveIt moves the origin of openarm_<side>_ee_base_link, which is on the J7 axis, to the target pose. The fingertips are about 0.17 m away from this point.

To control the end effector accurately, use a frame at the tool center point (TCP) of your task as the control point. We don't define a standard TCP because the best point depends on the task. For reference, the lower end of the fingertips is 0.170 m from the origin of openarm_<side>_ee_base_link along its -Z axis when the gripper is closed.

How do I check that the arm has reached the target?​

In the default configuration of ROS 2 control, the joint trajectory controllers don't check the goal tolerance. A trajectory can succeed even if the arm hasn't reached the target, for example because of the steady-state error. Check the error between the target and the actual position yourself. We recommend checking the error at the end effector, not at each joint.

You can also set the goal tolerance of each joint (constraints.<joint>.goal) in the controller configuration to make a trajectory fail when the arm doesn't reach the target. The appropriate tolerance depends on your task and gains.

The cameras disconnect.​

In the standard configuration in the OpenArm 2.0 BOM, the head stereo camera (ZED mini) and both wrist cameras share one USB hub and one USB repeater cable.

PC ── USB repeater cable (5 Gbps) ── USB hub ─┬─ Head stereo camera (ZED mini)
                                              ├─ Right wrist camera
                                              └─ Left wrist camera

The cameras can disconnect when the hub's power or the shared link is not stable. Check the following in order.

  • Connect the auxiliary power supply (USB charger) to the USB hub.
  • Connect the USB repeater cable to a USB Type-C port of 5 Gbps or faster on the PC.
  • If the cameras still disconnect, connect the head stereo camera directly to the PC instead of the USB hub. Some PCs share an internal hub among several ports, so run lsusb -t to make sure that it is not under the same hub as the wrist cameras.

Should I use the zero-position calibration jig with OpenArm Cell?​

We recommend the zero-position calibration with the mechanical limits in OpenArm Cell instead of the jig. The jig aligns the arm to OpenArm Cell, so assembly errors of the Cell shift the zero position. The calibration with the mechanical limits uses the mechanical limit of each joint, so the assembly errors of the Cell don't affect it.

OpenArm Cell shuts off during zero-position calibration.​

The wiring around the elbow or other joints may enter the detection area of the area sensors and trigger the Reach-In Stop. Turn off the power, then secure the wiring along the arm so that it stays out of the detection area.

The LED panels of OpenArm Cell get very hot.​

The LED panels get very hot when they are left on. Turn them off when you are not using OpenArm Cell, and do not touch them while they are on. Adding a switch to the power supply of the LED panels makes it easy to turn them off.

Please use the CAN-FD devices listed in the OpenArm 1.0 Bill of Materials > Electronics. Using other CAN devices may result in unexpected behavior.

How accurate and repeatable is it?​

We're preparing the documentation.

How much power does it consume?​

We're preparing the documentation.

Where can I get support?​

You can also reach out to our community for tips and help.

  • Discord Connect with other builders, researchers, and the OpenArm team for real-time support and discussions: Join Now

  • GitHub Issues Report bugs or request features directly in our repository: Open an Issue

  • GitHub Discussions Ask technical questions directly in our repository: Start a Discussion

Last updated on