問題現場
低成本雷達在 demo 場合最常見的死法，是被講得太滿——好像能高速、精密、逐人追蹤。但把它放到室內現場跑一陣子就會發現：它真正做得穩的，其實只有一件事——後方某個方向，有沒有東西在靠近。
我要的不是炫技，是一個讓人看了會信、自己講出口也不心虛的後方接近告警。最直覺的做法是把感測器的原始輸出直接接上燈號——我試過，結果畫面一直抖、一直閃，時不時還誤報。看的人要嘛被嚇到，要嘛被那串浮誇的規格帶著誤會。兩種都不是我要的。
最小技術背景
看這頁需要先知道三個詞，其餘用到再說：
- 24GHz 雷達 / LD2450：用無線電波偵測「附近有沒有目標、在哪個方向、大概多遠」的低成本模組。
- 狀態機（state machine）：把情況分成有限幾種狀態，規定彼此之間怎麼轉換，讓行為穩定可預期。
- confidence / hold / fade：信心值（這次偵測有多可信）、保持（短暫丟失先別馬上熄）、淡出（漸滅而非瞬滅）——把不穩的原始訊號平滑成順眼的回饋。
系統架構與資料流
所以我在中間多隔了一層。原始偵測不直接點燈，先進一個狀態機，把雜訊和「偵測間歇掉一兩幀」這種事吸收掉，再決定燈要不要亮：
flowchart LR RAD["LD2450 雷達"] --> DET["偵測｜目標 / 方向 / 距離"] DET --> SM["zone state machine｜分區 + confidence + hold + fade"] SM --> UI["燈效 / UI｜穩定的接近告警"] SM --> VIZ["PC visualizer｜把看不見的狀態可視化"] UI --> AUD["觀眾感受到的：穩定告警，而非生硬 raw data"]
關鍵設計決策（含取捨）
| 決策 | 選了什麼 | 否決的替代 | 為什麼 |
|---|---|---|---|
| 範圍界定 | 先界定 sensor 可靠範圍，只承諾做得穩的 | 宣稱接近量產等級的全能追蹤 | 否決：建立在不穩的假設上，一到現場就破功給大家看 |
| 追蹤精度 | 只做方向分區與接近偵測 | 高速、逐人 identity 追蹤 | 否決：這超出這顆便宜 sensor 撐得住的範圍 |
| 訊號處理 | 狀態機 + confidence + hold + fade | 原始偵測直接驅動燈號 | 否決：會抖、會閃，掉個一兩幀就誤報 |
| 設計順序 | 從「想讓觀眾感受到什麼」倒推狀態機 | 從 sensor 規格往前堆功能 | 否決：很容易做出那種炫技、但一跑久就露餡的東西 |
代表性技術證據
區域狀態機（pseudo-code，示意）
# 不讓「短暫丟失」直接熄燈：用 hold 先撐著，confidence 過門檻才真的算它在（PRESENT）
def step(zone, det):
if det.confidence >= ENTER_TH:
zone.state = "PRESENT"; zone.hold = HOLD_FRAMES
elif zone.hold > 0:
zone.hold -= 1 # 才掉一下下，先撐著別熄
else:
zone.state = fade(zone.state) # 撐到真的沒了才慢慢暗，而不是啪一聲消失
return zone舉個具體的：假設偵測進來是 [有, 有, 無(掉一幀), 有, 無, 無, 無]。沒有 hold，第三幀就會熄一下、閃給觀眾看；加了 hold/fade 之後，燈號變成 [亮, 亮, 亮, 亮, 亮, 漸滅, 滅]——掉一兩幀撐得住，真的離開了才慢慢暗下去。
踩過的坑
| 欄位 | 內容 |
|---|---|
| 症狀 | demo 時某方向燈號間歇閃爍、抖動 |
| 初判（猜錯） | 第一個念頭是 sensor 壞了、還是線沒接好 |
| 驗證 | 印出原始偵測，發現目標其實還在，只是偵測間歇性掉幀 |
| 根因 | 把 raw 偵測直接對應燈號，沒有 hold，掉一幀就熄 |
| 修法 | 加入 hold（短暫丟失先維持）與 fade（漸滅），並設 confidence 門檻 |
| 預防 | 用「間歇掉幀」的合成序列做回歸，確保燈號不再閃 |
驗證方式
- 狀態轉移：用合成事件序列驗證 hold / fade / confidence 門檻的行為。
- 現場：實際擺最多三個目標同時在場，看方向分區準不準、誤報多不多。
- 整合：JS 前端與 Python bridge / dashboard / harness 測試。
- 驗收標準：室內 demo 燈號穩定、不抖、不誤報，且不宣稱高速精密追蹤。
可複製 SOP：做一個誠實又穩的感測 demo
適用情境：用能力有限的感測器，做一個要當眾展示、且要讓人信服的互動 demo。
不適用情境：已是量產級、規格有保證的感測模組，可直接做功能。
前置條件
- 先實測這顆感測器「穩定做得到什麼、做不到什麼」，寫下來。
- 一組可重播的合成事件序列（含掉幀、多目標），當回歸基準。
步驟
- 界定範圍：先白紙黑字寫下 demo「要證明什麼、不證明什麼」，不證明的就別去碰它。
- 倒推體驗：從「想讓觀眾感受到什麼」這個結果，往回設計狀態與回饋。
- 加緩衝層：raw 訊號先過一層狀態機（confidence / hold / fade）再說，別讓它直接點燈。
- 可視化內部狀態：做一個看得見「機器現在以為發生什麼」的 visualizer，調參跟除錯都方便。
- 合成回歸：用掉幀 / 多目標的序列先驗過穩定，再上現場見人。
停損點
- 想加的功能超出 sensor 可靠範圍 → 停，回到「不證明」清單。
- 合成序列出現閃爍 / 誤報 → 先調 hold/fade/門檻，不要上現場。
驗收標準
- demo 燈號穩定、低誤報、室內可重現。
- 對外敘述不含 sensor 做不到的宣稱。
回滾：參數調壞時，回到最後一次「合成序列全穩」的參數組。
可複製到：任何「感測能力有限、但要做可信展示」的場景。
決策回放（三個月後回讀用）
- 背景：用低成本雷達做室內後方接近告警 demo，要可信、不誇大。
- 限制：不宣稱量產 / 高速 / 逐人追蹤；室內；低成本模組。
- 考慮過但放棄：直接拿 raw 偵測驅動燈號——被它的閃爍 / 誤報否決。
- 證據：狀態機 hold/fade 邏輯、合成掉幀回歸、PC visualizer。
- 未解：戶外場景到底穩不穩；要不要再擴充多模組融合。
作者備註： 這案子教我的是「敢講做不到」。一開始我也想讓 demo 看起來什麼都能追，後來發現，把不穩的部分老實圈出去、只在能穩的範圍把體驗做到漂亮，反而更有人信。規格表上少寫一行，現場就少翻一次車——這筆我算得來。