vee/Cognitive_Agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: update CAN integration and T2G seat firmware

Browse Source
This commit is contained in:
vee
2026-08-01 15:55:21 +08:00
parent 8cda026ac2
commit 4aded5c21d
1443 changed files with 1007122 additions and 4978 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/workflows/seat-stage1-delivery.md
+10 -12
View File
@@ -22,8 +22,6 @@
| capability | target | parameter | 0x42A signal |
| --- | --- | --- | --- |
| `seat.set_ventilation` | `front_left` | `state: on/off` | `Driver_Seat_Ventilation_S` |
| `seat.set_heating` | `front_left` | `state: on/off` | `Driver_Seat_Heating_S` |
| `seat.set_ventilation` | `front_right` | `state: on/off` | `Front_Passenger_Seat_Ventilation_S` |
| `seat.set_heating` | `front_right` | `state: on/off` | `Front_Passenger_Seat_Heating_S` |
@@ -39,7 +37,7 @@
| `seat.set_legrest_height` | 完全降下 | 完全升起 |
| `seat.set_legrest_extension` | 完全收回 | 完全伸出 |
五轴均支持主副驾。模型必须基于会话中的当前位置将相对语句转换为绝对 `position_pct`；适配器不会自行解释“往后、躺一点、再伸长”。能力范围参考了厂商公开车主手册中常见的前后、坐垫倾角、靠背和腿部支撑调节，但 CAN 定义并非来自这些厂商。
五轴只支持副驾。模型必须基于会话中的当前位置将相对语句转换为绝对 `position_pct`；适配器不会自行解释“往后、躺一点、再伸长”。能力范围参考了厂商公开车主手册中常见的前后、坐垫倾角、靠背和腿部支撑调节，但 CAN 定义并非来自这些厂商。
靠背和腿托同时接受精确夹角语义：
@@ -48,7 +46,7 @@
GPT 保留用户指定的原始 `angle_deg`，适配器使用线性演示标定确定性转换为电机 `position_pct`；`FunctionConfig`、模拟反馈和孪生模型同时保留百分比与夹角。该换算只用于验证认知编排和 UI，不代表真实座椅运动学。
`seat-motion-virtual-matrix.yaml` 使用虚构标准帧 `0x550/0x551` 控制主/副驾，用 `0x558/0x559` 反馈。每个命令包含绝对目标、轴使能掩码、计划内命令序号、模式和虚构 checksum；反馈包含实际位置、moving mask、fault mask 和 position-valid mask。`CommandPlan.completion` 要求位置在 `±1%` 内到位，虚拟执行报告保留起点、中间采样和终点。
虚拟链路只使用标准帧 `0x551` 控制副驾，并用 `0x559` 反馈。每个命令包含绝对目标、轴使能掩码、计划内命令序号、模式和虚构 checksum；反馈包含实际位置、moving mask、fault mask 和 position-valid mask。`CommandPlan.completion` 要求位置在 `±1%` 内到位，虚拟执行报告保留起点、中间采样和终点。
## 用户姿态预设
@@ -68,10 +66,10 @@ GPT 保留用户指定的原始 `angle_deg`，适配器使用线性演示标定
`domains/seat/can/seat-thermal-matrix.yaml` 保存 6 个报文、23 个信号：
- `0x42A`：主/副驾通风、加热开关候选控制信号。
- `0x4FA`：主/副驾通风、加热工作状态。
- `0x29E`：主驾开关、模式和 1–5 档状态。
- `0x3CE`：主驾通风/加热控制模式。
- `0x42A`：原始矩阵中的主/副驾通风、加热开关候选控制信号；当前应用只编译副驾映射。
- `0x4FA`：原始矩阵中的主/副驾通风、加热工作状态；当前应用只消费副驾状态。
- `0x29E`：板端既有 `Driver_Seat_*` 命名字段，不代表应用目标为主驾。
- `0x3CE`：板端既有 `Driver_Seat_*` 通风/加热控制字段，不代表应用目标为主驾。
- `0x3D3`：副驾开关、模式和 1–5 档状态。
- `0x2AA / sub-id 0x01`：主/副驾档位配置状态。
@@ -80,8 +78,8 @@ GPT 保留用户指定的原始 `angle_deg`，适配器使用线性演示标定
因此以下值是演示结果，不是实车发送结论：
```text
打开主驾通风 + 关闭副驾加热
0x42A minimum payload: 01 80
打开副驾通风 + 关闭副驾加热
0x42A minimum payload: 00 90
```
## 认知档位与主动阻断项
@@ -90,7 +88,7 @@ GPT 保留用户指定的原始 `angle_deg`，适配器使用线性演示标定
- 4–5 档目标：超出当前自动舒适策略和 `0x4FA` 虚拟回读范围，主动阻断。
- 零重力/姿态：可用虚构五轴、演示夹角标定和用户预设验证模型分解，但没有真实运动学或车型安全标定。
- 硬件发送：平台、矩阵和映射均未达到 HIL/vehicle verified。
- 显式控制语句缺目标或开关状态：进入 `needs_confirmation`；舒适反馈可依据会话目标和默认强度策略补全。
- 显式控制语句缺少座位目标时默认副驾；显式主驾、主副驾或前排目标进入 `needs_confirmation`，不得重定向。缺少开关状态时仍需确认；舒适反馈可依据副驾会话状态和默认强度策略补全。
## GPT 边界
@@ -98,7 +96,7 @@ GPT 返回受动态 JSON Schema 约束的 `domain/capability/target_scope/operat
当 `planning_environment=dry_run_candidate_synthesis` 时，命名 preset 不是执行前提。对“休憩、休息、阅读”等可理解的模式目标，GPT 应使用已注册的原子能力生成保守的绝对位置候选方案，并在 `decision_summary` 中记录推断。“没有同名预设”本身不构成歧义；只有目标座位、期望结果或所需能力确实无法判断时才要求确认。这类百分比是模型推断的 dry-run 候选值，不是人机工程或车型标定结论。
模型结果返回后，本地层只执行能力注册表一致性检查、参数校验、路由与域适配，不使用本地领域规则重新解释或改写 GPT 动作。未安装执行适配器的能力保留为 `deferred_requests`：纯未接入域请求返回 `capability_unavailable`，混合请求则先执行已接入子请求并返回 `partially_succeeded`。本地解析器只作为未配置 GPT 或 `auto` 模式调用失败时的显式降级。UI 展示 `decision_summary`、`model_requests` 和确定性阶段事件，不保存或展示模型私有 chain-of-thought。
模型结果返回后，本地层只执行能力注册表一致性检查、参数校验、路由与域适配，不使用本地领域规则重新解释或改写 GPT 动作。未安装执行适配器的能力保留为 `deferred_requests`：纯未接入域请求返回 `capability_unavailable`，混合请求则先执行已接入子请求并返回 `partially_succeeded`。本地解析器作为未配置 GPT，或 GPT/`auto` 模式调用失败时的显式安全降级，并以 `local_rules_fallback` 标记。UI 展示 `decision_summary`、`model_requests` 和确定性阶段事件，不保存或展示模型私有 chain-of-thought。
## 实车前置条件
docs/workflows/t2g-seat-hardware-bench.md
+52 -65
View File
@@ -1,59 +1,59 @@
# T2G 座椅真实硬件台架接入
本链路把一句话生成的 `FunctionConfig` 确定性编译成统一 IAR 固件的真实经典 CAN 协议，并以开发板反馈作为成功依据。默认仍是 `dry_run`；只有服务端显式启用、请求提供正确授权令牌、固件 profile 匹配且目标通过配置门禁时，才会打开 CAN 适配器。绝对位置还会在发命令前实时检查板端 `Position_Valid`；未标定时仅允许显式、小幅相对指令使用受限定时/Hall 路径。主驾和副驾当前都是 `t2g_primary_seat` 的逻辑别名，两种指令驱动同一组实体电机、加热和通风。
本链路把前端一句话生成的 `FunctionConfig` 确定性编译为统一 IAR 固件的经典 CAN 协议，并以开发板真实反馈作为成功依据。默认仍为 `dry_run`；只有服务端启用硬件且目标通过门禁时才会打开 CAN 适配器。生产/公网环境默认还要求每次请求携带正确授权令牌；本地受控调试可显式关闭该令牌门禁。
## 固件与拓扑
## 自包含固件
仓库内的固件接口工程为：
仓库已经包含完整构建输入：
```text
firmware\t2g\Seat_Controller_demo\IAR\Seat_Controller_demo.ewp
firmware/t2g/
├── CYPRESS_SDK_LICENSE.txt
├── common/
├── tviibh8m/
└── Seat_Controller_demo/
├── App/ Bsp/ Config/ Driver/
├── Docs/ Tests/
└── IAR/Seat_Controller_demo.ewp
```
厂商 SDK 只作为外部编译依赖，默认根目录为：
```text
C:\Users\D30042075206\Desktop\T2G_Sample_Driver_Library_7.9.0
```
三个已验证 demo 已合并为一个单板统一固件；原工程继续作为能力来源和回归基线：
| 来源 | IAR 工程 | 能力 | CAN |
| --- | --- | --- | --- |
| 加热基线 | `Seat_Backrest_Heater_demo` | 主驾靠背加热 | RX `0x3CE/0x29E`，TX `0x4FA` |
| 通风基线 | `Seat_Fan_demo` | 主驾通风 | RX `0x29E`，TX `0x4FA` |
| 移动/安全骨架 | `Seat_Move_demo` | 腿托伸缩/升降、靠背；Motor3 暂锁定 | RX `0x300`，TX `0x301/0x302/0x303` |
| 仓库内单板交付 | `firmware/t2g/Seat_Controller_demo` | 上述能力、共享 CAN4/IRQ/WDT、固件身份握手 | 全部上述报文及 `0x304/0x305` |
真实执行只接受仓库内 `combined` profile 和 `Seat_Controller_demo.hex/.out`。该工程用一个 CAN4 实例接收热管理与移动命令，`0x4FA` 同时填充通风 bits0..2 和加热 bits3..5；移动 ACK/反馈保持 `0x301/0x302/0x303`。三个原始 demo 镜像不再作为 Web 硬件执行入口。
每次真实请求在控制帧发送前先执行不驱动执行器的身份握手：主机向 `0x304` 发送 `53 45 41 54 01 00 00 00`，固件必须在 `0x305` 返回 `53 45 41 54 01 01 00 3F`。该响应表示协议 1、固件 1.1.0 和统一能力掩码。响应缺失或不匹配时，后端不会发送加热、通风或电机命令。
## 构建（不烧录）
因此迁移仓库后不再依赖原电脑桌面的 `T2G_Sample_Driver_Library_7.9.0`。IAR、CMSIS-DAP 与 ZLG 驱动属于本机工具链/硬件驱动，仍须在台架电脑安装。
```powershell
powershell -ExecutionPolicy Bypass -File .\tools\build_seat_firmware.ps1 -Profile combined
powershell -ExecutionPolicy Bypass -File .\tools\build_seat_firmware.ps1
```
脚本把仓库内工程临时放到与 SDK `common/tviibh8m` 相同的相对拓扑中，调用 IAR EWARM 9.2 的 `iarbuild.exe` 构建 `rev_d`，再把 HEX/OUT 回写到仓库并输出 HEX SHA-256。脚本不包含下载、烧录或电机启动操作。
构建脚本只使用仓库内 `common/tviibh8m`，在临时目录编译并回写 HEX/OUT，不连接探针、不烧录、不启动执行器。非标准 IAR 路径可通过 `COGNITIVE_AGENT_IAR_BUILD` 或 `-IarBuild` 指定。
后端自动烧录与构建脚本相互独立：只有真实台架请求已通过授权、`COGNITIVE_AGENT_SEAT_AUTO_FLASH_ENABLED=true`、身份握手失败且 IAR/C-SPY 依赖完整时，才会关闭 CAN，使用 CMSIS-DAP 和专用 `Seat_Controller_program.mac` 执行一次限时 Download-and-Debug，并以 `--leave_target_running` 把目标交还给新固件，随后重新打开 CAN 并再次验证 `0x305`。不能使用 `--download_only`，因为 IAR 会在下载后保持 CM0+ 停止。该宏在下载前强制关闭电机、风扇和加热输出并清除 program-only 调试标记；新固件从正常复位入口启动。二次验证失败时控制帧仍被阻断；交互调试仍使用原 `Seat_Controller_demo.mac` 的调试脱离故障锁存。
## 四轴与量程
## 物理链路检查
统一坐标为最近端 `0 Hall = 0%`，朝最远端 Hall 增加，`0x302.Value_X100` 范围为 0–10000。
1. 开发板 CAN4 使用 `RX=P3.7`、`TX=P3.6`，`P3.1` 为板载 CAN 收发器使能，高电平有效。
2. ZLG 适配器、各开发板和执行器控制硬件必须共地；CANH 对 CANH、CANL 对 CANL，禁止反接。
3. 总线两端各使用一个 120 Ω 终端；断电测量 CANH 与 CANL 之间应约为 60 Ω。短台架也只能保留总线两端的两个终端。
4. 使用经典标准 CAN、11-bit ID、DLC 8、500 kbit/s；不要把旧版 32-byte CAN-FD 表用于当前 `Seat_Move_demo`。
5. 先确认急停/断电手段、机械行程、夹伤区域、执行器电源能力和 Hall 接线，再上电。不要依赖 Web 软件替代物理急停。
6. ZCANPRO 与本服务不能同时独占同一个适配器。启动服务前关闭 ZCANPRO 的在线通道。
| MotorID | 前端能力 | 物理执行器 | 最近端 → 最远端 | MaxHall | 全量程 |
| ---: | --- | --- | --- | ---: | ---: |
| M0 | `seat.set_longitudinal_position` | 水平前后 | 最前 → 最后 | 480 | 215 mm |
| M1 | `seat.set_cushion_tilt` | 坐盆斜上下 | 最高 → 斜向下 | 374 | 水平 51 mm / 垂直 56 mm |
| M2 | `seat.set_backrest_recline` | 靠背 | 竖直 → 后躺 | 917 | 68° |
| M3 | `seat.set_legrest_height` | 腿托 | 最下 → 抬起 | 647 | 72° |
## 服务端启用
四轴与 physical Mode 同号，均已纳入硬件映射；台架不实现独立腿托伸缩轴，因此 `seat.set_legrest_extension` 只保留虚拟展示，真实请求会在打开 CAN 前拒绝。
把 `.env.example` 中相关变量复制到本机 `.env`，至少设置：
## CAN 协议与反馈
- 热管理命令：`0x29E/0x3CE`；档位反馈：`0x4FA`。
- 移动命令：`0x300`；系统 ACK：`0x301`；归一化位置：`0x302`；Hall/量程：`0x303`。
- 电流诊断：`0x304` 四轴轮询，`0x305` 通风/加热；这些值用于台架可见性，当前保守阈值不能替代外部限流或量产保护。
- Opcode 1 的 `ParamA` 为 0–10000 绝对位置，`ParamB=0` 使用各轴固件默认超时。
- Opcode 3 的 `ParamA` 为持续时间，`ParamB` 为驱动等级×10（默认 90% 即 900）。
- `STOP_ALL` 的专用 ACK 为 4；完成/故障 TaskState 分别为 6/7。
新版固件把 `0x304/0x305` 用于电流诊断，不能继续发送旧版身份请求。后端在任何控制帧之前被动观察 `0x301–0x305`、`0x4FA`、四个 MotorID 和 MaxHall `480/374/917/647`；真实硬件执行启用后，未观察到完整签名会自动使用仓库内 IAR 镜像烧写，重新被动验证成功后继续原请求。烧写或复验失败时禁止发送座椅控制帧。
## 启用配置
```dotenv
COGNITIVE_AGENT_HARDWARE_EXECUTION_ENABLED=true
COGNITIVE_AGENT_HARDWARE_APPROVAL_TOKEN_REQUIRED=false
COGNITIVE_AGENT_HARDWARE_APPROVAL_TOKEN=123456
COGNITIVE_AGENT_SEAT_FIRMWARE_PROFILES=combined
COGNITIVE_AGENT_SEAT_AUTO_FLASH_ENABLED=true
@@ -61,42 +61,29 @@ COGNITIVE_AGENT_IAR_CSPYBAT=D:\Program Files\IAR Systems\Embedded Workbench 9.2\
COGNITIVE_AGENT_SEAT_CAN_BACKEND=zlgcan
COGNITIVE_AGENT_SEAT_CAN_CHANNEL=0
COGNITIVE_AGENT_SEAT_CAN_BITRATE=500000
COGNITIVE_AGENT_ENABLE_UNVERIFIED_LONGITUDINAL=false
COGNITIVE_AGENT_SEAT_AUTO_HOME_ENABLED=false
COGNITIVE_AGENT_SEAT_HOME_TIMEOUT_S=120
```
服务运行在 64 位 Python，ZCANPRO 的 `zlgcan.dll` 和内置 Python 是 32 位，因此主进程会启动 `zlgcan_bridge.py` JSON-line 子进程。运行时页面只显示“令牌已配置”和固件哈希，不返回令牌本身。
`COGNITIVE_AGENT_HARDWARE_APPROVAL_TOKEN_REQUIRED` 默认为 `true`，生产和公网部署应保持默认值。本地受控台架调试可显式设为 `false`，此时前端隐藏令牌输入且服务端不再逐请求校验令牌；硬件启用、固件、适配器、副驾目标、物理反馈和故障 STOP_ALL 等其他门禁保持不变。
可先做不打开设备的 DLL/ABI 自检：
`COGNITIVE_AGENT_SEAT_AUTO_FLASH_ENABLED` 在真实硬件执行启用时默认为 `true`，上面的显式配置便于台架审计；如需禁止自动覆盖控制器固件，可明确设置为 `false`。此默认值不会影响 `dry_run`。
```powershell
& 'C:\Program Files (x86)\ZCANPRO\python38\python.exe' `
'.\src\cognitive_agent\infrastructure\can\zlgcan_bridge.py' `
--dll 'C:\Program Files (x86)\ZCANPRO\zlgcan.dll' `
--device-type 41 --self-test
```
当前台架只公布并接受副驾目标 `passenger/front_right`。没有座位词的座椅指令默认副驾；显式主驾、主副驾或前排范围请求会在打开 CAN 前拒绝，不能静默重定向。热管理 CAN 中仍出现的 `Driver_Seat_*` 是板端既有协议字段名，不代表应用层可以控制主驾。
## 请求与反馈闭环
## 绝对位置与已知量程归零
前端选择“真实台架”，输入本次授权令牌后再提交。硬件路径只接受 `seat` 单域，`front_left/driver` 和 `front_right/passenger` 都映射到 `t2g_primary_seat`：
绝对命令发送前必须看到 `Position_Valid=1`。SMV8 clean 记录有效时，一句话可以直接下发绝对目标；位置无效时默认失败关闭，不会静默触发全行程标定。
- 固件：先执行 `0x304/0x305` 身份握手；必要时自动烧录并二次握手。烧录和身份验证结果写入 `ExecutionReport`，授权令牌不会写入制品。
台架无遮挡、急停就绪并且明确允许自动回最近端时，可设置 `COGNITIVE_AGENT_SEAT_AUTO_HOME_ENABLED=true`。后端仅对目标失效轴发送 `HOME_KNOWN_RANGE(0x0B)`，先核对 MaxHall，再等待 `COMPLETE/OK`、Near、Hall≤2 和 PositionValid，随后继续原绝对目标。此流程会产生真实机械运动，但不会访问最远端或重测量程。Opcode `0x0A` 全行程标定不会由普通一句话请求触发。
- 热/风：发送真实 `0x3CE/0x29E`，必须等到 `0x4FA` 的实际档位匹配。
- 绝对移动：打开适配器后先发 `STOP_ALL` 并用 `0x301` 重同步 sequence；发送 Opcode `1` 前读取目标电机 `0x302.Position_Valid`。未标定时不会发送绝对移动帧，而是返回需要显式端点标定的错误。标定有效时必须收到匹配 sequence 的 ACCEPTED ACK，再等 `0x302` 返回 COMPLETE/OK、位置有效且在容差内。
- 小幅相对移动：GPT 仍输出解析后的绝对目标，同时 `FunctionConfig.operation.motion` 保留 `increase/decrease`、起点和增量。未标定安全路径编译为 Opcode `3`、50% 定时占空比；时长按仓库内 500 ms 实测 Hall 速度确定，单次增量限制为 15%。成功必须同时满足 ACK、`0x302 COMPLETE/OK` 和固件内部“至少一个原始 Hall 边沿”门禁；后端还记录 `0x303` 的 Hall 前后值并核对可观测方向。
- 拒绝、安全故障、Hall 未运动、方向不符、位置无效或超时：报告失败，并立即尽力再次发送 `STOP_ALL`；失败的动作不会写入会话状态。未标定相对移动成功时会话中的绝对百分比/角度明确标记为估计值，不能替代端点标定结果。
## 上电与安全检查
Opcode `10` 的全行程端点标定会主动运动到两个机械端点，普通一句话请求绝不会静默触发。需要精确绝对角度时，应先在台架无遮挡、急停可用的维护流程中显式完成目标电机标定，并保存 clean 记录。
1. 固定座椅，清空四轴全行程，准备硬件急停和 12 V 限流电源。
2. CAN4：RX=P3.7、TX=P3.6、P3.1 收发器使能；CANH/CANL 正确、共地、总线两端各 120 Ω。
3. 使用 Classic CAN、11-bit、DLC 8、500 kbit/s；ZCANPRO 与服务不能同时独占适配器。
4. 首次动作只做单轴短行程并目视核对 M0/M1/M2/M3 与方向；任一映射异常立即急停。
5. 先验证通风/加热关闭与低档，再执行移动；无示波器时不得声称 PWM、死区或硬实时关断已经验证。
6. 每次检查 `ExecutionReport.spec.mode=hil`、协议签名、命令帧、ACK、位置/Hall 回读与失败后的 STOP_ALL。
如果一句话同时要求主驾和副驾对同一能力使用相同目标，编译器只发送一次实体命令，并把同一真实回读投影给两个逻辑目标；如果两侧对同一实体能力提出冲突目标，请求会在打开 CAN 之前被拒绝。真实执行成功后，两侧会话状态保持同步。
Motor0（腿托伸缩）、Motor1（腿托升降）和 Motor2（靠背）已验证。Motor3（座椅前后）仍未接线、未实标，默认强制禁止。`seat.set_cushion_tilt` 在当前固件没有物理电机，始终禁止。只有完成 Motor3 接线、端点标定、方向核对和风险评审后，才能显式设置 `COGNITIVE_AGENT_ENABLE_UNVERIFIED_LONGITUDINAL=true`。
## 建议上电顺序
1. 保持服务为 `dry_run`，运行完整测试。
2. 从仓库构建 `Seat_Controller_demo`。首次联调建议人工烧录并先用 ZCANPRO 观察周期反馈；确认 CMSIS-DAP、复位和供电链路后再启用自动烧录。
3. 使用固件文档中的短时测试帧逐电机核对方向、Hall 与急停；Motor3 不参与。
4. 关闭 ZCANPRO 在线通道，启用服务端环境变量；需要自动烧录时保持 CMSIS-DAP 连接并显式设置自动烧录开关。
5. 前端先执行加热/通风 OFF，再做低档 ON；移动先从小行程、无遮挡状态开始。
6. 对每次实际动作核对 `ExecutionReport.spec.mode=hil`、真实反馈帧和固件镜像哈希。
完整固件协议、HIL 结果和手工回归工具位于 `firmware/t2g/Seat_Controller_demo/Docs` 与 `Tests/manual_hil`。