...

• Daniel Puratich did not attend the flight test in favor of EE session, but supporting debrief efforts.

...

Flightline Team

...

...

⏲️ Flight Test Timeline

...

Date/Time

...

Action

...

Notes

...

10:00

...

arrive bay

...

12:30

...

setup test and get ready to go

...

12:40 ~1:10

...

wait for the weather

...

1:10

...

first take off

...

1:20

...

second takeoff

...

1:30

...

Fixed the prop

...

1:40

...

return to service flight

💻 DEBRIEF

Flight test debrief report

Card 1 Test 1

...

Flight planning

Flight test card requirements/objectives Performance

...

Control performance & payload situation

...

Identified issue

 Updated during debrief with best guess of timings from the testing team.

A flight is denoted by a single time the drone remained in the air, each landing is a new flight.

New log is for every power cycle. We power cycled to restart the Pi.

...

💻 DEBRIEF

Debrief is done chronologically and aligns roughly with the above timeline table

Lead Up

• Gemini testing was deleted from this test the evening before after it failed ground validation.

Flight #1 Debrief

• Took off Altitude Hold

• Switch to Loiter

• Controls Check

• full stick deflection

• was at ~10m

• still in loiter

• pitch and roll input led to oscillations

  • these were not recoverable and led to a crash

• No damage to Houston observed after this crash

Flight #2

• Card 1 test 1 #2

  • redid calibration for accelerator and Magnetometer

    • these were done on the ground before the flight

  • Pilot Reports

    • Yuchen Lin the Loiter control reasonable

    • Manasva Katyal responsive and flew as expected

    • did not feel different at all after this accel and magnetometer re-calibration.

    • we have not run auto-tune or done any tuning on Houston so far.

• Decided the aircraft was ready to operate in auto mode.

Flight #3

Card 2 Test 1 #1 dry run

• No autonomy hardware mounted

• Flying in Auto mode

• straight line way point

  • pilot intervene due to uphill slope of terrain and worried about hitting the ground

  • the speed was too fast which was concerning

• switched to loiter to return

• uneventful landing

Flight #4

Card 2 Test 1 #2 Dry run

• No autonomy hardware mounted

• Fly in auto

• Straight line way point

  • WP_NAV_Speed reduced to 1m/s

  • altitude is ascending from 2 m to 3 m

• rtl at the end

• uneventful landing

Autonomy Hardware Install

• Mounting of LIDAR and RPi 5

  • smaller and longer Allen key would be useful

  • mounting hole for RPI need to be oversized (right now too tight)

  • need a better placement for RFD900 one screw is not reachable

  • no nylon nuts for the all 3 screws

• Ground test the system and verified it’s working

  • this is testing for the autonomy system only

Flight #5

Card 2 Test 1 Try 1

• Take off in auto and Dylan Finlay to act as the obstacles

  • Dylan Finlay at the left side of the drone ~5 meter

• No mode changed observed when the drone should’ve detected an obstacle

  • see card 2 test 1 expect mode change if detect obstacles

• when landing mode change occurred switching between the two mode(loiter → auto) land in loiter

  • during manual landing it was detecting ground as obstacle

  • RPi was commanding it into auto when trying to land the drone

  • Had to spam the loiter button to force into loiter for long enough to land then disarm

  • need to implement logging

  • Possible Solutions:

    • RPi could try reading the flight mode to know when it shouldn’t issue commands?

    • In Ardupilot we need to look into a way to block the telem port when pushing a button

    • We need a software disable mechanism for the autonomy system before we fly this again. Daniel Puratich hard requirement. A hardware disable mechanism can come down the line. This is extremely scary imo, we got lucky here.

    • Need to look into state variables to do that in Ardupilot

Flight #6

• ask Dylan Finlay to stand in front of the drone to see if the mode change got triggered

• Tried taking off in auto, but RPi was not allowing it and switching back into loiter

  • The take off mode can only be loiter (auto keep switching out into loiter)

  • there was grass off to the side so it was detecting that as an obstacles

• Pilot manually took off in loiter and switch to auto

• Dylan was standing in front of drone and it was not able to recognize him

  • not observing mode change at all throughout the flight test

