2026 机器人工程实例（四）：让 G1 / T800 在 MuJoCo 中真正走起来——预训练步态、定点行走与受控停止

GSYY0510

206人浏览 · 2026-09-09 19:17:36

GSYY0510 · 2026-09-09 19:17:36 发布

系列： 2026 机器人工程实例
环境： Windows 11、WSL2 / WSLg、Ubuntu 26.04、Python 3.12、MuJoCo 3.3.6
机器人： Unitree G1、EngineAI T800
项目名称： 04-humanoid-locomotion
完整代码： zephastra/robotics：04-humanoid-locomotion
关键词： 人形机器人、Unitree G1、EngineAI T800、MuJoCo、强化学习、预训练步态、运动控制

前言

让一个机器人模型出现在仿真器中并不困难。真正困难的是让它在重力和地面接触存在的情况下保持平衡，并通过关节力矩完成前进、后退、转向、定点到达和受控停止。

如果只是修改模型根节点坐标，机器人也能从 A 点“移动”到 B 点，但这并不是行走。一个更可信的仿真至少应该形成下面这条链路：

任务目标或人工速度指令
        ↓
预训练步态策略推理
        ↓
各关节目标位置
        ↓
PD 关节力矩
        ↓
MuJoCo 动力学与足底接触
        ↓
机器人实际位姿变化

本次工程把 Unitree G1 和 EngineAI T800 接入同一套控制、交互和验证框架，但两种机器人仍然加载各自的模型、关节映射和预训练策略。项目实现了自动路线、动态位置保持、手动控制、受控取消、有限推力实验、跌倒检测以及逐次报告。

需要先说明：这个项目使用 MuJoCo 和 Python，不依赖 ROS 2 或 Gazebo。因此从本篇开始，系列名称由“ROS 2 Lyrical 工程实例”扩展为“机器人工程实例”。

一、工程四是做什么的？

工程四是一个独立的人形机器人运动控制与验证项目。它分别加载 Unitree G1 和 EngineAI T800 的官方模型及对应预训练步态，在 MuJoCo 中通过关节力矩和足底接触完成行走；上层控制器可以发送机体坐标系下的前向、侧向和转向速度，也可以根据目标点反馈生成速度指令，让机器人依次到达指定位置并连续保持。系统还提供手动控制面板、输入超时保护、平滑减速、取消停车验收、外力扰动和跌倒检测，并为每次运行保存 JSON 报告、CSV 轨迹和结果图。

它不是模型展示器，也不是把关节关键帧按时间播放一遍。机器人在运行过程中必须持续根据自身状态和速度指令推理动作，并由物理引擎决定是否能够保持平衡。

二、为什么同时支持 G1 和 T800？

G1 和 T800 都是人形机器人，但它们不是可以互换皮肤的同一套模型。

项目	Unitree G1	EngineAI T800
模型	12 个腿部活动关节，上身固定	25 关节串联模型
策略动作	12 维	22 维
策略输入	47 维	72 维状态 × 15 帧历史 + 3 维指令
推理框架	PyTorch	MNN
推理频率	50 Hz	100 Hz
物理与力矩更新	500 Hz	500 Hz
上游来源	Unitree RL Gym	EngineAI Native SDK

选择机器人时，程序会同时切换：

MuJoCo 模型；
预训练策略权重；
活动关节名称与顺序；
qpos、qvel 地址映射；
策略观测结构；
控制周期；
基座和足部名称；
跌倒高度阈值；
资源清单与哈希。

如果缺少 T800 资源，程序会提示执行安装命令，而不是悄悄退回 G1 模型。启动时还会检查模型自由基座、关节数量、关节顺序和力矩限制，避免错误权重驱动错误模型。

T800 在本文中指当前仓库适配的模型版本，不代表 T800 Pro，也不能代表所有商品版本。它的上肢会随步态策略参与控制，但本工程没有实现双臂抓取任务。

三、项目的三级控制架构

