PID, Failsafe และเฟิร์มแวร์

ก่อนเริ่มฝึก

วัตถุประสงค์: แยกสมการสอนจากผล ArduCopter SITL และอ่านเหตุเปลี่ยนโหมด พื้นฐาน: ผ่านเซนเซอร์ หน่วย เวลา และการอ่าน log เวลาฝึกโดยประมาณ: 90 นาที เป็นเวลาที่ผู้จัดทำเสนอ ยังไม่ได้วัดกับผู้เรียนจริง

ตรวจความเข้าใจ: อ้างเวลา/โหมดใน log และระบุว่าไม่ได้ยืนยันการบินจริง ใช้ผลชุดเดิมประกอบการเรียน การคอมไพล์หรือการจำลองที่ผ่านยังไม่ยืนยันบอร์ดหรือการบินจริง

ดูเส้นทางเรียนทั้งหมด · ทบทวนเซนเซอร์และการสื่อสาร

จากค่าที่วัดสู่คำสั่งแรงขับ

เส้นทางโดยย่อคือ IMU → การประมาณสถานะ → ค่าคลาดเคลื่อน → ตัวควบคุม → การจัดสรรคำสั่ง → ESC/มอเตอร์ ระบบประมาณสถานะ เช่น EKF ผสานข้อมูลพร้อมความไม่แน่นอนและตรวจคุณภาพข้อมูล ก่อนตัวควบคุมใช้ค่าท่าทาง/ตำแหน่ง ดู PX4 EKF v1.16

การควบคุมท่าทางมักมีหลายชั้น วงนอกเปลี่ยนความผิดพลาดของท่าทางเป็นอัตราการหมุนที่ต้องการ วงในเทียบอัตรานั้นกับ gyro แล้วคำนวณคำสั่งควบคุม ก่อนจัดสรรตามรูปทรงและ actuator จึงต้องอ่านว่าแต่ละวงรับและส่งตัวแปรอะไร คำสั่งไม่ได้เป็น “RPM เป้าหมายของมอเตอร์” เสมอไป

แผนภาพย่อของหลายวงควบคุม ข้อมูลที่วัดกลับเข้าสู่วงที่ใช้ตัวแปรนั้น; ภาพกราฟเสมือนจริงต้นบทไม่ใช่หลักฐานการทดสอบ

ส่วนของ PID	บทบาท	ข้อจำกัดที่ควรศึกษา
P	ตอบสนองต่อ error ปัจจุบัน	gain สูงเกินไปอาจทำให้สั่น
I	สะสม error เพื่อแก้ความคลาดค้าง	ต้องจัดการ integral windup เมื่อคำสั่งอิ่มตัว
D	ตอบสนองต่ออัตราการเปลี่ยนของตัวแปรที่ใช้คำนวณ	ขยาย noise ได้และมักต้องกรอง; ไม่ใช่ตัวทำนายอนาคตที่แน่นอน

ตัวอย่างคณิตศาสตร์แบบ discrete: I[k] = I[k-1] + e[k] × dt และ u[k] = Kp × e[k] + Ki × I[k] + Kd × (e[k] - e[k-1]) / dt ใช้เพื่อเข้าใจความสัมพันธ์เท่านั้น dt ต้องเป็นบวกและสอดคล้องกับเวลาเก็บจริง ระบบใช้งานต้องพิจารณาขีดจำกัด output, anti-windup, filtering และการใช้ derivative จากค่าที่วัดตามโครงสร้าง controller นั้น อย่านำสูตรย่อไปใช้บินโดยไม่มีส่วนเหล่านี้

Failsafe ต้องสัมพันธ์กับสถานะการบิน

กำหนดเหตุผิดปกติและการตอบสนองก่อนทดลอง เช่น สัญญาณควบคุมหาย ข้อมูลเซนเซอร์ไม่น่าเชื่อถือ หรือพลังงานต่ำ แยกสถานะ disarmed, armed บนพื้น และกำลังบิน การตัดมอเตอร์ทันทีเหมาะกับบางการทดสอบบนโต๊ะ แต่ขณะบินอาจทำให้อากาศยานตก ระบบจริงอาจใช้ Hold, Return หรือ Land ตามเงื่อนไขและการตั้งค่า ดู PX4 safety/failsafe และคู่มือ firmware ที่ใช้

