docs: expand deployment logging guidance

四足机器狗训练到实机部署全流程指南.md

@@ -857,6 +857,8 @@ pgrep -fl 'keep_sport_alive|Legged_sport|appTransit'
 
 运行 ONNX/BPU 推理并记录 action，仍不发送电机命令。检查 action 无 NaN/Inf、无持续饱和、静止状态不发散，ONNX 和 BPU 的动作差在离线验收范围内。
 
+从这一级开始，命令必须显式保留 `--log-dir logs`；只要要判断板端实时性，就同时加 `--log-timing`。日志目录会在启动时自动创建，终端退出时会打印 `Log saved:` 路径。
+
 X5 示例：
 
 ```bash
@@ -866,7 +868,8 @@ python3 deploy_45dim_rl_gym/bpu_deploy_x5/deploy_go1_robotlab_bpu_x5_fastcpp.py
   --infer-check \
   --log-dir logs \
   --print-every 50 \
-  --max-steps 500
+  --max-steps 500 \
+  --log-timing
 ```
 
 S100 示例：
@@ -878,7 +881,8 @@ python3 deploy_45dim_rl_gym/bpu_deploy_s100/deploy_go1_robotlab_bpu_s100_fastcpp
   --infer-check \
   --log-dir logs \
   --print-every 50 \
-  --max-steps 500
+  --max-steps 500 \
+  --log-timing
 ```
 
 ### 14.5 第 4 级：悬空状态机，不启用 RL
@@ -914,6 +918,8 @@ IDLE -> CALIBRATE -> HOLD -> OBS_TEST -> INFER_TEST
 
 先用已经通过地面测试的 ONNX 版本确定基线，再在相同软件保护、相同指令、相同场地上测试 BPU。两次测试只替换推理后端。若 BPU 行为异常，回到离线输入逐帧对比，不能通过放宽关节或姿态保护继续测试。
 
+对照日志至少要能证明三件事：同一段动作里 `commands` 接近一致，`action_raw/action_safe/joint_targets` 的差异在离线验收范围内，`policy_ms/loop_dt_ms/state_age_ms` 没有让 BPU 版本比 ONNX 版本产生额外控制延迟。若 BPU 端 `policy_ms` 很低但 `loop_dt_ms` 仍不稳，应继续查 SDK 收包、构包和系统调度，而不是只看 BPU 占用率。
+
 ### 14.10 第 9 级：坡面、台阶和扰动
 
 复杂地形是最后阶段。先从低难度、低速度和正向通过开始，再逐步测试侧向、反向、急停和摩擦变化。每次增加难度前必须确认前一级多次可复现。
@@ -927,20 +933,54 @@ metadata.json
 steps.jsonl
 ```
 
-元数据应包含 Git commit、模型哈希、推理后端、控制周期、PD 参数、动作限制、保护阈值、设备型号、测试人员和场景。逐步日志至少包含：
+部署脚本默认在 `--log-dir` 下创建带时间戳的目录，例如：
 
 ```text
-timestamp / state / state_reason
+logs/robotlab_go1_deploy_YYYYMMDD_HHMMSS/
-commands_raw / commands
+```
-obs_single / obs_history
+
+不要关闭日志来“省性能”。实机调试阶段宁可降低打印频率，也要保留 JSONL 日志；后续量化校准、ONNX/BPU 对齐、力矩保护分析和动作异常定位都依赖这些记录。
+
+`metadata.json` 用来复现实验条件。当前部署脚本会自动写入：
+
+```text
+created_at
+num_obs / history_len / onnx_input_dim
+action_scale / default_dof_pos
+joint_names_sdk / joint_names_policy / joint_order_policy
+lowcmd_backend 或 BPU backend
+history_expected_span_ms
+命令行传入的所有标量参数
+```
+
+发布或多人复现实验时，还应额外记录 Git commit、模型哈希、板端系统版本、BPU runtime 版本、设备型号、测试人员和场景。只给一条 `Log saved:` 路径而没有对应模型与参数，后续无法判断问题来自策略、量化、SDK 还是现场操作。
+
+`steps.jsonl` 是逐周期日志。当前脚本每条记录至少包含：
+
+```text
+step / time_wall / mode / state_reason
+commands_raw / commands / rc_lx / rc_ly / rc_rx / rc_ry / rc_buttons
+obs_single / history_fill / history_zero_pad
 action_raw / action_safe
 joint_targets
-dof_pos / dof_vel / tau_est
+dof_pos / dof_vel / tau_est / motor_mode / motor_temperature / motor_reserve
-base_ang_vel / projected_gravity / imu_rpy
+imu_rpy_deg / imu_quat / base_ang_vel / projected_gravity
-inference_ms / loop_ms
+battery_soc
-battery / temperature / communication_status
+loop_dt_ms / recv_ms / policy_ms / work_ms / state_fresh / state_age_ms
 ```
 
+这些字段的用途：
+
+- `mode` 和 `state_reason`：判断处于 `MONITOR`、`OBS_CHECK`、`INFER_CHECK`、`RAMP`、`RL` 还是故障/阻尼路径；保护触发时首先看这里。
+- `commands_raw` 和 `commands`：区分遥控器原始输入、deadzone/比例/交换后的策略输入，避免把遥控映射问题误判成模型问题。
+- `obs_single`、`history_fill`、`history_zero_pad`：检查 45 维观测和历史缓存是否正确预热；刚进 RL 时历史未填满属于高风险段。
+- `action_raw` 和 `action_safe`：区分模型原始输出与 clip、smooth、trip 检查后的实际动作；若二者差异大，说明部署端限制正在影响行为。
+- `joint_targets`、`dof_pos`、`dof_vel`、`tau_est`：分析目标角、实际角、速度和力矩保护之间的因果关系。
+- `motor_mode`、`motor_reserve`、`motor_temperature`：定位电机是否掉出 servo、是否有错误码或过热。
+- `loop_dt_ms`、`recv_ms`、`policy_ms`、`work_ms`、`state_age_ms`：判断慢在推理、收包、构包发送还是系统调度。
+
+分析日志时不要只看最后一帧。应从 `state_reason` 第一次不为 `ok`、`action_safe` 第一次明显被 clip、`motor_mode` 第一次异常、`tau_est` 第一次接近阈值、`loop_dt_ms` 第一次超过 20 ms 的位置向前回看至少 1 到 2 秒。
+
 一次测试通过的最低条件：
 
 - 无 NaN/Inf、状态超时和控制周期持续超期。