企业官网建设流程全解析

很多人第一次看到"微小型双足鸭形机器人"这个项目，第一反应大概率是：双足机器人本来就不容易站稳，为什么还要套个鸭子的壳？多出来的头部和翅膀不是纯粹给自己增加负担吗？说实话，我在最初立项的时候也有过这个疑惑。但等我真正把整条链路跑完——从结构设计到仿真训练，再到真机调参——才发现这个"鸭形"不仅不是累赘，反而成了整个强化学习训练里最有价值的一块试金石。

这篇文章我想完整记录一下这个项目的技术决策过程。内容会覆盖微小型双足平台的结构与硬件选型、强化学习训练管线的搭建、开源代码仓库的架构思路，以及从仿真迁移到真机时那些仿真里永远教不会你的坑。项目本身已经开源，所有结论都可以在仓库里复现。如果你正准备做一个类似的强化学习驱动的微小型双足机器人，或者只是好奇"一个看起来像玩具的项目到底能挖多深"，这篇应该能给你一些参考。

1. 为什么是"微小型双足鸭形"：项目定位背后的取舍逻辑

1.1 微型化到底改变了什么

先聊一个在论文里经常被一笔带过、但实际做起来处处掣肘的问题：机器人一旦做到"微小型"，整个动力学行为和中大型平台是完全不同的。

以常见的15cm级双足机器人为例，整机重量通常在300g到600g之间，而每条腿的长度可能只有5到7cm。这个尺度下，腿部的转动惯量极小，系统的时间常数非常短——换句话说，关节稍微多转一度，质心位置就立刻发生变化，留给控制器纠错的时间窗口远小于大型双足机器人。大型双足（比如60kg级的人形平台）可以用线性倒立摆模型、零力矩点（ZMP）这类经典方法做稳定控制，因为系统响应慢、惯量大、结构刚度好。而微型双足腿部的运动频率往往超过10Hz，一旦出现步态失稳，基本没有时间去"调整支撑脚的位置"，只能靠下一次迈步的落点规划来兜底。

这带来的直接结果是：经典控制方法在微型双足上非常难调，而强化学习反而成了更自然的选择。因为强化学习不要求精确的动力学模型，它直接在"状态-动作"的映射空间里搜索稳定策略，策略输出的就是关节目标角度或力矩，天生适合这种"响应速度快、模型不精确、状态耦合强"的小型平台。

我在立项时就把这条作为核心判断依据：**这个项目本质上不是"给鸭子做外观"，而是"用微小型双足这个极具挑战的植物人级平台，验证强化学习策略的鲁棒性"。**鸭形外观则负责加大难度——头部和尾部的非对称重量会迫使策略必须学会主动调节重心，而不是简单复现一个"原地踏步"的假稳定。

1.2 鸭形外观：视觉友好与扰动注入的折中

再说鸭形。市面上的开源双足机器人大多走极简的"骨架风"——两根腿、一个髋关节横杆、一个控制板吊着。这类平台的好处是重心集中、调试容易，但坏处是策略很容易过拟合到"理想重心"上。一旦换一个外壳，重量分布变了，原来在仿真里跑得很溜的策略立刻就废。

鸭形设计刚好是对冲这个问题的。鸭子的特征重心区间比较靠前——头部通常占整个外观件的15%到20%重量，而且位于躯干前方偏上的位置。这个重心偏移量在微型双足上足以产生持续的倾覆力矩，策略必须学会"抬头挺胸"或"步幅补偿"来抵消这种偏移。从训练角度看，这相当于在奖励函数里天然植入了一个"外力扰动项"，只不过这个扰动不是靠随机力模拟的，而是实实在在的物理重量分布。

另外，鸭形外观还有一层交互上的考虑：**微小型机器人最大的应用场景其实是桌面级教育、展厅引导和家庭陪伴，这类场景非常看重"第一眼亲和力"。**同样的强化学习步态控制代码，装进一个鸭子里和装进一个裸露的铝骨架里，观众的主观感受完全是两回事。实际做下来，鸭形头部对目标跟踪、语音交互这类上层功能也有天然的遮挡问题——它可以藏住各种传感器和线缆，让整机看起来干净很多。

所以"鸭形"不是装饰，而是这个项目的第二个核心变量：一个会主动制造重心偏移、同时又具备产品化外观的双足平台。

2. 硬件平台拆解：自由度配置、驱动选型与算力权衡

2.1 从机构设计说起：每条腿需要几个自由度

