自己做一台足式机器人：从舵机狗到无刷关节的进阶路线

论坛上每隔一段时间就会出现同一个提问：我想自己做一台四足机器人，从哪儿开始？

下面的回答通常是甩一个开源项目地址，配几段跑得很漂亮的演示视频。发帖的人满怀信心地照着买了一堆东西，然后卡在"电机转起来了，但腿一放下去就抽搐"这一步，再然后这个帖子就没有后续了。

问题不在于这个人不够聪明，在于路径反了。足式机器人是一个把机械、电子、控制、感知全都串在一起的系统，任何一环不通，整机都是不动的。 直接从最难的那一环起步，等于把四门课的期末考同时安排在第一周。

这篇文章给一条循序渐进的路线，分四个阶段，每个阶段都有一个能拿出手的东西。核心主张只有一句：不要一上来就冲无刷关节的四足。

先把边界说清楚：本文是基于几个公开开源仓库的文档与目录结构整理出的路线建议，不是我本人的实操记录。文中提到仓库里有什么、README 怎么说，都可以核对；涉及"跑起来是什么效果"的部分，以官方文档的说法为准。

阶段零：先在仿真里走一遍

这是最容易被跳过、也是性价比最高的一步。

仿真的好处直白到不需要论证：不花钱、不会摔坏东西、参数写错了顶多是机器人在屏幕里表演一个后空翻。而你要学的那几个概念——步态、状态估计、平衡控制——它们本身跟有没有实物没关系。

MuJoCo 这类物理仿真器加一个现成的机器人描述文件就能开始。以 unitree_mujoco 为例，仓库里的 unitree_robots 目录按机型分了一堆子目录，每个子目录下放着 MJCF 描述文件和 mesh：

unitree_robots/
    go2/
        go2.xml
        scene.xml
        scene_terrain.xml
        assets/          —— hip / thigh / calf / foot 的网格
    b2/ b2w/ go2w/ h1/ g1/ ...
terrain_tool/
    terrain_generator.py
simulate/               —— C++ 版仿真器
simulate_python/        —— Python 版仿真器
example/                —— cpp / python / ros2 三套示例

有几处细节值得停一秒。

scene.xml 和 scene_terrain.xml 是分开的两个场景文件，再配上一个 terrain_tool 目录——README 里说这个工具用来参数化地生成楼梯、粗糙地面、高度图之类的地形。一个仿真项目专门为地形做了工具，说明"在平地上走通"和"在不平地面上走通"在难度上根本不是一回事。 你在阶段零就能免费体会到这个落差。

另一处是 simulate_python/config.py 里的两个时间步：

SIMULATE_DT = 0.003   # 物理步长
VIEWER_DT   = 0.02    # 可视化刷新步长

配置注释写明，物理步长要大于渲染一帧所需的时间，否则仿真的可靠性没有保证。这其实提前给你演示了实时系统的核心矛盾：控制回路的节拍不能被显示、日志这类非关键任务拖累。 这个道理你在真机上也一定会再遇到一次，只是那时候的代价是机器人摔在地上。

还有一个配置项耐人寻味：enable_elastic_band，虚拟弹力带。README 说人形机器人不适合直接从地面启动，所以做了一根虚拟吊带，按键可以升降和释放。真实的人形机器人调试也是这么吊起来做的，仿真只是把这个工程习惯搬了进去。

控制程序这边，可以看 unitree_guide。它是一个面向入门者的四足控制器实现，README 里说它是配套一本讲四足控制算法的书出版的。它的目录结构基本就是足式控制的知识地图：

include/FSM/          —— Passive / FixedStand / FreeStand / Trotting
                         BalanceTest / StepTest / SwingTest
include/Gait/         —— WaveGenerator / GaitGenerator / FeetEndCal
include/control/      —— BalanceCtrl / Estimator / ControlFrame
include/common/       —— unitreeLeg / mathTools / LowPassFilter
include/interface/    —— KeyBoard / WirelessHandle / IOROS / IOSDK

按 README 的操作说明，控制器起来之后机器人趴在地上，按 2 从 Passive 切到 FixedStand，按 4 切到 Trotting，然后用 wasd 控制平移、jl 控制旋转、空格停下站住。

这个状态机顺序本身就是路线图。 没有人一上来就 Trotting，中间必须经过一个"先老老实实站好"的状态。而 State_SwingTest、State_StepTest、State_BalanceTest 这三个测试状态的存在更说明问题——摆腿、踏步、平衡是被拆成三个独立可验证的能力分别调试的，而不是合起来一把梭。

这一阶段能做到：在屏幕里让一台四足按预设步态走起来，改参数看效果，理解 FSM 各状态之间的切换条件。

做不到：任何跟真实物理有关的事。仿真里的电机是理想的，没有发热、没有延迟、没有电流限制、齿轮没有间隙。

真正学到的：步态相位是怎么编排的、状态估计在估什么、平衡控制器的输入输出是什么。这些概念以后在真机上你不必再重学，只需要重新调参。想系统看这套概念的话，站内的步态基础和状态估计两篇是配套的。

