First Draft of Crew 3 Crew Resource Management

AT 409

Capstone Crew Resource Management (CRM)

Tristan Bungen, Aaron Varnau, Treston Russell

Roles and Responsibilities

● Aaron Varnau: Pilot in Command (PIC)

○ Preflight Checklist

○ UAS Controller

○ Flight Monitoring

○ Mission Leader

● Treston Russell: Pre-Flight Planner, Observer

○ Packing for the field

○ Charging Batteries

○ Preflight Checklist

○ Observing

○ Planning Drone Routes

○ Emergency Procedures

○ Dual fail safe redundancy checks

● Tristan Bungen: Data Processing

○ Transferring Data

○ Correcting Data

○ Processing Data

○ Data Placement / File Structure

○ Mapping / Project Lead

Checklists

M600 Checklist provided in Brightspace:

Bramor checklist provided in Brightspace:

Communication

Communication between the VO and pilot or PIC will be either in-person or through the Zello

communication app. The aircraft’s location will be described using its position on the predetermined

flight path and its position relative to landmarks or crew members if need be. Heading will be

communicated based on either a compass heading or relative to crew members if it would be more

clear. Altitude will be described relative to its ideal or preset altitude for small changes during flight, or

larger approximations possibly relative to the ground if significant deviations occur. The height of

surrounding landmarks may be used for more specific communication. Other midflight

communications will be delivered as needed, such as the position of potential threats to the aircraft

relative to the aircraft or crew, or deviations in heading.

The crew will keep communications specific and brief so that more can be said in less time.

This will be modeled after ATC communication in that all communications are straight to the point.

Checklist communications will be an example of this model as the crew will read specific lines and

verbally confirm/check/etc. with each other on that line’s status. As a safety process, challenging the

decisions of the PIC or other crew will be encouraged if someone believes a decision is risky or

incorrect. Collaboration and clarity will be key to the success of the team.

● Emergency procedures should also be provided:

○ What to do if GPS is lost?

○ Line of sight lost?

○ Loss of control.

○ Approach of manned aircraft.

○ Bird Strike

Emergency Procedures

Emergency procedures allow the flight crew to respond effectively to emergency situations.

Even though the airframes used in AT 409 have their own fail safes for the majority of in-flight failures,

procedures to mitigate human error are always a necessity. This CRM includes fail safes and

emergency procedures for the flight crew to determine the correct course of action. All of the following

emergency procedures must be followed by the PIC and VO(s) for the best chance to mitigate further

damage or injury.

A frequent problem missions face is loss of GPS signal . If the airframe is capable, the flight

crew will switch the control from autonomous to manual until the signal reconnects. If the airframe is

not within visual line of sight, then the flight crew will use the attached camera as a visual reference.

This emergency procedure is a last resort because some airframes do not allow much pilot

interaction, and allows more room for human error.

Visual line of sight and airframe situational awareness are important to mitigate emergency

situations. When line of sight of the UAV is lost, the first course of action for the flight crew is a

constant form of communication. Communication is key for respotting the airframe, and especially

without situational awareness. If none of the flight crew can spot the aircraft, then the mission should

be paused and returned to home. If the UAV is not capable of returning, and cannot be spotted, then

the aircraft must end the flight. This can be done by landing the aircraft or deploying a parachute.

Even with experienced pilots who are certified in operation of an airframe, it is possible to

lose control of the aircraft . If the PIC loses control of the aircraft, then the mission needs to be

paused and the aircraft should be grounded. The mission can be continued when the flight crew

decides the aircraft is capable for operation and the crew is ready.

Even though the flight area should be already designated as a UAS operation with elevation,

along with other metadata, if a manned aircraft enters the flight crew’s operation airspace the

airframe should be grounded and the operation should continue when the airspace clears. ATC

should be notified and reminded that there is a UAS operation in that airspace.

Bird strikes are a way to cause major damage to the aircraft during operation. If there is a

bird strike during operation, the flight crew must ground the aircraft as soon as possible to assess the

damages. A formal inspection of the aircraft’s fuselage, motor, wings and sensors should be

conducted. This inspection can be done on site or in the lab, it is recommended the crew return the

aircraft to the lab for a thorough inspection. If it is determined the airframe is still operational on site,

and an instructor is present and approves, the mission can resume. If an instructor is not present,

then the mission should be terminated and the airframe returned to the lab.

Week 4 Crew 3 Field Report

Mission

