Lumipad ← Back to homepage
Library · Reference

The software in your hand.

Once the drone is in the air, your hands are on a radio, your eyes are on FPV goggles, and your laptop or phone shows telemetry, mission progress, and the OSD overlay. This is the software stack on your side of the link — what runs on the operator's hardware during a mission and after. Different from fc-setup.html (which covered the FC's firmware) and from missions.html (which covered the planning thinking). This page covers the operator side: ground stations, telemetry, in-mission monitoring, log review.

Version 1.0 · Updated 05·2026 Author: Lumipad Engineering License: CC-BY-SA-4.0 Languages: EN
4
Ground-station tools covered
3
Telemetry protocols
~5
In-mission alerts to monitor
~30 min
Post-flight log review
How to read this page

Operator-side software, not drone-side.

fc-setup.html covered configuring the flight controller's firmware. firmware.html covered managing that firmware over time. This page covers the software running on your hardware — the laptop you bring to the field, the phone in your pocket, the configuration that monitors the drone during flight and lets you review what happened afterwards.

The page is structured top-to-bottom by typical use: the ground-station landscape (Section 1), telemetry links between drone and laptop (Section 2), in-mission monitoring (Section 3), post-flight log review (Section 4), mobile workflows for partner-org operations (Section 5), and multi-drone fleet coordination (Section 6). Sections 5 and 6 are partner-org specific; individual alumni can mostly skip them.

Section 01 Pick once per build; reconsider rarely

The ground-station landscape.

A ground station is the software running on your laptop, tablet, or phone that talks to the drone — for configuration, mission upload, in-flight monitoring, and post-flight review. Four ground stations are realistic options for cohort default builds. The choice is mostly determined by which firmware your FC runs; the second factor is what features you actually need.

The four ground stations:

Tool Works with Strengths Cohort role
INC
INAV Configurator Same tool used for FC setup. Has a Mission Control tab for mission planning and a CLI tab for advanced settings. Modest in-flight monitoring features.
INAV firmware (cohort 5"/7" builds).
+ One tool covers config, missions, and monitoring. Free.
− In-flight monitoring is basic; no real-time map view. Best for one-drone setups.
Cohort default for individual alumni with INAV builds.
MP
Mission Planner ArduPilot's official ground station. Comprehensive: mission planning, in-flight monitoring with map, full telemetry view, log analysis, parameter management.
ArduPilot firmware (cohort 10" builds; some advanced 7" builds).
+ Most capable. Real-time map shows drone position, mission progress, alerts. Extensive logging and analysis built-in.
− Windows-primarily; Mac via Mono with limitations. Steeper learning curve. ArduPilot-specific.
Cohort default for ArduPilot 10" builds. Required for serious mission work on those builds.
QGC
QGroundControl Cross-platform alternative ground station. Works with both ArduPilot and PX4 (and INAV with limitations). Modern interface, solid feature set.
ArduPilot, PX4, partial INAV support.
+ True cross-platform: Windows, Mac, Linux, iOS, Android. Best mobile/tablet ground station option.
− Less mature than Mission Planner for ArduPilot-specific features. INAV support is limited.
Cohort recommendation for partner orgs with mixed Mac/Linux operators or for tablet/phone-based field workflows.
UGS
UgCS Commercial ground station. Multi-drone mission planning, advanced terrain following, mission optimization, fleet management features.
ArduPilot, PX4, MAVLink-compatible firmware.
+ Best multi-drone and fleet management. Sophisticated mission optimization. Used by some commercial drone services.
− ~$200/year basic edition; pricier tiers for fleet management. Overkill for individual alumni.
Cohort recommendation for partner orgs running 5+ drones in coordinated operations. Not for individual alumni.

The "do I need a ground station beyond the configurator" question

For individual alumni doing simple cohort default missions: probably not. INAV Configurator handles mission planning, upload, basic in-flight monitoring, and post-flight log access. Adding Mission Planner or QGroundControl provides better in-flight visualization and log analysis but is overkill for one-drone cohort default operations.

When a separate ground station starts to matter:

  • Multi-drone operations (UgCS becomes useful at 5+ drones)
  • Mission complexity beyond cohort defaults (terrain-following, multi-AOI surveys, complex mission patterns)
  • Need for real-time map view of drone position during longer missions (Mission Planner or QGC)
  • Tablet/phone-based field workflow (QGC, especially on iOS/Android)

