Raspberry Pi 5 + YOLOv8: ระบบนับรถพลังงาน Solar แบบไม่แตะถนน

ถ้าอยากนับรถที่วิ่งผ่านถนนสองทิศทาง เราไม่จำเป็นต้องฝัง Sensor ลงบนพื้นถนนเสมอไป Project Thesis ของ Marios Christoforou เลือกใช้ Raspberry Pi 5, กล้อง USB และ Machine Vision เพื่อ Detect, Track และ Count รถที่เคลื่อนผ่านกล้อง ก่อนส่งเฉพาะจำนวนรถขึ้น Database

สิ่งที่ทำให้ Project นี้น่าสนใจกว่า Vehicle Detection Demo ทั่วไป คือผู้สร้างพยายามทำให้ระบบใช้งานแบบ Standalone ได้: ลด Load ของ Raspberry Pi, ลดการใช้พลังงานเหลือเฉลี่ยประมาณ 5.6 W และออกแบบระบบ Solar Panel 100 W ร่วมกับ Battery 600 Wh สำหรับติดตั้งในพื้นที่ที่ต้องการความเป็นอิสระด้านพลังงาน

ระบบ Traffic Monitoring ด้วย Raspberry Pi และกล้องสำหรับตรวจจับและนับรถ
Solar-powered Traffic Monitoring Project ใช้ Raspberry Pi และกล้องเพื่อประมวลผลรถที่ผ่านจุดตรวจด้วย Machine Vision
Key Takeaways
  • ใช้ Raspberry Pi 5 4GB ร่วมกับกล้อง USB 720p
  • YOLOv8 Nano ตรวจ Car, Truck, Bus และ Motorcycle
  • Kalman Filter ใช้ทำนายตำแหน่ง ส่วน Greedy IoU ใช้เชื่อม Detection กับ Track เดิม
  • POINT_A และ POINT_B ใช้เป็นแกนสำหรับวิเคราะห์ทิศทางการเคลื่อนที่
  • Final System ทำงานประมาณ 10 FPS และกินไฟเฉลี่ยประมาณ 5.6 W
  • ระบบ Solar ที่เสนอใช้ Panel 100 W และ Battery 12 V 50 Ah หรือ 600 Wh
  • 96.6% ใน Source คือ Total Count Agreement ของ Test Video ชุดหนึ่ง ไม่ใช่ YOLO mAP
  • ภาพถูกประมวลผลบนอุปกรณ์ และ Cloud รับเพียง UTC Timestamp กับจำนวนรถรวมสองทิศทาง

Solar Traffic Monitoring ตัวนี้คืออะไร?

Project นี้เป็น Final-year Thesis สำหรับหลักสูตร Computer Engineering ที่ University of Cyprus โดยเป้าหมายคือสร้างอุปกรณ์ที่สามารถนับรถ ที่เคลื่อนผ่านจุดหนึ่งบน Campus ได้สองทิศทาง และส่งข้อมูลเป็นช่วง ๆ ไปยัง Cloud Database

ผู้สร้างเลือกใช้ Camera-based Machine Vision เพื่อหลีกเลี่ยงการติด Sensor ลงในโครงสร้างถนน และให้ระบบสามารถปรับ Configuration ให้เข้ากับ Scene ใหม่ได้

USB Camera
Capture ภาพถนน
↓
Raspberry Pi 5
Crop และประมวลผล Frame
↓
YOLOv8 Nano
Detect รถในแต่ละ Frame
↓
Kalman + Greedy IoU
Track รถข้ามหลาย Frame
↓
Direction Classification
แยก POINT_A / POINT_B
↓
Vehicle Counter
ป้องกัน Double-counting ด้วย Counted Flag
↓
MySQL
Upload Timestamp + Aggregate Counts

ทำไมเลือกกล้องแทน Sensor บนถนน?

เป้าหมายของผู้สร้างคือระบบที่ติดตั้งได้โดยไม่รบกวน Road Infrastructure หรือการไหลของ Traffic กล้องจึงช่วยให้การตรวจจับเกิดขึ้นจากภาพ แทนการฝัง Detector ลงในพื้นถนน

