# CAN/里程计频率修改建议报告

## 1. 结论

建议采用以下组合修改，而不是单独只改一边：

1. 下位机 `FDR-Core` 将 `0x200 Odom Delta` 从当前约 `60ms` 提升到 `20ms` 固定发送。
2. 上位机 `ARES` 将 `0x200` 的消费与 `Odom_Update()` 从 `monitorTask(100ms)` 挪到 `navTask(20ms)`。
3. `0x182/0x183` 保持低频轮询即可，不需要跟着一起提到 `20ms`。
4. 当前阶段不建议把 `0x200` 进一步提到 `10ms`，先做到 `20ms` 即可。

一句话概括：当前 odom 不够实时，不是总线带宽不够，而是“下位机发送慢 + 上位机消费慢”叠加导致的；最合适的修法是把两端都对齐到 `20ms`。

## 2. 本次核对到的事实

### 2.1 下位机当前真实行为

下位机工程：`C:\Users\Falling_jasmine\CLionProjects\FDR-Core`

实际实现文件：`Core/Src/f4_can_app.c`

关键实现如下：

1. `CAN_Send_Telemetry_20ms()` 每 `20ms` 调一次。
2. `0x181` 状态帧固定每次都发。
3. `0x182 / 0x183 / 0x200` 通过 `s_telem_slot` 三选一轮询发送。
4. 所以 `0x200` 实际发送周期约为 `60ms`，不是 `20ms`。
5. `0x184` 通过 `s_comm_diag_divider` 每 `100ms` 发送一次。

对应代码位置：

1. `C:\Users\Falling_jasmine\CLionProjects\FDR-Core\Core\Src\f4_can_app.c:925-966`
2. `C:\Users\Falling_jasmine\CLionProjects\FDR-Core\Core\Src\f4_can_app.c:907-923`

另外，下位机头文件注释和实际实现已经出现漂移：

1. `f4_can_app.h` 注释写的是 `0x181/0x182/0x183/0x200` 都在 `20ms` 周期发送。
2. 但真实代码并不是这样，而是只有 `0x181` 固定 `20ms`。

对应位置：

1. `C:\Users\Falling_jasmine\CLionProjects\FDR-Core\Core\Inc\f4_can_app.h:165-173`
2. `C:\Users\Falling_jasmine\CLionProjects\FDR-Core\Core\Src\f4_can_app.c:925-966`

### 2.2 下位机 odom 数据源没有问题

下位机 `motor.c` 中，编码器增量在控制周期中持续累加到 `s_odom_acc_ticks[]`：

1. 每次电机更新时都会把四轮增量累加到 odom 累加器。
2. `CAN_Send_OdomFrame()` 发送 `0x200` 时，通过 `Motor_Get_And_Clear_Delta_Ticks()` 原子取走并清零。

这说明：

1. `0x200` 本质是“自上次发送以来的积分增量”。
2. 如果把 `0x200` 发送频率从 `60ms` 提高到 `20ms`，语义仍然正确，只是每帧覆盖的时间窗变短、实时性更高。

对应位置：

1. `C:\Users\Falling_jasmine\CLionProjects\FDR-Core\Core\Src\motor.c:225-245`
2. `C:\Users\Falling_jasmine\CLionProjects\FDR-Core\Core\Src\motor.c:263-295`
3. `C:\Users\Falling_jasmine\CLionProjects\FDR-Core\Core\Src\f4_can_app.c:907-923`

### 2.3 上位机当前真实行为

上位机工程：`D:\ARES`

当前 `0x200` 的消费模型是：

1. CAN ISR 收到每帧 `0x200` 后，不直接覆盖，而是累加到 `odom_accum`。
2. `monitorTask` 每 `100ms` 调用 `SNC_CAN_ConsumeOdomDelta()` 原子取走累计值。
3. 然后再调用 `Odom_Update()` 推送黑板。
4. `navTask` 本身跑在 `20ms`，但它读到的 `board.odom_vx` 很多拍都是旧值。

对应位置：

1. `D:\ARES\App\Can\snc_can_app.c:185-225`
2. `D:\ARES\App\app_tasks.c:145-167`
3. `D:\ARES\App\app_tasks.c:295-340`

## 3. 问题本质

当前 odom 实时性差，来自两个串联环节：

1. 下位机发送 `0x200` 只有约 `60ms` 一次。
2. 上位机又只在 `100ms` 的 `monitorTask` 中消费一次。

所以当前 `odom_vx` 的有效刷新节拍，不是 `navTask` 的 `20ms`，而是被这两个环节一起拖慢了。

这会直接影响：

1. `CorridorEKF_Predict()` 中 `odom_vx` 的实时性。
2. 沿程 `s` 的连续性。
3. 车体加减速或转向阶段时，状态传播的平滑度。

## 4. 是否需要把 CAN 提得更高频

当前不建议先追求高于 `20ms` 的 CAN 频率。

原因：

1. 上位机 `navTask` / EKF 当前就是 `20ms / 50Hz`。
2. `0x100` 速度命令协议推荐节拍也是 `20ms`。
3. `0x200` 先做到 `20ms`，就已经与主导航闭环对齐。
4. 再往 `10ms` 提，边际收益明显变小，且会引入更多调度与验证成本。

在你当前系统中，更合理的目标是：

1. `0x100` 保持 `20ms`
2. `0x181` 保持 `20ms`
3. `0x200` 提到 `20ms`
4. `0x182/0x183/0x184` 维持低频

## 5. 总线负载是否会成为问题