ก่อนทดสอบฮาร์ดแวร์ ให้ใช้ SITL ตรวจ trigger, state transition และเหตุผลที่บันทึกไว้ การจำลองข้อมูลหายควรให้หยุดหรือเปลี่ยนโหมดได้ตามแผน หลีกเลี่ยงการสร้างเหตุเสียจริงเพื่อให้ได้ log

ดาวน์โหลดแบบฝึก timing, PID และ failsafe บน PC

ดาวน์โหลดชุดฝึก PC และเฉลย (ZIP) · ใบงานเปล่า (CSV) · เฉลยรวม (JSON) · รายการไฟล์และ SHA-256

ใช้ Python 3.11 ขึ้นไป และ standard library จาก ZIP เดียวกับบทประยุกต์ ไม่ต้องมี STM32 จุดประสงค์คืออ่านเหตุและผลใน log ก่อนเลือกเครื่องมือทดสอบ firmware โปรแกรมผ่านการทดลองซ้ำบน Windows Python 3.11/3.14 และ Ubuntu Python 3.12 แบบจำลองหนึ่งแกนนี้ผู้พัฒนากำหนดเพื่อสอน ไม่ได้รัน PX4/ArduPilot หรือ SITL

1. อ่าน protocol และตรวจชุดฝึก: แตก ZIP เปิด terminal ในโฟลเดอร์นั้น อ่าน README.md/protocol.json แล้วรัน python -m unittest discover -s . -v ใช้ python3 แทนได้ตามระบบ
2. สร้าง baseline แล้วเปลี่ยนเหตุทีละกรณี: รันสี่คำสั่งด้านล่าง แต่ละโฟลเดอร์ได้ control-log.csv และ summary.json
3. ไล่เหตุจากเวลา: เทียบ scheduled_ms, start_ms, dt_ms, finish_ms และ missed_deadline ก่อนดู setpoint, measured angle/rate, PID terms, integral และ command
4. บันทึกหลักฐาน: กรอกใบงานพร้อมแถว log ที่แสดง saturation, integral hold หรือ STOP_SIM แล้วเทียบ answers/control-* การแก้ gain หรือเงื่อนไขใหม่เป็นการทดลองของผู้เรียน ต้องเก็บ protocol แยกจากเฉลยเดิม

python control_lab.py --scenario healthy --output results/control-healthy
python control_lab.py --scenario overload --output results/control-overload
python control_lab.py --scenario saturation --output results/control-saturation
python control_lab.py --scenario data-loss --output results/control-data-loss

แบบจำลองและหน่วย: ทุกกรณีมี 601 tick ช่วง 0–6 วินาที ตั้งคาบ 10 ms ใช้ rate_next = rate + (u - 0.8 × rate) × dt แล้ว angle_next = angle + rate_next × dt โดย angle เป็น deg, rate เป็น deg/s และ u เป็น deg/s² ในสมการสอน ไม่ใช่คำสั่ง ESC/RPM ค่า state ที่ tick start เป็นเซนเซอร์อุดมคติ ไม่มี noise หรือ acquisition latency แบบจำลองเคลื่อนด้วย command ก่อนหน้าตลอดช่วง dt จริงก่อนคำนวณ command ใหม่

PID ใช้ Kp=4 s⁻², Ki=1 s⁻³, Kd=2.5 s⁻¹ และ derivative จาก measured rate: u = Kp × error + Ki × integral - Kd × rate จำกัด output ±60 deg/s² และ integral ±20 deg·s หยุดสะสมเมื่อ candidate output อิ่มตัวและ error ดันต่อทิศเดิม แต่ยอมให้ integral คลาย ขอบเขตและ gain เหล่านี้เป็นของโจทย์ หากศึกษาตัวควบคุมจริงให้อ่านโครงสร้างและการกรองของ PX4 controller diagrams v1.16 แยกจากสมการนี้

