โดรน SAR DIY ทำแผนที่ความสูงด้วย InSAR ได้อย่างไร?

Synthetic Aperture Radar หรือ SAR ไม่ได้ต้องการแค่เรดาร์ที่ดี แต่ยังต้องรู้ตำแหน่งของเรดาร์ขณะเคลื่อนที่ให้แม่นมากด้วย และเมื่อขยับจาก SAR ธรรมดาไปสู่ Interferometric SAR หรือ InSAR ความคลาดเคลื่อนระดับเพียงไม่กี่เซนติเมตร ก็สามารถทำให้ Phase ระหว่างภาพสองเที่ยวบินไม่ตรงกัน จนผลวัดความสูงเสียได้

Henrik Forsten จึงใช้เวลาราวหนึ่งปีครึ่ง ปรับทั้ง Hardware และ Software ของ SAR Drone เดิม: เพิ่ม RTK/PPK Positioning, ปรับ PLL ของ FMCW Radar, ทำ Lossless Compression บน FPGA, เขียน Ground Control Software ใหม่ และพัฒนา Residual Motion Estimation เพื่อให้โดรน DIY สามารถสร้าง Interferogram และ Digital Elevation Model จากการบินหลาย Pass ได้

โดรน SAR DIY พร้อม RTK GPS และเสาอากาศเรดาร์ใต้ลำ
ระบบ SAR Drone ของ Henrik Forsten: RTK GPS อยู่ด้านซ้าย เสาอากาศ Radar อยู่ใต้ลำ และยังมี GPS สำรองกับกล้องติดตั้งบน Drone
Key Takeaways
  • ระบบนี้เป็น FMCW SAR Drone ที่พัฒนาต่อจาก Project เดิมของผู้สร้าง
  • RTK GPS ลด Position Error ในการทดสอบจากระดับประมาณ 1 m เหลือประมาณ 2 cm
  • ผู้สร้างยังใช้ PPK เพื่อปรับ Position Solution แบบ Offline
  • PLL Loop Filter ที่ไม่เหมาะสร้าง Integer Boundary Spur และ Artifact ใน SAR Image ได้
  • ADC ให้ Raw Data 75 MB/s แต่ SD Interface ใช้งานจริงได้ประมาณ 20 MB/s
  • จึงสร้าง Lossless Nibble Compression และย้าย Compressor ไปทำบน FPGA
  • Repeat-pass InSAR ใช้ Phase Difference ระหว่างการบินสอง Pass เพื่อคำนวณความสูง
  • Processing Pipeline ใช้ GPGA, Backprojection, RME, Interferogram และ Phase Unwrapping
  • Mean Coherence ใน Mission หลักดีขึ้นจาก 0.210 เป็น 0.453 หลัง Autofocus + RME
  • Processing Code ส่วน SAR อยู่ใน Open-source Project ชื่อ torchbp

จาก SAR Drone เดิม สู่ Interferometric SAR

ผู้สร้างไม่ได้เปลี่ยน Radar และ Drone ทั้งชุด แต่เลือกพัฒนาระบบเดิมทีละส่วน เพราะ Hardware ปัจจุบันยังมีพื้นที่ให้ปรับปรุงได้อีกมาก

Upgrade หลักแบ่งได้เป็น 4 กลุ่ม:

Positioning
Non-RTK GPS → RTK + PPK
↓
Radar Hardware
PLL Loop Filter / Spur Reduction
↓
Data Pipeline
Lossless FPGA Compression
↓
Processing
GPGA + RME + InSAR + DEM

InSAR คืออะไรแบบไม่ต้องเริ่มจากสมการยาว?

แนวคิด repeat-pass interferometric SAR ใช้การวัดสองตำแหน่งเพื่อหา elevation
Repeat-pass InSAR ใช้ข้อมูลจากการวัดมากกว่าหนึ่งตำแหน่ง เพื่อให้ Phase Difference ช่วยบอกความต่างระดับของพื้นผิว

SAR ปกติจาก Linear Track เดียว ให้ข้อมูลระยะและตำแหน่งบนภาพได้ดี แต่การ Solve ความสูงของ Target ต้องมีข้อมูลเพิ่ม เช่น Reference DEM หรือ Measurement จากอีกตำแหน่งหนึ่ง

InSAR ใช้ Phase ของ Radar Return จากสอง Pass ที่มี Geometry ต่างกัน แล้วดู Phase Difference เพื่ออนุมานความต่างของระยะทางและ Elevation

