目录引一、那个让开发者抓狂的瞬间二、物理架构指令到底去哪了三、架构第一关输入源仲裁四、架构第二关McAction 状态机五、架构第三关拒绝码REASON六、排查清单从架构视角看问题引先扔一张脑图看看启元T1的控制架构到底分了哪几层。很多开发者觉得指令发过去机器人就该动其实这中间隔了好几道“安检”。下发速度指令来源合法吗? 优先级够吗? 心跳还在吗?当前状态允许走吗? 姿态稳吗?不通过: 静默丢弃不通过: 返回 REASON 拒绝码开发者代码 / 大脑板FastDDS 通信层运控板 MC 控制中枢第一道关: 输入源仲裁第二道关: McAction 状态机第三道关: 指令解析与下发HAL 硬件抽象层底层关节伺服控制指令被拦截一、那个让开发者抓狂的瞬间你写了段代码调用启元T1的走跑接口发了一条“向前移动”。返回值是成功的日志干干净净。但机器人纹丝不动。你查了网络没问题。ros2 node list能看到你的节点ros2 topic hz显示数据在稳定输出。甚至你确认了McLocomotionVelocity确实打到了/aima/mc/locomotion/velocity上。T1就是不动。这不是Bug。这是启元T1的控制架构在“合法地”忽略你。启元的SDK里有个aimdk_msgs包里面定义了各种接口。走跑控制属于底层运动控制mc层。在这个架构里指令发出去只是第一步能不能被执行得看运控板上的控制中枢给不给过。二、物理架构指令到底去哪了要看懂这个问题得先看看启元T1的物理架构。它不是一块板子跑到底的而是双板设计。你的代码跑在大脑板上它通过 FastDDS 把指令发给了运控板。运控板收到指令后不是立刻让电机转而是得先过几道关。三、架构第一关输入源仲裁试想一下如果遥控器、App、你的代码同时发送“向前走”的指令机器人听谁的为了解决这个冲突启元在运控架构里设计了一套输入源仲裁机制。这套机制遵循三条硬规则这里的架构设计很有意思。优先级不是一个连续值而是分段抢占的。100 - 80系统级如急停、底层保护。79 - 60高级控制如工业遥控器、App。59 - 40中级控制语音、手势。39 - 20SDK 二次开发。也就是你写的代码。19 - 0备用/研发调试。当你发指令时如果系统的遥控器正握着控制权你的指令优先级不够架构层会直接静默丢弃它不报错。更坑的是如果你在发一次指令后1000ms 内没发下一次心跳断了看门狗机制触发控制权自动释放机器人就停住了。四、架构第二关McAction 状态机假设你现在抢到了控制权指令成功度过了第一关。第二关是状态机校验。启元底层有一个叫McAction的状态机。这个状态机定义了机器人的 18 种运动状态并且规定了极其严格的跳转逻辑。初始化任意状态可达位控站立唯一出口走跑模式停止行走全身动作动作结束自动切回二开上肢控制退出PASSIVEDAMPINGSTANDWALKMIMICCUSTOM_UPPER为什么要做这么复杂的状态机架构为了防呆。如果机器人现在是PASSIVE零力矩急停状态你直接发走跑指令它不仅不会走还可能直接摔了。架构上强制要求你先切到STAND位控站立等站稳了状态变成RUNNING才能切到WALK走跑模式。也就是说你的代码发完指令后不能当甩手掌柜必须得用GetMcAction去轮询确认底层状态真的完成了跳转再发下一步的动作。很多开发者不查状态直接发指令就被状态机拦截了。五、架构第三关拒绝码REASON如果状态机校验没通过或者遇到了别的问题架构底层会返回一个拒绝码。这套拒绝码有 30 个枚举值基本覆盖了所有可能出问题的情况。这些拒绝码在CommonState.reason字段里返回。从架构角度看它们分了四个大类环境安全类前方有障碍物、低电量限制、正在充电中。形态模式类当前形态不支持、机器人需要处于双足站立状态。任务调度类其他任务正在运行、机器人已经是目标状态。配置资源类动作不在白名单、无可用技能列表。你的代码得去解析这个reason判断是重新发、等一等、还是直接放弃。不解析这个字段你永远不知道指令到底是被谁拦下的。六、排查清单从架构视角看问题所以当你的 T1 “假装听不见”时别去查网络延迟也别去怀疑 FastDDS 丢包。这套架构的防呆设计决定了得按下面的顺序排雷这套控制架构看起来有点繁琐但在实际部署里是必须的。大脑板上的模型可以随便崩但运控板上的状态机和仲裁机制必须能兜底。有了这套分层防呆机制才能保证无论上面的代码怎么写底层电机都不会乱转。这大概就是控制架构里“防呆”的另一面它防住了不安全的动作但也要求开发者必须遵守它的规则去查状态、去解析返回码。启元机器人开发者社区https://dev.primebot.com/