เปิดบทเรียนด้วยของจริงก่อน

ปิดคอร์สแบบเดิมที่เราเปิดคอร์ส — กลับด้าน รันของที่ทำงานได้จริงก่อน (Guardian ตัวเต็ม) แล้วค่อยแกะว่าทำไมมันถึงร้อยครบทั้งสามเสา

วิธีเดิมที่ใช้ทั้งคอร์ส — PRIMM (Predict–Run–Investigate–Modify–Make) วันนี้หนักที่ Make: คุณจะออกแบบผลิตภัณฑ์ของทีมเอง ไม่ใช่แค่เติมช่องว่างแล้วจบ

ชุดบทเรียนสุดท้ายไม่ใช่การสอนของใหม่กองโต แต่คือ "พิสูจน์ว่าเราต่อของเป็น" — หยิบชิ้นส่วนจาก 19 ชุดบทเรียนมาประกอบเป็นชิ้นเดียวที่ทำงานได้และเล่าให้คนอื่นเข้าใจ

เป้าหมายของชุดบทเรียนนี้

จบชุดบทเรียนนี้เราจะเดินครบ แล้วปิดท้ายด้วยการส่งมอบผลิตภัณฑ์ Edge AI ของทีม:

1. Capstone คืออะไร — ต่างจาก "เดโมชิ้นเดียว" ตรงไหน และทำไมต้องข้าม ≥3 เสา
2. สามเสาใน Guardian หนึ่งไฟล์ — DAQ (เซนเซอร์ดิบ) · Processing (กรอง+หน่วง) · Apps (verdict→action)
3. ชั้นตัดสินใจ — CONF_FLOOR + debounce + edge-trigger กัน false positive
4. การตัดสินใจเชิงวิศวกรรม — latency vs false positive vs พลังงาน: เลือกอะไร แลกกับอะไร
5. ลงมือ: เติม 5 บรรทัดสันหลัง ของ s20_capstone.py แล้วออกแบบ Guardian เวอร์ชันของทีม

ปลายทางของวันนี้: กด Load เฝ้าโมเดล ทำเหตุการณ์เป้าหมาย แล้ว Guardian สั่งการเอง (เสียง + แบนเนอร์ + นับครั้ง) โดยไม่เตือนพร่ำจากพีคหลอก

วันนี้เน้น "ประกอบเป็น + อธิบายการออกแบบได้" ไม่ใช่เขียนของใหม่ — ทุกคำสั่งที่ใช้ เราเจอมาหมดแล้วในชุดบทเรียนก่อน ๆ

Capstone คืออะไร — ไม่ใช่ "อีกหนึ่งเดโม"

ตลอดคอร์สเราสร้าง "ชิ้นส่วน" ทีละชิ้น: logger, ฟิลเตอร์, FFT, โมเดลที่ฝึกเอง, action pipeline วันนี้เอามาต่อเป็น ระบบเดียว

• เดโม ตอบคำถาม "ทำได้ไหม" — โชว์ฟีเจอร์เดียว รันในสภาพอุดมคติ
• Capstone / ผลิตภัณฑ์ ตอบ "ใช้ได้จริงไหม" — ต้องรับมือ noise, false positive, การเก็บกวาด, และอธิบายได้ว่าทำไมออกแบบแบบนี้
• ข้อบังคับของ capstone: ต้องข้าม ≥3 เสา ของวงจรชีวิตข้อมูล ไม่ใช่แตะแค่ขั้นเรียกโมเดล

เส้นแบ่งง่ายๆ: เดโมพังเงียบๆ ได้ ผลิตภัณฑ์พังไม่ได้ — มันต้อง "รู้ตัวว่าไม่ชัวร์" และ "ไม่เตือนมั่ว" นี่คือสิ่งที่ capstone ให้คุณพิสูจน์

มองย้อนทั้งคอร์ส — 5 เสาที่เราเดินมา

Guardian ที่จะสร้างวันนี้ ไม่ได้ใช้ของใหม่เลย มันหยิบจากเสาที่เราปูมาทั้งคอร์ส:

เกณฑ์ MVP ของบทเรียน 8.1–8.2 คือ "ข้าม ≥3 เสา" — Guardian ทำครบพอดี และเปิดช่องให้ทีมที่อยากต่อยอดเสียบโมเดลที่ฝึกเอง (เสา Training) หรือ FFT feature (เสา Analysis) เพิ่ม

ชุดบทเรียนนี้อยู่ตรงไหนของคอร์ส

เราปิดวงพอดี — บทเรียน 1.1–1.3 เริ่มที่ ขั้น Apps (รันโมเดลสำเร็จรูป) วันนี้กลับมาที่ Apps อีกครั้ง แต่คราวนี้เราสร้างได้ทั้งวงจร

