Sharpa's DQ robot needs a deployment memory

Sharpa's DQ robot follows DQ's original Blizzard process, from taking cups and dispensing ingredients to adding toppings and mixing. According to geekpark, it also opens a cabinet made for human hands to retrieve cup rings, then lifts topping lids and uses a small spoon. That is a task sequence, not a deployment record. As woshipm illustrates, across 61 actions, a 99% success rate at every step yields a theoretical one-attempt completion probability of about 54%; at 98%, it falls to about 29%.

The real test is what the robot retains after a miss: a fix that helps it recover and makes the next task require less intervention. This article examines the operating loop that turns demonstrations into reusable deployment knowledge.

A continuous task is not a deployment result

Sharpa's DQ Blizzard robot follows DQ's original process: it takes cups, dispenses ingredients, adds toppings, and mixes. It also opens a cabinet made for human hands to retrieve cup rings, then opens topping lids and uses a small spoon. That is a meaningful manipulation sequence, not a simple pick-and-place display. Yet 55 continuous steps for one Blizzard show why an uninterrupted run is only the start of deployment evidence.

A chain succeeds only when its individual actions keep succeeding.

woshipm illustrates the compounding problem with a 61-action mobile-manipulation run. At a 99% success rate for each step, the theoretical chance of finishing the entire sequence in one attempt is about 54%. At 98% per step, it falls to about 29%. A polished continuous task can therefore conceal many recovery moments across ordinary operation. The relevant question is not merely whether the robot completed the Blizzard sequence, but how often a person must reset the machine. They may also need to intervene or take over when cups and lids vary, as topping and cabinet interactions do.

geekpark reports that the DQ project is in trial operation at only one store, handles limited product categories, makes ice cream more slowly than a human worker, and has a first-generation whole-machine cost far above human labor. It is planned to operate steadily for 12 hours per day and serve customers directly. Those conditions turn reliability into an operating requirement. As woshipm's author argues, evaluation should emphasize P95 cycle time, variation across hundreds of consecutive tasks, and required human intervention. Li Yifan similarly argues that completing 90% of a real task can be commercially closer to zero than to 100% when a worker must cover what remains.

How three Chinese robotics approaches turn deployments into reusable capability

Measure the cost of the next task

A deployment scorecard should ask what the next task costs, not merely whether a robot can complete a polished task once. Record deployment time, the added demonstrations needed for an adaptation, and the rate at which people must step in. Then measure exception recovery: can the machine resume useful work after a fault, or does every disruption become an engineering ticket?

The tail of performance matters more than the highlight reel.

According to woshipm, evaluation should track P95 cycle time and variation across hundreds of consecutive tasks, alongside required human intervention. That makes slow or fragile runs visible instead of burying them beneath an average. Continuous operating time and task success rate also belong on the vendor sheet, as do data-iteration speed and deployment cost; a source attributes that view to Gao Haichuan.

Full operating cost must mean cost per effective task. woshipm says that calculation should include depreciation, consumable parts, hand replacement, recalibration, remote monitoring, on-site engineers, production stoppages, and material losses. Those costs reveal whether recovery is a product capability or a hidden service operation. They also expose why every extra demonstration matters: Gao says real-robot data carries high time and destructive costs, and that data supply is the main constraint rather than computing power or algorithms. A useful deployment should therefore leave the next task requiring less data, less engineering time, and less human intervention.

Treat failures as training data

A deployment memory begins with a trajectory, not a verdict that a task succeeded. According to woshipm, a useful record joins what the robot observed with its body state. It also records the control action it chose and the environmental result. Training records can retain images and joint states. They can also preserve control commands with task outcomes. That makes a stalled grasp or missed connector inspectable rather than anecdotal: engineers can trace what the machine saw, how it moved, and where the result diverged.

Human intervention belongs in that record too. woshipm describes operators using VR equipment to steer robotic arms through picking parts. They can also open drawers or return items.

Those remote takeovers are valuable when they preserve the context that prompted them. The corrective action can become a labeled recovery trajectory, while the surrounding robot state and outcome identify the condition it addressed. Beijing E-Town's planned examination system and robot error notebooks point to the same discipline: failures need structured capture, rather than disappearing into informal reports.

