宇树G1人形机器人开发实践：从基础运动控制到PPT汇报复盘

年底了，各种项目汇报堆在一起。我最近刚把一轮宇树G1开发实践的阶段性成果，整理成了一份基础版的PPT汇报稿。在整理和准备讲稿的过程中，踩了不少坑，也理清了不少思路。这篇博文就来聊聊：拿到宇树G1这类通用人形机器人之后，开发实践到底该怎么规划、技术链路怎么打通，以及最后怎么把这些实践内容浓缩成一份不丢分的基础版PPT汇报。

这篇文章不是教你从零手搓机器人操作系统，也不是完整的人形机器人算法教程。我更想分享的是：站在一个普通开发者的角度，如何给G1定一个合理的基础版目标，如何把环境、接口、调试这些琐碎事理顺，然后在汇报时把“做了什么”讲清楚。适合刚接触人形机器人开发的同学、准备做阶段性汇报的研究生，以及想给团队做技术分享的工程师参考。

1. 为什么先做基础版：开发实践的起点与边界

很多朋友拿到G1之后的第一反应，是直接冲进高级功能——今天想让它做后空翻，明天想让它抓取物体，后天又想接大语言模型对话。这种想法我非常理解，人形机器人本身的诱惑力就在这儿。但真到开发实践阶段，尤其是还要交一份PPT汇报的时候，最该想的反而不是“功能有多酷”，而是“基础版我要做到什么程度”。

1.1 从“能走”到“能交代”：基础版到底要验证什么

我给自己定的基础版目标是：跑通G1的基础运动控制闭环，让它能在平整场地上稳定行走、完成一组可复现的动作序列，并且能实时上报关节状态数据。这个目标听起来很朴素，但真正动手之后你会发现，它已经足够支撑一次有分量的汇报。

为什么选这个目标？因为“能走”这件事，在宣传片里是一瞬间，在开发实践里却是一整套链路。从上位机发出控制指令，到控制器解析目标位姿，再到各关节电机响应，最后还要通过IMU、编码器反馈实际状态——任何一个环节对不上，机器人都走不好。把这个闭环跑通，你就已经触及了人形机器人开发最核心的部分。

更重要的是，基础版的目标必须能被验证、能被演示、能被量化。我当时给自己定了一条验收标准：让G1在无外部辅助的情况下，沿着一条约5米的直线路径往返走3次，期间不发生明显倾斜或失稳，并把整个过程的关节角度变化记录下来。这个标准不需要多高的技术门槛，但汇报时放出来，大家一眼就能看懂你做成了什么。

1.2 范围裁剪的三个判断标准

人形机器人涉及的模块太多了：运动规划、环境感知、物体操作、人机交互、云端决策……如果全都要做，别说一轮开发实践，半年都不一定够。我的经验是，用三个标准来裁剪范围，判断一个功能该不该放进基础版。

第一个标准是“是否处于核心链路”。核心链路就是完成一次“感知-决策-行动-反馈”所必须经过的模块。对基础版来说，运动控制和状态反馈是不可或缺的；而像物品抓取、视觉避障这类，属于增值模块，可以先放一放。

第二个标准是“能否在有限时间内跑通”。我通常给每个候选功能预估一个开发时间，如果连仿真验证加真机调试验证需要超过两周，就会默认它不适合放进基础版。别高估自己的排错能力——G1这类机器人的问题往往不在代码逻辑，而在硬件响应、通信延迟、机械结构这些你意想不到的地方。

第三个标准是“能不能稳定向别人演示”。开发实践最终要汇报，如果一个功能在台上只能碰运气成功，那它对你的汇报不是加分项，而是风险项。宁可让基础版的功能平庸但稳定，也不要让它看上去惊艳却随时可能翻车。

我把三个标准整理成一个简单的判断表格，做范围裁剪时非常实用：

基础版的“基础”，不是降低工程质量，而是刻意控制变量。把有限的精力集中到一两个点打穿，比十个点各做三分之一的收益要大得多。这个道理在PPT汇报里同样成立：听众记住的永远是那一两个讲透的点，而不是你罗列的十个半成品模块。

2. G1开发环境与调试链路：从拿到设备到跑通第一个程序

定了目标之后，接下来就是基础设施工作。这块工作最琐碎，也最容易被低估。我见过不少朋友急急忙忙跑第一个例程，结果卡在一个环境依赖上白耗一下午。说实话，这一阶段的内容并不难，但顺序搞错了会非常折磨人。

