jim800121/visionA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
93 Commits 1 Branch 0 Tags
Commit Graph

9 Commits

Author SHA1 Message Date
jim800121chen
c03eb6fd0e feat(local-tool): M9-2 — Go driver UpgradeFirmware + firmware service module 
A 階段第二個 milestone、銜接 M9-1 bridge.py、暴露 service layer 給 M9-3 API/WebSocket。

New module `server/internal/firmware/`:
- types.go: 123 行（FirmwareVersion / FirmwareProgress / ActiveTaskInfo / UpgradeDriver interface / 8 reason const）
- progress.go: 147 行（仿 flash pattern 的 Tracker、Task.cancel 預留 SIGTERM force-cancel godoc）
- service.go: 373 行（核心 service：UpgradeFirmware / HasActiveTask / GetActiveTaskInfo / RequestShutdown / WaitForActiveTasks / ListBundledVersions / GetCurrentVersion）
- service_test.go: 676 行、13 個 test 含 MultiDeviceParallel

Driver layer:
- kl720_driver.go: 697 → 1054 行（+357、新 UpgradeFirmware method + tryRouteFirmwareEvent + sendCommandForUpgrade snapshot pattern）
- kl720_driver_test.go: 360 行、11 個 test（含 InfoNotBlockedDuringUpgrade / CtxCancelReleasesBridge / StderrEventAfterCtxCancel 100 round stress）

關鍵設計：
- flash 與 firmware 模組分離（不 import flash）
- UpgradeDriver interface 隔離 driver 細節、DeviceLookup interface 隔離 device manager
- 中介 channel pattern（service ↔ driver）方便 service 補欄位（DeviceID / Direction / BeforeVersion）
- timeout 雙保險：chip timeout + 30s margin
- 8 reason enum 對齊 bridge.py、stage 採 Design 命名

Concurrency race 修復（M9-2 Reviewer round 1 → round 2）:
- Major 1（mutex deadlock）：新 fwUpgradeMu 獨立鎖 + sendCommandForUpgrade snapshot stdin/stdout pattern、避開 d.mu field-level race + 升級期間 Info/Disconnect 不被卡 + timeout 路徑無死鎖
- Major 2（close-channel race）：tryRouteFirmwareEvent 持 fwMu 整段、配合 defer setFirmwareProgressCh(nil) 提供 happen-before、絕無 send on closed channel panic

Reviewer 兩輪審查：
- Round 1: 0 Critical / 2 Major / 5 Minor / 5 Suggestion
- Round 2: 0 Critical / 0 Major / 2 Minor / 2 Suggestion（11/12 issue 修到位、Suggestion 4 留 follow-up）

M9-1 follow-up 順手清：
- m5（test 死碼 _firmware_upgrade_start_ts 殘留兩行）已清
- s5（test 註解 idempotent shape 說明）已加

測試：
- go test ./... -race -count=1: 全綠（28s、無 regression）
- Python: 36 tests + 22 subtests 全綠（0.31s）
- go vet / build: 0 output

下一步：M9-3 API handler + WebSocket progress（CI 建議 `go test -race -count=3` 提升 race 偵測強度）

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-25 11:27:36 +08:00
jim800121chen
d7b5a2398a feat(local-tool): M9-1 — bridge.py firmware_upgrade handler（KL520+KL720 KDP1→KDP2） 
A 階段第一個 milestone、純 bridge.py 層 + ctypes 直接呼叫 KneronPLUS C symbol。

Source:
- server/scripts/kneron_bridge.py: 1207 → 2058 行（+851）
- server/scripts/test_kneron_bridge_firmware.py: 新檔 840 行、36 unit tests 全綠 0.076s

Firmware bundled:
- server/scripts/firmware/KL520/fw_loader.bin（90112 bytes、MD5 aef7cca17bc023abbd6152c46c18e774、與 warrenchen 一致）
- server/scripts/firmware/{KL520,KL720}/VERSION（v2.2.0）

