Actively Compliant Arm Control for Agricultural Robotics

Return to Fabio Lo Presti's personal page

Actively Compliant Control for Agricultural Robotics

During my internship at IRALab, I developed control software for a robotic arm intended for autonomous agricultural tasks.
The system adapts to external forces in soft real-time while maintaining stability against expected loads such as gravity.

Tech Demo

Demonstration of behaviors enabled by the actively compliant control system. The demo is structured as a state machine, where the robotic arm transitions between states based on predefined thresholds for joint angle, velocity, or torque.

Project Overview

IRALab is developing Otto, a wheeled agricultural robot. The platform is designed to integrate a Piper robotic arm by Agilex to physically interact with its environment, with a current focus on autonomous weeding.

Agricultural environments are inherently unstructured and unpredictable. A rigid control strategy is insufficient; the robot must safely adapt to unknown forces while remaining stable during normal operation.

My contribution focused on the design and implementation of a control layer enabling this adaptive behavior.

This control strategy is referred to as compliance, more specifically active compliance, since the desired compliant behavior is not an inherent property of the mechanical structure but is instead generated by the control software using telemetry data.

Unlike passive compliance, where flexibility arises from physical elements such as springs or dampers, the system actively measures its state and interaction forces and adjusts its motion accordingly.

Why Active Compliance?

The weeding strategy under development involves grasping the weed with the gripper and applying traction using the wheeled base to extract it.

During this process, the Piper arm must passively extend when torque is applied to its joints. This reduces peak loads and shifts mechanical strain from the gear teeth to the gear shafts, helping to reduce wear and damage.

Diagram of Otto grasping a weed.

At the same time, if an unexpected force is encountered, for example due to an obstacle in the soil, the arm should not resist it, as this could cause significant damage.

Diagram of Otto encountering an obstacle while grasping a weed.

Making the arm compliant to all forces is straightforward. When the motors exert no torque, such as when the arm is powered off, it can be freely moved by hand and will fall under its own weight if unsupported. The main challenge is therefore not enabling compliance, but selectively resisting undesired forces such as gravity.

Implementation

The software computes the motor torque required at each joint to counteract undesired forces and uses this as a bias in the commands sent to the arm. Currently, this accounts only for the weights of the joints.

The arm is controlled using “MIT mode”, a built-in control mode that specifies the torque applied at each joint as follows:

u = Kp Δq + Kd Δq̇ + ub

Δq = qd − q

Δq̇ = q̇d − q̇

  • qd: target joint position (rad)
  • q: current joint position (rad)
  • q̇d: target velocity (rad/s)
  • q̇: current velocity (rad/s)
  • Kp: position gain
  • Kd: velocity gain
  • ub: torque bias
  • u: resulting torque

MIT mode inherently allows simple actively compliant behavior. However, achieving the desired effect of rendering the arm dynamically “weightless” is more complex and requires inverse dynamics.

Solving inverse dynamics efficiently is non-trivial. For this reason, the implementation relies on Pinocchio, a widely used dynamics library.

The software provides the library with a physical model of the arm and continuously updates its configuration using joint angle data.

To improve determinism, raw instantaneous measurements are not used. Instead, a windowed average over recent data within a fixed time interval is computed.

These averaged values are used to compute the torque bias terms, which are combined with user commands and continuously sent to the arm.

The manufacturer provides a calibrated physical model of the arm. However, this model does not perfectly match the real system and requires additional calibration.

In particular, torques computed at the joint axes in the simplified model must be mapped to the corresponding motor torques in the physical hardware.

Activity diagram illustrating the control flow and ROS message exchanges involved in actively compliant behavior.

The software is built using the Robot Operating System (ROS). Despite its name, ROS is not an operating system but a robotics framework that structures systems as multiple concurrent nodes communicating asynchronously, primarily through messages.

