Unitree Go1 Repair Guide: Gait, Power and Version Evidence

Robotics repair branch

A Unitree Go1 symptom should be tied to the exact robot, hardware version, current software state, event timeline and intended task before anyone changes settings or orders parts. Uneven gait, a connection drop or a shutdown can cross mechanical, power, sensing and control layers. This guide preserves the customer's concern as evidence, avoids a blind update or parts guess, and builds a transparent route from safe observation to workshop scope and acceptance.

Quick answer

Confirm the Go1 hardware version and reproduce one bounded symptom before changing software

Photograph the label, full robot, joints, feet, battery, charger, controller and supplied kit. Record hardware version, current supported software information, last normal task, surface, load and event. Do not blind-update a Go1 when the hardware/software relationship is uncertain; preserve the current state and use Unitree support information for the exact configuration. Stop for swelling, impact, binding, odor, abnormal heat or uncontrolled movement. Reboot Hub then separates gait, power, perception and connection evidence in writing.

What evidence should be captured before the customer acts?

How should common Unitree Go1 symptoms be separated?

How do you distinguish the exact Go1 from a similar Unitree quadruped?

Photograph the full robot, front sensor face, side panels, carry area, joint housings, legs, feet, product label, battery interface, controller, charger and supplied accessories. Record the model exactly as shown on the unit. Do not rely on a marketplace title or old invoice to distinguish Go1 from Go1 Pro or another configuration. If several robots share a workshop, assign a simple evidence label before videos and status files are collected.

The identity record should include hardware version and current supported software information when available. Unitree's own update materials distinguish hardware conditions, so compatibility cannot be assumed from the family name alone. Keep the exact robot, its battery and its controller together in the intake file. That continuity prevents a comparison from becoming an accidental swap and gives the customer a repair scope tied to the unit they actually supplied.

Why must hardware version be recorded before any update?

A software package is not automatically appropriate for every hardware version that looks like the same Go1. Preserve the current version information, working functions and first symptom before any change. Record where an update package came from and which prerequisites apply to the exact unit. If identity or compatibility is uncertain, stop and confirm through supported Unitree channels rather than trying several packages until one appears to run.

Do not blind-update a robot to investigate gait, power or connection behavior. An unsupported or poorly documented change can add a second problem, erase the baseline and make the customer's original concern harder to reproduce. A workshop should explain in writing why an update is relevant, what evidence supports it, what will remain unchanged and how the result will be accepted. Software change is a scoped action, not a generic reset button.

What should a Go1 arrival record contain?

Capture the robot from all sides while powered off, then document joint housings, lower legs, feet, sensor face, body panels, ports, fasteners, battery, charger, controller and transport packaging. Preserve original photographs or video from the first event. Record falls, collisions, moisture, storage, shipping, previous repair, cable changes, battery substitutions and software changes in chronological order.

Ask the customer to describe the symptom in their own words and show the task that matters. A laboratory owner may need repeatable low-speed walking on a known surface, while a training customer may care about remote control and camera behavior. The evidence record should name the required route, environment, runtime and deadline. A diagnosis without that outcome can produce a robot that powers on but does not solve the customer's problem.

How do you capture Go1 gait evidence that a technician can use?

After safety screening, use a clear level lane and record front, side and rear views at a modest speed. Keep the mode, surface, load, battery state and temperature stable. Note where in the step cycle the concern appears, whether it follows one leg and whether it repeats at the same point. Do not push the robot into a longer or faster run merely to make a subtle symptom more dramatic.

Gait is an output shared by structure, joints, calibration, sensing, control, power and the surface. A late foot or short step is not proof of a single failed motor. Compare evidence one variable at a time and write down what changes. If a joint binds, heats, shifts visibly or produces uncontrolled movement, stop the powered sequence and move to professional inspection rather than continuing for more footage.

What can joint sound and exterior inspection tell you?

Record the exact joint, direction, mode, load and temperature state when a sound appears. Photograph housing gaps, fasteners, impact marks, leg structure and foot pads under broad light. A sound during startup may follow a different branch from one that appears only under walking load. Do not force motion through resistance, pry a housing or compare by hand against another robot beyond safe external observation.

Exterior evidence can show contact, looseness clues or a changed gap, but it cannot reveal every internal condition. A clean panel does not rule out deeper risk, and a scuff does not identify a damaged actuator. The written record should distinguish observed evidence, reasonable next checks and unknown internal findings. That language protects the customer from paying for a confident guess disguised as diagnosis.

How should startup, charging and shutdown symptoms be separated?