微小型双足的机构设计绕不开一个经典争论：每条腿到底用2自由度（髋侧摆+膝俯仰）还是3自由度（髋侧摆+髋俯仰+膝俯仰）？

2自由度腿的优点是结构简单、舵机少、重量轻、控制维度低，强化学习训练起来收敛更快。缺点是步态受限，基本只能走"屈膝拖步式"，无法实现高抬腿、跨障碍、侧向平衡这些能力。3自由度腿更接近真实动物运动学结构，能实现更多样的步态，但代价是每条腿多一个舵机，整机重量上浮、控制周期变长、动作空间维度从4维升到6维，训练难度明显上升。

我最终选的是3自由度腿——胯部负责侧摆和俯仰，膝盖负责小腿俯仰。原因有两个：

第一，鸭形外观的重心偏移幅度比想象中大，如果只有2自由度，策略能用来调节姿态的手段实在太少——它甚至没法主动外展大腿来扩大支撑多边形，稍微一个大扰动就会直接侧翻。

第二，从开源社区目前的主流模型看，3自由度腿是"标准答案"级配置。选它意味着可以直接复用社区里大量基于6维动作空间的行为克隆和强化学习经验，不用自己从头趟一遍参数。

下面是我在结构设计阶段确定的自由度分配方案：

• 每条腿：髋侧摆（yaw）、髋俯仰（pitch）、膝俯仰（pitch），共3个自由度
• 双足合计：6个可控自由度
• 颈部：1个俯仰自由度，控制鸭头抬降
• 翅膀：左右各1个俯仰自由度，主要用来辅助平衡表达和交互反馈
• 尾部：固定，不带自由度，但承担了约5%的整体配重

2.2 舵机选型中的扭矩估算与实例计算

微型双足最尴尬的环节就是驱动选型。舵机太小，扭矩不足，腿根本撑不住机身；舵机太大，重量超标，强化学习策略要消耗更多能量去对抗自身重量。

我用的估算方法是按静载扭矩乘一个动态裕度系数。以整机重量500g、腿长7cm、质心高度4cm为例：

• 单腿在单脚支撑相承受的极限静载扭矩 = 0.5kg × 9.8N/kg × 0.04m ≈ 0.2N·m
• 考虑动态摆动和落地冲击，峰值扭矩约为静载的2.5到3倍，也就是0.5到0.6N·m
• 微小型舵机标称扭矩通常以kg·cm标注，换算关系为1kg·cm ≈ 0.098N·m，0.6N·m对应大约6.1kg·cm

所以理想条件下，髋关节和膝关节的舵机至少要能输出6kg·cm级别扭矩才算安全。但实际市面上真正能在7g到9g克级重量下稳定输出6kg·cm的舵机非常少，通常需要折中：髋关节用大力矩舵机（比如6kg·cm），膝关节用稍弱的型号（4kg·cm左右），因为膝盖在多数步态相位承担的力矩小于髋关节。

除了扭矩，还要看舵机的总线协议和响应带宽。微型双足对舵机带宽的要求比想象中高，因为强化学习策略输出的目标角度通常以50到100Hz的频率下发，舵机本身如果只支持模拟PPM信号，分辨率和响应延迟都会成为控制瓶颈。更推荐的是带串行总线（如串行总线舵机或CAN总线舵机）的型号，这样能实时反馈位置、电压、温度，对训练和调试都有大帮助。尤其是电压反馈，真机运行中如果舵机堵转，电源掉压明显，反馈数值会立刻提醒你调整策略或机械结构。

2.3 主控选型与算力分配

微小型双足的算力窗口很窄。策略网络推理和步态控制都要在机载完成，不能依赖远程PC——依赖上位机还能叫机器人，那不依赖就只能叫遥控玩具了。但机载算力也不宜太强，因为主控板重量和功耗会直接影响续航与结构设计。

我的分工方案是：

• 低层控制用MCU（STM32G431系列）：负责读取IMU、解析舵机反馈、执行PD外环、计算腿部正逆运动学。控制周期定在1kHz中断里，所有低层计算控制在20微秒以内
• 策略推理用树莓派Zero 2W级别的主板：负责加载强化学习策略网络（ONNX或TFLite格式）、接收IMU和关节状态输入、推理出目标关节角度、下发给STM32执行

这样分工的好处是：策略网络更新时只需要替换树莓派里的模型文件，不用重新烧录MCU逻辑。对开源项目来说，使用者可以非常方便地跑自己的训练结果，而不用碰底层控制代码。

