assets

assets — robot & target geometry registry

Purpose

Declares the physical assets the sim instantiates: robot model paths, body inertia,
torque/velocity limits, the engineered joint-limit envelope, and the inspection-target
meshes (mesh path + bounding radius). Loaded alongside parameters at construction time;
the loader attaches the named robot/target blocks onto the run config.

Structure

The file has two top-level sections:

• robots: — one block per robot variant. UR3 (6-DOF, the live workhorse) and UR3_7 (7-DOF S-R-S variant). Each block: model path, I_body, frame names, torque/velocity limits, mass, n_DOF, and a joint_limits envelope.
• targets: — one block per inspection satellite. GRO (Gamma Ray, the mission target), RCM (RadarSat), acrim (AcrimSat). Each block: display name, mesh path, bounding radius.

Key knobs/sections

key path	what it controls	default/example	note
robots.<v>.relative_path	MuJoCo XML model, repo-relative	models/ur3/ur3_box_limited_with_capsules.xml	loader resolves → absolute robot_path
robots.<v>.I_body	3×3 body-frame inertia tensor	shared UR3/UR3_7	NOT re-derived for 7-DOF (roll link negligible)
robots.<v>.base_frame / cam_frame	free-flyer base + camera link names	box_base / camera_link	frame lookups into the model
robots.<v>.joint_torque_limits	per-joint τ bound, base→tip	[56,56,28,12,12,12] Nm	→ constraints.tau_max
robots.<v>.joint_velocity_limits	per-joint θ̇ bound, base→tip	[3.142,…,6.284] rad/s	→ constraints.theta_dot_max
robots.<v>.mass	total robot mass	15.68 kg	feeds com.v_dot_max = F_max / mass
robots.<v>.n_DOF	arm DOF count	6 / 7	sizes joint-limit/torque vectors
robots.<v>.joint_limits.lower/upper	engineered clip envelope	UR3 elbow [−2.891,−0.250]	data-derived (CHAIN_5), NOT datasheet
targets.<t>.path	satellite mesh file	GRO_offset.stl	resolved under models/ by loader
targets.<t>.radius	mesh bounding radius	3.87 m	sets orbit.radius = radius + clearance

Who reads it

• parameter_loader (ParameterLoader) owns this file. load_domain("assets") parses it into a RecursiveNamespace; load_robot(variant) resolves relative_path → absolute robot_path, builds constraints.{theta_dot_max, tau_max} from the limit arrays, and load_target(satellite) returns the target block. finalize_parameters() attaches the named (simulation.robot / simulation.target) blocks onto params.robot / params.target — utils/parameter_loader.py:107, :100, :122.
• Downstream the resolved blocks feed the camera/orbit geometry derivation (camera_targeting_parameters, :195): target.radius → orbit.radius, target.path → targeting.mesh_path, robot.mass → CoM accel cap.
• robot (GiordanoRobot) consumes the resolved robot_path + I_body to build the Pinocchio model; the joint-limit envelope flows into the breve_controller derate/clip stack.

Footguns

The joint-limit envelope is engineered, not hardware

The UR3 lower/upper vectors are data-derived via c3c_envelope_derivation.py, NOT the
UR3 datasheet. The elbow bounds [−2.891, −0.250] are the load-bearing adoption: they break the
INITIAL-aiming lock-in that froze the arm at q3 = −π (3.6× slowdown). shoulder_pan (joint 0) is
EXEMPT — ±1e6 — because it winds continuously across the helix orbit; clamping it would break
the trajectory. (YAMLs_by_domain/INSIGHTS.md Assets, CHAIN_5; adopted Jun 10 commit 64c3905.)

UR3_7 limits are a PLACEHOLDER (review R8)

The 7-DOF envelope is just the 6-DOF data-derived envelope with a ±2π roll spliced in at arm
index 2. The 7-joint re-derivation has not been done; the elbow rides this fence ~30% of
mission steps. Do not treat UR3_7 limits as validated hardware bounds. (YAMLs_by_domain/INSIGHTS.md.)

XML box_limited ranges ≠ these limits, and nominal operation exceeds them

The model XML’s own box_limited joint ranges are task artifacts that nominal operation exceeds
constantly (wrist_1 75% out-of-range). The clip that matters is constraints.arm.joint_limits in
parameters, which resolves to these arrays (or the robot block) — not the XML tails. The clip
is a simple velocity-kill at the wall. (YAMLs_by_domain/INSIGHTS.md parameters.yaml.)

Post-load overrides of asset-derived quantities go SILENTLY STALE

finalize_parameters() bakes derived quantities (orbit.radius from target.radius,
com.v_dot_max from robot.mass, camera geometry) at load time, before any
pre_run_loader override runs. Overriding a raw asset input afterward leaves the derived value
stale — use the rederive_* escapes. (utils/INSIGHTS.md parameter_loader, the snapshot trap.)

Shared inertia, base→tip ordering

I_body is shared between UR3 and UR3_7 (the extra roll link adds negligible inertia). The torque
and velocity arrays are ordered base→tip (joint 0 = pan); UR3_7 classes the inserted roll with
the shoulders (56 Nm / 3.142 rad s⁻¹), not the elbow. (YAMLs_by_domain/INSIGHTS.md Assets.)

Related

parameters · parameter_loader · pre_run_loader · robot · breve_controller · current_sota · terminology