Δφ = (4π / λ)(R₁ − R₂), mod 2π

Phase ไวต่อระยะมาก: ระยะเปลี่ยนเพียงครึ่ง Wavelength ก็ทำให้ Phase เปลี่ยนครบรอบ 360 องศา แต่ข้อเสียคือ Phase วัดได้แบบ Modulo 360° จึงต้องผ่านขั้นตอน Phase Unwrapping ก่อนแปลงเป็น Elevation

ทำไม GPS ปกติระดับเมตรไม่พอ?

โมดูล RTK GPS ที่ติดตั้งบนโดรน SAR
Creator เพิ่ม RTK GPS ขนาดเล็กบน Drone เพื่อให้ Position Reference แม่นกว่าการใช้ GPS ปกติ

ระบบเดิมใช้ Non-RTK GPS ที่ Creator เปรียบเทียบว่ามี Error ระดับประมาณ 1 m ซึ่งมากเกินไปสำหรับ SAR โดยตรง และต้องใช้ Autofocus Algorithm ช่วยแก้หนักมาก

RTK GPS ใช้ Receiver สองฝั่ง:

  • Base Station — อยู่กับที่และมีตำแหน่งอ้างอิง
  • Rover — อยู่บน Drone

Base ส่ง RTCM Correction พร้อมข้อมูลที่เกี่ยวข้องกับ Satellite Signal ให้ Rover ทำให้ Position Solution ของ Project นี้ ดีขึ้นเป็นระดับประมาณ 2 cm

2 cm ไม่ใช่ค่ารับประกันของ RTK ทุกระบบ: ตัวเลขนี้เป็นผลและระดับ Accuracy ที่ Creator ใช้อ้างอิงกับ System ของเขา ซึ่งขึ้นกับ Receiver, Satellite Geometry, Base Station และสภาพการรับสัญญาณ
ชิ้นส่วนพิมพ์สามมิติสำหรับยึด RTK GPS บนโดรน
ผู้สร้างออกแบบชิ้นส่วน 3D Print รวมกล่อง RTK GPS เข้ากับ Rear Landing Leg Attachment
RTK GPS base station ของระบบ SAR drone
Base Station ใช้ F9P เช่นกัน แต่เป็น Board คนละแบบและมีเสาอากาศที่ใหญ่กว่าฝั่ง Drone
กราฟเปรียบเทียบ position error ของ GPS กับ RTK ในระบบ SAR drone
การเปรียบเทียบ Position Error แสดงความต่างระหว่าง Position Reference ที่มีผลโดยตรงต่อ Image Formation

RTK แล้วยังต้อง PPK ทำไม?

กราฟเปรียบเทียบ RTK กับ PPK position solution
Creator ใช้ PPK Processing เพื่อ Solve Position แบบ Offline จากข้อมูล GNSS ที่บันทึกไว้ทั้ง Base และ Rover

RTK ต้องส่ง Correction แบบ Real-time และ Rover Solve ตำแหน่งขณะทำงาน

แต่ SAR Image ของ Project นี้ ถูกประมวลผล Offline อยู่แล้ว จึงสามารถใช้ PPK ซึ่งเก็บ Raw GNSS Data จากทั้ง Base และ Rover แล้วคำนวณ Position ภายหลัง

ข้อดีคือ Solver สามารถใช้ข้อมูล จากช่วงเวลาทั้งก่อนและหลังตำแหน่งที่กำลัง Solve และยังช่วยกู้ Measurement ในกรณีที่ RTK Correction Link มีปัญหาชั่วคราว

Creator ระบุว่าเมื่อ RTK ทำงานดีอยู่แล้ว PPK ปรับ Position เพิ่มเล็กน้อย: ต่างราว 1 cm ใน XY และมากกว่าใน Z แต่ Image Quality ต่างกันเพียงเล็กน้อย

ArduPilot Raw GPS Logging เจออะไร?

GPS บน Drone เชื่อมกับ Flight Controller และ Position/Timing ถูกส่งต่อไปยัง Radar

Creator ทดลองใช้ GPS Raw Data Logging ของ ArduPilot สำหรับ PPK แต่ Version ที่ใช้อยู่ตอนพัฒนามีปัญหา เช่น:

  • Buffer รองรับ Satellite Measurement ได้เพียง 32 รายการ
  • Measurement ที่มี Satellite มากกว่านั้นถูก Drop
  • Signal ID / Frequency Band ไม่ถูก Log ทำให้ Phase Solving ใช้งานไม่ได้