ข้อดีอีกด้านคือ Software สามารถใช้ Bounding Box และตำแหน่งของ Object เพื่อ Track รถหลายคันพร้อมกัน รวมถึงแยกว่ารถแต่ละคันกำลังเคลื่อนที่ไปทิศไหน

ไม่ได้แปลว่ากล้องเหมาะกับทุก Location: Performance ยังขึ้นกับ Camera View, Lighting, Scene Configuration และสิ่งกีดขวาง Source ไม่ได้ให้ Accuracy Guarantee สำหรับทุกถนนหรือทุกสภาพอากาศ

Hardware ใช้อะไรบ้าง?

Hardware รายละเอียดจาก Source
Computer Raspberry Pi 5 4GB
Operating System Raspberry Pi OS 64-bit ตาม Thesis
Camera Basic 720p USB Webcam
Cooling Raspberry Pi Active Cooler ตาม Thesis
Solar Panel 100 W
Battery 12 V Lead-acid, 50 Ah / 600 Wh

หน้า Project ยังระบุว่า Raspberry Pi 5 รุ่น 2GB ก็น่าจะสามารถรัน Software นี้ได้ แต่ Source ไม่ได้ให้ Benchmark แยกของรุ่น 2GB จึงควรถือเป็นข้อความจากผู้สร้างมากกว่าผลทดสอบเปรียบเทียบ

Machine Vision Pipeline ทำงานอย่างไร?

Main Loop เริ่มจาก Capture Frame แล้ว Crop ภาพตาม Configuration ก่อนส่งให้ YOLOv8 Nano

Model ตรวจ Object ที่อยู่ใน Vehicle Classes ได้แก่:

  • Car
  • Truck
  • Bus
  • Motorcycle

Output จาก YOLO เป็น Bounding Box แต่ Bounding Box เพียงอย่างเดียวยังไม่รู้ว่า รถใน Frame ปัจจุบันคือรถคันเดียวกับ Frame ก่อนหรือไม่ จึงต้องมี Tracking ขั้นต่อไป

ระบบรู้ได้อย่างไรว่ารถใน Frame ใหม่คือคันเดิม?

Software ใช้ Kalman Filter เพื่อทำนายตำแหน่งปัจจุบันของรถแต่ละ Track จากตำแหน่งและ Velocity ที่เคยเห็น

จากนั้นใช้ Greedy IoU หรือ Intersection over Union เปรียบเทียบ Detection ใหม่กับตำแหน่งที่แต่ละ Track ถูกคาดการณ์ไว้

Track เดิม
มีตำแหน่งและความเร็วจาก Frame ก่อน
↓
Kalman Prediction
ทำนายว่ารถควรอยู่ตรงไหนใน Frame ใหม่
+
YOLO Detection
Bounding Box ที่พบจริงใน Frame ใหม่
↓
Greedy IoU Matching
Match Prediction กับ Detection
↓
Maintain ID
รถคันเดิมยังใช้ Track ID เดิม

หาก Track ไม่ Match กับ Detection ระบบยังสามารถใช้ Prediction ของ Kalman ต่อไปได้ช่วงหนึ่ง ก่อนจะถือว่า Object หายและลบ Track

หากมี Detection ใหม่ที่ไม่ Match กับ Track ใดเลย Software จะสร้าง Track ใหม่และกำหนด Unique ID ให้

Source ไม่ได้ให้ Tracking Parameter ครบ: ไม่มีค่า IoU Threshold, Kalman Covariance, Track Timeout หรือจำนวน Frame ที่ใช้ทุกขั้นตอนแบบที่สามารถนำไปสร้าง Code ใหม่ได้ บทความนี้จึงไม่เติมค่าเหล่านั้นเอง

POINT_A และ POINT_B ใช้แยกทิศทางอย่างไร?

ใน Configuration ผู้ใช้กำหนด POINT_A และ POINT_B ให้เป็นสองทิศทางหลักที่รถเคลื่อนที่ไป

ตัวอย่างที่ผู้สร้างอธิบาย: หากถนนอยู่แนวนอนกับ Frame POINT_A อาจอยู่ด้านซ้าย และ POINT_B อยู่ด้านขวา