整个系统分为三个控制层：

任务 / 交互层
目标点反馈或人工输入
输出 [vx, vy, wz]
        ↓
步态策略层
组织机器人状态与历史观测
输出关节动作
        ↓
关节 / 物理层
PD 计算关节力矩
MuJoCo 积分动力学与接触

1. 任务与交互层

这一层只关心机器人希望怎样移动：

vx：机体前后方向速度
vy：机体左右方向速度
wz：绕竖直轴旋转速度

自动路线模式根据当前位置和目标位置产生指令；手动模式则根据控制面板上的按键状态产生指令。

2. 步态策略层

G1 的观测包含：

机体角速度；
重力在机体坐标系中的投影；
速度指令；
相对默认姿态的关节位置；
关节速度；
上一次策略动作；
步态相位。

T800 使用不同的观测定义。它保留 15 帧历史状态，再附加当前三维速度指令，形成 1083 维网络输入，并输出 22 维动作。

两套策略都不是本项目重新训练的。本项目完成的是模型与策略加载、观测适配、任务控制、人工交互、异常处理和结果验收。

3. 关节与物理层

策略输出会转换为各关节目标位置，再通过 PD 控制得到力矩：

τ = Kp × (q_target - q) - Kd × q̇

其中：

q_target：策略给出的关节目标；
q：当前关节位置；
q̇：当前关节速度；
Kp、Kd：模型对应的控制增益；
τ：最终施加到关节的力矩。

MuJoCo 根据质量、惯量、关节约束、足底接触和摩擦继续计算机器人下一时刻的状态。项目运行期间不会通过修改根部 qpos 或 qvel 帮助机器人移动、纠偏或恢复。

四、项目目录结构

04-humanoid-locomotion/
├── README.md
├── run_demo.sh                  # 统一启动入口
├── requirements.txt            # 直接依赖
├── requirements-lock.txt       # 本机完整依赖基线
├── THIRD_PARTY_NOTICES.md       # 模型、策略和许可说明
├── config/
│   ├── lab.yaml                 # 路线、限速与验收标准
│   ├── upstream_g1.yaml         # G1 策略配置
│   └── t800/                    # T800 模型与策略配置
├── src/humanoid004/
│   ├── app.py                   # 仿真、任务、报告与主循环
│   ├── core.py                  # 路线、指令滤波与跌倒判断
│   ├── policy.py                # G1 PyTorch 策略适配
│   ├── t800_policy.py           # T800 MNN 策略适配
│   ├── robots.py                # 双机器人模型与关节映射
│   └── manual_panel.py          # 独立手动控制面板
├── scripts/
│   ├── setup.sh                 # 建立独立 Python 环境并准备 G1
│   ├── setup_t800.sh            # 准备 T800 模型与策略
│   ├── doctor.sh                # 环境与资源检查
│   ├── test.sh                  # 自动化测试
│   └── batch.py                 # 批量路线、取消和推力实验
├── tests/                       # 控制、模型与图形交互测试
├── assets/                      # 固定版本模型与资源清单
├── policies/                    # 对应机器人策略权重
└── docs/                        # 架构、截图与逐次验证证据

模型、权重和配置都记录来源、固定提交与哈希。启动时会验证资源，避免文件不完整或版本发生变化后仍然使用旧测试结果。

五、克隆与安装

完整代码地址：

https://github.com/zephastra/robotics/tree/main/projects/04-humanoid-locomotion

首次克隆：

git clone https://github.com/zephastra/robotics.git
cd robotics/projects/04-humanoid-locomotion

项目使用 uv 管理自己的 Python 环境。安装 G1 所需环境与资源：

bash scripts/setup.sh
bash scripts/doctor.sh

如果还要运行 T800，再执行：

bash scripts/setup_t800.sh
bash scripts/doctor.sh --robot t800

安装脚本会建立项目自己的 .venv，不会替换系统 ROS 使用的 Python。当前本机环境约为：

