Principle:ARISE Initiative Robosuite Object Modeling
| Knowledge Sources | |
|---|---|
| Domains | Robotics, Simulation, Procedural Generation |
| Last Updated | 2026-02-15 07:00 GMT |
Overview
Object modeling defines a hierarchy for creating simulation objects through either XML file loading or procedural geometry generation, with support for collision/visual geom separation, scaling, and joint attachment.
Description
Manipulation simulation environments require a rich set of objects for robots to interact with: household items, tools, fasteners, containers, and task-specific props. The object modeling principle provides a flexible hierarchy for defining these objects, supporting two creation pathways: loading from pre-authored XML files and procedural generation from geometric primitives.
The base object class establishes the common interface and infrastructure. Every object has a geometric type specification that controls which geoms are included: collision-only (for physics), visual-only (for rendering), or both. Objects support optional duplication of collision geoms as visual geoms, ensuring that physics-relevant geometry is always visible during debugging. The base class provides scaling capabilities that adjust all geometric dimensions uniformly or anisotropically, and asset merging for combining multiple objects' textures and materials.
The XML-based pathway loads objects from pre-authored MJCF files, which may contain mesh assets, textures, and complex geometry authored in external tools. These objects are parsed and processed like any other MJCF model: default classes are resolved, names are prefixed, and elements are categorized. Joints can be added programmatically (e.g., a free joint for objects that should be unattached, or hinge joints for articulated objects).
The procedurally generated pathway constructs object geometry from primitive shapes (boxes, cylinders, spheres, capsules) using the ElementTree API. This allows parametric randomization of object properties (size, density, friction, color) at initialization time, which is valuable for domain randomization in robot learning. Generated objects define their geometry through an _get_object_subtree method that returns an ElementTree representing the object's body hierarchy.
Usage
Apply XML-based object modeling when high-fidelity visual assets or complex mesh geometry is needed. Apply procedural generation when parametric randomization of object properties is important for training robust policies. Both pathways produce objects with the same interface, allowing tasks to use either type interchangeably. The collision/visual separation is particularly important for simulation performance: use collision-only for physics-heavy scenarios, visual-only for rendering-only objects (e.g., goal markers), and both for standard interactive objects.
Theoretical Basis
Object Modeling Hierarchy:
MujocoModel (semantic model base)
|
MujocoObject (object base)
| - obj_type: "collision" | "visual" | "all"
| - duplicate_collision_geoms: bool
| - scale: float or [float, float, float]
| - get_obj() -> ET.Element (copy with filtering)
| - set_scale(scale): scale all geometry
| - Properties: root_body, bodies, joints, sites,
| contact_geoms, visual_geoms,
| bottom_offset, top_offset, horizontal_radius
|
|-- MujocoXMLObject (XML-based)
| - Load from MJCF file
| - Process default classes, add prefix
| - Optionally add joints (free, hinge, etc.)
| - Support mesh and texture assets
|
|-- MujocoGeneratedObject (procedurally generated)
- Define geometry via _get_object_subtree()
- Construct from primitives: box, cylinder, sphere, capsule
- Parametric: size, density, friction, rgba, material
- Support randomized construction via RNG
Geom Filtering:
On get_obj(), filter geoms based on obj_type:
"collision" -> keep group 0 only
"visual" -> keep group 1 only
"all" -> keep both groups
If duplicate_collision_geoms:
Copy each collision geom as a visual-only geom
Joint Attachment:
joints parameter: list of joint specifications
"default" -> single free joint (6-DOF floating)
Custom -> list of dicts with type, damping, etc.
Joints are added to the root body of the object
Key design decisions:
- Dual creation pathways: Supporting both XML and procedural creation covers the full spectrum from high-fidelity asset-driven objects to parametrically randomizable training objects.
- Geom type filtering: Separating collision and visual geometry allows optimization (simpler collision shapes for faster physics) while maintaining visual fidelity.
- Automatic visual duplication: Copying collision geoms as visual geoms ensures that physics-relevant geometry is always visible, aiding debugging and visualization.
- Parametric randomization: Procedural objects accept ranges for properties, enabling automatic domain randomization without external scripts.
- Standardized interface: Both XML and generated objects expose the same properties (bodies, joints, offsets, radii), making them interchangeable in task definitions.