Until one of these applies, the configurator is sufficient. Don't add tooling complexity that doesn't earn its place.

Cohort recommendations summary:

  • 5" or 7" cohort default INAV build, single drone: INAV Configurator. Free, sufficient.
  • 10" cohort default ArduPilot build: Mission Planner. The capability gap vs INAV Configurator is significant on ArduPilot builds.
  • Tablet/phone field workflow: QGroundControl (especially iOS).
  • Partner org with 5+ drones: UgCS for fleet operations.

The downloadable setup pack (linked at the top of this page) includes cohort default configurations for INAV Configurator and Mission Planner — telemetry rates, OSD overlays, mission template defaults, log capture settings.

Section 02 The radio link the ground station depends on

Telemetry links.

Ground stations need a way to talk to the drone in flight. The telemetry link is the radio channel the laptop uses to receive drone status (battery voltage, GPS position, mode, attitude) and send commands (mission upload, mode changes, RTH triggers). Without a working telemetry link, the ground station is just configuring the drone before flight — no in-flight monitoring possible.

Three telemetry approaches matter for cohort default builds:

Approach How it works Range and reliability Cohort use
CRSF
CRSF telemetry (over ELRS) Telemetry rides the same ELRS radio link used for control. Drone reports battery, GPS, attitude back through the receiver to the radio.
Same range as control link (~5km LOS for 100mW ELRS). Highly reliable; same antenna and link the radio uses.
Cohort default for OSD-displayed flight info. Limited to what fits in CRSF telemetry frames; less detail than dedicated telemetry.
USB
USB cable to FC (pre-flight only) Direct USB connection from laptop to FC. Used for configuration, mission upload, and post-flight log download.
Zero range — only works while connected. Not usable in flight.
Cohort default for mission upload and configuration. Not telemetry, but the workflow that fills the gap when telemetry isn't available.
SIK
SIK radio modem (433 / 915 MHz) Dedicated 100mW or 500mW telemetry radio pair. One on the drone, one on the laptop's USB port. Carries MAVLink protocol bidirectionally.
~5km LOS at 100mW; ~15km at 500mW. Reliable; lower bandwidth than CRSF but full MAVLink protocol.
Cohort recommendation for ArduPilot 10" builds running Mission Planner. Adds ~₱2,500 for the radio pair but enables full ground-station integration.
BT
Bluetooth or WiFi (FC built-in) Some FCs have built-in Bluetooth or WiFi modules for short-range telemetry. SpeedyBee F405 V4 has Bluetooth.
~30m line-of-sight; degrades fast through obstacles. Useful for pre-flight bench check but not in-flight.
Cohort default for mobile-app pre-flight verification. Don't rely on for in-flight monitoring.

The CRSF telemetry trade-off