เมื่อ Track ถูกติดตามมานานพอ Software จะ Project ตำแหน่งของรถลงบนเส้นระหว่าง POINT_A กับ POINT_B แล้วดูว่าค่าดังกล่าวเปลี่ยนไปทางไหนเมื่อเวลาผ่านไป

เมื่อระบุ Direction ได้แล้ว รถจะถูกเพิ่มลง Counter และถูก Flag ว่า Counted เพื่อไม่ให้นับรถคันเดิมซ้ำ

ใน Preview ของผู้สร้าง: Bounding Box เริ่มต้นเป็นสี Teal แล้วเปลี่ยนเป็น Red เมื่อรถถูก Classify ว่าเคลื่อนซ้าย หรือ Green เมื่อเคลื่อนขวา

Thesis ยังอธิบาย Configuration MASK_RECT และ CROP_RECT เพิ่มเติมสำหรับจัดการส่วนของ Scene ที่ไม่ควรนำมาใช้ประมวลผล

จาก Version แรกจนถึง YOLOv8 Nano

จุดที่น่าสนใจของ Thesis นี้คือระบบไม่ได้เริ่มต้นด้วย Pipeline ปัจจุบันทันที แต่ผ่านการทดลองหลายแนวทาง

Version แรก: Detection จาก Frame

ผู้สร้างพบว่าการพยายามระบุทิศทางจากข้อมูลใน Frame เดียว ไม่เพียงพอสำหรับการ Track Movement ที่ต้องรู้ว่า Object เคลื่อนอย่างไรเมื่อเวลาผ่านไป

Version สอง: Background Subtraction

การใช้ Background Subtraction สามารถหา Motion ได้ แต่เกิดปัญหาจาก Light Reflection และการเปลี่ยนแสง ซึ่งสร้าง Motion ที่ไม่ใช่รถจริง อีกทั้ง Performance ยังไม่ตอบโจทย์

Version ปัจจุบัน: YOLOv8 + Tracking

การใช้ YOLOv8 Nano ช่วยให้ระบบสนใจ Object ในกลุ่ม Vehicle โดยตรง จากนั้นจึงใช้ Kalman Filter และ IoU เพื่อรักษา Track ข้าม Frame

บทเรียนจาก Creator Journey: Object Detection อย่างเดียวไม่พอสำหรับ Traffic Counter เพราะระบบยังต้องแก้โจทย์ “รถคันนี้คือคันเดิมหรือคันใหม่?” และ “กำลังเดินทางไปทิศไหน?”

Optimize Raspberry Pi อย่างไรให้ได้ทั้ง FPS และประหยัดไฟ?

Project นี้ไม่ได้ Optimize เพื่อ FPS อย่างเดียว เพราะระบบสุดท้ายต้องใช้ Solar Power ดังนั้น Performance ต่อ Watt จึงสำคัญมาก

Hardware / OS Optimization

  • Disable Bluetooth
  • Disable PCIe
  • Disable Audio
  • Disable HDMI ทั้งสอง Port
  • ลด CPU จาก 2400 MHz เหลือ 2000 MHz
  • ลด GPU Clock เป็น 400 MHz ตาม Project Overview
  • Undervolt CPU ด้วย Preset -2
  • ตั้ง CPU Governor เป็น Conservative

Software Optimization

  • Fuse YOLOv8 Nano Model
  • ใช้ Memory Pre-allocation
  • เพิ่ม Headless Mode
  • Skip Rendering ของ Object ที่ไม่จำเป็น
  • ลด Camera Capture Resolution
  • Crop ส่วนของ Frame ที่ไม่สำคัญออกจริง แทนการ Mask อย่างเดียว
Stage จาก Thesis Performance Power
Initial System ประมาณ 8.9 FPS ประมาณ 8 W
Disable Hardware + Headless ประมาณ 9.5 FPS ประมาณ 7 W
Crop ส่วนภาพที่ไม่สำคัญ ประมาณ 12.2 FPS Source ไม่ได้ล็อกค่า Power ของ Step นี้ใน Summary
Final Underclock / Undervolt Configuration ประมาณ 10 FPS ประมาณ 5.6 W
ทำไม Final เหลือประมาณ 10 FPS ทั้งที่เคยได้ 12.2 FPS? เพราะเป้าหมายสุดท้ายไม่ใช่ Maximum FPS แต่เป็นการ Trade-off ระหว่างความเร็วกับ Power Consumption สำหรับระบบที่ต้องพึ่ง Solar + Battery
เรื่องตัวเลข 35% / 37%: หน้า Project Overview สรุปว่า Optimization เพิ่ม Performance 35% และลด Power Consumption 37% ขณะที่ Thesis แสดงผลแบบ Step-by-step ด้วย Baseline หลายช่วง ดังนั้นบทความนี้ไม่รวมตัวเลขทั้งหมดให้เป็น Benchmark เดียว

