robotctl monitor

robotctl monitor
robotctl monitor --json --hz 50 > run.jsonl

整套工具里信息量最大的一个。它把客户端请求了什么和实际执行了什么并排显示，并在两者不同时说明原因。

「原因」才是关键

安全机制会持续钳制指令。「摇杆推到底但机器人不动」在没有原因说明时无法解读——你不知道该怀疑手柄、策略还是电机。它会直接写出来：

deadman — no intent arrived recently, velocity zeroed

限制是被说明的，不只是被命名的。

画面上有什么

• 每个关节的测量值对比指令值
• IMU 的投影重力，以及由它得出的跌倒判定。站立时约为 [0, 0, -1]
• 实际达成的循环频率，以轨迹形式呈现——所以一次已经恢复的卡顿仍然看得见
• 底部边框：当前加载的策略文件

底部边框那条特别重要：walk 是一个模式名，两个步态完全不同的发布版都会报告成 walk。

右侧的机器人视图

用测量到的关节角度和 IMU 重力向量把机器人画出来，用的是训练策略时同一个视觉模型。

一条腿反向折叠、头栽进地板、鸭子侧躺，在关节数值表里都只是数字，在这个视图里一眼就能看出来。终端宽度约 110 列以上时自动出现。

ToF 有数据时，它看到的点会画进同一个场景并与机器人自身做深度遮挡——这让「它是在看我的手还是在看自己」变得可回答。

快捷键

键	作用
q	退出
↑ ↓	滚动关节列表
u	角度在度与弧度间切换
t	打开 ToF 矩阵
d	开关机器人视图
[ ]	旋转视图
p	手柄原始输入流

p 打开的手柄流是唯一能看见「无线电卡住」的地方——链路保持连接、机器人拿着过期指令继续走的那种故障。

重定向时行为不同

管道或重定向时它改为每 tick 打印一行，所以 > run.log 和 | grep FALLEN 都能正常工作。这些数字始终是弧度，与屏幕设置无关。