ความรู้สึกที่อยากให้คุณมีวันนี้: "เมนู 6 โมเดลในชุดบทเรียนแรกเคยเป็นกล่องดำ ตอนนี้เราเปิดกล่องได้ทุกชั้น และประกอบกล่องของเราเองได้แล้ว"

สาธิต — Guardian ทำอะไรบนจอ

ก่อนแกะโค้ด ดูปลายทางก่อน นี่คือสิ่งที่ s20_capstone_full.py โชว์เมื่อรัน:

• เลือกโมเดลใน dropdown (เช่น Motion) กด Load → สถานะ RUNNING
• การ์ดกลางโชว์ คลาสที่ชนะ + conf ที่กรองแล้ว + latency + motion (บริบทจากเสา DAQ)
• ทำเหตุการณ์เป้าหมาย (เขย่า/ร้อง/ไอ) ให้ตรงคลาสสุดท้ายของโมเดล ติดกันหลายครั้ง
• พอครบเกณฑ์ debounce → แบนเนอร์เด้ง ! ALERT ! + เสียงบี๊บ + ตัวนับ alert: N ครั้ง เพิ่มขึ้น
• ทำท่าก้ำกึ่ง/พีคแวบเดียว → Guardian ไม่เตือน เพราะยังไม่ครบเกณฑ์

จุดที่อยากให้จับ: มันไม่ได้ "เจอปุ๊บเตือนปั๊บ" — มันรอให้มั่นใจพอ แล้วค่อยลงมือ นี่คือความต่างระหว่างเดโมกับผลิตภัณฑ์

สามเสาใน Guardian หนึ่งไฟล์

หัวใจของ capstone: สามเสาที่เคยอยู่คนละบทเรียน วันนี้ไหลต่อกันในลูปเดียว

สังเกตว่า conf จากโมเดล (Apps) ไม่ได้ถูกใช้ตรงๆ มันวิ่งผ่านเสา Processing ก่อน (กรอง+หน่วง) แล้วค่อยกลายเป็น action — เสาไม่ได้เรียงกันเฉยๆ มัน "ป้อนกันจริง"

เสา Apps — verdict → decision → action

หัวใจเดิมจากบทเรียน 1.1–1.3 และ 1.6–1.7 กลับมาครบ: อ่านทะเบียน เลือกโมเดล อ่านผล หยุด แล้วเพิ่ม "ตัดสินใจ + สั่งการ"

• ทั้งหมดนี้คุณใช้เป็นตั้งแต่บทเรียน 1.1–1.3 แล้ว — capstone แค่ให้ "เอามาต่อกับเสาอื่น"
• ของใหม่คือชั้น decision: top == alert_idx และ conf ถึงเกณฑ์ ค่อยนับเป็น "เจอ"

เรายึด 4 คำสั่งเดิม (models/select/result/stop) เป็นแกน แล้วห่อชั้นตัดสินใจรอบนอก — โครงนี้คือ pattern ของแอป Edge AI ทุกตัวในโลกจริง

เสา Processing — ทำไมต้องกรอง conf

โมเดลตอบความน่าจะเป็น มันกระโดดขึ้นลงได้ทุกเฟรม ถ้าเอา conf ดิบไปตัดสินใจตรงๆ Guardian จะ "เตือนแล้วเงียบ เตือนแล้วเงียบ" น่ารำคาญและไม่น่าเชื่อถือ

conf_ema = dsp.EMA(alpha=EMA_ALPHA)   # สร้างครั้งเดียวก่อนลูป
...
conf_s = conf_ema.update(r['conf'])   # กรองก่อนเทียบเกณฑ์
sure = conf_s >= edge_ai.CONF_FLOOR

• EMA (Exponential Moving Average) จากบทเรียน Analysis (บทเรียน 4.1–4.2) — ถัวเฉลี่ยถ่วงน้ำหนักอดีต ราคาถูกสุด เขียนบรรทัดเดียว
• alpha มาก = ตอบไวแต่ยังแกว่ง · alpha น้อย = นิ่งแต่ตอบช้า — นี่คือปุ่มออกแบบที่ทีมต้องเลือก
• กรอง conf แล้วยังไม่พอ — เราซ้อน debounce อีกชั้น (ถัดไป)

นี่คือเหตุผลที่โมดูล 4 (Analysis) มีอยู่จริง ไม่ใช่ทฤษฎีลอยๆ: ฟิลเตอร์ตัวเดียวกับที่ทำสัญญาณเซนเซอร์ให้สะอาด วันนี้เอามาทำ "ความมั่นใจ" ให้สะอาดด้วย

คณิตเบื้องหลังเสา Processing — สูตร EMA