實作對齊 TDD §6.1 規格（98% 對齊度）：
- handler input/output schema 100%
- stage enum: preparing/loading/flashing/verifying/done/error（採 Design 命名）
- reason enum 7/8（disconnect_during_op 留 M9-5 實機測試）
- ctypes binding 1:1 對齊 warrenchen legacy_plus121_runner.py
- 4 個情境 stage 序列驗證通過（KL520 KDP1+loader / KL520 KDP1 缺 loader / KL720 legacy / 已 KDP2）
- timeout 60s/200s、USB stable 5-8s wait、SIGTERM 拒絕邏輯
- progress event schema 完整（percent/stage/message/elapsed_ms/eta_ms/extra）

Reviewer 兩輪審查：
- 第 1 輪：0 Critical / 3 Major / 4 Minor / 4 Suggestion
- 第 2 輪：通過 with 1 Minor + 1 Suggestion（m5 test 死碼 / s5 test 註解、留 M9-2 順手清）
- M3 firmware 字串覆蓋從 substring → 顯式 enumeration + KDP3+ forward-compat（防未來 brick 風險）
- M2 控制流重構（needs_loader/should_run_loader_stage/loader_required_but_missing 三個顯式 bool）
- m3 single-owner disconnect 原則完整落地

既有 6 個 handler（scan/connect/disconnect/reset/load_model/inference）零改動、無 spillover risk。

下一步：M9-2 Go driver UpgradeFirmware + firmware/service.go

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-25 08:10:46 +08:00
jim800121chen
b71ff4cd3c perf(local-tool): Windows KL520 cold-boot connect 106s → ~40s（跳過多餘 reset） 
背景：
Windows 實測 KL520 首次 connect 耗時 106 秒，原因是 reset 流程內部重複
firmware load：
  1. 進來 Loader → load firmware (35s) → Comp/U
  2. reset 退回 Loader → bridge 重啟
  3. reconnect 進來又是 Loader → load firmware (30s) → Comp/U
  4. Loader reconnect 第一次常 fail（15s timeout）
總共 ~65s 花在「砍掉剛載好的 firmware、再載一次」的白工上。

根因：先前修的 needsReset 邏輯不管 firmware 新舊一律 reset。但 Error 15
只發生在「Comp/U 是上次 session 殘留」的情境；「本次 connect 內部剛載的
Comp/U」session 是乾淨的，不需要 reset。

修法（條件性 reset）：
- server/scripts/kneron_bridge.py：connect handler 新增追蹤本次有無走
  firmware load flow，return 多帶 `fresh_firmware_loaded` bool
- server/internal/driver/kneron/kl720_driver.go：Connect 讀 flag，若為
  true 就 skipReset（firmware 剛載的，session 已乾淨）

驗證（2026-04-21）：
- `/tmp/test_bridge.py` 拔插 USB 後跑 `connect (fw=Loader) →
  fresh_firmware_loaded=True → skip reset → load_model → inference`
  → 11 detections（person×8, tie×3, latency 332ms）
- Mac UI Comp/U 殘留路徑：reset → 11 bbox ✓
- Mac UI Loader cold-boot 路徑（拔插後）：skip reset → 11 bbox ✓

預期效益：
- Windows cold-boot（常見）：106s → ~40s（省 65s）
- Mac 跨 session（常見）：~15-20s 不變
- 極少數（Windows device 未斷電但跨 server session）：走完整 reset

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-04-21 11:09:25 +08:00
jim800121chen
30d0ff5695 fix(local-tool): 推論 bbox 標註不顯示 — 前端 canvas 尺寸 + KL520 reset + 延長 timeout 
症狀：Mac 版上傳單張圖推論，畫面完全沒有 bbox 標註。實測追根因後發現
兩層獨立問題疊加（前端 + 後端），擇一修復都無法解決。

## Layer 1: 前端 canvas 尺寸對不上 img 顯示尺寸
- camera-inference-view.tsx renderedSize 初始值硬寫 {w:640, h:480}
- ResizeObserver 理應在 <img> load 後 fire，但實測沒 fire 或時機不對
- 結果 overlay canvas 永遠用 640×480 畫，bbox 嚴重偏位或跑出 canvas

