{"submission_id":"5feb2535-ecc6-4b94-870d-0e9607a86815","submission_revision_id":"21dd91ff-da2a-4cb7-9f97-d86f9d940bf6","revision_version":2,"submission_status":"under_review","submitted_at":"2026-08-03T04:30:46.211834Z","submitter_name":"Jiageng Mao","submitter_email":"maojiageng@gmail.com","task":{"status":"submitted","version":2,"extra_fields":{"difficulty_self_test":{"model":"Sonnet 5","harness":"Claude Code","estimated_score":"20–40%"}},"submitted_at":"2026-08-03T04:30:46.211834+00:00","industry_domain":"Robotics & Autonomous Systems (Engineering)","task_short_name":"robot_dexterous_grasping","operating_system":"Linux","task_description":"**Objective:** Produce robot trajectories that make a Unitree G1 humanoid grasp\nand lift **three different objects** — one trajectory per object — using only its\nupper body. Hand back the recorded trajectories as `.npz` files.\n\n**Starting State:** A fully self-contained MuJoCo simulation is provided per\nobject: `assets/obj_<id>/scene.mjb` (the G1 already standing at the table in front\nof that object, meshes embedded), a frozen initial physics state\n(`init_state.npy`), the balance policy's internal state (`amo_init_state.npz`),\nand robot parameters (`robot_params.json`: joint order, the 31\n`upper_body_joint_names` the agent controls, PD gains, torque limits,\n`target_body`, `init_object_z`, `stand_command`). A bundled RL balance policy\n(`policy/`) holds the robot standing.\n\n**Instructions & Rules:** The robot's **lower body does not move** — the agent\ndoes **not** control the legs or the base and the robot never walks; the bundled\nbalance policy holds it standing with a fixed in-place command. The agent\ncontrols **only the 31 upper-body joints**: waist (3), left arm (7), right arm\n(7), left Dex3 hand (7), right Dex3 hand (7); the right hand is the grasping\nhand. For each target object, build your own control loop over that object's\nscene and synthesize an upper-body motion that reaches to the object, closes the\nDex3 fingers on it, and lifts it ≥ 8 cm. Record each run as\n`output/trajectory_<object_id>.npz` containing the array `upper_body` of shape\n[T, 31] (schema in `TRAJECTORY_SCHEMA.md`). Do not write anything outside\n`output/`.","software_licensing":"Free/Open Source","evaluation_criteria":null,"verification_method":"Verification is **functional, objective and deterministic** (a replay, not a\nsubjective comparison). The grader (`reference/grader/run_grader.py` plus\noperator-side `scripts/score_outputs.py`) is run as:\n\n```\npython3 run_grader.py --output <submission dir> \\\n    --assets input/assets --policy input/policy --results result.json\n```\n\nStrict rules (no room for guessing):\n1. `output/` must contain `trajectory_<object_id>.npz` for **every** object id in\n   `assets/objects.json`; each must hold the array `upper_body`, 2-D with exactly\n   31 columns, `T >= 1`, all finite. Any violation → 0.\n2. For each object the grader restores that object's frozen MuJoCo integration\n   state and balance-policy state, then replays the submitted upper-body\n   trajectory under the exact contract in `TRAJECTORY_SCHEMA.md` (lower body held\n   by the balance policy with a fixed stand command).\n3. An object is **solved** iff, at the end of its replay: `hand_obj_dist <= 0.15 m`\n   (object within 0.15 m of the Dex3 right-hand fingertip centre — actually\n   grasped) **AND** `lift >= 0.08 m` above its starting height **AND**\n   `pelvis_z > 0.60 m` (robot upright).\n4. **Score is binary and all-or-nothing: 1.0 iff every object is solved, else\n   0.0.** (The report also lists `objects_succeeded / objects_total` and a\n   per-object breakdown.)\nMuJoCo and the policy are deterministic, so scores reproduce bit-for-bit on the\nsame GPU (verified over repeated runs). Verified reference results: thermos(103)\nlift 0.129 m / hand-obj 0.030 m, vitamin_box(105) lift 0.181 m / 0.033 m,\nclock(106) lift 0.116 m / 0.037 m -> all three solved, score 1.0. Negative\ncontrols: submitting only 2 of 3 objects -> 0.0 (all-or-nothing); zero-motion\ntrajectories -> 0.0 (0/3 solved).","software_and_version":"MuJoCo 3.3.6, PyTorch 2.7.0 (CUDA 12.x), NumPy, transforms3d, Python 3.10","specific_requirements":null,"expected_completion_time":null},"files":[{"file_id":"8274f8a1-1310-4ab9-8a63-e1a1ec756baf","filename":"robot_dexterous_grasping_ref.tgz","category":"reference_output","content_type":"application/x-compressed","size_bytes":46236},{"file_id":"4d0bbb20-0bd2-4fe3-aae1-b371c4d9c370","filename":"robot_dexterous_grasping_data.tgz","category":"input_materials","content_type":"application/x-compressed","size_bytes":283439801}],"deep_review":{"overall_verdict":"Accept","review_text":"**Overall Verdict:** Accept — the submission is complete and end-to-end reachable, with only non-blocking documentation inconsistencies concerning exact reproducibility and the starting-height field name.\n\n**Completeness Check:**\n- Instruction: Complete — the objective, three-object scope, upper-body-only controls, output schema, replay behavior, and terminal success conditions are explicit; attached documentation consistently uses `init_target_z`, although the submission summary calls it `init_object_z`.\n- Inputs: Complete — all three object bundles include distinct MuJoCo scenes, finite frozen physics and policy states, consistent 43-joint parameter sets, and exactly 31 ordered upper-body joints.\n- Toolchain: Complete — Linux, package versions, CUDA GPU requirements, setup commands, policy dependencies, and the single-machine workflow are specified.\n- Reference output: Complete — reference trajectories exist for all three objects and contain finite `float32` `upper_body` arrays of shapes `(421, 31)`, `(469, 31)`, and `(412, 31)`, accompanied by the replay grader.\n- Rubric: Complete — schema gates, per-object distance/lift/upright thresholds, all-or-nothing scoring, partial-result reporting, and negative controls are objective and precise.\n\n**File and Task Reachability:**\nThe attachment set is `partially_reachable`, solely because the review environment did not provide the exact MuJoCo/CUDA runtime needed to semantically load the binary scenes or execute the policy. The end-to-end task is `reachable` on one suitable Linux machine with a CUDA GPU and the declared dependencies.\n\nBoth manifest archives were inspected: `robot_dexterous_grasping_ref.tgz` and `robot_dexterous_grasping_data.tgz`. Their actual sizes match the manifest, both are valid unencrypted gzip-compressed tar archives, and neither contains traversal paths, absolute paths, links, device entries, or unexpected member types. Static inspection covered `run_grader.py`; all three reference trajectory files; `task_brief.md`, `SETUP.md`, `TRAJECTORY_SCHEMA.md`, and `SUCCESS.md`; `objects.json`; every `robot_params.json`, `init_state.npy`, and `amo_init_state.npz`; all three `scene.mjb` files; `amo_policy.py`; and the three policy-weight containers. NumPy schemas, dimensions, finiteness, JSON consistency, binary signatures, required model names, TorchScript container structure, and pickle globals were checked. No relevant manifest content was omitted from static inspection. Submitted programs and models were not executed; therefore, the reported reference scores and full scene parseability were not independently reproduced. This is a reviewer-tooling and safety limitation, not evidence of a submission defect.\n\nThe completion path is coherent: install the declared packages, load each scene and its frozen states, restore the bundled balance policy, synthesize and record the 31 upper-body targets, save one trajectory per object, and replay them through the supplied grader to obtain the threshold-based all-or-nothing result. Solver-visible inputs and protected reference trajectories are separated into different archives, with no evident answer trajectory in the input bundle. License keys, accounts, tokens, and other credentials are not required from the contributor. Confidential, proprietary, or internal material may be evaluated as submitted evidence without requiring additional disclosure.\n\n**Special Screening:**\nNone — no affirmative evidence supports `ai_synthetic`, `public_benchmark`, or `synthetic_defect_fixture`. Public-benchmark status could not be independently searched in the offline review environment.\n\n**Recommended Changes:**\nThe self-contained assets, frozen-state contract, reference trajectories, and evaluator are strong. No material changes are required. As optional documentation cleanup, use the actual `init_target_z` field name everywhere and reconcile the claim of bit-identical CUDA replay with the attached schema’s warning that policy inference may vary by approximately `1e-7`; the latter should be the authoritative guidance unless deterministic execution has been explicitly enforced.","reviewed_at":"2026-08-11T07:41:26.077591Z"},"claim":null}