AT409 Week 6 Report

 

Introduction:

This week we conducted another series of flights for William Weldon at the Purdue Wildlife Area (PWA). Like in pervious flights of this type, the objective was to use traditional (visual) and digital search methods in combination with a UAS platform to perform a simulated search and rescue operation. 5 flights were planned for that day but, only 3 were flown due to the laptop battery being depleted.

Metadata:

Date	9/29/20
Location	Purdue wildlife area
Vehicle	DJI Mavic 2
Sensor	1” CMOS
Dataset	1
Takeoff time
Landing time
Altitude	119m
Sensor angle	NADIR
Overlap	80%
Sidelap	80%

 

Overview:

The setup of the scenario was a search and rescue operation modeled in a condensed multi-crew manner. There was a flight team, search coordinator, search ream, and recovery team. Normally these groups would be physically separated with the search coordinator running the show and coordinating between various search elements and first responders. Being as this was only a simulated event, there are no first responders and there is no physical separation of the groups; however, we still acted in accordance with how it would be done were it real. I was assigned to the visual search team, for which my duty was to use photo imagery collected by the flight crew and visual scan the images looking for the simulated missing person, in this case represented by a red shirt and jeans placed at a random location within the search area.

During the first flight the digital search team found and identified he missing person several minutes before I was able to with the visual method. After that the recovery team would be directed to the missing person via instructions given by the search team, the person would be recovered and then the test was restarted. In the subsequent test I was able to visual identify the missing person at nearly the same time as the digital team; and during the final test I was able to find the missing person in less than 1 min of receiving the image data and beginning the search. While I do not have access to data to confirm this, I would suspect this was due to the fact that as we flew subsequent flights I began to get familiar with the area, and began to develop a sense of what I should and should not expect to see in the images and was able to quickly notice when something was there when in previous flights it had not been.

AT409 Week 5 Report

 John Cox 

Kaleb Gould 

Jeff Hines

Introduction 

Throughout the week of September 21st to September 27th , group 1 conducted two M600 flights, a Bramor flight, and aided in Weldon’s search and rescue research. We have become quite efficient in M600 flights, to the point where the roles are interchangeable between members and data can be collected in a speedy, efficient manner. There are areas for improvement though both in terms of the number of flights we can conduct, using the Bramor in more flights, and following standard operating procedures. Moving forward, we have put together a set schedule for weekly flights so that future flights do not need to be put together last minute. 

Tuesday Flight - M600 

On Tuesday September 22nd, Group 1 get together to gather data for Martell’s northwest plot. Before flying, our group met at the dispatch building to gather flight equipment and define roles for the flight. Kaleb was to act as PIC, Jeff acted as the SO, and John took on the responsibilities of FO. Once properly equipped for the day and with expectations set, the team headed for Martell. 

Upon arrival, the team dynamic shifted from jovial to task oriented, ensuring our movements were efficient and documented. At this point, each team member was in a role that they had previously worked, so the tasks and expectations were familiar. The team ran into one issue during the pre-flight inspection with the Sony A600 camera, that being one of the security screws has come undone and had fallen out. The inconsistency was found when formatting the camera since the entire camera had rotated about ten degrees from its intended position making it hard for the SO to view the digital display. We immediately brought the issue up to our superior who was out in the field with us. Though hesitant, we assured him that if we fly no damage would come to the aircraft, but for redundancy sake we taped the camera to the mount. The rest of the preflight inspections and checklist items were completed with no issues and at a quicker pace than any previous flights. 

With preparations complete, John and Jeff shifted location to better act as visual observers and Kaleb began the mission at 09:56. The aircraft experienced no disruptions of any kind throughout the flight, though the team remained on high alert and were ready to announce any unusual behavior or surrounding traffic. At the mission’s end, Kaleb lowered the aircraft to the ground announcing the altitude in increments of 100 feet until touchdown. The aircraft touched down at 10:14 totaling a flight time of 18 minutes. We were asked by another team to not fully tear down the aircraft as they would be using the same platform for a nearby plot, so we ended the PPK session to differentiate between the flights and removed the batteries. 

