Files
FlyShotHost/docs/uttc-ms11-jerk-validation-decision-20260511.md
yunxiao.zhu d82128da4a feat(config): 更新 RobotConfig.json 以支持运行时速度倍率配置
* 在 RobotConfig.json 中新增 speed_ratio 配置,允许在运行时设置默认速度倍率。
* 调整 ControllerClientCompatService 以使用 speed_ratio 初始化机器人设置。
* 更新 TrajectoryLimitValidator 和 FlyshotExecutionSendSequenceBuilder,支持在飞拍链路中临时关闭 jerk 校验,仅保留速度和加速度约束。
* 新增文档记录对 UTTC_MS11 的 jerk 阻断策略调整,确保飞拍链路的执行效率。
* 增加单元测试以验证 speed_ratio 的加载和 jerk 校验的行为。
2026-05-11 14:44:58 +08:00

152 lines
4.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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` 与旧抓包主段的剩余时长差异已经很小
- 当前判断:这点差异可以忽略
后续除非现场再次提供新的反证,否则本结论作为当前项目实现与验收的记录保留。