Record whether the robot reaches any supported indicator state, whether the controller or app can see it, and exactly when power drops. Note battery identity, storage history, charger, connection seating, ambient condition and whether the symptom occurs at idle or under movement. Never keep charging or cycling a swollen, damaged, leaking, odorous or unusually hot battery in order to reproduce a shutdown.

A displayed charge value does not prove that a pack can support the task. Conversely, a movement shutdown does not automatically prove that the battery is the only cause. A trained workshop may use documented comparisons, but every substituted battery or charger must be recorded. Acceptance should return to the original task and supplied kit so a successful comparison does not hide uncertainty about what the customer will take home.

When is a sensor concern actually an environment concern?

Preserve lighting, surface texture, reflections, obstacles, dust, moisture and the robot's mode when perception changes. Repeat only a modest safe observation under one controlled condition. If behavior changes with the environment, record that relationship without claiming the sensor is healthy or defective. A surface or lighting sensitivity can still matter to the customer's task even when a workshop cannot reproduce it on a clean bench.

Keep sensor evidence separate from network and gait conclusions. A camera image, avoidance response or orientation cue can be affected by several layers. Do not cover sensors, point intense light at them or create hazards as an owner-side test. The goal is to document the operating boundary and provide a professional diagnostic question, not to force a pass or fail through an artificial stress condition.

How do app, network and controller symptoms fit the repair path?

Break the report into stages: device discovery, connection, status visibility, command receipt, robot response and connection stability over the required distance. Record the phone or controller, network context, obstacles and any recent change. A connection drop can prevent access to useful evidence while the robot remains mechanically intact, or it can appear alongside a separate power or movement concern. Keep those branches distinct.

Do not treat a successful reconnection as complete acceptance. Confirm that commands are received predictably and that the robot remains stable in a controlled area. If movement is unsafe, stop before investigating range. A transparent quote can include connection diagnosis and locomotion diagnosis as separate scope items, with known and unknown boundaries for each.

What changes after a fall, moisture event or transport impact?

Preserve the event location, fall direction, surface, packaging and first observed condition. Photograph panels, joints, legs, feet, sensor face and battery area before repeated movement. Moisture, salt, odor, abnormal heat, battery damage, binding or uncontrolled motion are stop conditions. A dry-looking exterior after transport does not prove that internal connectors, structure or calibration stayed unchanged.

Do not make a robot stand to prove it survived shipping. The safer sequence is physical evidence, power-risk screening, supported status where appropriate, then staged movement only after the boundary is clear. Tell the customer which observations came from the as-received state and which came after an approved comparison. That distinction is essential if damage responsibility, carrier evidence or warranty scope may be considered.

What does a transparent Go1 repair quote include?

The quote should identify the exact Go1, hardware version, supplied kit, customer's concern, event timeline, reproduced result, known and unknown findings and proposed diagnostic boundary. It should name parts provenance, timing, acceptance tests and what would trigger a revised scope. A list of possible motors, boards or sensors without evidence is not a transparent quote.

Reboot Hub keeps the evidence visible from intake through handover. If an update, battery, controller or known-good unit is used for comparison, that action is recorded. The customer should understand what has been shown, what remains uncertain and why the proposed work fits the required task. Written boundaries let the customer approve or decline without relying on workshop shorthand.

When is a documented replacement stronger than Go1 repair?

Repair is stronger when the symptom can be reproduced safely, the hardware and software baseline is understood, parts provenance is defensible and the robot can pass a representative acceptance route. Replacement is stronger when impact or battery risk cannot be bounded, multiple layers are affected, version history is uncertain, critical parts are unavailable or downtime exceeds the customer's operational need.

A replacement comparison should identify the exact model, configuration, supplied kit, visible condition, warranty boundary and remaining unknowns. It should not imply that every Go1 is interchangeable. The customer's surface, control method, runtime and workflow still define fit. A transparent alternative helps the customer compare evidence and downtime rather than being pushed toward whichever option is easier to sell.

How should controlled acceptance and handover be completed?

Acceptance progresses from safe startup and status visibility to stationary response, low-speed gait, connection stability and the representative task. Record the hardware version, software state, battery, surface, mode, load, duration and observer positions. Stop if instability, heat, sound, warning or uncontrolled movement returns. A single successful lap cannot replace repeatability and the customer's required outcome.

The handover should include the original concern, written findings, approved work, parts provenance, before-and-after evidence, residual risks and care boundaries. Reboot Hub's normal workshop target is 1-3 business days after quote approval when diagnosis, parts and acceptance allow. Approved work carries a 30-day repair warranty; eligible pre-owned complete products follow a separate 180-day product warranty. The record keeps those terms distinct.

Related Reboot Hub paths

Move from evidence to a documented next step

Continue the learning path, submit the exact-unit concern or compare a documented replacement.