After all flights for the day concluded, the team returned to home base and divided post mission tasks amongst members present. John charged any batteries used while Jeff learned how to properly store and post-process data using EZSurv. 

Friday Flight - M600 

On Friday September 25th , group 1 met to collect data of the northwestern plot using the M600 and the Sony A6000 sensor. Once again, the roles were picked as follows: Kaleb Gould – PIC, Jeff Hines – SO, John Cox – FO. The team feels they excel best when the roles are distributed like this, however if the need arises all members feel confident enough with the M600 platform to take on the responsibilities of any role. The team met at 8:30 to prepare the platform and flight equipment then left for Martell forest at 9:00 once everything was stowed and loaded. 

The entire mission took a little more than an hour, starting with preflight operations. We have shifted from a primarily “read and do” method of completing preflight checklist items to a “do and read” style which significantly reduces the time between arrival and platform launch while maintaining the same level of standard. We encountered no problems throughout the preflight stage and transitioned into beginning data collection. We originally ran into a brief problem upon takeoff where the mission failed to upload to the aircraft. The M600 was hovering 10 feet off the ground as the PIC attempted to quickly troubleshoot the problem. Eventually the PIC decided to land the aircraft temporarily since a quick fix could not be found. The problem was resolved quickly after landing by checking free fly mode. Once properly downloaded, the mission began at 09:52 and ended at 10:10, an 18-minute flight just like Tuesday. 

The mission commenced and ended with no abnormalities. Once everyone returned to home base, Kaleb and John began to prep for future flights by charging batteries that were used and returning equipment to its designated spaces. Jeff took the data from the sensors and PPK, transferred the data into the collective data dump, and processed the data using EZSurv. Once finished with the data, Jeff returned the SD cards to their proper housings and the team disbanded for the day. 

Saturday Search and Rescue Missions - Mavic 2 Pro 

On Saturday September 26th , the entirety of group 1 met to aid in Weldon’s search and rescue research project. The full team consisted of Weldon, Kaleb, John, Jeff, Logan, and two students from AT 209. Kaleb and John were PIC and VO respectively while Jeff and Logan acted as data analysts, with Jeff specializing in Loc8 and Logan using a manual search method. The two AT 209 students acted as a recovery team. 

Sunday Flight - Bramor 

On Sunday September 27th, group 1 attempted to conduct a Bramor flight of northern Martell but ran into a series of issues. Zach Miller acted as the PIC, while Kaleb and John acted as an SO and FO, respectively. Jeff had an earlier engagement that interfered with the flight on Sunday, so he could not attend the flight that day. The flight ran into a series of issues including a late parachute deployment which lead to a botched landing and a sensor issue that prevented us from gathering flight data. The post flight inspection of the Bramor showed no structural damage with the only damage noted was a small puncture in the parachute. Since the data was lost, we supplied the metadata for the flight below as it will likely not be recorded elsewhere. 

Metadata: General 

Date 9/27/2020 Location Martell North Vehicle Bramor ppX Sensor Multispec Dataset 1 Battery 3&4 

Metadata: Flight

Takeoff time 2:00 pm Landing time 2:39 pm Flight time 39 min Altitude (m) 152 Sensor angle NADIR Overlap 80% Sidelap 80% 

Metadata: Crew 

PIC Zach Miller SO Kaleb Gould FO John Cox

AT409 Week 4 Report

Week 4 Field Report 

John Cox, Kaleb Gould, Jeff Hines 

9/21/2020 

Week 4 Field Report 

This week we split into two groups. One group went to Martell with Dr. Hupy and Zach, while the other was at PWA with Kaleb and William. At PWA our group performed a series of weighted flights with the DJI Phantom 4 Pro. These flights were to test; first the lifting capabilities of the aircraft, second to test flight stability, and lastly to check the top speed of the aircraft at 250ft AGL. 