Python 3.12.13
MuJoCo 3.3.6
PyTorch 2.7.1+cpu
MNN 3.6.1（T800）

首次安装需要联网下载固定版本依赖、模型和策略。本机虚拟环境约 0.9 GB，模型约 25 MB，下载缓存还会额外占用空间。资源准备完成后，日常运行不需要持续联网。

当前版本已经在作者本机 WSL2 / WSLg 环境完成验证，但跨机器全新安装复现尚未验收，因此不能保证所有电脑第一次安装都没有兼容性问题。

六、选择 G1 或 T800 运行

不指定机器人时默认运行 G1：

bash run_demo.sh

也可以明确选择：

bash run_demo.sh --robot g1
bash run_demo.sh --robot t800

选择动作发生在启动阶段。项目不支持仿真运行过程中从 G1 切换成 T800，也不会让 T800 使用 G1 的策略。

T800 手动控制界面如下图：

在这里插入图片描述

七、五种运行模式

项目提供五种模式：

模式	作用
`route`	依次到达 A、B、HOME，并在每个目标连续保持
`stand`	在初始位置附近动态保持 30 秒
`manual`	通过独立控制面板手动行走
`push`	行走期间向骨盆施加一次有限外力
`baseline`	直接测试原始速度指令下的策略表现，不做位置保持补偿

1. 自动路线

bash run_demo.sh --robot g1 --mode route
bash run_demo.sh --robot t800 --mode route

2. 动态位置保持

bash run_demo.sh --robot t800 --mode stand

3. 手动操作

bash run_demo.sh --robot t800 --mode manual

4. 有限推力实验

bash run_demo.sh \
  --robot t800 \
  --mode push \
  --push-force 30 \
  --push-duration 0.2

5. 无界面运行

bash run_demo.sh --robot t800 --headless

无界面模式不等待现实时间，可以更快地完成批量物理仿真。

八、自动路线如何从速度指令变成定点行走？

默认路线定义在 config/lab.yaml：

route:
  - {name: A, x: 3.0, y: 0.0, yaw: 0.0}
  - {name: B, x: 3.0, y: 2.0, yaw: 1.5707963267948966}
  - {name: HOME, x: 0.0, y: 0.0, yaw: 0.0}

即：

HOME (0, 0)
     ↓
A (3, 0)
     ↓
B (3, 2，朝向 90°)
     ↓
HOME (0, 0，朝向 0°)

任务层读取 MuJoCo 中的基座位置和朝向，计算目标相对机器人的距离与方向。

距离较远时，机器人先朝向目标，再向前行走：

if distance > 0.45:
    yaw_error = wrap(bearing - pose.yaw)
    vx = min(0.45, 0.7 * distance)

    if abs(yaw_error) > 0.65:
        vx = 0.0

当机器人接近目标时，再同时调节前向、侧向和目标朝向误差：

vx = clip(0.9 * forward_error, -0.15, 0.25)
vy = clip(0.9 * sideways_error, -0.15, 0.15)
wz = clip(1.2 * yaw_error, -0.5, 0.5)

这不是路径规划器，也不包含障碍物感知。它适用于当前开放平地场景：远处先转向并前进，近处再进行小范围位置修正。

九、“到达目标”为什么不能只看一瞬间？

人形机器人行走时会不断摆动。如果机器人某一帧刚好进入目标圆，就立刻认定到达，结果可能是在下一步又走出目标区域。

当前验收条件为：

position_tolerance: 0.30
yaw_tolerance_degrees: 15.0
hold_seconds: 10.0
hold_mean_speed_limit: 0.15
waypoint_timeout: 90.0

一个目标只有同时满足以下条件才会被接受：

平面位置误差不超过 0.30 m；
朝向误差不超过 15°；
连续保持在允许范围内至少 10 s；
保持期间平均平面速度不超过 0.15 m/s。

如果中途走出范围，连续保持计时会重新开始。达到目标只是一瞬间，能够稳定留在目标区域才是完整结果。

