TerraGuard รถ Rover ใช้ Arduino UNO Q + Edge AI สำรวจความเสี่ยงไฟป่า

ดาวเทียมและ Drone เหมาะกับการมองพื้นที่จากด้านบน แต่ใต้เรือนยอดป่าหนา ๆ ยังมีใบไม้แห้ง สนเข็มแห้ง และ Brush ที่สะสมอยู่ระดับพื้น ซึ่งเป็นสิ่งที่ผู้สร้าง TerraGuard อยากลงไปสำรวจให้ใกล้กว่านั้น

TerraGuard จึงเป็น 4WD Scout Rover ที่ขับไปตามทางป่า วัด Temperature และ Humidity, ใช้กล้อง XIAO ESP32S3 Sense ถ่ายพื้นด้านหน้า แล้วส่งภาพเข้า Arduino UNO Q เพื่อรัน MobileNetV2 ผ่าน ONNX Runtime แบบ Local และแบ่งภาพออกเป็น Low, Medium หรือ High Risk

จุดที่น่าสนใจคือ Project นี้ไม่ได้จบแค่ AI Classification: มี Encoder, IMU, GPS, BLE Android Controller, Teach / Waypoints / Autonomous Replay, Camera Pan Servo และ Mission Map รวมอยู่ใน Rover คันเดียว

TerraGuard autonomous rover สำหรับสำรวจพื้นป่า
TerraGuard: Wildfire Risk Scout รถ Rover ที่ใช้ Arduino UNO Q, Sensor และ Edge AI สำรวจสภาพพื้นป่า
Key Takeaways
  • Arduino UNO Q แบ่งงานระหว่าง STM32 สำหรับ Real-time I/O กับ Linux สำหรับ AI / Navigation
  • XIAO ESP32S3 Sense ทำหน้าที่เป็นกล้อง Wi-Fi MJPEG แยกจาก Main Computer
  • Dataset ถูกเก็บจาก Rover จริงประมาณ 400 ภาพ ไม่ใช่ Aerial Image จาก Internet
  • AI ใช้ MobileNetV2 แบ่งพื้นป่าเป็น Low / Medium / High Risk
  • Test Set 53 ภาพให้ Accuracy ประมาณ 64.2% และ Weighted F1 ประมาณ 0.67
  • High-risk Recall 100% มาจากตัวอย่าง High-risk เพียง 6 ภาพ และ Precision ของ Class นี้ประมาณ 31.6%
  • ระบบมี Teach, Waypoints และ Autonomous Drive Replay
  • GPS ไม่ได้ถูกใช้เป็นแหล่งหลักของ Autonomous Navigation หลังพบ Error ใน Field Test
  • Project เป็น Maker / Research Prototype ไม่ใช่ Certified Wildfire Detection System

TerraGuard คืออะไร?

แนวคิดของ TerraGuard คือส่ง Sensor และ Camera ลงไปใกล้พื้นป่า เพื่อประเมินสภาพ Surface Fuel เช่นใบไม้แห้ง สนเข็มแห้ง หรือ Brush ที่อาจมองเห็นได้ยากจากด้านบน

Forest FloorCamera + SensorsEdge AIRisk ClassificationMission Map

คำสำคัญคือ Risk Scout ไม่ใช่ Fire Detector: Project ประเมินลักษณะพื้นและ Microclimate ไม่ได้ตรวจ Flame, Smoke หรือ Thermal Signature โดยตรง

Architecture: Arduino UNO Q แบ่งงาน Linux กับ STM32 อย่างไร?

จุดเด่นของ UNO Q ใน Project นี้คือ Hardware เดียวมีทั้ง Real-time Microcontroller และ Linux Application Processor แล้วสื่อสารกันผ่าน RPC Bridge

XIAO CameraWi-Fi MJPEGUNO Q LinuxONNX + Navigation
UNO Q LinuxRPC BridgeUNO Q STM32Motors / Sensors / Servo
ฝั่ง งานหลักใน TerraGuard
STM32 Real-time MCU Motor PWM, Encoder Interrupt, IMU, AHT Sensor, GPS, Servo และ Low-level I/O
Linux / Debian Python Service, Sensor Fusion, Navigation, BLE, ONNX Inference, Mission Logging และ Visualization
XIAO ESP32S3 Sense ส่งภาพ MJPEG / JPEG ผ่าน Wi-Fi ให้ Linux Side ใช้ประมวลผล

