Zhejiang University is one of China's leading research universities, and its embodied intelligence work is correspondingly ambitious. In the deployment documented in our cases collection, a flagship industrial quadruped - the Jueying X30 class platform, equipped with an embodied navigation system - performs navigation and patrol duties in the university's real operating environment, serving simultaneously as a research instrument and as a working system. The university's laboratories use the platform class to study embodied navigation in genuine conditions: real routes, real weather, real pedestrians, real consequences for sloppy localisation.
The Case in Brief
Two features of the case deserve attention before any lesson-drawing. First, the robot's duties are operational, not ceremonial - the navigation work is the research data source. Second, the deployment sits inside a broader laboratory ecosystem of the kind our university laboratories solution describes: platforms, simulation and curriculum operating as one programme rather than as separate purchases.
Lesson One: Anchor the Lab in a Working Application
Laboratories built around demonstrations decay; laboratories built around duties renew themselves. A robot with a real job - a patrol to complete, a route to cover, readings to deliver - generates the three things research programmes chronically lack: continuous real-world data, a standing list of genuine problems, and a reason for the institution to maintain the equipment at working standard. The Zhejiang deployment's navigation duties are not a distraction from the research; they are its engine, because every operational failure is a research question with evidence attached.
The transferable decision is sequencing: choose the anchor application when the laboratory is founded, not after the robots arrive. The application disciplines everything - platform class, payload fit, the platform layer for scheduling and records - and gives the laboratory's first annual report something better than intentions to describe. Booster's laboratory builds are scoped this way by default: the duty roster is part of the design document.
Lesson Two: Let Research and Service Share the Machines
In the Zhejiang pattern, the same quadruped fleet serves the research programme and the working deployment, and the sharing is the point. Research gets operational data and real constraints; operations get a platform whose capabilities improve as the research progresses; students get the rarest educational asset - responsibility for a system whose work matters. The alternative pattern, common and wasteful, quarantines 'research robots' from 'service robots' and thereby denies both sides their best input: the researchers never meet production conditions, and the service fleet never improves.
Sharing requires governance rather than goodwill: scheduling that protects both duties, configuration discipline so experiments do not silently alter the working system, and the platform layer mediating between them. These are solvable, ordinary management problems - and solving them is precisely the institutional capability an embodied AI research lab exists to build. Our three-lab-types model gives the sharing a structure: the industry-specialised lab is where research and real duties formally meet.
Lesson Three: Build the Platform Layer Before the Fleet
The case's quiet infrastructure decision is its most copyable: the scheduling, navigation and data platform thinking came with the first robots, not after the fifth. Routes, records, fleet state and the traceability of observations were treated as laboratory infrastructure from the start, so growth since then has been accretion onto a system rather than archaeology through log files. Institutions that invert this - robots first, platform when the pain demands it - pay for the inversion in lost history: the early operational record, which is the baseline every improvement is measured against, simply does not exist.
Booster's platform products exist to make the right order easy: the simulation development platform for the training loop, the scheduling and operation platforms for fleets, bought with the first platform rather than as a later remediation. The Zhejiang case shows the compounding value of that order over a multi-year programme.
Reading Cases Well: A Closing Note
The correct way to read any vendor case, including this one, is as a set of decisions to interrogate rather than a result to admire. Ask what the anchor application is, how research and service share the fleet, when the platform layer was built, and what the institution would do differently. Booster publishes its cases in that spirit - the cases page gives the deployments, and records the decisions, including the imperfect ones, so institutions planning their own build can learn from them.