G1 的实际路线与身体倾角、平面速度记录如下：
在这里插入图片描述

T800 的同一路线结果：

在这里插入图片描述

十、为什么零速度不等于原地站稳？

向步态策略发送：

[vx, vy, wz] = [0, 0, 0]

只表示“期望速度为零”，不代表机器人一定会锁在原地。

预训练策略可能继续踏步，也可能因为状态误差产生缓慢漂移。G1 的原始零速度基线运行 30 秒后，本机记录的平面位移约为 0.710 m；T800 在相同类型测试中的漂移较小，约为 0.044 m，但仍不能把零指令解释成绝对位置保持。

因此 stand、目标到达后的保持、手动松键保持和取消后的停车验收，都增加了任务层位置反馈：

记录希望保持的 xy / yaw
          ↓
持续计算当前位置误差
          ↓
转换成小幅 vx / vy / wz
          ↓
步态策略继续保持动态平衡

这里的“站立”仍然是动态保持。脚部可以小幅移动，机器人也仍在运行平衡策略，不是固定基座或锁定模型坐标。

更重要的是，这层位置反馈直接使用 MuJoCo 仿真真值。它验证的是理想状态反馈下的位置控制逻辑，不是 SLAM、视觉定位或真实机器人状态估计的精度。

十一、手动控制为什么需要独立控制面板？

早期手动控制直接依赖终端或仿真窗口的单次按键回调，实际使用中遇到了几个问题：

按住 W 时只收到一次事件，机器人很快认为指令过期；
不同窗口的键盘焦点行为不一致；
方向键会产生 ANSI 转义序列，其中的字符可能被误识别成取消命令；
切换窗口后，程序难以判断按键是否已经松开；
图形窗口内的自定义文字接口曾造成真实桌面窗口阻塞。

最终方案使用独立的 Tk 控制窗口，明确处理：

KeyPress
KeyRelease
鼠标按钮按住与释放
窗口失去焦点
控制窗口关闭
20 ms 输入心跳
0.5 s 指令过期看门狗

操作时应该先点击 004 Controls - EngineAI T800 或 G1 控制窗口，再按住按键，而不是在终端或 MuJoCo 窗口里按 W。

按键	动作
W / S	前进 / 后退
A / D	左转 / 右转
Q / E	左侧移 / 右侧移
R / T	前进同时左转 / 右转
X 或空格	停止移动并保持当前位置
C	取消、减速并执行停车验收
P	暂停 / 继续物理仿真
F	施加一次当前设置的推力

松键、鼠标离开方向按钮或窗口失去焦点时，移动指令会被撤销，再按照加速度限制平滑减速。

输入看门狗只是应用线程中的防护。如果整个主线程被完全阻塞，它不能代替独立安全控制器，因此不能把它描述成真实硬件安全功能。

十二、指令限幅、加速度限制和输入超时

项目不会把目标速度直接交给步态策略，而是先经过 CommandFilter：

command_limits: [0.5, 0.2, 0.6]
command_acceleration: [0.4, 0.4, 0.8]
input_timeout: 0.6

分别对应：

前后速度上限：0.5 m/s
侧向速度上限：0.2 m/s
转向速度上限：0.6 rad/s

滤波器每个周期只允许指令按照给定加速度逐渐接近目标：

value += clip(
    desired - value,
    -acceleration * dt,
     acceleration * dt,
)

如果输入超过 0.6 s 没有刷新，目标自动变为零，再继续平滑减速。这样既避免突然改变速度破坏平衡，也避免旧的人工指令无限生效。

十三、取消不是立刻结束进程

如果收到取消命令后直接退出仿真，只能证明程序停止了，不能证明机器人已经安全停下。

本工程的受控取消流程为：

收到 C 或 --cancel-at
        ↓
撤销原移动目标
        ↓
按照加速度限制减速 3 秒
        ↓
记录当前位置作为保持点
        ↓