修法（camera-feed.tsx + camera-inference-view.tsx）：
- <img> 加 onLoad handler，decode 完立刻用 getBoundingClientRect 回報
- ResizeObserver effect 進來先檢查 img.complete && naturalWidth > 0，
  是就立刻 report（cover HMR / cached image）
- effect 依賴加 streamUrl / batchImageUrl，換圖會重觀察
- renderedSize 初始值改 null，overlay 改為拿到真實尺寸才 render
- setState callback 用 prev 比對，同尺寸不觸發 render
- camera-overlay.tsx 加 [bbox-debug] console.log 保留（debug 成本低，
  對未來排查有幫助）

## Layer 2: KL520 推論炸 ApiKPException Error 15
- kp.inference.generic_image_inference_send 回 SEND_DATA_TOO_LARGE
- 試過 image 尺寸（516×640 / 640×794 / 640×640 host pad）、numpy vs
  bytes、明確傳 width/height — 全部炸
- Python bridge 直接測試（/tmp/test_bridge.py）做完整
  `connect → reset → reconnect → load_model → inference` 序列 → 11 個
  detection 正常回傳
- Go driver 走 `connect → load_model → inference` 跳過 reset

根因：commit ddf0eb8（2026-04-16）「KL520 首次 connect 跳過 reset」當時
為解 Windows 60s HTTP timeout 的優化。但副作用：KL520 若 session 間
firmware 殘留（fw=KDP2 Comp/U），直接 load_model + inference 100% 炸
Error 15。必須走完整 reset → 退回 Loader → 重新載 firmware → Comp/U
流程才能得到能 inference 的 session。

修法（kl720_driver.go）：
- 移除「KL520 跳過 reset」特例，讓 KL520 和 KL720 都走 needsReset → restartBridge
- 註解記錄 trade-off：KL520 connect 時間 ~2s → ~15-20s（macOS），
  Windows 可能 60s+

## HTTP timeout 配套調整
- device_handler.go ConnectDevice timeout 60s → 120s
- Windows worst-case（~65s：Loader reconnect 16s + firmware load 31s +
  reboot 8s + reconnect 5s）留 buffer，避免 504 CONNECT_TIMEOUT

## Bridge 清理
- kneron_bridge.py 清掉中途試驗遺留的 `_host_preproc` 死碼
  （還原成原版 _correct_bbox_for_letterbox）
- 加了 debug log（Inference: sending / parse done / EXCEPTION with
  traceback）保留，未來排查 inference 路徑很有用

## 驗證（function 層）
/tmp/test_bridge.py 三種尺寸全通過：
- 516×640 直式 → 11 detections (person×8, tie×3) latency 308ms
- 1920×1080 横式 → 0 detections（合成圖，正常）
- 512×512 正方 → 0 detections

## 待使用者驗證
- Mac UI 實測：上傳 ~/Downloads/000000000459.jpg 應見 11 個 bbox 精準框住
- Windows 實測 connect 耗時 + timeout 是否足夠
- Linux 實測

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-04-21 01:12:10 +08:00
jim800121chen
d0b33f8c71 fix(local-tool): macOS 掃不到 Kneron 裝置 — PythonModeAuto 先 bundled 
症狀：Mac 版 app 啟動後，前端顯示沒有裝置（實際 KL520 透過 USB 連上）。

根因：
PythonModeAuto 原本「先 system 後 bundled」，但系統 python3 通常沒裝
KneronPLUS wheel → `import kp` 失敗 → HAS_KP=False → bridge 降級 pyusb →
pyusb 找不到 libusb → scan 空陣列。表面看起來啟動成功但 detector 是空的。

修法：
- visiona-local/app.go PythonModeAuto 語意翻轉 → 先 bundled（已預裝 kp wheel），
  失敗才 fallback system。Local-tool 架構就是整包內嵌 Python + wheels，
  系統 python 不會裝 kp，不該優先。
