การสื่อสารโดรนและ MAVLink
แยก message, transport และ datalink แล้วทดลอง telemetry กับ SITL อย่างเป็นลำดับ
แยกสามชั้นของการสื่อสาร
MAVLink กำหนดรูปแบบและความหมายของข้อความ ส่วน serial/UDP/TCP เป็นวิธีขนส่ง และ radio/Wi-Fi/cellular เป็นช่องทางเชื่อมต่อ การเปลี่ยนเครือข่ายจึงไม่รับรองว่าพฤติกรรม mission หรือ failsafe จะเหมือนเดิม
ระบุ system ID, component ID, endpoint, port, baud rate เมื่อมี serial และอัตราข้อความที่ต้องการ HEARTBEAT ช่วยเห็นการมีอยู่ของระบบ แต่ไม่บอกว่าข้อมูลจาก sensor ทุกชุดยังสดใหม่
วัดข้อมูลที่โปรแกรมใช้งานจริง
เริ่มจากอ่าน ATTITUDE หรือ position ใน SITL แล้วบันทึก timestamp พร้อมหน่วย ถ้ามี packet capture ให้เทียบอัตรา packet กับอัตราข้อความที่ application อ่านได้ ข้อความหลายชนิดอาจอยู่ใน traffic เดียวกัน
| เครื่องมือ | เหมาะกับ |
|---|---|
| MAVProxy | forwarding, GCS และ log analysis |
| pymavlink | อ่าน/สร้างข้อความระดับ protocol |
| MAVSDK | telemetry/mission API ระดับสูง |
| Wireshark | packet ฝั่ง IP และเวลา |
| GNU Radio | signal/noise/filter ใน simulation |
Link loss มีหลายความหมาย
Telemetry loss, RC loss และ GCS failsafe เป็นคนละเหตุการณ์ ทดสอบโดยหยุด forwarding ในระบบจำลองแล้วอ่าน log ว่า mode เปลี่ยนหรือไม่ อย่าถือว่าลิงก์ขาดทุกกรณีต้อง RTL หรือควรทำงานเหมือนกัน
Signing และการปกป้องข้อมูล
MAVLink2 signing ใช้ตรวจความแท้ของข้อความ ไม่ใช่การเข้ารหัสเนื้อหา เมื่อนำไปใช้กับ IP network ต้องพิจารณาวิธีปกป้องข้อมูลและสิทธิ์เข้าถึงแยกจาก protocol การทดลองเริ่มที่ loopback/local simulator ได้ก่อนมีวิทยุ
เก็บหลักฐานให้ทำซ้ำได้
เก็บ topology, firmware/API version, endpoint configuration, packet/application log และเวลาที่ตัดต่อ link ส่วนความถี่/กำลังส่งเมื่อใช้วิทยุจริงต้องตรวจตามอุปกรณ์และข้อกำหนดพื้นที่
F25: Free-space loss และบัญชีกำลังรับ
| ตัวแปร | ความหมายและหน่วยเข้า → ออก | ช่วง/แหล่งค่า |
|---|---|---|
| d, f | ระยะ m และความถี่ Hz (เข้า) | มากกว่า 0; โจทย์สังเคราะห์ ต้องอยู่ใน far field |
| c | อัตราเร็วแสง m/s (ค่าคงที่) | 299792458 ในสุญญากาศ |
| Pt, Pr | กำลังส่งที่ขั้วและกำลังรับ dBm (เข้า, ออก) | จำนวนจริง finite; ไม่ใช่ค่า dB |
| Gt, Gr | gain สายอากาศเทียบ isotropic dBi (เข้า) | จำนวนจริง; ค่าทิศทางและความถี่เดียวกับโจทย์ |
| Lother | loss อื่นรวม dB (เข้า) | ตั้งแต่ 0; เช่นสายและ connector ไม่รวม FSPL ซ้ำ |
| S | sensitivity ของตัวรับ dBm (เข้า) | จำนวนจริง; ต้องตรง mode/อัตราข้อมูลที่ระบุ |
| FSPL, M | free-space loss และ margin dB (ออก) | คำนวณในขอบเขตแบบจำลอง; M อาจติดลบ |
ระดับประยุกต์ · คำถาม: ถ้าสมมติให้คลื่นเดินทางในอวกาศอิสระ กำลังรับเหลือเท่าใด? เริ่มจาก loss ระหว่างสายอากาศ isotropic ตาม ITU-R P.525-5 (11/2024), Annex §2.3 สมการ (5) (P2C01, ตรวจ 26 กันยายน 2569) แล้วทำบัญชี gain และ loss เพิ่มเองดังนี้
FSPL = 20 log10(4πdf/c)
Pr = Pt + Gt + Gr − FSPL − Lother
M = Pr − S
อัตราส่วนใน log ไม่มีหน่วย เพราะ m × Hz ÷ (m/s) หักล้างกัน dBm เป็นระดับกำลังอ้างอิง 1 mW ส่วน dB เป็นอัตราส่วน จึงบวก gain/loss กับ dBm ได้ แต่ไม่บวกกำลังสองตัวใน dBm ตรง ๆ
ตัวอย่าง: ช่องสัญญาณสังเคราะห์
ให้ d = 1000 m, f = 2400000000 Hz, Pt = 20 dBm, Gt = Gr = 2 dBi, Lother = 2 dB และ S = −90 dBm
- แทนค่า 20 log₁₀(4π × 1000 × 2400000000 / 299792458) = 100.052008 dB
- Pr = 20 + 2 + 2 − 100.052008 − 2 = −78.052008 dBm
- M = −78.052008 − (−90) = 11.947992 dB เป็นส่วนต่างทางเลขในแบบจำลอง
ภาพแสดงขั้นบวกและลบของบัญชี ไม่ใช่กราฟสเกลระยะ สมมติ free space, far field, gain ในทิศที่ใช้และ polarization ที่ตรงกัน ไม่มีสิ่งกีดขวาง multipath หรือ interference ค่าบวกของ margin ไม่รับรองระยะใช้งานจริงหรือคุณภาพลิงก์ และตัวเลขกำลังส่งในโจทย์ไม่ใช่ข้อกำหนดอนุญาตใช้งานวิทยุ
ลองทำด้วยตนเอง
เปลี่ยนเฉพาะ d เป็น 2000 m จงหา FSPL, Pr และ M ยอมรับคลาดเคลื่อน 0.01 ในหน่วยแต่ละผลลัพธ์
เปิดเฉลย F25
FSPL = 106.072608 dB; Pr = −84.072608 dBm; M = 5.927392 dB ระยะเพิ่มสองเท่าทำให้ loss เพิ่ม 20 log₁₀2 = 6.020600 dB ภายใต้สมมติฐานเดิม
F27: อัตราข้อมูลและการนับข้อความที่หาย
| ตัวแปร | ความหมายและหน่วยเข้า → ออก | ช่วง/แหล่งค่า |
|---|---|---|
| rᵢ | อัตราข้อความชนิด i, message/s (เข้า) | ตั้งแต่ 0; วัดในช่วงเวลาที่ระบุ |
| bᵢ | ขนาด packet ที่ชั้น MAVLink, byte/message (เข้า) | จำนวนเต็มมากกว่า 0; ขนาดหลัง serialize รวม header/checksum/signature |
| R | อัตราบิตเฉพาะชั้น MAVLink, bit/s (ออก) | ตั้งแต่ 0; 1 kbit/s = 1000 bit/s |
| Nexpected | จำนวนที่ผู้ส่งส่งในหน้าต่างที่ตรวจ, packet (เข้า) | จำนวนเต็มมากกว่า 0; sender log ของช่องเดียว |
| Nreceived | จำนวน packet ไม่ซ้ำที่รับในหน้าต่างนั้น, packet (เข้า) | 0 ถึง Nexpected; รอช่วงยอมรับ reorder ก่อนปิดหน้าต่าง |
| Nmissing, loss | จำนวนที่ขาด packet และสัดส่วนที่ขาด (ออก) | 0 ถึง Nexpected; สัดส่วน 0–1 คูณ 100 เป็น % |
| seq | ตัวนับ MAVLink แบบ 8 bit (เข้า) | จำนวนเต็ม 0–255; ต้องรู้ sender/channel และการเริ่มใหม่ |
ระดับประยุกต์ · คำถาม: ข้อมูลใช้กี่บิตต่อวินาที และสิ่งที่ขาดใน log เป็น loss จริงหรือเพียงมาช้า?
R = 8 Σ(rᵢ × bᵢ)
Nmissing = Nexpected − Nreceived; loss = Nmissing / Nexpected
ตาม MAVLink Packet Serialization, MAVLink 2 Packet Format (P2C02, ตรวจ 26 กันยายน 2569) packet รุ่น 2 มี overhead 12 byte ก่อน signature ซึ่งเพิ่มอีก 13 byte เมื่อใช้ signing ขนาด payload จริงอาจลดจากการตัดศูนย์ท้าย ต้องนับขนาดที่ส่งจริง
ตัวอย่าง: แยก bandwidth แต่ละชั้น
packet รวมขนาด 50 byte ส่ง 10 message/s ให้ R = 8 × 50 × 10 = 4000 bit/s หรือ 4 kbit/s ก่อน overhead ของ transport/link ถ้าสมมติเพิ่ม IPv4 header 20 byte และ UDP header 8 byte ต่อหนึ่ง packet โดยไม่มี options และไม่มีการรวม packet จะได้ 8 × (50 + 28) × 10 = 6240 bit/s ตัวอย่าง transport เป็นเงื่อนไขของโจทย์ ต้องนับ Ethernet/Wi-Fi/TLS/retransmission แยกเมื่อมี ไม่ใช้ 6240 เป็น wire rate ของทุกระบบ
สำหรับ sender log ที่รู้ว่าส่ง 100 packet และ receiver รับไม่ซ้ำ 97 packet หลังปิดหน้าต่าง loss = (100 − 97)/100 = 0.03 = 3% นี่คือ loss ณ จุดเก็บ log ที่กำหนด ไม่ระบุสาเหตุว่าเกิดจาก RF
ขอบเขตการนับ seq
counter วน 255 → 0 เป็นปกติ ตาม MAVLink Packet Loss Calculation (P2C03, ตรวจ 26 กันยายน 2569) การอนุมานจากช่องว่างใช้ได้เมื่อเห็นข้อความทั้งหมดจาก channel เดียว routing ที่กรองข้อความหรือการรวมหลาย channel ทำให้อนุมานผิดได้ แม้ system/component ID ตรงกันก็ยังต้องตรวจ channel ต้นทาง
สมมติ packet มาตามลำดับและไม่มี restart จึงคำนวณช่องว่างด้วย (seq_now − seq_previous − 1 + 256) mod 256 ได้ แต่ห้ามใช้สูตรนี้ตรง ๆ กับ reorder, duplicate หรือการขาดเกินหนึ่งรอบ เพราะเลข 8 bit อย่างเดียวแยกเหตุการณ์เหล่านั้นไม่ได้ ให้เก็บ sender log, extended sequence, ขอบเขตเวลา และนโยบายรอข้อความมาช้า แบบฝึกต่อไปให้ข้อมูลผู้ส่งเพื่อขจัดความกำกวม
ลองทำด้วยตนเอง
เพิ่มเฉพาะ rate จาก 10 เป็น 20 message/s ที่ 50 byte จะได้กี่ bit/s ก่อน transport? อีกหน้าต่างหนึ่งผู้ส่งยืนยันลำดับ 254,255,0,1,2,3,4 ผู้รับเห็น 254,255,0,2,1,4 หลังรอครบแล้ว ขาดกี่ packet และกี่เปอร์เซ็นต์? ยอมรับเปอร์เซ็นต์คลาดเคลื่อน 0.0001 จุดเปอร์เซ็นต์
เปิดเฉลย F27
8 × 50 × 20 = 8000 bit/s; ผู้ส่งส่ง 7 packet รับไม่ซ้ำ 6 packet จึงขาดหมายเลข 3 เพียง 1 packet: 1/7 × 100 = 14.285714% หมายเลข 1 มาหลัง 2 เป็น reorder ไม่ใช่ loss เพิ่ม; 255 → 0 เป็น wrap ตามปกติ
ดาวน์โหลด CSV ลำดับ telemetry สังเคราะห์ เพื่อทำโจทย์เดิม คอลัมน์ sender_order เป็นลำดับจริง 1–7, seq_uint8 เป็น counter, receive_order เป็นลำดับที่รับหลังรอครบ ช่องว่างหมายถึงไม่รับ และ window_closed_s เป็นเวลาปิดหน้าต่างของโจทย์ ไม่ใช่ timestamp จากอุปกรณ์จริง ทั้งชุดเป็น sender/channel เดียว ไม่มี restart หรือ duplicate
ลอง เครื่องคำนวณอัตราข้อมูลและ loss โดยเลือกขอบเขต byte ให้ตรงกับโจทย์ และต่อด้วย อายุข้อมูลและคิว MQTT เพื่อแยกความครบถ้วนออกจากความสดของข้อมูล
อ่านต่อและแหล่งอ้างอิง
- เอกสารตั้งต้น: DTI, Drone_Communication_v1
- MAVLink protocol overview
- MAVLink signing
- MAVProxy
- MAVSDK
- MQTT และ Mosquitto
เนื้อหานี้เรียบเรียงจากเอกสารที่ DTI เอื้อเฟื้อและแหล่งอ้างอิงข้างต้น ตัวอย่างตัวเลขเป็นกรณีเพื่อการเรียนรู้ อ่านกิตติกรรมประกาศและที่มาของเนื้อหา
ดาวน์โหลดชุดฝึกสูตรประยุกต์ (CSV/JSON พร้อมเฉลย) · ข้อมูลสังเคราะห์สำหรับฝึกคำนวณและตรวจหน่วย
ทดลองภาระ Telemetry และอัตรารับไม่ครบ
คำนวณในเบราว์เซอร์โดยไม่ส่งข้อมูลออกจากเครื่อง เปลี่ยนค่าทีละตัวแล้วเทียบกับสูตรในบทเรียน
จำนวนไบต์ต้องรวม overhead ของชั้นที่กำลังวัด และความจุลิงก์ต้องอ้างอิงชั้นเดียวกัน ค่า utilization ต่ำกว่า 100% ไม่รับรองคุณภาพลิงก์ ส่วนอัตรารับไม่ครบใช้ชุดแพ็กเก็ตที่รู้ว่าควรได้รับ หลังรอ reorder และตัด duplicate แล้ว ไม่ใช้ sequence gap สรุปเป็น RF loss โดยตรง
ตัวอย่าง: (50 × 10 + 100 × 2) × 8 = 5,600 bit/s; เทียบ 20,000 bit/s ได้ 28% รับไม่ครบ (100 − 95)/100 = 5% สองค่านี้วัดคนละเรื่องและไม่ได้อนุมานจากกัน