Architecture แบบนี้ทำให้ Task ที่ต้องตอบสนองกับ Hardware เร็ว อยู่ฝั่ง MCU ขณะที่ AI และ High-level Navigation อยู่บน Linux

Hardware Stack ของ TerraGuard

TerraGuard rover hardware จากโปรเจกต์ต้นฉบับ
ภาพ Hardware ของ TerraGuard จาก Source ต้นฉบับ
Component หน้าที่
Arduino UNO Q Main Compute: STM32 + Linux
XIAO ESP32S3 Sense Ground Camera / Wi-Fi Stream
BNO055 Heading / Orientation
AHT10 / AHT20 Temperature / Humidity
NEO-6M GPS Logging
Quadrature Encoders ×4 Wheel Odometry
L298N ×2 Motor Drivers สำหรับ 4WD
SG90 Servo หมุนกล้องประมาณ -60° ถึง +60°
AS7341 Spectral Sensor ที่มีอยู่ใน BOM / Firmware
มุมเพิ่มเติมของ TerraGuard rover
ภาพเพิ่มเติมของ Rover และการจัดวาง Hardware จาก Hackster
รายละเอียดฮาร์ดแวร์ TerraGuard จากโปรเจกต์ต้นฉบับ
รายละเอียด Hardware อีกมุมจาก Project ต้นฉบับ
AS7341 มีจริง แต่บทบาทต่อ AI ยังไม่ชัด: Current STM32 Firmware มีการ Initialize AS7341 และอ่าน Spectral Channels จริง แต่ Source ไม่ได้อธิบายว่า Spectral Data ถูกใช้เป็น Input ของ MobileNetV2 Risk Classification จึงไม่ควรเขียนว่า AI Fuse ข้อมูล AS7341 เข้าโมเดล

ทำไม Rover ถูกแบ่งเป็น Upper Deck และ Lower Deck?

ผู้สร้างแบ่งโครงรถเป็นสองชั้น เพื่อแยก Power / Wiring ออกจาก Main Compute

Lower Deck

  • Main 3S 11.1 V Li-ion Battery
  • Wiring ส่วนใหญ่
  • Camera Pan Servo
  • AHT10 ใกล้ระดับพื้น

การวาง AHT10 ใกล้พื้น เป็น Design Choice ของผู้สร้าง เพื่อวัด Microclimate ใกล้ชั้นใบไม้และวัสดุแห้ง มากกว่าวาง Sensor ไว้สูงบนตัวรถ

Upper Deck

  • Arduino UNO Q
  • L298N Motor Drivers
  • BNO055
  • NEO-6M GPS

XIAO ESP32S3 Sense Camera ทำงานอย่างไร?

กล้องถูกวางด้านหน้าของ Rover บน Socket ที่หมุนด้วย SG90 Servo เพื่อมอง:

  • ซ้ายประมาณ -60°
  • ตรงกลาง 0°
  • ขวาประมาณ +60°

Current GitHub Camera Firmware เปิดตัวเองเป็น Wi-Fi Access Point และให้ HTTP Endpoint:

/stream — MJPEG Live Stream
/capture — Single JPEG Snapshot
/ — Browser Live Dashboard

Current Code ตั้ง Camera Stream ไว้ที่ VGA 640 × 480 JPEG และใช้ PSRAM เมื่อพร้อมใช้งาน

ชื่อ Wi-Fi ใน Source ไม่ตรงกัน:
Hackster Quick Setup เรียก Access Point ว่า TerraGuard_Cam แต่ Current GitHub Firmware ใช้ TerraGuard_Camera ดังนั้นควรดู Firmware Revision ที่ใช้งานจริงเป็นหลัก

Power Architecture และจุดที่ Source ขัดกัน

Rover หลักใช้ 3S Li-ion Battery ที่ Source ระบุเป็น 11.1 V และมี MP1584EN Buck Converter สำหรับ 5 V Rail บางส่วน

Motor Power ถูกจ่ายเข้า L298N Drivers ตาม Architecture ของ Project ขณะที่ Encoder และ Servo ใช้ 5 V Rail ที่ลดแรงดันแล้ว

Power ของ XIAO Camera มี Conflict:
Hackster Story ระบุว่า XIAO ESP32S3 Sense ใช้ 3.7 V Li-ion Battery ของตัวเอง เพราะ Camera อยู่บน Moving Joint แต่ GitHub README Pinout Table กลับจัด ESP32 ไว้บน 5 V Rail

