现象
Go2 EDU 在户外自主运行途中，运控侧突然停止响应，而机载运算板（Jetson，192.168.123.18）一切正常。
狗保持站立僵在原地，遥控器全通路失灵（包括摇杆），最后只能断电重启才恢复。
最关键的证据是一个时间戳冻结：从某一刻起，unitree_slam 日志里"当前 odom 与 lidar 时间差"
以每秒 1 秒的速度线性拉大，也就是说 odom 的时间戳停止推进了，而雷达时间戳照常走。
这是 80 次记录中的第 1 次，很罕见，但后果严重：它持续期间，操作员没有任何手段能指挥狗。
环境
| 项 |
值 |
| 机器人 |
Go2 EDU |
| 运算板 |
Jetson，L4T R35（REVISION 3.1），内核 5.10.104-tegra |
| SDK |
unitree_sdk2 2.0.0（C++），跑在 EDU 运算板上 |
| 在用的官方模块 |
/unitree/module/unitree_slam（重定位 + gridmap）、避障服务 |
| 我方程序 |
路点导航。速度指令经由避障模块下发：ObstaclesAvoidClient::SwitchSet(true) + UseRemoteCommandFromApi(true)，随后以约 10 Hz 调用 ObstaclesAvoidClient::Move()。位姿取自 unitree_slam 的重定位输出 |
| 故障时已开机时长 |
约 2 小时 06 分；当天此前还跑过一轮约 18 分钟的任务 |
时间线（同一轮，本地时间）
| 时刻 |
事件 |
| 12:57:44 |
重定位收敛，自主任务开始 |
| 12:57:44 – 13:01:17 |
一切正常。位姿流稳定在约 10 Hz，2149 个样本中最大间隔仅 0.22 秒。避障模块一直在正常整形速度（故障前一刻还在发 −0.19 m/s） |
| 13:01:17.437 |
位姿流戛然而止 —— 不是逐渐变差，之前没有任何间隔异常，之后一个样本都没有 |
| 13:01:18 – 13:02:41+ |
unitree_slam 仍在运行、仍在处理点云，但日志中"当前 odom 与 lidar 时间差"线性拉大：−3.1 → −7.4 → −11.6 → −15.9 → … → −84.0 秒，恰好每秒 1 秒。其规划器日志打印 stateMachine ----> pause!! |
| 13:01:28 |
我方程序等待位姿超时（10 秒）后干净地中止任务，并交还指令源：UseRemoteCommandFromApi(false) 返回 0（成功） |
| 13:01:28 – 13:03 |
狗原地站立不动。遥控器完全没有反应——按键没用，摇杆也没用。 运算板上的取图服务仍在正常出帧 |
| 约 13:03 |
操作员断电重启；13:03:39 完成开机，之后一切正常 |
官方模块日志摘录（/unitree/module/unitree_slam/bin/logs/gridmap/INFO_*.log）：
13:01:16 ---> 当前odom与lidar时间差：-0.106 <- 正常，整轮都稳定在这个量级
13:01:20 ---> 当前odom与lidar时间差：-3.102
13:01:24 ---> 当前odom与lidar时间差：-7.399
13:01:29 ---> 当前odom与lidar时间差：-11.601
...
13:02:41 ---> 当前odom与lidar时间差：-84.006
13:01:59 ----------------> stateMachine ----------------> pause!!
已经排除的
- 不是我方程序占着指令源。 13:01:28 已成功交还（
UseRemoteCommandFromApi(false) → 0），
交还之后遥控器依然无效。
- 不是运算板的问题。
/var/log/kern.log 与 /var/log/syslog（由 rsyslog 落盘，跨重启保留）
在 13:00–13:09 之间什么都没有：无 OOM、无内核 panic、无欠压、无过热、无服务崩溃。
温度传感器读数约 54 °C。
- 不是雷达或 SLAM 的问题。
unitree_slam 全程在运行、在处理点云；正是它报告了 odom 时钟冻结。
- 不是常发故障。 80 次有记录的运行中仅出现 1 次。
运控侧本身我们无从检查：它不往运算板写日志，我们也不知道有什么办法事后取出它的日志。
想请教几个问题
- 是否存在已知故障模式：运控侧停止发布里程计、同时不再接受遥控器输入，且只能靠断电恢复？
- 运控板是否保留有可以事后导出的日志？ 如果有，怎么取？
（这是我们最大的障碍——对那一侧完全没有可见性。）
- 有没有办法在不断电的前提下检测并恢复这个状态？比如看门狗、服务重启接口，
或者某个能反映该状态的状态字段？
- 在该状态下，硬件阻尼急停（
L2+B）是否仍然有效？我们希望有一个既不依赖我方程序、
也不依赖运算板的可靠停车手段。
- 长时间使用避障模块并保持
UseRemoteCommandFromApi(true)（连续数小时、约 10 Hz 调用 Move()），
是否可能与此有关？
如果复现，我们会记录什么
我方已经加上：每分钟一条健康记录（电量 SoC、rt/lowstate 频率、位姿年龄）、
rt/lowstate 静默 3 秒即中止任务的看门狗、以及一份断电前必须执行的检查清单
（记录运控板在内网是否还应答）。如果对排查有帮助，原始日志（轨迹 CSV、事件 JSONL、
官方模块日志）都可以提供。
English TL;DR: On a Go2 EDU, the motion-control side stopped publishing odom and stopped
accepting any remote input mid-run (odom timestamps froze — the vendor SLAM log shows the
odom-vs-lidar time delta growing at exactly 1 s/s), while the Jetson compute board stayed
fully healthy (clean kern.log/syslog). The robot froze standing; only a power cycle recovered
it. Once in 80 runs. Questions: known failure mode? Are motion-control-side logs retrievable?
Any non-power-cycle detection/recovery? Does the L2+B damping stop still work in that state?
现象
Go2 EDU 在户外自主运行途中，运控侧突然停止响应，而机载运算板（Jetson，
192.168.123.18）一切正常。狗保持站立僵在原地，遥控器全通路失灵（包括摇杆），最后只能断电重启才恢复。
最关键的证据是一个时间戳冻结：从某一刻起，
unitree_slam日志里"当前 odom 与 lidar 时间差"以每秒 1 秒的速度线性拉大，也就是说 odom 的时间戳停止推进了，而雷达时间戳照常走。
这是 80 次记录中的第 1 次，很罕见，但后果严重：它持续期间，操作员没有任何手段能指挥狗。
环境
5.10.104-tegraunitree_sdk22.0.0（C++），跑在 EDU 运算板上/unitree/module/unitree_slam（重定位 + gridmap）、避障服务ObstaclesAvoidClient::SwitchSet(true)+UseRemoteCommandFromApi(true)，随后以约 10 Hz 调用ObstaclesAvoidClient::Move()。位姿取自unitree_slam的重定位输出时间线（同一轮，本地时间）
unitree_slam仍在运行、仍在处理点云，但日志中"当前 odom 与 lidar 时间差"线性拉大：−3.1 → −7.4 → −11.6 → −15.9 → … → −84.0 秒，恰好每秒 1 秒。其规划器日志打印stateMachine ----> pause!!UseRemoteCommandFromApi(false)返回 0（成功）官方模块日志摘录（
/unitree/module/unitree_slam/bin/logs/gridmap/INFO_*.log）：已经排除的
UseRemoteCommandFromApi(false)→0），交还之后遥控器依然无效。
/var/log/kern.log与/var/log/syslog（由 rsyslog 落盘，跨重启保留）在 13:00–13:09 之间什么都没有：无 OOM、无内核 panic、无欠压、无过热、无服务崩溃。
温度传感器读数约 54 °C。
unitree_slam全程在运行、在处理点云；正是它报告了 odom 时钟冻结。运控侧本身我们无从检查：它不往运算板写日志，我们也不知道有什么办法事后取出它的日志。
想请教几个问题
（这是我们最大的障碍——对那一侧完全没有可见性。）
或者某个能反映该状态的状态字段？
L2+B）是否仍然有效？我们希望有一个既不依赖我方程序、也不依赖运算板的可靠停车手段。
UseRemoteCommandFromApi(true)（连续数小时、约 10 Hz 调用Move()），是否可能与此有关？
如果复现，我们会记录什么
我方已经加上：每分钟一条健康记录（电量 SoC、
rt/lowstate频率、位姿年龄）、rt/lowstate静默 3 秒即中止任务的看门狗、以及一份断电前必须执行的检查清单（记录运控板在内网是否还应答）。如果对排查有帮助，原始日志（轨迹 CSV、事件 JSONL、
官方模块日志）都可以提供。
English TL;DR: On a Go2 EDU, the motion-control side stopped publishing odom and stopped
accepting any remote input mid-run (odom timestamps froze — the vendor SLAM log shows the
odom-vs-lidar time delta growing at exactly 1 s/s), while the Jetson compute board stayed
fully healthy (clean kern.log/syslog). The robot froze standing; only a power cycle recovered
it. Once in 80 runs. Questions: known failure mode? Are motion-control-side logs retrievable?
Any non-power-cycle detection/recovery? Does the L2+B damping stop still work in that state?