> For the complete documentation index, see [llms.txt](https://gryfn.gitbook.io/gryfn-operations/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gryfn.gitbook.io/gryfn-operations/operations/flight-planning.md).

# Flight Planning

## Basic Requirements

1. Ensure the aircraft is physically and legally capable of what it is being asked to do.
2. Ensure the flight plan will not put the aircraft in hazard's way.
3. Satisfy necessary characteristics for optimal collection of each sensor modality, fully covering the area of interest.

Nuance of step 3: Operators must understand the requirements of the collect, and how to maximize data quality from each sensor, particularly with hyperspectral line-scan cameras.

Reference our [Flight Planning Calculator](/gryfn-operations/operations/flight-planning/flight-planning-calculator.md) with appropriate selections of sensors, lenses, frame periods, etc. Adjust flight altitude, speed, and spacing until ground sampling distance, overlap, sidelap, and frame periods meet the requirements for optimal data processing quality and your research.

## Flight Time

Most aircraft manufacturers provide a graph displaying flight time with various payload weights to give operators a sense of expected flight times. But manufacturers do everything they can to increase this number as a competitive selling point. Many caveats must be taken into account for real world applications. Flight time estimates are:

* Often derived at sea level altitude, improving rotor and propeller efficiency with higher air density.
* Using the most power efficient stable forward flight speed possible.
* Often taking batteries from full charge to dead, ignoring typical safety limitations.
  * Some manufacturers transparently provide curves estimating flight time to dead, to critical battery voltage, and to safe landing voltage.
* Extrapolated from a small sample of payload weights.
* On calm days with optimal air temperature and humidity.
* Using brand new batteries with no health loss.

Flight planning software also provides rough mission duration estimates, sometimes over or underestimating true times. All of this to say, when planning flights, conservatively plan flight times to ensure safe returns home. We recommend keeping track of flight time estimates, true flight times, and landing voltages as you get comfortable with an aircraft and payload combination. Over time as you gain experience with a setup, you will learn the practical flight duration and can slowly push the limits within your own comfort level.

## Flight Planning

Pictured below is a study area we want to collect data over. The agricultural field in the center of the image is the area of interest. In this example, the autonomous data collection mission will be performed at 60m AGL, 5m/s flight speed. This mission will capture LiDAR, RGB, and VNIR data.

<figure><img src="/files/K38KQtSJkDKGlaNKhgDV" alt=""><figcaption><p>Study Location</p></figcaption></figure>

Area of interest (AOI) is highlighted in red in the figure below. This is the absolute minimum required area that must be covered by the collected data to identify a flight as successful.

<figure><img src="/files/8IiStVprSYJoo9IspbkH" alt=""><figcaption><p>Area of Interest</p></figcaption></figure>

When approaching turns, the aircraft slows down and banks to make its turn. As it completes the turn, it will quickly accelerate, often exceeding the planned flight speed then backing off speed slowly. To guarantee high quality collection of the AOI, we prefer to make these deceleration, turn, and acceleration phases well outside the AOI.

{% hint style="success" %}
A great rule of thumb is that the survey boundary should be wider than the area of interest, in the flight line direction, by \~2m per m/s of flight speed.
{% endhint %}

We must also make sure our sensor field of view fully covers the area of interest. We typically recommend increasing the survey boundary, perpendicular to the flight line direction, by several meters as well.

<figure><img src="/files/VKE4wScl0bdjmTtLitt4" alt=""><figcaption><p>Survey Boundary (green) and Area of Interest (red)</p></figcaption></figure>

### Hyperspectral Collection

For most hyperspectral sensors that capture data based on a GPS polygon, called the Capture Polygon, this boundary can usually be created using corner coordinates of the survey boundary, ensuring the flight lines are not too close to the perpendicular edge of the capture polygon.

{% hint style="warning" %}
If flight lines are too close to the perpendicular edge of the capture polygon, edit the capture polygon to increase distance from flight lines in that direction. At least 5m of buffer.
{% endhint %}

With hyperspectral line-scan sensors, we like to give additional time beyond the AOI for speed and heading to fully resolve after turns to the nominally planned rates. In this case, we can increase our recommendation from 2m per m/s flight speed to 4m+ per m/s flight speed.

{% hint style="success" %}
Many flight planning software have built in features that automatically extend flight lines past the survey boundary. QGroundControl calls it "Turnaround Distance," UgCS calls it "Overshoot," DJI Pilot 2 has a similar setting called "Margin" that increases flight coverage in all four directions.
{% endhint %}

<figure><img src="/files/x8snELvNWLh4i0Js0Avh" alt=""><figcaption><p>Flight lines overlayed on top of survey boundary and area of interest (GRYFN)</p></figcaption></figure>

In the example flight at 5m/s, the survey boundary is set 10m beyond the edge of the AOI. Turnaround Distance/Overshoot is set to 10m, allowing flight lines to extend beyond the survey boundary.

#### Continued Hyperspectral Collection Details

* From the takeoff location, the UAV/sensor should not enter the polygon as it navigates to the first survey waypoint.
  * For sensors with vertical components of the polygon, set the minimum altitude of the polygon such that any alignment and navigation to the first waypoint can be done below the polygon
  * For sensors without vertical polygon limits, ensure the aircraft can easily navigate to the first waypoint without laterally entering the polygon.
* Reflectance panels should be placed in the capture area.
  * Preferably in the first or last flight line to find them easier in post-processing software.

<figure><img src="/files/wUyPMRWLkcxX66f5JANT" alt=""><figcaption><p>Area of Interest, Survey Boundary/GPS Polygon, Flight Lines (GRYFN)</p></figcaption></figure>

* When reflectance panels cannot be placed in the survey area due to restrictions or lack of access, users may build conjoining segments to an additional polygon area, and add waypoints the the flight plan that traverses over the panels.

<figure><img src="/files/XLeXQwjTsJZDApjCTc8g" alt=""><figcaption><p>Multiple polygons for data capture (GRYFN)</p></figcaption></figure>

## Additional Notes

#### Terrain Following

When relief in a scene is noticeable, greater than a few meters, we highly recommend using terrain following in your flight plan. This is especially important to hyperspectral line-scanners as the spatial sampling rate is determined by distance to ground (or more accurately, to scene). If terrain elevation increases but aircraft elevation is constant, line-scanners may end up missing measurements on the ground.

#### Distance to Scene

Keep in mind that when calculating resolution, overlap, sidelap, and other collection characteristics, the important metric is distance to scene, not distance to ground. When surveying tall objects, such as in forestry, canopy tops would lose a considerable amount of overlap by using calculations to the ground. Factor in the height of objects in the scene when calculating sensor parameters and in flight planning.

Ex: Surveying 10m tall trees in an arboretum. If I set my flight plan to 60m AGL, I would need to set the altitude in the flight calculator to 50m to accurately calculate sensor behavior above the scene.

### Terminology

**Flight Time** Total time UAV is capable of flight, manufacturer calculations typically performed at MSL in a hover.

**Mission Time** Total time UAV is capable of carrying out an autonomous flight plan. This number is less than flight time due to accounting for takeoff/landing time, GNSS alignment procedure time, and time to travel to the start point of an autonomous mission.

**Area of Interest** The area intended for data collection, minimum area required for capture/analysis

**Survey Boundary** Area extended beyond AoI to ensure full data product coverage from post-processing

**Turnaround Distance/Overshoot/Margin** Parameter in many flight planning software that extends flight lines beyond the survey boundary. If this parameter does not exist in your flight planning software, simply extend the survey boundary further.

**Capture Polygon** GPS coordinates used in a polygon file (KML/txt) to trigger Headwall hyperspectral data collection

**Hyperspectral Flight Lines** GPS flight line coordinates used in KML file to trigger Specim hyperspectral data collection


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://gryfn.gitbook.io/gryfn-operations/operations/flight-planning.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
