visionA

jim800121/visionA

Fork 0

Commit Graph

Author	SHA1	Message	Date
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	ddf0eb8147	fix(local-tool): KL520 首次 connect 跳過不必要的 device reset 使用者 Windows 上 connect KL520 耗時 60+ 秒且前端收到 504 timeout。根因分析（從 log 逐行推斷）： 1. server 啟動後首次 connect → needsReset=true → restartBridge() 2. reset 送出 → KL520 reboot → 退回 KDP2 Loader 模式（USB Boot 裝置， reset = firmware 從 RAM 清掉） 3. USB 重新枚舉 8 秒 → 新 bridge process → 嘗試 reconnect 4. Loader 模式的 connect_devices_without_check 不穩定 → attempt 1 fail (16 秒 timeout) → attempt 2 成功 (4 秒) 5. 載 firmware fw_scpu.bin → 31 秒 6. firmware loaded → 再次 reboot → 5 秒後 reconnect 7. 總時：8 + 16 + 4 + 31 + 5 = 64 秒 > 前端 60 秒 HTTP timeout → 504 但 KL520 是 USB Boot 裝置，每次斷電 firmware + model 就會清掉，connect 時本來就是 clean state。server 啟動後主動 reset 是多餘的——它把完整 firmware 砍掉再重載一次，浪費 60 秒且 Loader 模式 connect 不穩定。這個 reset 邏輯最初是為 KL720 設計的：KL720 是 flash-based 裝置， firmware 和 model 保留在 flash，reset 清 stale model 才有意義。修法：needsReset 條件加上 chipType == "KL720"。KL520 跳過 reset，直接使用已有的 firmware。如果 KL520 真的有殘留 model 要清（理論上不會因為它是 RAM-based），下次 load_model 前的 restartBridge 會處理。修復後 KL520 connect 預期時間：2-5 秒（一次 connect + set_timeout）。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-16 22:49:01 +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

Author

SHA1

Message

Date

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

ddf0eb8147

fix(local-tool): KL520 首次 connect 跳過不必要的 device reset

使用者 Windows 上 connect KL520 耗時 60+ 秒且前端收到 504 timeout。

根因分析（從 log 逐行推斷）：
  1. server 啟動後首次 connect → needsReset=true → restartBridge()
  2. reset 送出 → KL520 reboot → 退回 KDP2 Loader 模式（USB Boot 裝置，
     reset = firmware 從 RAM 清掉）
  3. USB 重新枚舉 8 秒 → 新 bridge process → 嘗試 reconnect
  4. Loader 模式的 connect_devices_without_check 不穩定 → attempt 1 fail
     (16 秒 timeout) → attempt 2 成功 (4 秒)
  5. 載 firmware fw_scpu.bin → 31 秒
  6. firmware loaded → 再次 reboot → 5 秒後 reconnect
  7. 總時：8 + 16 + 4 + 31 + 5 = 64 秒 > 前端 60 秒 HTTP timeout → 504

但 KL520 是 USB Boot 裝置，每次斷電 firmware + model 就會清掉，connect
時本來就是 clean state。server 啟動後主動 reset 是多餘的——它把完整
firmware 砍掉再重載一次，浪費 60 秒且 Loader 模式 connect 不穩定。

這個 reset 邏輯最初是為 KL720 設計的：KL720 是 flash-based 裝置，
firmware 和 model 保留在 flash，reset 清 stale model 才有意義。

修法：needsReset 條件加上 chipType == "KL720"。KL520 跳過 reset，
直接使用已有的 firmware。如果 KL520 真的有殘留 model 要清（理論上
不會因為它是 RAM-based），下次 load_model 前的 restartBridge 會處理。

修復後 KL520 connect 預期時間：2-5 秒（一次 connect + set_timeout）。

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-04-16 22:49:01 +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

3 Commits