Principle:ARISE Initiative Robosuite Controller Abstraction
| Knowledge Sources | |
|---|---|
| Domains | Robotics, Software Architecture, Control Theory |
| Last Updated | 2026-02-15 07:00 GMT |
Overview
The controller abstraction principle defines a uniform base class interface for body-part controllers, ensuring that all controller variants share a common contract for state updates, goal setting, action scaling, and torque computation.
Description
In robotic systems with multiple control strategies (position control, velocity control, torque control, task-space control), a common interface is essential for composability and interchangeability. The controller abstraction principle establishes a base class that all concrete controllers inherit from, defining the lifecycle of a control loop: initialization from simulator state, periodic state updates, goal setting based on policy actions, action scaling and clipping, torque computation, and output clamping.
The base class maintains references to the physics simulator, tracks the controlled joints via index mappings (joint indices, generalized position indices, generalized velocity indices), and stores the actuator range for torque clamping. It provides state update logic that reads end-effector pose, velocity, Jacobians, and the mass matrix from the simulator at each control step, with a lazy update mechanism that skips redundant computations unless forced. An abstract run_controller method defines the contract that each subclass must implement to convert goals into torques.
Action scaling is another core responsibility of the base class. Raw policy actions are clipped to a configured input range and linearly remapped to an output range, decoupling the policy's action representation from the physical units of the controller. The base class also provides gravity compensation via the simulator's bias force vector, which subclasses can add to their computed torques. This layered design allows new control strategies to be added by implementing only the goal-setting and torque-computation logic, inheriting all other infrastructure automatically.
Usage
Apply the controller abstraction pattern whenever a robot simulation framework must support multiple interchangeable control strategies for the same body part. This principle ensures that higher-level components (composite controllers, environments, teleoperation interfaces) can interact with any controller through a uniform API, without knowledge of the specific control law being used.
Theoretical Basis
The design follows the Template Method pattern from object-oriented software engineering:
Abstract Controller Interface:
- __init__(sim, joint_indexes, actuator_range, ...)
Initialize from simulator state; compute initial Jacobians, mass matrix
- update(force=False)
Read joint_pos, joint_vel, ref_pos, ref_ori_mat, J_pos, J_ori, mass_matrix
Skip if already up-to-date (lazy update), unless force=True
- set_goal(action) [abstract - subclass must implement]
- run_controller() -> tau [abstract - subclass must implement]
Also resets the update flag so next update() proceeds
- scale_action(action)
clip(action, input_min, input_max)
transform linearly to [output_min, output_max]
- clip_torques(tau)
clip(tau, actuator_min, actuator_max)
Properties:
- torque_compensation: gravity + Coriolis bias from sim
- control_limits: (input_min, input_max)
- actuator_limits: (actuator_min, actuator_max)
- name: unique string identifier for the controller type
Key design decisions:
- Lazy state updates: The update flag mechanism prevents redundant forward dynamics calls when the simulator state has not changed, reducing computational overhead.
- Lite physics mode: An optional mode skips explicit forward calls during updates, relying on the environment's own stepping to keep state current, trading accuracy for speed.
- Reference site abstraction: The controller can track one or multiple reference sites (end-effector frames), supporting both single-arm and multi-site control (e.g., humanoid hands plus head).
- Separation of concerns: Action scaling, torque clamping, and gravity compensation are handled generically, leaving subclasses to focus solely on their specific control law.