In-flight positional and energy use data set of a DJI Matrice 100 quadcopter for small package delivery

We autonomously directed a small quadcopter package delivery Uncrewed Aerial Vehicle (UAV) or “drone” to take off, fly a specified route, and land for a total of 209 flights while varying a set of operational parameters. The vehicle was equipped with onboard sensors, including GPS, IMU, voltage and current sensors, and an ultrasonic anemometer, to collect high-resolution data on the inertial states, wind speed, and power consumption. Operational parameters, such as commanded ground speed, payload, and cruise altitude, were varied for each flight. This large data set has a total flight time of 10 hours and 45 minutes and was collected from April to October of 2019 covering a total distance of approximately 65 kilometers. The data collected were validated by comparing flights with similar operational parameters. We believe these data will be of great interest to the research and industrial communities, who can use the data to improve UAV designs, safety, and energy efficiency, as well as advance the physical understanding of in-flight operations for package delivery drones.


Background & Summary
The last decade has seen considerable development towards using Uncrewed Aerial Vehicles (UAVs) or "drones" 1 to improve the efficiency, speed, and access of last-mile package delivery. Apart from the ability to carry packages, the majority of these UAVs also have the capability to takeoff and land vertically to reduce their operational footprint and increase their delivery precision. A common solution is to use a multirotor system that generates lift by pushing the air down by using a set of brushless direct current (BLDC) motors that spin counter-rotating propellers. UAVs that produce lift purely using rotors either during the entirety of the mission or for a part of it, need considerably large amounts of energy to lift a package when compared to a conventional winged aircraft where lift is produced by air flowing over a fixed wing. This larger energy requirement has a considerable impact on the range and endurance of these multi-rotor UAVs. The energy required is a function of the environmental factors like the prevailing wind conditions, temperature, humidity, etc; UAV design parameters such as the powerplant specifications, and the shape and build of the UAV; and mission-specific parameters such as the nominal ground speed, operation altitude, and delivery package specifications. Developing energy models that can accurately predict the energy use of these UAVs using these factors as inputs is critical in improving UAV safety and efficiency 2,3 . Current research uses theoretical models and physical parameters to estimate energy consumption [3][4][5][6][7] , while other methods use data-driven approaches to regressed parameters and estimate models [8][9][10] .
However, a recent survey 2 on the state-of-the-art of energy modelling for multirotor UAVs compared various models and found that the even with the common sets of parameters, the energy consumption rate (J/m) varies by a factor of 3 to 5 across the models. The survey advocates for comparing results to empirical data from comprehensive drone delivery field tests to improve the energy prediction accuracy. Most studies only conduct a few flight and the raw flight data is not released in public domain to aid comparisons. Given the strict regulatory requirements and significant effort required to conduct UAV field tests, no standard comprehensive data set exists in the public domain to the best of authors' knowledge.
In this work, we performed experiments in order to empirically measure the energy use of a Multirotor UAV with autonomous capabilities while carrying a range of payloads through various campaigns. We autonomously direct a DJI ® Matrice 100 (M100) 11 drone to take off, carry a range of payload weights through a triangular flight pattern, and land. We collected high-resolution data on the inertial speeds, altitude, wind and energy for each flight. Between flights, we varied specified parameters, such as commanded ground speed, payload weight, and cruise altitude. We simultaneously collected data from the broad array of on-board sensors throughout 209 flights.
We developed an experimental protocol to ensure the reliability of the data collected. The flights followed a pre-established route with varying altitude (25 m, 50 m, 75 m and 100 m), speed (4 m/s, 6 m/s, 8 m/s, 10 m/s and 12 m/s) and payload mass (no payload, 250 g and 500 g). Each combination was repeated at least three times, totaling 195 flights. In addition, 14 recordings were performed with the drone in hover and idle modes, for a total 209 flights. Finally, the data provided by each sensor were synchronized at a frequency of approximately 5 Hz. Information on the operational setup, such as payload mass, altitude and speed during cruise, date and time the flight started, and the predefined route, was manually logged and attached to the data set.
The flights were performed in the township of Penn Hills, PA at a site that is approximately 16 kilometers away from Pittsburgh, PA, USA. Proper certifications from federal and local authorities were obtained prior to testing. Checklists were created to ensure that flights would occur as safely and efficiently as expected. Finally, the information collected on each flight was plotted and assessed in order to validate the consistency of the data acquired.

