Principle:ARISE Initiative Robosuite Controller Factory Pattern
| Knowledge Sources | |
|---|---|
| Domains | Robotics, Software Architecture, Design Patterns |
| Last Updated | 2026-02-15 07:00 GMT |
Overview
The controller factory pattern uses string-based type names to instantiate the appropriate controller class for a given robot body part, decoupling controller selection from the code that uses controllers.
Description
In a modular robotics framework, the specific controller used for a given body part (arm, gripper, mobile base, torso, head, legs) must be configurable at runtime. The controller factory pattern provides a centralized dispatch mechanism: given a string identifier for the controller type (e.g., "OSC_POSE", "JOINT_POSITION", "IK_POSE", "JOINT_VELOCITY", "JOINT_TORQUE", "GRIP") and a dictionary of parameters, the factory instantiates and returns the corresponding controller object.
The factory is hierarchically organized. A top-level dispatcher routes based on the body part name (e.g., "right" or "left" for arms, "right_gripper" or "left_gripper" for grippers, "base" for mobile bases) to a part-specific sub-factory. Each sub-factory maps the controller type string to the corresponding class constructor and handles any type-specific initialization, such as creating interpolators for controllers that support smooth goal transitions. This two-level dispatch keeps each sub-factory focused on a single body-part domain while the top-level factory presents a unified interface.
Configuration loading is also part of the factory infrastructure. Controller configurations can be loaded from JSON files, either from a custom path or from a built-in set of default configurations indexed by controller type name. This allows the same factory to be driven by external configuration files (for reproducibility and experiment management) or by programmatic parameter dictionaries.
Usage
Apply the controller factory pattern when a robotics framework must support pluggable, runtime-configurable controllers for multiple body parts. This pattern is essential for simulation environments where users switch between control modes (e.g., OSC for teleoperation, joint position for trajectory replay, torque for RL training) without modifying environment code. It is also critical for multi-robot setups where different robots may require different controllers.
Theoretical Basis
Controller Factory Architecture:
Top-Level Factory: controller_factory(part_name, controller_type, params)
|
|-- part_name in {"right", "left"}
| -> arm_controller_factory(controller_type, params)
| |-- "OSC_POSE" -> OperationalSpaceController(control_ori=True, ...)
| |-- "OSC_POSITION" -> OperationalSpaceController(control_ori=False, ...)
| |-- "IK_POSE" -> InverseKinematicsController(...)
| |-- "JOINT_POSITION" -> JointPositionController(...)
| |-- "JOINT_VELOCITY" -> JointVelocityController(...)
| |-- "JOINT_TORQUE" -> JointTorqueController(...)
|
|-- part_name in {"right_gripper", "left_gripper"}
| -> gripper_controller_factory(controller_type, params)
| |-- "GRIP" -> SimpleGripController(...)
| |-- "JOINT_POSITION" -> JointPositionController(...)
|
|-- part_name == "base"
| -> mobile_base_controller_factory(controller_type, params)
| |-- "JOINT_VELOCITY" -> MobileBaseJointVelocityController(...)
|
|-- part_name in {"torso", "head", "legs"}
-> respective sub-factories with JOINT_POSITION / JOINT_VELOCITY / JOINT_TORQUE
Configuration Loading:
load_part_controller_config(custom_fpath, default_controller)
-> Reads JSON from file path or default config directory
-> Returns parameter dictionary for factory consumption
Key design decisions:
- String-based dispatch: Using string names (e.g., "OSC_POSE") rather than class references allows controller selection to be driven by configuration files and command-line arguments.
- Part-specific sub-factories: Each body part has its own factory function, encapsulating part-specific logic (e.g., arm controllers may need interpolators for both position and orientation, while gripper controllers do not).
- Interpolator creation: The factory handles interpolator instantiation (linear interpolation between setpoints) based on the configuration, relieving the caller from this concern.
- Extensibility: Adding a new controller type requires only adding a new branch to the appropriate sub-factory and registering the type string.