ดังนั้นบทความนี้ไม่สร้าง Wiring Power เพื่อแก้ Conflict นี้เอง ควรตรวจ Hardware Revision และ Diagram จริงก่อนประกอบ
Li-ion Safety: Source ไม่ได้ให้รายละเอียด BMS, Fuse, Cell Capacity, C-rating, Charging Circuit หรือ Protection Circuit ครบ จึงไม่ควร Copy Power System จากข้อความสรุปเพียงอย่างเดียว

Pinout / Wiring จาก Current GitHub README

แผนผังการเชื่อมต่อ TerraGuard rover
Diagram การเชื่อมต่อระบบ TerraGuard จาก Source ที่ผู้สร้างเผยแพร่
UNO Q Pin Device Function
I2C SDA BNO055, AHT10 Shared I2C Data
I2C SCL BNO055, AHT10 Shared I2C Clock
A0 Front Left Encoder Phase A
D12 Front Left Encoder Phase B
D13 Rear Left Encoder Phase A
D11 Rear Left Encoder Phase B
A1 Front Right Encoder Phase A
A2 Front Right Encoder Phase B
A3 Rear Right Encoder Phase A
A4 Rear Right Encoder Phase B
A5 L298N #1 Front Left Direction
D10 PWM L298N #1 Front Left PWM
D7 L298N #1 Rear Left Direction
D6 PWM L298N #1 Rear Left PWM
D4 L298N #2 Front Right Direction
D5 PWM L298N #2 Front Right PWM
D2 L298N #2 Rear Right Direction
D3 PWM L298N #2 Rear Right PWM
D9 PWM SG90 Camera Pan Servo
D0 / RX NEO-6M GPS NMEA Input
D1 / TX NEO-6M GPS Configuration

GitHub README ยังระบุ 4.7 kΩ Pull-up ไป 3.3 V บน Shared I2C Bus ของ BNO055 และ AHT Sensor

เก็บ Dataset จากพื้นป่าจริงอย่างไร?

ภาพตัวอย่างจาก TerraGuard สำหรับการประเมินสภาพพื้น
ภาพจาก Project TerraGuard ซึ่งผู้สร้างเก็บข้อมูลจากระดับพื้นด้วย Rover จริง

ผู้สร้างตั้งใจไม่ใช้ Generic Aerial Photos เพราะมุมมองจากอากาศ แตกต่างจากสิ่งที่ Camera บน Rover เห็นมาก

ใน Teach Mode ผู้ใช้ขับ Rover ผ่าน Android App แล้วถ่ายภาพที่มุม:

  • -60°
  • +60°

พร้อมเก็บ Temperature, Humidity และ Odometry Coordinate ประกอบกับภาพ

ผู้สร้างรายงานว่าเก็บ Dataset ได้ประมาณ 400 ภาพ
Current Repo Caveat: README อธิบายว่ามี dataset/ ใน Repository Structure แต่ Root Listing ปัจจุบันที่ตรวจ ไม่แสดง Dataset Folder ดังกล่าว จึงไม่ควรบอกว่าชุดภาพประมาณ 400 รูป ดาวน์โหลดจาก Current Repo ได้ครบ

Low / Medium / High Risk คืออะไร?

ผู้สร้างสร้าง Label สำหรับ Prototype เอง 3 กลุ่ม:

Class ตัวอย่างที่ Source ใช้อธิบาย
Low Risk Moist soil, damp moss, gravel, rocks, lush green vegetation
Medium Risk Normal forest debris, leaves, twigs, mixed or patchy brush
High Risk Dry pine needles, dry brush, brittle dead leaves และ Surface Fuel แห้งหนาแน่น
นี่ไม่ใช่มาตรฐาน Wildfire Risk Classification: เป็น Label Scheme ที่ผู้สร้างกำหนดขึ้นสำหรับ Dataset และ Prototype นี้โดยเฉพาะ

MobileNetV2 ถูก Train อย่างไร?

Model ใช้ MobileNetV2 ที่ Pretrained บน ImageNet แล้วเปลี่ยน Classification Head เพื่อให้ Output เหลือ 3 Classes

MobileNetV220% DropoutLinear Layer3 Risk Classes