基于你补充的信息：总线上只有两个单片机，且 CAN 速率为 `1 Mbps`。

在这个前提下，把 `0x200` 提到 `20ms` 是合理的，风险较低。

主要原因：

1. 当前实时关键帧就只有 `0x100`、`0x181`、`0x200`。
2. 即便这三类帧都在 `20ms` 发送，总线占用通常仍远低于饱和。
3. 下位机当前发送代码本身也把遥测帧视为“允许丢”的低优先级消息，不会因短时发不出去而阻塞主循环。

对应代码：

1. `C:\Users\Falling_jasmine\CLionProjects\FDR-Core\Core\Src\f4_can_app.c:808-821`

## 6. 推荐修改方案

### 6.1 下位机修改建议

修改文件：

1. `C:\Users\Falling_jasmine\CLionProjects\FDR-Core\Core\Src\f4_can_app.c`
2. `C:\Users\Falling_jasmine\CLionProjects\FDR-Core\Core\Inc\f4_can_app.h`

修改目标：

1. `0x181` 每 `20ms` 固定发送。
2. `0x200` 每 `20ms` 固定发送。
3. `0x182/0x183` 改成低频轮询发送。
4. `0x184` 继续 `100ms`。

最小改法建议如下：

1. 保留 `CAN_Send_StatusFrame()` 每拍都发。
2. 在 `CAN_Send_Telemetry_20ms()` 中，每拍额外固定调用 `CAN_Send_OdomFrame()`。
3. 把原来的 `s_telem_slot` 轮询从 `0x182/0x183/0x200` 三选一，改成只在 `0x182/0x183` 两者之间轮询。
4. 更新头文件中的注释，避免文档/实现再次漂移。

推荐把 `CAN_Send_Telemetry_20ms()` 的逻辑改成：

1. 先发 `0x181`
2. 再发 `0x200`
3. 再按 slot 发 `0x182` 或 `0x183`
4. 每 5 拍发一次 `0x184`

这样改的优点：

1. `0x200` 得到稳定 `20ms` 周期。
2. `0x182/0x183` 仍然保留，但不抢实时关键链路。
3. 代码改动很小，不需要碰控制内环和接收协议。

### 6.2 上位机修改建议

修改文件：

1. `D:\ARES\App\app_tasks.c`

修改目标：

1. `SNC_CAN_ConsumeOdomDelta()` 不再由 `monitorTask(100ms)` 调用。
2. odom 消费与 `Odom_Update()` 挪到 `navTask(20ms)`。

具体建议：

1. 删除 `AppTasks_RunMonitorTask()` 中 `145-167` 这段 odom 消费代码。
2. 在 `AppTasks_RunNavTask_Impl()` 中、`Blackboard_GetSnapshot(&board)` 之前插入同样的 odom 消费逻辑。
3. 保持 `SNC_CAN_ConsumeOdomDelta()` 全系统只有一个消费者。

推荐新顺序：

1. `now_ms = HAL_GetTick()`
2. `SNC_CAN_ConsumeOdomDelta(...)`
3. `Odom_Update(...)` 或 `Odom_HandleTimeout(...)`
4. `Blackboard_GetSnapshot(&board)`
5. `CorridorPreproc_ExtractObs(...)`
6. `CorridorFilter_Update(...)`

这样可以保证：

1. `navTask` 每一拍都能第一时间消费已到达的 `0x200`。
2. 当下位机把 `0x200` 提到 `20ms` 后，上位机不会再被 `100ms monitorTask` 卡住。

## 7. 不建议的修改方式

### 7.1 只改上位机，不改下位机

这样只能把 odom 的消费延迟从 `100ms` 降下来，但 `0x200` 源头仍是约 `60ms`，收益有限。

### 7.2 只改下位机，不改上位机

这样虽然 `0x200` 更快到达了，但上位机仍在 `100ms` 才取走一次，实时性改善不完整。

### 7.3 直接把 `0x200` 提到 `10ms`

现阶段不建议。原因：

1. 上位机 `navTask` 仍是 `20ms`。
2. EKF 和控制链路当前主频也是 `20ms`。
3. 先把 `20ms` 跑顺、验证完，再决定是否需要更高频更合理。

## 8. 推荐实施顺序

建议按下面顺序改：

1. 先改下位机 `f4_can_app.c`，让 `0x200` 固定 `20ms` 发送。
2. 同步修正下位机 `f4_can_app.h` 注释。
3. 再改上位机 `app_tasks.c`，把 odom 消费搬进 `navTask`。
4. 实车或日志确认 `0x200` 到达间隔、`odom_vx` 刷新节拍和 EKF 状态表现。

## 9. 验收建议

改完后至少验证以下几点：

1. 上位机收到的 `0x200` 时间戳间隔是否接近 `20ms`。
2. `SNC_CAN_ConsumeOdomDelta()` 是否只在 `navTask` 被调用一次。
3. `board.odom_vx` 是否不再长时间停留旧值。
4. `EKF` 的 `s` 和 `e_y` 传播是否更连续。
5. `s_can_tx_drop_total` 是否没有明显上升。
6. `0x181`、`0x184`、`0x100` 协议行为是否保持兼容。

## 10. 最终建议

最终建议如下：

1. 下位机把 `0x200` 改成 `20ms` 固定发送。
2. 上位机把 odom 消费改到 `navTask(20ms)`。
3. `0x182/0x183` 保持低频，不必提频。
4. 先不要把 `0x200` 提到 `10ms`。

这是当前这两套代码下，改动最小、收益最大、工程风险也最低的方案。