CRSF carries telemetry on the same link as the control. Saves a radio; works at full radio range. But the bandwidth is limited (it's sharing a link primarily designed for control), so the data is condensed: voltage, RSSI, GPS coords, mode, altitude. Not the full MAVLink stream.

For cohort default 5"/7" missions: CRSF telemetry on OSD covers what the pilot needs in flight. The ground station (laptop) is mostly used pre-flight for upload and post-flight for log review.

For 10" research-grade missions: SIK telemetry pair gives full MAVLink to Mission Planner during flight, enabling real-time map view, mission progress overlay, and direct command channel. Worth the ₱2,500 for these builds.

Don't add SIK telemetry to a 5"/7" cohort default unless you specifically need the Mission Planner-style in-flight workflow. The CRSF + OSD approach is what cohort training uses, what alumni fly with, and what works.

Telemetry rate settings:

  • CRSF telemetry: configured in INAV at 4-8 Hz typically (drone-side). The OSD pulls from this. Don't increase past 8 Hz; bandwidth becomes a bottleneck and control link suffers.
  • SIK telemetry (MAVLink): 5-10 Hz default for ground-station map updates. Mission Planner has rate settings per stream type; default is fine for cohort use.
  • Bluetooth (in-bench): as fast as the FC will write; not relevant in flight.

Antenna placement matters more than people expect. Ground-station antennas at the operator's position should be at least 1.5m above the ground for usable range. SIK radios on a stand (a tripod, a pole) work much better than SIK radios sitting on the truck's tailgate. The cohort default field setup uses a 2m fishing-pole-style mast for the ground SIK antenna — adds 30 seconds to setup; doubles effective range in some sites.

Section 03 What you watch during a mission

In-mission monitoring.

During autonomous missions, the pilot's job shifts from active flying to active monitoring. The pilot is the catch-net for things the drone can't handle. This section covers what to watch on the ground station and OSD, what to do when alerts fire, and the discipline of staying engaged through long missions when nothing seems to be happening.

The five things to monitor during autonomous flight, in order of attention priority:

Monitor Where you see it Trigger to act Action
1
Battery voltage Per-cell voltage; total pack voltage; trend (dropping fast or steady?).
OSD top-left (cohort default); Mission Planner battery widget.
Below 3.6V/cell sustained: prepare to abort. Below 3.5V/cell: trigger RTH. Below 3.4V/cell: emergency land.
Switch to RTH mode; drone returns to launch point. Don't try to "finish the line" once at warning threshold.
2
RSSI / link quality Strength of the radio link. Drops when drone moves further from the operator or terrain blocks the signal.
OSD top-right; ground station has bar/percentage indicator.
Below -100 dBm or below 30%: drone is at the edge of reliable control.
If continuing: stop forward progress; wait for link to recover. If still degrading: trigger RTH while link still works.
3
Flight mode What the drone is currently doing — Mission, Position Hold, Angle, RTH.
OSD bottom-left; ground station mode indicator.
Mode changes you didn't command: investigate immediately. Could indicate failsafe firing or unexpected mode-switch input.
Verify ground station that the mode change is intentional; if not, re-establish control authority and switch to known-good mode.
4
GPS lock and satellite count Number of satellites; lock quality; HDOP or accuracy estimate.
OSD bottom-right; ground station GPS widget.
Sat count drops below 6: position-hold and RTH become unreliable. Sat count drops below 4: GPS-based modes fail.
Switch to Angle (manual) mode; take direct control; land manually.
5
Mission progress Current waypoint; remaining waypoints; estimated time to mission completion.
Mission Planner map view; INAV Configurator mission progress text; OSD doesn't show this.
Mission stalls (no progress for 30+ seconds): something is wrong with autonomous flow.
Take manual control; assess what the drone is doing; resume mission, abort, or fly the remaining manually.

The "boring autonomous mission" trap

A well-running autonomous mission is, frankly, boring. The drone flies waypoints; you watch numbers. Many alumni report the boredom is the hardest part of mission work — easier to stay sharp when actively flying than when monitoring 8 minutes of routine waypoint following.

Cohort approaches that work:

  • Verbalise what you see: speak the values out loud (battery, RSSI, mode) every 30 seconds. Forces engagement; helps observers (if any) follow along.
  • Observer rotation: in cohort cell flying, the observer (not the pilot) handles ground-station monitoring while the pilot watches the drone visually. Splits attention; both stay engaged.
  • Plan the abort thresholds before flight: "I'll abort if voltage hits 3.55V" is much easier to act on than "I'll abort when voltage gets low." The threshold-on-paper is the threshold-in-action.

The pilot's job during autonomous missions is exactly to catch the rare problem amid hours of routine. That requires staying engaged. The strategies above help.

OSD overlay during autonomous missions. The OSD on the FPV feed (or screen) provides at-a-glance status without needing to look at the ground station. Cohort default OSD layout (covered in fc-setup.html Section 8) shows battery, RSSI, mode, GPS, and a flight timer. Practice reading these without conscious thought — during stressful moments, the only useful information is what you can take in instantly.

Section 04 Where missions are reviewed and learned from

Logging & review.

Every mission produces logs: BlackBox flight data, telemetry stream, OSD recording. Most alumni never look at them; the ones who do learn faster and fly better. This section covers how to extract the logs, what to look for, and the cohort default workflow for post-mission review.

Three log sources matter for cohort missions:

Source What it captures How to extract What to do with it
BB
BlackBox flight log Per-loop FC state: gyro, motor outputs, RC inputs, mode, attitude, ~1-2 kHz sampling rate.
Onboard SD card or flash. Pull SD card after flight; insert into laptop.
Detailed flight analysis with PIDtoolbox or BlackBox Explorer. Used for tuning issues (covered in tuning.html Section 5) and incident investigation.
TLM
Telemetry log (MAVLink) Full telemetry stream as received by the ground station. Position, attitude, mode, battery — everything the ground station saw.
Mission Planner saves automatically to tlogs/ folder. INAV Configurator: enable telemetry logging in settings.
Mission Planner can replay the entire flight on the map — useful for understanding what happened during a difficult section. Not as detailed as BlackBox but easier to navigate.
OSD
OSD recording Video of FPV feed with OSD overlay. What the pilot saw during the mission.
FPV goggles or DVR recorded automatically. Also possible to record the laptop's ground-station screen.
Visual review of the mission: what looked weird, what wasn't obvious from numbers alone. Useful for client deliverables (showing the survey was conducted) and for training (reviewing trainee missions).

Cohort default post-flight review workflow (~30 minutes):

  1. Pull SD card from drone; copy BlackBox file to laptop. Filename includes timestamp.
  2. Locate ground-station telemetry log if applicable (Mission Planner saves YYYY-MM-DD HH-MM-SS.tlog files automatically).
  3. Review imagery quickly: open the SD card's photos folder in any image viewer. Scroll through to verify capture happened at expected intervals; no obvious blank or blurry frames.
  4. Skim BlackBox in PIDtoolbox: load the file, look at the FFT plot. If gyro noise looks elevated, note it — possibly tuning needed (see tuning.html). Otherwise file the BlackBox for archive.
  5. Note anything unusual in the cohort mission logbook: weather, alarms during flight, drone behavior, lessons learned. The 5-minute notes today are the prevented incidents next month.

This workflow doesn't require deep BlackBox expertise — that's for diagnosing specific issues. The skim-level review catches major problems and builds the operator's familiarity with their drone's normal flight signature.

When deeper log analysis is worth it

Post-flight log review at the skim level is cohort default after every mission. Deeper analysis (PIDtoolbox FFT comparisons, MAVLink replay, frame-by-frame OSD review) is only worth doing in specific situations:

  • An incident occurred: a crash, a near-crash, an unexplained mode change. Deep log review identifies the cause for prevention next time.
  • A mission produced unusable imagery: deep review identifies whether the cause was wind, vibration, GPS, or something else. Different fixes for different causes.
  • Tuning work is happening: BlackBox is the input to PID tuning (tuning.html Section 5).
  • Training a new operator: review their missions in detail to identify what they did well and what to work on.

Outside these cases, skim-level review is sufficient. Don't make every mission a research project; the routine missions are routine for a reason.

Section 05 For partner orgs and alumni in remote barangays

Mobile workflows.

Some missions happen at sites where bringing a laptop is impractical: small barangay paths, missions in flooded fields, multi-hour walks to remote AOIs. Phone- and tablet-based ground stations enable these missions, with trade-offs around screen size, telemetry options, and feature parity. This section covers when mobile makes sense and what works.

Three mobile workflows:

Approach Hardware Capabilities Trade-offs
SBL
SpeedyBee app + Bluetooth Phone connects to FC via Bluetooth. Configure missions, monitor pre-flight, receive in-bench telemetry.
Android phone (iOS supported but limited); SpeedyBee F405 V4 with Bluetooth (cohort default FC).
Free; full configuration and mission planning capability. In-flight telemetry only at very short range.
Cohort default for pre-flight checks. Can replace laptop for cohort default missions if site logistics demand it. Save mission file to phone, upload via Bluetooth.
QGC-M
QGroundControl mobile (iOS / Android) Tablet or phone runs QGC; connects to drone via USB OTG cable to a SIK telemetry radio, or via Wi-Fi adapter on the FC.
iPad / Android tablet; SIK 433/915 MHz radio + USB OTG cable.
Full ground-station capability on tablet. Mission planning, in-flight monitoring, log review. Tablet screen smaller than laptop but readable in field conditions.
Cohort recommendation for partner orgs running ArduPilot 10" builds in the field. Add ~₱8,000 for the tablet + telemetry radio above what a laptop-based setup costs.
DRONE-M
Drone-specific mobile apps Some commercial drone manufacturers ship phone apps (DJI Fly, Autel Explorer). For cohort builds, this category is largely empty.
Phone running a drone-specific app.
Slick UX where it exists; not relevant for cohort builds.
Mentioned for completeness. Cohort default builds use the open-source ground stations; commercial apps don't apply.

When mobile makes sense:

  • Site access constraints: small footpaths, flooded fields, or sites requiring multi-hour walks where a laptop bag is impractical. Phone in pocket, tablet in small bag.
  • Quick recurring missions: monthly cooperative surveys where the mission file is unchanged from last month. Phone-based upload via Bluetooth is faster than booting a laptop.
  • Partner orgs working in remote regions: tablets with cellular coverage may work where laptops with WiFi-only don't.

When laptop is still better:

  • First missions of a new build: laptop's bigger screen makes config issues easier to diagnose.
  • Deep configuration changes: CLI work, full mission planning for new AOIs, parameter tuning. Phone interfaces are too small for this.
  • Post-flight log review: BlackBox analysis needs a real screen and PIDtoolbox or similar desktop software.

Most cohort alumni use both: laptop in the truck for primary work, phone in pocket for quick checks and pre-flight verification. The phone's value is in being always-available, not in replacing the laptop.

Section 06 For partner orgs running multiple drones

Multi-drone coordination.

Operations with 5+ drones in the same fleet face coordination problems that single-drone operations don't. Mission scheduling, telemetry deconfliction, parallel mission tracking, fleet-wide configuration management. This section covers what changes at fleet scale and which tools handle it. Cohort default individual alumni can mostly skip this section.

The four problems that show up at fleet scale:

Problem What it looks like Solution approach Tooling
1
Mission scheduling Multiple drones flying different AOIs on the same day. Coordinating launch times, observer assignments, battery rotations.
Spreadsheet or shared calendar for the operations day. Each drone has a "flight number" with assigned operator, AOI, time window, batteries.
Shared spreadsheet (Google Sheets) works well at 5-10 drones. UgCS has built-in fleet scheduling at larger scales.
2
Radio frequency deconfliction Multiple drones in flight: their radio links can interfere. ELRS at 2.4 GHz on 5+ drones in close proximity can degrade.
Different ELRS UID per drone (already required for binding); spread missions across the day rather than parallel flights at the same site.
UgCS has a frequency planning feature; for cohort use, simple time-staggering works.
3
Parallel telemetry tracking Operations centre wants to see all flying drones simultaneously: mission progress, alerts, battery status across the fleet.
Multi-drone ground station with per-drone status panels. Mission Planner has limited multi-drone support; UgCS is purpose-built for this.
Realistic for partner orgs with 5+ drones; impractical at smaller scales (the operational complexity overhead exceeds the benefit).
4
Fleet-wide configuration management All drones running the same firmware, same config, same calibration. Drift between drones creates troubleshooting nightmares.
Cohort default config dump applied to every drone in the fleet (firmware.html Section 5 covered version logbooks and coordinated update windows).
Spreadsheet logbook + git-tracked config dump files. Lumipad shares cohort default configs; partner orgs version-control their own modifications.

The realistic minimum for a multi-drone operation:

  • One ground station laptop per drone, or one operator per drone with their own laptop. Don't try to run multiple drones from a single ground station unless the tooling explicitly supports it (UgCS does; Mission Planner doesn't cleanly).
  • One coordinator (could be a pilot) who tracks the day's schedule and handles contingencies.
  • Shared fleet logbook tracking each drone's status, recent maintenance, current firmware.
  • Pre-mission briefing covering each drone's assignment for the day.