The first test was unweighted to set a base line for the flight. The aircrafts take off characteristics were noted as level and stable. Once in flight at 25ft, the full stick deflection was preformed to test flight stability. The aircraft showed stable and steep bank deflection compared to the M600, M210, and Mavic Pro 2. Despite the deeper deflection angle, it was able to keep its position in space position. Finally, a 1-mile speed test was flown. The top speed was 43.8 mph for one mile. These characteristics were noted as the standards for this aircraft and are what we would use to compare the other flights.

 Next a 3D printed camera mount was fixed to between the legs. Two half pound ingots were fastened to the mount and performance was noted. The takeoff had a slight fall backwards, but the vehicle was able to take off. It easily claimed to 25ft and the full stick deflection began. The aircraft slipped very lightly in place but was able to keep stable. Then the vehicle was climbed to 250ft and was flown to top speed. A flight speed of 42 mph was achieved. This flight performance suggests that an externally mounted one-pound payload could easily been flown. 

The last flight turned into two parts. Originally it was supposed to be flown with a three-pound payload. During take off the controller gave a max RPM warning on the motors. The vehicle achieved a max height of 1 foot then immediately began sinking back to the ground. So the test was changed to a two pound load. The aircraft had a higher than normal take off RPM but no warning was given. After staying at 2 ft AGL for one minute, the aircraft was flown into position for the stability test. With full stick deflection, there was lots of slipping and instability with rapid direction changes. At 25ft the aircraft was left to maintain its location but after a minute the vehicle began to sink and gave no indication on the controller or otherwise. With additional input it would regain stability. The speed test was done and a top speed was held at 40 mph with no altitude loss. 

During to post flight debrief, it was noted the 3lb pay load was excessive and beyond the aircrafts limits. Instead the team speculated that the max external payload was likely 2.5lbs. No data exists for the Phantom 4 Pro max take off limit so this was all experimental. The flights were successful, and the data needed was obtained. The next step is to load the aircraft for drop tests. This is to test the dispersion radius of one or more of the payloads.

AT409 Week 3 Report

 

Figure 1:DJI M600 Being Prepared for Flight

 

Introduction:

This week our flights continued at the Martell forest area. Our flight crew was assigned to fly the first of 4 missions over a specific plot of trees for one of the PHD students in the Purdue forestry department. This week I was assigned the role of pilot in command (PIC) and given responsibility of the first flight which allowed me to have a more hands on experience with crew resource management (CRM), checklists and flying the mission than I’ve had previously: all of which I will go into more detail with below.  Additionally, this was our flight crews’ first experience handling and recording information from ground control points (GCPs). And our mission this week involved general handling and placement of the GCPs, their operational use, as well as a small experiment that was more for our benefit of learning what not to do rather than gathering useful data. 

 

Overview:

Figure 2:AeroPoint Ground Control Point Unit

Mission Prep and GCPs

Once we arrived at the mission area and had our usual brief on the mission and crew assignments, we began to set up our GCPs. For this mission we used 10 AeroPoint GCP platforms as seen in figure 2 above. We then set about placing ad turning on our GCPs. We placed most of our GCPs around the perimeter of the mission area and a few in the forest itself under the canopy. Its important to note at this point the importance of GPS “soak” time. Without being too technical, “soak” time refers to the amount of time the GCP needs to acquire the appropriate amount of satellites and calibrate its position after it is turned on and before the flight takes place. What this means for us as a flight crew is that we had to mark the time that we activated our first GCP, and make sure that our flight didn’t commence until our GCPs had “soaked” for a minimum of 45mins as per the recommendation by AeroPoint. 

I’ve talked at length about GCPs in previous writings before, but for a refresher; a GCP is basically a GPS transceiver that uses satellites to acquire precise data on its location on the Earth’s surface. It then interfaces with our drones to provide accurate, real-time positional data which allows the drone and the sensors on it to create the precise image data with correct positioning for our GIS work. With this in mind we come to a unique problem we had for this mission; GCPs need an un interrupted line of sight (LOS) to the satellites they are connecting to in order to generate accurate positional data (as pointed out in figure 3 below). And, seeing as our mission was taking place over a plantation of densely planted trees, we were going to have problems finding suitable locations to place our GCPs. This is where we had a bit of an experiment for our learning benefit as we deliberately place some of our GCPs under the forest canopy where it was very unlikely to get accurate data from the satellites. This had the affect of when we went to post process the image data, we could only find one of the four GCPS we had planed under the forest canopy which rendered some the images we collected unusable.

Figure 3:AeroPoint GCP Instructions