เขาแก้ปัญหาเหล่านี้ และส่ง Pull Request กลับไปยัง ArduPilot

อย่าอ่านส่วนนี้เป็น Bug Report ของ ArduPilot เวอร์ชันปัจจุบัน: นี่คือปัญหาที่ Creator พบใน Version ที่ใช้งานระหว่างการพัฒนา Project และเขาระบุว่าได้ส่ง Fix upstream แล้ว

RTCM Correction ก็มี Bandwidth Bottleneck ได้

ช่วงแรก Creator ส่ง RTCM Corrections ผ่าน ExpressLRS ใน MAVLink Mode แต่ Correction Data ใช้ Bandwidth มากกว่าที่ Link รองรับ จึงเกิด Packet Drop

RC Command ยังทำงานได้ เพราะมี Priority สูงกว่า แต่ RTK Fix Quality ได้รับผล

วิธีแก้คือสร้าง RTCM Server ของตัวเอง ที่จำกัด Bandwidth เพื่อไม่ให้ Telemetry Link อิ่ม

Engineering Lesson: Sensor อาจแม่นมาก แต่ถ้า Data Link ส่ง Correction ไม่ครบ Accuracy ของระบบจริงก็ลดลงได้

PLL ทำไมสร้าง Artifact ในภาพ Radar ได้?

block diagram ของ PLL และ active loop filter ใน FMCW radar
FMCW Frequency Sweep ของ Radar ถูกสร้างจาก PLL, Loop Filter และ VCO ซึ่งการ Tune ที่ไม่เหมาะสามารถเพิ่ม Spur และ Phase Noise ได้

FMCW Radar ส่ง Linear Frequency Sweep และ Radar ของ Creator ใช้ PLL สร้าง Sweep นี้

Loop Filter เดิมมี Bandwidth กว้างเกินไป ขณะที่ Charge Pump Current ตั้งต่ำเกิน ทำให้เกิด Instability และ Spur

Integer Boundary Spur หรือ IBS

เมื่อ PLL Sweep ผ่าน Integer Multiple ของ Reference Frequency สามารถเกิด Spur ที่แรงขึ้นได้ ถ้า Loop Filter ตั้งไม่เหมาะ

Impulse สั้นแต่ Wideband เหล่านี้ สะสมใน SAR Image จนเห็นเป็นเส้น Artifact

ค่าที่ Creator Optimize ใน Test ชุดหนึ่ง:
Loop bandwidth ประมาณ 60 kHz
Phase margin ประมาณ 55°
ห้ามนำ 60 kHz / 55° ไปใช้เป็นค่ามาตรฐานของ FMCW Radar ทุกตัว: ค่านี้เกิดจาก Hardware, LMX2491-like configuration และ Sweep Parameters ของ Creator ในการทดสอบนั้น
ตัวอย่าง integer boundary spur ใน raw radar signal
ตัวอย่าง IBS ที่เกิดขึ้นเมื่อ PLL Sweep ผ่านบริเวณ Integer Boundary
ผลจำลอง PLL sweep non-linearity และ integer boundary spur
Creator สร้าง PLL Simulator เพื่อช่วย Optimize Loop Filter สำหรับ Frequency-sweeping PLL
range doppler comparison ก่อนและหลังปรับ PLL loop filter
Range-Doppler Map แสดง Artifact ก่อนและหลังปรับ Loop Filter โดย Spur หลักลดลงอย่างชัดเจนในระบบนี้

ADC 75 MB/s แต่ SD รับได้ราว 20 MB/s แก้ยังไง?

block diagram digital interface ของ FMCW SAR radar
Data Path ของ Radar ต้องรับ Raw ADC Data อัตราสูง แต่ปลายทางสุดท้ายต้องเขียนลง SD Card
จุดในระบบ ค่าที่ Source ระบุ
ADC Sample Rate 50 MSPS
ADC Resolution 12-bit
Raw Data Rate 75 MB/s
SD Interface Theoretical 25 MB/s
SD Practical ประมาณ 20 MB/s

เดิม Creator เก็บ Data ลง EMMC ก่อน แล้วหลัง Measurement ค่อย Copy ไป SD

Measurement ประมาณ 1 นาที อาจต้องรอ Copy อีกราว 3 นาที ทำให้ Workflow ช้ามาก