Week 4 consisted of our crew training with a Mavic 2 Pro and Loc8 software. The goal was to find a body located in a field at the Purdue Wildlife Area, one hidden by William Weldon, the other hidden by the flight crew. Unfortunately, due to a UAS mission by another Purdue class and activity in the field from local bird watchers, the mission was cut short and only two flights were conducted. After flying, the crew returned to NISW to put all the equipment on chargers and organize the cases, and learned how to use the computer lab for data transfer off of SD cards. 

Hardware

    A DJI Mavic 2 Pro was used to fly this mission with iPhones running Measure. A regular laptop ran Loc8. To capture the images, a Hasselblad L1D-20c was fixed to the Mavic. 

Software

    Loc8 was used to determine the average pixel value of the color of the body’s clothes. Then, the software runs through the images collected by the flight mission and finds groupings of that pixel value. More specific methods for this have been described in previous field reports, but it is important to note that it was used in the same way as previous missions. The crew did not reach the stage of actually using Loc8 to find the body as the second mission’s sensor data was unworthy of being used and the third flight had to be cancelled. 

    Measure GroundControl was used to create an autonomous flight plan for the UAS and alter the sensor settings for optimal use in the mission’s weather conditions and data needs. An iPhone was attached to the transmitter, allowing for manual control of takeoff and landing. 

Human Factor

    Our crew resource management document was used in this mission for almost everything we did. Before we took any hardware out of their cases, we assigned roles for the crew. The pilot in command chose who would prepare the UAS for flight, who would set up the transmitter and Measure app, who would act as pilot, who moved the data from the UAS to the laptop with Loc8, and more. As we enjoyed the roles we took during our first mission with the M600 during week 3, we mostly reprised them. This led to a faster turnaround time on flights and data transfer.

    We continued to learn how best to communicate with each other verbally. We are beginning to work better as a crew as we see more and more of each others’ behaviors and preferences. After leaving the flight area, we worked together to charge all the batteries at NISW and learn how to upload data to the UAS computer lab drives. 

    Our crew learned the value of adjusting sensor data as the data collected from the second flight was too poor to be used in a professional setting. While it could be used for our training flights, we decided to adjust it heavily for the other flights we would conduct that day. This was when the other Purdue group began flying and the bird watcher arrived, and we were forced to ground our mission. 

Metadata

General

------------------

Location: Purdue Wildlife Area

Date: 9/15

Vehicle: Mavic 2 Pro

Sensor: Hasselblad L1D-20c

Battery: 5 & 11

Approval # N/A

Flight Information

-------------------

Flight Number: 2

Takeoff Time: 10:58

Landing Time: 11:04

Altitude (m): 61

Sensor Angle: Nadir

Overlap: N/A

Sidelap: N/A

f-stop: 3.5

Exposure: 1/240

ISO Speed: ISO-100

Focal Length: 10mm

Max Aperture: 2.971

Weather

------------------

Temp: 63 F

Humidity: 72%

Clouds: Thin overcast

Wind: 5mph variable 

Crew

------------------

PIC: Aaron Varnau

VO: Treston Russell

Submitter: Tristan Bungen

9/14/20

Treston Russell

AT 409

Week 3 Individual Field Report

Week 3 of the UAS capstone lab revolved around helping a Forestry PhD student, Aisha, with her research. The question Aisha wanted to answer was “does a difference in elevation affect the quality of the collected data”. To answer this question, the different flight groups had to fly operations at different elevations. My flight crew was assigned to survey at 400ft elevation. For preparation of the operation, we walked the perimeter and placed Ground Control Points (GCPs). I placed 10 Propeller Aeropoint GCPs around the perimeter, along with one in the center for reference. The GCPs require at least 45 minutes of “GPS soaking” before finishing the operation. A requirement of these GCPs is that they must be collected off the ground in reverse order. 

This week was not focused on processing the data collected, rather than just collecting the data itself. There was emphasis on the preflight procedures to become more familiar with each step and ask questions where there were gaps of clarity. The M600 was used in this operation, along with its preflight checklist. Once the preflight procedure was completed, and the correct metadata was programed in the Measure app, the M600 took off on its autonomous flight. After the operation finished, and the M600 landed, a post flight procedure commenced. This procedure was to heighten our attention to detail when handling the aircraft. 

Not all the flight groups got to fly this week due to time, and this tight time frame didn’t let us process the data collected. So, the next week will be focused on processing this data for a piece of the answer to Aisha’s research. When all of the flight groups finish their data collection operations, a final determination of the best quality DSM from each elevation will be made. The best DSM will more than likely be made a standard elevation in future Purdue UAS operations. 

9/7/2020

Treston Russell

AT 409

Week 2 Individual Field Report

