...
🥅 Testplan
Expand | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||
|
Expand | |||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||
|
Expand | |||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||
|
Expand | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||
|
Necessary Preparation
Explain what capacity you need, what needs to be mounted, etc.
...
Name | Phone # | Sub-team | Role |
---|---|---|---|
8076320853 | Mech | ||
6474256385 | |||
2896985018 | |||
6473836886 | Auto | ||
5195898378 | Auto | ||
6473319757 | Auto | ||
Daniel Puratich did not attend the flight test in favor of EE session, but supporting debrief efforts.
...
Flightline Team
Name | Phone # | Role | Reason |
---|---|---|---|
|
|
| |
...
Expand | ||
---|---|---|
| ||
Hardware (wiring)
Hardware (airframe)
Hardware (groundstation)
Flightline Kit
|
...
Expand | ||
---|---|---|
| ||
Total 5 main system checked:
|
⏲️ 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
...
bgColor | #E3FCEF |
---|
Control performance & payload situation
...
Identified issue
Warning |
---|
Issue need to be RCA |
...
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.
Time | Event |
---|---|
11:00 | departure |
11:00 - 11:30 | go back and get the controller box |
11:30 |
|
11:45 |
|
11:50 |
|
11:55 |
|
12:00 |
|
12:00 - 12:15 |
|
12:15 | card 2 test 1 try 1
|
12:20 | card 2 test 1 try 2
|
12:50~1:37 |
|
1:37 ~1:50 |
|
1:50 - 2:00 | setup and card 3 test 1
|
2:00 -2:05 | setup and card 3 test 1 try 2
|
2:00 -2:05 | card 3 test 1 take off at landing pad
|
...
💻 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.
Crash #2
logs analyzed are from 134