zjk b547772709 新增 pCanBridge:USBCAN-8E-U CAN->MOOSDB 透传桥 + SQLite 落库
新应用 src/pCanBridge(独立 MOOS App,单通道):
- CanEndpoint:TCP Client 连接 CANET/USBCAN-8E-U 工作端口
  (目标 IP/端口可配置,默认 192.168.0.222:4001=CAN0),
  接收线程流式缓冲按 13 字节切帧,过滤无效 DLC(>8),
  断线自动重连(非阻塞 connect+超时 / SO_RCVTIMEO 读超时)。
- 帧协议(CANET-8E-U 手册 8.1):byte0=帧信息(bit7 FF/bit6 RTR/
  bit3~0 DLC),byte1~4=ID 大端,byte5~12=数据。
- MOOS 映射:变量名 CAN_0x%08X=CAN ID(不缩减),m_sVal=二进制
  data(逐帧透传不限流),m_sSrcAux=通道名(can_channel_name),
  m_dfVal2=原始帧信息字节(用于区分标准/扩展、数据/远程帧)。
- CanDbStore:每帧落库 SQLite(can_frame 表:time/channel/
  frame_info/can_id/dlc/hex,含 time、can_id 索引),参考 pCCU
  DbStore:预处理语句 + WAL + synchronous=NORMAL,路径由 dbpath
  配置;复用 pPowerManger 的 sqlite3 amalgamation。
- AppCast 输出连接状态/收帧/发布/落库统计。

配套:
- missions/h100.moos 新增 pCanBridge 配置块(板卡 dbpath 指向
  data 目录)。
- build-board.sh / deploy.sh 支持 pCanBridge:产物部署 +
  pCanBridge.service 安装,服务列表加入第 5 个服务。
- .gitignore 忽略 bin/pCanBridge 与本机默认数据库。

已验证(板卡 192.168.0.223 实测):服务 active,连接设备正常,
~60 帧/s 透传,落库 9000+ 行 integrity ok、无丢帧。
2026-08-31 19:14:59 +08:00
2026-01-19 21:52:26 +08:00
2025-04-07 21:18:02 +08:00
2024-10-22 17:28:15 +08:00
2025-09-12 11:35:17 +08:00
2025-06-06 13:28:05 +08:00
2025-05-23 15:38:23 +08:00
2025-07-02 16:20:36 +08:00

H100PowerManger

H100 能源管理程序

CI

测试报告

每次 CI 运行后自动生成测试报告:

自动化测试(PowerManger)

CI 在 aarch64 (QEMU) 环境下运行两类测试,不改动任何 src/ 生产代码:

单元测试(GoogleTest,PowerMangerTests,56 例)

  • DriverTest:10 个工况的设备表生成(STANDBY/岸基备航/水中备航/巡航/高速/上浮下潜/浮调/水下侦查/水面侦查/DJ)+ 设备状态读写 + JSON 往返
  • SystemDataTest:4 类配电/CCU 反馈的故障检测(断路器 0x55/0xAA/0x5A 映射、绝缘低、电源失电、漏水、DCDC、继电器位提取、缩放)+ 故障码集合/等级 + 漏水位
  • FaultMapTest:锂电池故障表(54) / 配电故障表(45) 完整性
  • UpmsgTest:上位机/外部通信 JSON 消息解析与序列化往返
  • UdpCommTest:UDP 校验和 / 消息头识别 / 校验解析 / 日期
  • PmSysvariableTest:#pragma pack(1) 协议结构体大小/偏移 + 枚举完整性
  • SqliteTest:用裸 sqlite3 读回校验 10 个 insertData 写入

集成测试

  • 冒烟:MOOSDB + pPowerManger 拉起存活
  • UDP 回环:udpFeeder 发送真实 CCU 反馈 → 校验 power_data.db 落行(验证 UDP→SystemData→SQLite 全链路)

本地跑测试:需要 GoogleTest(git clone https://gitea2.zhaojingkui.xyz/zjk/googletest.git 后 cmake && make && make install),然后 ./build.sh 即可。

构建产物(Gitea Releases,手动部署)

CI 构建的 aarch64 二进制(RK3588 / Ubuntu 22.04,板卡实测为 Orange Pi 5 Plus 的 Jammy 系统)会发布到 Gitea Releases,供手动下载部署:

  • 版本号 Release:推送 v* tag(如 v1.0.0)时创建,正式版 → https://gitea2.zhaojingkui.xyz/zjk/H100PowerManger/releases/tag/v1.0.0
  • latest Release(测试):每次 main push 时更新,标记为预发布(测试用) → https://gitea2.zhaojingkui.xyz/zjk/H100PowerManger/releases/tag/latest

发布流程(CI 自动执行,仅测试通过后发布)

Publish release / Publish latest release 步骤(if: success(),即构建 + 测试全部通过才发布)用 ${{ secrets.CI_TOKEN }} 调 Gitea API 完成:

  1. 创建 Release:POST /releases
  2. 删除旧 latest(仅 latest):DELETE /releases/tags/latest
  3. 上传附件:POST /releases/{id}/assets?name=pPowerManger(multipart 字段 attachment)
  4. 按 github.ref 分支处理:
    • refs/tags/v* → 直接为该 tag 创建版本号 Release
    • refs/heads/main → git tag -f latest && git push -f origin latest,删除旧 latest Release,重建为 prerelease,再上传二进制
  5. Release body 自动带上:commit / 时间 / 测试报告链接 / 手动部署命令

手动部署到板卡

从 Releases 页面下载 pPowerManger 后,手动推送到板卡(仅推送,不自动重启):

rsync -avz pPowerManger root@192.168.0.223:/root/work/moos_ws/moos-ivp-extend/bin/pPowerManger
S
Description
No description provided
Readme
33 MiB
Languages
C 79%
C++ 14.4%
Python 5.4%
Shell 0.6%
HTML 0.4%
Other 0.2%