As GCPs are an essential part of creating using GIS datasets and many things go into their placement and usage. For example, our GCPs needed to have good coverage over the area we are surveying. This means they need to be fairly evenly spaced out over the width, length, and breath of the area. If the GCPs are too clustered in one area our eventual data when we generate a combined image or 3D map will look like its being stretched or warped to the area with the high concentration of GCPs. 

Flight Ops.

With our GCPs set up and soaked we were ready to begin flight preparations. As PIC for the first flight I was responsible for leading my flight crew through the preflight checklist, I talked at length about checklists in last weeks report so I’ll be brief with this; once we established out flight line we began to assemble the aircraft, I was responsible for checking my fight crew as they did this though there were many nuances that my TA Zach had to coach me through. Which is a good time to iterate that the checklist is not meant to be a finely detailed document, but rather a quick reference for a user already familiar with the system and checklists are NOT an alternative for proper training on a system. There are many things that contribute to smooth and efficient preparation of the aircraft and sensors for flight that are not on the checklist, such as how to arrange the boxes when you have retrieved their contents or where to store the lenses covers for the sensors to where you don’t lose them or walk off at the end of the mission with them still in your pocket and this mission as PIC was a good experience for that.

Once the aircraft was assembled I began to plan the flight with the Pix4D system, normally the PIC would either do this prior to arriving on site or concurrently with the aircraft assembly and preflight checklist but being as this was my first experience operating the DJI M600 platform this was essentially a training flight for me and my TA wanted me to focus on each step individually. The Pix4D system is very intuitive and it took very little time for me to upload the flight plan to the aircraft. And once the checklist was completed, we began our first flight. Our group originally planned to fly 5 flights that day from 500-100ft AGL, but time constraints meant that our last 2 flights had to be postponed. The metadata for the 3 flights we completed are recorded below.

Metadata:

*Sensor angle, overlap, sidelap, and dataset are shared across all flights. And GCP start time was the same for all flights

General:

Location	Martell Forest
Date	9/8/2020
Vehicle	DJI M600
Sensor	Sony A6000
GCP	AeroPoint
Number of GCPs	10

 

Flight 1:

Takeoff Time	11:16 AM
Landing Time	11:23 AM
Altitude (ft)	500
Sensor Angle	NADIR
Overlap	80%
Sidelap	80%
Dataset	1
Airtime	7 min
GCP start time	9:47 am
Crew
PIC	John Cox
FO	Jeff Hines
SO	Logan Jones
VO	Zach Miller

 

Flight 2:

Takeoff Time	12:08 AM
Landing Time	12:15 AM
Altitude (ft)	400
Crew
PIC	Aaron Barnau
FO	Tresten Russell
SO	Tristen Bungen
VO	Zach Miller

 

Flight 3:

Takeoff Time	12:37 Am
Landing Time	12:45 AM
Altitude (ft)	300
Crew
PIC	Logan Jones
FO	Connor Cromwell
SO	Joe Hammel
VO	Zach Miller

 

Data Processing:

After our flight was completed my flight crew was instructed to go back to our computer lab and unpack our equipment and learn how we will be post processing our data this semester. Once Zach arrived with the equipment, we started recharging the batteries as they could charge while we did other things, then Zach showed us how to download the data from the GCPs using our phone. After that we recovered the sim cards from the aircraft sensors and began to upload the data to our University research drive, we were also instructed in the correct was to catalog data in the research drive as well as how to format the data and the cards for the next flight. Our data consisted of both RGB and thermal image data, which had to be separated, as well as separated by flight in order for the data to be compared later on. While this all may sound trivial, this is essential for efficient and organized operation, all of our data goes into an initial data collection folder in the research drive, while all work is done in a separate processing folder, and deliverables and completed projects are stored in an analysis folder. This is done so that anyone in our group can easily find the data we’re looking for as we may have multiple different flight crews over many days or weeks gathering data for a project before it is processed into a final product and its important that any of our members be able to quickly find and access the data they require.

Summary:

GCPs are a vital part of UAS/GIS operations and the operational use of them is not a procedure to be taken lightly. There are unique challenges that arise when using GCPs or UAS operations and care must be taken in GCP placement and handling.