What multi-drone operations don't need:

  • Multiple drones flying simultaneously over the same AOI. The collision risk and the radio interference exceed any time savings.
  • Sophisticated swarm coordination. Cohort default missions are mostly independent surveys of different AOIs; swarm-style cooperation isn't the model.
  • Custom multi-drone software development. UgCS handles the cases where this matters; below 5 drones, spreadsheets and Mission Planner work fine.

For partner orgs scaling from 1-2 drones to 5+ drones, the operational discipline matters more than the tooling. Document who's doing what, when, with which equipment. The tools support that discipline; they don't replace it.

Numbers worth knowing

Six numbers across the operator-side stack.

Reference values for ground-station setup, telemetry rates, and the cost-tier breakpoints between cohort default workflows and partner-org fleet operations.

~5 km
CRSF telemetry range
100mW ELRS LOS · same as control link
~15 km
SIK 500mW range
Dedicated MAVLink telemetry · ArduPilot only
4–8 Hz
CRSF telemetry rate
Cohort default · don't exceed 8 Hz
~₱2,500
SIK radio pair
Adds full Mission Planner workflow on ArduPilot
5+
Drones for fleet tooling
Below this, spreadsheets win over UgCS
~30 min
Cohort post-flight review
Skim-level; deeper analysis only when needed
Real ground-station scenarios

