Jump to content

Connect Leeroopedia MCP: Equip your AI agents to search best practices, build plans, verify code, diagnose failures, and look up hyperparameter defaults.

Principle:ARISE Initiative Robosuite Controller Configuration

From Leeroopedia

Metadata

Property Value
sources robosuite
domains Robotics_Simulation, Control_Systems
last_updated 2026-02-15 12:00 GMT

Overview

Mechanism for loading and configuring composite robot controllers from JSON configuration files to define the control strategy for a robot.

Description

Robosuite uses a two-level controller architecture where composite controllers orchestrate multiple part controllers (arm, gripper, mobile base). Configuration is driven by JSON files stored in robosuite/controllers/config/. Each robot has a default controller config that defines how its constituent parts should be controlled.

The system supports several composite controller types:

  • BASIC - Standard composite controller for basic robot configurations
  • HYBRID_MOBILE_BASE - Controller for robots with mobile bases
  • WHOLE_BODY_IK - Inverse kinematics-based whole body control
  • WHOLE_BODY_MINK_IK - Model-based inverse kinematics for whole body control

Configuration files are organized hierarchically:

  • Default composite controller configs: robosuite/controllers/config/default/composite/
  • Robot-specific configs: robosuite/controllers/config/robots/

Each configuration file maps robot part names (e.g., "arm_0", "gripper_0", "mobile_base") to their respective controller types and parameters. This separation allows for flexible controller composition and easy experimentation with different control strategies.

Usage

Use this principle when you need to specify a control strategy before creating a robosuite environment. The loaded configuration dictionary is passed as the controller_configs parameter to robosuite.make(). This configuration determines how the robot will respond to actions during simulation.

Typical workflow:

  1. Load a controller configuration using the appropriate loading function
  2. Optionally modify the configuration dictionary to customize parameters
  3. Pass the configuration to robosuite.make() when creating the environment
  4. The environment instantiates the configured controllers for robot control

Theoretical Basis

The controller configuration system implements a config-driven controller instantiation pattern. This design pattern separates controller logic (implementation) from configuration (declarative specification), providing several benefits:

  • Modularity: Controllers are composed from independent part controllers
  • Flexibility: Different control strategies can be swapped via configuration
  • Maintainability: Controller parameters can be tuned without code changes
  • Reusability: Configurations can be shared across robots with similar structures

Configuration-Driven Instantiation

The pattern follows this flow:

# Pseudocode for config-driven controller lookup and instantiation

def load_controller_config(controller_name=None, robot_name=None):
    """
    Load controller configuration from JSON files

    Lookup hierarchy:
    1. If controller_name provided -> load from default/composite/{controller_name}.json
    2. If robot_name provided -> load from robots/{robot_name}.json
    3. Return configuration dictionary
    """

    if controller_name:
        # Load from default composite controller configs
        config_path = f"config/default/composite/{controller_name}.json"
    elif robot_name:
        # Load robot-specific default config
        config_path = f"config/robots/{robot_name}.json"
    else:
        raise ValueError("Must specify controller or robot name")

    # Load and parse JSON configuration
    config_dict = load_json(config_path)

    # Configuration structure:
    # {
    #     "type": "BASIC" | "HYBRID_MOBILE_BASE" | "WHOLE_BODY_IK" | ...,
    #     "body_parts": {
    #         "arm_0": {
    #             "controller_type": "OSC_POSE",
    #             "controller_config": {...}
    #         },
    #         "gripper_0": {
    #             "controller_type": "GRIPPER",
    #             "controller_config": {...}
    #         }
    #     }
    # }

    return config_dict


def instantiate_composite_controller(config, robot):
    """
    Instantiate composite controller from configuration
    """

    # Create composite controller of specified type
    composite_type = config["type"]
    composite_controller = CompositeControllerFactory.create(composite_type)

    # Instantiate and register part controllers
    for part_name, part_config in config["body_parts"].items():
        controller_type = part_config["controller_type"]
        controller_params = part_config["controller_config"]

        # Create part controller
        part_controller = ControllerFactory.create(
            controller_type,
            robot.get_part(part_name),
            **controller_params
        )

        # Register with composite controller
        composite_controller.register_part(part_name, part_controller)

    return composite_controller

Separation of Concerns

The configuration system maintains clear separation between:

  • Configuration Layer (JSON files): Declarative specification of controller types and parameters
  • Factory Layer (loading functions): Responsible for reading and parsing configurations
  • Controller Layer (controller classes): Implements control algorithms and logic
  • Robot Layer (robot models): Defines physical structure and dynamics

This layered architecture enables independent development and testing of each component while maintaining clean interfaces between layers.

Related Pages

Page Connections

Double-click a node to navigate. Hold to expand connections.
Principle
Implementation
Heuristic
Environment