算力上，树莓派Zero 2W跑一个输入维度11、隐藏层256、输出维度6的三层MLP策略，单次推理耗时大约5到8毫秒，完全满足50Hz的控制下发频率。这个算力余量还可以留一部分给后续的视觉识别模型，不需要额外换板子。

3. 强化学习训练管线：仿真环境搭建、算法选型与奖励机制设计

3.1 仿真引擎选型：MuJoCo、PyBullet还是Isaac Gym

微型双足项目在仿真引擎选择上有个比较现实的排序：物理精度、环境搭建速度、训练并行度、以及社区生态。每个引擎都有明显的侧重点，我用一个表把关键差异列出来：

• MuJoCo：物理精度高，接触模型稳定，Python接口简洁，支持批量仿真，对足式机器人支持较好，但可视化相对朴素。免费开源，社区持续维护
• PyBullet：使用门槛很低，内置URDF导入和调试GUI，用户多、资料全，适合动手验证思路。但批量并行训练效率一般，复杂接触下的数值稳定性略弱
• Isaac Gym：GPU并行仿真，可以在单张显卡上同时开几千个环境实例，训练速度快几个量级，适合大规模随机化训练。但环境构建和安装较繁琐，老显卡和老系统支持不友好
• Gazebo：适合ROS2生态，物理引擎和渲染都完整，但强化学习训练的并行度和易用性都偏弱，更多用于验证整体系统而非训练算法

我最终选择的方式是MuJoCo作为主要训练平台，PyBullet作为交叉验证平台。原因很实际：**这个项目的核心目标是可控可复现地研究"策略在微小双足平台上的迁移能力"，而不是刷训练速度或展示超大规模并行。**MuJoCo在足式接触这部分数值更稳，训练出的策略在真机上的迁移成功率明显更高。

3.2 为什么要选PPO而不是SAC或TD3

在强化学习算法选型上，其实主流选项就几个：PPO、SAC、TD3、DQN变体。DQN这类基于价值的算法首先排除——双足行走的动作空间本质上是连续的关节角度，离散化做不了高精度步态。

剩下的连续控制算法里，我做了一组对比实验，结论是PPO在这个场景下综合表现最好，但并不意味着SAC不行。表里是我实测的几个维度：

• 训练稳定性：PPO高，SAC中高，TD3中
• 样本效率：SAC高，PPO低
• 超参数敏感度：PPO低，SAC高，TD3高
• 真机迁移表现：PPO好，SAC中，TD3中
• 多环境并行扩展：PPO方便，SAC方便，TD3一般

PPO的优势在于它做policy optimization时有一个clip机制，避免了单次更新步长过大导致策略崩溃。微小型双足这种高动态系统，仿真里训练时策略经常会在某个更新步突然跳进"疯狂抖动"的局部最优点，一旦跳进去再想出来非常难。SAC和TD3在标准benchmark上收敛更快，但它们在超参数上更娇气——奖励缩放系数、熵温度系数都要仔细调，而在一个需要长期维护、希望社区用户也能轻松复现的开源项目里，PPO的鲁棒性是最有价值的。

你也可以理解为"样本效率低"在这个场景里根本不是致命伤：仿真环境跑几千步只需要几分钟，多花一点训练时间换来策略稳定性，非常划算。

3.3 奖励函数设计：从"活下来"到"走得像鸭子"

奖励函数是强化学习训练管线的灵魂。我在这个项目里的设计思路分三层：基础生存层、步态质量层、行为风格层。

基础生存层最简单：每个仿真step存活给一个小正奖励，跌倒（躯干触地或高度低于阈值）立即终止并给大负奖励。这一层保证策略的首要目标是"不摔倒"。

步态质量层包括几个核心项：

• 速度跟踪奖励：鼓励机器人以目标速度前进
• 姿态平滑度惩罚：对相邻两个控制周期之间的关节角速度突变加惩罚，抑制高频抖动
• 能量消耗惩罚：对关节力矩和角速度乘积的积分加惩罚，让策略学会省力
• 头部高度维持惩罚：对鸭头离地高度偏离理想范围的时刻加惩罚，防止策略通过"趴地走"这种取巧方式维持稳定

