จากบทเรียน MCU สู่กิจกรรม Sim และ SITL

เลือกตามวัตถุประสงค์

กิจกรรมเหล่านี้เชื่อมความรู้ด้วยโจทย์และหลักฐาน ไม่ได้เชื่อม DroneSim เข้ากับ Arduino/ESP32/STM32 หรือรันเฟิร์มแวร์ในเว็บ เริ่มกิจกรรมที่ตอบคำถามของตนเองได้ ไม่ต้องมีบอร์ดจริง

1. อยากรู้ว่าจะสร้างชุดโดรนอะไร: ออกแบบชุดและวางภารกิจใน DroneSim เชื่อมบทพื้นฐานเรื่อง input/process/output และข้อจำกัดของระบบ
2. อยากรู้ว่าข้อมูลมาช้าหรือหาย: อ่าน Log ของชุด PC เชื่อมคิว เวลา และ freshness ไม่ต้องสร้างชุดโดรน
3. อยากรู้ว่า firmware เปลี่ยนโหมดเพราะอะไร: อ่านเหตุการณ์ SITL เชื่อม failsafe กับสถานะและ clock ไม่ต้องติดตั้ง firmware เพื่ออ่านตัวอย่างเดิม

ใบงานกิจกรรม (CSV) · แนวคำตอบและเกณฑ์ตรวจ · เหตุการณ์ SITL ย่อพร้อมที่มา (JSON) · รายการไฟล์และ SHA-256

กิจกรรม 1: ออกแบบชุดโดรนให้ตอบภารกิจ

วัตถุประสงค์: อธิบายว่าเลือกชิ้นส่วนเพื่อทำอะไร และระบุข้อมูลที่ยังต้องตรวจในระบบจริง พื้นฐาน: Arduino/ESP32 และสัญญาณ เวลาที่เสนอ: 30–45 นาที ยังไม่ได้วัดกับผู้เรียน

1. เปิด DroneSim เลือกวัตถุประสงค์การฝึกก่อนสร้างชุด: ออกแบบ/ประกอบ FPV, จำลองภารกิจอัตโนมัติ หรือสนามฝึกและ Replay อ่านคำอธิบายของแบบที่เลือก
2. สร้างชุดโดรน เลือกภารกิจและชิ้นส่วนให้ครบ บันทึกชื่อชุด/ชิ้นส่วน/เงื่อนไขที่หน้าเว็บแสดงและเหตุผลของการเลือก เก็บชุดเดิมเป็นกรณีฐานก่อนเปลี่ยนเพียงหนึ่งรายการ
3. สำหรับสนามฝึก อ่านกติกาและยืนยันก่อนเริ่ม: ระบบบินอัตโนมัติผ่าน 3 checkpoints คะแนน 0–3 ในกรอบ 120 วินาที มี collision proxy และ Replay ตามกติกาที่เว็บกำหนด
4. ดู Replay แล้วจดเหตุการณ์และความต่างจากกรณีฐาน อย่าสรุปว่าคะแนนเปลี่ยนเพราะ MCU ทำงานเร็วขึ้น เพราะเว็บไม่ได้วัด MCU หรือรัน firmware ของชุดนั้น
5. เขียนแผนผัง input → process → output ของลำที่ออกแบบ ระบุข้อกำหนด MCU ที่ต้องตรวจเพิ่ม เช่น ขารับเซนเซอร์ บัส หน่วยความจำ งบเวลา และพฤติกรรมเมื่อข้อมูลหาย อ้าง เส้นทางควบคุมในบทเฟิร์มแวร์

คำแนะนำ: เริ่มฉากและเงื่อนไขเดิม เก็บภาพชุดก่อน/หลังพร้อมรายการที่เปลี่ยน ตรวจงาน: ภารกิจชัด 1, เหตุผลเลือก/เปลี่ยนชิ้นส่วน 1, แผนผังสัญญาณ 1, ข้อจำกัดและสิ่งที่จะวัดจริง 1 คะแนน ไม่มีการใช้คะแนนสนามแทนทักษะบังคับรีโมตหรือรับรอง NIST

กิจกรรม 2: แยกข้อมูลเก่า คิวเต็ม และช่องส่งหาย

วัตถุประสงค์: อ่านสิ่งที่ Log บอกได้ โดยไม่เติมข้อมูลที่ไม่ปรากฏ พื้นฐาน: คิวจาก ISR และ Freshness Gate เวลาที่เสนอ: 30 นาที

1. เปิดเครื่องมืออ่าน Log เลือก “ข้อมูลเก่าโดยไม่มี loss” วิเคราะห์ แล้วระบุแถว fresh/stale และหน่วยในกราฟ
2. เปลี่ยนเป็น “คิวและ Serial ร่วมกัน” เปรียบเทียบ counter แรก/สุดท้ายและ delta แยกผลออกจาก stale ตรวจสมการ delta_tick = delta_overflow + delta_dropped + 1
3. เปลี่ยนเป็น “ยอดสะสมจากก่อนช่วงที่เห็น” อธิบายว่าทำไมยอด 7/3 ที่คงเดิมให้ delta 0/0 ส่วน “tick ข้ามที่อธิบายไม่ได้” ต้องถูกปฏิเสธ
4. กรอกใบงานด้วยแถวหรือผล JSON และเขียน “สิ่งที่เห็น / สิ่งที่ยังบอกไม่ได้ / หลักฐานที่ต้องเก็บเพิ่ม” อย่านำ JSON ของ SITL มาใส่เครื่องมือนี้ เพราะเครื่องมือรับ CSV หกช่องของชุด Freshness เท่านั้น