Week 2 into the UAS capstone lab was centered around a search and rescue operation along with an introduction to Martell forest property. I was placed in the recovery team 2, which had the task to search an area with a possible match of the missing person. We unfortunately were not deployed during this operation due to loss of time. This mission was conducted with the Bramor UAV, equipped with a Sony RX1 sensor, at 11:04 a.m. on September first. The Bramor flew a predesignated flight plan over Martell forest for optimal space coverage of 100m with 80/80 overlap. The Bramor finished the mission and landed at 11:49 a.m. via deployed parachute. Once the Bramor was brought back to the ground station area, the SSD card was removed and handed over to the intel branch for review. The lengthy review process was as far as the mission got, due to time. 

During this time another mission was flown with the M600 hexacopter. The M600 was equipped with two sensors, a Zenmuse XT2 10mm thermal and RGB lens and a Sony Alpha 6000 mapping sensor. For proper mapping and data collection with this airframe a Geosnap PPK receiver is mounted to the top. The mission for this airframe was to autonomously map a section of the Martell forest property with a predetermined flight. Takeoff time for this mission was 12:15 p.m. on September first. The mission took 313 images at 500ft agl over the flight area. At 12:37 the mission came to a conclusion with a manual landing. For optimal mapping outcomes, the collected data had to be taken back to the lab and processed. 

AT 409 Week 1 Field Notes

 

An introduction to the UAS capstone lab was conducted demonstrating the goals of the course, along with introducing some of the airframes used. Within this introduction it was stressed that checklists are fundamental to a successful UAS operation. No matter the numerous times an operator has performed a checklist, or the level of their comfortability, a professional always completes a thorough pre-flight checklist. A constant form of communication between the flight crew during preflight, takeoff, inflight and landing mitigates risk of problems during each stage. Constant communication also presents an impression of professionalism and gives the customer a sense that the flight crew has optimal experience in the field. The goals of this course are to get us comfortable with getting in the mindset of professionalism and efficiency with time and resources. To demonstrate the level of professionalism and efficiency required for the course, an introduction to two of the airframes used was conducted. First the Bramor, a fixed wing UAS equipped with an 35mm lens RX1 camera at 42 megapixels, preflight checklist was ran through with excellent communication and flow. This checklist included small things that many people who think they’ve done this enough to know what they’re doing, or in a rush, miss. From the time the Bramor is taken out of its case and assembled, to the pull of the catapult release, there was constant communication about what needed to be checked and the status of the item being checked. While the UAV was in autonomous flight, the RPIC was constantly aware of its position with the controller in their hands. The RPIC could start and stop the mission at any time, along with the capability of deploying the parachute for emergencies. The second airframe was a quadcopter equipped with two sets of sensors: Z30 camera and an XT2 thermal RGB. This allows the operator to fly to the correct position with their transmitter, and an observer to operate another transmitter for the sensors to capture optimal data. A lesson learned from this lab was that the flight crew needs to know the operation terrain well, because when the Bramor came down to land it almost hit metal poles sticking out of the ground. The final demonstration was showing the com box used for the operation. This com box is capable if EMPing all electronics within range if not handled properly. Underlining the idea of always be aware of your tools and surroundings. 

AT 409: Field Report Week 5

AT 409: Field Report Week 5

Aaron Varnau, Treston Russell, Tristan Bungen

Class Lab Report:

The lab for this week was conducted at Martell forest. The mission was to survey the

northeastern plot of the property, and become certified on operating the M600 alone for future

operations outside of class time. Flight crew roles were assigned as follows: Aaron as PIC,

Tristan as SO, and Treston as VO. The mission was conducted smoothly, with the help of the

checklists and the crew’s flow of communication. This communication was put on display by the

PIC’s callouts of clearing props for take off, the switch from manual control to autonomous flight,

elevation, and battery percentage. This communication helped the flight crew operate safely

when manned aircraft hugged the border of the research area. Two aircraft were spotted and

watched to be sure the mission was not going to become an unsafe operation. Once the

mission finished, the aircraft was manually landed by the PIC and packed up following the pack

up procedures. After the flight our SO, Tristan, went back to the lab and processed the data

collected. On Friday, we took the M600 out alone for an additional flight.

Hardware:

M600, PPK, Flight Pad, Sony A6000, Zenmuse XT2, Ipad

Software:

Measure App

Human Factor:

Our crew was cleared to fly on Tuesday while being observed by Dr. Hupy and Zach. We were

familiar with our checklists and ran through with only a couple questions for our observers to

make sure we were doing okay. Our flight was successful and we demonstrated good crew

resource management skills and knowledge.