Training ที่ผู้สร้างระบุ:

  • PyTorch
  • Adam Optimizer
  • Initial Learning Rate = 1e-4
  • Cosine Annealing
  • 18 Epochs

GitHub มี training_history.json ครบทั้ง 18 Epochs และมี Model Artifact ทั้ง PyTorch และ ONNX

64.2% Accuracy แต่ High-risk Recall 100% หมายความว่าอะไร?

นี่เป็น Section ที่สำคัญที่สุด เพราะตัวเลข 100% ถ้าอ่านแบบผ่าน ๆ อาจทำให้เข้าใจว่า Model “ตรวจ High Risk แม่น 100%” ซึ่งไม่ตรงกับข้อมูลทั้งหมด

Metric ผลบน Test Set
Test Images 53
Overall Accuracy ประมาณ 64.2%
Weighted F1 ประมาณ 0.67
High-risk Support 6 ภาพ
High-risk Recall 100%
High-risk Precision ประมาณ 31.6%
High-risk F1 0.48

Recall 100% หมายถึง High-risk จริงทั้ง 6 ภาพใน Test Set ถูก Model จับได้ครบ

แต่ Precision ประมาณ 31.6% หมายความว่าหลายภาพที่ Model เรียกว่า High Risk จริง ๆ อยู่ใน Low หรือ Medium Class

ดังนั้นห้ามสรุปว่า “AI แม่น 100%”:
ผลที่ถูกต้องกว่าคือ High-risk Recall = 100% บน High-risk Test Samples 6 ภาพ แต่ Precision ของ Class นี้ต่ำกว่ามาก และ Overall Accuracy อยู่ราว 64%

ผู้สร้างเองระบุว่า ผลน่าจะดีขึ้นได้หากเพิ่มจำนวน Training Images

Edge AI ทำงาน Offline บน UNO Q อย่างไร?

หลัง Train เสร็จ ผู้สร้าง Export Model เป็น ONNX แล้ว Linux Side ใช้ ONNX Runtime ประมวลผลภาพจาก XIAO Camera

MJPEG FrameJPEG DecodeRGB 224×224ImageNet NormalizeONNX Runtime3 Risk Classes

Hackster รายงาน Inference Time ประมาณ 45–65 ms ต่อ Frame บน Linux CPU ของ UNO Q โดยไม่ต้องส่งภาพขึ้น Cloud

แล้ว INT8 ล่ะ?

Repository มีทั้ง:

  • wildfire_model.onnx
  • wildfire_model_int8.onnx
  • wildfire_model_single.onnx

แต่ Current vision.py และ Deployment Script ชี้ไปที่ wildfire_model.onnx เป็นหลัก

อย่าเขียนว่า Runtime ปัจจุบันใช้ INT8 โดย Default: INT8 Artifact มีอยู่จริง แต่ Source Code ปัจจุบันโหลดไฟล์ ONNX ปกติ
Fail-open Behavior ที่ต้องระวัง:
Current vision.py Return CLEAR หาก ONNX Session ไม่มี หรือไม่มี JPEG Frame

สำหรับ Maker Prototype นี่คือ Behavior ของ Code ปัจจุบัน แต่ถ้าจะต่อยอดสู่ Safety-related System ไม่ควรตีความ “Model/Camera ใช้ไม่ได้” ว่า “พื้นที่ปลอดภัย”

Temperature + Humidity ถูก Fuse กับ AI อย่างไร?

Current vision.py ไม่ได้ใช้แค่ Visual Class แต่ยังมี Heuristic Rule จาก Temperature และ Relative Humidity

Condition ใน Code ความหมายใน Project
Temp ≥ 30°C และ RH ≤ 35% Severe Condition ตาม Heuristic ของ Project
Temp ≥ 35°C Severe Condition
RH ≤ 20% Severe Condition
Temp ≥ 26°C และ RH ≤ 45% Elevated Condition

ถ้า Visual Model ให้ Medium Risk และ Weather เข้า Severe Condition Code จะ Escalate เป็น High Risk / BLOCKED

นี่ไม่ใช่ Fire Weather Standard: Source ไม่ได้อ้างว่า Threshold เหล่านี้ มาจากหน่วยงานป้องกันไฟป่า หรือ Fire Weather Index มาตรฐาน จึงควรเรียกว่า Project-specific heuristic thresholds

GPS พังในป่าจริง แล้วผู้สร้างแก้อย่างไร?