แทนที่จะทำ PCB ใหม่ เขาเลือกแก้ด้วย Data Compression

Custom Lossless Compression ทำงานอย่างไร?

histogram ของ radar samples และ sample delta สำหรับออกแบบ compression
Histogram แสดงว่า Sample Delta ส่วนใหญ่มีค่าค่อนข้างเล็ก ซึ่งเหมาะกับ Variable-length Encoding

FMCW Signal ใน Time Domain ค่อนข้าง Smooth เพราะ Return ระยะใกล้ มี Amplitude สูงกว่าส่วนความถี่ที่แทนระยะไกล

Creator จึงใช้แนวคิด:

  1. คำนวณ Difference ระหว่าง Sample ติดกัน
  2. ทำ Zigzag Encoding เพื่อเปลี่ยน Signed Value เป็น Positive Value
  3. ใช้ Code สั้นสำหรับ Delta เล็ก
  4. ใช้ Code ยาวขึ้นเฉพาะ Delta ที่ใหญ่

ใน Measurement ตัวอย่างหนึ่ง:

  • 79% ของ Sample ใช้ 1-nibble code
  • 20% ใช้ 3-nibble code
  • เพียง 0.004% ใช้ 5-nibble code
Method Compression Ratio Bits / Sample
FLAC 2.8× 4.5
Rice 2.7× 4.8
Nibble 2.3× 5.7
zstandard 2.1× 6.1
gzip 2.0× 6.5
ทำไมไม่เลือก FLAC ทั้งที่ Ratio ดีกว่า? เพราะเป้าหมายคือ Real-time FPGA Implementation ไม่ใช่ Compression Ratio อย่างเดียว Nibble Scheme ทำ Hardware ได้ง่าย และ Decode บน CPU ได้เร็วกว่า

ทำไม Compressor ต้องอยู่ใน FPGA?

block diagram FPGA stream compressor สำหรับ radar ADC data
Compressor ถูกย้ายไปยัง Programmable Logic และเชื่อม Data ด้วย DMA + AXI Stream

ARM Core ใน Zynq SoC ของระบบนี้ รันที่ 667 MHz แต่ Creator พบว่า แม้ Algorithm จะง่าย CPU ก็ยังประมวลผล ADC Stream แบบ Real-time ไม่ทัน

เขาจึง Implement Compressor ใน Programmable Logic ของ FPGA

RAM
↓
DMA
↓
AXI Stream Compressor
↓
DMA → RAM

Implementation ของ Creator ประมวลผลได้ประมาณ 3 Samples ต่อ Clock Cycle และเมื่อรวม Compression กับ 2× Decimation Data Rate สามารถลดลงจนเขียน SD ได้ง่ายขึ้น

Custom Ground Control Software ช่วยอะไร?

custom ground control software แสดงแผนที่และสถานะ radar drone
Ground Control Software ที่ Creator เขียนขึ้นเอง มีทั้ง Map, Radar Status และ Mission Workflow สำหรับ SAR

เดิม Creator ใช้ Mission Planner แต่บน Linux เจอทั้งเรื่อง Mono, Performance, Crash และ Workflow สร้าง Radar Mission ที่ยุ่งยาก

จึงเขียน Ground Control Software ที่ออกแบบสำหรับ SAR โดยเฉพาะ

  • สร้าง Linear SAR Mission
  • สร้าง Circular SAR Mission
  • สร้าง Interferometric SAR Mission
  • ตั้ง Sweep Length
  • ตั้ง PRF
  • เลือก Polarization
  • ดู Radar Status แบบ Real-time
  • Upload RTCM Correction
  • Save Base Station Log
  • จัดการ Telemetry Bandwidth
  • ปรับ ArduPilot Parameters
  • Download Autopilot Logs
  • ดู Drone Location และ Telemetry
Ground Station ไม่ได้เป็น Flight Safety Controller หลัก: Creator ระบุว่า Mission-critical Logic อยู่ใน Flight Controller ที่รัน ArduPilot ไม่ใช่ใน Ground Control UI
หน้าจอสร้าง SAR mission plan อัตโนมัติ
Software สามารถ Generate Waypoint และ Action สำหรับ SAR Mission แทนการป้อนทุกจุดด้วยมือ

Processing Pipeline จาก Raw Radar ไปเป็น DEM