ตัวกรอง dsp.EMA ที่เราเติมในช่อง 4 มีสูตรบรรทัดเดียว — ผสมค่าปัจจุบันกับ "ความจำ" ที่กรองไว้แล้ว:

$$s_n = \alpha \, c_n + (1-\alpha)\, s_{n-1}$$

อ่านทีละตัวแบบง่ายๆ:

• $c_n$ — ค่า conf ดิบ ที่โมเดลตอบในเฟรมนี้ (คือ r['conf'])
• $s_n$ — ค่า conf ที่กรองแล้ว ในเฟรมนี้ (คือ conf_s) เอาไปเทียบ CONF_FLOOR
• $s_{n-1}$ — ค่าที่กรองไว้เมื่อเฟรมก่อน (ตัวกรอง "จำ" ให้เราเอง)
• $\alpha$ — น้ำหนักของค่าปัจจุบัน คือ EMA_ALPHA โดย $0 < \alpha \le 1$ ($\alpha$ มาก = เชื่อค่าใหม่มาก, $\alpha$ น้อย = เชื่ออดีตมาก)

ทำไมสำคัญกับชุดบทเรียนนี้: conf ดิบกระโดดขึ้นลงทุกเฟรม ถ้าเอาไปตัดสินใจตรงๆ Guardian จะเตือนๆ เงียบๆ น่ารำคาญ สูตรนี้ถ่วงอดีตเข้ามาช่วย ทำให้ conf "นิ่ง" ก่อนผ่านด่านตัดสินใจ และเป็นเหตุผลที่ต้องสร้าง conf_ema นอกลูป — เพราะมันต้องเก็บ $s_{n-1}$ ข้ามเฟรม ถ้าสร้างใหม่ทุกเฟรมความจำจะถูกล้างทิ้ง

อยากเห็นผลของ $\alpha$ ให้ชัด ลองตั้ง EMA_ALPHA = 0.9 เทียบกับ 0.2 แล้วรัน: 0.9 ตอบไวแต่ยังแกว่ง, 0.2 นิ่งมากแต่ตามช้า — ไม่มีค่าที่ "ถูกที่สุด" มีแต่ค่าที่ "เหมาะกับงานของทีม"

เสา DAQ — เซนเซอร์ดิบเป็นบริบท

Guardian ไม่ได้ดูแค่คำตอบของโมเดล มันอ่านเซนเซอร์ดิบคู่ขนานไปด้วย เพื่อให้ผู้ใช้ (และตัวมันเอง) รู้ "สถานการณ์รอบตัว"

ax, ay, az = sensors.bmi270.acceleration()   # เสา DAQ: อ่านดิบ
mag = (ax*ax + ay*ay + az*az) ** 0.5          # ขนาดเวกเตอร์ความเร่ง
ctx.text("motion: %.1f" % mag)                # โชว์เป็นบริบท

• อยู่นิ่ง mag ~9.8 (แรงโน้มถ่วง) · ถูกจับ/เขย่า mag พุ่งขึ้น
• ประโยชน์จริง: โมเดลเสียง (Baby Cry/Cough) อาจโดน noise การจับเครื่อง รบกวน — เห็น motion สูงตอนได้ verdict ก็รู้ว่าควรระวัง
• นี่คือประตูสู่ sensor fusion: รวม "โมเดลว่าไง" กับ "เซนเซอร์ดิบว่าไง" ก่อนตัดสินใจ (โจทย์ต่อยอด)

การอ่านเซนเซอร์ดิบคือทักษะจากชุดบทเรียน DAQ (โมดูล 2) — capstone เอามาวางข้าง verdict ให้เห็นว่าเสาแรกสุดของวงจรก็ยังมีบทบาทในผลิตภัณฑ์ปลายทาง

ชั้นตัดสินใจ — กัน false positive ยังไง

ปัญหาใหญ่สุดของ Edge AI ที่ใช้งานจริง ไม่ใช่ "เจอไหม" แต่คือ "เตือนมั่วบ่อยแค่ไหน" Guardian ใช้สามด่านกรองซ้อนกัน:

• debounce (streak) ตัดพีคหลอกที่โผล่เฟรมเดียวทิ้ง — ต้อง "ยืนยันตัวเอง" หลายครั้งก่อน
• edge-trigger (fired) ยิงครั้งเดียวตอน "เพิ่งเข้าเหตุการณ์" ไม่รัวทุกเฟรมที่ยังเจออยู่

สามด่านนี้คือ "วิศวกรรมความน่าเชื่อถือ" — ชุดบทเรียน Apps (บทเรียน 6.3–6.4) ปูเรื่อง debounce มาแล้ว วันนี้เอามาเป็นหัวใจการตัดสินใจของผลิตภัณฑ์

