演出前一晚机器人集体拖拍，宇树团队通宵重写代码保住王力宏演唱会

{"title_zh":"演出前一晚机器人集体拖拍：一场人形机器人群舞如何靠通宵重写代码完成","body_zh":"# 演出前一晚机器人集体拖拍：一场人形机器人群舞如何靠通宵重写代码完成\n\n2025 年 12 月，王力宏成都演唱会准备了一段特殊的伴舞：6 台宇树 G1 人形机器人登台演出《火力全开》。这被介绍为全球首次机器人群体舞蹈演出。几个月的准备，几千个逐帧采集的动作，原本已经把彩排推进到了“看起来万无一失”的阶段。\n\n但真正的系统问题往往不会出现在单机演示里，而会在多个设备、真实舞台和连续运行条件同时出现时暴露。演出前一晚，机器人出现集体拖拍。宇树团队连夜重写代码，最终保住了正式演出。这个故事的技术价值，不只是“机器人跳舞成功”，而是展示了一个典型的实时控制系统如何面对最后时刻的系统性故障。\n\n## 从动作捕捉到舞台执行，难点不在“录进去”\n\n准备过程中，编舞老师绑上动作捕捉器，把舞蹈动作逐帧输入机器人关节。这个流程解决的是“机器人应该做什么”：人体动作被转换成关节角度、时序和姿态轨迹。\n\n然而，动作数据并不等于可直接执行的控制指令。机器人还要面对一系列运行时问题：\n\n- 不同机器人关节的零点、减速器间隙和响应速度可能存在差异。\n- 音乐节拍、控制周期和动作采样频率必须保持一致。\n- 动作需要经过速度、加速度和关节限位检查。\n- 多台机器人必须共享同一个时间基准，否则每台设备都可能“单独跳得对，合起来却不齐”。\n- 真实舞台的网络延迟、温度、地面摩擦和电量变化，会让彩排结果与正式演出不同。\n\n因此，群舞系统通常需要把动作轨迹、时间同步、状态监测和故障处理分开设计。动作捕捉负责生成计划，实时控制层负责在约束范围内执行计划，监控层则要及时发现“正在逐渐落后”这样的软故障。\n\n## “拖拍”是一个时间系统问题\n\n如果机器人完全停止，故障很容易被识别；集体拖拍更麻烦，因为机器人仍然在运动，只是动作相对于音乐越来越晚。\n\n可以把每一拍看成一个时间点。假设音乐从时间 t_music 开始，机器人当前动作进度对应的时间是 t_robot，两者之差就是同步误差：\n\ntext\n同步误差 = t_robot - t_music\n\n误差接近 0：机器人与音乐同步\n误差持续为负：机器人逐渐落后\n误差持续为正：机器人逐渐抢拍\n\n\n单台机器人偶尔出现几十毫秒的抖动，观众可能不容易察觉；6 台机器人同时以相似方式落后，就会形成明显的群体性拖拍。问题可能来自控制循环负载、动作队列阻塞、时间戳使用不一致，也可能来自某个在单机彩排中没有暴露的同步假设。\n\n这里最关键的工程判断是：不要只检查“动作有没有执行”，还要检查“动作是否在正确的时间执行”。对于演出类系统，时间本身就是数据，必须进入日志、指标和告警。\n\n## 一个可以落地的同步监控骨架\n\n下面是一个简化的 Python 示例。它不是宇树 G1 的控制代码，而是一个可以改造成机器人群体、灯光设备或多媒体播放系统监控模块的最小实现。示例假设每台设备周期性上报当前执行时间，控制端根据音乐时间计算偏差。\n\n运行前可以直接保存为 sync_monitor.py，使用 Python 3 执行：\n\npython\nfrom dataclasses import dataclass\nfrom time import monotonic\n\n@dataclass\nclass RobotState:\n name: str\n robot_time: float\n last_seen: float\n\n\ndef check_sync(states: list[RobotState], music_time: float,\n warn_ms: float = 40, critical_ms: float = 100) -> None:\n now = monotonic()\n for state in states:\n if now - state.last_seen > 0.5:\n print(f"{state.name}: OFFLINE heartbeat")\n continue\n\n error_ms = (state.robot_time - music_time) * 1000\n level = "OK"\n if abs(error_ms) >= critical_ms:\n level = "CRITICAL"\n elif abs(error_ms) >= warn_ms:\n level = "WARN"\n\n print(f"{state.name}: {level} offset={error_ms:+.1f}ms")\n\n\nif __name__ == "__main__":\n now = monotonic()\n robots = [\n RobotState("G1-01", 12.000, now),\n RobotState("G1-02", 11.950, now),\n RobotState("G1-03", 11.880, now),\n ]\n check_sync(robots, music_time=12.000)\n\n\n示例中的阈值只是工程起点。正式系统应根据动作速度、舞台效果和观众可感知程度，通过压力测试确定阈值。监控还应该记录动作编号、音乐时间戳、机器人本地时钟、网络延迟、控制循环耗时和电量等信息。否则，团队只能在演出结束后凭视频猜测问题。\n\n## 为什么连夜重写代码能解决问题\n\n“通宵重写代码”听起来像一次冒险，但它是否合理，取决于重写的边界。若团队直接替换整套运动控制系统，风险会非常高；若是针对已经定位的时间同步或调度缺陷，修改时间基准、动作队列或节拍跟随逻辑，就可能快速恢复系统行为。\n\n一种常见的修复思路是让所有机器人都以同一个外部演出时钟为准，而不是各自从本地启动时间推算动作进度。控制端可以为每个动作定义统一的演出时间戳：\n\nyaml\nshow:\n clock: external_monotonic\n start_at: 0.0\n beat_ms: 500\n sync:\n warn_offset_ms: 40\n abort_offset_ms: 120\n heartbeat_timeout_ms: 500\nrobots:\n - id: G1-01\n motion: fire_all_opening\n - id: G1-02\n motion: fire_all_opening\n - id: G1-03\n motion: fire_all_opening\n\n\n修复后的系统还需要具备三种能力。第一是可观测：能回答哪台机器人从哪一拍开始落后。第二是可回放：能用同一段音乐和动作数据重现故障。第三是可降级：单台设备异常时，其他设备是否能继续完成表演，或者是否应该统一进入安全姿态。\n\n## 这件事对机器人产品化有什么启发\n\n这场演出把实验室里容易被忽略的要求全部放到了聚光灯下。机器人不只要会走、会跳，还要在确定的时间内，以可重复的方式完成动作。\n\n对于类似项目，可以在上线前准备一份小型验收清单：\n\n- 使用与正式演出相同的音乐、网络拓扑和设备数量进行全链路测试。\n- 连续运行完整演出时长，并额外留出热量、电量和负载裕量。\n- 注入网络延迟、丢包、单机离线和控制循环超时，验证降级策略。\n- 把同步偏差作为实时指标，而不是只在视频复盘中观察。\n- 为动作、音乐、时钟和版本建立唯一的发布编号。\n- 给现场团队准备经过验证的回滚版本，而不是只保留最新代码。\n\n这段经历最值得记住的地方，是“几个月的准备”和“一个晚上的修复”并不矛盾。前者解决动作设计、数据采集和系统集成，后者解决真实运行中暴露的时间与调度问题。高风险现场系统的可靠性，往往来自这两种工程能力的叠加：平时把边界测清楚，出问题时把故障缩小到可以验证的范围。\n\n对人形机器人来说，登台并不是完成动作就结束，而是要在多机协同、严格节拍和不可暂停的现场环境中稳定完成动作。能在演出前识别问题、定位问题并快速修复，才是从展示原型走向真实应用的重要一步。","title_en":"When Six Humanoid Robots Fell Behind the Beat: The Engineering Behind a Last-Minute Concert Fix","body_en":"# When Six Humanoid Robots Fell Behind the Beat: The Engineering Behind a Last-Minute Concert Fix\n\nIn December 2025, Wang Leehom’s Chengdu concert included an unusual group of backup dancers: six Unitree G1 humanoid robots performing to “FIRE.” The performance was described as the first group humanoid-robot dance show of its kind. Months of preparation went into it. A choreographer wore motion-capture equipment, and thousands of movements were transferred frame by frame into the robots’ joints.\n\nRehearsals looked perfect. Then, on the night before the show, the robots began falling behind the beat as a group. The Unitree team worked through the night and rewrote the relevant code in time for the concert.\n\nThe important engineering lesson is not simply that robots can dance. It is that a real-time multi-robot system can behave correctly in rehearsal and still fail when timing, hardware, networking, and continuous execution meet the conditions of a live stage.\n\n## Motion capture is only the beginning\n\nMotion capture answers one question: what should the robot do? The captured human movement must still become executable joint trajectories with valid timing, velocity, acceleration, and joint-limit constraints.\n\nA multi-robot performance adds more variables: actuator differences, clock drift, control-loop load, network latency, floor friction, temperature, and battery state. Each robot may execute its own trajectory correctly while the group gradually loses synchronization.\n\nThat is why a production choreography system should separate at least four concerns:\n\n- Motion planning: the trajectory and pose sequence.\n- Timing: the relationship between the choreography and the music clock.\n- Execution: the controller that converts the plan into safe actuator commands.\n- Observability: the metrics and logs that show whether the robot is on time.\n\nA rehearsal that checks only whether every movement completed is incomplete. The system must also check whether each movement completed at the intended timestamp.\n\n## Falling behind is a timing failure\n\nA stopped robot is easy to diagnose. A robot that continues moving but becomes late is harder. Let t_music represent the current position of the music and t_robot represent the robot’s corresponding execution time. The synchronization error is: t_robot - t_music.\n\nAn occasional small deviation may be invisible. Six robots drifting in the same direction creates an obvious group-level failure. The cause could be a blocked motion queue, inconsistent timestamp handling, a slow control loop, or an assumption that worked for one robot but not for six.\n\nTime therefore needs to be treated as first-class operational data. It belongs in logs, dashboards, alerts, and replay tools.\n\n## A minimal synchronization monitor\n\nThe following Python example is not Unitree G1 control software. It is a small monitoring skeleton that can be adapted for robots, lighting systems, or synchronized media devices. Save it as sync_monitor.py and run it with Python 3. It assumes that each device periodically reports its current execution time.\n\npython\nfrom dataclasses import dataclass\nfrom time import monotonic\n\n@dataclass\nclass RobotState:\n name: str\n robot_time: float\n last_seen: float\n\n\ndef check_sync(states: list[RobotState], music_time: float,\n warn_ms: float = 40, critical_ms: float = 100) -> None:\n now = monotonic()\n for state in states:\n if now - state.last_seen > 0.5:\n print(f"{state.name}: OFFLINE heartbeat")\n continue\n\n error_ms = (state.robot_time - music_time) * 1000\n level = "OK"\n if abs(error_ms) >= critical_ms:\n level = "CRITICAL"\n elif abs(error_ms) >= warn_ms:\n level = "WARN"\n\n print(f"{state.name}: {level} offset={error_ms:+.1f}ms")\n\n\nif __name__ == "__main__":\n now = monotonic()\n robots = [\n RobotState("G1-01", 12.000, now),\n RobotState("G1-02", 11.950, now),\n RobotState("G1-03", 11.880, now),\n ]\n check_sync(robots, music_time=12.000)\n\n\nThe thresholds are only starting points. A real system should establish them through load tests based on movement speed, stage effects, and what an audience can perceive. Logs should include the motion ID, music timestamp, local robot clock, network delay, control-loop duration, and battery level. Without that data, the team is forced to diagnose the failure from video after the event.\n\n## Why an overnight rewrite can work\n\n“Rewrite the code overnight” is not automatically reckless. The risk depends on what was changed. Replacing the entire motion-control stack before a show would be dangerous. Fixing a diagnosed defect in the time base, motion queue, or beat-following logic can be a controlled emergency response.\n\nA robust design gives every robot a shared external show clock instead of deriving progress from independent local start times. Each motion can carry an explicit timestamp in the performance timeline:\n\nyaml\nshow:\n clock: external_monotonic\n start_at: 0.0\n beat_ms: 500\n sync:\n warn_offset_ms: 40\n abort_offset_ms: 120\n heartbeat_timeout_ms: 500\nrobots:\n - id: G1-01\n motion: fire_all_opening\n - id: G1-02\n motion: fire_all_opening\n - id: G1-03\n motion: fire_all_opening\n\n\nThe repaired system also needs three practical properties. It must be observable enough to identify the robot and beat where drift began. It must be replayable with the same music and motion data. And it must degrade safely: if one robot fails, the remaining robots need a defined response, whether that means continuing, reshaping the formation, or moving to a safe pose.\n\n## A checklist for live robot performances\n\nThe concert exposed the requirements that are easy to miss in a laboratory demo. A humanoid robot must not only walk or dance; it must do so repeatably within a strict time budget.\n\nBefore deploying a similar system, teams should: \n\n- Test the complete chain with the production music, network topology, and robot count.\n- Run the full show continuously with thermal, battery, and compute headroom.\n- Inject latency, packet loss, device disconnects, and control-loop overruns.\n- Track synchronization error as a live metric instead of relying only on video review.\n- Version the motion data, music, clock configuration, and software together.\n- Keep a tested rollback build available for the stage crew.\n\nMonths of preparation and one night of emergency debugging are not contradictory. The preparation handles choreography, data capture, and integration. The emergency work handles a timing or scheduling defect revealed by real execution. Reliable live systems need both: measure the boundaries before the event, then reduce any failure to a small behavior that can be tested and verified.\n\nFor humanoid robots, stepping onto a stage is not merely a demonstration that a motion can be executed. It is a test of multi-robot coordination, timing discipline, observability, and recovery under conditions where the system cannot simply be paused and restarted. That ability to find, isolate, and fix a problem before the curtain rises is a meaningful step from prototype behavior toward real-world deployment.","seo_description_en":"How six humanoid robots fell behind the beat before a concert, and what shared clocks, monitoring, replay, and safe fallback teach us about reliable robot shows."}