กราฟจาก log ที่สร้างด้วยแบบจำลอง ไม่ใช่ benchmark STM32 หรือผลบิน เปิดกราฟตัวควบคุมขนาดเต็ม เพื่อขยายรายละเอียด

กรณี	ตัวแปรที่เปลี่ยน	หลักฐานที่ควรพบ
healthy	เป้าหมาย 15° ที่ 1 s; งาน 6 ms ต่อ tick	missed deadline 0; output แตะขีดจำกัด 1 tick
overload	งานสื่อสารรวมทำให้งานใช้ 12 ms ที่ tick 40, 80, …, 600	missed deadline 15; delay สูงสุด 2 ms; dt บางช่วง 12/8 ms
saturation	เป้าหมายเพิ่มเป็น 30°	output แตะขีดจำกัด 36 tick และ integral hold 36 tick
data-loss	ไม่มี sample ใหม่ตั้งแต่ 3 s; ค่าสุดท้าย 2.99 s	อายุถึง 120 ms ที่ 3.11 s และเข้าสู่ STOP_SIM

Scheduling ledger กำหนดให้งาน tick ถัดไปรอเวลาจบงานก่อนหน้า คำว่า missed deadline ใช้เมื่อจบ หลัง nominal start+10 ms; จบตรงขอบเวลายังผ่าน แถวแรกใช้ dt nominal 10 ms เพราะไม่มี start ก่อนหน้า ตัวเลข workload เป็นข้อสมมติ ไม่ใช่เวลาที่จับจาก CPU จริง

STOP_SIM latch เมื่ออายุข้อมูล ตั้งแต่ 120 ms ทำให้ u=0 เฉพาะในแบบจำลองและคง integral ไว้ ข้อมูลใหม่ไม่เริ่ม run ต่อเอง นโยบายนี้ใช้แทน failsafe ขณะบินไม่ได้ การตอบสนองจริงต้องสัมพันธ์กับสถานะการบินและตรวจใน firmware/SITL แยก เกณฑ์ผ่านชุดฝึกคืออธิบายเวลา หน่วย ขีดจำกัด และเหตุเปลี่ยนสถานะจาก CSV ได้ ไม่ใช้กราฟหรือ RMSE รับรองการบิน

ฝึกอ่าน PID และเหตุหยุดจาก Log ทีละขั้น

วัตถุประสงค์: อธิบาย deadline, คำสั่งอิ่มตัวและเหตุเปลี่ยนสถานะจากหลักฐาน พื้นฐาน: อ่านหน่วย/timestamp จาก ชุดฝึก IMU และข้อความ เวลาเสนอ: 45–60 นาที เป็นเวลาแนะนำ ยังไม่ได้วัดกับผู้เรียนจริง ใช้เครื่องคิดเลข/โปรแกรมอ่าน CSV ได้ ไม่ต้องมีบอร์ดหรือแพ็กเกจเพิ่ม

ภาพนำทางประกอบกราฟและภาพเสมือนจริงเดิม ข้อมูลเป็นผล PC สังเคราะห์ที่เผยแพร่ไว้แล้ว ไม่มี firmware/SITL/อุปกรณ์จริงรอบใหม่

ดาวน์โหลด วิธีทำ, ใบงาน 8 ข้อ, Log คัด 20 แถว, ผลรวมสี่กรณี และ protocol ก่อนเปิด เฉลยพร้อมเหตุผล ตรวจที่มา/SHA-256 ใน manifest evidence.csv คงค่าคอลัมน์เดิม พร้อมตำแหน่งสมาชิก ZIP และเลขบรรทัดที่นับ header เป็น1; ผลรวมทั้ง run ใช้ CSV เต็ม/summary เดิม

1. อ่านหน่วยและเวลาจริงในแบบจำลอง · C1–C2