96.6% หมายถึงอะไรจริง ๆ?

ตัวเลขนี้เป็นจุดที่ควรอ่านอย่างระวังที่สุด เพราะหน้า Overview ใช้คำว่า “96.6% detection and classification accuracy” แต่ Thesis อธิบายวิธีได้ตัวเลขนี้ละเอียดกว่า

175 คัน Manual Ground Truth
181 คัน Software Count
≈96.6% Total Count Agreement
Direction Manual Count Software Count
Direction 1 119 120
Direction 2 56 61
Total 175 181

ระบบจึง Over-count รวม 6 คัน ซึ่ง Thesis คำนวณเป็น Count Error ประมาณ 3.4% และ Total Count Agreement ประมาณ 96.6%

96.6% ไม่ใช่ YOLO mAP, Precision หรือ Recall: เป็นความสอดคล้องของจำนวนรถรวม ระหว่าง Software กับ Manual Ground Truth ใน Test Video ชุดนี้ ไม่ควรนำไปโฆษณาว่า YOLOv8 Nano ในระบบนี้มี Detection Accuracy 96.6%

Test Video ถูกบันทึกที่ Location ที่เสนอ ในวันที่ 21 พฤศจิกายน 2025 ช่วงประมาณ 10:15–10:35 และหลังตัดช่วงไม่มีรถออก Video ที่ใช้ทดสอบมีความยาวประมาณ 17 นาที

ดังนั้นตัวเลขนี้เป็นผลจาก Standardized Test Case ของ Thesis ไม่ใช่การ Guarantee Performance สำหรับถนนทุกแบบ

ระบบทำงานกลางคืนได้แค่ไหน?

Source ระบุว่ามีการทดสอบในเวลากลางคืน และระบบสามารถทำงานได้เมื่อ Scene มี Street Lighting

อย่างไรก็ตาม Thesis อธิบายบริบทว่าเป็นการทดสอบกลางคืนแบบสั้น ไม่ใช่ Long-term Validation ในหลาย Lighting Condition

Bad Weather ยังไม่ได้ Validate: Source ไม่ได้ให้ Test Result ที่ยืนยัน Performance ในฝนหนัก หมอก หรือสภาพอากาศเลวร้าย และไม่ได้ระบุ Weatherproof Enclosure Rating

ระบบส่งข้อมูลอะไรขึ้น MySQL?

หากเปิด Data Upload ใน Configuration Software จะอัปโหลดข้อมูลเป็นช่วง ๆ ไปยัง Remote MySQL Database

แต่ละ Record ประกอบด้วย:

  • UTC Timestamp
  • จำนวนรถที่เคลื่อนไปทาง POINT_A
  • จำนวนรถที่เคลื่อนไปทาง POINT_B

หลัง Upload สำเร็จ Counter จะ Reset เป็นศูนย์ เพื่อเริ่มสะสมข้อมูลสำหรับ Period ถัดไป

Source ไม่ได้ระบุ Database Detail ครบ: ไม่มี Schema เต็ม, Cloud Provider, Upload Interval แบบค่าตายตัว หรือ Security Configuration ที่เพียงพอสำหรับสร้าง Deployment ใหม่จากบทความนี้

กล้องเห็นรถ แต่ไม่ต้องเก็บภาพขึ้น Cloud

Privacy เป็นหนึ่งใน Design Consideration ที่ผู้สร้างกล่าวถึงโดยตรง

Frame จากกล้องถูกใช้เพื่อทำ Machine Vision บน Raspberry Pi และอยู่ใน Volatile Memory ระหว่างกระบวนการประมวลผล