2.1 开机检查与本体标定的优先级

第一次拿到G1，别急着写代码。先花半天时间把机器人的“身体基础”搞清楚。我习惯按这个顺序走一遍：

第一，检查电量与电源管理。人形机器人全身关节多，电机多，电量消耗比想象中快。基础版实践里有大量重复性调参测试，每轮测试都可能持续十几分钟甚至更久。我后来养成了一个习惯：每次调试前都记录起始电量，如果低于百分之三十，宁可先去充电。一次因为电量不足导致机器人中途下电蹲下，差点把旁边的支架碰倒，从那以后我再也不敢忽略电量检查。

第二，确认关节初始位置与标定状态。G1的关节编码器在上电后需要得到正确的零位。如果机器人关机前处于非常规姿态，下次上电可能会出现关节限位判断异常。建议在上电后先让它回到标准站姿，检查每个关节的反馈角度是否和机械零位一致。这个动作不需要额外工具，控制程序里通常都有查询关节状态的接口。

第三，找到急停开关并做一次急停测试。这一点我会在后面的章节展开，但这里先强调：急停测试一定要在做任何运动实验之前完成。按下急停后机器人是否立刻停止、控制程序是否收到状态信号，这两点直接决定了你后续测试敢不敢放开手脚。

2.2 SDK与开发机部署：仿真先行，真机后置

环境部署这一块，我的经验是优先在Linux上做开发，然后用官方SDK连接仿真环境跑通例程，最后再切换真机。为什么这么安排？因为仿真环境有两个巨大的优势：一是没有机械损坏风险，你可以放心地把关节速度拉到极限，看它的动力学响应是怎样的；二是参数修改成本低，改一次步态参数仿真里跑一遍，比真机一次次试要高效得多。

SDK部署本身不难，一般是拉取依赖、安装通信库、运行基础控制例程三步。我第一次部署时犯过一个很低级的错：没看SDK匹配的运行时版本，直接装了最新版，导致连接出错。后来老老实实按照官方文档的版本匹配表来，一次就通了。所以这里提醒大家：先看版本，后装环境，别默认“最新就是最好”。

跑通例程的标准不是“程序没报错”，而是你能从状态接口里读到连续的关节数据。我当时的验证方式是，写一个最简单的连接脚本，查询所有关节的目标角度、实际角度、力矩信息，打印十帧以上，确认数据是连续更新的。

# 示意性伪代码，展示连接和状态读取的基本结构 import robot_interface as ri # 连接控制器，默认通信地址和端口按实际环境配置 robot = ri.connect(host="192.168.8.100", port=8000) robot.enable_control() # 循环读取关节反馈状态，连续读到10帧即视为链路正常 for i in range(10): state = robot.query_joint_state() joint_names = state.joint_names actual_pos = state.actual_position print(f"frame {i}: joints={len(actual_pos)}, " f"first_joint_deg={state.actual_position[0] * 57.3:.2f}") time.sleep(0.05) robot.disable_control()

这段代码只能帮你验证通信链路是通的。真正让机器人动起来，还需要根据官方接口文档明确控制模式：是用关节角度指令，还是用电机力矩指令。基础版我建议只使用关节角度指令，它最直观，也最容易和运动规划结果对接。

2.3 通信链路、频率与状态反馈

做开发实践不是只要“能动就行”，你得清楚数据和指令是怎么流动的。G1的控制链路大致是这样的：开发计算机把控制目标发到机器人控制器，控制器经过内部运算把指令下发给各个关节电机，然后编码器和IMU的反馈数据再回流到控制器，最终以一定频率上报给开发计算机。整个链路里，我最关注“状态上报频率”和“通信稳定性”两个指标。

状态上报频率决定了你能多及时地感知机器人实际状态。如果上报频率偏低，比如每100毫秒才能收到一次完整姿态数据，那么当你调试步态参数时，会明显感觉机器人像“蒙着眼睛走路”——你看到的状态永远是滞后一拍的。解决方法是优先使用有线网络连接，然后把控制程序和状态订阅逻辑尽量简化，避免在回调函数里做耗时操作。我实测下来，稳定地拿到高频数据之后，调参的直觉准确度会显著下降？不对，是显著上升。你会更容易判断参数变化带来的真实影响。

