Skip to main content
Pitfall

Firmware 1.5.1: one update, four compounding failures

Symptom​

Six days after a fully successful open-house demo, the G1 received firmware update 1.5.1. What came back was not one failure but a cluster of them, all surfacing around the same time, with no initial way to tell which symptom belonged to which cause:

  • External WebRTC connections rejected outright at the handshake stage.
  • The internal speaker stopped producing audio.
  • Motor alarms appeared that had not been present before the update.
  • Custom (taught) gestures dispatched via api_id 7112 returned success codes with no physical motion.

Environment​

  • Unitree G1 EDU+, firmware 1.4.5 → 1.5.1
  • Custom WebRTC-based control stack, rt/arm_sdk gesture dispatch, onboard speaker and ASR

Why this gets its own entry​

Each individual failure above has (or eventually got) its own root-cause writeup — the WebRTC handshake break is covered in full in the 1.5.1/1.5.2 WebRTC entry, and the custom-gesture failure turned out to be an unrelated, pre-existing FSM gating issue that simply surfaced at the same time. What's worth documenting separately is the triage itself: four things breaking at once off the back of a single firmware update, with real pressure to treat them as one problem, when they were in fact at least three independent ones wearing the same trigger.

Triage sequence​

A — Refuse to assume a single cause. The instinct after a firmware update is to look for one root cause that explains everything. Here that instinct was wrong twice over: the custom-gesture failure was unrelated and pre-existing, and the speaker/motor-alarm symptoms and the WebRTC handshake break, while both genuinely caused by 1.5.1, were separate regressions inside the same release rather than one shared mechanism.

B — Isolate by dependency, not by timing. "Broke right after the update" was true of all four symptoms and therefore useless as a filter on its own. What separated them was checking which layer each symptom actually lived in: WebRTC failed at the handshake (network/auth layer, confirmed via the /con_notify data2=3 change), custom gestures failed at the FSM/dispatch layer (motion never reached the arm, independent of any transport), and the speaker and motor alarms pointed at firmware-level regressions in onboard subsystems, unrelated to the network path entirely.

C — Don't let the loudest failure absorb the others. The WebRTC break was the most visible and the most heavily community-documented, since it was independently reported by another G1 owner the same day (see the linked entry). That visibility created real risk of writing off the speaker and motor-alarm symptoms as "probably the same WebRTC thing" without separately confirming it — worth naming explicitly, since it's the kind of shortcut that costs real diagnostic time later if it turns out to be wrong.

D — Use blocked time on genuinely independent work. While the WebRTC side was blocked on a community fix (see the linked entry for the full arc), gesture-authoring tooling and the digital face system both moved forward, since neither depended on the robot being network-operational. That only works once you've confirmed the problems are actually independent — otherwise you risk building on top of a still-broken assumption.

Findings​

  • A single firmware update can plausibly cause several genuinely independent regressions at once; treating "everything broke together" as evidence of one shared cause is a reasonable first guess but needs to be checked, not assumed.
  • The failure that gets the most external attention (here, WebRTC, because it was independently reported upstream the same day) isn't necessarily the one worth prioritizing internally — the motor alarms and dead speaker were arguably higher-severity, being closer to the safety-relevant surface of the robot.
  • Firmware 1.5.2 subsequently resolved the WebRTC/onboard-ASR conflict specifically; it did not retroactively explain the custom-gesture issue, which needed its own independent fix regardless of transport.

Why this is worth documenting as its own entry​

The individual fixes are each written up where they belong. This entry exists for the part that doesn't fit inside any single fix: the discipline of pulling apart a multi-symptom regression by dependency layer before committing to a root cause, so that a loud, well-documented failure doesn't crowd out quieter ones that need their own diagnosis.

Time cost​

The WebRTC resolution alone took just over five weeks end to end (see the linked entry for that arc in full). Separating the four symptoms into independent tracks happened in the first session after the update — the cost here was mostly in resisting the urge to treat it as one problem, not in additional diagnostic time.