# UTTC_MS11 跳过 flyshot jerk 阻断的结论记录

## 背景

2026-05-11 对 `UTTC_MS11` 做了两轮独立 `ConfigRoot` 重新生成与对比：

1. 保持 flyshot 离散校验中的 `vel/acc/jerk` 全部生效。
2. 临时只对 flyshot 链路跳过 `jerk` 阻断，仍保留速度与加速度校验。

两轮都使用当前程序重新生成：

- `POST /set_speedRatio/`
- `POST /save_traj_info/`

并与以下旧抓包侧结果做对比：

- `../Rvbust/uttc-20260428/2026042802-1_joint_segments/segment_02/JointDetialTraj.txt`
- `../Rvbust/uttc-20260428/2026042802-0.5_joint_segments/segment_02/JointDetialTraj.txt`
- `../Rvbust/uttc-20260428/1倍速度 角度坐标点/真实轨迹JointDetialTraj.txt`

## 直接结论

对当前 `UTTC_MS11` 现场样本，flyshot 链路若继续用离散 `jerk` 作为阻断条件，会触发大量时间轴 stretch，使新结果远慢于旧抓包。

当 flyshot 链路只保留速度、加速度校验并跳过 `jerk` 阻断后：

- 新 `1.0x` 实发时长从 `16.576s` 回落到 `7.552s`
- 新 `0.5x` 实发时长从 `33.152s` 回落到 `15.104s`
- 与旧抓包主运动段相比，只剩很小的时长差异，可接受并忽略

因此，当前项目对 `UTTC_MS11` 的实际结论定为：

- flyshot 链路临时不再把离散 `jerk` 作为阻断条件
- 仍保留速度、加速度校验
- `jerk` 诊断文件继续保留，用于分析，不再作为该路径是否可运行的唯一否决条件

## 证据

### 1. 开启 jerk 阻断时的现象

重新生成结果目录：

- `../temp/regen-20260511-110950/`

关键结果：

- `1.0x ActualSendTiming.txt`：`2073` 行，`send_duration=16.576s`
- `0.5x ActualSendTiming.txt`：`4145` 行，`send_duration=33.152s`

对比旧抓包主段：

- 旧 `1.0x`：`7.408109s`
- 旧 `0.5x`：`14.808342s`

可见新结果明显被拉长。

### 2. 触发 stretch 的第一条失败证据

日志文件：

- `../temp/regen-20260511-110950/host.log`

第一条离散失败不是加速度，而是开头窗口的 `Joint1 Jerk`：

- `轨迹 UTTC_MS11 第 3 行 Joint1 Jerk超限`
- `time=0.008000->0.016000s`
- `actual=-1732.421875`
- `limit=91.698044`
- `ratio=18.8927`

后续 `CreateLimitCompliantDenseTrajectory(...)` 按 `1.01` 倍持续拉长时间轴，直到通过离散校验，最终把总时长推到约 `16.57s`。

### 3. 只跳过 flyshot jerk 阻断后的结果

重新生成结果目录：

- `../temp/regen-nojerk-20260511-113258/`

关键结果：

- `1.0x ActualSendTiming.txt`：`945` 行，`send_duration=7.552s`
- `0.5x ActualSendTiming.txt`：`1889` 行，`send_duration=15.104s`

与旧抓包主段对比：

| 项目 | 旧抓包时长 | 新结果时长 | 差值 |
| --- | ---: | ---: | ---: |
| `1.0x` | `7.408109s` | `7.552s` | `0.143891s` |
| `0.5x` | `14.808342s` | `15.104s` | `0.295658s` |

该差异已经很小，当前按“可忽略”处理。

## 轨迹误差变化

在同一套对比脚本口径下：

### 开启 jerk 阻断时

- `JointDetialTraj` 新 vs 旧真实轨迹：全局 RMS 约 `46.664 deg`
- `ActualSendJointTraj 1.0x` 新 vs 旧抓包：全局 RMS 约 `46.665 deg`
- `ActualSendJointTraj 0.5x` 新 vs 旧抓包：全局 RMS 约 `46.667 deg`

### 跳过 flyshot jerk 阻断后

- `JointDetialTraj` 新 vs 旧真实轨迹：全局 RMS 约 `8.411 deg`
- `ActualSendJointTraj 1.0x` 新 vs 旧抓包：全局 RMS 约 `8.412 deg`
- `ActualSendJointTraj 0.5x` 新 vs 旧抓包：全局 RMS 约 `8.412 deg`

说明这次差异收敛主要来自去掉 flyshot jerk 阻断后的 stretch，而不是 `speed_ratio` 链路本身被重新设计。

## 对 jerk 的解释

这次调整不等于“现场 jerk 完全合规”，而是明确区分：

1. `jerk` 仍然继续计算和导出
2. `jerk` 仍然可作为诊断指标
3. 但对当前 `UTTC_MS11` flyshot 现场样本，不再把 `jerk` 作为阻断执行的唯一判据

重新生成后的分析文件仍显示：

- 加速度 ratio 明显在限值内
- `jerk` ratio 依然可能大于 `1`

这与旧抓包整理结果的观察一致：当前现场样本里，“加速度合规但跃度超限”是可接受现象，不能单凭 jerk 超限就否决 flyshot 轨迹。

## 当前代码决策范围

本次代码调整范围刻意收窄为：

- 只对 flyshot 链路关闭 `jerk` 阻断
- 保留 flyshot 的速度、加速度校验
- 不修改 `move_joint` 的 jerk 约束逻辑

对应入口包括：

- `ControllerClientTrajectoryOrchestrator.CreateLimitCompliantDenseTrajectory(...)`
- `FlyshotExecutionSendSequenceBuilder.Build(...)`
- `FlyshotTrajectoryArtifactWriter.WriteActualSendArtifacts(...)`

`move_joint` 仍保持原先的 jerk 受限实现，不共享这次豁免策略。

## 当前验收判断

对 `UTTC_MS11`：

- 只保留 flyshot 速度/加速度校验
- 跳过 flyshot jerk 阻断
- 新 `1.0x / 0.5x` 与旧抓包主段的剩余时长差异已经很小
- 当前判断：这点差异可以忽略

后续除非现场再次提供新的反证，否则本结论作为当前项目实现与验收的记录保留。