继续运行平衡与位置反馈
        ↓
连续验收 10 秒
        ↓
写入停车漂移和平均速度

如果机器人在保持阶段漂移过大或速度不合格，该次运行会记录为失败。程序不会因为速度指令已经变成零，就自动宣布停车成功。

G1 和 T800 都在仿真第 0、8、30、45 s 请求取消，当前归档结果均为 4/4 通过。

需要区分三种行为：

C：受控取消，并执行停车验收；
X 或空格：手动模式下停止移动并保持位置；
Ctrl+C 或直接关闭 MuJoCo：终止仿真，不代表完成停车验收。

受控停止依然依赖仿真真值反馈，也不等于真实机器人断电、抱闸或急停。

十四、有限推力与跌倒检测

push 模式会在指定仿真时刻向机器人骨盆施加世界坐标系下的侧向外力：

bash run_demo.sh \
  --robot g1 \
  --mode push \
  --push-force 30 \
  --push-duration 0.2

外力通过 MuJoCo 的 xfrc_applied 施加，不会修改机器人根部位置。报告同时保存：

力：N
持续时间：s
冲量：N·s
施力时间与方向
最大身体倾角
最低骨盆高度
最终状态

跌倒判断使用骨盆高度和躯干倾角：

G1 骨盆高度低于 0.45 m
或 T800 基座高度低于 0.65 m
或躯干倾角超过 60°
并持续超过 0.12 s
        ↓
FALL_DETECTED

当前归档实验中，每个力度只测试了一次：

外力，持续 0.2 s	G1	T800
10 N	完成路线	完成路线
30 N	完成路线	完成路线
60 N	完成路线	完成路线
100 N	完成路线	完成路线
150 N	完成路线	完成路线
250 N	检测到跌倒	完成路线
400 N	检测到跌倒	完成路线
800 N	检测到跌倒	检测到跌倒

这张表不能用来宣布某个机器人的“抗推极限”。机器人当时的步态相位、受力方向、施力位置和接触状态都会影响结果；每个力度只有一次样本，也不足以得出统计结论。

强外力导致失败是有效实验数据。正确做法是保留 FALL_DETECTED，而不是删除失败记录或为了全绿而放宽跌倒阈值。

十五、测试与本机实测结果

运行自动测试：

bash scripts/test.sh

当前 README 汇总记录为 53 项自动检查，其中 5 项需要图形环境。测试覆盖：

角度与坐标转换；
指令限幅、加速度和输入超时；
目标连续到达与保持速度验收；
跌倒去抖；
模型、关节与策略维度匹配；
资源哈希与项目独立性；
手动按键、鼠标释放和失焦处理；
ANSI 终端输入过滤；
Tk 图形事件与实际 MuJoCo 物理循环；
禁止再次调用导致窗口阻塞的文字叠加接口。

批量路线测试：

# G1
.venv/bin/python scripts/batch.py \
  --suite route \
  --count 20

# T800
.venv/bin/python scripts/batch.py \
  --robot t800 \
  --suite route \
  --count 20

测试会在初始 x/y ±0.04 m、朝向 ±0.08 rad 的有限范围内改变初始状态，并让每次仿真使用新进程和新场景。

当前归档结果如下：

验收项目	G1	T800
有限初始扰动路线	20/20	20/20
仿真路线用时	64.08～64.22 s	66.11～66.33 s
最终位置误差	2.34～2.54 cm	7.21～7.63 cm
带界面完整路线	`COMPLETED`	`COMPLETED`
动态保持最终误差	3.11 cm	2.40 cm
取消停车	4/4	4/4

G1 完成路线后的画面：

在这里插入图片描述

T800 完成路线后的画面：

在这里插入图片描述

这些数据来自固定模型、固定平地、有限初始变化和仿真真值反馈。它们是本机仿真验证记录，不是真实机器人成功率或定位精度承诺。

十六、运行报告记录了什么？

每次运行都会在下面的位置创建独立目录：

