Public Docs
【模型量化】深度学习模型量化 & 量化理论 & 各平台的量化过程 & 硬件加速
【TVM】TI关于TVM的使用测试与分析
【LLM&LVM】大模型开源工程思维导图
SmartSip
【北航卓越工程师】《汽车前沿技术导论:智能驾驶》讲义
【工具链】Yocto使用介绍——使用Yocto创建一个树莓派的系统镜像
【工具链】使用ssh+dialog指令设定服务器指定用户仅容器访问
【推理引擎】一篇关于模型推理的详细对比与学习
【推理引擎】关于TVM中的Schedule优化详解(On going)
【LLM微调】使用litgpt进行私有数据集模型微调的测试总结
【TVM】在TVM Relay中创建一个自定义操作符
【STT+LLM+TTS】如何使用语音转文字模型+大预言模型+语音生成模型完成一个类人的语音交互机器人
【RAG】 通过RAG构建垂直领域的LLM Agent的方法探索
【RAG】GraphRAG精读与测试(On going)
【AI Agent】MetaGPT精读与学习
【AI Base】Ilya Sutskever 27篇必读论文分享清单
【Nvidia】Jetson AGX Orin/ Jetson Orin nano 硬件测试调试内容(On going)
【BI/DI】LLM Using in BI Testing Scenario (On going)
【Nvidia】How to Activate a Camera on Nvidia Platform in Details
【RAS-PI】树莓派驱动开发
【行业咨询阅读】关注实时咨询和分析
【mobileye】2024 Driving AI
【mobileye】SDS_Safety_Architecture
【yolo】yolov8测试
【nvidia】Triton server实践
【alibaba】MNN(on updating)
【OpenAI】Triton(on updating)
【CAIS】关于Compound AI Systems的思考
【Nvidia】关于Cuda+Cudnn+TensorRT推理环境
【BEV】BEVDet在各个平台上的执行效率及优化(On Updating)
【Chip】AI在芯片设计和电路设计中的应用
【Chip】ChiPFormer
【Chip】关于布线的学习
【Chip】MaskPlace论文精读与工程复现优化
【gynasium】强化学习初体验
【Cadence】X AI
【transformer】MinGPT开源工程学习
【中间件】针对apollo 10.0中关于cyberRT性能优化的深度解读和思考
【Robotics】调研了解当前机器人开发者套件(on updating)
【Robotics】ROS CON China 2024 文档技术整理与感想总结(上2024.12.7,中2024.12.8,下场外产品)
【algorithm】关于模型、数据与标注规范的平衡问题
【nvidia】DLA的学习了解与使用
【nvidia】构建nvidia嵌入式平台的交叉编译环境(其他环境平台可借鉴)
【2025AI生成式大会】2025大会个人总结
【Robotics】 Create Quadruped Robot RL FootStep Training Environment In IsaacLab
【Robotics】如何一个人较为完整的完成一个机器人系统软件算法层面的设计与开发
【VLM】读懂多模态大模型评价指标
【VLM】大模型部署的端侧部署性能与精度评估方法与分析
【Nvidia】Jetson Orin 平台VLM部署方法与指标评测
【Database】向量数据库
【SoC】性能与功耗评估
【MCP】MCP探索
【InnoFrance】一个“关于声音”的有趣项目
【Robotics】写给那些想要快速了解机器人或者具身智能的工程师们
【Robotics】open X Embodiment RT-X 数据集下载与使用和分析
【SKILLS】股票分析skill
【Robotics】当 AI + 强化学习重来时,那些"老机械结构"值得再做一遍
文档发布于【Feng's Docs】
-
+
首页
【Robotics】当 AI + 强化学习重来时,那些"老机械结构"值得再做一遍
# 0 PreTalk 最近在 IsaacLab 里折腾了一个 Stewart 平台的强化学习任务(工程见 https://github.com/FengD/StewartLab ),过程中越发觉得一个事情:`在 AI + 强化学习这一轮范式下,不少经典的机械结构其实都值得拿出来重做一遍`。  不是说结构本身要改,而是它的"控制大脑"可以换一种思路。很多机构当年受限于算力和控制理论的工程化能力,只能跑在一个相对保守、相对静态的工作模式里。而现在,把运动控制这件事交给一个基于物理模型训练出来的 policy 网络,整套设备能干的活儿、能稳的工况,可能是另一个量级。Stewart 平台就是一个很典型的例子。  ## 0.1 Stewart 平台过去主要是"测试装备的装备" Stewart 平台是个六自由度的并联机构,六根作动器(一般是液压或电动的伸缩杆)撑起一个上平台,通过六根杆的协同伸缩,实现上平台在空间中的 6-DOF 位姿运动。 `但过去它大多数时候,是用来"测试别的装备"的装备。` 典型场景就是各种振动台、运动模拟器、飞行/驾驶模拟器的底座。结构上往往是高度定制化的——为某个特定的被测对象、某个特定的振动谱去设计。它的核心使命是:在末端复现一段预设的运动或振动激励,然后让被测件在上面接受实际的振动测试。换句话说,它干的是复现和激励的活,输入是确定的、预先规划好的轨迹,平台只要忠实地"跟随"就行。 这类场景下,传统的控制方式(逆运动学解算 + 各轴 PID/前馈)足够用了,因为目标轨迹已知,扰动也相对可预测。 ## 0.2 一旦要做"主动控制",事情就复杂了 但如果我们换个目标,不让它做被动复现,而是让它做`主动控制`: * 海浪环境下的主动稳定(平台装在一个持续 6-DOF 晃动的船基/浮基上,要把上平台稳住); * 接住一个掉下来的物体并保持其平衡(上平台要根据物体的实时位姿动态调整); 这时候难度一下就上来了。如果走传统 MPC(模型预测控制)的路子,会撞到几个比较现实的墙: 1. 依赖高精度输入。MPC 的预测全靠模型,而模型的好坏又取决于状态估计的精度。海浪/船基的运动、被接物体的实时位姿和速度,这些输入一旦有噪声或者延迟,预测就开始飘; 2. 实时复杂解算。六自由度并联机构本身就是一个闭链强耦合系统,MPC 每个控制周期都要在线求解一个带约束的优化问题,要在毫秒级周期里反复解算,对算力和实现都有要求; 3. 运算周期不可控。这是工程上最难受的一点——优化求解的耗时是数据相关的,遇到病态工况或者约束边界,求解迭代次数会突然变多,单步耗时不稳定。对于一个需要硬实时闭环的运动控制系统,这种"运算不可控"是大忌。 `说白了,传统 MPC 把"难"全压在了在线解算上,而在线解算的稳定性恰恰是它最薄弱的地方。` ## 0.3 基于模型的强化学习 policy,把"难"挪到了训练阶段 强化学习的运控 policy 模型,思路正好反过来——把复杂的优化和试错放到训练阶段(离线,可以慢慢算、海量并行),而部署阶段只剩一次前向推理。 这就解决了上面最致命的第三点:`一个固定结构的 policy 网络,单次推理的耗时是稳定且可预测的`,不会因为工况变难就突然卡住。对于硬实时控制回路来说,"周期稳定"这件事本身的价值,有时候比"单步更优"还重要。 而且 policy 是在大量带噪声、带扰动的仿真工况里训练出来的,它见过的"海浪"成千上万种,对输入噪声和未建模动态的鲁棒性,往往比一个依赖精确模型的 MPC 更好。这正是它适合做海浪稳定、动态接物这类`扰动强、模型难精确`场景的原因。 `当然,这不是说 RL 就吊打 MPC`。MPC 在可解释性、约束硬保证、稳定性证明上仍然有 RL 难以替代的优势。这里更想说的是:在这一类"扰动强、模型难精确、要求推理周期稳定"的主动控制问题上,基于模型的 RL policy 提供了一个非常有竞争力的新选项。 # 1 用 IsaacLab 把场景定义出来,完成训练 光说思路没用,关键是工程上能不能跑起来。这部分就是 IsaacLab 这类工具的价值——`它让"定义一个训练场景"这件事,变成了写配置和写 reward`。 整个 StewartLab 工程基于 IsaacLab 的 direct-RL 范式,训练后端用的是 RSL-RL 的 PPO。我设计了三个递进的环境,对应上面从"测试"到"主动控制"的思路演进: | 任务 | 干什么 | | --- | --- | | | Template-Stewart-Test-Direct-v0 | 最基础的:平台把一个掉在上盘中心的椭球稳住 | | Template-Stewart-Wave-System-Direct-v0 | 进阶:平台装在一个持续运动的 6-DOF 矩形基座上(模拟海浪/船基),稳住一个掉下来的球 | | Template-Stewart-Wave-System-IMU-Direct-v0 | 同样的海浪场景,但观测里去掉了上帝视角的波浪指令位姿/速度,改用类 IMU 的根部测量 | 第三个任务专门拆出来,是因为它更接近真实部署:实际系统里你拿不到"海浪的真值指令",只能靠 IMU 这种本体传感器去感知基座运动。`这一步是把仿真往真机迁移时绕不开的一道坎`,先在仿真里把观测做得"现实一点",后面 sim2real 才不会太崩。 ## 1.1 观测与动作的设计 这部分是 RL 任务的核心,值得展开说。policy 的观测设计成 27 维: ``` 6 六根滑块关节位置 6 六根滑块关节速度 3 上平台投影重力(姿态) 3 上平台角速度 3 物体中心相对上盘中心的位置 6 上一步平滑后的动作 ``` 动作是 6 维,每根滑块一个,clip 到 [-1, 1],平滑后映射成力: ``` slider_force = action * action_scale ``` 注意这里有个工程上的选择——直接用滑块力控(effort control),而不是 PhysX 的 drive target 位控。原因下面踩坑部分会讲。 # 2 工程踩坑记录 并联机构在物理仿真里其实是个"难伺候"的对象,闭链约束让它和那些开链的机械臂、足式机器人很不一样。这里把几个关键的调试结论记一下,都是用 0.10m 滑块初始伸长量、num_envs 1024 这种配置反复试出来的。 * 闭链约束不能随便 reset。默认禁用了完整的关节状态 reset——因为 Stewart 是闭链机构,如果像开链机器人那样直接把所有关节状态重置成随机值,闭链的几何约束会被破坏掉,仿真直接崩或者出现非物理的姿态。这一点和训练四足、机械臂的习惯完全相反,踩过一次才知道; * 自碰撞要关掉。articulation self-collision disabled,并联机构六根杆在工作空间里几何关系很近,开自碰撞会引入大量无意义的接触求解,既慢又容易把训练带偏; * 用力控不用位控。前面提到的 effort control,是因为对闭链机构下 PhysX 的 drive target 位控容易和闭链约束打架,直接给力反而更稳定、更可控; * 滑块预留行程。六根滑块初始就给 0.10m 的伸长量,留出双向行程的 buffer,避免动作一开始就顶到行程边界。 另外关于 USD 资产,这是最容易出隐性问题的地方: * 上盘参考体是 UJ61,观测里用的是"物体中心相对上盘中心"的位置。如果你换了 USD、上盘原点变了,必须同步去 stewart_test_env_cfg.py 里改 platform_center_offset,否则 reward 算的是错的,训出来的 policy 看着 loss 在降,实际行为完全不对——这种 bug 最坑,因为它不报错; * 导入的 CAD/USD 资产经常会刷一堆 UsdPreviewSurface.mdl 或者 mesh collision fallback 的 warning,这些大多不影响训练,可以先忽略;但如果出现 Failed to find an articulation 这种硬报错,基本就是 USD 的 reference 路径断了,去 docs/USD_ASSET_CHECK.md 走一遍引用检查修复流程。 `PS:play 的时候默认是关掉 curriculum 的,直接用最终难度评估。如果你想看 curriculum 行为,得手动加 --use_curriculum_in_play,否则会以为模型在简单工况下表现就是它的真实水平。` # 3 一点延伸的思考 回到开头那句话。Stewart 平台只是一个切口,它代表了一大类机构:结构成熟、运动学清楚,但过去因为控制能力的天花板,只能跑在保守工作模式下的设备。 当运动控制的"大脑"从在线优化求解,换成一个推理周期稳定、对扰动鲁棒、在海量仿真工况里见过世面的 policy 网络之后,这些机构能胜任的任务边界会被重新划定。海浪稳定、动态接物、移动基座上的精密操作……这些过去 MPC 做起来又重又不稳的活,RL policy 给了一条新路。 而 IsaacLab 这类工具的意义,在于它把"重做一遍"的门槛拉低了——你不需要从零搭物理引擎、写并行环境、调 PPO,更多精力可以放在真正重要的事情上:怎么定义场景、怎么设计观测、怎么写 reward、怎么把仿真做得离真机更近一点。 `所以,这一轮 AI + RL 浪潮下,值得做的不只是新结构,还有那些老结构的"第二次生命"`。Stewart 只是个开始。 `训练完这个接球的动作,第一反应是刷到的在榴莲树下,一个人拿刀切下一个,另一个人拿网兜接榴莲的视频。这么危险的动作能把人替换了多好`   # Thanks 感谢 https://github.com/mlayek21/Stewart-Platform 提供的平台模型。让我这个完全不懂建模的人有了快速上手尝试的条件。
dingfeng
2026年6月9日 15:49
10
0 条评论
转发文档
收藏文档
上一篇
下一篇
评论
手机扫码
复制链接
手机扫一扫转发分享
复制链接
Markdown文件
PDF文档
PDF文档(打印)
分享
链接
类型
密码
更新密码