Prandium Docs

16. Known issues and gaps in main

2 min read

Part I: The ROS 2 stack · §16 of 43

  • openarm.repos only lists openarm_can. openarm_description must be cloned separately, and the repo’s .docker/Dockerfile never runs vcs import (you patched both).
  • description_file launch argument is declared but unused. Both launch files default to arm_type=openarm_v2.0.
  • arm_prefix namespacing refers to openarm_bimanual_controllers_namespaced.yaml, which doesn’t exist.
  • MoveIt gripper controllers are GripperCommand but the bringup runs gripper JTCs (§9).
  • openarm_hardware uses the Humble-era on_init(HardwareInfo) signature (deprecation warnings on Jazzy). It doesn’t implement on_shutdown/on_error.
  • return_to_zero() sends the gripper 0.044 as a raw motor angle (no joint→motor conversion), so during activation the gripper goes to ≈ closed, not “open”. After activation, gripper commands are converted correctly. (The zeus patch ramps the gripper but keeps this target.)
  • return_to_zero() (upstream) first sends a full-stiffness command to 0 before reading the positions, then ramps to 0 in only 2 s, and never checks that the motors replied or how far the arm is from zero. Patched on zeus (§4).
  • OpenArmHW sends the torque-on command only in on_activate: motors powered later stay disabled while ROS keeps commanding them.
  • ros2_control_node (Jazzy) can segfault on Ctrl+C in JointTrajectoryController::update before the hardware is deactivated, leaving motors enabled (§12.4).
  • config/arm/joint_limits.yaml doesn’t match the limits the URDF actually uses for joints 1–2 (per-arm offsets and mirroring in openarm_arm.xacro), which is easy to misread (§3).
  • openarm-can-cli: monitor/diagnose/motor_status enable the motors, monitor decodes all motors as DM4310, set_zero defaults to all 8 motors (§10.5).
  • Gripper joint↔motor mapping is a linear approximation (source comment: “the mappings are approximates”). Gripper velocity/effort states are always 0.
  • *_forward_velocity_controller is declared but never spawned. Because MIT mode always includes the kp·(q_cmd − q) term and q_cmd keeps its last value, using it alone doesn’t give true velocity control. Don’t use it on hardware without modifying OpenArmHW.
  • No gravity compensation (tau_ff = 0).
  • JTC tolerances all 0, so failures are never detected (§4).
  • All four bringup JTCs set interpolation_method: none, so single-point and sparse goals step to the target after time_from_start instead of moving there. Changed to splines on zeus (§4).
  • The Python calibration tools need the openarm_can Python bindings, which colcon build doesn’t produce.

Graph View

Backlinks