什么时候该进入下一阶段：当你能说清"为什么这个参数改大以后它开始晃"的时候。如果只是照着 README 敲了几个键看它走路，那还没到。

阶段一：舵机四足（入门）

现在动手做实物。用普通舵机加 3D 打印件或亚克力件，做一台小四足。

我知道这一步在很多人眼里"很 low"。恰恰相反，这一步的价值不在算法，在于让你用最便宜的方式踩完所有非算法的坑。

机械件装不上、螺丝孔位偏了、舵机臂角度装错导致零位不对、线束缠住关节、多个舵机一起动的时候主控莫名其妙复位——这些问题在舵机平台上出现，代价是几个小时和几块钱；在无刷关节平台上出现，代价可能是一台电机。

能做到：按预设步态往前走、原地转向、简单遥控，摆几个姿势拍视频发朋友圈。

做不到：力控。舵机的接口就是给一个角度让它转过去，它不知道自己受了多大力，也不会顺从外力。所以它适应不了不平的地面，抗不了扰动，被推一下要么硬顶要么翻。原因跟减速比有关，我在关节电机那篇里拆过。

真正学到的有三样：

正逆运动学。 你要让脚尖走出一条特定的轨迹，就必须把足端坐标反解成几个关节角。unitree_guide 里 common/unitreeLeg.h 干的就是这件事。这套数学和机械臂是同源的，站内的机械臂运动学那篇可以直接拿来用。

步态相位编排。 四条腿什么时候抬、什么时候落、相位差怎么排，直接决定它是走还是趴。Gait/WaveGenerator 这个命名很直白——步态本质上就是一组有固定相位关系的周期波。

多路舵机同步。 十几路 PWM 要在同一个控制周期里更新，靠主控直接输出很快就不够用了，一般会挂一片专门的驱动芯片。站内的 PCA9685 舵机驱动讲的就是这条路。

什么时候该进入下一阶段：当它能稳定走完一段路，而你觉得"再调步态参数也就这样了"的时候。这个天花板不是你的问题，是开环控制的天花板。

阶段二：加入感知与闭环

给它装一个 IMU。

这一步的改动看起来很小，思路上却是一次跃迁：机器人第一次知道了自己现在是什么姿态，而不是闭着眼睛按剧本演。

最直接的一个目标：让它站在斜面上时，身体保持水平。实现方式是给身体姿态加一个闭环——IMU 读出俯仰和横滚角，与目标姿态求差，把这个差通过运动学分配到各条腿的长度上。腿伸长的那侧被抬高，机身就转回水平。

unitree_guide 的 FSM 里有一个 State_FreeStand，做的就是站定之后调整身体姿态这件事。它和 State_FixedStand（固定姿态站立）分成两个状态，说明"站住"和"按你要的姿态站住"是两个难度台阶。

这一阶段真正要学的东西是传感器融合。IMU 的加速度计对姿态的静态估计准但噪声大，陀螺仪短时间内平滑但会漂移，只用其中一个都不行。仓库里 common/LowPassFilter 和 control/Estimator 这两块的存在就是这个问题的答案——原始传感器读数永远要过滤波，姿态和速度永远要靠融合估计而不是直接读。

闭环本身则回到最基础的PID 控制。姿态环的结构和你在平衡小车上写过的没有本质区别，只是输出从"两个轮子的速度"变成了"四条腿的长度"。

能做到：斜面上站平、被轻推之后自己调回来、走的时候机身不那么晃。

做不到：真正的动态平衡。落地冲击、打滑、踩空这些情况需要腿能柔顺地卸力，纯位置控制的舵机做不了。

真正学到的：闭环的思维方式。从这一步开始，你写的代码不再是"发指令"，而是"根据反馈修正指令"。这是控制工程和玩具编程的分界线。

什么时候该进入下一阶段：当你确信瓶颈已经从"代码没写对"变成"硬件做不到"的时候。这个判断很重要——很多人在硬件天花板下反复调参调了半年。

阶段三：无刷关节（进阶）

到这一步才谈得上真正的足式动态运动。

核心变化是关节换成可力控的方案，控制器不再只发角度，而是发一组包含刚度、阻尼、目标位置、目标速度和前馈力矩的指令。unitree_actuator_sdk 的 README 里给了这样一段赋值示例：

cmd.kp    = 0.0;
cmd.kd    = 2;
cmd.q     = 0.0;
cmd.dq    = -6.28 * queryGearRatio(MotorType::A1);
cmd.tau   = 0.0;

门槛在这里陡然升高，而且是全方位的：

电机贵，而且需要配套驱动器。 关节不是一个电机加一根信号线就完事，里面跑着固件、有 bootloader、走串口总线、多个电机挂同一条线上要靠 ID 区分。那个 SDK 的 example/ 里专门有一个 changeID.cpp，motor_tools/ 目录下有 changeid、swboot、cancelboot 这类工具——新电机出厂 ID 相同，装机之前必须逐个改 ID，这是装配流程的一部分，不是可选步骤。

控制回路要跑在高频率上。 力控关节的指令是每个周期都要重发的，节拍一乱，关节的表现就是抖。