เมื่อได้ข้อมูลตำแหน่งของรถแล้ว Image ไม่ได้ถูกเก็บเป็น Persistent Dataset สำหรับระบบ Monitoring ปกติ

ข้อมูลที่ส่งขึ้น Cloud จึงเป็นเพียง:

  • UTC Timestamp
  • Aggregated Count ไปทาง POINT_A
  • Aggregated Count ไปทาง POINT_B
Edge AI ใน Project นี้ไม่ได้ช่วยแค่ Performance: การประมวลผลภาพบน Device ช่วยลดความจำเป็นในการส่ง Raw Camera Frames ขึ้น Cloud ด้วย
อย่าขยายความเป็น Compliance Claim: Source อธิบายแนวทางลดข้อมูลที่จัดเก็บ แต่ไม่ได้ระบุ Certification หรือรับรองว่า Deployment เป็นไปตาม Privacy Regulation ทุกประเทศ

Power 5.6 W กลายเป็น Solar System 100 W ได้อย่างไร?

Final Configuration มี Average Power Draw ประมาณ 5.6 W

หากทำงานต่อเนื่อง 24 ชั่วโมง Thesis คำนวณ Daily Energy Requirement ได้ประมาณ:

5.6 W × 24 h = 134.4 Wh/day
จากนั้นผู้สร้างใช้ Design Load ประมาณ 140 Wh/day สำหรับขั้นตอน Solar Sizing

จากนั้นจึงใช้ข้อมูล Solar Production และ PVGIS เพื่อประเมินขนาด Panel และ Battery ที่ต้องการ

Solar 100 W + Battery 600 Wh ถูกเลือกอย่างไร?

Parameter ค่าที่ใช้ใน Project
Solar Panel 100 W
Tilt 45°
Orientation South-facing สำหรับ Location ที่ออกแบบ
Battery 12 V Lead-acid
Capacity 50 Ah / 600 Wh nominal
Design Load ประมาณ 140 Wh/day

ผู้สร้างใช้ทั้งข้อมูลจาก Residential Solar Installation และ Photovoltaic Geographical Information System หรือ PVGIS เพื่อประเมินว่าระบบสามารถรักษาการทำงานในช่วง Solar Generation ต่ำได้หรือไม่

หน้า Overview สรุปว่า Worst-case Winter Scenario ควรให้ระบบ Self-sufficient ได้อย่างน้อยประมาณ 3 วัน

ขณะที่ Thesis กล่าวถึง Design Objective สำหรับ Energy Autonomy ประมาณ 4 วัน ดังนั้นสองตัวเลขนี้ควรถูกมองใน Context คนละส่วนของการออกแบบ ไม่ใช่ Specification เดียวกัน

Solar System เป็น Proposed / Modelled Setup: ผู้สร้างระบุว่าไม่มีเวลาทำ Long-term Full Deployment ของระบบพร้อม Solar ทั้งชุด ดังนั้นผลนี้มาจาก Power Measurement, Solar Data และ Simulation ไม่ใช่การพิสูจน์จากการใช้งานกลางแจ้งต่อเนื่องตลอดฤดูหนาวจริง

ข้อจำกัดของระบบที่ต้องรู้

1. ไม่มี Low-voltage Disconnect ใน Power Setup แบบที่เสนอ

Source ระบุว่า Charging จะหยุดเมื่อ Battery ถึง 13.5 V แต่ Setup แบบง่ายนี้ไม่มีระบบหยุดโหลดเมื่อ Battery ถูก Discharge ต่ำเกินไป

การทำ Deep Discharge ซ้ำ ๆ สามารถลดอายุการใช้งานของ Lead-acid Battery ได้ตามข้อสังเกตของผู้สร้าง

2. Outdoor Deployment ยังไม่ถูก Validate ระยะยาว

ยังไม่มี Long-term Test ของทั้งระบบ รวม Solar, Battery, Weather Exposure และ Camera ในสภาพแวดล้อมจริงต่อเนื่อง

3. Bad Weather ยังเป็น Unknown

Source ไม่ได้ให้ Validation Result สำหรับฝน หมอก หรือสภาพอากาศเลวร้าย

4. Accuracy เป็น Scene-dependent

