RynnBrain 1.1: The 3D-Grounded Robot Manipulation Acceptance Test for Operators

A robot can identify the right object and still botch the job. The mug is visible. The model points to it. Then the gripper approaches from the wrong coordinate frame, catches the curved wall instead of the handle region, clips the item next to it, and turns a perception win into a manipulation failure. That gap, between seeing and acting safely, is where a RynnBrain 1.1 acceptance test should live.

Alibaba DAMO Academy presents RynnBrain 1.1 as a family of open embodied foundation models at 2B, 9B, and 122B-A10B scales. The project page and paper describe native 3D grounding for compact models, contact-point prediction with in-plane grasp orientation, and RynnBrain-VLA with a unified cross-embodiment action space plus embodiment-specific masking. The same materials also report real-robot evaluations on Unitree G1, Astribot-S1, and Tianji-Wuji systems. Treat those benchmark and real-robot results as author-reported claims until your team reproduces them.

For operators, the release is interesting. That is not the hard question. The hard question is whether it passes on your artifacts, robots, scenes, safety process, latency budget, and recovery path. If your team is comparing related open robotics stacks, pair this article with Optijara's edge robotics infrastructure planning, open model retrieval acceptance testing, and production serving evaluation.

Why RynnBrain 1.1 Needs an Acceptance Test

RynnBrain 1.1 is not a model card to skim over coffee. Its claims sit at the boundary between perception, spatial reasoning, robot control, and physical contact. The official page states that RynnBrain 1.1 introduces contact-point prediction for task-relevant interaction locations and in-plane grasp orientations, while the 2B and 9B models receive explicit 3D supervision for language-conditioned grounding in metric physical space. The arXiv paper should be treated as the primary technical reference, with GitHub, Hugging Face, and ModelScope used to confirm executable artifacts.

Here is the blunt version: a benchmark table is not a control boundary. It tells you where to start testing. It does not tell you what to automate.

Keep the claims separated. Benchmark tables, scaling comparisons, and real-robot superiority statements are author-reported until your team reproduces them under pinned code, pinned checkpoints, documented hardware, and your target scene distribution. That does not make the claims weak. It makes them testable. Robotics adoption goes wrong when teams confuse a paper result with a production decision.

The Optijara 3D Manipulation Acceptance Test is built for that problem. It separates 2D perception from metric 3D grounding, metric grounding from usable contact, contact from robot-specific execution, and execution from safe deployment. The rule is simple: if a release cannot pass a constrained version of the real workflow, it should stay in evaluation.

What to Verify First: Artifacts, Licenses, and Model Fit

Before any robot trial, build an adoption record. Capture the official project URL, arXiv paper, GitHub repository, Hugging Face collection, ModelScope collection, checkpoint names, model cards, license text, dependency versions, sample inference commands, and any safety or limitation statements. The GitHub repository advertises an Apache-2.0 license in the live repository snapshot checked during fact-checking, but operators should still confirm whether each model artifact, dataset dependency, and downstream integration has matching redistribution and commercial-use terms.

Do not download a checkpoint and call the artifact verified. Save commit identifiers, release timestamps where available, hash files if published, your own downloaded file hashes, environment lockfiles, GPU driver versions, inference scripts, and evaluation command lines. Six months later, that evidence trail is what tells you whether a benchmark drifted because of the model, the hardware, the preprocessing, or your setup.

2B vs 9B vs 122B-A10B decision matrix

For robot platforms, evaluate the platform before evaluating the model. Unitree G1, Astribot-S1, and Tianji-Wuji are named in the RynnBrain paper and project materials. They represent different embodiment assumptions: humanoid mobility and manipulation, bimanual manipulation, and dexterous-hand control. Document the sensor suite, end-effector geometry, grasp taxonomy, control API, calibration procedure, workspace limits, collision model, safety stop mechanism, and available demonstration data for each platform.

The Optijara 3D Manipulation Acceptance Test

The framework has seven gates. Artifact integrity comes first, followed by offline reproduction, metric 3D grounding, contact viability, embodiment mapping, safety envelope review, and limited supervised deployment. A model passes only when each gate has evidence. Impressions do not count.

Stage 1: 2D localization versus metric 3D grounding

2D pointing asks whether the model can indicate a target in image space. Manipulation asks whether the robot can reach the right place in the real world. Your test should compare bounding boxes or points against metric 3D targets, depth consistency, object orientation, reachable surfaces, and transforms between camera, world, robot base, and tool frames.

Start with a fixed scene set. Include known objects, novel objects, cluttered surfaces, occluded targets, and transparent or reflective objects if they appear in the workflow. Add state changes too: open or closed, upright or tilted, empty or filled. A valid 3D response should repeat after recalibration and hold up under moderate lighting or viewpoint changes.

Stage 2: Contact-point and grasp-orientation scoring

Contact-point prediction is useful only if it survives physics. Score whether the predicted point sits inside a task-valid contact region, whether the approach vector clears nearby objects, whether the gripper orientation matches the object geometry, and whether the proposed contact avoids slip, torque, or collision risks that your sensors can observe.

Stage 3: Calibration and coordinate-frame consistency