Field Test ทำให้เจอ Bug ที่ไม่ปรากฏตอนทดสอบในบ้าน

ปัญหา 1: Coordinate Jump ถึง 5.6 ล้านเมตร

ผู้สร้างเคยผสม Local Metric Odometry กับ Raw GPS Coordinate จนเมื่อ GPS Lock ค่า Position กระโดดจาก Local 0 ไปเป็นระดับหลายล้านเมตร ทำให้ Rover คิดว่า Waypoint อยู่ไกลผิดปกติ และพยายามหมุนหาเส้นทาง

วิธีแก้คือ:

Autonomous Navigation ใช้ Encoder + Gyro Dead-reckoning เป็นหลัก ส่วน GPS ถูกใช้สำหรับ Origin และการ Plot Map

ปัญหา 2: GPS Multipath ใต้ต้นสน

ใต้เรือนยอดหนา Source รายงานว่า GPS เคยกระโดดประมาณ 400 m ชั่วคราวจาก Multipath

ผู้สร้างจึงใช้ Filter ใน Visualization เพื่อทิ้ง Jump ที่ดูเป็นไปไม่ได้ โดย Story ระบุ Threshold ที่ประมาณ 4.0 m/s เทียบกับ Rover ที่วิ่งประมาณ 0.6 m/s

Threshold นี้เป็น Heuristic ของ TerraGuard: ไม่ใช่ Universal GPS Multipath Filter สำหรับ Robot ทุกประเภท

Field Test จริงมากกว่า 1.6 km ได้เรียนรู้อะไร?

ผู้สร้างนำ TerraGuard ไปทดสอบบนทางป่าจริง และรายงานระยะการเดินทางรวมมากกว่า:

1.6 km

ช่วงสภาพแวดล้อมที่ Source รายงาน:

  • Temperature: 19.5–25.4°C
  • Humidity: 37.5–63.7%
Field Trial ≠ Certified Field Validation: ระยะ 1.6 km เป็นผลการทดลองของ Prototype ไม่ใช่การรับรอง Reliability สำหรับงานดับเพลิงหรือ Emergency Response

Mission Map แสดงอะไรบ้าง?

หลัง Patrol ระบบเก็บข้อมูล Mission เป็น JSON เช่น:

  • x, y
  • Heading
  • GPS
  • Speed
  • Temperature
  • Humidity
  • Inspection Photo
  • AI Classification

จากนั้น visualize_mission.py สร้าง Interactive Map ด้วย Leaflet.js มี:

  • Satellite View
  • GPS Track
  • Risk Pins
  • Clickable Photo Popups
  • AI Confidence
  • Environment Data
หน้าจอหรือผลลัพธ์จากระบบ TerraGuard
ภาพจากส่วน Software / Mission Workflow ของ TerraGuard ที่เผยแพร่ใน Project
หน้าจอเพิ่มเติมของระบบ TerraGuard
ภาพเพิ่มเติมจาก Software / Mission Workflow ของ Project
ผลลัพธ์เพิ่มเติมจาก TerraGuard mission system
ผลลัพธ์เพิ่มเติมจากระบบ Mission และ Visualization

Camera Socket 3D Print สำหรับ XIAO ESP32S3 Sense

Project มี Custom Camera Socket สำหรับติดตั้ง XIAO ESP32S3 Sense เข้ากับ Mechanism ของ Servo และผู้สร้างปล่อยไฟล์ OBJ ให้ดาวน์โหลด

ดาวน์โหลด Camera Socket OBJ
Source ไม่ได้ระบุ Printing Settings ครบ: ไม่มีข้อมูลยืนยันเรื่อง Layer Height, Infill, Nozzle, Support, Material, Print Temperature หรือ Orientation จึงไม่ควรสร้าง Profile ขึ้นเอง

มีไฟล์ 3D แล้วแต่ไม่มีเครื่องพิมพ์? หากสิทธิ์ของไฟล์อนุญาต สามารถสอบถามทีม Globalbyte เรื่องบริการพิมพ์ 3D สำหรับ Prototype ได้

Source Code ที่น่าสนใจจาก GitHub

Repository เป็น Public และระบุ MIT License โดยแยก Code ออกเป็นฝั่ง:

  • UNO Q STM32 Firmware
  • UNO Q Linux / Python
  • XIAO ESP32S3 Camera
  • Android Controller
  • Model Artifacts

XIAO Camera — HTTP Endpoints