reports/<UTC运行编号>-<robot>-<mode>-<seed>/

主要文件包括：

report.json       # 最终状态、参数、目标验收、策略哈希和异常
trajectory.csv    # 时间、位姿、速度、倾角、指令和任务阶段
summary.png       # 实际轨迹、身体倾角与速度曲线
final-camera.png  # 开启 --snapshot 时保存的仿真画面

report.json 会明确写入：

使用的是 G1 还是 T800；
运行模式和随机种子；
初始位姿；
上游仓库、固定提交和策略哈希；
定位来源为 MuJoCo ground truth；
每个目标的到达误差和保持数据；
外力大小、持续时间与时间点；
最大倾角、最低基座高度和最终位姿；
COMPLETED、FAILED 或停车验收结果。

这样可以区分“程序运行结束”和“任务通过验收”，也能确认报告对应的是哪一个模型、哪一份策略和哪一版源代码。

十七、常见问题

1. T800 提示资源尚未安装

执行：

bash scripts/setup_t800.sh
bash scripts/doctor.sh --robot t800

程序不会在 T800 资源缺失时自动改用 G1。

2. WSL 中画面非常卡

先检查是否正在使用 llvmpipe 软件渲染。项目启动器只为当前进程选择已有的 WSL D3D12 驱动，不会修改系统驱动或登录脚本。

如果图形驱动确实不兼容，可以测试：

H004_RENDERER=software bash run_demo.sh --robot g1

软件渲染通常会明显变慢。无界面批量测试可以使用 --headless。

3. 按 W 没有反应

手动模式需要点击独立的 004 Controls 窗口，再按住 W。不要在终端或 MuJoCo 窗口中按移动键。

bash run_demo.sh --robot t800 --mode manual

如果暂停、切换焦点或者在窗口外松开按键，先回到控制窗口松开所有按键，再重新按下。

4. 机器人收到零速度仍然移动

零速度只是步态策略输入，不是位置锁。要验证位置保持，使用：

bash run_demo.sh --robot g1 --mode stand

不要把 baseline 模式的 COMPLETED 理解为零漂移，它只表示机器人没有跌倒并运行到指定时间。

5. 关闭窗口后没有停车报告

直接关闭 MuJoCo 或按 Ctrl+C 会终止仿真。需要测试受控停车时，应按控制面板中的 C，或者在自动测试中使用 --cancel-at。

6. 推力测试失败

强扰动触发 FALL_DETECTED 是有效结果，不一定是程序错误。先查看本次报告中的施力时刻、最大倾角、最低基座高度和失败原因，不要直接放宽判断阈值。

7. MNN 在新系统中加载失败

当前 T800 使用固定的 MNN==3.6.1。本机 glibc 2.43 曾拒绝加载 wheel 的可执行栈请求，安装脚本会用项目内固定版本的 patchelf 清除该标记，并保留原件与哈希。它不会开启可执行栈，也不会修改系统库。

十八、项目边界

这套工程已经能够完成较完整的人形机器人行走与验证，但边界必须写清楚：

步态策略来自 Unitree 和 EngineAI 上游，不是本项目训练的；
G1 使用固定或合并上身的 12 关节腿部模型；
T800 虽然包含更多关节，但当前没有抓取任务；
定点行走和位置保持使用 MuJoCo 仿真真值定位；
没有实现 SLAM、视觉定位、状态估计器或障碍物导航；
只验证开放平地，不包含上下楼、跑跳和复杂地形；
跌倒后不会自主起身；
没有连接机器人硬件 SDK 或网络控制通道；
仿真参数与策略不能直接部署到真实机器人；
手动输入看门狗和受控停止不是工业安全认证功能。

项目证明的是：在固定模型、预训练策略和理想仿真状态反馈下，两种人形机器人能够通过关节力矩完成指定的行走、保持、交互和失败验收。

十九、下一步可以怎样扩展？

后续可以沿着以下路线逐步增加真实度：