Methods
This section details the acquisition setup used in these experiments and the sensor suite mounted on the airframe. It also discusses the experimental protocol for the flight tests.

Acquisition Setup
The acquisition setup discusses the hardware and software setup used to collect the data. A complete schematic is shown in Figure 1.  Multirotors are characterized by their use of multiple rotors to produce lift. The majority of the commercially available multirotor systems use 3 to 8 rotors to achieve flight. We use the DJI Matrice 100 quadrotor platform to represent multirotor UAVs which is seen in Figure 2. The Matrice 100 is a fully programmable and customizable UAS with a maximum cruise speed of 17 m/s (in GPS mode). The airframe is equipped with the DJI 3510 motors (350 Kv), DJI E SERIES 620D ESCs, and we use the DJI 1345s for our rotor blades. The system has an on-board autopilot that provides autonomous capabilities. Its standard battery has a capacity of 4500 mAh which gives it a flight time of 22 minutes without any additional payload.
The mass of the airframe is 1831 g, the battery 600 g, the anemometer and pole 136g, and the onboard computer with small sensors and wiring 1113 g, totaling 3680 g. Therefore, the total takeoff masses were 3680 g (no payload), 3930 g (with the 250-g payload) and 4180 g (with the 500-g payload). The payloads of different masses were all of dimensions 22 x 13.8 x 4.4 cm and were attached to the bottom of the airframe with velcro straps. The mass of the drone includes the mass of the Velcro straps.

Wind measurement sensor
The experiments use a FT Technologies FT 205 UAV-mountable ultrasonic anemometer for wind measurements 13 which is seen in Figure 3a. The sensor is accurate up to ±0.1m/s, has a refresh rate of 10 Hz, and is factory calibrated. We use the device's built-in filtering process to obtain reliable data. UART communication is used to record data from the sensor.  We record the state of the system (position, velocity, and orientation) using the 3DM-GX5-45 GNSS/INS 14 which is seen in Figure 3b. These sensors use a built-in Kalman filtering system to fuse the GPS and IMU data. The sensor was used at an output rate of 10 Hz. The sensor records data in N(North)-E(East)-D(Down) frame fixed at the takeoff point. The sensor is calibrated as per manufacturer instructions.

Current and Voltage measurement sensor
The current and voltage supplied to the drone are measured using a Mauch Electronics PL-200 sensor 15 . This sensor is based on the Allegra ACS758-200U hall current sensor, which can record currents up to 200 A and voltages up to 33 V. The sensor board is only installed into the "positive" (red) main wire from the battery; the "negative" (black) wire stays untouched, which reduces the risk the sensor board might short circuit. A Hall sensor was chosen for its better accuracy when compared with a traditional shunt sensor. The sensor is calibrated as per manufacturer instructions. Analogue readings from the sensor are converted into a digital format using a 8 channel 17 bit analogue-to-digital converter (ADC). The ADC is based on the MCP3424 from Microchip Technologies Inc and is a delta-sigma A/D converter with low noise differential inputs.

Syncing and Recording
Data syncing and recording is handled using the Robot Operating System (ROS) running on a low-power Raspberry Pi Zero W. Data is recorded on the Raspberry Pi's microSD card. The data provided by each sensor were synchronized to a frequency of approximately 5 Hz using the ApproximateTime 16 message filter policy of ROS. The synchronized output approximately follows the current frequency of the sensors. The frequency variability in the synchronized output is thus a by-product of this decision not to interpolate but keep the data intact as received directly from the sensor. All the data has associated timestamps which enables a user to interpolate it at whichever frequency the user desires. A hard synchronization at a particular frequency would have required us to apply an interpolation algorithm, the choice of which we felt should rest with the end-user.

Acquisition Protocol
This section discusses the flight routines for data collection. A flight plan was created to ensure safety and reliability of the data collected. Procedures for pre-, during, and post-flight were followed as described below.

