# Flight Test

At this point, you should have successfully completed the hardware and software integration of the Cyclops system, as well as a bench test. Theseus recommends running several test flights prior to full operational deployment of Cyclops.

<table><thead><tr><th width="162.84375">Test Flight #</th><th>Configuration</th><th>Purpose</th></tr></thead><tbody><tr><td>Flight 1 &#x26; 2</td><td>GPS is available and primary position source. Cyclops will run in the background.</td><td>Observe background position updates on Vozilla app. Collect Cyclops recording and ArduPilot logs. Analyze and confirm nominal performance of the system.</td></tr><tr><td>Flight 3 &#x26; 4</td><td>GPS is disabled by pilot. UAV flies using EKF dead reckoning with position updates from Cyclops.</td><td>Confirm nominal performance of the system through multiple live flights. position updates on Vozilla app. Analyze Cyclops recordings and ArduPilot logs.</td></tr></tbody></table>

{% hint style="info" %}
Remember: Cyclops position updates **will not be sent** when GPS is enabled as a position source, but they will always be recorded in the background.
{% endhint %}

## Flight 1 & 2 - Ride along

The goal of the first two flights is to validate your UAV setup with Cyclops estimating positions in the background (i.e. not running in the loop). This way you can fly without the risk of sending bad inputs to the flight controller in the event that something is not working as expected.

Here are some errors to look out for on the first flight:

* Camera calibration issues
* Hardware power and overheating issues
* Flight controller configuration

It is preferable to test in an environment where GPS is available. This enables us to collect ground truth position data and evaluate Cyclops' performance against GPS.

### GPS-Denied Environment

A working VTX, pilot capable of manually flying the aircraft, and a redundant source of position (e.g., CRPA GPS antennas) are all useful to avoid issues in case GPS is compromised during test flights. Making sure that you have a stable way to navigate while setting up Cyclops is essential.

{% hint style="warning" %}
If you are **testing in GPS-denied environments,** make sure you have several redundancies before running test flights. You should not rely on Cyclops for positioning on your first test flight.
{% endhint %}

{% hint style="warning" %}
If you are disabling GPS on ArduPilot, make sure you setup the [Cyclops safety switch](/cyclops/autopilot-integration/optional-improvements/cyclops-safety-switch.md) script and **disable Cyclops inputs for the first test flight**. Otherwise, your flight controller may use Cyclops' position estimates when GPS is disabled.
{% endhint %}

### Success Criteria

* [ ] Cyclops position updates appear on [Vozilla under the MAVLink tab](/gcs-software/vozilla-gcs/mavlink.md)
* [ ] Cyclops position estimates correspond to UAV trajectory

### Mission Plan

The goal of this first mission is to feed Cyclops all the necessary inputs to its normal operation and validate that we get a nominal predicted trajectory. Here's what to include in this first mission plan:

* [ ] 3-5 km in total distance
* [ ] Fly above 100 m AGL
* [ ] Include terrain features (e.g., roads, tree lines, houses)

{% hint style="info" %}
If you are flying in a GPS-denied environment, it is recommended to keep a line of sight to the UAV at all times to avoid fly-aways and facilitate recovery.
{% endhint %}

<figure><img src="/files/sEmHUP3OPktDwHwo6lgw" alt="Example mission plan for initial test flight"><figcaption><p>Example mission plan for initial Cyclops test flights</p></figcaption></figure>

### Before the flight

Refer to the [pre-flight checklist](/cyclops/validation/pre-flight-checklist.md).

### During the flight

* [ ] You should see the position appear in real time under the [MAVLink tab on Vozilla](/gcs-software/vozilla-gcs/mavlink.md)

### After the flight

* [ ] Connect your device to your laptop running Vozilla to synchronize logs
* [ ] Review the performance under the [Vozilla Flights page](/gcs-software/vozilla-gcs/flights.md)

Run this first mission on one flight, if possible repeat with a second flight. The Cyclops position track should match the trajectory of the UAV (and GPS track, if available).

{% hint style="success" %}
Once you've successfully run two ride-along flights, you are good to go in the loop and rely on Cyclops your next test flight.
{% endhint %}

## Flight 3 & 4 - In the loop

