Page Comparison

Procedure

Goals/Objectives

Knockoff criteria

1. Setup drone: (can be done at or before going to testing location?)

   1. Switch on drone, ensure the GOOD cv camera is connected

   2. (at time of writing, it is unclear if rc.local autostarting will work). SSH into pi, start airside

   3. Read live log output, compare flight controller log home location coordinates to phone’s gps

   4. Point drone’s cv camera at landing pad (keep a couple meters distance), check if geolocation is logging and data merge logs timestamps of detections and odometry

• A good outcome is if:

  • flight controller log has correct home location and altitude (compare with a phone’s GPS)

  • drone is able to detect landing pad and geolocation logs the coordinates (also ensure timestamps are logged in data merge logs)

< list of reasons why you would want to stop the test >

• Geolocation Logs are not working

• If data merge or flight controller logs not working, leave decision up to the tester present?

2. Either

   1. Switch on drone at takeoff location (Start airside system when drone at takeoff location)

   2. Get coordinates of drones takeoff locationStart airside system when drone at takeof

3. Get distance from home location to landing pad (measure it)

   1. OR takeoff on landing pad

• Good outcome: Flight controller log has the home coordinates

• Able to manually measure relative distance from takeoff location to landing pad

4. Flying back and forth over the landing pad at different heights (3-5m, 10m, 15m, 20m)

   1. Each time a height changes, airside system should be restarted (each test should be an independent flight)

• Good outcome: images show bounding boxes over landing pads, geolocation logs are outputting detection coordinates

Obstacle Detection/Guided Mode (HOUSTON)

Procedure

Goals / Objectives

Knockoff criteria

1. Setup drone:
   a) Ensure the guided-mode script has been uploaded to the drone
   b) Switch on drone
   c) Run the script (starts the mission, where drone navigates to waypoints in a square, switches from AUTO → GUIDED → AUTO, completes mission and returns to landing)

• Good outcome if drone completes the auto-guided-auto mode switches seamlessly, drone continues its auto mission after diversion, and returns to land.

• The mission is setup as follows. connection initialised, armed, takes off 10m altitude, flies 10m NW to the first vertex of the square, flies 10m E to the second vertex. When the drone is about to arrive at second vertex, it switches from AUTO to GUIDED to simulate a diversion and navigates to a waypoint 7.5 NE of current pos. After reaching this intermediate wp, drone switches to AUTO, continues to 3rd waypoint 10m S, 4th waypoint 10m W, signifying the completion of the auto-mission. The drone then returns to landing position and lands gracefully.

< list of reasons why you would want to stop the test >

Pilot intervention is not necessary unless safety issues arise, or there are environmental disruptions, as the auto → guided → auto switch is handled by the script.

if at any point the pilot needs to take control: 1) kill the script, this forcefully changes drone mode to loiter (tested on MP), and then aborts the current mission. 2) Pilot has manual control over the drone

NOTE: on mp, simulating a mission-abort, ie. killing the script changes mode to loiter almost instantly, but drone altitude plummets to zero. (discussed with Andrew and it should just be a MissionPlanner default issue). However, just in case, pilot should be ready to control vertical throttle when aborting mission (by killing the script)