行为风格层是这个项目比较特别的地方。既然做了一个鸭形机器人，就希望它走起来确实有一点鸭子的形态特征——身体有适度的左右摇摆、脚掌抬离地面的最大高度控制在合理范围、头部的俯仰维持在一个自然的范围里。我对鸭子的步态做了一个粗略的时序采样，把"脚掌离地高度"和"躯干横滚角速度"这两条曲线作为参考信号，加了一个正向模仿奖励。这部分并不强制策略精确复现参考轨迹，而是提供"走得像鸭子更有可能拿到高分"的倾向性信号。

奖励函数里还有个容易忽略的细节：**Vx（前进速度）如果直接作为奖励目标，策略很容易学会"原地快速踏步"来骗速度分数。**解决方法是把一个周期内的实际位移离散步进奖励，而不是把瞬时速度作为变量参与计算——简单说就是走完一段距离才给一段距离的奖励，原地踏步拿不到分。

3.4 域随机化与课程学习

微型双足从仿真迁到真机，最大的障碍是仿真和物理世界之间的参数差异。我在仿真环境里实现了多维度随机化：

• 质量随机化：每个link质量乘以0.8到1.2的随机系数
• 重心偏移随机化：让鸭头、翅膀的质心位置在±5mm内浮动
• 摩擦系数随机化：地面摩擦与脚底摩擦分别设定在0.4到1.2之间
• 关节电机参数随机化：最大力、阻尼系数、回差大小都做了随机
• 观测噪声注入：在IMU和关节角度观测上叠加高斯噪声，让策略不能盲信反馈

课程学习的设计也比较关键。我没有让策略直接从头就在全扰动环境下硬跑，而是分了三级：

上一级：平坦地面，无随机化，设置速度奖励，让策略先学会基本迈步。
下一级：加入质量随机化和重心偏移，让策略适应鸭形外观带来的重量分布。
最后一级：加入地面摩擦随机化、电机参数随机化和观测噪声，模拟真实传感器和执行器特性。

这个过程下来，训练收敛速度大概提升了1.5倍左右，而且最终策略在真机上的首次落地成功率明显提高。

4. 开源架构解析：代码仓库如何组织才能让社区真正用起来

4.1 仓库目录结构与模块边界

开源项目最怕的是"作者自己跑得通，别人跑不通"。我在组织这个仓库的时候，刻意把代码分成几个彼此独立的层，每一层都可以单独替换。

完整的目录结构大致如下：

duckbot/ ├── envs/ # 环境层，仿真环境的封装 │ ├── duckbot_env.py # MuJoCo环境 │ ├── duckbot_pybullet.py# PyBullet交叉验证环境 │ └── task_registry.py # 任务注册表，课程学习难度配置 ├── algos/ # 算法层，策略优化实现 │ ├── ppo.py │ ├── sac.py │ └── replay_buffer.py ├── models/ # 策略网络与价值网络结构 │ ├── mlp_policy.py │ └── duckbot_urdf/ # URDF模型文件 ├── scripts/ # 训练入口 │ ├── train_ppo.py │ └── train_curriculum.py ├── deploy/ # 真机部署 │ ├── deploy_onnx.py │ └── onnx_export.py ├── hardware/ # 真机控制代码（STM32和树莓派） │ ├── stm32_fw/ # MCU固件 │ └── pi_controller/ # 树莓派策略推理节点 └── configs/ # YAML配置 ├── ppo_default.yaml ├── reward_weights.yaml └── sim_params.yaml

分层原则很简单：**环境层不知道算法的存在，算法层不知道机器人的存在，部署层只负责把策略模型文件加载起来对接底层控制。**依赖方向是单向的：train_ppo.py 调用 envs 和 algos，deploy 只读取导出的onnx文件，不依赖任何训练库。

4.2 配置管理：让奖励权重的调整变成一个文本操作

我在前面提到奖励函数有很多项，每一项都有权重。项目里这些权重全部集中在一个reward_weights.yaml文件里，训练脚本启动时自动加载。这样做的目的是把训练实验变成"文本修改"，而不是"代码修改"。

configs/ppo_default.yaml里会包含这些核心配置字段：

• seed：固定随机种子，保证可复现
• total_timesteps：总训练步数
• learning_rate：学习率
• clip_range：PPO的裁剪范围
• gae_lambda：GAE折现因子
• num_envs：并行环境数
• batch_size：更新批次大小
• reward_weights：从YAML单独读取的奖励权重字典

这个做法对开源社区特别友好：任何用户拿到仓库后，想复现结果只需要把配置文件里的seed改成同一值，再确认依赖版本一致，跑出来的训练曲线应该是基本一致的。