เขียนหน่วยของ angle/rate/u/integral แล้วอธิบายว่า u ต่างจากคำสั่ง ESC อย่างไร ในกรณี overload ไล่ tick40–42 ว่างานจบเมื่อใด deadlineอยู่ตรงไหน และทำไม dt เป็น12แล้ว8 ms แม้ตั้งคาบ10 ms คำแนะนำ:แยกเวลานัดเริ่ม (scheduled) จากเริ่มจริง (start) และขอบจบที่ scheduled+10 ก่อนนับ missed

2. ตรวจ P/I/D และขอบคำสั่ง · C3–C4

คำนวณ candidate integral ที่ healthy tick100 และ saturation tick100 แล้วเทียบกับ integral ที่เก็บจริงและ u ที่จำกัดไว้ ใช้ผลรวมสี่กรณีตอบว่า healthy มี output_at_limit ได้หรือไม่ และเหตุใดจึงยังต้องอ่าน integral_held แยกจากคำสั่ง ค่าหน่วย/gainและ anti-windup เป็นของโจทย์ ไม่รับรองการจูน flight controller

3. ผูกอายุข้อมูลกับเหตุหยุด · C5–C7

ใช้ data-loss tick310/311 คำนวณอายุจาก sampleสุดท้าย2990 ms แล้วตรวจขอบ age≥120 ลองตอบว่าตั้ง u=0 แล้วมุม/อัตราเป็นศูนย์ทันทีหรือไม่ ด้วย tick311/312/600 และอธิบายว่าทำไม integral hold291 แต่ STOP_SIM290 คำแนะนำ:อ่าน mode/reason ก่อนตีความ P/I/D เพราะ STOP_SIM force u0 และคง integral โดยไม่ได้รวม PID ต่อ

4. เขียนข้อสรุปพร้อมขอบเขต · C8

แยกสิ่งที่ log PC ยืนยันจาก CPU timing/IRQ/เซนเซอร์/actuatorและการบินที่ยังไม่ได้วัด จากนั้นอ่านผล ArduCopter SITLเดิมด้านล่างเป็นอีกชุดหลักฐาน การคัด20แถวช่วยชี้จุดสำคัญ แต่ไม่ใช้แทนผลรวม601แถวต่อกรณี ส่วนการฟื้นข้อมูลไม่มีใน data-loss fixture จึงไม่อ้างว่า trace ทดสอบการเริ่มกลับเองแล้ว

ตรวจตนเอง: ข้อละ2คะแนนที่เสนอ (คำตอบ1+เหตุผล/หน่วย/ขอบเขต1) รวม16 ใช้เฉลยเลือกหัวข้อทบทวน ไม่มีเกณฑ์รับรองพร้อมบินหรือผลผู้เรียนจริง ต่อ กิจกรรม MCU กับ Sim เมื่อแยกสมการสอนกับผล firmware ได้

ทดลอง GCS failsafe กับ ArduCopter จริงใน SITL

ดาวน์โหลดชุด SITL failsafe และ log (ZIP) · ใบงาน (CSV) · เฉลย (JSON) · ผล source build · รายการไฟล์และ SHA-256

วัตถุประสงค์: ตรวจว่า firmware เปลี่ยนจาก GUIDED ไป LAND เมื่อ GCS heartbeat ขาดตามการตั้งค่า แล้วแยกเหตุออกจากคำสั่งผู้ทดสอบ ชุดนี้รัน ArduCopter 4.7.1 official Linux x86_64 กับแบบจำลอง quad บน Ubuntu/WSL จริงวันที่ 1 ตุลาคม 2026 ต่างจากสมการหนึ่งแกนด้านบน มีหนึ่ง run ต่อกรณี ใช้ network namespace ที่มีเพียง loopback และไม่เชื่อมอุปกรณ์จริง

การตรวจ source: คอมไพล์ tag Copter-4.7.1 commit dbe792162d06cab66c3475fd5556bf7a120f119e ด้วย GCC 13.3.0 เป็น SITL ผ่าน โดยไม่แก้ source ผลนี้เป็น Linux SITL build ไม่ใช่ STM32 target build ส่วนการทดลองด้านล่างใช้ official prebuilt binary และ SHA ที่ระบุใน protocol.json แยกจาก binary ที่ build เอง ดู release 4.7.1 และ คู่มือ build