通信稳定性这块，我踩过一个印象很深的坑：调试笔记本的Wi-Fi信号不太好，当时的无线连接隔一会儿就丢包，导致G1的指令有时发不出去。表现是机器人明明已经收到指令开始迈步，但因为下一个指令没到，只好停在半路。排查了很久才发现不是控制参数的问题，而是网络质量。自那之后，所有真机调试我都优先使用有线方式连接，无线只用于查看日志和视频回传。

3. 实践中真正花时间的部分：运动控制、感知融合与状态反馈

基础版的核心技术工作可以拆成三块：运动控制、感知数据接入、状态安全处理。这三块也正是PPT汇报里最有可能被追问的部分，因为它们是“实践含量”最足的环节。我把每一块单独说透。

3.1 动作不是写个坐标就完事：步态参数与姿态约束

第一次让G1迈步，比想象中难的不是“让它动”，而是“让它稳定地动”。如果你仔细读官方例程，会发现一个简单的走路动作背后包含了步态周期、步幅长度、抬腿高度、躯干俯仰角约束、落地缓冲等一系列参数。这些参数不是孤立的。步幅加大，躯干的姿态偏差就会变大；步频提高，关节的加速度就会变大，相应的力矩上限又是一个新的约束。

我一开始犯的错误是贪多，一次性把步幅和步频都调大，结果机器人起步两步就开始摇晃。后来学乖了：每次只动一个参数，动完记录一条实验结果，包括当时的行走距离、姿态偏差最大值、有没有异常抖动。这样排查起来非常快——出了问题，你只需要回滚上一个变量就行。

基础版的步态调参，我给自己的方法叫“小步增量法”。以步幅参数为例，我先把步幅从默认值往大调百分之五，跑一次，记录姿态偏差；如果稳定，再往大调百分之五；如果出现明显侧倾，就回退一个档位，然后在附近用更小的步进反复试。整个过程有点像用天平称量东西——你先放一个大概的砝码，再逐步微调。

另一个容易被忽视的是躯干姿态约束。G1走得好不好，很大程度上取决于控制器对躯干俯仰角、横滚角的约束能力。我在调参时会在GUI界面里同时打开姿态曲线，实时观察躯干角度有没有超出预设范围。这个方式很朴素，但比只看“走没走完”要精确得多。

3.2 传感器数据怎么喂给控制策略

基础版不一定需要复杂的多传感器融合，但最少也要面对两类数据：关节编码器数据和IMU惯性数据。这两类数据一个描述“关节转了多少”，一个描述“躯干姿态怎么样”，二者共同构成最基本的本体感知。

一开始我把IMU数据打印出来，只是想确认数据能读。后来发现不对劲：数据读到了，但和机器人实际动作对不上。排查下来发现是时间戳没对齐——关节数据和控制指令走的是一个通道，IMU数据走的是另一个通道，它们各自的时间戳起点不一样，直接混在一起用就会产生错觉，仿佛机器人正在做动作，而IMU数据还停留在动作开始前。

这里有个通俗类比：多个传感器就像好几双眼睛，如果每双眼睛看的方向、记时的方式都不一样，大脑收到的一定是吵架的信息。基础版里我不追求复杂的标定，只要求所有数据在进入算法之前统一到同一套时基。具体做法是，让主控制循环统一打时间戳，然后以其中一类数据（我用的是关节编码器数据）的时间为基准，把IMU数据按最近邻时间匹配进来。

这个细节虽然不起眼，但备不住汇报时评审一问就露馅。准备PPT时，我特意把“数据同步”作为一个小的技术点放进去，一方面表明基础版不是简单调包，另一方面也展示了我在工程细节上的思考。

3.3 状态机与安全保护：汇报里最容易被问住的角落

说实话，基础版汇报里最容易让整个汇报变尴尬的，不是你讲了什么酷炫功能，而是评委冷不丁问一句：“假如它走着走着遇到意想不到的情况，你怎么处理的？”

这个问题的本质不是技术方案，而是你有没有认真考虑过安全和异常状态。对G1这种体型和动力的机器人，如果关节超限、通信中断、或者机器人意外侧倾，没有可靠的保护机制，后果不只是演示失败，还可能是设备损伤和安全隐患。

基础版我强制实现了三层安全保护：

