ปัญหา: น้ำที่มีพลาสติกมาก กลับมีข้อมูลน้อยที่สุด

จุดเริ่มต้นของ MarineSentinel มาจากการเห็นขยะพลาสติกที่ Limbe Down Beach ใน Cameroon ทั้งขยะที่ถูกทิ้งลงน้ำโดยตรง และขยะที่ไหลออกจาก Drain / Inlet มาสู่ทะเล

Pain Point ของผู้สร้างไม่ใช่แค่ “มีขยะ” แต่คือไม่มีการวัดแบบต่อเนื่อง: ถ้ามีคนเข้า Site ถ่ายภาพหรือเก็บตัวอย่างเพียงครั้งคราว Pollution Event ที่เกิดหนึ่งวัน กับ Event ที่ต่อเนื่องหนึ่งเดือน อาจไม่มีข้อมูลมากพอให้แยกออกจากกัน

MarineSentinel คืออะไร — และไม่ได้ทำอะไร?

MarineSentinel เป็นทุ่น Monitoring ที่ถูกออกแบบให้ลอยอยู่บนผิวน้ำ พร้อมอ่าน Sensor และใช้ Camera + Edge AI ตรวจวัตถุที่ลอยผ่าน

ระบบปัจจุบันติดตาม:

• Turbidity
• Water Temperature
• Roll / Pitch / Yaw จาก IMU
• GPS
• Object Detection จาก Camera
• Alert State

แต่สิ่งที่ MarineSentinel ไม่ได้ทำ คือ Scoop หรือเก็บขยะออกจากน้ำ

Architecture: UNO Q หนึ่งบอร์ด แต่มีสองสมอง

จุดเด่นของ UNO Q ใน Project นี้ คือมีทั้ง MCU และ Linux MPU อยู่ในระบบเดียว

Current Code แบ่ง Cadence ชัดเจน:

วิธีนี้ช่วยให้ IMU Update ได้เร็ว โดยไม่ต้องบังคับ Water Sensors ให้ทำงานด้วย Sampling Rate เดียวกัน

Hardware Stack ของ MarineSentinel

Wiring ที่ต้องระวัง: D4 / D2 และ QWIIC คนละ Bus

ทำไม MPU6050 ต่อ QWIIC แล้วใช้ Wire ไม่ได้?

ผู้สร้างเจอปัญหาว่า MPU6050 ต่อ QWIIC แล้วเปิดไฟปกติ แต่ I2C Scan บน Default Wire กลับไม่เจอ Device

Current Firmware อธิบาย Mapping:

Current Code จึงใช้ MPU6050 imu(Wire1) และ Wire1.begin()

Turbidity Sensor วัดอะไร และทำไมค่า NTU ต้องระวัง?

MarineSentinel อ่าน Analog Turbidity Sensor ผ่าน A0 แล้ว Current sensors.py แปลง ADC Reading เป็น NTU ด้วยสมการใน Project

Code ยังแบ่ง Label เป็น:

NTU ใน Dashboard ยังไม่เท่ากับ Calibration Lab

Current Code มี Conversion Function แต่ Source ไม่ได้ให้ผล Calibration ของ MarineSentinel Build เทียบกับ Reference Turbidimeter, Standard Solution, Accuracy หรือ Measurement Uncertainty

ดังนั้นคำที่ปลอดภัยคือ: ระบบ แปลง Analog Reading เป็นค่า NTU ตาม Curve ใน Code ไม่ใช่การรับรองว่า MarineSentinel เป็นเครื่องวัด NTU ที่ผ่าน Calibration แล้ว

MPU6050 รู้ได้อย่างไรว่าทุ่นเอียง?

MarineSentinel ใช้ MPU6050 เพื่อวัด Accelerometer + Gyroscope แล้ว Firmware Fuse ข้อมูลออกมาเป็น:

• Roll
• Pitch
• Yaw

