Use this 3-layer checklist before you sign off on a Unitree Go2, B2, G1, H1, or H2 deployment. Tick each line as you verify it — your progress saves locally and persists across reloads. No login, no cloud, no telemetry.
You receive a new Unitree shipment. Forty-five minutes from now you're supposed to run a 20-minute safety demo for the VP. You have ten minutes to decide whether this robot is ready to leave the crate.
So you skim. You confirm the legs are attached, you push the button and watch it stand up, you wave at the camera, you ship it to the demo. The demo goes fine. The robot makes it into a deployment loop. Three weeks later, it falls over in a meeting room with a 25% slope in the floor, the E-stop was on the wrong VLAN, and now the VP is asking "didn't anyone test this?"
The problem is: your team has never agreed on what a robot review is actually for. This is not a process problem; this is a clarity problem, and clarity begins by understanding what you're looking at.
When you unbox a robot, you're not looking at a single machine to test. You're looking at three layers stacked on top of one another. We'll give you a mental model to identify these layers, deal with them correctly, and take your robot acceptance testing to the next level.
This is firmware versions, battery telemetry, network handshake success, IMU stream rates. It's everything a computer can verify without understanding what your robot is about to do.
Here's the thing: every minute a robotics engineer spends verifying this layer by hand is a waste. If someone is running battery diagnostics with a multimeter when there's a `battery_state` DDS topic, that's not robotics — that's archaeology.
This is architecture. You review how the E-stop is wired, what happens on a controller crash, whether the fall-recovery routine is tested on the actual floor surface, whether the policy trained in Isaac Lab transfers to the real unit. You ask: "if we do it this way, what happens when the network drops mid-walk, or the battery hits 5% mid-grasp, or the operator forgets to put the robot in its crate at end of day?"
This is what should take up 80% of your acceptance time. This is hard. It requires understanding both the robot and the environment it lives in. It requires taste, experience, and the ability to imagine failures.
A junior engineer can run the Layer 1 battery test. Only senior engineers who've lived through a fall-recovery failure can catch the Layer 2 ones.
This is the why. Why this platform? Why this floor? Why this policy? What happens when the operator's kid walks into the work cell? What's the plan if the robot doesn't actually deliver on the use case? What's the rollback if the deployment turns out to be a bad fit?
Most of this doesn't live in the spec sheet — it lives in the runbook, the stakeholder meeting, and the post-deployment review. This is where you communicate your intent for the deployment, and this is where you get to make decisions that live forever, since this is where you set your standards.
A deployment with no narrative context is a deployment that someone else has to debug. The reviewer has to reconstruct the reasoning from scratch, asks questions that should have been answered upfront, and approves decisions they don't fully understand because they're exhausted from detective work.
Once you see these three layers, the rest of the checklist finally makes sense. Let's make it practical.
Click any line. Your progress saves in this browser.
Layer 1
What scripts and sensors should catch
These are the things a battery monitor, a DDS ping, a firmware-version probe, or a 30-second unit-test should surface — without a human in the loop. Every minute a robotics engineer spends verifying this layer by hand is a minute stolen from real engineering.
Layer 2
What determines long-term reliability
This is architecture. How the E-stop is wired, what happens on a controller crash, whether the fall-recovery routine is tested on the actual floor surface, whether the policy trained in Isaac Lab transfers to the real unit. This is what should take up 80% of your acceptance time.
Layer 3
What the deployment means for the operator
Most of this doesn't live in the robot's spec sheet — it lives in the runbook, the stakeholder meeting, and the post-deployment review. Without this layer, you've shipped a feature that nobody knows how to operate, scale, or defend in a safety audit.
These are real failures from public Unitree reports, the /r/robotics subreddit, and direct field reports we've collected. Each one would have been caught by a line in this checklist:
Layer 2 — Security
UniPwn 2025 — Bluetooth RCE on Unitree robots running firmware < 1.5.2 allowed an attacker within BT range to take control of the gait loop. Caught by: "Firmware ≥ 1.5.2" + "Bluetooth pairing requires a physical button press."
Layer 2 — Control loop
Go2 fall on raised-floor meeting room — fall-recovery routine trained on flat gym floor, never tested on a 25mm raised access floor. Caught by: "Self-righting routine tested on the deployment surface."
Layer 3 — Use case fit
G1 outdoor demo — humanoid taken to an outdoor parking-lot demo with no weather protection, slipped on wet asphalt on first walk. Caught by: "Indoor-only platforms (G1, R1) flagged in the runbook and access policy."
Layer 1 — Pre-flight telemetry
B2 5-volt rail brownout under payload — battery SOC reading looked fine (50%) but the 5V rail to the depth cameras dipped under transient load, causing intermittent SLAM failures. Caught by: "Battery telemetry parses all 4 fields (SOC, voltage, current, temperature), not just SOC."
Best practices aren't random rules — they're tactics for solving problems in one of the three layers. Every rule of thumb you've heard maps to a specific layer.
Run the checklist above. When you hit a line you can't verify on your own, that's the line we help with. We sell, program, and integrate Unitree robots — Go2, B2, G1, R1, H1, H2, and arms.