第一层是硬件急停。手掌可及的范围内必须有一个明确标记的急停按钮，而且动手测试前一定要实测，不能用“应该是好的”来代替。第二层是关节限位检查。每次下发动作序列之前，程序先检查目标角度是否超出关节的机械限位和软件限位，一旦超限就拒绝下发并报错。第三层是控制看门狗。如果控制程序在一定时间内没有收到机器人的状态回包，就自动把控制模式切换到安全停止状态，并记录最后一次异常。

这三层保护写进PPT可能只占半页，但价值很大。它不仅展示了你的工程意识，还能在演示出问题时帮你兜底。我记得有一次真机测试时，一个关节的反馈数据突然跳变，控制看门狗在几十毫秒内触发了安全停止，机器人稳稳站住，没有摔倒。那一刻我真的觉得，保护机制比任何花哨功能都重要。

4. 把实践装进PPT：基础版汇报的叙事结构与页面逻辑

开发和调试做完了，接下来是把实践变成PPT。这一阶段很多人会走极端：要不就是事无巨细地把代码逻辑贴上去，要不就是把PPT做得像广告宣传片，讲完听众完全不知道你具体做了什么。我自己的经验是，基础版汇报的叙事结构要服从一个原则：证据链清晰，重点突出，让听的人能跟着你的逻辑走。

4.1 先回答三个问题：做了什么、为什么这么做、下一步怎么走

准备PPT之前，我先在纸上写下来三个问题的答案。这三个问题也是整个汇报的骨架：

做了什么？这个问题的答案必须是可以被验证的事实，比如“完成了G1在平整场地上的稳定闭环行走，记录了完整的关节状态变化序列”。不要写成“研究并探索了人形机器人的运动控制”，这种话听着空，落不了地。

为什么这么做？这个回答要体现你对问题的理解，比如“选择以基础运动闭环为切入点，是因为它是所有上层应用的地基，先把这块做扎实，再扩展感知和操作模块”。这句话比罗列十个模块名称更有力。

下一步怎么走？这个回答要展示你的全局视野，比如“下一阶段计划在基础运动上叠加视觉避障，用单目摄像头做前方障碍检测，并把状态机扩展到避障触发上”。哪怕下一步还只是计划，也要给出明确的路径，别让人觉得你做完一次就结束了。

把这三个问题的答案写顺手了，再打开PPT软件。你会发现页面逻辑自然就出来了，因为每一页都对应这三个问题的一个切面。

4.2 基础版PPT的“六页骨架”

基础版汇报如果内容不算多，我建议不要硬撑十几页。控制在六页左右，每页讲清楚一件小事，效果会好很多。六页怎么分配，我直接列成一个表：

第1页的“一句话概述”很重要。这句话我打磨了很多遍，最终版本是：基于宇树G1，完成了从控制链路搭建、基础步态调参到状态安全保护的最小闭环实践，并实现了可稳定复现的演示流程。这句话能不能让别人在30秒内知道你干了什么？能，就说明合格了。

第3页的系统架构，一定要画成数据流向图，但别用太复杂的图。我在这一页只放了四个方块：上位机、控制器、执行器、感知反馈，然后用箭头标出数据来回的方向。旁边配上几句话解释每个箭头代表什么。我相信评审看这张图的时间不会超过一分钟，但如果图太乱，给评审的负面印象会延续很久。

第4页是整份PPT的重心。我建议放两类内容：调参过程和量化结果。调参过程不用列出每一次改参数，而是用“小步增量法”做概括；量化结果则要具体，比如“经过对比，步幅增加百分之十五后，躯干横滚角偏差从约3.5度下降到约1.8度”。这类数据让基础版汇报瞬间有了技术含量。

4.3 演示视频与现场动跑的取舍

基础版汇报最怕的事情是，现场动跑突然出问题，整个汇报的节奏被打断。我的经验是，必须准备两套演示素材：一个预录视频，一个现场动跑预案。

预录视频的录制要求，我给自己定了几条硬规则：不能剪辑拼接、画面里必须有实时时间戳、录制时环境条件必须和PPT里描述一致。为什么这么严？因为评审的眼睛很毒，一旦发现视频有剪辑痕迹，整份汇报的可信度就打折了。宁可视频里有一次明显的姿态调整，也比一个看起来像特效的完美录像更可信。

现场动跑预案则是在时间允许、场地安全、电量充足的条件下，安排一段不超过30秒的展示。这段展示不需要复杂，只需要做一件你在调试阶段重复做过多次、熟练度最高的事情。比如对我而言，就是让G1完成一次直线往返行走并停在指定位置。展示越简单，成功率越高，给汇报收尾的力度就越大。