• manually switched to loiter

• landed

• did not have to battle the RPi for flight mode for this landing.

• Hotspot phone over heat and need to wait before reconnect

  • this was being used to connect to the RPi

  • had a few phones that could hotspot the RPi

  • router is long term path for this just wasn’t setup

Ground Test

• after flight #6, ground testing ensued

• drone was in loiter and auto for this test, but was disarmed the entire time

• drone stayed in loiter and not switching to auto

  • decide not to flight test obstacle avoidance anymore today

• the mode change from auto to loiter triggered after picking up the tree when testing

• it did not switch back to auto when it was in a open field (and was expected to do so)

• Weather is extremely sunny we suspect interfered with Lidar performance

Camera Mounting

• Want to remake the camera mount for a simpler installation

• CV camera, RPI and Lidar are all mounted

• We did not remove Lidar because we did not have a working Allen key to remove the screws. It was possible to remove it using pliers.

  • Possible Solutions: get more tools!

Flight #7

Card 3 test 1 Try 1:

• Gelocation Testing flight #1

• Ground test the drone and verify the Geolocation value make sense

• Worked well at 1m height with drone being held

• ran script a second time and saved to log1.txt, will go into flight test folder

• take off in loiter, remained in loiter for the entire flight

• 0 degrees north, 9m away, no tape measure, just approximated with walking

• hovering over the pad for a few minutes

• flew around the pad for a while

  • was kind of pilot training session here

  • flight lasted a few minutes total

• landed in loiter.

• reviewed log files

• 10m north, 0m east was reported from geolocation

• confirmed with phone app this seemed correct orientation wise

• with phone app measuring got about 9m

Flight #8

• Gelocation Testing flight #2

• log2.txt

• same script

• took off in loiter

• flew toward landing pad

• hoverred for a few minutes

• then landed on the pad in loiter

Flight #9

• Gelocation Testing flight #3

• Wanted to takeoff in landing pad to set the drone’s home location to the landing pad

• logged the home location, stored latitude and longitude, stored in flight interface log on RPi

• took off in Loiter mode from the landing pad

• landing pad was flat

• Flight plan was to take off and then go a square path and hover over the pad

  • When given pitch command, and the drone roll for a full turn 360 degree

• Ascended to 5m in loiter, always in loiter for this

• Pitch was given and this resulted in a roll and crash

• It started pitching too far and control authority was lost so drone was disarmed

  • about a second

  • disarmed from ~5m

• GCS report EKF failure during this event, logs to confirm

• Drone was disarmed in the air

Damage Assessment

Crash #1

• resulted in no observed damage

Crash #2

• Lidar appears to have some damage

  • testing it off the drone

  • it functions software wise and rotates but it looks a bit beat up

• One prop broken

• GPS scratched, needs to be verify

• telem continued after crash

  • should be inspected

• RPi looks okay from cursory glance

• CV camera looks ok

• lost a nut on the landing gear after this crash

Extra Notes

• Hardy Yu observed vibration on Z axis was high for all flights

• Houston is not stock PIDs, it’s the tune from the old Houston, this is the newer Houston but same frame.

  • Unsure what the aggressiveness was set to from the past Houston tune

  • Daniel Puratich suspects the high aggressiveness on the tune of previous Houston results in an un-stable tune on this new Houston, especially when the new Houston is loaded with extra weight.

• EKF warning generally happens during crashes

• Vibration overall in the logs doesn’t appear to be that bad.

• Pixhawk is secured with tacky tape and a zip tie over the top

• This was the pixhawk that was in the pond, possibly its pixhawk?

Root Cause Analyses

Analyzing the log files to determine why this crash occurred and how we can not repeat these mistakes.

Link to logs is here in our Onedrive folder, if that doesn’t work, try here.

Steady crosswind for all tests, got stronger as test progressed. Wind coming from south east, going toward north west.

Crash #1

logs analyzed are from 129

...

...

The above capture confirms GPS was fine throughout this event. GPS.NSats=30 during this and GPS.Status =4 during this.

Image Added

Crash #2

logs analyzed are from 134

Image AddedImage Added

Image Added

Image Added

Image Added

Image Added

Ways to Improve