4.3 策略导出与部署接口

训练得到的PyTorch策略模型，直接用TorchScript或者ONNX格式导出。我选择ONNX，因为ONNX的推理库对Raspberry Pi这类ARM平台更友好，加载速度更快，依赖更少。

部署侧的逻辑大概是这样的：

部署流程: 1. 训练完成后脚本自动导出 .onnx 文件 2. 将 onnx 文件拷贝到树莓派的 model/ 目录下 3. 树莓派节点加载 ONNX Runtime，启动 50Hz 推理线程 4. 在 ROS2 或自研的轻量通信协议中，将 IMU 数据与关节角度组合为 11 维观测向量 5. 推理结果作为目标关节角度下发到 STM32

这里有个容易忽略的细节：**训练环境里的观测值定义必须和真机部署完全一致。**比如训练里用了加速度计的原始值还是滤波值，归一化是否使用训练的统计量，若在部署时没做同样的预处理，策略的输入分布和训练时不一致，输出直接就会失真。我的做法是导出的onnx模型里直接包含了归一化的均值和方差，部署端不需要再单独维护一套归一化逻辑，把不一致的可能性降到最低。

5. 真机迁移的踩坑记录：仿真里学不到的教训

5.1 舵机延迟与"仿真稳定、真机抽风"的根因

在仿真里训练完一套策略后，第一次上真机的过程基本可以用"信心崩塌"来形容。仿真里走得稳稳当当的策略，到了真机上变成了"原地抖动、迈出一步就倒"，这个问题几乎100%会遇到。最主要的根因是舵机响应延迟。

MuJoCo仿真里的执行器是理想的位置驱动器——你给定目标位置，理论上它瞬时到达或者用一个标准PD模型逼近。但真实舵机内部是一个位置闭环系统，目标角度输入到实际输出之间存在30到50毫秒的延迟。在50Hz控制周期下，这个延迟相当于1.5到2.5个控制周期。对微型双足这种高动态系统，一个控制周期的延迟就足以让姿态误差发散。

解决这个问题的几个层面：

• 第一层：在仿真训练阶段就给执行器引入延迟模型。把目标的当前动作延迟N步之后才应用到仿真机器人身上，N取1到3随机化
• 第二层：在真机侧增加一个前馈补偿，读取当前舵机角度后，根据历史的角度跟踪误差估算延迟，并把目标角度提前一点下发
• 第三层：降低策略输出频率，从100Hz降到50Hz，反而能减弱延迟的影响——因为输出频率过高时，策略刚给了一个新目标，舵机还没追上，新的目标又来了，系统一直在追空气

我在实际调试中试过把目标角度通过一阶低通滤波再发到舵机，这个方法也能显著抑制抖动，代价是响应变短。拉格朗日插值预测舵机未来位置比较费事，最后我用延迟训练这一层就解决了大部分问题。

5.2 重心偏移与鸭头重量的重新分配

前文提到鸭形外观会主动制造重心偏移，但这个偏移如果超出策略的校正能力范围，会直接导致训练失败。我在最初版本的机械设计里，鸭头做得比较沉，测试下来头重约80g，占整机重量的16%——这个比例在静平衡状态下还看不出问题，但一旦进入单脚支撑相，头部的重力力矩会迫使躯干快速低头，而策略把头部俯仰角拉回来需要的髋关节力矩又不够。

后来做了一次机械结构的减重优化：把鸭头做成了中空外壳，内部只放了IMU和一块小电池，重量降到35g；同时把一部分电池挪到尾部，让整机的重心尽量靠近支撑多边形中心。这个改动之后的强化学习训练难度直接下降了一档，同样的奖励配置，策略收敛速度提升明显。

这个经验可以抽象成一条设计准则：外观件占整机重量超过10%时，必须把它纳入到仿真模型的link质量和质心参数里一起训练，否则真机必翻车。

5.3 跌倒检测、恢复策略与安全边界

微型双足在真机测试中跌倒几乎是不可避免的。项目开源的仓库里我专门写了一套跌倒检测与恢复逻辑，不是为了让它爬起来继续走——以微型舵机的扭矩输出能力，原地自扶起基本没有可能——而是为了在跌到前发出信号，让舵机进入低功耗保持模式，避免电机堵转烧毁。

检测逻辑其实不复杂：

• 用IMU的俯仰角和横滚角判断躯干姿态
• 任何一个方向超过45度就认定即将跌倒
• 触发后立即将所有舵机目标角度切换到当前角度，而不是给零力矩