Current Sketch Update Filter ต่อเนื่องใน Loop แต่ส่ง Orientation ขึ้นไปยัง Linux ทุก 100 ms หรือประมาณ 10 Hz

Dashboard จึงสามารถแสดง Capsule 3D ที่เอียงตาม Sensor ได้แบบต่อเนื่อง และ Current Alert Logic ใช้:

แล้ว Yaw ล่ะ?

MPU6050 ไม่มี Magnetometer ทำให้ Yaw ไม่มี Absolute Heading Reference เหมือน Compass

Current Software ทำได้เพียง Wrap ค่าให้อยู่ในช่วง -180° ถึง 180° เพื่อให้อ่านง่าย แต่ไม่ได้แก้ Gyro Drift จริง

GPS และ Local Alert ทำให้ Detection มี Context มากขึ้น

GPS ใน Current Firmware ส่งข้อมูลขึ้น Linux ประมาณ 1 Hz:

• Fix State
• Latitude
• Longitude
• Speed
• Course
• Satellite Count

นี่สำคัญเพราะ Detection ที่รู้เพียงว่า “เจอขวด” มีประโยชน์น้อยกว่าข้อมูลที่รู้ว่า เจอที่ตำแหน่งไหนและเมื่อไร

นอกจากนี้ Python ยังส่ง Alert State กลับไปยัง STM32 ผ่าน Router Bridge เพื่อเปลี่ยน RGB LED บนบอร์ด:

AI ตอนนี้ใช้ YOLO-X หรือ Edge Impulse?

คำตอบคือ: Project รองรับทั้งสองทาง แต่ Current GitHub Default ใช้ YOLO-X

Current app.yaml ระบุ:

bricks:
- arduino:video_object_detection:
    model: yolox-object-detection
- arduino:web_ui: {}
- arduino:dbstorage_tsstore: {}

นั่นหมายความว่า Runtime Default ใช้ Built-in Object Detection Model ไม่ได้บังคับว่าต้องมี Custom Edge Impulse Model

แล้วมันรู้จัก “ขยะ” ยังไง?

Current sensors.py มีรายการ COCO Labels ที่ Project เลือกตีความว่าอาจเป็น Debris เช่น:

• bottle
• cup
• bowl
• backpack
• handbag
• suitcase
• umbrella
• sports ball
• book
• vase
• cell phone

Current Python Configuration ใช้ Confidence Threshold: 0.4 และ Debounce: 3 วินาที

ค่านี้เป็น Configuration ปัจจุบันของ Project ไม่ใช่ค่าที่ Source พิสูจน์แล้วว่า Optimal สำหรับแม่น้ำหรือชายฝั่งทุกพื้นที่

อยาก Train AI ให้รู้จักขยะของพื้นที่ตัวเอง ทำต่อยังไง?

Hackster แนะนำ Edge Impulse สำหรับ Training Model เฉพาะพื้นที่ โดย Workflow คือ:

Current Technical README อธิบายว่าสามารถ Register Custom Model แล้วนำ Model ID มาแทน yolox-object-detection ใน app.yaml

Dashboard ทำงานแบบ Local และเก็บ History ด้วย InfluxDB

Current App ไม่ได้ใช้ Streamlit เป็น Runtime หลักแล้ว แต่เปลี่ยนไปใช้:

• arduino:web_ui
• arduino:video_object_detection
• arduino:dbstorage_tsstore

เหตุผลที่ผู้สร้างย้ายจาก Streamlit คือเวอร์ชันเดิมจะเริ่ม App Logic เมื่อมี Browser เปิดหน้า Dashboard ซึ่งไม่เหมาะกับทุ่นที่ควรเริ่ม Sensor, AI และ Logging เองตั้งแต่ Boot

Current web_ui จึงเป็น Always-on Process: เปิดระบบขึ้นมาแล้ว Backend ทำงานทันที แม้ยังไม่มีคนเปิด Dashboard