MetaData

General:

Location: Martell Forest, Northeast Plot

Date: 9/25/20

UAS: M600

Sensor: Zenmuse XT2, PPK

Camera: Sony A6000

Batteries: Yellow

Flight Information:

Flight Attempt Takeoff Time: 10:46 a.m.

Flight Attempt Landing Time: 11:07 a.m.

Max Altitude: 508 ft

Flight Altitude: 500 ft

Return to Home: 262 ft

Max Distance: Disabled

Loss of RC: RTH

Shutter Speed: 1/4000

Aperture: F3.5

Iso Setting: Auto

Dial Setting: Shutter Priority

Lens Setting: Infinity Focus, F-3.5

Weather:

Temp: 66 degrees

Humidity: 62%

Precipitation: 10% chance

Wind: 5mph

Clear Skies, Great Visibility, Cirrus

Crew:

PIC: Aaron Varnau

VO: Treston Russell

Submitter: Tristan Bungen

Aircraft Sightings

● East of mission area on 4th leg

● East of mission area on 12th leg

Weekly Crew Flight Report:

This mission was completed on September 25th. The flight crew met up in the lab in NISW

around 3 P.M. We went through the necessary checklists to set up the M600 for our mission at

Martell Forest. When we attempted to fit the entire M600 with its hard case we were unable to fit

it into any of our vehicles. Kaleb cleared us to take what we needed from the M600 case and set

the drone in the back seat of Aaron's car. With Aaron as PIC, Tristan as Sensor Operator, and

Treston as Visual Observer we went through all 3 checklists given to us for the M600. We safely

put the drone together and set up the flight on Measure. As we started our flight we ran into

some issues. As we started the autonomous flight plan, measure crashed and the drone stood

still in its flight path. We were able to take control of the M600 manually and land the UAS. We

investigated and found out that the Measure app started updating itself during the flight because

we were connected to Treston’s hotspot. It was an unavoidable accident that we handled very

well. After we landed the aircraft, we changed the M600’s batteries from yellow to pink and

switched the PPK battery as well. We then proceeded to go through the checklist once more

before flight. We completed the Northeast plot with no problems. We then packed up the UAS

using the post flight checklist and made sure everything was properly in its place. We then

drove back to NISW and charged batteries and returned all supplies. Since our mission took so

long at Martell I had to leave for my job and was unable to pull the data from the SD cards and

into the data dump. I asked Zach if he would do it for me and he agreed so it was resolved. That

concludes the report for our flight of the Northeast plot at Martell Forest.

Hardware:

M600, Extra Battery Case, PPK, Flight Pad, Sony A6000, Zenmuse XT2, Cellphone

Software :

Measure App, Phone Wifi Hotspot

Human Factor:

Our crew’s communication and teamwork skills were tested and proven on Friday when we

experienced an unexpected problem with Measure. About halfway through the flight, the M600

stopped flying its grid path and simply hovered in place. Measure had to some extent crashed

and decided to run through the preflight checklist without also cancelling the current flight.

Obviously, the preflight checklist failed as the aircraft was several hundred feet in the air on the

other side of the plot from its home location. It didn’t return home because Measure hadn’t

aborted the previous plan and somehow that plan was still running in the background. Our crew

decided to manually return and land the aircraft but experienced a massive problem: the landing

gear would not come down. The batteries were running low (~35%) and we did not know how to

solve this issue. We tried a few basic things such as pressing the physical home button on the

transmitter but none worked, so we called our classmate Kaleb Gould who successfully

coached us through the issue. We switched the flight mode on the transmitter and reset

Measure. This actually led to an accidental solution and clue as to what crashed Measure; the

app needed to update and already started to install the new version during use. The app quickly

updated and we went back in and opened the flight plan. This caused the landing gear to go

down and we were able to manually land the aircraft.

This was a very stressful situation for our crew, and was certainly a bonding experience. Our

visual observer constantly updated the crew on the status of erratic flight and the sensor

observer searched for Measure solutions online and called Kaleb as the pilot maintained the

aircraft’s flight. All three of us played important roles and did so without projecting our stress and

frustration onto our crewmembers. To add a cherry on top, a manned aircraft flew directly over

the plot five minutes after we landed and was so low it looked to be below 500 feet. We have no

doubts that it could have crashed into the M600 without manual takeover.

MetaData

General:

Location: Martell Forest, Northeast Plot

Date: 9/25/20

UAS: M600

Sensor: Zenmuse XT2, PPK

Camera: Sony A6000

Batteries: Yellow, Pink

Flight Information:

Flight Attempt 1 Takeoff Time: 4:43 pm