这里有个容易犯的错误：跌倒时直接给舵机零目标会让舵机瞬间释放，导致机器人在惯性作用下猛烈砸地，损坏外壳。最好的处理是让舵机缓慢地跟随当前位置，用可控的阻尼把冲击吸收掉。

另外，在机械结构上一定要加限位挡块。舵机的物理行程范围如果超过运动学允许的最大范围，一旦策略输出异常角度，舵机就会带着结构件硬撞限位，反复几次就会扫齿。我在鸭头颈部和膝盖关节上都加装了硬限位，这一条看起来简单，但实际止损效果非常明显。

5.4 从仿真到真机的"步态粗调"清单

最后给一份实用的真机落地检查清单，都是踩过坑之后总结出来的：

• 检查IMU安装方向与仿真定义一致。坐标系不一致，观测直接是反的，策略必然崩溃
• 检查每个舵机的旋转方向与URDF定义是否一致。舵机方向反了，策略输出的正方向会变成负运动
• 校准舵机零点。强化学习策略通常以中位作为零位，真机的初始安装角度如果不在零点附近，第一步就会走出奇怪姿势
• 逐步调低期望速度。刚上真机时先让策略跟踪一个很小的前进速度（比如0.05m/s），确认稳定后再逐步加大。
• 记录舵机电压和电流。如果电压在控制周期内有掉落，优先检查电源线和电池内阻，而不是急着改策略

6. 策略部署后的实际步态观察与下一步演进思路

6.1 真机步态质量：观察项与量化指标

跑通之后，我在真机上采集了几组步态数据，用来评估策略的实际表现。重点观察的指标包括：躯干横滚角的峰值、俯仰角的均值、步频一致性、脚掌离地高度、以及整机前进速度的波动情况。

从实测来看，经过延迟随机化和域随机化训练的策略，在平整桌面上行走的速度峰值能到0.1m/s，单次连续稳定行走距离在3米左右。对于500g级别的微小型双足平台来说，这个数据不算亮眼，但已经足够稳定地完成直线前进、小半径转弯和基本交互动作。走得快不是这个阶段的目标，让策略在不同类型地面上都能保持稳定才是这个项目真正想验证的能力。

我还专门在几种不同的表面上做了测试：硬木桌面、短绒地毯、纸板表面。地毯和纸板的摩擦力与形变特性都和硬木桌面差别明显，策略在仿真中如果做了摩擦随机化训练，在这几种表面上的表现会比较接近。没有做随机化的对照组，上地毯后步频明显下降，甚至出现拖脚的情况。这一组对照很直观地说明了"仿真随机化不是锦上添花，而是真机可用的前置条件"。

6.2 开源架构还能怎么扩展

这个项目目前的架构留了几个可以继续深入的扩展点：

第一，可以把鸭头部分升级成带摄像头模块的版本。鸭头内部本身有两个自由度，装上摄像头后可以让机器人做视觉目标识别和追踪，头部转动为策略增加了两个观测维度。这样一来，从单纯的"行走策略"就自然进化成了"感知-决策-运动"的闭环系统，很适合作为教学项目或二次开发的起点。

第二，强化学习算法还有升级空间。我目前主要用的是PPO和SAC的对比实验，代码仓库里还保留了基于模型的强化学习（MBRL）和离线强化学习（如IQL）的接口。对于"后期想要低成本积累数据再做微调"的场景，离线强化学习其实更有价值——从真机历史数据里直接学到更鲁棒的策略，不需要再回仿真去训练。

第三，在部署层可以进一步引入因果推断的思想。比如把IMU观测中的几个关键变量（横滚角、横滚角速度）单独提取出来，作为因果干预的对象，在策略输出端做有条件的修正。这个方向虽然还在实验阶段，但对于"抗外力扰动"这类问题，会比单纯的端到端策略更可控。

我在实际使用中的体会是，这类微小型平台最可贵的部分不是它能走多快或者多稳，而是它把"硬件、仿真、算法、部署"这一整条链路压缩到了一个几乎每个人都能负担得起的规模和成本里。任何一个人拿到这套开源架构，也都能在同一个起跑线上开始自己的实验——这才是它比一个演示视频或一篇论文更值得传播的地方。如果未来能在现有基础上把真机数据自动回流进训练管线，让"真实环境数据"和"仿真训练"形成闭环，这个项目就真的变成了一只自己会学习走路的鸭子了。