Preflight checklists are not training manuals, or material used for learning how to operate a system, a UAS operator should know the ins and outs of their system before any operation.

AT409 Week 2 Report

 

Figure 1: Bramor Flight Preparation

Introduction:

In this week’s lab we flew two flights over the Martell forest area, one with the Bramor and one with the M600. Our objectives with the Bramor flight were to begin mapping the Martell forest area with the RGB sensor on the Bramor and a separate mission with the M600 was designed to test on of our PHD students’ systems for S&R operations. With this as a backdrop our class was divided into our flight crews and given various tasks to assist with during the operations. This included recovery teams, data handling teams, and two flight teams (one for each aircraft). Tangentially to this we were to observe and note the metadata for the two flights and the various processes used by the flight crews for crew resource management (CRM).

Overview:

After we were briefed on pour flights and roles by the professor, we traveled to the mission area near the northern edge of the Martell forest area. Initially I was supposed to be part of the recovery team for the first mission, but my roll was changed to fill the role of an absent student. I was now to be the Sensor Operator (SO) of the Bramor flight. The process of setting up the area for the mission was a good practice for how we use CRM to safely and efficiently run our missions. Starting with unpacking the drone we use the crates that the Bramor is transported in to demarcate our flight line. Once the crates are open and the drone is on the catapult, no non-essential personnel, even those in the flight crew are to enter the flight line in order to minimize risk of injury or damage and to ensure the PIC and FO have ample space to work and no distractions.

Once the Flight line was established our flight crew began assembly of the drone and catapult, we used a call and response system (or “say and do”) of communication to go down our preflight checklist. This was accomplished by our PIC and FO. With the checklist completed the mission began. The Bramor flight went smoothly and the recovery was accomplished without issue. The only hiccup in the operation was that the computer we brought out to the field for data processing couldn’t really handle the volume of data we had collected during the flight. The metadata for this first flight is recorded below.

Flight 1 Metadata:

Location: Martell Forest

Date: 9/1/2020           

Vehicle: C-Astral Bramor PPX

Sensor: Sony X1

Battery: 3 and 4

Approval Number: 1

Takeoff Time: 11:04 AM

Landing Time: 11:49 AM

Altitude (m): 152

Sensor Angle: NADIR

Overlap: 80%

Sidelap: 80%

Airframe Time: 46 mins

Photos Taken: 1131

Distance Traveled: 47.5 km

Datalog: 1

Crew:

PIC: Kaleb Gould

FO: Jeff Hines

SO: John Cox

VO: Zack Miller

Our second flight of the day was with the DJI M600. This flight was to find a simulated missing person in the forest. However, this flight had to be aborted soon after launch due to worsening weather conditions. The metadata for this flight is recorded below:

Flight 2 Metadata:

Location: Martell Forest

Date: 9/1/2020

Vehicle: DJI M600

Sensor: Sony A6000

Battery: Yellow

Approval Number: 1

Takeoff Time: 12:15 pm

Landing Time: 12:37 pm

Overlap: 80%

Sidelap: 80%

Conclusions:

CRM plays a huge role in how we conduct operations. There are four main concepts that we integrate into our CRM which are: 1_Clearly defined and assigned roles for crew members and a summary of duties for each role. 2_Integration of established checklists. 3_Commmunications strategies. And 4_Emergency Procedures. I briefly mentioned these in my previous post but now I have examples of each of these core concepts from this week’s mission to share. Starting with clearly defined assigned roles and duties. All members of our flight crew were assigned our roles prior to the meeting and reviewed the assigned duties of our respective roles. For myself, I was assigned the role of sensor operator and my duties primarily focused on the collection and storage of the data to be gathered during the flight. In this particular instance once the storage disk was formatted and installed in the aircraft there was little for me to do during the actual flight as the Bramor automated the actual senor operations during the flight. However, once the flight had concluded I was responsible for handing off the data to the processing team.

Checklists have always been a cornerstone in aviation operations and UAS is the same. In this instance our PIC and FO had to follow a preflight checklist, this you can see in the figure below:

Figure 2: Bramor Preflight Checklist