xiao_esp32s3_camera.ino
httpd_uri_t index_uri = {
    .uri       = "/",
    .method    = HTTP_GET,
    .handler   = index_handler,
    .user_ctx  = NULL
};

httpd_uri_t stream_uri = {
    .uri       = "/stream",
    .method    = HTTP_GET,
    .handler   = stream_handler,
    .user_ctx  = NULL
};

httpd_uri_t capture_uri = {
    .uri       = "/capture",
    .method    = HTTP_GET,
    .handler   = capture_handler,
    .user_ctx  = NULL
};

Edge AI — Resize และ Normalize ก่อน ONNX

uno_q_linux/vision.py
img = Image.open(io.BytesIO(jpeg_bytes)).convert("RGB")
img = img.resize((224, 224), Image.BILINEAR)

arr = np.array(img, dtype=np.float32) / 255.0

for c in range(3):
    arr[:, :, c] = (
        arr[:, :, c] - IMAGENET_MEAN[c]
    ) / IMAGENET_STD[c]

arr = np.transpose(arr, (2, 0, 1))
arr = np.expand_dims(arr, axis=0)
เปิด GitHub Repository

Quick Setup จาก Source

ถ้าต้องการศึกษา Workflow การ Deploy Source แบ่งขั้นตอนหลักไว้ดังนี้

  1. Flash uno_q_stm32/sketch.ino เข้า STM32 Side ของ UNO Q ผ่าน Arduino App Lab หรือ IDE
  2. Flash xiao_esp32s3_camera/xiao_esp32s3_camera.ino เข้า XIAO ESP32S3 Sense โดย Source ระบุให้เปิด OPI PSRAM
  3. Deploy Python Stack และ Model ไปยัง Linux Side ด้วย Deployment Script
  4. SSH เข้า UNO Q แล้ว Run Python Main Service
  5. Build Android Controller และ Connect ผ่าน BLE
  6. หลัง Mission ใช้ Fetch Script ดาวน์โหลด Log และเปิด Interactive Map
Commands จาก README
deploy.bat

ssh arduino@[YOURIP]
python3 ~/terraguard/python/main.py

fetch_mission.bat
[YOURIP] เป็น Placeholder: ต้องเปลี่ยนเป็น IP ของ UNO Q ใน Network ที่ผู้ใช้เป็นเจ้าของหรือได้รับอนุญาต

ข้อจำกัดที่ต้องรู้ก่อนเอาแนวคิดนี้ไปใช้จริง

  1. AI ยังมี False Positive สูงใน High-risk Class
    High-risk Recall ดีใน Test Set นี้ แต่ Precision ต่ำกว่ามาก
  2. High-risk Test Support มีเพียง 6 ภาพ
    Dataset และ Test Set ยังเล็กเกินไป สำหรับการสรุป Performance กว้าง ๆ
  3. ถ้า Model หรือ Camera Frame หาย Current Code คืนค่า CLEAR
    ไม่เหมาะกับ Safety-critical Interpretation
  4. Weather Threshold เป็น Heuristic ของผู้สร้าง
    ไม่ใช่เกณฑ์เตือนไฟป่าที่ผ่านการรับรอง
  5. GPS ใต้เรือนยอดมี Multipath
    Project จึงไม่ใช้ GPS เป็น Core Autonomous Navigation
  6. Power Design ยังมีข้อมูลขัดกัน
    โดยเฉพาะ Camera Battery / 5 V Rail
  7. AS7341 มีใน Hardware/Firmware แต่บทบาทเชิง AI ไม่ได้อธิบายชัด
  8. Repository Structure ใน README ไม่ตรงกับ Root Listing ปัจจุบันทุกจุด
Safety:
TerraGuard เป็น Experimental Rover ไม่ควรนำเข้าใกล้ Active Wildfire และไม่ควรใช้เป็นระบบเตือนภัยหลัก

Autonomous Motor System ควรทดสอบในพื้นที่ควบคุม ห่างจากคน สัตว์ และสิ่งกีดขวาง พร้อมมีวิธีหยุดรถได้ทันที

ระบบมี Li-ion Battery หลายชุด แต่ Source ไม่ได้ให้ Protection / Charging Detail ครบ จึงไม่ควรเดา Power Wiring เพิ่มเอง

FAQ: TerraGuard Arduino UNO Q Wildfire Rover