ผล 96.6% มาจาก Test Video และ Configuration หนึ่งชุด ไม่ควรใช้เป็น Performance Guarantee เมื่อเปลี่ยนถนน Camera Angle หรือ Traffic Pattern

Power Safety: Project ใช้ Solar Panel และ Lead-acid Battery แต่ Source ที่ใช้ในบทความนี้ไม่ได้ให้ Complete Field Wiring, Fuse Sizing, Cable Sizing หรือ Charge-controller Specification ดังนั้นบทความนี้จะไม่สร้าง Wiring ระบบพลังงานเพิ่มจากการคาดเดา

Maker ได้อะไรจาก Project นี้?

1. Object Detection ไม่เท่ากับ Object Tracking

YOLO บอกได้ว่ามีรถตรงไหน แต่ระบบนับรถยังต้องรู้ว่า Detection ใหม่ เป็นรถคันเดิมหรือไม่

2. Direction Classification ต้องอาศัยเวลา

การบอกว่ารถวิ่งซ้ายหรือขวา ต้องวิเคราะห์ตำแหน่งของ Track หลาย Frame ไม่ใช่ดูภาพนิ่งเพียง Frame เดียว

3. Crop ภาพคือ Optimization ที่ทรงพลัง

การไม่ประมวลผล Pixel ที่ไม่จำเป็น ช่วยลด Load ตั้งแต่ต้น Pipeline และใน Test ของ Thesis การ Crop ช่วยเพิ่ม Performance จากประมาณ 9.5 เป็น 12.2 FPS

4. Maximum Performance ไม่ได้ดีที่สุดเสมอ

Final System ยอมลด Performance เหลือประมาณ 10 FPS เพื่อให้ Average Power ลงมาอยู่ราว 5.6 W ซึ่งสำคัญต่อ Solar Sizing มากกว่า FPS สูงสุด

5. Edge AI ช่วยเรื่อง Privacy

การประมวลผล Camera Frame บน Raspberry Pi ทำให้ Cloud ไม่จำเป็นต้องรับ Raw Image และเก็บเพียง Aggregate Count

6. AI Project ที่จะออกนอก Lab ต้องคิดเรื่อง Energy ด้วย

จาก 5.6 W ไปถึง 140 Wh/day แล้วต่อไปถึง Solar 100 W และ Battery 600 Wh แสดงให้เห็นว่า Deployment จริงต้องคิดไกลกว่า Model Accuracy

โปรเจกต์นี้มีหลายขั้น แนะนำอ่านต้นฉบับควบคู่กัน

Project นี้มีรายละเอียดตั้งแต่ Machine Vision Algorithm ไปจนถึง Power Optimization และ Solar Sizing จึงควรเปิด Thesis ต้นฉบับประกอบ โดยเฉพาะหากต้องการนำแนวคิดไปสร้างระบบจริง

FAQ: คำถามที่พบบ่อย

1. Project ใช้ Raspberry Pi รุ่นอะไร?

ใช้ Raspberry Pi 5 4GB เป็น Hardware หลัก

2. ใช้กล้องอะไร?

Source ระบุ Basic 720p USB Webcam แต่ไม่ได้ระบุ Brand หรือ Model

3. ใช้ AI Model อะไรตรวจรถ?

ใช้ YOLOv8 Nano

4. Detect รถประเภทไหน?

Source ระบุ Car, Truck, Bus และ Motorcycle

5. ทำไมต้องใช้ Kalman Filter?

ใช้ทำนายตำแหน่งปัจจุบันของ Track จากตำแหน่งและ Velocity ก่อนหน้า เพื่อช่วยเชื่อม Object ข้าม Frame

6. Greedy IoU ใช้ทำอะไร?

ใช้ Match Detection ใน Frame ปัจจุบัน กับตำแหน่งที่คาดการณ์ของ Existing Tracks

7. ระบบแยกทิศทางรถอย่างไร?

ใช้การเปลี่ยนตำแหน่งของ Track เมื่อ Project ลงบนเส้นระหว่าง POINT_A และ POINT_B

8. 96.6% คือ Accuracy ของ YOLO หรือไม่?

ไม่ใช่ ตัวเลขนี้มาจาก Total Count Agreement ระหว่าง Manual Ground Truth 175 คัน กับ Software Count 181 คัน ใน Test Video ชุดหนึ่ง