调试的危险性完全不同。 一条能输出足够力矩的腿在你手边失控地抽动，和一个舵机抽动，不是一个量级的事。

参数换算会安静地坑你。 README 里明确写了指令都是转子侧的，而我们通常计算的是输出侧的，kp 和 kd 需要除以减速比的平方才能换算过去。写错了程序照跑不误，只是关节剧烈振荡。仓库里同时给了 example_a1_motor.cpp 和 example_a1_motor_output.cpp 两个示例，就是为了把这件事讲清楚。README 里还提到，输出侧那个示例针对特定型号额外做了两次系数修正，并注明那是这几款电机的特有处理，换其他电机不需要——这种"型号特有的魔法数"是嵌入式世界的常态，看到别人代码里有看不懂的常数，先怀疑它是硬件特性而不是笔误。

这个阶段可以参考的开源资源是有的。Qmini 是一个把硬件侧完整开源出来的双足项目，仓库里给了：

Qmini_DIY.pdf           —— DIY 说明
STEP_file/              —— 全部机械件的 STEP，有 v1_0 和 v2_0 两版
urdf/Qmini.urdf
urdf/meshes/            —— LL/RL 的 hip_yaw、hip_roll、hip_pitch、
                           knee、ankle 与 base_link

README 里说明它提供了完整的物料清单、电气系统框图和装配 SOP，机械结构可以整体 3D 打印，几乎不需要定制加工；核心软件栈则指向另一个外部仓库。mesh 的命名把每条腿的关节层次摆得明明白白：髋部三个转轴（yaw / roll / pitch）加膝、加踝。看懂这个命名，你就看懂了腿的自由度是怎么分配的——髋部负责三个方向的朝向，膝和踝负责伸缩与足底贴地。想细看这个项目的开源程度，站内有单独的一篇Qmini 开源双足拆解。

能做到：在你把整套东西调通之后，才谈得上柔顺落地、抗扰动、上下台阶这些足式机器人真正的看点。

做不到：省事。

真正学到的：一个完整机器人系统的全部层次，从电机固件一直到步态规划。

这一阶段的现实认知：它已经不是周末项目了。 前三个阶段每一个都可以在若干个周末里做出成果，这一个不行。如果你的目标只是"做一台会走路的机器人给孩子看"，停在阶段二完全没有问题，而且成果同样能看。

四个跟阶段无关的坑

这几件事在任何阶段都会咬你一口，越早知道越好。措辞上我说的是"常见的问题是"，因为它们来自公开的讨论与工程常识，不是官方文档里的条款。

电源是第一大坑。 多个电机同时启动、同时换向的瞬间，电流会出现一个远高于平均值的尖峰。电源撑不住，母线电压被拉低，主控直接复位——现象是"机器人走着走着自己重启了"，而你在代码里怎么找都找不到 bug。常见的做法是主控和电机分别供电、电源线加粗、在电机端就近加大电容。只要遇到"随机复位"，先怀疑电，别怀疑代码。

机械精度决定上限。 3D 打印件的公差、齿轮的回差、轴承的间隙，这些误差会原封不动地变成控制误差，而且是控制算法永远补不回来的那一种。腿在空中甩的时候看不出来，一落地承力就全暴露出来。当你调参调到某个点之后怎么调都不再变好，去检查机械。

先搭调试手段，再写控制。 这一条最容易被急着看效果的人跳过。你需要能实时看到关节的目标值和实际值画在同一张图上——只有这样你才能一眼看出是跟不上、超调了、还是根本方向反了。这不是我的个人偏好：unitree_guide 里有 common/PyPlot.h，并且把 matplotlibcpp.h 放进了 thirdParty/，一个控制器项目专门集成了绘图能力，就是这个原因。有曲线看，比盲调快十倍。

任何时候都要有一个物理断电开关。 位置要在你伸手就能拍到的地方，而且切的是动力电，不是信号。软件急停在软件跑飞的时候是无效的。这一条在阶段一可有可无，到阶段三是保命的。

收束

回头看这四个阶段，它们其实是在按顺序解决四个不同的问题：概念（阶段零）、机械与工程（阶段一）、反馈与闭环（阶段二）、力与动态（阶段三）。每一个都必须解决，区别只在于你打算按什么顺序、用多大代价去解决它们。

跳过前面直接冲最后一个，不是走了捷径，是把四个问题堆在一起同时面对——而且是在最贵、最容易摔坏、最难调试的平台上面对。

还有一条贯穿始终的经验：每个阶段都要有一个能拿给别人看的东西。 屏幕里走起来的仿真、桌上会转向的舵机狗、能站在斜板上的小四足——这些成果的意义不只是好玩，而是它们能证明"上一层的东西你确实通了"，同时也是你在漫长的调试期里唯一的补给。

接下来往哪走看你的兴趣：想先把仿真吃透，可以顺着 unitree_mujoco 的结构往下读，再看从仿真到真机这一步的门槛在哪；想动手做点小的，机器人与具身智能卷里有从舵机起步的完整阶梯；想找一个能做完的具体项目，去实战项目库挑一个。