interferometric SAR processing pipeline จาก autofocus ไปจนถึง elevation
Pipeline หลักของ InSAR: Autofocus → Backprojection → Alignment / RME → Interferogram → Phase Unwrapping → Elevation
  1. GPGA Autofocus: Focus แต่ละ Pass แยกกัน
  2. Backprojection: สร้างภาพบน Flat Ground Plane หรือ Reference DEM
  3. Grid Alignment: Interpolate ภาพให้ตรง Grid เดียวกัน
  4. Residual Motion Estimation: แก้ Phase Error ที่ยังเหลือระหว่าง Pass
  5. Interferogram: สร้าง Phase Difference ระหว่างภาพ
  6. Filtering: ลด Noise ตามความเหมาะสม
  7. Phase Unwrapping: Creator ใช้ SNAPHU
  8. Elevation: แปลง Unwrapped Phase ไปเป็น DEM

หากมี Reference DEM Backprojection สามารถใช้ Surface นั้นเป็น Reference ทำให้ Phase ที่เหลือแสดงความต่าง ระหว่าง Measurement กับ Reference ซึ่งช่วยให้ Unwrap ง่ายขึ้น

RME ช่วย Coherence ได้แค่ไหน?

InSAR result ก่อนใช้ autofocus และ residual motion estimation
ก่อนใช้ Autofocus และ RME Mean Coherence ของ Mission หลักอยู่เพียง 0.210 และ Interferogram มี Noise สูง

ปัญหาของ InSAR คือ ภาพ Amplitude สอง Pass อาจดูคล้ายกันมาก แต่ Phase Error เพียงเล็กน้อย ก็ทำให้ Interferogram แย่ลงได้มาก

Creator จึงพัฒนา Residual Motion Estimation จากแนวคิด Generalized Phase Gradient เพื่อ Align Phase History ระหว่าง Pass

Creator ระบุว่า Method นี้ เป็นแนวทางใหม่ตามความรู้ของเขา จึงควรตีความเป็น Claim ของผู้พัฒนา ไม่ใช่ข้อสรุปว่าเป็น Algorithm แรกที่ผ่าน Peer Review แล้ว

Processing Mean Coherence
No Autofocus / No RME 0.210
Autofocus 0.297
Autofocus + RME 0.453
Autofocus + RME + Reference DEM 0.468
InSAR result หลังใช้ autofocus แต่ยังไม่ใช้ RME
หลังใช้ Autofocus อย่างเดียว Coherence ดีขึ้น แต่ยังมี Phase Error เหลือ
InSAR result หลังใช้ autofocus และ residual motion estimation
หลังใช้ Autofocus + RME Interferogram และ Coherence ดีขึ้นชัดเจนใน Mission นี้
trajectory correction ที่ได้จาก SAR autofocus
ตัวอย่าง Correction ที่ได้จาก Autofocus ของ Pass แรก
residual motion correction ที่ได้จาก RME
RME Correction ส่วนใหญ่ในตัวอย่างนี้ อยู่ใน Elevation Direction
ค่าความ Coherence เหล่านี้ไม่ใช่ Benchmark สากล: เป็นผลเฉพาะ Mission, Scene, Geometry และ Processing Configuration ของ Project นี้

Flight Mission ถูกวางแผนยังไง?

Drone บิน Measurement แบบอัตโนมัติ ผ่าน Mission ที่สร้างจาก Custom Ground Control

Parameter ค่าที่ Creator ใช้
Transit Speed Limit 10 m/s เพื่อ Safety
SAR Capture Speed 5 m/s
Pass Direction บินทิศเดียวกัน
Vertical Baseline 1 m

Capture ที่ 5 m/s ช่วยให้เก็บ Measurement ได้มากขึ้นต่อระยะทาง เมื่อเทียบกับการบินเร็วกว่า

สอง Pass ถูกบินทิศเดียวกัน เพื่อให้ Doppler และ Timing Error บางชนิดมีแนวโน้ม Cancel กัน ได้ง่ายกว่าการบินสวนทิศ

ค่าความเร็วและ Baseline เหล่านี้เป็น Mission Parameter ของระบบนี้: ไม่ควรนำไปใช้กับ Drone หรือ Radar คนละ Platform โดยไม่วิเคราะห์ Flight Dynamics, Sampling Geometry และข้อกำหนดความปลอดภัยใหม่

SAR DEM เทียบ Lidar ได้ใกล้แค่ไหน?