1. ตรวจ log ได้ทันทีบน PC: แตก ZIP ใช้ Python 3.11+ standard library รัน tests และสองคำสั่งด้านล่าง อ่าน README.md/protocol.json ก่อนเทียบเฉลย ไม่ต้องมี STM32 หรือ firmware สำหรับขั้นวิเคราะห์
2. ตรวจเงื่อนไขก่อน arm: runner ตั้งและอ่านกลับ FS_GCS_ENABLE=5, FS_GCS_TIMEOUT=5, FS_OPTIONS=0 ตรวจ ARMING_SKIPCHK=0 และ MAV_GCS_SYSID=255 รอ EKF/pre-arm readiness ใช้ arm ปกติและ takeoff เป้าหมาย 5 m ไม่ force arm
3. เทียบทีละปัจจัย: เมื่อสูงอย่างน้อย 4.5 m รอ 10 s กรณี baseline ส่ง heartbeat ต่อแล้วสั่ง LAND ส่วน gcs-loss หยุด heartbeat โดยคง TCP ไว้รับ telemetry และไม่ส่ง LAND ตรวจ mode/reason แล้วรอลงจน disarm
4. บันทึกข้อสรุป: ใช้ accepted COMMAND_ACK, HEARTBEAT, GLOBAL_POSITION_INT และ STATUSTEXT ผูกเหตุ–ผล กรอกใบงานพร้อมระบุ clock และแถว trace หากต้องการรันใหม่ใช้ WSL/Linux ตาม README; runner ปฏิเสธ network ที่ไม่ใช่ loopback-only และ binary SHA ไม่ตรง

python -m unittest discover -s . -v
python analyze.py data/baseline.json
python analyze.py data/gcs-loss.json

กราฟจาก firmware จริงที่รันกับแบบจำลอง เวลาแกน X คือ host observation นับจาก observed arm ไม่ใช่ clock trigger ภายใน firmware เปิดกราฟ SITL ขนาดเต็ม

กรณี	เหตุที่สร้าง	สิ่งที่พบจาก trace
baseline	ส่ง heartbeat ต่อ แล้วสั่ง LAND	GUIDED/armed → รับคำสั่ง LAND → LAND → disarm; ไม่พบ GCS failsafe
gcs-loss	หยุด heartbeat หลัง hover โดยไม่ส่ง LAND	พบ LAND และ GCS Failsafe จาก firmware → ลงและ disarm

กรณี gcs-loss สังเกต LAND 4.679 s หลังโปรแกรมหยุดส่ง หรือ 5.076 s หลัง heartbeat ครั้งสุดท้ายที่ host ส่ง เพราะ heartbeat ส่งประมาณทุก 1 s จุดหยุดจึงไม่ตรงจุดส่งครั้งสุดท้าย ตัวเลขยังรวม scheduler/telemetry latency ห้ามใช้รับรอง deadline ภายใน firmware หรือหักลบ t ของ host กับ time_boot_ms ของ firmware โดยตรง ตาม คู่มือ GCS Failsafe ค่าที่เลือก 5 คือ Always Land และ timeout อ้าง heartbeat ครั้งสุดท้าย

ขอบเขตผล: source build และสอง SITL cases ผ่าน แต่ยังไม่ได้ทดสอบ STM32, ESC, IMU หรือการบินจริง ไม่ได้เปรียบเทียบ gains/estimator/actuator timing และไม่ใช่ผลความเชื่อถือได้ทางสถิติ รูปเสมือนจริงต้นบทเป็นภาพแนวคิด การกลับมาของ GCS หรือ failsafe รูปแบบอื่นเป็นโจทย์ต่อยอดที่ต้องเขียน protocol และเก็บผลแยก

ขั้นตอนต่อยอด firmware/SITL และอ่าน log

