Principle:Google deepmind Dm control MJCF Model Attachment
| Metadata | |
|---|---|
| Knowledge Sources | dm_control |
| Domains | Physics Simulation, Robotics, Model Composition |
| Last Updated | 2026-02-15 00:00 GMT |
Overview
Composing multiple independently authored physics models into a single unified model through hierarchical attachment and automatic namespace isolation enables modular, reusable simulation design.
Description
MJCF Model Attachment is the mechanism by which two or more MJCF models are combined into a single coherent model. This is the cornerstone of model composition -- the idea that complex environments can be assembled from simpler, reusable building blocks (e.g., a robot, an object, and an arena).
The fundamental operation is attaching one model (the child) to a specific site or worldbody in another model (the parent). When attachment occurs:
- An attachment frame (an empty
<body>element) is created at the attachment site. This frame inherits the position, orientation, and other spatial attributes of the site. - All bodies in the child model's
<worldbody>become children of this attachment frame. - All non-worldbody elements (actuators, sensors, defaults, assets, etc.) from the child model are merged into the corresponding sections of the parent model.
- The child model's name scope becomes a child of the parent's name scope. All identifiers in the child model are automatically prefixed with the child model's scope name followed by
/. This prevents name collisions even when multiple instances of the same model are attached.
There is also an alternative composition mode called include_copy, which copies all elements from one model into another without creating a separate name scope. This is analogous to the MJCF <include> directive and is used when true merging (rather than scoped attachment) is desired.
The attachment is reversible: a detach() operation removes the child model and its attachment frame, restoring the parent to its pre-attachment state.
Usage
Model attachment is used whenever a simulation environment is assembled from multiple components:
- Attaching a robot model to an arena model at a specific site.
- Attaching a tool or object to a robot's end-effector site.
- Attaching multiple copies of the same object model (each automatically receives a unique scope prefix).
- Detaching and re-attaching models to reconfigure the environment dynamically.
Theoretical Basis
FUNCTION attach(parent_site, child_model):
ASSERT child_model is a RootElement
ASSERT child_model is not already attached
ASSERT no attribute conflicts between parent and child
# Ensure unique scope name
IF parent.namescope.has('namescope', child_model.name):
child_model.name = child_model.name + '_' + next_id
child_model.namescope.parent = parent.namescope
# Create attachment frame at the site
frame = new AttachmentFrame(parent=site.parent, site=site)
frame.attachments[child.namescope] = child.worldbody
# Merge non-worldbody elements (actuators, sensors, etc.)
parent.root.attach_children(child_model, exclude_worldbody=True)
RETURN frame # can be used to add joints for degrees of freedom
FUNCTION detach(child_model):
parent_model.remove_attachment(child_model.namescope)
child_model.namescope.parent = None
The key invariant is namespace isolation: after attachment, every identifier from the child model is prefixed by child_scope_name/, guaranteeing uniqueness in the flattened XML that is ultimately compiled by MuJoCo. This prefix is computed dynamically by traversing the name scope hierarchy, so renaming a scope transparently updates all generated identifiers.