digital elevation model จาก interferometric SAR เทียบกับ lidar reference
DEM จาก InSAR ถูกเปรียบเทียบกับ Lidar Reference ของ National Land Survey of Finland

หลัง Phase Unwrapping ด้วย SNAPHU Creator สร้าง DEM แล้วเปรียบเทียบกับ Lidar Reference

ใน Dataset นี้:

  • RMS Height Difference: 0.4 m
  • Median Absolute Difference: 0.11 m
อย่าแปล 0.11 m เป็น “Accuracy ของ Radar = 11 cm”: ตัวเลขนี้คือ Median Absolute Difference ของ DEM ใน Measurement และ Comparison ชุดนี้ ไม่ใช่ Sensor Accuracy Specification

Creator ยังพบ Baseline Error คงที่ ระดับมิลลิเมตร ซึ่งหากไม่แก้ สามารถกลายเป็น Elevation Error ระดับหลายเมตรที่ขอบภาพ เพราะ InSAR ไวต่อ Geometry มาก

ทำไม Forest และ Shadow กลายเป็นช่องว่างใน DEM?

Low Coherence บางส่วน ไม่ได้เกิดจาก Software Error อย่างเดียว

Vegetation

Return จากต้นไม้และพืช เปลี่ยนระหว่าง Pass เพราะโครงสร้างมี Height Variation มาก ทำให้ Phase ไม่ Correlate กันดี

Radar Shadow

พื้นที่ที่ Radar Beam มองไม่ถึง ไม่มี Return ที่เพียงพอ จึงไม่สามารถสร้าง Elevation อย่างน่าเชื่อถือได้

Smooth Surface

ถนนเรียบบางมุม สะท้อน Energy กลับ Radar น้อย จึงมี Signal ต่ำ

SNAPHU ช่วยระบุ Connected Region ที่ Phase Unwrapping เชื่อถือได้ และ Creator ตัดพื้นที่ที่ไม่น่าเชื่อถือออกจาก DEM

Mission ที่สองบอกอะไรเรา?

flight tracks ของ SAR drone สอง mission ที่ทำมุมต่างกัน
Creator บิน Mission ที่สอง โดยหมุน Track ประมาณ 90° เพื่อเก็บ Scene เดิมจาก Geometry ต่างกัน

Mission ที่สองบินหลัง Mission แรกเพียงไม่กี่นาที และใช้ Vertical Baseline 1 m เช่นกัน

หลัง Autofocus + RME Mean Coherence ของ Mission ที่สอง อยู่ที่ 0.480 รวมพื้นที่ที่ Decorrelate ด้วย

เมื่อจำกัดเฉพาะ Field Area Coherence เข้าใกล้ 1 มากขึ้น แสดงให้เห็นว่า Scene Type และ Look Angle มีผลต่อ InSAR อย่างมาก

DEM จาก SAR mission ที่สอง
DEM จาก Track ที่หมุน 90° ยังคงสอดคล้องกับ Reference ในพื้นที่ที่ Measurement มีคุณภาพดี
coherence histogram เปรียบเทียบ processing ของสอง SAR missions
Histogram แสดงผลของ Autofocus + RME ต่อ Coherence ในพื้นที่ Field

Processing บน RTX 3090 Ti ใช้เวลานานแค่ไหน?

Creator ให้ Processing Example ของ Full SAR Image ไว้ชัดเจน

รายการ ค่าจาก Measurement ตัวอย่าง
GPU RTX 3090 Ti
Input 17,000 Radar Sweeps
Output Grid 4,156 × 16,473 pixels
Autofocus 22 seconds
Image Formation 0.9 seconds / polarization
นี่เป็น Processing Example ไม่ใช่ Benchmark ทั่วไป: เวลาเปลี่ยนได้ตาม GPU, Image Grid, Sweep Count, Algorithm Configuration และ Data ที่ใช้

ดู Source Code ใน torchbp

Creator เปิด Source Code สำหรับ SAR Image Formation และ Autofocus ใน Repository: torchbp

Current Repository อธิบายตัวเองว่าเป็น C++ / PyTorch extension สำหรับ Differentiable SAR Image Formation และ Autofocus บน GPU

Current README ระบุว่า Nvidia GPU ได้รับการรองรับเป็นหลัก และ CPU รองรับเพียงบาง Operation