1. เลือกคำถามเดียว: เช่น “เมื่อข้อมูลควบคุมขาด ระบบเข้าโหมดที่ตั้งไว้หรือไม่” บันทึก firmware/version, แบบจำลอง, parameter และเงื่อนไขอ้างอิง
2. สร้าง baseline: ทำภารกิจสั้นใน SITL ด้วยวิธีตามคู่มือ เก็บ log ก่อนเปลี่ยน gain หรือ inject fault
3. เปลี่ยนทีละตัวแปร: ทำซ้ำด้วยข้อมูลหรือเงื่อนไขสมมติที่ควบคุมได้ บันทึกว่าตัวแปรใดเปลี่ยนและเหตุใด
4. เทียบหลักฐาน: ตรวจ setpoint, measured attitude/rate, actuator command, timestamp, estimator status, mode/failsafe reason และ reset reason ถ้ามีในระบบที่เลือก

อาการสั่นคล้ายกันอาจมาจาก gain, vibration, ข้อมูลเก่า, saturation หรือแกนผิด อย่าสรุปจากภาพเคลื่อนไหวเพียงอย่างเดียว ผลที่ควรได้คือแผนทดลอง ตารางก่อน–หลัง และข้อสรุปที่ผูกกับ log หากยังไม่มีข้อมูลพอให้ระบุว่าต้องตรวจอะไรเพิ่ม

เชื่อมกับภารกิจและเรียนต่อ

เปิด DroneSim เพื่อฝึกประกอบลำ วางแผนภารกิจและอ่าน Replay แล้วเขียนว่าระบบต้องวัด/ควบคุมอะไรในการทำภารกิจนั้น DroneSim ปัจจุบันไม่ได้รัน PX4/ArduPilot หรือ MCU code ให้เลือกเครื่องมือให้ตรงคำถามจาก เส้นทางเรียน Simulator

เมื่อพร้อมพัฒนา firmware ให้เลือกบอร์ดที่ flight stack รองรับ อ่านคู่มือ build/port ของรุ่นนั้น และเริ่มจากการเปลี่ยนแปลงเล็กที่มีผลตรวจชัดเจน เกณฑ์ผ่านบทนี้: อธิบายวงนอก–วงใน จัดงบเวลา และใช้ log แยกสมมติฐานได้ โดยไม่อ้างผลจำลองเป็นผลยืนยันการบินจริง

เรียนต่อและทบทวน

ทบทวน ที่มาและขอบเขต Log · กลับภาพรวมขั้นสูง

กิจกรรมเชื่อมความรู้ MCU กับการจำลอง

เลือกกิจกรรม DroneSim อ่าน Log หรือศึกษาผล firmware SITL พร้อมวัตถุประสงค์ ขั้นตอน ใบงาน และเหตุการณ์ย่อจากผล ArduCopter 4.7.1 ที่เก็บไว้แล้ว แยกสิ่งที่แต่ละเครื่องมือยืนยันได้

ฝึกอ่านเหตุและเวลาจากผล firmware SITL

วัตถุประสงค์: แยก LAND จากคำสั่งผู้ทดสอบกับ GCS failsafe และแยกเวลาที่ host สังเกตจาก trigger ภายในเฟิร์มแวร์ พื้นฐาน: ผ่าน PID/STOP_SIM และที่มา/ขอบเขต Log เวลาเสนอ: 45–60 นาที ยังไม่ได้วัดกับผู้เรียนจริง อ่านผลที่เก็บไว้แล้วด้วย CSV/JSON ไม่ต้องติดตั้งหรือรันเฟิร์มแวร์ใหม่

คงภาพเสมือนจริงและกราฟ telemetry เดิม ผลในชุดนี้มาจาก ArduCopter 4.7.1 quad SITL วันที่ 1 ตุลาคม 2026 หนึ่ง run ต่อกรณี รอบนี้เพิ่มสื่ออ่านผล ไม่มี SITL/build/บอร์ดรอบใหม่

ดาวน์โหลด วิธีฝึกอ่านผล SITL, ใบงาน SITL 8 ข้อ, เหตุการณ์เดิม 11 รายการ, ตารางเวลา 7 ช่วงว่าง, protocol/ผล build/trace คัดพร้อมที่มา และ แบบรายงานว่าง ทำก่อนอ่าน เฉลยพร้อมเหตุผล กับ เฉลยเวลา 7 ช่วง ตรวจที่มา/SHA-256 จาก manifest