The goal of these flights is to **progressively start relying on Cyclops for navigation**. Cyclops works by correcting drift while the aircraft is dead reckoning. For these flights, you should take off and switch GPS off to let Cyclops send position inputs to the autopilot.

It is helpful to use the provided [dead reckoning switch](/cyclops/autopilot-integration/optional-improvements/dead-reckoning-switch.md) and [Cyclops safety switch](/cyclops/autopilot-integration/optional-improvements/cyclops-safety-switch.md) Lua scripts to facilitate transitions between GPS and Cyclops.

### Success Criteria

* [ ] Cyclops position updates appear on Vozilla and match mission plan
* [ ] UAV navigates with Cyclops in the loop without GPS input

### Mission Plan

We recommend you repeat the [same mission plan](#mission-plan) from the ride along flights to minimize variables while bringing Cyclops in the loop.

### Before the flight

Refer to the [pre-flight checklist](/cyclops/validation/pre-flight-checklist.md).

### During the flight

Typical operation for the first flight with Cyclops in the loop:

* Take off (with or without GPS, depending on environment and CONOP)
* Fly without Cyclops until mission altitude is reached
* After first waypoint, transition to Cyclops (enable Cyclops, switch GPS off)
* During the test, monitor Cyclops and GPS tracks on Vozilla.

Your aircraft should now be dead reckoning and receiving occasional position updates from Cyclops. You **should not be seeing any increase in EKF variance** compared to normal dead reckoning operations. Cyclops position updates should appear as "jumps" on the aircraft position on Mission Planner/QGC.

### After the flight

* [ ] Connect your device to your laptop running Vozilla to synchronize logs
* [ ] Review the performance under the [Vozilla Flights page](/gcs-software/vozilla-gcs/flights.md)

{% hint style="info" %}
If anything seems off (UAV behaving erratically, inaccurate Cyclops position), default to safety and fallback to another method of navigation (e.g., GPS, manual).
{% endhint %}

## Further Test Flights

It is helpful to extend the total distance and mission envelope flown to validate the performance of the system on your UAV. If you validated stages 1 and 2 of flight testing, you should expect normal operation at this stage.

Below is an example of a longer mission plan (17 km) which covers feature-sparse terrain and a maximum distance-to-home of 6 km.

<figure><img src="/files/cdLEhHOeHLVXNLBGughV" alt=""><figcaption></figcaption></figure>

## Best Practices

### Mission Planning

We recommend creating a few small, autonomous mission plans to test Cyclops' performance on your UAV. There are a few procedures that will help you make the best mission plans for these initial tests as well as in full deployment:

1\) **Fly over features**: Cyclops is more likely to get a map match when it is flying over distinct terrain such as roads, tree lines, or neighborhoods. Avoid planning long durations over "textureless" terrains like fields, sand, and especially bodies of water.

2\) **Avoid dramatic banks**: large bank angles can reduce the amount of visible terrain directly below your UAV. This will limit Cyclops' ability to estimate its position in this area. Large banks pose more of a risk if you are flying at high altitude or your camera is mounted off the roll axis of your UAV (i.e. on the wing or a protruding mount).

3\) **Prioritize reaching >100m**: Time spent flying below this altitude will lead to uncorrected position drift. We recommend that operators prioritize reaching at least 100m before flying toward distant waypoints so Cyclops can begin correcting this drift.

4\) **Keep the mission plan inside the map boundary**: Cyclops cannot localize&#x20;

### Reducing Risks

Testing any system on a UAV has some level of risk. There are many ways to mitigate these risks when testing with Cyclops:

1\) **Test using a validated platform**: Fly Cyclops on a UAV that has already flown successfully

2\) **Avoid using expensive/critical components**: If you plan on using a more expensive camera for missions, we recommend using a cheaper camera for testing if available

3\) **Understand testing conditions**: Be aware of the conditions in your test flight area such as GPS jamming, bad weather (clouds, rain, wind), air raid alerts, etc.

{% hint style="info" %}
Dense clouds can obstruct Cyclops' view. Be sure to note the altitude of any cloud cover and plan your missions below it.
{% endhint %}

### Identifying Potential Issues

It is important to be able to quickly identify any problems that may occur in the air and have a plan to recover the UAV safely.&#x20;


---

# Agent Instructions: 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:

```
GET https://docs.theseus.us/cyclops/validation/flight-test.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