9. ระบบทำงานกี่ FPS?

Final Configuration ทำงานประมาณ 10 FPS ตาม Source

10. กินไฟเท่าไร?

Final System มี Average Power Draw ประมาณ 5.6 W

11. ใช้ Solar Panel ขนาดเท่าไร?

Proposed Setup ใช้ Solar Panel 100 W ที่ Tilt 45°

12. Battery มีขนาดเท่าไร?

12 V 50 Ah Lead-acid หรือประมาณ 600 Wh nominal ตาม Source

13. ระบบ Solar ทำงานได้กี่วัน?

Overview กล่าวถึง Worst-case Winter Scenario อย่างน้อยประมาณ 3 วัน ขณะที่ Thesis ตั้งเป้าระดับ Design สำหรับ Energy Autonomy ประมาณ 4 วัน ทั้งสองตัวเลขมาจากบริบทการออกแบบและ Simulation ไม่ใช่ Long-term Full Field Test

14. ใช้กลางคืนได้หรือไม่?

Source ระบุว่ามี Short Night Test และใช้งานได้เมื่อมี Street Lighting แต่ไม่ได้รับรองทุกสภาพแสง

15. ใช้งานตอนฝนตกได้หรือไม่?

Source ไม่ได้ Validate Performance ใน Bad Weather และไม่ได้ระบุ Outdoor Enclosure Rating

16. ระบบอัปโหลดภาพรถขึ้น Cloud หรือไม่?

Design ของ Project ประมวลผลภาพบน Device และอัปโหลดเพียง Timestamp กับ Aggregate Vehicle Counts

17. ใช้ Raspberry Pi 5 2GB ได้ไหม?

ผู้สร้างระบุว่า Software น่าจะรันบนรุ่น 2GB ได้ แต่ Source ไม่ได้ให้ Benchmark แยกเพื่อเปรียบเทียบกับรุ่น 4GB

18. มี Source Code ให้หรือไม่?

ใน Source ที่ใช้สำหรับบทความนี้ ยังไม่มี Python Source File ที่ถูก Verify เพียงพอสำหรับนำมาแสดงเป็น Code Snippet จึงไม่ได้สร้าง Code เพิ่มขึ้นเอง

References / แหล่งข้อมูลต้นฉบับ

Edge AI Project ไม่ได้จบแค่ตอน Model Detect ได้

Project นี้ทำให้เห็นครบตั้งแต่ Computer Vision, Object Tracking, Data Privacy และ Performance Optimization ไปจนถึง Power Budget และ Solar Sizing สำหรับการนำระบบออกจากโต๊ะทดลอง

หากกำลังทำ Raspberry Pi, Edge AI หรือ Computer Vision Project สามารถสอบถามทีม Globalbyte เรื่อง Development Board, Camera, Storage และ Maker Accessories ที่เหมาะกับ Project ได้

Disclaimer: บทความนี้เป็นการสรุปและเรียบเรียงจากแหล่งข้อมูลภาษาอังกฤษ อาจมีความคลาดเคลื่อน กรุณาตรวจสอบ Source ต้นฉบับก่อนลงมือทำ ตัวเลข Total Count Agreement ประมาณ 96.6% เป็นผลจาก Test Video ชุดหนึ่งและไม่ใช่ค่า mAP, Precision หรือ Recall ของ YOLOv8 Nano ผลด้าน FPS และ Power Consumption ขึ้นกับ Configuration และ Optimization ที่ผู้สร้างใช้ ส่วนระบบ Solar 100 W + Battery 600 Wh เป็น Proposed / Modelled Setup ที่ประเมินจาก Power Measurement, Solar Data และ PVGIS ไม่ใช่ผลจาก Long-term Full Field Deployment Source ยังไม่ได้ Validate Bad-weather Performance, ไม่ได้ระบุ Weatherproof Enclosure Rating และไม่ได้ให้ Complete Solar Wiring, Fuse Size, Cable Size หรือ Low-voltage Disconnect Design จึงควรตรวจสอบรายละเอียดด้าน Electrical Safety และ Power System เพิ่มก่อนสร้างระบบใช้งานจริง

แท็ก


Blog posts