MiniCPM-Robot Opens the Weights. Only One Branch Closes the Loop
MiniCPM-RobotManip produces a 30-step by 80-dimensional action tensor. MiniCPM-RobotTrack produces eight future [x, y, yaw] waypoints and comes with a documented path that can turn those waypoints into rate-limited commands for one specific robot.
That difference is the useful way to read OpenBMB's July 19 release.
The headline package is attractive: Apache-2.0 code and weights, a 1.5B generalist manipulation VLA, and a compact target-tracking policy designed to run locally on a Unitree Go2 EDU. The obvious summary is that open embodied AI has become smaller and more deployable.
The files tell a more instructive story. RobotTrack publishes much of a sensor-to-waypoint-to-motion stack, but only inside a tightly pinned Go2 EDU and Jetson Orin NX configuration. RobotManip publishes a capable-looking checkpoint and inference wrapper, then stops at an abstract action interface whose embodiment map, dimensions, normalization, and actuator conversion are not documented.
That asymmetry does not make MiniCPM-Robot a weak release. It makes it an unusually revealing one. A robot model is useful only when the contract from observation to safe motion is inspectable. OpenBMB has opened a large part of that contract for tracking and exposed precisely what is still missing for manipulation.
RohitAI previously covered Reachy Mini as an open hardware and app-distribution bet. MiniCPM-Robot approaches the other half of the problem: perception, policy, runtime, and control. Put the two together and the bottleneck becomes obvious. Open weights invite experimentation; open interfaces make the experiment transferable to a real machine.
Both checkpoints are public, ungated, and tagged Apache-2.0 on Hugging Face. The RobotManip snapshot contains 1,536,237,296 parameters and occupies about 3.60 GB in repository storage. The RobotTrack snapshot contains 449,787,035 parameters and occupies about 0.97 GB, while OpenBMB's README gives Track a 0.9B model-size label. OpenBMB does not publish an accounting bridge between those figures. Track separately loads DINOv3 and SigLIP vision encoders, which plausibly explains part of the difference but does not turn that inference into an official breakdown.
As of the July 20 snapshot, the project had no tagged GitHub Release. The sensible reproducibility unit is therefore the inspected Git commit—630eefd256ff2bf74ff84d5038da467a738ec437—plus the exact Hugging Face revisions, not simply main and a model name.
| Release layer | RobotManip | RobotTrack | Builder consequence |
|---|---|---|---|
| Weights and inference | Public 1.536B checkpoint and a single-sample inference helper | Public 449.8M policy checkpoint plus separate vision encoders | Both can be inspected; neither checkpoint alone describes the full robot system |
| Input and output contract | RGB views, language, optional 80-D state, embodiment ID; returns (30, 80) | Language-conditioned RGB history; returns eight [x, y, yaw] waypoints | Track exposes a meaningful navigation interface; Manip leaves the motor mapping to the integrator |
| Training and evaluation path | No public training recipe or benchmark adapters at research time | Fine-tuning and evaluation code, sample data, and validation manifests; full rollouts and assets remain external | Track supports a serious reproduction attempt; Manip supports model inference, not benchmark reproduction |
| Validated physical deployment | No public actuator adapter or real-device guide | Go2 EDU, Orin NX 16GB, pinned Jetson stack, dry-run and live-control gates | Track is runnable inside a narrow rectangle; Manip is an integration research project |
| Primary missing contract | Embodiment map, action semantics, normalization, limits, timing, and controller | Independent physical trials, tail latency, full training corpus, and broader hardware validation | The two branches should be evaluated and budgeted separately |
“Family” is a packaging decision. It is not evidence that every branch has crossed the same release threshold.
AI launch coverage usually starts at the model and moves outward. Robotics deserves the reverse audit. Start at the actuator, then ask whether every upstream layer has a published interface, a version, a failure policy, and an owner.
The checkpoint is one link in the control loop. Solid teal marks a documented path; coral marks an interface builders still have to define.
This diagram explains why a small policy can still be a large systems project. A camera frame has to be acquired and timestamped. Vision features have to be generated under a latency budget. The policy has to preserve enough history to identify the right target. Its output must be converted into a robot-specific command. A separate safety layer must reject stale, missing-target, excessive-speed, or out-of-bounds motion. Only then should the actuator move.
RobotTrack publishes a route through most of those layers. RobotManip currently publishes the policy-side half.
The Go2 deployment guide targets a Unitree Go2 EDU with the expansion dock and EDU SDK, a Jetson Orin NX 16GB with NVMe, and a pinned software stack: JetPack 6.2.2, Jetson Linux R36.5, CUDA 12.6, TensorRT 10.7, Python 3.10, ROS 2 Humble, and MAXN mode 0.
OpenBMB explicitly puts Go2 Air and Pro, Orin Nano, Orin NX 8GB, and other RealSense models outside the supported scope. The default source is the Go2 front camera. A D435i appears in the bill of materials, but the runtime uses only its RGB stream and requires that path to be validated separately.
The data path is concrete: DINOv3 and SigLIP TensorRT engines encode the image stream; the MiniCPM4-derived policy uses language and visual history to predict eight waypoints; a rate-limited control layer converts those waypoints to motion. OpenBMB reports stable 5+ FPS and about 180 ms end-to-end latency on the Go2's onboard compute. That is an issuer result, not an independent latency trace. The release does not show p95 or p99 latency, thermal soak behavior, battery impact, physical route counts, or intervention rates.
Track's memory design is particularly interesting. The published model contract allocates four visual tokens to each of 31 historical frames and 64 tokens to the current frame. Each current frame therefore gets 16 times the spatial-token budget of an older one. That recency bias is efficient, but it creates a testable failure hypothesis: identity evidence visible only before a long occlusion or crowded crossing may be compressed away. A good evaluation should target that case rather than simply praising “long history.”
The coarse-history, fine-current pattern itself is evolutionary. The original TrackVLA paper also used a 32-frame window, but its physical setup sent images to a remote RTX 4090 and paired the policy with LiDAR and a separate obstacle-avoidance layer. MiniCPM's meaningful systems change is fitting an open policy and vision stack onto the Go2's local Orin NX, not inventing temporal target tracking from scratch.
RobotManip's public inference helper accepts one or more 448 × 448 RGB images, a language instruction, an optional 80-dimensional state, and an embodiment ID from 0 through 31. It returns a 30-step by 80-dimensional action chunk.
That is a clean software interface and an incomplete robot interface.
The public release does not say which ID maps to which embodiment. It does not define the meaning, units, masks, coordinate frames, or normalization statistics for all 80 state and action dimensions. It does not publish joint limits, action rate, inverse mapping, or an actuator-level adapter. Sending the tensor to hardware without those details would be guesswork.
The action-head code helps explain the design. A 16-layer diffusion transformer uses category-specific input and output projection banks for different embodiments. That is a sensible route to one checkpoint across heterogeneous robots, but it changes the meaning of “generalist.” The model contains a multiplexed bank of embodiment contracts. It does not abolish the contracts.
This is the first non-obvious lesson from the release: one set of weights is not the same as hardware-agnostic control. In robotics, an embodiment manifest is closer to an ABI than optional documentation. Without it, the checkpoint can be loaded but not safely linked to a machine.
A contributor confirmed in GitHub issue #3 that the released Manip checkpoint is the final general-purpose set of weights and said evaluation code would be open-sourced soon. No date was given. Until those adapters arrive, the published benchmark table is a vendor result rather than a reproducible release artifact.
OpenBMB reports competitive results. The right response is neither dismissal nor automatic acceptance. Keep inspectable artifacts, project-reported measurements, and promised work in separate columns.
For Manip, the complete reported set is 97.5 on LIBERO, 4.1 on CALVIN ABC-to-D, 91.3 and 91.6 on RoboTwin2 easy and hard, and 53.3 on RMBench. The RMBench paper's own Table 1 covers nine memory-dependent dual-arm tasks and reports 42.0 for its memory-specific Mem-0 policy, alongside 10.4 for Pi0.5. OpenBMB repeats the Pi0.5 result but does not include Mem-0 in its comparison table. If the protocols match, MiniCPM's relevant displayed margin is 11.3 points over Mem-0—not 42.9 over Pi0.5. That would still be meaningful; without the official adapter, the match cannot yet be verified.
The streaming claim deserves even more care. OpenBMB says recomputing 60 frames costs 125 TFLOPs per decision, while streaming needs 3.3 TFLOPs and can preserve up to one minute of visual context. Yet the visible model wrapper defaults use_cache to false, and the public quickstart does not expose a persistent streaming session. That does not disprove the result. It means the most strategically interesting Manip feature is also the least productized public path.
Track's EVT-Bench table is mixed in a different way. The benchmark authors define single-target, distracted, and ambiguity tracking, with success, tracking, and collision reported separately. MiniCPM leads the shown open-weight comparison on several cells, including all three single-target metrics and distracted success and tracking. OmTrackVLA shows lower collision rates in the distracted and ambiguity settings, plus a slightly higher ambiguity success rate. Simulation tracking performance is useful evidence; it is not physical obstacle-avoidance certification.
OpenBMB's code and released weights are Apache-2.0. That is a meaningful permission layer. It is not a blanket license for everything needed to reproduce the complete Track system.
The project's third-party notices separate the OpenBMB artifacts from gated DINOv3 weights under Meta's license, simulator code, HM3D and MP3D scenes, humanoid and robot assets, NVIDIA software, Unitree SDK components, and other dependencies. The upstream TrackVLA repository also declares CC BY-NC-SA 4.0, creating a provenance question around evaluation code and assets that a commercial adopter should review rather than guess at. This is a license-matrix task, not a conclusion that OpenBMB's own code is noncommercial.
The same layered thinking applies to security. Local inference can keep camera data off a hosted API and remove cloud availability from the control loop. It also makes patching, model-code review, credential hygiene, device-specific TensorRT builds, network segmentation, and fleet drift the operator's job.
Both checkpoints use custom Hugging Face model code. Track's local status UI listens on port 5801 without authentication, and the deployment guide explicitly warns against exposing it to the public internet. The guide also warns that the policy may predict forward motion when no person is visible. The released client does include a 1.5-second stale-plan brake, which zeroes commands when a plan expires or the dispatch loop exits. That is useful fail-safe behavior, not a substitute for independent target-presence and obstacle checks.
RohitAI's earlier advice to audit the path, not the open-source badge applies even more strongly when the final side effect is physical motion.
MiniCPM-Robot is not one adoption decision. The useful choice depends on the machine, the task, and how much missing integration work a team can absorb.
Use the documented Go2 EDU, Orin NX 16GB, camera, power mode, and software versions in a bounded site. Start in dry-run, keep a safety operator present, and measure target loss, collision, intervention, latency, and thermal behavior yourself.
Proceed only if the team can obtain or define the embodiment schema, build a controller adapter, collect corrected trajectories, reproduce task-specific evaluation, and tolerate changes while OpenBMB fills the public gaps.
Benchmark MiniCPM beside SmolVLA, OpenVLA or Wall-OSS, and GR00T using the same robot, data, controller, runtime, safety shell, and outcome metric. A family-wide leaderboard will not answer the deployment question.
The comparison set matters. SmolVLA was already a 450M open VLA with public recipes and consumer-hardware positioning. OpenVLA established a 7B generalist policy trained on 970,000 Open-X trajectories. Wall-OSS targets more than 20 embodiments, while NVIDIA GR00T N1.7 wraps a 3B checkpoint in a broader humanoid training and deployment platform.
MiniCPM's differentiation is therefore not “the first open VLA.” RobotManip combines a relatively small policy with a strong memory thesis. RobotTrack publishes a unusually concrete offline path for a specific quadruped. That narrow deployment pack is the part competitors should study.
The deployment guide gets one principle right: live control should be an earned state. It defaults to dry-run, requires multiple live-control flags and an explicit MOVE confirmation, caps default velocity at 0.15 m/s and yaw at 0.30 rad/s, and calls for an operator with an emergency stop.
Builders should extend that discipline into a reproducible acceptance suite.
The second non-obvious lesson is that embodied-AI benchmarking is becoming systems benchmarking.
A PhyAI Day-0 adapter report claims RobotManip throughput on H20 rose from 10.12 Hz in the native path to 36.77 Hz with CUDA Graph and Triton, while the same optimized path reached 47.85 Hz on RTX 5090 and 62.35 Hz on H100. Those results use three 448 × 448 views and steady-state measurement after warmup. At the research cutoff, support remained in an open, unmerged pull request, and the numbers were not independently replicated.
Even with those caveats, the shape of the result is important. Runtime optimization reportedly created a 3.6× gain on the same H20—larger than the difference between the optimized H20 and H100 measurements. Model revision, runtime commit, input views, precision, warmup, preprocessing scope, power mode, thermals, and tail latency belong on the benchmark card beside the model name.
The third lesson is a market prediction. Open robotics will likely split into two complementary products:
broad foundation policy
+
robot-specific deployment pack
=
versioned closed-loop system
GR00T, OpenVLA, Wall-OSS, and similar efforts compete on broad policy capability, data, and adaptation. MiniCPM-RobotTrack shows the value of the second product: a last-mile pack that names the sensor, feature encoders, edge runtime, hardware, waypoint contract, control limits, and operating procedure.
Parameter count will become less useful as a deployment label. Track's 449.8M downloadable policy sits behind a 0.9B headline for which OpenBMB does not publish a full accounting bridge. Neither figure says anything about TensorRT engines, camera transport, command handling, Jetson power mode, or the safety shell. The honest unit is closer to:
model revision + vision towers + runtime commit
+ sensor contract + hardware and power mode
+ controller + safety policy + evaluation protocol
This echoes RohitAI's broader argument that compute location changes the control plane. On a robot, it also changes who owns every failure between camera capture and motor command.
RobotManip needs an embodiment manifest before it needs another demo reel: the 32 ID mappings, all 80-D field semantics, masks, normalization statistics, units, coordinate frames, action rate, joint limits, and reference controller adapters. The promised benchmark code should include frozen preprocessing, task configurations, result logs, and the persistent streaming path behind the 125-to-3.3-TFLOP claim.
RobotTrack needs evidence beyond a single aggregate latency and simulation table: versioned releases, physical trial counts, route and lighting coverage, intervention logs, target-loss taxonomy, p95 and p99 latency, thermals, battery impact, and a documented safety architecture separate from the learned policy. Publishing the full provenance map for EVT-related code and assets would also make commercial review easier.
Those requests are demanding because the release is close enough to runnable that the missing details matter. That is progress. The industry should judge robot releases by whether outsiders can reconstruct the closed loop, not by how convincing the launch video looks.
OpenBMB publishes its code and released weights under Apache-2.0. The complete Track deployment also depends on separately licensed vision models, simulator components, datasets, assets, NVIDIA software, Unitree hardware, and SDK pieces. Treat “open” as a layer-by-layer property and run a license review for commercial use.
Not from the documented support path. OpenBMB validates Go2 EDU with the expansion dock and EDU SDK, Orin NX 16GB, and a pinned Jetson stack. The guide explicitly excludes Go2 Air and Pro, Orin Nano, Orin NX 8GB, and other RealSense configurations from its support scope.
It is ready for checkpoint inference. A physical integration still needs the missing embodiment map, action and state semantics, normalization, limits, timing, actuator conversion, and independent safety layer. Teams that already possess the relevant internal contract may be able to proceed; the public release does not yet supply it.
No. OpenBMB reports strong results, especially Manip's 53.3 on RMBench and several Track metrics, but its own comparison tables contain cells led by other models. The results were project-reported at the research cutoff, and Manip's official evaluation adapters were still promised rather than public.
There is no announced hosted API tariff, but deployment still costs hardware, sensors, power, integration, asset access, validation, and maintenance. Local execution can improve data control and remove a cloud dependency. It does not automatically secure custom model code, credentials, network ports, device images, or motion commands.
MiniCPM-Robot deserves attention because it moves open embodied AI closer to inspectable deployment. It also shows why weights are only the beginning.
RobotTrack turns a narrow hardware target into a documented advantage. RobotManip packages promising policy and memory work behind an interface that still needs its robot-side contract. The family is strongest when read honestly as both an achievement and a to-do list.
Open weights make a robot model inspectable. Open contracts make it buildable.