Jump to content

Connect SuperML | Leeroopedia MCP: Equip your AI agents with best practices, code verification, and debugging knowledge. Powered by Leeroo — building Organizational Superintelligence. Contact us at founders@leeroo.com.

Principle:ARISE Initiative Robosuite Robot Model Hierarchy

From Leeroopedia
Knowledge Sources
Domains Robotics, Simulation, MJCF Modeling
Last Updated 2026-02-15 07:00 GMT

Overview

A hierarchical set of model classes that represent robot kinematic and dynamic descriptions in MJCF format, organized by morphology to support single-arm manipulators, bimanual humanoids, upper-body humanoids, and legged manipulators.

Description

Physics simulators that use XML-based model descriptions (such as MJCF) require a programmatic layer to load, modify, and compose robot models at runtime. A robot model hierarchy provides this layer by defining a base class that wraps the raw XML tree and exposes properties for joints, actuators, end-effector names, and default configurations. Each subclass specializes the base for a particular morphology, adding logic for gripper attachment, arm type detection (single versus bimanual), and body-part-specific joint and actuator groupings.

The base robot model class handles universal concerns: loading the XML file, adjusting joint attributes such as friction loss, damping, and armature, setting the base position and orientation, and attaching a base model (mount, mobile base, or legged base). It also maintains a registry of all concrete robot model classes through a metaclass, enabling factory-based instantiation by name.

Manipulator models extend the base with gripper management, hand rotation offset computation, and categorization of joints and actuators into arm, base, torso, head, and leg groups. Humanoid models specialize for bimanual bodies that have both left and right end-effectors. The upper-body humanoid variant targets robots where only the torso and arms are modeled. Legged manipulator models add the ability to remove joint actuation and free joints from leg segments, supporting configurations where legs may be passive or replaced by a floating base.

Usage

Use this principle when building a robot model library that must accommodate diverse robot morphologies under a common interface. It applies whenever new robot types need to be added by subclassing and registering with a factory, and when the model layer must support runtime composition of bases and grippers onto a core robot body.

Theoretical Basis

The hierarchy uses a metaclass-driven registration pattern:

class RobotModelMeta(type):
    def __new__(meta, name, bases, class_dict):
        cls = super().__new__(meta, name, bases, class_dict)
        if cls.__name__ not in _unregistered:
            REGISTERED_ROBOTS[cls.__name__] = cls
        return cls

This ensures every concrete robot model subclass is automatically available for factory instantiation via its class name string.

The morphology hierarchy is structured as:

MujocoXMLModel
  +-- RobotModel                   (base: XML loading, joint attributes, base attachment)
        +-- ManipulatorModel       (single/bimanual arms, gripper attachment, actuator grouping)
        |     +-- LeggedManipulatorModel  (leg joint removal, free joint removal)
        +-- HumanoidModel          (full-body bimanual humanoid)
        +-- HumanoidUpperBodyModel (upper-body only bimanual humanoid)

Joint attribute initialization applies default physical parameters:

frictionloss = 0.1 for all joints
damping = 0.1 for all joints
armature_i = 5.0 / (i + 1)  (decreasing with joint index)

Gripper attachment merges the gripper XML subtree into the robot body at the end-effector link, compounding rotation offsets between the hand link and the gripper frame.

Related Pages

Page Connections

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