Skip to content
AIRBOT P7 7-Axis Robotic Arm AIRBOT P7 7-Axis Robotic Arm
⚙ Development Guide > SDK > Appendix

Motor Error Code Troubleshooting#

The P7 SDK returns raw error integers through ArmMotorState.error_ids and EEFMotorState.eef_error_id. The meaning of an error bit or code depends on the motor, firmware, and complete-system version, so this page does not provide a full numeric lookup table copied from another product.

Preserve On-Site Information First#

After detecting a nonzero error value, first stop subsequent operations that require the affected device to remain healthy, and preserve:

  • ServiceState.fsm_state, service_state, and valid;
  • every raw robot-arm or EEF error integer, not only the first one;
  • corresponding motor temperatures, joint positions, and velocities;
  • ArmFirmwareInfo, Python SDK, and Arm App versions;
  • the time of occurrence and the mode, payload, tool, power supply, cables, and on-site symptoms at that time.

Do not treat None as an all-zero state, and do not call an error-clearing method before recording the information.

Choose an Action Based on State#

Symptom Next Step Do Not
Nonzero robot-arm error_ids and FSM is UNKNOWN_ERROR Eliminate the indicated power-supply, cable, payload, temperature, or firmware cause; then acquire control authority and use the supported error-clearing workflow Retry without a limit or discard the original error code
EEF error is nonzero Keep the system stopped, record the EEF model, mode, state, and versions, and use the recovery instructions for the delivered configuration Probe the currently unsupported EEF error-clearing entry point
FSM is IN_COLLISION Keep the system stopped and follow the collision-recovery workflow Bypass the collision state with motor error clearing, an ordinary stop, or emergency-stop reset
State is missing or stale, or a stop cannot be confirmed Isolate the work area and check communication and the service; use the physical emergency stop if necessary Continue control or recover automatically based on an old cache

Robot-Arm Error-Clearing Interfaces#

clear_error() and clear_arm_motor_err() currently enter the same UNKNOWN_ERROR clearing path. The service must be in UNKNOWN_ERROR, the latest robot-arm motor state must be complete, the cause of the error must have been eliminated, and the client must hold control authority.

client.clear_error() -> bool
client.clear_arm_motor_err(retry: bool = True) -> bool

Even after error clearing returns True, read ServiceState to confirm that it has returned to IDLE, and then read motor state to confirm that the error has not recurred. If the method returns False, times out, or the error reappears, stop retrying and preserve the logs and original error values.

Although clear_eef_motor_err() is a public method, both current gRPC and DDS backends raise UnsupportedOperationError. Do not include it in an automatic recovery workflow.

A software emergency stop cannot replace the physical emergency stop

The SDK software emergency stop depends on the host computer, network, and board-side service. If unexpected motion occurs, a person enters the work area, or a stop cannot be confirmed, on-site personnel must operate the physical emergency stop and follow the site's safety procedure.

See API Reference for safety and recovery interfaces, and ArmState (Robot Arm State) and EEFState (End-Effector State) for field definitions.