Pre-flight
Each test day is selected subject to weather conditions. Extremely harsh weather is avoided, such as precipitation and high wind speeds, but care is taken that the data-set is not biased towards good weather. The test location Before each flight we ensure that the vehicle is airworthy and that the airframe and control system are calibrated to run the upcoming experiment. We ensure that the flight is configured correctly according to the control variables on the day's flight plan. We then go through the pre-flight checklist (see Supplementary Information).

Flight
Once the preflight is complete, the Remote Pilot-In-Command (PIC) issues a pre-flight notice to the members and uses a custom Graphical User Interface (GUI) to launch the health monitoring scripts. The program first completes a check of all the onboard sensors and ensures that all subroutines are fully operational. Once the system gets a go-ahead from the health monitoring scripts it then starts the data recording. After a verbal "Go for takeoff" notice, the PIC launches the flight control scripts that use the DJI SDK to autonomously control the GPS waypoint guidance. The UAV arms itself and then takes off vertically to reach the commanded cruise altitude at a constant upward speed of approximately 2.5 m/s. Once at the altitude, the UAV turns the heading to the first waypoint and accelerates to reach the commanded ground speed. On reaching the first waypoint, the UAV stops and turns to go to the next waypoint. This continues as the UAV tracks a triangular wind-neutral path while recording the data. The triangular path and a snippet of the recorded data is shown in Figure 4. When it reaches the launch point again, the UAV stops and descends at approximately 1.5 m/s. Once safely on the ground, the UAV disarms itself and the data recording stops. The PIC calls out flight completed. At all points in the flight, the PIC maintains visual line of sight with the UAV with access to the manual control override to ensure safety of the team and the UAV.

Post-flight
At the conclusion of the flight, a GUI is used to download the raw ROSBag files and then use the post-processing scripts to synchronize the data from various sensors and convert it to a comma-separated values (CSV) file for storage. The raw files are also stored. Concurrently entries are also completed on the flight plan. The post-flight checklist is followed (see Supplementary  Information) and the UAV is then configured for the next flight.

Regulation and Safety
All data collection is conducted within the rules and regulations under part 107 for UAS operations. This includes maintaining visual line-of-sight with the aircraft, keeping the aircraft weight under 55 pounds (24.95 kg), flying only in daylight, not flying above 400 feat above ground level, following a preflight inspection, and flying withing permissible airspace 17 . It is also ensured that the take-off weight and vehicle commands stay within the airframe safety specification. All FAA and local UAV regulations are observed.
Care is taken in the usage of LiPo DJI TB48D batteries. They are charged using chargers which monitor the voltage and temperature. Batteries are transported in a metal container to protect them from puncture and to contain a fire in the case of combustion.
Additionally, safety glasses are worn when appropriate and a fire extinguisher was always made available for use.