1. ระบุรุ่นและเหตุของแต่ละกรณี · S1–S3

เทียบ protocol กับ PARAM_VALUE ที่อ่านกลับ แล้วแยก SHA ของ official binary ที่ใช้ในสอง run ออกจาก binary ที่ source build ผ่าน อ่าน ACK/mode/armed ร่วมกับ events และโค้ด runner เดิมก่อนสรุปเหตุ คำแนะนำ: index ในเอกสารนับสมาชิก array จาก 1 ไม่ใช่เลขบรรทัด JSON และ land_command บันทึกหลัง runner รอ ACK accepted แล้ว จึงไม่ใช้เวลานี้แทนเวลาส่งคำสั่ง

2. เลือก boundary และ clock ก่อนคำนวณ · S4–S6

กรอกตารางเวลาเจ็ดช่วงจาก host clock ใน run เดียวกัน เทียบจุดหยุดส่งกับ heartbeat สุดท้าย แล้วอธิบายว่าทำไม LAND ที่ host เห็นก่อนข้อความ GCS Failsafe ไม่บอกลำดับ trigger ภายใน คำแนะนำ: แปลง ms เป็น s ยังไม่ทำให้ firmware clock ตรงกับ host และการแสดงหกทศนิยมไม่รับรองความแม่นยำระดับไมโครวินาที

3. แยก accepted, mode และ disarm · S7

ใช้ HEARTBEAT ที่คัดมาเทียบ mode/armed แล้วคำนวณ LAND→disarm ของทั้งสอง run คำแนะนำ: ACK accepted ยังไม่ใช่การลงเสร็จ ตาม MAVLink Command Protocol ผลหนึ่ง run ต่อกรณีใช้ฝึกอ้างหลักฐาน ไม่ใช้รับรองความเชื่อถือได้หรือ timing ของบอร์ดจริง

4. เขียนข้อสรุปและแผนคำถามต่อยอด · S8

กรอกแบบรายงานด้วย สิ่งที่สังเกต → protocol/ขอบที่ยังไม่ทราบ → แผนตรวจเพิ่ม อ้างไฟล์ array index ช่อง และ SHA ทุกข้อสรุป trace ที่คัดไม่แทน ZIP เต็ม จากนั้นเขียนแผนคำถาม heartbeat กลับมาโดยระบุว่ายังไม่รัน อ่านพฤติกรรมที่เอกสารอธิบายแยกจากผลสอง run นี้ใน ArduPilot GCS Failsafe ค่าของ protocol เป็นค่าทดลองเดิม ไม่ใช่คำแนะนำให้คัดลอกไปใช้กับลำจริง

ตรวจตนเอง: ชุดนี้เสนอข้อละ 2 (คำตอบ 1 + เหตุผล/หน่วย/ขอบ 1) รวม 16 แยกจากเกณฑ์กิจกรรม Sim เดิม ใช้เลือกทบทวน ไม่ใช่ผลผู้เรียนจริง รอบนี้ตรวจที่มา/ไบต์/ตัวเลขและคำอธิบาย ไม่ execute runner/analyzer หรือเพิ่มผล source build/SITL/firmware/บอร์ดใหม่ เมื่ออธิบายได้ให้ต่อ กิจกรรมเชื่อม MCU กับ Sim

เลือกชุดฝึกหรือทบทวนต่อ

กลับสารบัญชุดฝึก MCU 10 ชุด เพื่อเลือกโจทย์ตามเป้าหมายและพื้นฐานที่ควรรู้ หรือ ทำแบบประเมินความเข้าใจ 12 ข้อ เพื่อหาหัวข้อที่ควรทบทวน

หลังตรวจเฉลย ให้บันทึกคำตอบที่แก้ เหตุผล และสิ่งที่หลักฐานยังไม่ยืนยัน แล้วเลือกชุดถัดไปที่ช่วยตอบคำถามนั้น คะแนนใบงานกับแบบประเมินเป็นคนละส่วน ใช้เลือกทบทวนด้วยตนเอง