init
This commit is contained in:
orin
Executable
+102
@@ -0,0 +1,102 @@
|
||||
# T2G 座椅真实硬件台架接入
|
||||
|
||||
本链路把一句话生成的 `FunctionConfig` 确定性编译成统一 IAR 固件的真实经典 CAN 协议，并以开发板反馈作为成功依据。默认仍是 `dry_run`；只有服务端显式启用、请求提供正确授权令牌、固件 profile 匹配且目标通过配置门禁时，才会打开 CAN 适配器。绝对位置还会在发命令前实时检查板端 `Position_Valid`；未标定时仅允许显式、小幅相对指令使用受限定时/Hall 路径。主驾和副驾当前都是 `t2g_primary_seat` 的逻辑别名，两种指令驱动同一组实体电机、加热和通风。
|
||||
|
||||
## 固件与拓扑
|
||||
|
||||
仓库内的固件接口工程为：
|
||||
|
||||
```text
|
||||
firmware\t2g\Seat_Controller_demo\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 和统一能力掩码。响应缺失或不匹配时，后端不会发送加热、通风或电机命令。
|
||||
|
||||
## 构建（不烧录）
|
||||
|
||||
```powershell
|
||||
powershell -ExecutionPolicy Bypass -File .\tools\build_seat_firmware.ps1 -Profile combined
|
||||
```
|
||||
|
||||
脚本把仓库内工程临时放到与 SDK `common/tviibh8m` 相同的相对拓扑中，调用 IAR EWARM 9.2 的 `iarbuild.exe` 构建 `rev_d`，再把 HEX/OUT 回写到仓库并输出 HEX SHA-256。脚本不包含下载、烧录或电机启动操作。
|
||||
|
||||
后端自动烧录与构建脚本相互独立：只有真实台架请求已通过授权、`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` 的调试脱离故障锁存。
|
||||
|
||||
## 物理链路检查
|
||||
|
||||
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 的在线通道。
|
||||
|
||||
## 服务端启用
|
||||
|
||||
把 `.env.example` 中相关变量复制到本机 `.env`，至少设置：
|
||||
|
||||
```dotenv
|
||||
COGNITIVE_AGENT_HARDWARE_EXECUTION_ENABLED=true
|
||||
COGNITIVE_AGENT_HARDWARE_APPROVAL_TOKEN=123456
|
||||
COGNITIVE_AGENT_SEAT_FIRMWARE_PROFILES=combined
|
||||
COGNITIVE_AGENT_SEAT_AUTO_FLASH_ENABLED=true
|
||||
COGNITIVE_AGENT_IAR_CSPYBAT=D:\Program Files\IAR Systems\Embedded Workbench 9.2\common\bin\cspybat.exe
|
||||
COGNITIVE_AGENT_SEAT_CAN_BACKEND=zlgcan
|
||||
COGNITIVE_AGENT_SEAT_CAN_CHANNEL=0
|
||||
COGNITIVE_AGENT_SEAT_CAN_BITRATE=500000
|
||||
COGNITIVE_AGENT_ENABLE_UNVERIFIED_LONGITUDINAL=false
|
||||
```
|
||||
|
||||
服务运行在 64 位 Python，ZCANPRO 的 `zlgcan.dll` 和内置 Python 是 32 位，因此主进程会启动 `zlgcan_bridge.py` JSON-line 子进程。运行时页面只显示“令牌已配置”和固件哈希，不返回令牌本身。
|
||||
|
||||
可先做不打开设备的 DLL/ABI 自检：
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## 请求与反馈闭环
|
||||
|
||||
前端选择“真实台架”，输入本次授权令牌后再提交。硬件路径只接受 `seat` 单域，`front_left/driver` 和 `front_right/passenger` 都映射到 `t2g_primary_seat`：
|
||||
|
||||
- 固件：先执行 `0x304/0x305` 身份握手；必要时自动烧录并二次握手。烧录和身份验证结果写入 `ExecutionReport`，授权令牌不会写入制品。
|
||||
|
||||
- 热/风：发送真实 `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 记录。
|
||||
|
||||
如果一句话同时要求主驾和副驾对同一能力使用相同目标，编译器只发送一次实体命令，并把同一真实回读投影给两个逻辑目标；如果两侧对同一实体能力提出冲突目标，请求会在打开 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`、真实反馈帧和固件镜像哈希。
|
||||
Reference in New Issue
Block a user