yunxiao.zhu
b1710e5d01
* 将预捕获 alpha 数据表替换为解析式 7 阶平滑点到点时间律 s(u)=35u⁴-84u⁵+70u⁶-20u⁷，形状系数按 1~3 阶导数最大值重算 * 新增离散限位校验：按真实 8ms 采样点反算速度/加速度/jerk， 不满足时自动拉长总时长后重采样，最多迭代 10000 次 * 实发轨迹落盘：ActualSendJointTraj.txt（角度制）、 ActualSendJerkStats.txt（点间跃度统计），按时间目录归档 * J519 AcceptsCommand 门控：只有机器人就绪时才发送下一帧， 减少无效下发；状态日志附带最近发送目标关节轴 * FanucControllerRuntime 构造函数改为必选 ILogger 注入， 确保 DI 解析时稳定拿到日志实例 * LegacyHttpApiController 移除已废弃的 ConnectServer 调用， EnableRobot 参数从 2 改为 4 * 新增跃度报警分析文档和六轴限值表，补充反馈远离拒绝测试 Co-authored-by: Copilot <copilot@github.com>
137 lines
6.6 KiB
Markdown
137 lines
6.6 KiB
Markdown
# MoveJoint 失败样本六轴限值与 ActualSendJerkStats 对比
|
||
|
||
记录时间：2026-05-05
|
||
|
||
## 1. 目的
|
||
|
||
本文档固定记录以下三类证据，避免后续继续混用测试基线、旧文档结论和当前运行目录中的真实模型数据：
|
||
|
||
- 当前运行目录 `.robot` 模型中的六轴基础 `velocity / acceleration / jerk`
|
||
- 当前运行目录 `RobotConfig.json` 中的 `acc_limit / jerk_limit`
|
||
- 当前失败样本 `ActualSendJerkStats.txt` 中的逐轴实发跃度峰值
|
||
|
||
本次样本对应目录：
|
||
|
||
- `.robot`：`src/Flyshot.Server.Host/bin/Debug/net8.0/Config/Models/LR_Mate_200iD_7L.robot`
|
||
- 配置：`src/Flyshot.Server.Host/bin/Debug/net8.0/Config/RobotConfig.json`
|
||
- 实发跃度：`src/Flyshot.Server.Host/bin/Debug/net8.0/Config/Data/move-joint/DenseSend/20260505_203416_563/ActualSendJerkStats.txt`
|
||
- 抓包：`src/Flyshot.Server.Host/bin/Debug/net8.0/Config/Data/move-joint/DenseSend/20260505_203416_563/移动点 跃度过大.pcap`
|
||
|
||
## 2. 当前运行模型的真实六轴限值
|
||
|
||
当前仓库运行时通过 `RobotModelLoader.LoadProfile(...)` 从 `.robot` 中读取每轴 `limit.velocity / limit.acceleration / limit.jerk`，然后只对加速度和 jerk 叠加 `RobotConfig.json` 的全局倍率：
|
||
|
||
- `velocity_eff = velocity_base`
|
||
- `acceleration_eff = acceleration_base * acc_limit`
|
||
- `jerk_eff = jerk_base * jerk_limit`
|
||
|
||
当前运行目录 `RobotConfig.json` 中：
|
||
|
||
- `acc_limit = 0.74`
|
||
- `jerk_limit = 0.74`
|
||
|
||
按当前运行目录真实模型解出的六轴基础值与生效值如下：
|
||
|
||
| Joint | vel_base | acc_base | jerk_base | vel_eff | acc_eff | jerk_eff(rad/s^3) | jerk_eff(deg/s^3) |
|
||
| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
|
||
| Joint1 | 6.45 | 26.90 | 224.22 | 6.45 | 19.9060 | 165.9228 | 9506.6762 |
|
||
| Joint2 | 5.41 | 22.54 | 187.86 | 5.41 | 16.6796 | 139.0164 | 7965.0530 |
|
||
| Joint3 | 7.15 | 29.81 | 248.46 | 7.15 | 22.0594 | 183.8604 | 10534.4249 |
|
||
| Joint4 | 9.59 | 39.99 | 333.30 | 9.59 | 29.5926 | 246.6420 | 14131.5457 |
|
||
| Joint5 | 9.51 | 39.63 | 330.27 | 9.51 | 29.3262 | 244.3998 | 14003.0771 |
|
||
| Joint6 | 17.45 | 72.72 | 606.01 | 17.45 | 53.8128 | 448.4474 | 25694.1434 |
|
||
|
||
重要结论：
|
||
|
||
- 当前运行目录中，`Joint1.jerk_base` 不是测试基线里常见的 `272.7`，而是 `224.22`。
|
||
- 因此当前样本的 `Joint1` 生效 jerk 上限应按 `224.22 * 0.74 = 165.9228 rad/s^3` 计算。
|
||
|
||
## 3. ActualSendJerkStats 的单位边界
|
||
|
||
`ActualSendJerkStats.txt` 的代码注释写的是 `rad/s^3`，但当前实现里真实输入不是弧度，而是角度：
|
||
|
||
1. `SampleDenseJointTrajectoryDegrees(...)` 先把轨迹点从 `rad` 转成 `deg`
|
||
2. `BuildDenseSendJointRow(...)` 把这组角度制关节写入 `ActualSendJointTraj.txt`
|
||
3. `BuildDenseSendJerkRow(...)` 再直接基于这组角度制关节做三阶差分
|
||
|
||
因此当前这份 `ActualSendJerkStats.txt` 的逐轴跃度应按以下方式理解：
|
||
|
||
- 文本中的数值口径：`deg/s^3`
|
||
- 若要与 `.robot` / `RobotProfile` 中的 jerk limit 比较，需要先换算为 `rad/s^3`
|
||
- 换算公式：`jerk_rad = jerk_deg * π / 180`
|
||
|
||
## 4. 全文件逐轴最大跃度对比
|
||
|
||
扫描整份 `ActualSendJerkStats.txt` 后，各轴绝对值最大跃度如下：
|
||
|
||
| Joint | peak window(s) | peak line | peak actual(deg/s^3) | peak actual(rad/s^3) | jerk_eff(rad/s^3) | peak/limit |
|
||
| --- | --- | ---: | ---: | ---: | ---: | ---: |
|
||
| Joint1 | `1.056 -> 1.064` | 133 | 21868.115990 | 381.670625 | 165.922800 | 2.3003 |
|
||
| Joint2 | `1.056 -> 1.064` | 133 | 40.271793 | 0.702875 | 139.016400 | 0.0051 |
|
||
| Joint3 | `1.056 -> 1.064` | 133 | 98.314401 | 1.715910 | 183.860400 | 0.0093 |
|
||
| Joint4 | `1.056 -> 1.064` | 133 | 0.207266 | 0.003617 | 246.642000 | 0.0000 |
|
||
| Joint5 | `1.056 -> 1.064` | 133 | 26.759688 | 0.467045 | 244.399800 | 0.0019 |
|
||
| Joint6 | `1.056 -> 1.064` | 133 | 2.328736 | 0.040644 | 448.447400 | 0.0001 |
|
||
|
||
结论非常明确：
|
||
|
||
- 全文件范围内，只有 `Joint1` 的实发跃度显著超过当前生效 jerk 上限。
|
||
- 其余 5 个轴即使取全文件峰值，也远低于各自当前生效 jerk limit。
|
||
- 当前样本本质上是一个“J1 主导”的跃度问题，而不是六轴普遍同时逼近上限。
|
||
|
||
## 5. 报警窗口逐轴对比
|
||
|
||
结合抓包与 J519 序号，报警前最后一个关键窗口是：
|
||
|
||
- `seq=41552`
|
||
- 轨迹时间窗口：`0.296 -> 0.304s`
|
||
- `ActualSendJerkStats.txt` 行号：38
|
||
|
||
该窗口逐轴跃度如下：
|
||
|
||
| Joint | alarm window jerk(deg/s^3) | alarm window jerk(rad/s^3) | jerk_eff(rad/s^3) | alarm/limit |
|
||
| --- | ---: | ---: | ---: | ---: |
|
||
| Joint1 | -20395.713579 | 355.972355 | 165.922800 | 2.1454 |
|
||
| Joint2 | -37.560252 | 0.655550 | 139.016400 | 0.0047 |
|
||
| Joint3 | 91.694793 | 1.600376 | 183.860400 | 0.0087 |
|
||
| Joint4 | -0.193310 | 0.003374 | 246.642000 | 0.0000 |
|
||
| Joint5 | 24.957931 | 0.435598 | 244.399800 | 0.0018 |
|
||
| Joint6 | 2.171939 | 0.037907 | 448.447400 | 0.0001 |
|
||
|
||
该窗口的直接结论与全局扫描一致：
|
||
|
||
- 机器人开始报警的 `0.296 -> 0.304s` 窗口里，真正越限的仍然只有 `Joint1`
|
||
- `Joint1` 在报警窗口内已经达到当前生效 jerk limit 的 `2.1454x`
|
||
- 其余 5 轴在同一窗口仍远低于生效 jerk 上限
|
||
|
||
## 6. 报警窗口与全局峰值窗口的关系
|
||
|
||
本次样本不能简单理解为“最大峰值出现的位置就是首次报警位置”。
|
||
|
||
当前证据表明：
|
||
|
||
- 首次报警相关窗口在 `0.296 -> 0.304s`
|
||
- 全文件最大的 J1 跃度峰值出现在更后面的 `1.056 -> 1.064s`
|
||
|
||
这说明至少有两件事需要分开：
|
||
|
||
1. 机器人第一次进入异常态时，`Joint1` 已经在 `0.296 -> 0.304s` 超限约 `2.15x`
|
||
2. 即便忽略第一次报警，后续轨迹中仍存在更高的 J1 跃度峰值，说明当前 `MoveJoint` 临时轨迹整体都偏激，不只是单个孤立点异常
|
||
|
||
## 7. 当前可落地的结论
|
||
|
||
基于当前运行目录的真实模型、配置和实发跃度文件，本次失败样本可以先固定为下面这组结论：
|
||
|
||
- 当前运行模型 `Joint1.jerk_base = 224.22`，不是 `272.7`
|
||
- 当前样本 `jerk_limit = 0.74`，所以 `Joint1.jerk_eff = 165.9228 rad/s^3`
|
||
- `ActualSendJerkStats.txt` 需要按 `deg/s^3` 理解，再换算成 `rad/s^3` 后与模型 jerk limit 对比
|
||
- 无论看报警窗口还是看全文件峰值，越限主体都只有 `Joint1`
|
||
- 报警窗口 `0.296 -> 0.304s` 中，`Joint1` 已经约为当前生效 jerk 上限的 `2.1454x`
|
||
- 全文件最大峰值窗口 `1.056 -> 1.064s` 中，`Joint1` 约为当前生效 jerk 上限的 `2.3003x`
|
||
|
||
因此当前最合理的根因指向仍然是：
|
||
|
||
- `MoveJoint` 临时轨迹生成得过于激进
|
||
- 当前问题首先应按 `Joint1` 的 jerk 约束失配来处理
|
||
- 暂时没有证据支持“六轴普遍一起逼近限制”或“网络链路导致跃度统计失真”这类解释
|