Official torchbp README — Install from source 
pip install torch
git clone https://github.com/Ttl/torchbp.git
cd torchbp
pip install --no-build-isolation -e .
Current torchbp README มี Version Caveat: Extension ต้อง Build กับ PyTorch ตัวเดียวกับที่ใช้ตอน Run เพราะ libtorch C++ ABI ไม่ Stable ข้าม Version และ README ปัจจุบันจึงระบุให้ใช้ --no-build-isolation
เปิด torchbp บน GitHub อ่าน torchbp Documentation

ดู SAR Measurement จาก Drone จริง

Creator มี VideoSAR จาก Measurement จริง เพื่อให้เห็นว่าภาพ Radar เปลี่ยนตามตำแหน่ง Drone อย่างไร

Maker ได้อะไรจาก Project นี้?

1. Sensor Accuracy อย่างเดียวไม่พอ

Positioning, Timing, RF Hardware, Data Link และ Image Processing ต้องแม่นร่วมกันทั้งระบบ

2. Hardware Artifact อาจดูเหมือน Software Bug

Straight-line Artifact ใน SAR Image บางส่วน มาจาก PLL / IBS ไม่ใช่ Image Processing เพียงอย่างเดียว

3. Bottleneck แก้ได้หลาย Layer

แทนการทำ PCB ใหม่เพื่อเพิ่ม SD Bandwidth Creator ใช้ Algorithm + FPGA Compression แก้ข้อจำกัดของ Hardware เดิม

4. RTK ไม่ได้ทำให้ Motion Error หายทั้งหมด

แม้ Position Reference ดีขึ้นมาก InSAR ก็ยัง Sensitive จนต้องมี Autofocus และ RME ช่วยแก้ Residual Error

5. Open-source Processing ทำให้ Project ต่อได้ไกลกว่า Hardware ชิ้นเดียว

Hardware Radar ชุดนี้ไม่ได้ขาย แต่ Processing Library อย่าง torchbp เปิด Source ภายใต้ MIT License ให้ศึกษาและต่อยอดได้

FAQ: คำถามที่พบบ่อย

1. SAR คืออะไร?

Synthetic Aperture Radar ใช้การเคลื่อนที่ของ Radar และการรวม Measurement หลายตำแหน่ง เพื่อสร้าง Aperture เสมือนและสร้างภาพ Radar

2. InSAR ต่างจาก SAR ยังไง?

InSAR ใช้ Phase Difference จากมากกว่าหนึ่ง SAR Measurement เพื่อวัดความต่างของ Geometry เช่น Elevation ของพื้นผิว

3. Project นี้ใช้ Radar แบบไหน?

Source ระบุ FMCW Radar

4. ทำไม GPS ปกติถึงไม่พอ?

Creator ระบุว่า Non-RTK GPS มี Error ประมาณ 1 m ในการเปรียบเทียบ ซึ่งทำให้ SAR Image Blur หากไม่ใช้ Autofocus ช่วย

5. RTK ให้ Accuracy เท่าไร?

ใน System นี้ Creator ใช้ค่าประมาณ 2 cm แต่ไม่ควรถือเป็น Accuracy Guarantee ของ RTK ทุกระบบ

6. ทำไมต้องใช้ PPK เพิ่มจาก RTK?

PPK Solve Position แบบ Offline จาก GNSS Data ทั้ง Base และ Rover และช่วยได้เมื่อ Real-time Correction Link มีปัญหาชั่วคราว

7. Radar ใช้ PLL รุ่นอะไร?

Source ระบุ LMX2491 ใน Frequency-sweeping PLL ของระบบ

8. Loop bandwidth 60 kHz ใช้กับ Radar อื่นได้เลยไหม?

ไม่ ค่านี้มาจาก Optimization สำหรับ Hardware และ Sweep Parameter ของ Creator ใน Test ชุดนั้น

9. ADC สร้าง Data เร็วเท่าไร?

Source ระบุ 50 MSPS, 12-bit หรือ Raw Data Rate 75 MB/s

10. ทำไมไม่ใช้ gzip หรือ zstandard?

Creator ต้องการ Real-time FPGA Implementation และเลือก Nibble Scheme เพราะ Hardware ง่ายกว่าและ Decode เร็วกว่า แม้ Compression Ratio ไม่ดีที่สุด

11. Compression Ratio ของระบบเท่าไร?

Measurement ตัวอย่างหนึ่ง ได้ประมาณ 2.3× และ 5.7 bits/sample แต่ Ratio ขึ้นกับ Data

12. RME คืออะไร?