1. TerraGuard ตรวจจับไฟป่าโดยตรงไหม?

ไม่ ตัว Prototype ประเมินสภาพ Ground Vegetation / Surface Fuel และ Microclimate ไม่ได้ตรวจ Flame หรือ Smoke โดยตรง

2. Main Computer คืออะไร?

Arduino UNO Q โดยแบ่งงานระหว่าง STM32 MCU กับ Linux / Debian Application Side

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

Seeed Studio XIAO ESP32S3 Sense ซึ่งส่ง MJPEG ผ่าน Wi-Fi

4. กล้องหมุนได้กี่องศา?

Source ระบุประมาณ -60° ถึง +60° ด้วย SG90 Servo

5. Dataset มีกี่ภาพ?

ผู้สร้างรายงานประมาณ 400 ภาพ ที่เก็บด้วย TerraGuard เอง

6. AI Model คืออะไร?

MobileNetV2 Pretrained บน ImageNet แล้วเปลี่ยน Classification Head เป็น 3 Risk Classes

7. Accuracy เท่าไร?

Test Set 53 ภาพให้ Overall Accuracy ประมาณ 64.2% และ Weighted F1 ประมาณ 0.67

8. High-risk Accuracy 100% จริงไหม?

ไม่ควรเรียกแบบนั้น ตัวเลข 100% คือ High-risk Recall บน High-risk Samples 6 ภาพ ขณะที่ Precision ของ High-risk Class อยู่ประมาณ 31.6%

9. AI ทำงานบน Cloud ไหม?

ไม่ Inference ใช้ ONNX Runtime บน Linux Side ของ UNO Q ตาม Project

10. Project ใช้ INT8 Model อยู่หรือไม่?

Repo มี INT8 Model Artifact แต่ Current Runtime Path โหลด wildfire_model.onnx เป็นหลัก

11. ถ้า Camera หรือ Model ใช้งานไม่ได้จะเกิดอะไรขึ้น?

Current vision.py Return CLEAR ในบางกรณีที่ไม่มี ONNX Session หรือไม่มี JPEG Frame ซึ่งเป็น Caveat สำคัญของ Prototype

12. GPS ใช้ขับ Autonomous ไหม?

หลัง Field Test ผู้สร้างแยก Autonomous Driving ออกจาก GPS และใช้ Encoder + Gyro Dead-reckoning เป็นหลัก

13. Waypoint ถูกสร้างบ่อยแค่ไหน?

Current Code ใช้ Distance Threshold ประมาณ 0.5 m หรือ Heading Change ประมาณ 15° พร้อมเงื่อนไขการเคลื่อนที่

14. Rover ถูกทดสอบไกลแค่ไหน?

ผู้สร้างรายงาน Field Travel มากกว่า 1.6 km

15. มีไฟล์ 3D Print ไหม?

มี Camera Socket เป็น OBJ แต่ Source ไม่ได้ให้ Printing Settings ครบ

16. Source Code เปิดไหม?

GitHub Repository เป็น Public และมี MIT License

17. AS7341 ถูกใช้เป็น Input ของ AI ไหม?

Source ยืนยันว่ามี AS7341 และ Firmware อ่าน Sensor ได้ แต่ไม่ได้อธิบายชัดว่า Spectral Data เข้า MobileNetV2 Classification Pipeline หรือไม่

สรุป: จุดน่าสนใจของ TerraGuard ไม่ได้อยู่ที่ AI อย่างเดียว

TerraGuard เป็นตัวอย่างที่ดีของ Project ที่เอา Embedded, Linux, Computer Vision, Robotics, Sensor Fusion และ GIS มาต่อกันเป็นระบบเดียว

UNO Q รับบทเป็นสะพานระหว่าง Real-time Motor / Sensor Control กับ Python + ONNX ขณะที่ XIAO ESP32S3 Sense แยกหน้าที่กล้องออกไปเป็น Wi-Fi Camera Module

สิ่งที่มีคุณค่ามากที่สุดอาจไม่ใช่ Accuracy 64.2% แต่คือ Journey ที่ผู้สร้างเจอ GPS Error หลายล้านเมตร, Multipath ใต้ต้นไม้, Dataset ที่ยังเล็ก และ Model ที่ยังต้องเพิ่มข้อมูล แล้วแก้ Architecture ตามปัญหาจริง

