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

IR Camera Test (HOUSTON)

Procedure

Goals/Objectives

Knockoff criteria

1. Setup (prepare drone)

• A good outcome is if rc.local succesfully runs and images are auto captured and stored in a designated folder

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

2. Hover at 3-5.

• Best outcome: Image output is desirable (high quality and emitter light is clear visible with no discernible issues in image quality) and are successfully stored in a logging folder.

• Acceptable outcome: Images are successfully stored in a logging folder (we will see what why image quality is poor).

due to vibration on drone, images are very blurry.

Weather: cloudy

3. Hover at 10m

Same as above

4. Hover at 15m

Same as above

5. Hover at 20m

Same as above

Obstacle Detection/Guided Mode (HOUSTON)

Procedure

Goals / Objectives

Knockoff criteria

1. Setup drone:

2. a) Ensure the guided-mode script has been uploaded to the drone

3. b) Switch on drone

4. 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.

IMP: pls see photo before reading the description below!

• The mission is setup as follows. connection initialized, 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. Just before it reaches the third waypoint there is another auto-guided-auto switch, abrupt change in velocity component direction. Then we carry on naturally to 4th wp. halfway between, we auto-guided-auto (through ned_waypoint this time) to another intermediate wp (see photo), return to waypoint originally navigating too, and initiate landing procedure.

• 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 (when killing the script)

Image Added

Image Added

Image Added

Image Added

Image Added

Image Added