Browser เปิดผ่าน Local Network ที่ Port 7000:

http://<board-ip>:7000

InfluxDB เก็บอะไร?

Current data_store.py ใช้ TimeSeriesStore / InfluxDB สำหรับ:

• Turbidity
• Temperature
• Roll
• Pitch
• Yaw

3D Capsule โดยไม่โหลด Three.js จาก Internet

ผู้สร้างต้องการให้ Orientation View ยังแสดงได้แม้ Browser ไม่มี Internet ออกไปหา CDN

Current Dashboard จึงใช้ CSS 3D Transform แทนการบังคับโหลด 3D Library ภายนอก

นี่เป็น Design Choice ที่น่าสนใจ: ถ้าระบบอยู่ริมแม่น้ำ Local Dashboard ควรยังทำงานได้ แม้ Internet ภายนอกจะไม่มี

3D Print ตัวทุ่น: 5 ส่วนหลัก + STEP File สำหรับแก้ CAD

MarineSentinel ถูกออกแบบใน Fusion 360 และ Main Source ระบุว่า Print ชิ้นส่วนด้วย PETG

โครงหลักแบ่งเป็น:

1. Buoy Cover — ด้านบนสำหรับ Solar / GPS / Power Electronics
2. Buoy Mid Body — ส่วน Camera
3. Buoy Bottom — Sensor ใกล้น้ำ
4. Floating Base — Flotation
5. Electronics Enclosure — UNO Q, Battery และ Wiring

Source ระบุว่าหลายส่วน Snap-fit เข้าด้วยกัน และใช้เพียง 2 M3 Screws สำหรับยึดบาง Section

Floating Base มี Revision

Main Source ระบุว่า Floating Base เดิมถูกออกแบบเป็นชิ้นส่วน Printed แต่ Prototype รุ่นหลัง เปลี่ยนไปใช้ Polythene Foam สำหรับ Flotation

ดังนั้นแม้ STL ของ Floating Base ยังมีให้ดาวน์โหลด ก็ไม่ควรตีความว่าเป็น Final Flotation Method ที่ผู้สร้างใช้ล่าสุดเสมอ

Power + Solar: Source บอกอะไร และยังไม่บอกอะไร?

Source ยืนยันว่าระบบมี:

• Solar Panel — BOM ระบุ 2.5 W
• Build Step ระบุ 5 V Solar Panel
• Buck Converter
• Li-ion Battery

แต่ข้อมูล Battery มีรายละเอียดไม่ตรงกัน: BOM มีรายการ 1000 mAh ขณะที่ Build Instruction อีกจุด กล่าวถึง 7.4 V Battery Pack พร้อมตัวเลข 3 A

ดังนั้นเราเขียนได้ว่า:

แต่ยังไม่ควรเขียนว่า:

Water Test ไปถึงไหนแล้ว?

Main Source ระบุ Current Status เป็น:

• Bench proven
• Water tested
• AI Pipeline ทำงานบน Hardware จริง
• Dashboard ทำงาน End-to-end
• IMU / Sensor / Capsule ถูก Integrate แล้ว

แต่ Future Work ยังระบุชัดว่า การ Deploy แบบไม่มีคนดูแล เป็นระยะเวลาหลายสัปดาห์ ยังเป็นการทดสอบขั้นถัดไป

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

Project เปิด Source Files สำหรับทั้ง MCU, Python, Dashboard และ Mechanical Files

ตัวอย่างแรกคือ Sampling Cadence ที่ Firmware ใช้จริง:

const unsigned long SAMPLE_INTERVAL_MS   = 2000;
const unsigned long IMU_SEND_INTERVAL_MS = 100;
const unsigned long GPS_SEND_INTERVAL_MS = 1000;

#define TURBIDITY_PIN A0
#define DS18B20_PIN   D4

detector = VideoObjectDetection(
    confidence=0.4,
    debounce_sec=3.0,
    camera_preview=True
)