ถ้าจะต่อยอด TerraGuard ไปสู่งานจริง งานถัดไปจึงไม่ใช่แค่ “เพิ่ม AI” แต่ต้อง Review Fail-safe Behavior, Dataset Diversity, Navigation Safety, Power Protection และ Validation กับผู้เชี่ยวชาญด้านไฟป่า ให้เข้มกว่าระดับ Maker Prototype

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

TerraGuard มีทั้ง Firmware, Python Stack, Android App, AI Model, Wiring และ 3D File ดังนั้นถ้าจะ Build จริง ควรใช้ GitHub Current Revision ควบคู่กับ Hackster Story

อ่าน TerraGuard Tutorial ฉบับเต็มบน Hackster

ดู Source Code และ Model บน GitHub

ดาวน์โหลด Camera Socket OBJ

อ่าน Arduino UNO Q Documentation

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

อยากลองต่อยอด Rover, Edge AI หรือ Sensor Project แบบนี้?

ถ้ากำลังทดลอง Arduino, XIAO ESP32S3 Sense, Sensor, Motor Driver, Embedded AI หรือ Maker Robotics สามารถสอบถามทีม Globalbyte เรื่อง Development Board และอุปกรณ์ที่เหมาะกับ Project ได้

สำหรับ Camera Socket ถ้ามีไฟล์ OBJ และสิทธิ์การใช้งานเหมาะสม สามารถสอบถามเรื่องบริการพิมพ์ 3D สำหรับ Prototype ได้เช่นกัน

Disclaimer: บทความนี้เป็นการสรุปและเรียบเรียงจากแหล่งข้อมูลภาษาอังกฤษ อาจมีความคลาดเคลื่อน กรุณาตรวจสอบ Source ต้นฉบับก่อนลงมือทำ

TerraGuard เป็น Maker / Research Prototype สำหรับสำรวจ Ground Vegetation, Surface Fuel และ Microclimate ไม่ใช่อุปกรณ์ตรวจจับไฟป่า, ระบบเตือนภัยฉุกเฉิน หรืออุปกรณ์ Safety-certified สำหรับใช้งานใกล้ Active Wildfire

ผล AI บน Test Set 53 ภาพ มี Overall Accuracy ประมาณ 64.2% และ High-risk Recall 100% จาก High-risk Sample เพียง 6 ภาพ ขณะที่ High-risk Precision อยู่ประมาณ 31.6% จึงไม่ควรสื่อว่า Model มีความแม่นยำ 100%

Current vision.py มี Fail-open Behavior ที่สามารถ Return CLEAR เมื่อ ONNX Model Session หรือ JPEG Frame ไม่มี ซึ่งไม่ควรนำไปตีความเป็น Safety Guarantee และควร Review ใหม่หากนำแนวคิดไปใช้ ในระบบที่มีผลต่อความปลอดภัยจริง

Temperature / Humidity Threshold ที่ใช้ Escalate Risk เป็น Project-specific Heuristic และ Source ไม่ได้ระบุว่าเป็น Fire Weather Index หรือ Threshold จากหน่วยงานด้านไฟป่าที่ได้รับการรับรอง

Hackster Story และ GitHub README มีข้อมูลไม่สอดคล้องกันบางส่วน เช่นชื่อ Wi-Fi Access Point และ Power Source ของ XIAO Camera บทความนี้ใช้ Current GitHub เป็นหลักในส่วน Firmware และไม่สร้าง Power Wiring เพื่อเติมช่องว่างที่ Source ไม่ได้ Resolve

ระบบใช้ 3S Li-ion Battery และ Battery สำหรับ Camera แต่ Source ไม่ได้ให้ข้อมูลครบเรื่อง BMS, Fuse, Charging Circuit, Cell Capacity, C-rating และ Protection Circuit จึงควรออกแบบและตรวจระบบพลังงาน โดยผู้ที่มีความรู้ด้าน Battery Safety

Rover มี Motor และ Autonomous Movement ควรทดสอบในพื้นที่ควบคุม ห่างจากคน สัตว์ และสิ่งกีดขวาง พร้อมมีวิธีหยุดระบบได้ทันที

Source ไม่ได้ให้ Printing Settings สำหรับ Camera Socket OBJ เช่น Layer Height, Infill, Nozzle, Support, Material, Temperature หรือ Orientation บทความนี้จึงไม่ได้สร้างค่าเหล่านั้นขึ้นเอง

 

แท็ก


Blog posts