I want to point out that the way this checklist is laid out facilitates another core concept of our CRM which is the effective communication strategy. Our checklist uses the call and response or “say and do” method whereby the PIC reads off the points on the checklist in order and the FO preforms the action and responds with the appropriate response in the right-hand column. These two concepts are essential to quick and effective communication and are one of the things that elevates our operation. The last core concept is emergency procedures which, fortunately, I do not have an example to share with you. But this is a preestablish set of actions that account for the most likely emergency scenarios. For our setting we define these as: Loss of GPS signal, Loss of visual contact with the aircraft, loss of control, approach by a manned aircraft, and bird strikes. Each of these has its own set of responses that I will cover in more detail at a later date. 

 

AT409 Week 1 Report

 

Figure 1: C-Astral Bramor PPX; Picture curtesy of DroneProvide.com

Introduction:

This blog will document my experiences and work during my Unmanned Aerial Systems (UAS) capstone at Purdue university. I plan on merging this blog with my previous blogs on the rest of my aviation courses here at Purdue.

Our first meeting for this capstone course set out a general overview for the course, including a syllabus, course goals, and flight demos; which I will outline below. Before I move on however, I want to establish that, at the time of writing this, the COVID-19 virus is still very active in the United States and while Purdue University and our class specifically are taking great measures to prevent the spread of the virus there is a distinct possibility that further outbreaks beyond our control may cause our course of action for this class to change dramatically or be postponed altogether.

Overview:

Once we assembled at our work area within the Purdue wildlife area, class started in the way that most classes do with an overview of the course syllabus, now I could pad this out by summarizing the content of all 11 pages of the syllabus but that would be boring, stupid, and take forever. So instead the highlights of the course include: due to the virus situation we don’t really have a lecture component to this class. Instead, we will be working in flight crews of 3 in order to complete various applied UAS data collection projects; using a variety of UAS platforms and sensors (Such as the C-Astral Bramor pictured above). Most of these projects will involve the use of UAS platforms and Geospatial Information Systems (GIS) to affect Search and Rescue (SAR) operations and forestry surveying.

After the syllabus was covered, we moved on to demoing the platforms we would be using this semester. We began by watching our TA’s go through the process of setting up and launching the Bramor. The Barmor is a fixed-wing, sled-launched UAV. I’m sure I will cover the details of the actual setup and operation of the Bramor in a future post, but the focus of the demo was to observe and note the practices that we will be enforcing during the semester. This included noting the importance of checklists, crew-management, effective communication, safety precautions, and environmental factors. All of which I will cover in greater detail at a later date; yes, I know I’ve been saying that a lot in this report, it was the first day be patient.

The next demo was a bit more hands on as we familiarized ourselves with the operation of our quadcopter platform, who’s name escapes me at the moment but I will edit in at a later date… As a quadcopter all of our members are familiar with the flight handling characteristics of this sort of platform so the purpose of this demo was to take advantage of the platform’s sensor package and multicrew capability to familiarize ourselves with operating the visual and thermal imaging cameras and operating as a multicrew team. In my demo one of my TA’s piloted the drone while I used the thermal and high magnification cameras the drone was equipped with to locate and identify another TA that was wondering around the wildlife area. That pretty much wrapped up our first day.

Conclusions:

This semester is going to present us with a host of unique challenges as we try to adapt to the changing situation with the COVID-19 pandemic. However, the applied research that we will be doing in this lab will establish a basis of professionalism and best practices that will be invaluable not only as we individually move on into the workforce but also be crucially influential in the future as UAS becomes more and more common and organizations try to integrate and expand UAS into the airspace and workforce.

Lab 9 Using the ESRI Arc Collector

OK so normally this is where I'd do the blog thing but due to the Arc collector app crashing my phone whenever I tried to access it and most of the places I would go to get the photos for this lab being closed or otherwise inaccessible due to the rona anyway and the fact that I'm up against my deadline here I've got nothin. Sorry.

So instead here's a picture of my sister's ferret. I call her Noodle, she likes biting the butts of stuffed animals, hiding in my sister's sock drawer, stealing the tv remote form 3 rooms away, knocking over every trashcan in the house, sleeping, baths, and toes.

Figure 1: Sleepy Ferret in Flat Form