Flight Attempt 1 Landing Time: 4:55 pm

Flight Attempt 2 Takeoff Time: 5:14 pm

Flight Attempt 2 Landing Time: 5:34 pm

Max Altitude: 508 ft

Flight Altitude: 500 ft

Return to Home: 262 ft

Max Distance: Disabled

Loss of RC: RTH

Shutter Speed: 1/4000

Aperture: F3.5

Iso Setting: Auto

Dial Setting: Shutter Priority

Lens Setting: Infinity Focus, F-3.5

Weather:

Temp: 82 degrees

Humidity: 38%

Precipitation: 0%

Wind: 4 mph

Clear Skies, Great Visibility, Few Clouds

Crew:

PIC: Aaron Varnau

VO: Treston Russell

Submitter: Tristan Bungen

Aircraft Sightings:

● Small aircraft south, 1st leg

● Small aircraft south, 3rd leg

● Aircraft east, 4th leg

● Aircraft south, 7th leg

● Aircraft south, 9th leg

Lab 10: Measure Ground Control for UAS Operations

Introduction-

This week's lab was focused on flight preparation and readiness. Planning a flight is not done at the site, but in the office. The mobile app Measure Ground Control (MGC), and the website of the same name, were used in this lab to utilize all aspects of mission planning in one program. This will keep the planner's desktop neat and organized, ultimately preventing lost data or confusion. Inefficiencies with data collection or data storage has been such a problem in the UAS industry that many companies specialize in Single Source of Technology Solutions (SSoT). Measure Ground Control is one of these SSoT companies that are capable of checking the air space for no fly zones or advisories, and creating a flight mission for the site without being there. Having these capabilities is very useful for the UAS world because it keeps all preflight information in one area, outside of your field notes. When the mission planning is complete, the app is then used to connect and monitor the UAS during operation. It allows the pilot to observe the flight in FPV, along with flight metadata. This is the most efficient way of tracking data throughout the preflight, inflight and post flight operations.

Overview-

Before creating a flight plan on the app a mission has to be created and shared onto your profile, and is available for preflight planning. Figures 1 and 2 represent the basic setup of creating a flight mission. This details the mission name, date, type, location, pilot and airframe.

Figure 1: First half mission setup

Figure 2: Second half of mission setup

After the mission is created the planning process continues on the website. The first thing to check is the airspace in which you plan on operating. If you are within restricted airspace or any other airspace a part 107 operator can not fly in, then you need to seek permission for flight. Figure 3 represents the Airmap provided by the MGC app, the website does not look much different. Figure 4 and 5 represent the grounds when checking Airmap at Purdue campus and the Purdue Wild Life Area. The Purdue campus area shows a no fly zone due to the class D airport nearby, whereas the Purdue Wild Life Area is outside the class D airspace.

Figure 3: MGC Airmap

Figure 4: Purdue campus Airmap

Figure 5: Purdue Wild Life Area Airmap

Once the Airmap is consulted, and permission is given if needed, the flight planning begins remotely. The site is observed from the MGC Airmap for the best flight path, as shown in figures 6 and 7. The flight path is then created in flight planning, shown in figures 8 and 9. Once the flight path has been chosen, the mission can be shared onto your profile for the flight team to conduct the flight. When the flight team arrives on site, they can refer to the MGC for any updates on advisories in your area. After checking the advisories, weather and preflight checks, the operator is then able to make adjustments to the flight path if needed. Changes like adjusting the physical path the drone will be following, changing heights, speeds and time of flight could be done within the app due to the topography or other objects in the way that were not observed in the planning portion. These possible changes are demonstrated in figure 10. This is a major help to the efficiency of UAS operation due to being able to change features on the fly in one application, rather than having to set up a major ground station or aborting the mission to return to the office to make the changes. The pilot can then start the mission, after making appropriate changes, and monitor in FPV all of the data being collected. Once the mission is completed the data is then uploaded to the website in the operators mission profile.

Figure 6: MGC Airmap site exploded view

Figure 7: MGC Airmap site close view

Figure 8: MGC flight planning

Figure 9: MGC final flight planning

Figure 10: MGC app finalized mission adjustments

Conclusion-

In conclusion mission planning is one of the most important processes in executing a UAS flight mission. Having one place to keep all information created or collected betters the overall efficiency of the UAS data collection operation industry. This is why it is important to utilize SSoT applications to keep everything organized and easily accessible for the operators, planner and modelers.  Not only is having the data collection and planning all in one place very important for efficiency, but incorporating the mission execution portion of the operation in the same application increases that efficiency.