Skip to content

Known Problems

Start with the Kangaroo Doctor

Before you work through this list, open the Kangaroo Doctor at http://kangaroo-5c:8001. It shows which motors are in error, the e-stop state and deployer problems, and suggests the next step. Use this page for problems that the doctor's standard recovery order does not fix.

Recurring ESM OP state lost motor errors (EtherCAT)

Multiple motors (arm, leg and pelvis, on both sides) repeatedly switch to error state with the message ESM OP state lost in the diagnostics view Hardware > Motor, sometimes together with Motor errors detected. When this happens the robot drops out of stable OP state and cannot be used until it is reset.

The Kangaroo Doctor body map shows which motors are affected. First follow its standard recovery order. If the errors come back, check the cable as described below.

The cause is usually a flaky EtherCAT cable connection on the pelvis actuators, not a software fault. Reseating the connector (firmly unplug and reconnect) restores a stable OP state and clears the recurring errors.

Follow PAL's official cable connection check procedure when the error reappears:

Full write-up and status are in the issue tracker: Kangaroo esm_op_state_lost (see the issue tracker for all open issues).

Gripper goes into error when grasping an object (position mode)

The gripper motor raises an error when the target position and the actual position of the fingers differ too much. This usually happens when the fingers touch an object and cannot reach the commanded position. PAL can change the firmware so that this only raises a warning. Until then, the easiest fix is to control the gripper in impedance (current) mode instead of position mode.

  1. Stop the position controllers that default_controllers.launch starts:

    rosrun controller_manager controller_manager stop gripper_left_controller gripper_right_controller
    
  2. Load the parameters from gripper_current_controllers.yaml (provided by PAL):

    gripper_current_controllers.yaml
    gripper_left_current_controller:
      type: "effort_controllers/JointTrajectoryController"
      check_mode: True
      joints:
        - gripper_left_finger_joint
      gains: # Required because we're controlling an effort interface
        gripper_left_finger_joint: {p: 100,  d: 0, i: 0, i_clamp: 1}
      constraints:
        goal_time: &goal_time_constraint 0.6
        stopped_velocity_tolerance: &stopped_velocity_constraint 0.05
        gripper_left_finger_joint:
          goal: &goal_pos_constraint 0.02
    
      stop_trajectory_duration: 0.0
    
    
    gripper_right_current_controller:
      type: "effort_controllers/JointTrajectoryController"
      check_mode: True
      joints:
        - gripper_right_finger_joint
      gains: # Required because we're controlling an effort interface
        gripper_right_finger_joint: {p: 100,  d: 0, i: 0, i_clamp: 1}
      constraints:
        goal_time: *goal_time_constraint
        stopped_velocity_tolerance: *stopped_velocity_constraint
        gripper_right_finger_joint:
          goal: *goal_pos_constraint
    
      stop_trajectory_duration: 0.0
    
    rosparam load gripper_current_controllers.yaml
    
  3. Load and start the current controllers:

    rosrun controller_manager spawner gripper_left_current_controller gripper_right_current_controller
    

You can still move the gripper with the same joint trajectory interface, but the motor is now controlled by current. Change the PID gains (gains, default p: 100) in gripper_current_controllers.yaml to change the stiffness of the controller.

Left gripper does not move, but the bus looks fine

The left gripper drive hangs: it does not respond, but EtherCAT and the diagnostics look healthy. Check with Close left gripper in the Kangaroo Doctor (or rosrun kangaroo_doctor kangaroo_doctor.py gripper close). If the result is DID NOT MOVE, follow the gripper fix steps there.