ดาวน์โหลด STL / STEP / GitHub

คุณสามารถเปิด Source Project หรือดาวน์โหลดชิ้นส่วน Mechanical จากไฟล์ที่ผู้สร้างเผยแพร่ได้โดยตรง

Current GitHub ยังมี MarineSentinel.step สำหรับผู้ที่ต้องการแก้ Geometry ใน CAD ต่อจาก Source Design

ข้อจำกัดที่ต้องแก้ก่อน Deploy เป็น Monitoring Node ระยะยาว

1. AI ปัจจุบันยังเป็น General YOLO-X: ยังไม่ใช่ Plastic-specific Model ที่ผ่าน Validation สำหรับ Location นี้
2. Turbidity Calibration: Current Code มี NTU Conversion แต่ไม่มีผล Calibration / Accuracy ของ Build จริง
3. Analog Voltage: ต้อง Verify Signal Conditioning ก่อนใช้ Sensor ที่ Output เกิน 3.3 V กับ UNO Q ADC
4. Yaw Drift: MPU6050 ไม่มี Magnetometer จึงไม่ให้ Absolute Compass Heading
5. Power Budget: Source ยังไม่มี Validated Runtime หรือ Solar Energy Balance ระยะยาว
6. Waterproofing: Prototype ถูก Water-tested แต่ไม่มี IP Rating หรือ Long-term Seal Validation
7. Biofouling: การ Deploy เป็นสัปดาห์หรือเดือน อาจทำให้ Optical / Water-facing Sensor เปลี่ยนพฤติกรรม และยังเป็น Future Validation
8. Pin Documentation: Current Sketch ใช้ DS18B20 D4 แต่ Technical README อีก Section ยังระบุ D2
9. Logging: Current Runtime ใช้ InfluxDB ขณะที่ Planning Spec รุ่นก่อนมี microSD CSV Requirement
10. Long Deployment: หลายสัปดาห์แบบ Unattended ยังไม่ได้ถูกพิสูจน์ใน Current Public Result

FAQ: MarineSentinel และ Arduino UNO Q

สรุป: จุดแข็งของ MarineSentinel คือการทำ Monitoring ให้สร้างซ้ำได้มากขึ้น

สิ่งที่น่าสนใจของ MarineSentinel ไม่ใช่แค่การเอา YOLO-X ไปตรวจขวดบนผิวน้ำ

แต่คือการนำ:

• Real-time MCU
• Linux
• Edge AI
• Water Sensors
• IMU
• GPS
• Local Dashboard
• Time-series Logging
• 3D Printed Enclosure

มาประกอบเป็น Monitoring Node ที่ผู้สร้างตั้งใจให้ Workshop ท้องถิ่น สามารถซ่อมหรือสร้างซ้ำได้ โดยไม่ต้องเริ่มจาก Commercial Buoy ราคาสูง

ในขณะเดียวกัน Current Source ก็ยังมี Caveat สำคัญ: Turbidity Calibration, Power Architecture, Long-term Waterproofing, AI Validation, Biofouling และ Deployment Duration ยังต้องพัฒนาต่อ

สำหรับ Maker Project นี้จึงน่าสนใจมาก เพราะมันไม่ได้สอนแค่ “ต่อ Sensor” แต่แสดงให้เห็นว่าพอ Hardware ลงไปอยู่ในโลกจริง เรื่อง Revision, Voltage, Sampling Rate, Dashboard Lifecycle และ Sensor Limitation กลายเป็นส่วนหนึ่งของ Engineering ทันที

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

หากต้องการ Build MarineSentinel จริง ควรใช้ Hackster สำหรับ Story / Build Photos และ Current GitHub สำหรับ Firmware, Pin Assignment, App Lab Structure และ Mechanical Files

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

ดู Source Code และ Mechanical Files บน GitHub

อ่าน Arduino UNO Q Documentation

อ่าน DFRobot Turbidity Sensor Documentation