- server/scripts/kneron_bridge.py 在 `import kp` 前新增
  `_preload_kneron_dylibs_macos()` — 用 ctypes.CDLL 絕對路徑預載 wheel 內
  `kp/lib/libusb-1.0.0.dylib` + `libkplus.dylib`，避開 macOS hardened
  runtime 剝掉 DYLD_LIBRARY_PATH 的風險。Windows/Linux 守門不執行。

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-04-21 01:10:59 +08:00
jim800121chen
abbe9d4c0b fix(local-tool): DeviceGroup.__del__ access violation 全面修復 
上一個 commit (a6a121a) 只修了 script 結束時的 cleanup，但使用者仍在
connect 重試路徑看到 access violation：

  connect attempt 1 failed → 新 connect attempt 2 → GC 回收 attempt 1
  的舊 DeviceGroup → __del__ → kp_disconnect_devices 對已失效的 native
  handle → OSError: access violation

根因：`_device_group = None` 只是清掉 Python reference，舊物件的 __del__
會延遲到下一次 GC cycle（可能發生在新 connect call 的 allocation 時），
此時 native handle 已 invalid。

修法：
- 新增 `_clear_device_group()` helper：先 kp.core.disconnect_devices 把
  native handle 正常釋放（errors silenced），再設 None
- 全檔搜 `_device_group = None` 共 12 處，除了初始宣告（L40）和兩個 helper
  自身（_clear_device_group / _cleanup）以外全部替換為 _clear_device_group()
- 涵蓋所有 code path：connect retry / firmware load reconnect / disconnect
  handler / reset handler / error fallback

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-04-16 17:20:12 +08:00
jim800121chen
a6a121ae86 fix(local-tool): suppress KneronPLUS DeviceGroup.__del__ access violation 
Windows 上 bridge script 結束時 Python GC 呼叫 DeviceGroup.__del__ →
kp_disconnect_devices 對已釋放的 native handle 操作 → OSError: access
violation reading 0x00...0C。這是 KneronPLUS SDK 的 destructor 沒做
null check 的已知問題，不影響功能但會印嚇人的 stack trace 到 stderr。

修法：
- 新增 _cleanup() 函式：明確 kp.core.disconnect_devices + 把
  _device_group 設 None（讓 __del__ 成 no-op）
- atexit.register(_cleanup) 確保 interpreter 關閉前 cleanup
- main() return 後也同步呼叫一次（belt-and-suspenders）

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-04-16 15:40:30 +08:00
jim800121chen
96dee565b3 fix(local-tool): 補上 Kneron KL520/KL720 韌體檔案 
根因：KL520 在 USB Boot 模式下（fw=KDP2 Loader）需要先載入韌體到 RAM
才能接受模型載入。kneron_bridge.py connect 流程會自動呼叫
kp.core.load_firmware_from_file()，但前提是找到韌體檔案：
  scripts/firmware/KL520/fw_scpu.bin + fw_ncpu.bin
  scripts/firmware/KL720/fw_scpu.bin + fw_ncpu.bin

這些檔案在 M1 從 edge-ai-platform 搬程式碼時漏了，補入。
Makefile 的 payload-windows/linux/macos 的 cp -R server/scripts/
會自動帶入 firmware/ 子目錄。

KL520: scpu 51KB + ncpu 39KB
KL720: scpu 128KB + ncpu 2.0MB

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-04-12 23:11:47 +08:00
jim800121chen
c54f16fca0 Initial commit: visionA monorepo with local-tool subproject 
local-tool/: visionA-local desktop app
- M1: Wails shell + Go server + Next.js UI + Mock mode (macOS dmg ready)
- M2: i18n (zh-TW/en) + Settings 4-tab refactor
- M3: Embedded Python 3.12 runtime (python-build-standalone) + KneronPLUS wheels
- M4: Windows Inno Setup script (build on Windows runner)
- M5: Linux AppImage script + udev rule (build on Linux runner)
- M6: ffmpeg (GPL, pending legal review) + yt-dlp bundled
- Lifecycle: watchServer health check, fatal native dialog,
            Wails IPC raise endpoint, stale process cleanup

.autoflow/: full PRD / Design Spec / Architecture / Testing docs
            (4 rounds tri-party discussion + cross review)
.github/workflows/: macOS / Windows / Linux build CI

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
 2026-04-11 22:10:38 +08:00