Four operator-side software cases.

Specific cases from cohort and partner-org operations where ground-station software choice or workflow had measurable impact. Each illustrates a decision point this page addresses.

"My laptop died mid-mission day. Can I finish with my phone?"

Cohort 02 alumna, distant cooperative survey

The laptop's battery failed during a 3-mission day. The fix: SpeedyBee app on her phone connected to the FC via Bluetooth. Pre-loaded mission files were already on the phone (cohort default workflow stores them on phone too as backup). Completed the remaining 2 missions phone-only. Lesson: redundant copies of mission files matter; phone-as-backup-ground-station works for cohort default builds doing pre-planned missions.

"Partner org needs real-time map view across 6 drones."

Partner org evaluation, late 2025

Partner org ran 6 ArduPilot 10" builds, wanted unified ops centre showing all 6 simultaneously. Decision: UgCS Enterprise tier (~$700/year). Mission Planner doesn't handle multi-drone view well; QGroundControl is single-drone. UgCS's fleet view paid for itself in the first quarter through prevented coordination errors and faster mission turnover. Lesson: at 5+ drone scale, fleet-tooling cost is justifiable; below that, spreadsheets work.

"Telemetry kept dropping during a 7" extended-range mission."

Cohort 03 alumnus, 22-ha cooperative survey