คำแนะนำ: เก็บไฟล์ต้นฉบับ ไม่เพิ่ม cutoff หรือแก้ counter เพื่อให้ผ่าน กราฟใช้ลำดับแถว ไม่ใช่เวลา สถิติใช้ทุกแถวแต่กราฟเกิน 1,000 แถวจะเลือกจุด ตรวจงาน: อ่าน state 1, delta 1, ปฏิเสธข้อมูลผิด 1, จำกัดข้อสรุปให้ตรง clock/capture 1 คะแนน

กิจกรรม 3: ไล่เหตุเปลี่ยนโหมดจาก Log เฟิร์มแวร์

วัตถุประสงค์: แยกคำสั่งผู้ทดสอบออกจาก GCS failsafe พื้นฐาน: PID, Failsafe และเฟิร์มแวร์ เวลาที่เสนอ: 45 นาที

ชุดเหตุการณ์ย่อคัดจากผลเดิมวันที่ 1 ตุลาคม 2026 ใช้ ArduCopter 4.7.1 official Linux x86_64 กับแบบจำลอง quad หนึ่ง run ต่อกรณี ไม่รันใหม่ในรอบเพิ่มบทเรียนนี้ Source build แยกจาก official binary ที่ใช้ทดลอง อ่าน SHA และที่มาใน JSON/ชุดต้นฉบับ

1. เปิด เหตุการณ์ย่อ และ เฉลยต้นฉบับ ตรวจชื่อกรณี รุ่น binary และ parameters ที่บันทึกไว้ ในชุดนี้ FS_GCS_ENABLE=5, FS_GCS_TIMEOUT=5, FS_OPTIONS=0 มีผลอ่านกลับตาม protocol
2. ไล่ baseline: armed → สูงถึง gate → ส่งคำสั่ง LAND → สังเกต LAND → disarmed แล้วเทียบ gcs-loss: armed → สูงถึง gate → หยุดส่ง heartbeat → สังเกต LAND/ข้อความ GCS Failsafe → disarmed โดยไม่ส่งคำสั่ง LAND
3. คำนวณช่วงจาก host observation ใน gcs-loss: 64.711191 − 60.031862 = 4.679329 s หลังโปรแกรมหยุดส่ง หรือ 64.711191 − 59.635100 = 5.076091 s หลัง heartbeat ที่ host ส่งครั้งสุดท้าย ตัวเลขในเฉลยปัดเป็น 4.679 s
4. ระบุว่าขอบหยุดส่งกับ heartbeat สุดท้ายต่างกัน และ host observation ไม่ใช่เวลาตรวจ trigger ภายใน firmware ห้ามลบ time_boot_ms ของ firmware กับ t ของ host โดยไม่แปลง clock
5. ตรวจ ชุดเต็มพร้อม trace/คำสั่งที่ยอมรับและ protocol (ZIP) ก่อนสรุปเหตุ JSON ย่อไม่แทน trace ทั้งหมด หากวางแผนรันใหม่ให้ทำตามคู่มือใน environment แยกตามที่กำหนด ไม่ต่อกับลำจริง

คำแนะนำ: อ่าน mode พร้อมเหตุการณ์/คำสั่งและสถานะ armed ไม่ตัดสินจากข้อความเดียว ตรวจงาน: ลำดับเหตุสองกรณี 1, สมการพร้อมหน่วย 1, ความต่าง clock/boundary 1, ขอบเขตหนึ่ง run/แบบจำลอง/ไม่ใช่บอร์ดจริง 1 คะแนน

ตาม เอกสาร GCS failsafe ของ ArduPilot การตรวจใช้ heartbeat และการตอบสนองสัมพันธ์กับ parameters/สถานะ ค่าในกิจกรรมนี้เป็น protocol ของผลเก่า ไม่ใช่ค่าที่แนะนำให้คัดลอกไปใช้กับลำจริง

เปรียบเทียบสิ่งที่ยืนยันได้

• DroneSim: เหตุการณ์และคะแนนตามแบบจำลองเว็บ ไม่ยืนยัน MCU, firmware, ทักษะบังคับรีโมต หรือความปลอดภัยการบิน
• ชุด PC MCU: logic/ข้อมูลสังเคราะห์หรือ CSV ตามสัญญาที่ตรวจ ไม่ยืนยัน IRQ latency, บอร์ดจริง หรือ capture ครบ
• Firmware SITL: พฤติกรรมของ firmware/แบบจำลอง/parameters และ run ที่บันทึก ไม่ยืนยัน wiring, dynamics ของลำจริง หรือเวลาบน STM32

PX4 เป็นอีกเส้นทางการศึกษา ดู สถาปัตยกรรม v1.16 แล้วเลือก source/target/module ที่จะตรวจแยก กิจกรรมนี้ไม่มีผลรัน PX4 ใหม่และไม่ได้ถือว่า PX4/ArduPilot ให้ผลเท่ากัน

ตรวจความเข้าใจสามระดับ · ภาพรวมการจำลองโดรน · เจ็ดบทขั้นสูง

เตรียมเก็บหลักฐานจากบอร์ดจริง

คู่มือเตรียมทดลอง UNO/ESP32/STM32 พร้อมใบงาน ตรวจรุ่น wiring source/core clock และไฟล์ดิบก่อนสรุปผล คู่มือพร้อมใช้ แต่การ upload/วัดจริงยังรออุปกรณ์