Wildlife survey operations
Summary¶
Wildlife aerial survey using a thermal payload follows a five-phase operational workflow: pre-dawn preparation, autonomous grid flight during the thermal window, landing and data retrieval, detection processing, and report delivery. The deliverable is not footage — it is a PDF report with GPS-referenced detection counts suitable for submission to a ministry or land management authority. On libdrone Wing, the autonomous grid is executed by ArduPilot Plane with QGroundControl, the thermal data is logged by the ESP32-S3 payload companion, and the report is generated by a post-processing script running on a field laptop.
Concept¶
Service model vs hardware model¶
Wildlife survey with Wing is a service, not a product sale. The customer (a hunting association, a forestry department, an environmental NGO) needs a number — deer counted per hectare, GPS positions of wild pig groups — not a drone. The service model means Wing's commercial value is in repeatable delivery of credible data, not in hardware specification. A survey that produces unusable imagery because it was flown at the wrong time of day has zero commercial value regardless of the platform's capability.
The two most common failure modes in wildlife thermal survey are: 1. Flying outside the thermal window (ground too warm → no contrast) 2. Flying too high or with too wide a lens (animals too small to detect reliably → low confidence counts)
Both failures are operational, not technical. The technical requirements (thermal camera, autonomous grid, GPS logging) are straightforward to meet. Meeting them at the right time, in the right conditions, and producing a report the customer trusts is the operational challenge.
The thermal window¶
The optimal thermal window is 30–90 minutes before and after sunrise in autumn and winter. Planning a survey requires:
- Check sunrise time for the survey location and date.
- Check weather: cloud cover reduces ground cooling overnight (reduces contrast); wind above 4 m/s affects low-altitude fixed-wing stability.
- Check temperature: below 10°C ambient increases contrast; above 15°C reduces it. October–February is the reliable window in Central Europe.
- Arrive at the survey site 45 minutes before the survey window opens: set up, GPS lock, mission upload, pre-flight checks.
From detection to report¶
The ESP32-S3 on Wing's payload bay logs GPS-tagged thermal frames to MicroSD at each camera trigger event. Post-flight processing:
- Download MicroSD content to field laptop.
- Run detection script (Python + OpenCV): identify thermal blobs above a confidence threshold; extract GPS coordinates from EXIF / log.
- Generate KML file for GIS overlay (QGIS).
- Generate PDF report: survey date, area covered, detection count per species (where distinguishable), GPS positions, representative frames.
- Deliver report to customer contact.
The detection script and report generator are identified as open points in the Wing specification — they require approximately one weekend of development.
Reference¶
Survey planning parameters¶
| Parameter | Value |
|---|---|
| Survey altitude | 40–60 m AGL |
| Optimal time | 30–90 min after sunrise (autumn/winter) |
| Ambient temperature | < 10°C preferred |
| Wind limit | < 6 m/s for stable fixed-wing flight |
| Swath (Boson 320, 50 m AGL) | ~22 m |
| Swath (Lepton 3.5, 50 m AGL) | ~53 m |
| Transect overlap | 30% (detection); 70%+ (photogrammetry) |
| Survey area per battery | ~25 ha (Boson swath, 3 m/s, 45 min) |
Operator roles¶
| Role | Responsibility |
|---|---|
| Pilot | Arms aircraft, monitors QGC HUD, manages RC failsafe |
| Data operator | Monitors thermal feed (if live), manually flags detections |
| Report author | Runs post-flight processing, delivers PDF |
One experienced operator can cover all three roles for proof-of-concept surveys. Two-operator deployment is recommended for first commercial surveys.
Procedure¶
Standard dawn survey workflow¶
T−45 min: Arrive at survey site. Set up GCS laptop. Power on Wing and payload. Wait for GPS lock (HDOP < 1.5, ≥ 8 satellites).
T−30 min: Upload survey grid mission in QGroundControl. Verify flight path covers target area. Confirm mission ends with RTL.
T−15 min: Pre-flight check: battery voltage, control surface deflection, camera trigger fires, ESP32-S3 logging active (SD write LED blinking).
T=0 (survey window opens): Hand-launch Wing. Monitor climb to survey altitude in QGC. Confirm TECS maintains target airspeed and altitude. Switch to AUTO mode. Mission begins.
During survey: Monitor QGC HUD. Note any altitude deviations > ±5 m. Optionally monitor live thermal feed. Be ready to override AUTO if aircraft deviates from planned track.
End of mission: Wing executes RTL automatically on mission completion. Monitor approach and landing. Retrieve Wing and SD card.
Post-flight: Run detection script on field laptop. Review detections for false positives (rocks, water, fence posts can produce thermal signatures). Generate and review PDF. Deliver to customer contact.
Rationale¶
The five-phase workflow is explicit to prevent the most common failure: a technically successful flight that produces no usable data because the operator flew at the wrong time or altitude. Wildlife survey is operationally dependent on conditions that are easy to verify in advance (time, temperature, wind) but often ignored in the rush to fly. The workflow treats pre-flight planning as the primary quality gate, not the technical performance of the aircraft.
Connections¶
yaml requires: - [wing-variant](<./wing-variant.md>) - [thermal-imaging-payload](<./thermal-imaging-payload.md>) - [qgroundcontrol](<./qgroundcontrol.md>) - [ardupilot-plane](<./ardupilot-plane.md>) related: - [survey-imaging](<./survey-imaging.md>) - [aerial-imaging-basics](<./aerial-imaging-basics.md>) - [pre-flight-check](<./pre-flight-check.md>) - [post-flight-check](<./post-flight-check.md>) - [easa-open-category](<./easa-open-category.md>) leads_to: - [post-flight-check](<./post-flight-check.md>)