Residual Motion Estimation ใช้แก้ Phase Error ที่ยังเหลือระหว่าง SAR Pass หลัง Autofocus

13. Coherence ดีขึ้นเท่าไรหลัง RME?

ใน Mission หลัก Mean Coherence เพิ่มจาก 0.297 หลัง Autofocus เป็น 0.453 หลัง Autofocus + RME

14. Baseline ระหว่างสอง Pass เท่าไร?

Mission ที่อธิบายใช้ Vertical Baseline 1 m

15. Drone บินเร็วเท่าไรตอนเก็บ SAR?

Creator ใช้ 5 m/s ตอน Capture และจำกัด Transit ไว้ที่ 10 m/s เพื่อ Safety

16. DEM ของระบบแม่น 11 cm หรือไม่?

ไม่ควรสรุปแบบนั้น Source ระบุ Median Absolute Difference 0.11 m และ RMS Height Difference 0.4 m สำหรับ Dataset ที่เปรียบเทียบกับ Lidar

17. ทำไม Forest มี Coherence ต่ำ?

Vegetation Return เปลี่ยนระหว่าง Pass และมี Height Variation มาก ทำให้ Phase Decorrelate

18. Source Code เปิดหรือไม่?

SAR Processing Code เปิดอยู่ใน torchbp Repository ภายใต้ MIT License แต่ Hardware Radar ทั้งชุดไม่ได้ขาย

19. ระบบทั้งหมดราคาเท่าไร?

Creator สรุป Hardware Cost ของ Radar + Drone ใน Project นี้ ไว้ราว 1,000 EUR ซึ่งเป็น Cost Context ของการสร้างชุดนั้น ไม่ใช่ราคาสินค้าปัจจุบัน

20. มี STL ของ GPS Holder ให้ดาวน์โหลดไหม?

Source แสดงว่ามีชิ้นส่วน 3D Printed GPS Holder แต่ชุด Source ที่ใช้ในบทความนี้ ไม่ได้ให้ STL/CAD File จึงไม่มีไฟล์ให้ดาวน์โหลดจากบทความนี้

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

Radar Project แบบนี้ไม่ได้ยากเพราะมี Sensor ตัวเดียว

สิ่งที่ Project นี้แสดงได้ชัด คือระบบ Remote Sensing ขั้นสูง ต้องทำให้ GNSS, RF, FPGA, Flight Controller, Data Link และ Processing Pipeline ทำงานสัมพันธ์กันทั้งหมด

หากกำลังทดลองงาน Embedded, GNSS, FPGA, Sensor หรือ Development Board Project สามารถสอบถามทีม Globalbyte เรื่องบอร์ด, Module และอุปกรณ์ที่เหมาะกับ Project ได้

ช้อปสินค้า / บริการ เข้ากลุ่ม Community สอบถามผ่าน LINE OA
Disclaimer: บทความนี้เป็นการสรุปและเรียบเรียงจากแหล่งข้อมูลภาษาอังกฤษ อาจมีความคลาดเคลื่อน กรุณาตรวจสอบ Source ต้นฉบับก่อนลงมือทำ ตัวเลข Position Accuracy, Coherence, Compression Ratio, Processing Time, DEM Difference, Flight Speed และ Baseline ที่กล่าวถึง เป็นค่าจาก Hardware, Mission, Geometry และ Dataset ของ Project นี้ ไม่ใช่ Specification ทั่วไปของ SAR หรือ InSAR ค่า PLL Loop Bandwidth 60 kHz และ Phase Margin 55° ก็เป็นผล Optimization สำหรับ Sweep Parameters ของ Creator ไม่ใช่ค่าที่ควร Copy ไปใช้กับ Radar อื่นโดยตรง Project เกี่ยวข้องกับ UAV, RF Transmission, Battery, Autonomous Flight และ High-rate Data Acquisition ซึ่งต้องพิจารณากฎหมายการบิน, RF Regulation, Electrical Safety และข้อจำกัดของ Airframe จริง ก่อนทดลอง บทความนี้ไม่ได้สร้าง Wiring, Radar Frequency, RF Power, Battery Specification หรือ Autonomous Flight Parameter ที่ Source ไม่ได้ระบุเพิ่มเติม Hardware Radar ชุดนี้ไม่ได้จำหน่ายโดย Creator ส่วน SAR Processing Code อยู่ใน torchbp Repository ภายใต้ MIT License

 

แท็ก

SAR drone

Blog posts