仿真真值定位
    ↓
IMU + 关节编码器状态估计
    ↓
视觉 / LiDAR 环境感知
    ↓
落脚与局部路径规划
    ↓
复杂地形、绕障和跌倒恢复
    ↓
仿真到实物的安全迁移

也可以继续增加操作能力：

上肢动作与步行协调；
灵巧手或夹爪；
轻物体单手取送；
双手协同搬运；
主动视觉和手眼协调；
负载变化下的步态适配。

但增加能力以前，应继续保留当前工程的原则：机器人模型、策略、状态估计、任务层和验收层必须分开描述，仿真成功不能直接改写成实物能力。

二十、总结

工程实例（四）完成了一套独立的人形机器人运动控制与验证框架。

它实现了：

Unitree G1 与 EngineAI T800 双机器人选择；
对应模型、关节映射与预训练策略的独立加载；
速度指令到策略动作、PD 力矩和物理接触的完整链路；
HOME → A → B → HOME 自动定点路线；
连续位置、朝向和保持速度验收；
动态位置保持与零速度基线对比；
独立手动控制窗口和输入超时保护；
平滑减速、受控取消与停车验收；
有限外力实验和跌倒检测；
JSON 报告、CSV 轨迹、结果图与失败证据；
G1、T800 各 20 次有限初始扰动路线测试。

这个工程最值得保留的认识是：

人形机器人“速度指令为零”“某一帧到达目标”和“程序已经退出”，都不能自动等同于站稳、到达和安全停止。

只有把目标转换、策略推理、关节力矩、地面接触、连续保持、异常检测和结果报告连成闭环，我们才真正开始验证一台人形机器人是否能够走起来、停下来，并且诚实地告诉我们它什么时候失败了。

DAMO开发者矩阵

DAMO开发者矩阵，由阿里巴巴达摩院和中国互联网协会联合发起，致力于探讨最前沿的技术趋势与应用成果，搭建高质量的交流与分享平台，推动技术创新与产业应用链接，围绕“人工智能与新型计算”构建开放共享的开发者生态。

更多推荐

一键应用 AI 修复补丁：GitHub PR 自动化交互机器人开发

DAMO开发者矩阵

机器人自治不能停在“模型给出动作”：KINETOVELA 的具身运行边界

DAMO开发者矩阵

具身智能数据工程观察：从集中式数采工厂到真实场景采集，数据供给路线正在转向

DAMO开发者矩阵

所有评论(0)

查看更多评论

GSYY0510

@GSYY0510

已为社区贡献9条内容

2026 机器人工程实例（四）：让 G1 / T800 在 MuJoCo 中真正走起来——预训练步态、定点行走与受控停止

GSYY0510

前言

一、工程四是做什么的？

二、为什么同时支持 G1 和 T800？

三、项目的三级控制架构

1. 任务与交互层

2. 步态策略层

3. 关节与物理层

四、项目目录结构

五、克隆与安装

六、选择 G1 或 T800 运行

七、五种运行模式

1. 自动路线

2. 动态位置保持

3. 手动操作

4. 有限推力实验

5. 无界面运行

八、自动路线如何从速度指令变成定点行走？

九、“到达目标”为什么不能只看一瞬间？

十、为什么零速度不等于原地站稳？

十一、手动控制为什么需要独立控制面板？

十二、指令限幅、加速度限制和输入超时

十三、取消不是立刻结束进程

十四、有限推力与跌倒检测

十五、测试与本机实测结果

十六、运行报告记录了什么？

十七、常见问题

1. T800 提示资源尚未安装

2. WSL 中画面非常卡

3. 按 W 没有反应

4. 机器人收到零速度仍然移动

5. 关闭窗口后没有停车报告

6. 推力测试失败

7. MNN 在新系统中加载失败

十八、项目边界

十九、下一步可以怎样扩展？

二十、总结

所有评论(0)

温馨提示：您尚未绑定手机号

GSYY0510