CRSF telemetry between drone and radio was solid; OSD displayed correctly throughout. The problem: the operator had also added a SIK telemetry pair (unnecessarily for a 7" cohort default build) which dropped frequently due to suboptimal antenna placement. The fix: removed the SIK setup; relied on CRSF + OSD as cohort default specifies. Mission completed cleanly. Lesson: don't add tooling complexity that doesn't serve the build. CRSF + OSD is the cohort default for a reason.

"Reviewed BlackBox of a near-crash; found the cause."

Cohort 02 alumnus, post-incident analysis

A near-crash during Stage 5 mission practice — drone briefly drifted off-course before alumnus took manual control. Visual inspection revealed nothing. BlackBox review in PIDtoolbox showed a 2-second GPS lock dropout coinciding with a low-altitude pass over a roof structure. The autonomous mission tried to compensate using stale GPS data; the drift was the result. Lesson: BlackBox analysis identifies causes that visual review misses. Worth the 30 minutes when something unexpected happens — even if no actual crash occurred.

Frequently asked

Questions worth answering carefully.

What's the minimum software setup for a cohort default mission? +

For 5"/7" cohort default INAV builds:

  • INAV Configurator on a laptop (Windows, Mac, or Linux).
  • Cohort default config dump applied to the FC.
  • Mission file generated from missions.html planning + INAV mission tab.
  • OSD configured with cohort default layout (battery, RSSI, mode, GPS, timer).

That's it. No SIK telemetry radios, no Mission Planner, no UgCS. CRSF telemetry on the FPV link covers in-flight monitoring. Pre-flight check via SpeedyBee Bluetooth app if convenient. Post-flight log review with INAV Configurator's BlackBox tab.

Resist the urge to add more tools. Each additional tool adds setup overhead, calibration effort, and failure modes. The minimum cohort default setup works for >90% of cohort missions.

Mission Planner vs INAV Configurator — which is better? +

The question is wrong; they're not interchangeable. Mission Planner is the ArduPilot ground station; INAV Configurator is the INAV ground station. Your FC firmware determines which one you use.

If you have an INAV build and want Mission Planner-style features (real-time map, fleet view, advanced log tools), the answer is either:

  • Switch to ArduPilot firmware and use Mission Planner (significant work; only worth it if you need ArduPilot-specific capabilities).
  • Use QGroundControl, which has limited INAV support and provides some Mission Planner-style features.
  • Accept that INAV Configurator is sufficient for cohort default missions and stop chasing features you don't actually need.

The third option is cohort default for 5"/7" builds. The capability gap with Mission Planner exists but doesn't affect the kind of missions cohort alumni typically fly.

Should I install all four ground stations to have options? +

No. Pick one and learn it well.

Multiple installed ground stations create confusion: which configuration is current? Which mission files are valid? Which set of saved configs is the cohort default? Drone software has enough configuration surface area without spreading it across multiple ground-station applications.

The cohort default is one ground station per build, kept current with the firmware version. Switch only if your needs genuinely change (e.g. moving from individual operations to partner-org fleet operations). When you switch, fully migrate; don't straddle two ground stations.

What if the ground-station software has a bug? +

Ground-station bugs do happen — they're free open-source projects with imperfect testing. Symptoms range from minor (UI glitches) to serious (mission upload fails silently, telemetry stops mid-flight).

Mitigations:

  • Stay on stable releases, not bleeding-edge. Same advice as firmware (firmware.html Section 2). The configurator version should match the firmware version.
  • Verify mission upload before flight: re-read the mission from the FC and verify it matches what you sent. Quick sanity check that catches most upload failures.
  • Don't update mid-mission day: if the ground station is working, leave it alone until the day is done. Bug-fixing happens in the workshop, not in the field.
  • Report bugs upstream: open-source projects fix what they hear about. A clear bug report (with logs) is the contribution that keeps the tooling improving.
What about ground-station offline mode for remote sites? +

Most ground stations work offline once installed; the cellular dependency is mostly for map tiles. Practical workflow:

  • Cache map tiles before traveling: in INAV Configurator and Mission Planner, load the AOI region while at home/office (with internet); the tiles are cached on the laptop. They'll work offline at the site.
  • Cache mission files locally: never plan a mission for the first time at a remote site. Plan at home, save the file, verify it; bring the saved file to the site.
  • Don't rely on cloud features: anything requiring real-time API access (UgCS's cloud sync, Mission Planner's online elevation queries) won't work at remote sites.

Cohort default workflow assumes intermittent or no connectivity at flying sites. The laptop is configured to work fully offline; the operator brings everything they need.

How important is it to record the OSD video during missions? +

Useful but not essential. Most cohort missions don't need OSD video review afterwards — the imagery itself is the deliverable, not the FPV recording.

OSD video is worth recording when:

  • Client deliverable expects video proof of the survey being conducted. Some cooperatives request this for their internal records.
  • Training or troubleshooting context: reviewing OSD video helps identify what the pilot saw during a problematic mission.
  • Promotional or educational use: alumni use clean OSD videos for portfolio work, social media, training material.

FPV goggles with built-in DVR (cohort default Skyzone, Eachine 008XE, etc.) record automatically with no extra effort. Worth enabling; review only when needed. Don't treat it as essential post-flight artifact for routine cohort missions.

What's the cohort recommendation on automated mission monitoring tools? +

Some commercial drone fleet management tools offer "automated monitoring" — alerting on battery thresholds, flight envelope deviations, GPS lock loss. The category is mostly aimed at enterprise drone operations.

For cohort default operations, automated monitoring is overkill. The pilot is the monitor; the OSD shows the relevant alerts; the failsafe (configured in fc-setup.html Section 7) handles automatic protective responses. Adding a software layer between the pilot and the drone introduces failure modes without proportional benefit.

Where automated monitoring helps:

  • Multi-drone partner-org operations where the operator can't attend all drones simultaneously.
  • Beyond-VLOS operations (which require CAAP authorization and aren't cohort default work).
  • Long-duration monitoring (hours of continuous flight; not cohort default mission length).

For cohort default missions: rely on the pilot, the OSD, and the failsafe. The cohort training discipline (in flight-training.html Section 5) covers the in-mission attention discipline that automated tools attempt to replace.

Are there any ground-station tools we should actively avoid? +

Yes, a few categories:

  • Race-focused tools (BetaFlight Configurator alternatives focused on freestyle/race) — wrong feature set for survey work; learning them is wasted effort.
  • Closed-source proprietary tools from drone manufacturers other than the big commercial ones. Many small companies ship Windows-only tools that haven't been updated since 2020. Don't depend on these.
  • Tools that only work with their own custom firmware — locks you into a vendor; you can't take your skill to a different drone. Cohort builds use open-source firmware specifically to avoid this.
  • Beta/development branches for routine cohort work. Same as firmware advice; production missions need stable tools.

The four ground stations covered in Section 1 are the realistic options for cohort default work. Anything outside that list is either niche, outdated, or wrong fit.