Data Records
All raw and processed data records listed in this section are available at (https://doi.org/10.1184/R1/12683453) 18 .The data recorded by each sensor are compiled in a .zip file that contains a folder for each flight with a file named raw.bag. A CSV file named parameters.csv provides a list with all flights and flight parameters. Finally, a file flights.zip contains a csv file for each flight with the information on duration, wind speed and direction, current and voltage of the system, aircraft position, orientation speed and acceleration. Table 1 provides a description on each variable.

Technical Validation
The data collected were assessed to ensure the reliability of the data provided. The flights were grouped according to altitude, speed during cruise, and payload. Then, we assessed the parameters collected (positional parameters, wind speed, and power) by comparing flight that share the same setup (programmed altitude, programmed speed and payload mas).  Figure 6a shows the influence of wind that naturally varies the airspeed readings among flights. On the other hand, Figure 6b shows that the power demand is kept consistent for all three flights. The variations in the yaw (Figure 7a) at the beginning of the flight shows that the aircraft was initially facing a different direction before the take-off of flight 202. Once the take-off procedure starts the aircraft automatically rotates to face the preset direction, as followed by the other flights.   The behavior of the parameters assessed shows only minor variations among flights with similar setups. These minor variations were expected due to external factors and the inherent variability of the measuring processes. Nevertheless, in all assessments, the results showed a consistent pattern, with data varying within limits that respect the physical boundaries of the experiment.
In addition, we computed the total energy consumption of each flight by numerically integrating power (current * voltage) over time. Then, we compared the total energy consumption of flights with the same setup (programmed speed, programmed altitude, and payload mass). The mean relative energy amplitude across the flight groups was 4.3% with a standard deviation of 2.6%. Moreover, 95% of the groups had a relative energy amplitude of less than 10%, which reflects natural variations among the flights. The maximum energy amplitude was observed by flights 92, 129, and 252 (approximately 3.5 Wh), which represents a relative amplitude of 15.5% of the mean energy consumption within this group. An in-depth analysis shows that flight 129 (24.8 Wh) had a greater cruise duration, when compared to flights 92 and 252 (21.8 Wh and 21.3 Wh, respectively). However, the air speed experienced by flight 129 after 100 seconds (Figure 10a) might have reduced the actual ground speed of the drone (Figure 10b), increasing the total flight duration, and causing this discrepancy on the overall energy consumption. A similar analysis with two other groups of flights that had relative energy amplitude greater than 10% did not indicate any substantial difference among the flight recorded.
We have also implemented a script to automatically process and assess the values measured during flight and compare them to the programmed values of altitude. 173 out of the 194 flights with cruise movement did not have any altitude readings during cruise beyond the manufacturer's ± 5m tolerance range. Moreover, there was only one flight that had a mean altitude during cruise (107.1m) beyond the programmed altitude and manufacturer's range (105.0 m). However, as the flight pattern and energy consumption of this flight was consistent with the similar flights (relative energy amplitude of 3% within the group) we have decided to maintain its data in the data set.
Finally, the uncertainty inherent to each sensor used has been summarized on Table 2 according to the values provided by each manufacture.

Usage Notes
The data available can be used to model the energy consumption of a small quadcopter drone, empirically fitting the results found or validating theoretical models. These data can also be used to assess the impacts and correlations among the variables presented and/or the estimation of non-measured parameters, such as drag coefficients. These data should not be extrapolated to assess the energy consumption of different drone models or drones operating outside of the range of values tested. The measurements from the onboard anemometer can be used to calculate the airspeed components (cross-wind and head-wind) and local wind conditions. The anemometer records the wind angle and magnitude with respect to the moving drone. We provide the original data from the anemometer. However, previous works that have used anemometers for onboard wind measurements [19][20][21] have reported that while the wind angle measurements were found to be accurate for all flight conditions, the magnitude measurements show a bias that reports a higher wind magnitude than expected. We found that the effect is more pronounced at lower UAV speeds. Thus, future work is required to investigate and correct the magnitude bias in addition to correcting for the UAV motion. In Supplementary Information, we provide one method of magnitude bias and ego motion correction, although work in this area is ongoing.

Code availability
The codebase used to fly the UAV autonomously, record and synchronize data, and interface between different sensors is available for public use under BSD license. The codebase can be accessed at https://bitbucket.org/castacks/workspace/projects/DOE.

A.1 Pre-Flight
Inspect the aircraft

B Anemometer Magnitude Bias and Ego Motion Correction
One way to remove the magnitude bias and ego motion in the wind measurements is by using the inertial velocity data and the data collected by Brushi et al. 20 of a quadrotor flying with a ultrasonic wind sensor inside a wind tunnel. Given the similarity between our setup and theirs, the wind-tunnel results 20 are used to construct a polynomial mapping between measured and actual wind speeds. As the data lacks points in the lower range of values, it is augmented with results from our own setup. The data-points and the curve fit are plotted in Figure 11. The UAV was flown in hover and constant ground speed mode for an extended amount of time in near-zero wind conditions to get the lower range of values. The magnitude correction polynomial and ego-motion correction is given in Equation where V N and V E represent the inertial speed of the UAV in North and East directions, and w N and w E represent the corrected wind components in North and East directions. The data set contains the raw measurements and is not modified with these proposed methods, as the focus of this work is not about obtaining accurate wind field estimations. The area of wind estimation through the use of a drone is an ongoing field of research 22 , as the rotors induce complex air disturbances which affect the anemometer. Thus we left our data in a state where various current or future methods of wind correction can be applied if needed.