我也见过一些朋友在汇报时喜欢中途插一段“即兴发挥”，结果机器人撞到障碍物或者走出预定区域，场面一度很尴尬。所以我的建议是：现场动跑追求的是稳定完成，不是惊艳全场。基础版汇报的底气，来自每天都在重复验证的确定性，而不是临场发挥的偶然性。

5. 踩坑记录与复盘：给后来者的建议

这轮开发实践做完，再回头看，真正让我成长最快的部分其实是踩坑和复盘的过程。很多问题在互联网上不一定搜得到现成答案，只能靠一条条试错、一步步倒推找原因。我把典型问题分成了三类，应该能帮后来者少走一些弯路。

5.1 我遇到的三类典型问题

第一类是机械与运动层面的问题。印象最深的一次是，G1在反复测试后，某个腿部关节明显发热，随后动作开始变保守。起初我还以为是控制参数漂移，后来用状态查询对比才发现，是电机温度上升触发了控制器对输出力矩的限制。那次之后，我每次连续测试都会控制测试组数，每跑三五组就让机器人休息几分钟。这里也给一个经验：看到机器人“走路突然变软”，优先查温度、电流、力矩上限，而不是急着调步态参数。

第二类是软件接口层面的问题。SDK升级之后，部分接口字段的单位和命名发生了变化，导致我的老代码解析出错。比如同一个关节角度，老版本可能输出弧度值，新版本可能输出角度值。这种问题不会报明显的错，只会让数据看起来“怪怪的”。排查起来需要一层层打印中间变量，把原始数据、解析后数据、控制指令三者做对比。最后解决办法也简单：锁定SDK版本，不轻易升级；并在代码里加一个单位转换的断言，一旦数值范围异常就立刻报警。

第三类是汇报表达层面的问题。我最初做的PPT试图把每一个调试细节都塞进去，结果汇报超时严重，核心内容反而淹没在细节里。后来我把“调参日志”单独抽出来放在附录，主PPT只放结论和关键证据，整个汇报瞬间清爽了。这个调整给我的启发是：PPT上的每一个字、每一张图，都要服从“证明我做成了什么”这个大目标，无关的内容再精彩也要忍痛删掉。

5.2 从基础版到进阶版的路径

基础版终究只是起点。做完之后，下一步往哪里拓展，其实在PPT的“问题分析与下一步计划”那一页就应该有一个清晰的答案。

我的扩展思路是，按依赖关系排优先级。眼下最自然的扩展方向，是把感知能力加进去：先接单目摄像头做简单的障碍物检测，在现有步态状态机里增加“遇障停止”和“绕行”两个状态。这个方向对现有系统改动不大，又能明显提升任务的完整性。

再往后，可以做动作模仿或者遥控遥操作。让G1通过动捕设备或者视觉方式学习一组动作，再复现出来。这类工作视觉冲击力强，汇报时非常有说服力，但技术跨度大，建议在基础版跑熟之后再启动。

如果身边有同事或同学在做大模型应用，也可以考虑接入自然语言接口：通过语音或文字指令触发一组基础动作。不过这个方向不要把期望值放太高，目前这个阶段，稳定性优先级远高于想象力。

5.3 一个小技巧：把翻车记录也放进备稿里

最后分享一个我自己的习惯：除了正式的PPT，我会单独准备一份一到两页的“问题记录页”，不投屏，只放在自己的讲稿里。内容包括这次实践里最糗的一次翻车、最离谱的一个Bug、以及我是怎么排查出来的。

这份记录的作用不是汇报时展示，而是帮你应对追问。比如有人问“你有没有遇到过什么困难”，你可以非常自然地讲出一件具体的事，以及你的排查思路和最终解决方案。这比干巴巴地说“我们克服了很多困难”要有说服力得多，也更像一次真实的技术交流，而不是一场念稿表演。

我甚至觉得，这种问题记录页才是实践者真正的底气来源——它证明你是真的在设备前蹲过、调过、翻过车，而不是拿着别人的成果在台上念参数。做开发实践，最终收获的本来就该是这份经历过问题的判断力，而不只是一串能跑通的代码。

如果你也正打算围绕宇树G1做一轮开发实践并准备汇报，希望这篇能给你一个清晰的下手路径。先定小目标，再打通链路，做出稳定结果，最后用证据组织叙事。基础版做好了，后面的路会顺畅很多。