Files

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

4.9 KiB

Raw Blame History

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

背景

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

保持 flyshot 离散校验中的 vel/acc/jerk 全部生效。
临时只对 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 完全合规”，而是明确区分：

jerk 仍然继续计算和导出
jerk 仍然可作为诊断指标
但对当前 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 与旧抓包主段的剩余时长差异已经很小
当前判断：这点差异可以忽略

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

4.9 KiB Raw Blame History Unescape Escape