The system currently consists of three main nodes, corresponding to the swimlanes in the diagram:

  • Arm controller (in Python):
    Communicates directly with the arm over USB using the manufacturer's official SDK. It exposes the arm state and MIT mode command interface via ROS messages, normalizing all the values to standard units.
  • Telemetry node (in C++):
    Performs post-processing on telemetry data published by the arm controller. It computes windowed averages and message timing jitter within the averaging time window.
  • Active compliance node (in C++):
    Computes the motor torques required for gravity compensation using averaged telemetry data and a physical model of the arm. It listens for MIT mode command messages, applies the computed torque biases, and forwards the resulting commands to the controller.
Comparison of arm behavior when executing MIT mode commands with and without gravity compensation. Each row shows the resulting configuration without gravity compensation (left), with gravity compensation (center), and the corresponding command message (right).
Not gravity compensated Gravity compensated Command message 
{
  target_positions:
    [-0.78,0,0,0,0,0],
  target_speeds:
    [0,0,0,0,0,0],
  delta_position_multiplier:
    [0.5,0.5,0.5,0.5,0.5,0.5],
  delta_speed_multiplier:
    [0,0,0,0,0,0],
  torque_bias:
    [0,0,0,0,0,0],
  target_gripper_position:
    0,
  target_gripper_effort:
    0.5,
  is_gripper_enabled:
    true
}
        
{
  target_positions:
    [-0.78,0,0,0,0,0],
  target_speeds:
    [0,0,0,0,0,0],
  delta_position_multiplier:
    [5,5,5,5,5,5],
  delta_speed_multiplier:
    [0,0,0,0,0,0],
  torque_bias:
    [0,0,0,0,0,0],
  target_gripper_position:
    0,
  target_gripper_effort:
    0.5,
  is_gripper_enabled:
    true
}
        
{
  target_positions:
    [-0.78,1.57,-1.57,0,0,0],
  target_speeds:
    [0,0,0,0,0,0],
  delta_position_multiplier:
    [0.5,0.5,0.5,0.5,0.5,0.5],
  delta_speed_multiplier:
    [0,0,0,0,0,0],
  torque_bias:
    [0,0,0,0,0,0],
  target_gripper_position:
    0,
  target_gripper_effort:
    0.5,
  is_gripper_enabled:
    true
}
        
{
  target_positions:
    [-0.78,1.57,-1.57,0,0,0],
  target_speeds:
    [0,0,0,0,0,0],
  delta_position_multiplier:
    [1,1,1,1,1,1],
  delta_speed_multiplier:
    [0,0,0,0,0,0],
  torque_bias:
    [0,0,0,0,0,0],
  target_gripper_position:
    0,
  target_gripper_effort:
    0.5,
  is_gripper_enabled:
    true
}
        
{
  target_positions:
    [-0.78,1.57,-3.14,0,0,0],
  target_speeds:
    [0,0,0,0,0,0],
  delta_position_multiplier:
    [0.5,0.5,0.5,0.5,0.5,0.5],
  delta_speed_multiplier:
    [0,0,0,0,0,0],
  torque_bias:
    [0,0,0,0,0,0],
  target_gripper_position:
    0,
  target_gripper_effort:
    0.5,
  is_gripper_enabled:
    true
}
        
{
  target_positions:
    [-0.78,1.57,-3.14,0,0,0],
  target_speeds:
    [0,0,0,0,0,0],
  delta_position_multiplier:
    [1,1,1,1,1,1],
  delta_speed_multiplier:
    [0,0,0,0,0,0],
  torque_bias:
    [0,0,0,0,0,0],
  target_gripper_position:
    0,
  target_gripper_effort:
    0.5,
  is_gripper_enabled:
    true
}

Further work is required on the dynamics side, as the current system does not account for several dynamic effects which, while negligible in a laboratory setting, may become significant on a moving wheeled base.

Nonetheless, the current implementation provides a solid and maintainable foundation for IRALab's ongoing development.