Many manipulation failures are not model failures. They are frame bugs, timestamp drift, depth scale errors, stale extrinsics, or tool transforms that no longer match the hardware. Audit camera extrinsics, robot base frame, end-effector transform, depth scale, timestamp alignment, hand-eye calibration, and recalibration repeatability. Require the model output to be logged with the frame it refers to. A point without a frame is not an action plan.

Stage 4: Clutter, occlusion, and object-state shifts

Clean-table demos are necessary, but they do not prove much by themselves. Add distractors, partial occlusions, container state changes, deformable packaging, reflective surfaces, and object movement between perception and execution. The acceptance test should record whether failures come from perception, grounding, contact prediction, planning, control, or recovery.

Cross-Embodiment VLA Evaluation: From Task Plan to Safe Action

A cross-embodiment VLA has to be tested as a chain. Instruction understanding leads to subtask planning. Planning leads to scene grounding. Grounding leads to action proposals. Action proposals are translated into robot-specific commands. The robot executes, observes the result, and either continues or recovers. A weak link anywhere in that chain can invalidate the deployment.

Long-horizon tasks should vary object location, distractors, lighting, intermediate states, and instruction phrasing. The decomposition should remain stable when the scene changes, but it cannot be rigid. If a cup falls over, the system should not blindly continue the original grasp.

Cross-embodiment mapping is the hardest part to fake. Abstract actions such as pick, pour, push, wipe, place, or hand over must map to each robot platform's reachable workspace, gripper or hand geometry, joint limits, tool frames, collision model, and force or speed envelope. Embodiment-specific masks should block unreachable poses, unsafe orientations, forbidden zones, excessive force, and tool-incompatible actions.

Observability is mandatory. Log prompt, images, depth inputs, predicted contact point, target coordinate frame, action trace, mask decisions, confidence or uncertainty if exposed, recovery branch, operator override, and final outcome label. Without that trace, you cannot distinguish a model weakness from a calibration issue or controller bug.

Benchmark Reproduction and Measurement Plan

RynnBrain materials reference embodied cognition, spatial reasoning, localization, 3D grounding, and real-robot evaluation. The required reproduction set should include the official RynnBrain evaluation scripts where available and relevant benchmark documentation such as VSI-Bench, MMSI-Bench, RefSpatial-Bench, and the RynnBrain-Bench dataset page. Treat each benchmark as a measurement instrument, not a deployment proxy. A model can do well on spatial understanding and still fail your gripper, object set, latency budget, or safety envelope.

Reproduction should pin code, checkpoint, dataset version, hardware, driver stack, random seeds where applicable, image preprocessing, prompt templates, and evaluation scripts. If the paper reports a benchmark result, reproduce it before using it in an adoption memo. If reproduction fails, record the blocker: missing artifacts, environment mismatch, undocumented preprocessing, hardware difference, or implementation error.

Simulate first, then use constrained physical trials. Real-robot tests should run at low speed, inside a bounded workspace, with emergency stop access, supervised operation, and defined abort conditions. NIST smart manufacturing robotics resources are useful for evaluation thinking, but do not treat a research acceptance test as safety certification.

Implementation Checklist and Comparison Table

{
  "model": "RynnBrain 1.1",
  "acceptance_gates": ["artifact_integrity", "benchmark_reproduction", "metric_3d_grounding", "contact_viability", "embodiment_mapping", "safety_envelope", "supervised_trial"],
  "required_metrics": ["valid_3d_target_rate", "contact_point_validity", "grasp_orientation_validity", "intervention_rate", "recovery_success", "latency_distribution", "calibration_drift_sensitivity"],
  "deployment_blockers": ["unverified_license", "unreproduced_benchmark", "missing_frame_trace", "unsafe_action_mask_gap", "uncontained_failure"],
  "first_trial_scope": "single robot, bounded workspace, known objects plus controlled clutter, supervised low-speed execution"
}

Common Mistakes, Caveats, and Where Not to Deploy

Teams get this wrong in predictable ways. They treat 2D pointing as proof of 3D manipulation readiness. They skip calibration audits because a demo worked once. They trust paper benchmarks without reproduction. They ignore embodiment differences. They test only clean scenes. They omit failure recovery. They measure task success but miss contact quality, near misses, interventions, and frame errors.

Operational caveats matter. Evaluation takes engineering time. Model behavior can vary across size, serving path, sensor quality, prompt format, and robot controller. Camera feeds may contain sensitive information. Simulation can hide friction, compliance, latency, and object-state changes. Calibration drifts. Hardware wears. Networked inference can add jitter. Some model artifacts may expose less uncertainty or trace detail than operators want.

Do not deploy an open embodied model into unsupervised safety-critical manipulation, unbounded public spaces, high-force interactions, tasks requiring certified safety behavior, unstable tooling, or workflows where failures cannot be contained. Avoid deployments that capture sensitive visual data without governance, or where operators cannot inspect and override actions.

The practical path is narrow and valuable: verify the release, reproduce what you can, run a contained 3D manipulation acceptance test, and define rejection criteria before rollout. For teams evaluating open embodied AI, Optijara can help translate releases like RynnBrain 1.1 into test plans, prototype gates, benchmark reproduction, and safer automation roadmaps without overstating readiness.