คณิตของเสา DAQ + ด่านตัดสินใจ

ขนาดเวกเตอร์ความเร่ง (เติมช่อง 2) — ยุบสามแกนเป็นค่าเดียวที่ไม่ขึ้นกับทิศทางบอร์ด:

$$mag = \sqrt{a_x^2 + a_y^2 + a_z^2}$$

• $a_x, a_y, a_z$ — ความเร่งดิบสามแกนจาก sensors.bmi270.acceleration() (หน่วย m/s²)
• อยู่นิ่ง แรงโน้มถ่วงดึงแกนเดียว จึงได้ $mag \approx 9.8$ · ถูกจับ/เขย่า → $mag$ พุ่งสูงขึ้น

เงื่อนไขยิง action (สามด่านของช่อง 5) — ต้องเป็นจริง พร้อมกันทั้งหมด ถึงนับว่า "เจอ":

$$\text{fire} \iff (top = \text{alert\_idx}) \;\wedge\; (s_n \ge \text{CONF\_FLOOR}) \;\wedge\; (\text{streak} \ge \text{HITS\_NEEDED})$$

• ด่านหนึ่งดูว่าคลาสถูกตัว · ด่านสองดูว่ามั่นใจพอ (ใช้ $s_n$ ที่กรองแล้ว ไม่ใช่ $c_n$ ดิบ) · ด่านสามดูว่า "ติดกันพอ"
• $\wedge$ คือ AND — สัญลักษณ์นี้แหละที่บังคับให้ทั้งสามต้องผ่านพร้อมกัน

ทำไมสำคัญ: false positive ส่วนใหญ่ผ่านได้แค่หนึ่งหรือสองด่าน การบังคับ $\wedge$ ครบสามคือเหตุผลที่พีคหลอกแวบเดียวไม่ทำให้ Guardian เตือน

ร้อยกลับเข้าสามเสา: เสา DAQ ให้ $mag$, เสา Processing ให้ $s_n$, เสา Apps รวมทุกอย่างเป็น $\text{fire}$ — คณิตสามบรรทัดนี้คือสามเสาในการตัดสินใจครั้งเดียว

การตัดสินใจเชิงวิศวกรรม — เลือกอะไร แลกกับอะไร

capstone ที่ดีต้อง "อธิบายการแลกเปลี่ยนได้" ไม่ใช่แค่ "รันได้" ทุกปุ่มออกแบบมีราคาสองด้าน:

• ไม่มีค่า "ถูกที่สุด" — ขึ้นกับงาน: ตรวจการล้มของผู้สูงอายุ ยอม false positive ดีกว่า miss · ป้ายโฆษณากวักมือ ยอม miss ดีกว่ากวนคนเดิน
• งานทีมวันนี้: เลือกค่าพวกนี้ แล้วเขียนเหตุผล ว่าทำไม เหมาะกับผลิตภัณฑ์ของคุณ

นี่คือคำถามวิศวกรที่คอร์สฝึกมาทั้งเทอม — "โมเดลตัวนี้ควรอยู่ที่ไหน / ตั้งเกณฑ์เท่าไร / แลกอะไรกับอะไร" capstone คือที่ที่คุณตอบด้วยผลิตภัณฑ์จริง

design → build → ship

capstone ไม่ได้เริ่มที่โค้ด มันเริ่มที่ ออกแบบ แล้วค่อยสร้าง แล้วค่อยส่งมอบ — สามจังหวะเดียวกับงานจริง

อย่ากระโดดไป Build เลย — ใช้เวลา 15 นาทีแรกที่ Design ในบันทึกการเรียน (เฝ้าอะไร ทำไม, action คืออะไร, ตั้งเกณฑ์เท่าไรเพราะอะไร) แล้ว Build จะเร็วและตรง

รู้จักโมดูลที่ capstone ใช้

Guardian ยืนบนโมดูลที่เราคุ้นมือแล้วทั้งหมด — ไม่มี API ใหม่ให้จำ มีแต่การเอามาต่อกัน

• ทุกตัวเป็น API จริงที่ใช้มาทั้งคอร์ส บนบอร์ดกับ Emulator เหมือนกัน (BENTO IDE มีคำอธิบายของแต่ละคำสั่งในตัว)
• ui.tone(note, wave, vol, ms) เล่นเสียงผ่าน SFX mixer ฝั่ง CM55 — เราใช้ยืนยัน action

ถ้าอยากทบทวนคำสั่งไหน เปิด REPL ถามฮาร์ดแวร์ตรงๆ ได้เลย เช่น import edge_ai; edge_ai.models() — นิสัย "ถามก่อนเดา" จากบทเรียน 1.1–1.3 ยังใช้ได้จนชุดบทเรียนสุดท้าย