Skip to content

Concepts

In this section, we will introduce the concepts and basic architecture of the software for AIRBOT product series.

1. Software Architecture

  • framework

  • The software architecture for AIRBOT robot series consists of three main layers:

    • Data Link Layer: Run on the host connected to AIRBOT products. This layer is responsible for the communication between the robot and the external world. The communication is done in a real-time environment, running at a control frequency of 250Hz.
    • Driver Layer: Run on the server side. This layer maintains the robot's internal states and provides functionalities for controlling the robot. The driver layer is responsible for executing (and possibly preprocessing) commands and providing feedback to the external world.
    • Application Layer: Run on the server side. This layer provides the higher functionalities of the robot. In the world of AIRBOT, each application is a module (referred to as an APP) that can be loaded and unloaded by the driver layer. Currently provided applications are:
      • record_replay_app: This application provides functionalities for recording and replaying the robot's motion.
      • ai_infer_app: This application provides functionalities for AI inference. (working in progress)
    • SDK Layer: Run on the client side. SDK provide efficient and user-friendly ways to communicate with the driver layer. No internal states are held in the SDK layer so that multiple clients can connect to the same driver simultaneously. Currently provided SDKs are:
      • Python SDK
      • C++ SDK (working in progress)
      • JavaScript SDK (working in progress)

2. Driver State

The driver service works in a state machine that has these states:

  • IDLE: The driver is idle and waiting for commands. In this state, external commands can be sent to the driver and executed via SDK (Python SDK or C++ SDK).
  • APPLOADED: An APP is loaded and running. An APP is an out-of-the-box module providing specific functionalities based on the driver. APPs are classified into two types according to their behaviors:
    • READ-ONLY: The APP is in read-only state. In this state, the driver can only read the internal states of the robot and cannot send any commands to the robot.
    • READ-WRITE: The APP is in read-write state. In this state, the driver can send commands to the robot and control its internal states. Multiple applications can be loaded at the same time, but only one application can be in read-write state. Also, in this state, external controlling commands sent by the SDK (Python SDK or C++ SDK) will be rejected by the driver, while states feedback will still be sent to the SDK.
  • ERROR: The driver is in error state.

An APP can be loaded and unloaded via the SDK. Python SDK examples are provided:

# Load APP
python3 -m airbot_examples.app_load -a record_replay_app/record_replay_app::RecordReplayApp
# Or,
arm_load_app

# Unload APP
python3 -m airbot_examples.app_unload
# Or,
arm_unload_app

When AIRBOT Play is running, long press the base button for 3 seconds to load and unload record_replay_app APP.

3. Control Mode

Currently supported control modes are:

  • PLANNING_POS: planning mode. A single target is sent to driver server, then a execution path is planned and execute. The target could be joint positions or end cartesian pose.
  • PLANNING_WAYPOINTS_PATH: planning mode. Perform linear interpolation between multiple waypoints in cartesian space, then execute the path without stopping.
  • PLANNING_WAYPOINTS: planning mode. Perform local planning between adjacent waypoints, join the planned paths then execute the path. Deceleration may occur near waypoints.
  • SERVO_CART_TWIST: servo mode in cartesian space. Servo would require continuous commands to be sent to the driver server. In this mode, the robot would follow the cartesian twist commands, each of which representing the expected translational and rotational velocity of the end flange or the effecting point of the end effector.
  • SERVO_CART_POSE: servo mode in cartesian space. Servo would require continuous commands to be sent to the driver server. In this mode, the robot would follow the cartesian pose commands, each of which representing the expected cartesian pose of the end flange or the effecting point of the end effector.
  • SERVO_JOINT_POS: servo mode in joint space. Servo would require continuous commands to be sent to the driver server. In this mode, the robot would follow the joint position commands, each of which representing the expected joint position of the arm.
  • SERVO_JOINT_VEL: servo mode in joint space. Servo would require continuous commands to be sent to the driver server. In this mode, the robot would follow the joint velocity commands, each of which representing the expected joint velocity of the arm.
  • GRAVITY_COMP: gravity compensation mode. In this mode, the robot would be in a free-drive state with gravity compensated. In this mode the robot would not follow any commands, but the robot could be dragged by external forces.

Control mode can be switched via the SDK. Python SDK examples are provided:

python -m airbot_examples.switch_mode -m <CONTROL_MODE>
# Or,
arm_switch_mode -m <CONTROL_MODE>