The loop only becomes engineering knowledge after collection. Qingyan Precision gathers operating-process data and environmental conditions in power-battery work. It also records object states, including connector plugging and unplugging, component grasping, and assembly. It then cleans the material. It organizes and post-processes it. Before production use, it repeatedly trains and evaluates the data, models, equipment, and task workflows.

This is harder to standardize across humanoid work. The woshipm author argues that real-world product use can continuously create data, as in Tesla's autonomous-driving practice, but varied workstations and homes prevent a direct copy. A deployment memory therefore needs explicit error records and recoveries that remain usable when the next setting differs.

Generalization can include targeted adaptation

Sharpa's DQ robot is valuable precisely because it works through a human-designed process rather than a simplified cell. According to geekpark, it takes cups, dispenses ingredients, adds toppings, and mixes Blizzards using DQ's original procedure. It also opens a cabinet made for human hands to retrieve cup rings, then opens topping lids and uses a small spoon. Those details expose the physical assumptions embedded in an ordinary workstation.

Preserving that workflow does not mean refusing adaptation. Li Yifan says Sharpa has pursued general-purpose hardware and software since its founding, and that the five-fingered Sharpa Wave was developed because available hands could not adequately operate human tools. The transferable asset is the ability to work with existing objects and interfaces. A deployment may still need a different gripper, fixture, sensor placement, or control policy where the site makes those choices necessary.

The boundary is useful: according to a report, Gao Haichuan argues that task planning and object-interaction understanding can carry across robot embodiments, while actuator-level control remains bound to the hardware form. Qingyan Precision describes a comparable approach to scenario transfer. Its Yulin mining pilot built an engineering loop spanning real-data collection, data governance, simulation training, pilot validation, and on-site deployment. Its power-battery work then applied that foundation to connector plugging and unplugging, component grasping, and assembly.

Replication therefore means reusing the operating machinery, then validating the local changes.

A report states that Qingyan Precision defines cross-scenario replication around established data tools, simulation platforms, pilot processes, and engineering experience, followed by scenario-specific adaptation. That is a more practical meaning of generalization for Sharpa's DQ deployment. The robot need not treat every workstation as identical. It needs a record of which parts of a prior deployment transfer, which physical differences demand intervention, and how those interventions become the starting point for the next site.

Choose deployments that turn exceptions into reusable capability

• A robot has a polished demonstration but has not yet operated through varied real-world conditions. Do not treat the demonstration as proof of deployability. Evaluate task success rate, continuous operating time, exception-recovery capability, deployment cost, and data-iteration speed. A long sequence magnifies small reliability gaps: for 61 steps, a 99% per-step success rate implies about a 54% chance of completing the sequence in one attempt, while 98% implies about 29%.
• You are choosing an initial commercial scenario for a new robot system. Start with a scenario that has established demand and can support repeated data collection, rather than beginning with a broad humanoid claim. Catering, cleaning, hotel service, battery production, and mining are examples of scenarios used for this purpose. The aim is a closed loop from real-world collection and data governance through simulation validation, model training, and real-machine application.
• The task fails in contact-rich final movements such as plugging, assembly, or handling flexible objects. Instrument the failure rather than only collecting camera video. The relevant records can include images, joint states, control commands, task outcomes, observed environment state, body state, actions, and what happened afterward. For these tasks, force, touch, and sound may determine success in the final few millimeters.
• You need to transfer a learned workflow to a different robot body or a related worksite. Reuse the higher-level parts first: task planning, understanding of object interaction, data tools, simulation platforms, pilot processes, and engineering experience. Then perform scenario-specific adaptation and validation, because actuator-level control is tied to hardware form and cannot be directly transferred across embodiments.
• A deployment appears technically workable but still requires a person to watch it or resolve edge cases. Judge it by the operational burden, not the best run. Track variation across hundreds of consecutive tasks, P95 cycle time, frequency of human intervention, and the full cost per effective task, including remote monitoring, on-site engineers, stoppages, material losses, consumable parts, hand replacement, and recalibration. A system that completes most of a task can still leave a human worker necessary for the remainder.

Buy the operating loop, not the robot demo

A procurement review should start with the records produced after a task goes wrong. Ask who owns failure logs, who can export them, and whether recovery attempts remain available for later training. Ask how human supervision is recorded and what happens when the robot stops. A task that reaches 90% completion may still leave a worker responsible for the remainder, as geekpark argues.

An operating loop is what is being bought.

The vendor should specify how a learned action interface moves to another robot body. According to the cited outlet, task planning and object-interaction understanding may transfer across embodiments, but actuator-level control is tied to hardware form. That boundary matters because robots differ in arm length, degrees of freedom, and camera placement, according to woshipm. They also differ in actuator arrangements and control frequency. Require an account of recalibration, expected downtime, and the engineering work needed when the body changes.

Data collection also needs scrutiny. woshipm reports that UMI uses a portable camera-equipped gripper to record visual data, hand trajectories, and gripper states, without continuously occupying the eventual robot body. That can make collection more flexible, but the buyer should ask who can access the recordings and how they become executable behavior on the deployed machine. Qingyan Precision says it maps operation data to a three-finger dexterous hand for continuous work including plugging and unplugging.

The final question is where adaptation stops being a repeatable service and becomes bespoke automation. The cited outlet says investors examine success rate, continuous operating time, exception recovery, deployment cost, and data iteration speed rather than a demonstration alone. The June 2026 validation criteria cited by woshipm similarly include efficiency. They also include safety and reliability, plus economic viability.

Those are the terms a purchase agreement should make observable.

For each robot deployment, define a task package that survives a handoff from autonomous execution to a human operator. Record user intent, the real-world object, completed steps, missing information, the next action, and a fallback path. Treat the intervention as stateful work, not a reset. The woshipm author's handoff model also calls for a clear trigger, a target destination, state synchronization, and failure recovery.

Track how often recovery preserves progress.

Use completion rate, context repetition rate, recovery rate, and interruption cost to judge the next deployment. A return to human control is not automatically a failure if the robot's task state remains available. Teams without a broad device ecosystem can start with a narrow industry task chain, moving from on-site perception to back-end completion, then measure whether later deployments need less repeated context and fewer recovery steps.

For readers outside China

• Availability: The source material describes deployments and initiatives in China, including a DQ trial at one store and real-world training activity in manufacturing, logistics, elderly care, and emergency rescue environments. It does not say which products are available outside China, whether they can be purchased internationally, or how overseas customers can obtain support.
• Pricing: Retail pricing, robot leasing terms, and deployment pricing are not disclosed in sources. The available cost signal is qualitative: Sharpa's first-generation whole-machine cost is described as far higher than human labor, while commercial evaluation is argued to require a full cost-per-effective-task calculation rather than a hardware price alone.
• Closest Western equivalents: Physical Intelligence's π0.5 is a useful reference point for data-driven mobile manipulation: it was trained with real mobile-robot data alongside data from other robots, web vision, and language data.; Figure's Helix 02 is a useful reference point for humanoid mobile manipulation, tactile sensing, and long action sequences.; UMI is best understood as a real-world robot-data-capture workflow: a person uses a portable camera-equipped gripper while visual data, hand trajectories, and gripper states are recorded for transfer to robots.
• Data residency: The sources discuss real-world data collection, publicly released data, digital-twin data, data cleaning, simulation, and model training, but do not disclose where data is stored, whether it leaves a deployment site or country, how customer data is segregated, retention periods, or cross-border transfer terms.

Sources

• woshipm 打破百米纪录的机器人，为什么进不了工厂？ https://woshipm.com/embodied/6459379.html
• woshipm 机器人没有互联网 https://woshipm.com/embodied/6460388.html
• 36kr 清华博士做具身大脑拿下九轮融资，他说机器人行业不存在所谓ChatGPT时刻｜硬氪专访 https://36kr.com/p/3973012275785986
• woshipm AI眼镜为什么总要掏出手机？用一张任务接力图拆跨设备体验 https://woshipm.com/pd/6439121.html
• geekpark 对话 Sharpa 李一帆：通用机器人要么全能，要么无能 https://geekpark.net/news/369851
• 36kr 从矿山到动力电池｜清研精准第二个具身智能垂类中试场景落地 https://36kr.com/p/3946264412339335