Time-varying volume prediction system

Abstract

To provide a time-varying loudness prediction system, method and storage medium for predicting time-varying loudness in a geographic region.SOLUTION: In a time-varying loudness prediction system, historical dynamic feature data 306 including noise information, weather information and traffic information is collected from a plurality of sensors 302a, 302b, 308 located in a plurality of geographic regions. Then, dynamic feature data for training the regions is extracted from the collected historical dynamic feature data 322, a model is trained with the dynamic feature data and static feature data of the geographic regions so as to generate a trained model 320. The model is used to predict time-varying loudness in different regions at time later than the collection of the training data.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] This specification relates generally, but not exclusively, to methods and systems for predicting noise in a particular environment and generating noise map data. [Background technology]

[0002] Every day, millions of hours are wasted on roads around the world. The average San Francisco resident spends 230 hours a year commuting to and from work, representing more than 500,000 hours of lost productivity each day in that city alone. In Los Angeles and Sydney, residents spend seven weeks' worth of work time commuting each year, two of which are wasted unproductively stuck in traffic. The problem is worsening in many of the world's megacities; in Mumbai, the average commute time exceeds 90 minutes. For workers, this translates into less time with family, less time to work to grow the economy, higher fuel costs, and significantly increased worker stress levels. For example, a study published in the Journal of the American Academy of Preventive Medicine found that people who commute more than 10 miles are more likely to experience elevated blood pressure. Summary of the Invention

[0003] On-demand aviation has been proposed as one solution to the above-mentioned transportation and mobility problems. On-demand aviation has the potential to fundamentally improve urban mobility and allow people to regain the time lost in their daily commute. Urban air transportation has the potential to alleviate traffic congestion on the ground by utilizing three-dimensional airspace. A network of small electric aircraft that take off and land vertically (VTOL (Vertical Take-off and Landing) aircraft, pronounced "vee-tor") would enable fast and reliable transportation between suburbs and cities, and even within cities.

[0004] On-demand aviation offers a solution to the above problems, but one of the obstacles to its widespread adoption is the concern about the noise generated by its operations. Exposure to noise has psychological and physiological effects on people within the noise range. For example, one of the reasons that heliports are not currently located in or near large demand centers is that the noise generated by these rotorcraft is too disruptive and unacceptable to local communities.

[0005] Therefore, there is a need for improved methods for operating on-demand aircraft that minimize the noise impact on surrounding areas. The system comprises a hardware processing circuit and one or more hardware memories storing instructions that, when executed, configure the hardware processing circuit to perform operations including receiving measurements of dynamic feature data of a geographical area, determining static features of the geographical area, and generating a predicted background noise volume in the geographical area during a specified period of time using a model trained on training data including historical measurements of the dynamic feature data of a plurality of areas and static features of the plurality of areas over a plurality of training periods, wherein the geographical area is not included in the plurality of areas and the specified period occurs after the plurality of training periods.

[0006] This application claims the benefit of priority to U.S. Provisional Application No. 62 / 859,685, entitled "Time Varying Loudness Prediction via a Trained Model," filed June 10, 2019, the contents of which are incorporated herein by reference.

[0007] The drawings are not necessarily drawn to scale, but the same numerals may represent similar components in different figures. The same numerals but different suffixes may represent different instances of similar components. In the figures of the accompanying drawings, several embodiments are shown by way of example, and not by way of limitation. [Brief explanation of the drawings]

[0008] [Figure 1] 1 illustrates a traffic environment 100 according to one embodiment. [Figure 2] 1 is a diagrammatic representation of an autonomous aircraft system in accordance with some illustrative embodiments. [Figure 3] FIG. 1 is a schematic diagram of data flow in one or more of the disclosed embodiments. [Figure 4A] FIG. 1 is a diagram showing noise measurement locations in metropolitan areas. [Figure 4B] FIG. 1 is a diagram showing noise measurement locations in metropolitan areas. [Figure 5] 1A-1C illustrate two example noise sensors that may be used to collect noise measurements in at least some of the disclosed embodiments. [Figure 6A] FIG. 1 shows observations collected by the measuring equipment described above. [Figure 6B] FIG. 1 is a diagram showing noise levels in a geographical region at a particular time. [Figure 7A] FIG. 1 illustrates node optimization based on volume, in accordance with at least some of the disclosed embodiments. [Figure 7B] FIG. 10 illustrates air route selection based on volume data, in accordance with at least some of the disclosed embodiments. [Figure 8] FIG. 8 illustrates an example machine learning module 800, according to some examples of the present disclosure. [Figure 9] 1 is a flowchart of a process for normalizing training data in accordance with at least some of the disclosed embodiments. [Figure 10] FIG. 1 illustrates one observation from the analysis of the training set described above. [Figure 11] FIG. 10 illustrates a correlation matrix of model features in one embodiment. [Figure 12A] 1 is a flowchart of a process for predicting time-varying loudness across multiple frequencies. [Figure 12B] This is a continuation of the flowchart of FIG. 12A. [Figure 13] FIG. 1 is a block diagram illustrating an example of a software architecture for a computing device. [Figure 14] FIG. 1 is a block diagram illustrating the hardware architecture of a computer device. DETAILED DESCRIPTION OF THE INVENTION

[0009] The following description and drawings sufficiently illustrate particular embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, portions and features of other embodiments. The embodiments set forth in the claims encompass all available equivalents of the claims.

[0010] There are many reasons to understand the noise profile of an area. For example, the noise profile or noise levels can determine the tolerance for additional noise introduced into the environment. Some government regulations require that a proposed activity add no more than a specified percentage to existing noise levels. Therefore, quieter areas may make it more difficult to operate without violating these government requirements.

[0011] When planning operations, it can be difficult to understand the current noise environment. This can be especially true when planning aircraft operations that may cover long distances and affect large geographic areas. Noise information for these large areas is generally unavailable, making planning operations in these regions difficult. This lack of understanding of the noise environment in which aircraft operate can therefore present a technical problem. As a result of this technical problem, aircraft route allocations may have an undesirable adverse impact on ground activities. This may result in the need to curtail flight activity below levels that would be manageable if the noise environment were better understood.

[0012] The disclosed embodiments solve this technical problem by providing a model capable of predicting time-varying sound levels across multiple frequencies for nearly any geographic region for which a set of characteristic parameters is known. To achieve this, static and dynamic characteristic information for multiple regions is collected. Static characteristic information includes information such as elevation, the vegetation percentage of the region, distance from one or more roads, and other characteristics of the geographic region that are largely static over time, or at least change relatively slowly. Dynamic characteristic information is collected by deploying various sensors. Some sensors are configured to collect weather data for a region, such as one or more of temperature, dew point, humidity, wind speed, wind direction, barometric pressure, and other weather data. Other sensors collect noise information within the region. For example, a noise sensor is configured to collect time-varying sound level data at multiple frequencies. Other sensors record traffic volume information. In various embodiments, traffic in this context includes, but is not limited to, one or more of road traffic (traffic of buses, cars, motorcycles, scooters, etc.), air traffic, and / or rail traffic. Each of the weather, noise, and traffic data is correlated with the period over which the data was collected.

[0013] The static and dynamic feature data for each of the multiple regions is used to train the model. A percentage of the feature data is selected from the training set and used to test the accuracy of the model in predicting noise data for a region. The results of these tests are described below. Thus, the disclosed embodiments enable prediction of loudness information for a geographic region over multiple time periods. Note that the geographic region being predicted does not necessarily need to be included in the training data. Furthermore, the disclosed embodiments may also provide predictions for future periods, or at least for periods after recent training data has been collected. Data generated from the model can be used to generate noise map data for a particular region. This may include, for example, a region associated with the data input into the model or another region (for which the model can predict loudness). Furthermore, these predictions (e.g., based on the noise map data) may be used to route aircraft through the geographic region. For example, a noise prediction for a geographic region may be used to determine whether to route aircraft through the region, at what altitude, and / or at what time. For example, if the predicted background noise level in an area is relatively high (e.g., the background noise is above a predetermined threshold), some embodiments route aircraft over the area at a lower altitude than if the background noise level in the area is relatively low (e.g., the predicted background noise is below the predetermined threshold or a second predetermined threshold). In some embodiments, a minimum predicted background noise level along the aircraft route is determined, and the altitude along the aircraft route is set based on this minimum level. For example, if the minimum predicted background noise level along the route is below a predetermined noise threshold, some embodiments set the altitude along the aircraft route to be above a predetermined altitude threshold (e.g., to minimize the noise impact on relatively quiet areas). Urban planning may also be influenced by the model's predictions. For example, the location and / or time of operation of airports and / or skyports may be influenced based on the predictions provided by the disclosed models.

[0014] When estimating human noise perception, the weighted sound pressure level (L A ) alone may be inaccurate in some cases. A was developed to measure whether intentionally generated sounds, such as those from telephones, are loud enough to achieve their intended purpose. A does not measure whether a sound is annoying to humans; instead, loudness is a better metric for tracking the subjective perception of sound pressure.

[0015] L A By examining volume instead of frequency, the disclosed embodiments are able to identify and account for certain types of acoustic nuances. For example, the disclosed embodiments provide frequency weighting according to several levels. Auditory perception behaves differently depending on sound level. Sound pressure levels are traditionally weighted along a curve to account for the sound pressure levels audible to humans. This weighting minimizes or ignores noise outside the audible frequency range (20 Hz to 20 kHz). The weighting is designed to mimic human sensitivity to single tones at the level of soft speech. While other weighting curves have been proposed for higher sound levels (where humans are more sensitive to low and high frequency sounds), modern practice is to adjust the weighting curve continuously with level rather than using a discrete one.

[0016] Some of the disclosed embodiments further enable spectral volume summation. For example, two distinct sounds may share the same level, but spectral differences contribute to the difference in volume. In addition to variations in sensitivity with frequency, the ear is less sensitive to sounds that are close in pitch to a strong sound and more sensitive to sounds that are farther apart in pitch.

[0017] Some embodiments consider the temporal shape of a sound. In particular, some distinct sounds may share equivalent levels and spectra, yet still be perceived as very different. Temporal shape contributes to how a sound is heard, as humans have different integration times for the onset and decay of sound events. A particular sound may still stand out, even if its sound pressure is several decibels lower than background noise, depending on its rate of change.

[0018] The loudness can vary depending on the length of time recorded. Time-Varying Loudness (TVL) is of interest for understanding how aircraft blend into the urban soundscape. TVL includes both short-term reception (rapid onset) and long-term reception (memory) in the auditory system, and takes into account both the inertia of the human physiological system (e.g., human neurons do not fire instantaneously) and the perception of "pulses" such as rotor blades. A helicopter (for example) can still be heard at low dB(A) levels and stand out from the urban soundscape. Averaging over long periods (more than 50 ms) can obscure the perception of pulsed sounds, making it difficult to clearly see how a newly introduced noise blends into the surrounding soundscape.

[0019] To measure the loudness increase contributed by an on-demand aircraft flight, the degree to which ambient sounds mask the sound of the aircraft is measured. Ambient TVL versus time is considered for multiple spectral regions where aircraft noise occurs. In some embodiments, approximately 30 frequency bands are analyzed. In some embodiments, an average loudness measurement across the frequency range is reported. In at least some of the embodiments, data is typically collected within each frequency band.

[0020] So relying solely on the average physical displacement of an aircraft as a proxy for noise is an irresponsibly oversimplified metric for operational success. A system needs to take these nuances into account in measuring aircraft noise and map it against the same nuances in the urban soundscape.

[0021] Thus, the disclosed embodiments simultaneously report the relative total volume at a given location and the local volume due to flight activity. Among several commonly used volume metrics, time-varying volume is the most beneficial for applications contemplated by the disclosed embodiments. Specifically, TVL(i,l,h), the time-varying volume TVL given an equivalent rectangular band i, location l, and time h, accurately captures the nuances of a distributed urban soundscape.

[0022] In some embodiments, for any given location and time, the TVL is incorporated into the equivalent loudness for that time. As aircraft operations and flight routes increase in an area, the TVL at those times and locations will change based on the perceived loudness of the aircraft operations relative to the existing soundscape. In disclosed embodiments, this is captured by measuring the difference in TVL between the ambient sound and the ambient sound after the aircraft operations are introduced. In some embodiments, these determinations are performed for each spectral region.

[0023] Some embodiments also include weighting factors that take into account population density in a particular area and at a particular time, such as: Weighted effect (l,h) = ΔTVL(l,h) × P(l,h) Thus, the disclosed embodiments enable the calculation of total sound volume as additional operations are added by establishing a TVL standard, so that TVL(i,l,h) serves as the base soundscape metric.

[0024] FIG. 1 is a diagram of a transportation environment 100 in which a fleet of aircraft 102 and a fleet of ground vehicles 104 provide mobility services (eg, transporting people, delivering goods) in accordance with an illustrative embodiment.

[0025] Coordination of interaction, communication, and movement between the aircraft in the aircraft fleet 102 (e.g., vertical take-off and landing (VTOL) aircraft 115, helicopter 124, and aircraft 126) and the vehicles in the ground vehicle fleet 104 (e.g., cars 112, scooters 114, bicycles 116, motorcycles 118, and buses 120) is facilitated by one or more mobility network servers 110 coupled to both the aircraft fleet 102 and the ground vehicle fleet 104 via various networks 106. Specifically, the mobility network server 110 may coordinate the acquisition of data from various sensors on the aircraft in the aircraft fleet 102 to control the routing and operation of the various vehicles in the ground vehicle fleet 104. Similarly, the mobility network server 110 coordinates the acquisition of data from various sensors on the vehicles in the ground vehicle fleet 104 to control the routing and operation of the various aircraft in the aircraft fleet 102. For example, the mobility network server 110 may control the acquisition of traffic monitoring data by the aircraft fleet 102 to aid in routing of vehicles in the ground vehicle fleet 104 by a routing engine that is part of the mobility network server 110 .

[0026] The mobility network server 110 is also coupled to an unmanned aircraft traffic management system (UTM) 108, which operates to provide aircraft traffic management and collision avoidance services to the aircraft fleet 102. In one embodiment, the UTM 108 provides airspace management at various altitudes up to several thousand feet. The UTM 108 may also provide a large amount of voiceless air traffic control interaction and is integrated with air traffic control systems associated with airports. The mobility network server 110 utilizes the connectivity provided by the UTM 108 to communicate with aircraft in the aircraft fleet 102 to pass information such as routing.

[0027] For example, data acquisition for traffic monitoring by the aircraft fleet 102 may be based on predetermined and / or optimized aircraft movements via the UTM network. Connection to the UTM 108 is facilitated by multiple communication frequencies as required for operation. Onboard telemetry of aircraft in the aircraft fleet 102 is supplemented with GPS data and other communication streams (e.g., GPS, 5G).

[0028] The UTM 108 is connected to a mobility network server 110 that manages / monitors ground vehicle operations. The UTM 108 also communicates with third-party UAS service suppliers (USS) and complementary data service providers (SDSP) to facilitate the transfer of data to these third-party services.

[0029] The mobility network server 110 further performs proactive determination and / or optimization of aircraft fleet 102 flights, for example, based on cargo being transported from an origin to a destination (e.g., a vertical takeoff and landing airport, a reference point, or a location determined from time to time). For example, flights by aircraft fleet 102 may be optimized to improve overall throughput and thus system efficiency. Aircraft 126, vertical takeoff and landing (VTOL) aircraft, such as VTOL aircraft 115, and / or helicopters 124 may fly within dynamically assigned routes and airways, thereby enabling large-scale, safe, and high-density operations. These route / airway assignments are determined by the mobility network server 110 based on environmental acceptability (e.g., noise), weather, airspace collision avoidance, and operational relevance.

[0030] The aircraft in the aircraft fleet 102 may include human-controlled aircraft. For example, an aircraft operator (e.g., a pilot) may control the aircraft within the aircraft. In some embodiments, the aircraft operator may remotely control the aircraft by utilizing a computing device at a remote location that displays a user interface.

[0031] In some embodiments, aircraft fleet 102 may include autonomous aircraft. Figure 2 is a block diagram of aircraft 200, according to an exemplary embodiment of the present disclosure. Aircraft 200 may be, for example, an autonomous aircraft or a semi-autonomous aircraft. Aircraft 200 includes one or more sensors 218, an aircraft autonomy system 212, and one or more aircraft control systems 228.

[0032] Aircraft autonomous system 212 may be used to control or assist in the control of aircraft 200. In particular, aircraft autonomous system 212 receives sensor data from sensors 218 and performs various processing techniques on the data collected by sensors 218 to attempt to understand the environment around aircraft 200 and generate an appropriate movement path through the environment. Aircraft autonomous system 212 may control one or more aircraft control systems 228 to navigate aircraft 200 according to this movement path.

[0033] Aircraft autonomy system 212 includes perception system 220, prediction system 224, motion planning system 226, and attitude control system 222 that cooperate to perceive the environment surrounding aircraft 200 and determine a motion plan to control the movement of aircraft 200 accordingly.

[0034] Various portions of aircraft autonomous system 212 receive sensor data from sensors 218. For example, sensors 218 may include remote sensing sensors as well as motion sensors such as an inertial measurement unit (IMU), one or more encoders, etc. The sensor data may include information describing the location of objects in the environment surrounding aircraft 200, information describing the motion of the aircraft, etc.

[0035] Sensor 218 may also include one or more remote detection sensors or sensor systems, such as a LIDAR, a RADAR, one or more cameras, etc. As an example, a LIDAR system of sensor 218 generates sensor data (e.g., remote detection sensor data) that includes the locations (e.g., in three-dimensional space relative to the LIDAR system) of multiple points corresponding to objects that have reflected a ranging laser. For example, a LIDAR system may measure distance by measuring the time of flight (TOF) it takes for a short-pulse laser to travel from the sensor to the object and back, and calculating the distance from the known speed of light.

[0036] As another example, the RADAR system of sensor 218 generates sensor data (e.g., remote sensing sensor data) that includes the locations (e.g., in three-dimensional space relative to the RADAR system) of multiple points corresponding to objects that have reflected ranging radio waves. For example, the RADAR system transmits radio waves (e.g., pulsed or continuous waves) that are reflected off objects and returned to the RADAR system's receiver, which can provide information about the object's location and velocity. In this way, the RADAR system can provide useful information about the object's current velocity.

[0037] As yet another example, one or more cameras of sensor 218 can generate sensor data (e.g., remote sensor data) including still or video images. Various processing techniques (e.g., range imaging techniques such as structure from motion, structured light, stereo triangulation, and / or other techniques) can be performed to identify locations (e.g., in three-dimensional space relative to one or more cameras) of multiple points corresponding to objects shown in one or more images captured by the one or more cameras. Other sensor systems can similarly identify locations of points corresponding to objects.

[0038] As another example, sensors 218 may include a positioning system. The positioning system may determine the current location of aircraft 200. The positioning system may be any device or circuitry that analyzes the location of aircraft 200. For example, the positioning system may determine location using one or more of multiple inertial sensors, a satellite positioning system such as a Global Positioning System (GPS), determine location based on an IP address, determine location using triangulation and / or proximity measurements to network components such as network access points (e.g., cellular towers, Wi-Fi access points, etc.), and / or other suitable techniques. The location of aircraft 200 may be used by various systems of aircraft autonomous system 212.

[0039] In this manner, sensors 218 may be used to collect sensor data including information representing locations (e.g., in three-dimensional space relative to aircraft 200) of points corresponding to objects in the environment surrounding aircraft 200. In some embodiments, sensors 218 may be located at a variety of different locations on aircraft 200. Examples include one or more cameras, RADAR, and / or LIDAR sensors.

[0040] Attitude control system 222 receives some or all of the sensor data from sensors 218 and generates an attitude for aircraft 200. The attitude represents the position (including altitude) and attitude of the aircraft. The position of aircraft 200 is a point in three-dimensional space. In some examples, this position is represented by a set of Cartesian coordinate values, although any other suitable coordinate system may be used. The attitude of aircraft 200 roughly represents the orientation of aircraft 200 at that position. In some examples, the attitude is represented by yaw about a vertical axis, pitch about a first horizontal axis, and roll about a second horizontal axis. In some examples, attitude control system 222 generates the attitude periodically (e.g., every 1 second, every 0.5 seconds, etc.). Attitude control system 222 adds a timestamp to the attitude, indicating the point in time that the attitude represents. Attitude control system 222 generates vehicle attitude by comparing sensor data (e.g., remote sensor data) against map data 216 that is representative of the environment surrounding aircraft 200 .

[0041] In some examples, the attitude control system 222 includes a localizer and an attitude control filter. The localizer generates an attitude estimate by comparing remote sensor data (e.g., LIDAR, RADAR, etc.) with map data. The attitude control filter receives attitude estimates from one or more localizers as well as other sensor data, such as motion sensor data from an IMU, encoders, odometer, etc. In some examples, the attitude control filter generates vehicle attitude by combining the attitude estimates from one or more localizers with the motion sensor data by executing a machine learning algorithm, such as a Kalman filter. In some examples, the localizer generates attitude estimates less frequently than the attitude control system 222 generates vehicle attitude. Thus, the attitude control filter generates several vehicle attitudes by extrapolating from past attitude estimates.

[0042] Perception system 220 detects objects in the environment surrounding aircraft 200 based on sensor data, map data 216, and / or aircraft attitude provided by attitude control system 222. For example, map data 216 may provide detailed information about the environment surrounding aircraft 200. Map data 216 may provide information regarding the route and / or airspace along which aircraft 200 is traveling, the location of other aircraft, the location, attitude, orientation, and / or other parameters of vertical takeoff and landing airports or landing strips, weather data (e.g., weather radar data), noise map data, and / or any other map data that provides information that assists aircraft autonomous system 212 in understanding and perceiving its environment and its relationship thereto. Prediction system 224 uses the aircraft attitude provided by attitude control system 222 to perceive the environment of aircraft 200.

[0043] In some examples, perception system 220 determines state data for objects in the environment surrounding aircraft 200. The state data may represent the current state of the object (also referred to as object characteristics). The state data for each object may represent, for example, an estimate of the object's current location (also referred to as position), current speed (also referred to as velocity), current acceleration, current heading, current orientation, size / shape / footprint (e.g., represented by a bounding shape such as a bounding polygon or bounding polyhedron), type / classification (e.g., vehicle vs. pedestrian vs. bicycle vs. other), yaw rate, distance from aircraft 200, shortest path to interaction with aircraft 200, shortest time to interaction with aircraft 200, and / or other state information.

[0044] In some implementations, perception system 220 can determine state data for each object over multiple iterations. In particular, perception system 220 can update the state data for each object at each iteration. This allows perception system 220 to detect and track objects, such as vehicles, that are closest to aircraft 200 over time.

[0045] Prediction system 224 is configured to predict the future position of one or more objects (e.g., one or more objects detected by perception system 220) in the environment surrounding aircraft 200. Prediction system 224 may generate predictive data associated with the objects detected by perception system 220. In some examples, prediction system 224 generates predictive data representing each respective object detected by perception system 220.

[0046] The object prediction data may indicate one or more predicted future locations of the object. For example, prediction system 224 may predict where the object will be located within the next 5 seconds, 20 seconds, 200 seconds, etc. The object prediction data may indicate the predicted trajectory (e.g., predicted path) of the object within the environment surrounding aircraft 200. For example, the predicted trajectory (e.g., path) may indicate the path that each object is predicted to follow as it moves over time (and / or the predicted speed at which the object will move along the predicted path). Prediction system 224 generates the object prediction data based on, for example, state data generated by perception system 220. In some examples, prediction system 224 also considers one or more vehicle attitudes and / or map data 216 generated by attitude control system 222.

[0047] In some examples, the prediction system 224 predicts the trajectory of an object using state data indicative of the type or classification of the object. As one example, the prediction system 224 can determine the particular object (e.g., an object classified as a vehicle) using state data provided by the perception system 220. The prediction system 224 can provide the predicted trajectory associated with the object to the motion planning system 226.

[0048] In some embodiments, prediction system 224 is a goal-oriented prediction system that generates possible goals, selects the most likely goal, and develops a trajectory along which the object can achieve the selected goal. For example, prediction system 224 may include a scenario generation system that generates and / or scores goals for the object and a scenario development system that determines a trajectory along which the object can achieve the goal. In some embodiments, prediction system 224 may include a machine learning goal scoring model, a machine learning trajectory development model, and / or other machine learning models.

[0049] Motion planning system 226 determines a motion plan for aircraft 200 based at least in part on predicted trajectories associated with objects in aircraft 200's environment, object state data provided by perception system 220, vehicle attitude provided by attitude control system 222, and / or map data 216. In other words, given information about the current locations of objects and / or predicted trajectories of objects in aircraft 200's environment, motion planning system 226 can determine a motion plan for aircraft 200 that best navigates aircraft 200 relative to objects at such locations and predicted trajectories of objects along an acceptable route.

[0050] In some embodiments, motion planning system 226 may evaluate a cost function and / or one or more reward functions for each of one or more candidate motion plans for aircraft 200. For example, the cost function may represent the cost (e.g., over time) of executing a particular candidate motion plan, while the reward function may represent the reward of executing a particular candidate motion plan. For example, the reward may have the opposite sign as the cost.

[0051] Thus, given information about the object's current location and / or predicted future location / trajectory, motion planning system 226 can determine the total cost of executing a particular candidate path (e.g., the sum of the costs and / or rewards provided by the cost function and / or reward function). Motion planning system 226 can select or determine a motion plan for aircraft 200 based at least in part on the cost function and the reward function. For example, a motion plan that minimizes the total cost can be selected or determined. A motion plan can be, for example, a path along which aircraft 200 will travel during one or more upcoming time periods. In some embodiments, motion planning system 226 can be configured to iteratively update the motion plan for aircraft 200 as new sensor data is obtained from sensors 218. For example, when new sensor data is obtained from sensors 218, a motion plan can be determined through analysis of the sensor data by perception system 220, prediction system 224, and motion planning system 226.

[0052] Perception system 220, prediction system 224, motion planning system 226, and attitude control system 222 may each be included in or be part of aircraft 200 configured to determine a motion plan based on data obtained from sensors 218. For example, a motion plan may be developed by sequentially analyzing data obtained by sensors 218 by perception system 220, prediction system 224, and motion planning system 226, respectively. While Figure 2 illustrates elements suitable for use in an aircraft autonomy system according to an exemplary embodiment of the present disclosure, one skilled in the art will recognize that other aircraft autonomy systems may be configured to determine a motion plan for an autonomous aircraft based on sensor data.

[0053] Motion planning system 226 may provide the motion plan to aircraft control system 228 to execute the motion plan. For example, aircraft control system 228 may include pitch control module 230, yaw control module 232, and throttle control system 234, which may each include various aircraft controls (e.g., actuators or other devices or motors that control power) that control the motion of aircraft 200. The various aircraft control systems 228 may include one or more controllers, controls, motors, and / or processors.

[0054] Throttle control system 234 is configured to receive all or a portion of the maneuver plan and generate throttle commands that are provided to engines and / or engine controllers or other propulsion system components of aircraft 200 to control the engines or other propulsion system.

[0055] Aircraft autonomy system 212 includes one or more computing devices, such as computing device 202, that may implement all or a portion of perception system 220, prediction system 224, motion planning system 226, and / or attitude control system 222. Exemplary computing device 202 may include one or more processors 204 and one or more memory devices (collectively referred to as memory 206). Processor 204 may be any suitable processing device (e.g., a processor core, a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microcontroller, etc.) and may be a single processor or multiple operably connected processors. Memory 206 may include one or more non-transitory computer-readable storage media, such as random access memory (RAM), read-only memory (ROM), electrically erasable and programmable read-only memory (EEPROM), erasable and programmable read-only memory (EPROM), flash memory devices, magnetic disks, and combinations thereof. Memory 206 may store data 214 and instructions 210 that, when executed by processor 204, may cause aircraft autonomous system 212 to perform operations. Computing device 202 may also include communications interface 208, which may enable computing device 202 to communicate with other components of aircraft 200 or external computer systems, such as via one or more wired or wireless networks. Additional descriptions of hardware and software configurations of computing devices, such as computing device 202, are also provided herein.

[0056] FIG. 3 is a schematic diagram of a data flow 300 of a computer system according to one or more of the disclosed embodiments. FIG. 3 illustrates two dynamic feature sensors 302a, 302b. The dynamic feature sensors 302a, 302b may be configured to detect features of the geographic region in which the sensors are located. For example, some of the dynamic feature sensors 302a, 302b may be configured to detect weather information within each geographic region, such as temperature, dew point, humidity, wind speed, wind direction, precipitation amount or intensity, barometric pressure, or other weather information. Other dynamic feature sensors 302a, 302b may be configured to detect dynamic features of man-made sources. For example, the dynamic feature sensors 302a, 302b may be configured to detect sound pressure level and / or volume at multiple frequencies. Dynamic feature sensors 302a, 302b, such as traffic sensors, sense dynamic features (such as traffic levels) at multiple points over time and send sensed information 304a and sensed information 304b, along with an indication of the timing of the information collection, to a historical dynamic feature data store 306.

[0057] Third-party sensors 308 may also be relied upon to provide information 310 to the historical dynamic feature data store 306. For example, third-party traffic sensors may detect the volume and speed of air, road, rail, or other traffic in an area over time and send this information to the historical dynamic feature data store 306.

[0058] In some embodiments, sensors may not be used to obtain information about dynamic features. Instead, in these embodiments, some of the information may be obtained from other sources. For example, third-party organizations may make available APIs (e.g., Darksky) or files that provide recorded weather information for one or more regions. Thus, in some embodiments, this existing dynamic feature information may be used as an addition to the historical dynamic feature data store 306.

[0059] The historical dynamic feature data store 306 accumulates historical information 304a, 304b, and 310 over time. This historical information 312 is then used to train the untrained model 314. In some embodiments, both the untrained model 314 and the trained model 320 shown in FIG. 3 include computing hardware and software, either alone or in combination. For example, in some embodiments, the untrained model 314 and / or the trained model 320 include one or more of the hardware components described below with respect to FIG. 14. Also in these embodiments, the untrained model 314 and / or the trained model 320 include instructions that configure a hardware processing circuit (e.g., the processor 1402 described below) to perform one or more of the functions of the untrained model 314 and / or the trained model 314, respectively, as described below. In some embodiments, one or more of the untrained model 314 and / or the trained model 320 are incorporated into the routing system 323 described below.

[0060] Static feature data store 316 provides additional information about the geographic region identified in historical information 312. Static feature data store 316 stores static information about the geographic region, such as elevation, topography, percent vegetation, and distance from one or more roads, highways, or air routes. Static feature information about the region used to train untrained model 314 is also provided to untrained model 314 as static feature information 317.

[0061] After training the untrained model 314, a trained model 320 is available. The trained model 320 generates noise predictions 321 for a region. These predictions may include predictions of time-varying loudness across multiple frequencies. The trained model generates predictions for the region based on dynamic feature data 322 and static feature information 324 for the region.

[0062] In some embodiments, the noise prediction 321 is provided to a routing system 323. The routing system 323 stores the prediction generated by the trained model 320 in a data store 325. In some of the disclosed embodiments, the routing system 323 further processes the noise prediction 321 configured by the trained model 314 to generate noise map data. For example, the routing system 323 generates noise information for multiple regions based on the noise prediction 321. In some embodiments, the multiple regions constitute a map. Some embodiments of the routing system 323 further generate multiple routes for the aircraft based on the noise prediction 321. For example, in some embodiments, the routing system 323 generates multiple routes from the origin to the destination of the aircraft's flight. Then, in some embodiments, the routing system 323 determines the route to use for the aircraft's flight by comparing background information for each of the multiple routes. In some embodiments, the background noise volume for each region included in the route is aggregated. Then, the route to select for the aircraft's flight is determined by comparing the aggregated noise levels of the multiple different routes. For example, in some embodiments, the route with the highest aggregate noise level is selected based on the comparison.

[0063] Additionally, in some cases, the altitude of the aircraft flight is selected based on the predicted background noise volume along the route, with the aircraft altitude being set to a higher value (above the first predetermined altitude threshold) for quieter routes (below a first predetermined noise threshold) and a lower altitude (below the second predetermined altitude threshold) for louder routes (above a second predetermined noise threshold). In some embodiments, the first predetermined altitude threshold and the second predetermined altitude threshold are equivalent. In some embodiments, the first predetermined noise threshold and the second predetermined noise threshold are equivalent.

[0064] In some embodiments, once a route is selected, the routing system 323 sends information defining the selected route to the UTM 108 described above. Figures 4A and 4B illustrate noise measurement locations in a metropolitan area. The collected noise measurements can be used to train models for predicting noise, as described in more detail below. Map 400 shown in Figure 4A includes noise measurement devices, examples of which are shown as 402a-402c. Figure 4B illustrates map 450 showing the locations of noise measurement devices in a metropolitan area. The noise measurement devices can be configured to measure time-varying sound levels at least once per second. The measurement devices can be positioned in geographic areas to capture fluctuations and correlations with traffic on nearby highways. Some measurement devices are mounted at fixed locations and sample sound pressure, potentially as many as 32,000 times per second. This sound pressure data is applied to offline analysis to produce partial-octave pressure and sound level data. Some measurement devices are mounted on portable platforms that can be repositioned in various nearby areas. The measurement devices on the portable platforms can be configured to collect 1 / 3-octave band level data once per second and internally process 1 / 12-octave band sound level data. This is a higher fidelity acquisition compared to previous 1 / 3 octave or A-weighted acquisition methods that traditionally use averaging times of one minute or more.

[0065] Loudness data may be collected in tenths of phon. The measurement device may also be configured to collect 1 / 4Cam (Cambridge) characteristic loudness (1 / 4Cam is approximately equivalent to 1 / 12 octave). These measurements may be used to represent a loudness spectrum. Sound pressure level (SPL) may also be collected. For example, the measurement device may be configured to collect SPL in each 1 / 3 octave band.

[0066] Previous studies have used sound pressure level to measure noise. As explained above, SPL does not accurately measure whether a sound is annoying to humans. Loudness measures such as International Organization for Standardization (ISO) 532-3 (e.g., Cambridge-based loudness measurements and more advanced metrics incorporating loudness) are a better way to track sound perception because they take into account several factors.

[0067] These factors include frequency weighting according to level. Sound pressure levels are traditionally weighted along a curve to take into account the range of human hearing. Auditory reception behaves differently depending on sound level.

[0068] Another factor not taken into account in the use of SPL is spectral loudness summation: two distinct sounds may share the same level, but spectral differences may contribute to differences in loudness. Human hearing varies in sensitivity with frequency, and across the entire frequency range, is less sensitive to frequencies close to originally strong frequencies and more sensitive to frequencies far away from strong spectral components.

[0069] Another factor not taken into account by SPL is the temporal shape of a sound; distinct sounds may share equivalent levels and spectra, yet still be perceived as very different. For example, a particular sound may have a sound pressure level a few decibels lower than background noise, yet still stand out depending on its temporal shape.

[0070] In contrast, fixed or time-varying loudness metrics, derived from research at Cambridge University, include measures of both short-term reception (rapid onset) and long-term reception (memory) in the auditory system. These measures take into account both the inertia of the human physiological system (human neurons do not fire instantaneously) and how we hear "pulses" like rotor blades. Because event frequency and loudness are also important for perception, intermittency ratios can play a role in measuring perceived sound exposure. One model of loudness is proposed in "Moore BCJ, Glasberg BR (1996) A revision of Zwicker's loudness model, Acustica United with Acta Acustica 82: 335-345." The loudness model was further updated in 2006 in "Glasberg BR, Moore BC, Prediction of absolute thresholds and equal-loudness contours using a modified loudness model, J Acoust Soc Am. 2006 Aug; 120(2):585-8." Time-varying loudness (TVL) is described in "Stone M.A., Glasberg BR, Moore BCJ, Dynamic aspects of loudness: A real-time loudness meter., British Journal of Audiology 30: 124 (1996)" and further expanded in "Glasberg B.R., Moore BCJ, A model of loudness applicable to time-varying sounds., Journal of the Audio Engineering Society 50: 331-342 (2002)."

[0071] The measurement equipment described above is capable of measuring Cambridge-based time-varying loudness at least once every second. Data collected from several locations is used by the disclosed embodiments for a training set. The training set is used to build a loudness prediction model. The loudness prediction model predicts the loudness of noise at any moment of the day based on other inputs including weather, traffic volume, traffic speed, and distance from roads (e.g., highways).

[0072] Figure 5 illustrates two exemplary noise measurement devices implemented in accordance with one or more of the disclosed embodiments. Figure 5 illustrates a fixed noise measurement device 502 and a mobile noise measurement device 504. Exemplary mobile sensors have characteristics such as an all-weather omnidirectional microphone mounted on the trunk lip in conjunction with a solar panel on the roof or trunk lid of a vehicle. Some microphones used in the disclosed embodiments have the characteristics shown in Table 1 below.

[0073] [Table 1] The system enclosure in some embodiments has two XLR connectors and an opening for connecting a USB cable to an LTE modem. One connector is attached to a microphone and the other is attached to a solar panel. Some embodiments include a switch to control power to the data system.

[0074] In some embodiments, the microphone signal is provided to a USB analog-to-digital converter attached to a USB port of a computing device (e.g., a Raspberry Pi 3B microcontroller (Raspberry Pi is a registered trademark)).

[0075] The software is installed on an SD card in a computing device (e.g., running Raspbian Jesse). In some embodiments, a solar panel powers a charge controller that provides a programmed charging current to an 18AH motorsport / light aircraft battery OdysseyPC680.

[0076] The charge controller incorporates a low-voltage disconnect that prevents the battery from being discharged below approximately 11 volts. Battery capacity can be significantly reduced if the battery is deeply discharged even once. In at least some embodiments, the battery supplies the computing device with a switched-mode power supply (via a switch on the outer housing) that provides 5.3 volts.

[0077] The accuracy of the predictions provided by the model is improved by collecting noise data from acoustically distinct locations, while still maintaining a set of covariates consistent with the geographic region for which the predictions are made. Examples of covariates used in collecting model training data, one or more of which are employed in various embodiments, are shown in Tables 2-1 and 2-2 below.

[0078] [Table 2-1]

[0079] [Table 2-2] FIG. 6A shows observations 600 collected by the measurement equipment described above. These observations show that, as shown in FIG. 5, noise levels in many locations vary significantly throughout the day on weekends versus weekdays. FIG. 6A shows that peak activity at 6:00 AM is approximately three times louder than the quiet period three hours prior. High noise levels can provide an opportunity for heavy traffic operations. In contrast, operations during periods of low background noise can significantly disrupt the local community.

[0080] Using a predictive model implemented by embodiments of the present disclosure, noise map data can be generated based on predictions made by the model. The noise map data can represent predicted levels (e.g., background noise levels) for multiple locations within a geographic region. To generate the noise map data, the output of the model 320 can specify the predicted background noise levels (time-varying levels) as well as associated locations (e.g., represented by longitude coordinates, latitude coordinates, attitude, etc.) as described herein. Aggregation of predictions output by the model can generate noise map data showing predicted background noise levels for multiple locations within a region. For example, the noise map data can include a noise heat map of the geographic region predicted by the model. Examples of these predictions are shown in Figures 6B, 7A, and 7B. Figures 6B, 7A, and 7B show noise levels for geographic regions 650 and 700 at different times. Comparing Figure 6B with Figures 7A and 7B, the darker colors associated with Figures 7A and 7B relative to Figure 6B indicate increased noise levels in the darker areas. 7B is a diagram illustrating route selection based on volume data, according to at least some of the disclosed embodiments. The route defines situations in which air traffic can be routed to the geographic region shown in the image. FIG. 7B shows a first line 705 illustrating situations in which route selection is performed without considering volume. FIG. 7B also shows a second line 710 illustrating the effect of considering volume.

[0081] As described in more detail herein, the noise map data can be used for various purposes associated with aircraft. For example, in some embodiments, the noise map data can be used to optimize aircraft routing and / or airspace routing. For example, generating an aircraft route based on the noise map data can generate a route that maintains an acceptable level of sound volume at locations along the route within a region. The acceptable level of sound volume can be a threshold (e.g., in units such as decibels) below which the total noise level (e.g., predicted sound volume + aircraft-generated sound volume / noise) remains low. The threshold can be set by an authority such as a regulatory body, a service provider that manages an aircraft fleet, or the like. The route and / or airspace routing can be generated such that the aircraft is routed such that the acceptable level of sound volume is not exceeded at any point along the route. Furthermore, the airspace routing of the route (e.g., the volume around the route in which the aircraft will remain) can be generated such that the aircraft remains within a threshold distance along the route to maintain the acceptable level of noise.

[0082] Additionally or alternatively, the noise map data can be used to determine one or more operational constraints for the aircraft. For example, time constraints identifying takeoff times, flight times, landing times, the first takeoff or landing time of the day, the last takeoff or landing time of the day, etc. can be determined based on the noise map data. In particular, the noise map data can provide predicted noise levels for various times of day, allowing flight schedules to be generated to maintain acceptable sound levels. As an example, the noise map data can help determine when morning and / or evening flights should begin and / or end, and / or intermediate times when lower aggregate noise levels are preferred (e.g., when school ends for the day).

[0083] Additionally or alternatively, one or more landing constraints may be determined based on the noise map data, for example, the noise map data may help determine the takeoff angle / direction and / or landing approach angle that would be most conducive to maintaining the total noise level below a threshold loudness tolerance level.

[0084] The noise map data can be used to determine the assignment of aircraft to routes within a geographic region and / or the frequency of aircraft flight along the routes. For example, an aircraft fleet may include aircraft of different types, makes, models, sizes, etc. As such, certain types of aircraft within the aircraft fleet may generate different levels of noise / volume during aircraft takeoff, landing, and / or route travel (e.g., due to differences in propulsion systems, cargo capacity, fuel type, etc.). Aircraft operation noise / volume can be obtained and stored (e.g., via the aircraft manufacturer / supplier), measured by sensors while the aircraft is in operation, and / or calculated based on an aircraft model. As described herein, the noise map data can indicate predicted noise levels (e.g., background noise layers) at locations along routes within a geographic region, which can enable the determination of the amount of additional noise / volume (e.g., aircraft noise layers) that can be added by operating aircraft to maintain the noise level below acceptable noise levels. Based on such determinations, specific aircraft can be selected and assigned to routes to maintain the total noise level below acceptable noise levels.

[0085] In some embodiments, the noise map data can be used to determine the frequency of flights along a route / within a geographic region, for example, the number of times an aircraft should travel a route to maintain acceptable levels of sound volume at locations along the route / within the mapped geographic region.

[0086] 8 illustrates an example machine learning module 800 according to some examples of the present disclosure. The machine learning module 800 utilizes a training module 810 and a prediction module 820. The training module 810 inputs historical information 830 to a feature determination module 850A. The historical information 830 may be labeled. As described above, the historical information may include historical measurements of dynamic feature information for multiple geographic regions. In at least some embodiments, the dynamic feature information may be collected over multiple historical periods (training periods), which are also indicated in historical information 830. Static feature information for the geographic region is also used to train the model.

[0087] The feature determination module 850A determines features 860 based on this historical information 830. Generally, features 860 are a set of input information that are determined to predict a particular outcome. In some examples, features 860 include all historical activity data, while in other examples, features 860 include a subset of historical activity data.

[0088] It should be noted that some features may be initially provided at different resolutions. For example, in some embodiments, weather data is received in hexadecimal, road traffic is obtained as a location in two-dimensional space, air traffic information is obtained as a location in three-dimensional space, and some static features are provided on a grid. To aggregate this data, some embodiments perform noise attenuation for road traffic and air traffic (e.g., logarithm). Some embodiments apply linear weights to the features represented on the grid. Some embodiments aggregate different features for a given point of interest by an adjustable radius.

[0089] In some embodiments, the historical activity data used to train the model is adjusted to reduce multi-collinearity. In developing the disclosed embodiments, strong correlations between various features have been identified. As such, in some embodiments, one or more of principal component analysis (PCA) and recursive elimination are used to remove less relevant correlated features. These embodiments demonstrate significant performance improvements when compared to embodiments that do not operate to reduce multi-collinearity.

[0090] The machine learning algorithm 870 generates a model 806 (e.g., equivalent to the trained model 314 in some aspects) based on the features 860 and the labels. In the prediction module 820, current information 890 is input to the feature determination module 850B. The current information 890 may include dynamic and static feature information for a particular geographic region. The particular geographic region may or may not be included in the historical information 830.

[0091] Feature determination module 850B may determine the same set of features from current information 890 as feature determination module 850A determined from historical information 830, or it may determine a different set of features. In some examples, feature determination modules 850A and 850B are the same module. Feature determination module 850B generates a feature vector 815 that is input to model 806 to generate a volume prediction 895 for a geographic region. The volume prediction 895 includes predictions for multiple frequencies. In an exemplary embodiment, training module 810 may operate offline to train model 806, although prediction module 820 may be designed to operate online. Model 806 may be periodically updated with additional training and / or user feedback.

[0092] The machine learning algorithm 870 may be selected from among many different potential supervised or unsupervised machine learning algorithms. Examples of supervised learning algorithms include artificial neural networks, Bayesian networks, instance-based learning, support vector machines, decision trees (e.g., Iterative Dichotomiser 3 (ID3), C4.5, Classification and Regression Tree (CART), Chi-squared Automatic Interaction Detector (CHAID), etc.), random forests, linear classifiers, quadratic classifiers, k-nearest neighbors, linear regression, logistic regression, hidden Markov models, artificial life-based models, simulated annealing, and / or virology. Examples of unsupervised learning algorithms include expectation-maximization algorithms, vector quantization, and information bottleneck methods. An unsupervised model may not have a training module 810. In an exemplary embodiment, a regression model is used, and the model 806 is a vector of coefficients corresponding to the features 860 and the learned importance of each feature in the feature vector 815. To calculate the score, the dot product of the feature vector 815 (in some embodiments, features are not necessarily represented as vectors) and the vector of coefficients of the model 806 is taken.

[0093] In disclosed embodiments, a variety of features are used to train a noise prediction model. In an exemplary embodiment, these features include static and dynamic features of an area over multiple time periods. In some embodiments, time identifying a time period is provided in various formats, such as time since January 1, a concatenation of month, day, and hour, or a weekend or weekday indicator and a time indication for that day. In some embodiments, training inputs include static location features (e.g., elevation) and time-dependent dynamic location features (e.g., traffic volume). In some embodiments, inputs are location covariates (fixed and time-dependent) or location (e.g., longitude, latitude), time representations (e.g., time since January 1, 1970, month + day + hour, or in some embodiments, weekend / weekday indicators and / or time indications), or location covariates (fixed), time representations. Location covariates enable predictions at new locations. In some embodiments, the use of time-dependent covariates requires predicting covariate values ​​when predicting future noise levels. In various embodiments, the additional training inputs include one or more of traffic volume, traffic speed, temperature, dew point, humidity, wind speed, wind direction, precipitation intensity, barometric pressure, distance to a body of water (e.g., a waterway or lake), elevation, distance from a road, distance from a railway, distance from a coast, and distance from an airport. In some embodiments, the training set data generated by the measurement equipment described above with respect to FIG. 1 includes location (e.g., longitude and latitude) and time features (both dynamic and static features) and labels (SPL values ​​or one or more TVL spectral data). Some embodiments provide a noise measure in the form of L90. L90 is the highest sound level exceeded in 90% of the measurement period. Sound measurements in the form of L90 are commonly considered to represent the background or ambient level of noise in the measurement environment. A challenge in building a training set is mapping different data sets to the same location. Some data sources use random locations, some of which correspond to road segments.Weather data uses hexagonal identifiers, and NPS data uses longitude and latitude for a grid of points on a map a predetermined number of meters apart. Some of the disclosed embodiments include processes for integrating these different location systems to minimize data loss and improve efficiency.

[0094] In some of the disclosed embodiments, the model is trained using noise data collected from flight tracking information obtained from the Federal Aviation Administration (FAA). The flight tracking information allows for determining the distance between noise emitted by an aircraft and noise measurements made by sensors on the ground. In at least some embodiments, the flight tracking information is in the form of (x, y, z, t), where x, y, and z define the location of the aircraft in three-dimensional space (e.g., x, y are longitude, latitude, and z represents altitude in the form of AGL (altitude above ground level) or MSL (mean sea level)). In some embodiments, one or more noise measurements are quantified based on the noise impact due to air traffic, such as:

[0095] The normalized noise impact due to air traffic at time t is:

[0096]

number

[0097] In disclosed embodiments, for a given location and a given time (e.g., 1 hour), the trained model can predict sound pressure level (SPL) in dBA. This prediction produces a single value (a scalar). In disclosed embodiments, the same trained model can further predict time-varying loudness. In some embodiments, this prediction may include multiple values ​​(e.g., 150) represented as a vector. In various embodiments, predictions of SPL and VTL can also be obtained by using either separate models for each prediction or a single model with multiple outputs. One TVL model produced by the disclosed subject matter produces a RMSE of 3.39, R 2 The coefficient of determination is 0.69. In this embodiment, a decision tree-based model is used.

[0098] The values ​​of different TVL bands contain some correlation. For this reason, in some embodiments, the TVL spectral output of the model is represented as a vector, with each unit of the vector representing a 1 / 3 octave band (e.g., 32). Alternatively, a model for each TVL band can be trained separately. In exemplary embodiments, several types of models can be used, such as linear models (e.g., linear regression, logistic regression), support vector regression, random forest regression, Gaussian processes, free-base models, multilayer perceptrons (MLPs) / neural networks (NNs), or an ensemble of models.

[0099] 9 is a flowchart of a process 900 for processing training data before using it to train a model. In some aspects, process 900 is performed by hardware processing circuitry. For example, in some embodiments, instructions stored in electronic memory configure the hardware processing circuitry to perform one or more of the functions described below with respect to FIG. 9 and process 900.

[0100] After start operation 902, process 900 proceeds to operation 905. In operation 905, a radius is defined. In some embodiments, the radius is implemented as an adjustable parameter. The radius defines a distance from a sensor to search for related features (from other sensors).

[0101] The location of the sensor is determined in operation 910. In an exemplary embodiment, process 900 is applied iteratively to a set of sensors, where operation 910 determines the location of the sensor currently being analyzed by process 900.

[0102] In operation 915, a region is determined based on the location and the radius, which defines a circular region around the sensor location. In operation 920, feature data points within a region are identified. In some embodiments, the feature data points are aggregated to a single value for a particular location / time. In some embodiments, the following formula is used for aggregation, where region R i n points are identified in

[0103]

number

[0104] In operation 925, a weighted average is generated from the data points. In some embodiments, a principled weighting function is applied. In some embodiments, a negative exponential weight is used to approximate sound attenuation with distance. Thus, in some embodiments, for feature i at distance d from the sensor location, a weight of w i =1 / e αd This becomes: The alpha (α) value is based on environmental conditions within the region. Exemplary environmental conditions include whether the environment is primarily urban, suburban, or rural, the average height of buildings, etc. In some embodiments, an alpha (α) value of 2 is used.

[0105] In some other embodiments, one of the following weighting formulas is used:

[0106]

number

[0107]

number

[0108]

number

[0109]

number

[0110] One observation from the analysis of the training set described above is shown in Figure 10. Figure 10 shows a relatively strong correlation between sound pressure level (SPL) and traffic volume, given that SPL is higher during peak hours and generally lower at night.

[0111] 11 illustrates a correlation matrix of model features, according to one embodiment. Correlation matrix 1100 shows the correlation between traffic volume and speed (negative correlation) and the correlation between dew point and temperature (positive correlation). Correlation matrix 1100 also shows the correlation between speed and humidity.

[0112] To determine a suitable model for loudness prediction, several analyses were performed using a variety of different models. In the first test, a multiple linear regression model was trained using 70% of the training data for training and 30% of the training data for testing. The results are shown in Table 3 below.

[0113] [Table 3] The above metrics indicate that the linear regression model performed relatively well in predicting SPL. To understand how well the model predicted noise for time periods not included in the training data, another test was performed. To perform this test, the training data for the first time period was extracted from that used in training the model and then used to estimate the accuracy of the predictions the model would make for that first time period. The results are shown in Table 4 below.

[0114] [Table 4] The above analysis suggests that the model can accurately predict SPL even for periods that do not include training data.

[0115] 12A and 12B are flowcharts of a process 1200 for predicting time-varying background volume for multiple frequencies. In some aspects, one or more of the functions described below with respect to process 1200 and FIGS. 12A and 12B are performed by hardware processing circuitry. For example, in at least some embodiments, instructions stored in hardware memory configure the hardware processing circuitry to perform one or more of the functions described below. In some embodiments, one or more of the functions described below are performed by one or more of trained models 320 and / or routing system 323, both of which are described above with respect to FIG. 3.

[0116] After start operation 1205, process 1200 proceeds to operation 1210 where measurements of dynamic feature data for a geographic region are received. In some embodiments, the dynamic feature data includes weather data for the region. Examples of weather data include one or more of temperature, dew point, pressure, wind speed, wind direction, sun position, precipitation, snow accumulation rate, snow depth, and other weather data. Weather information is available from the National Weather Service in the United States via a web service. Similar services are available in other regions. In some embodiments, the weather data is received in operation 1210 by retrieving the weather data from a web service.

[0117] In some embodiments, the dynamic feature data includes noise information or artificial feature data related to man-made sources. Examples of artificial feature data include traffic speed and / or volume on one or more roads, aircraft speed, railroad speed, and / or traffic volume across an area. In some embodiments, the artificial feature data is received at least indirectly from one or more data sources. For example, current traffic data is available from various web services operated by local governments. Some embodiments of operation 1210 interface with these services to obtain information related to traffic data. Similarly, the Federal Aviation Administration (FAA) operates a web service that provides aircraft flight information. Similar services are also offered in regions outside the United States. Current rail traffic information is available through web services provided by rail operators. In at least some embodiments, operation 1210 accesses one or more of these services to obtain or receive the artificial dynamic feature data.

[0118] In an exemplary embodiment, dynamic feature data is measured and / or received for multiple different time periods in operation 1210. For example, in some aspects measurements are received periodically, such as every hour, every half hour, or other time period.

[0119] In operation 1212, static features of the geographic region are determined. Examples of static features include one or more of the following: elevation, distance from one or more roads, distance from one or more airports, percent vegetation of the region, road composition of the region (e.g., concrete, asphalt, or cobblestone), distance to a railroad, distance to a coast (ocean or Great Lakes), and distance to a body of water (e.g., a lake or waterway). As described above with respect to Figure 3, in some embodiments, operation 1212 retrieves static feature data from a static feature data store, such as static feature data store 316 described above with respect to Figure 3.

[0120] In operation 1215, the dynamic and static features are provided to the model. For example, FIG. 3 illustrates a data flow for providing dynamic features (e.g., dynamic feature data 322) and static feature information 324 to the trained model 314. In some embodiments, providing the dynamic and static features to the model includes the trained model retrieving the dynamic and static features from a source for this information, for example, as described above with respect to FIG. 3. As shown in FIG. 3, in some embodiments, the trained model retrieves static feature information for one or more geographic regions from a static feature data store 316. Dynamic feature data for the regions is also received by the trained model 320 (as dynamic feature data 322). As mentioned above, in some embodiments, the dynamic feature data is received from a web service that provides the dynamic feature data or directly from a sensor that measures the dynamic feature information. As described above with respect to FIGS. 3 and 8, or either of FIGS. 3 or 8, the model is trained based on historical data collected from multiple sensors that detect time-varying loudness across multiple frequencies in multiple geographic regions. Some of the sensors are configured to collect weather data, such as temperature, dew point, humidity, wind speed, wind direction, and other weather data, over multiple time periods. The detected time-varying sound volume and weather data are correlated according to the time the sound volume and weather information was collected. Thus, the historical data represents weather, traffic, and noise information for a particular area over multiple time periods.

[0121] In an exemplary embodiment, the historical data used to train the model also includes static features of the region. For example, some embodiments obtain static information for a plurality of different regions, such as the amount of vegetation in the region, the amount (e.g., percentage) of man-made structures (e.g., concrete, asphalt, buildings) in the region, or other static features as described above. In some embodiments, the static features used to train the model are obtained from a static feature data store, such as static feature data store 316 described above with respect to FIG. 3.

[0122] Then, in operation 1218, the background noise volume is predicted based on output from the trained model (e.g., trained model 320). The predicted background noise volume is specific to a specified time period, a geographic region, or any given location based on meteorological information for the region, static characteristics of the region, and dynamic characteristics of the region, one or more of which, in at least some embodiments, are provided as inputs to the model, as described above. In some embodiments, the specified time period is the "current time period" based on when the prediction is performed. In other embodiments, the specified time period is passed as input to the model, and the model is configured to generate a predicted background noise volume for the specified time period based on this input.

[0123] In operation 1218, the background noise volume is predicted for a specific time and a specific date within a specified time period. In some embodiments, the specific time and date, or the specific time or date, are passed as input to the model.

[0124] In operation 1220, noise map data is generated based on the model-predicted background noise loudness within the geographic region (as output by the trained model), where, for example, predicted loudness values ​​at multiple locations may be aggregated to generate a heat map (or other type of representation) representing loudness at locations within the geographic region for one or more times, time ranges, etc. In various embodiments, the predicted background noise loudness includes one or more of fixed, time-varying, fractional, and fractional specific noise loudness.

[0125] In some embodiments, generating the noise map data in operation 1220 includes generating predicted background noise levels for a plurality of geographic regions. In some embodiments, the plurality of geographic regions bound each other (e.g., in a grid orientation) to form a map of a portion of the Earth's surface. As such, the noise map data includes the plurality of geographic regions and their corresponding predicted background noise levels.

[0126] In operation 1222, one or more aircraft routes and / or airways for a region are determined based on the model-predicted volume and / or noise map data, where determining the location / altitude of the flight route (and associated airways) can maintain acceptable volume levels for the geographic region, as described herein.

[0127] In some embodiments of operation 1222, an origin and destination for the aircraft are determined. These embodiments then determine multiple possible routes between the origin and destination. Each of the multiple possible routes includes multiple different geographic regions through which the aircraft will travel as it travels from the origin to the destination. Some embodiments of process 1200 generate predicted background noise for each of these geographic regions based on the dynamic and static feature data for each of these regions. This information is provided to a trained model, which then predicts the background noise for each geographic region.

[0128] Some embodiments then select one of the multiple routes based on the predicted background noise. For example, some embodiments aggregate the predicted background noise along each route (e.g., based on the predicted background noise of each region the aircraft will pass through during the route) and select the route with the most noise aggregation. In some embodiments, prior to aggregating the noise along the route, the predicted background noise of the regions is set to a predetermined maximum value to limit selection bias due to particularly noisy regions.

[0129] As described above, some embodiments define flight routes that specify high altitudes when traveling over geographic regions with relatively low predicted background noise levels (e.g., noise below a predetermined threshold). These embodiments define flight routes that specify low altitudes when traveling over geographic regions with relatively high predicted background noise levels (e.g., above a predetermined threshold). Also, in some embodiments, the altitude of a region is based on the altitudes of adjacent regions along the route to avoid excessively frequent altitude changes along the route.

[0130] In operation 1224, one or more aircraft operational constraints are determined based on the predicted background volume and / or noise map data. For example, utilizing the predicted volume and / or noise map data, aircraft constraints are determined, including operational constraints such as takeoff time, in-flight travel time, landing time, first takeoff / landing time of the day, last takeoff / landing time of the day, takeoff angle / direction, landing approach angle, and / or other operational constraints. As an example of an aircraft constraint, in some embodiments, a minimum climb rate for an aircraft after takeoff is set based on the predicted background noise of one or more geographic regions the aircraft will fly over before reaching its cruising altitude. In some embodiments, a predetermined background noise below a predetermined noise threshold causes the minimum climb rate to exceed a first climb rate threshold. In these embodiments, if the predicted background noise of the region the aircraft will fly over before reaching its cruising altitude exceeds a second predetermined noise threshold, the minimum climb rate is set below a second climb rate threshold. In some embodiments, the first climb rate threshold and the second climb rate threshold are equivalent.

[0131] As another example, the maximum range attribute of an aircraft required for a route between an origin and a destination is constrained based on the distance from the origin to the destination along the selected route. As an example, some embodiments generate multiple different routes between the origin and the destination. In some cases, a longer route is selected, for example, to avoid a geographic area with relatively low background noise. Such longer routes require that the aircraft have sufficient range to cover the route.

[0132] In operation 1226, aircraft are assigned to routes based on the predicted background volume and / or noise map data. For example, as discussed above, constraints on an aircraft are determined based on a route selected for travel between an origin and a destination. In the example above regarding climb rate, an aircraft is selected to cover that route based on aircraft specifications indicating that the aircraft can climb at or above a minimum climb rate determined for the route (based, in some embodiments, on the predicted background noise level of one or more geographic areas over which the aircraft will fly while covering the route). Similarly, the aircraft must have a range that is equal to or greater than the distance between the origin and destination when covering the selected route.

[0133] As an additional example, a first route may include locations with higher predicted noise levels than a second route. An aircraft fleet may include a first aircraft and a second aircraft. The first aircraft may be a different make, model, type, etc. than the second aircraft. The first aircraft may emit a higher level of noise / volume during operation (e.g., takeoff, landing, flight, etc.) than the second aircraft. The first aircraft (a noisy aircraft) may be assigned to a first route (a noisy route) because the predicted background noise levels of locations along the first route are more compatible with the operation of the first aircraft. In this case, compatibility is determined by a balance between the predicted background noise levels of areas along the first route and the volume of the aircraft. The second aircraft (a quieter aircraft) may be assigned to a second route (a quieter route) because the predicted noise levels of locations along the second route are more compatible with the noise generated by the operation of the second aircraft.

[0134] In another example, a first aircraft can be assigned to a second route because locations along the second route may have higher acceptable levels of loudness. A second aircraft can be assigned to a first route because locations along the first route may have lower acceptable levels of loudness.

[0135] In operation 1228, a frequency of aircraft flight is determined based on the predicted background noise level and / or noise map data. For example, in at least some embodiments, the number of times the aircraft travels the first route and / or the second route is determined to maintain acceptable levels of background noise level at locations along these routes. For example, in some embodiments, the percentage of aircraft flight over a particular geographic area is limited. In some embodiments, this percentage is adjusted based on the time of day and / or whether it is a weekday or weekend. Also, in some embodiments, this percentage is adjusted based on the predicted background noise level.

[0136] After operation 1228, process 1200 proceeds to end operation 1230. FIG. 13 is a block diagram illustrating an example software architecture 1300 of a computing device. The software architecture 1302 may be adapted for use in conjunction with various hardware architectures, such as those described herein. FIG. 13 is merely a non-limiting example of the software architecture 1302, and many other architectures may be implemented that facilitate the functionality described herein. A representative hardware layer 1304 is shown, which may represent, for example, any of the computing devices described above. In some examples, the hardware layer 1304 may be implemented according to the architecture 1400 of FIG. 14 and / or the software architecture 1302 of FIG. 13.

[0137] The exemplary hardware layer 1304 includes one or more processing units 1306 having associated executable instructions 1308. The executable instructions 1308 represent executable instructions of the software architecture 1302, implementing the methods, modules, components, etc., of FIGS. 1-12. The hardware layer 1304 also includes memory and / or storage modules 1310 that also have the executable instructions 1308. The hardware layer 1304 may also include other hardware 1312, which represents any other hardware in the hardware layer 1302, such as other hardware shown as part of the software architecture 1300.

[0138] In the exemplary architecture of FIG. 13 , software architecture 1302 may be conceptualized as a layer stack, with each layer providing a specific function. For example, software architecture 1302 may include layers such as operating system 1314, libraries 1316, framework / middleware 1318, application 1320, and presentation layer 1344. Optionally, application 1320 and / or other components within a layer may make API calls 1324 through the software stack and receive responses, return values, etc., shown as messages 1326 in response to the API calls 1324. The layers shown are representative, and not all software architectures have all layers. For example, some mobile or dedicated operating systems may not provide a framework / middleware 1318 layer, while other operating systems may provide such a layer. Other software architectures may include additional or different layers.

[0139] The operating system 1314 may manage hardware resources and provide common services. The operating system 1314 may include, for example, a kernel 1328, services 1330, and drivers 1332. The kernel 1328 may act as an abstraction layer between the hardware layer and other software layers. For example, the kernel 1328 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security configuration, etc. The services 1330 may provide other common services to other software layers. In some examples, the services 1330 include an interrupt service. The interrupt service may detect the receipt of a hardware or software interrupt and, in response, cause the software architecture 1302 to suspend current processing and execute an ISR if an interrupt is received. The ISR may generate an alert.

[0140] Drivers 1332 may be responsible for controlling or interfacing with underlying hardware, such as a display driver, a camera driver, a Bluetooth driver, a flash memory driver, a serial communications driver (e.g., a Universal Serial Bus (USB) driver), a Wi-Fi driver, an NFC driver, an audio driver, a power management driver, etc., depending on the hardware configuration.

[0141] Libraries 1316 may provide a common infrastructure that applications 1320 and / or other components and / or layers can use. Libraries 1316 typically provide functions that allow other software modules to perform tasks more easily than by working directly with the underlying operating system 1314 functions (e.g., kernel 1328, services 1330, and / or drivers 1332). Libraries 1316 include system libraries 1334 (e.g., the C standard library), which may provide functions such as memory allocation, string manipulation, and mathematical functions. Libraries 1316 also include API libraries 1336, such as media libraries (e.g., libraries that support the presentation and manipulation of various media formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG), graphics libraries (e.g., the OpenGL framework, which can be used to render 2D and 3D graphical content to a display), database libraries (e.g., SQLite, which may provide various relational database functions), and web libraries (e.g., WebKit, which may provide web browsing functionality). Libraries 1316 also include a wide variety of other libraries 1338 that provide many other APIs to applications 1320 and other software components / modules.

[0142] The framework / middleware 1318 (sometimes referred to as middleware) may provide a high-level common infrastructure that the applications 1320 and / or other software components / modules can use. For example, the framework / middleware 1318 may provide various graphical user interface (GUI) functionality, high-level resource management, high-level location-based services, etc. The framework / middleware 1318 may provide a wide spectrum of other APIs that the applications 1320 and / or other software components / modules can use, some of which may be specific to a particular operating system or platform.

[0143] Applications 1320 include built-in applications 1340 and / or third-party applications 1342. Representative examples of built-in applications 1340 include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and / or a game application. Third-party applications 1342 include any of the built-in applications 1340 as well as a wide range of other applications. In a particular example, third-party applications 1342 (e.g., applications developed by entities other than the supplier of a particular platform using the Android® or iOS® Software Development Kit (SDK)) may be mobile software running on a mobile operating system such as iOS, Android, Windows® Phone, or other computing device operating system. In this example, third-party applications 1342 may make API calls 1324 provided by a mobile operating system such as operating system 1314 to facilitate the functionality described herein.

[0144] Applications 1320 may use built-in operating system facilities (e.g., kernel 1328, services 1330, and / or drivers 1332), libraries (e.g., system libraries 1334, API libraries 1336, and other libraries 1338), or frameworks / middleware 1318 to generate a user interface that interacts with a user of the system. Alternatively or additionally, some systems may interact with the user through a presentation layer, such as presentation layer 1344. In these systems, the "logic" of an application / module is separable from the aspects of the application / module that interact with the user.

[0145] Some software architectures use virtual machines. For example, the systems described herein may be implemented using one or more virtual machines running on one or more server computing devices. In the example of FIG. 13, this is illustrated by virtual machine 1348. The virtual machine creates a software environment in which applications / modules can be executed as if they were running on a hardware computing device. Virtual machine 1348 is hosted by a host operating system (e.g., operating system 1314) and typically (but not always) includes a virtual machine monitor 1346 that manages the operation of virtual machine 1348 as well as its interface with the host operating system (e.g., operating system 1314). The software architecture executes in virtual machine 1348, such as operating system 1350, libraries 1352, frameworks / middleware 1354, applications 1356, and / or presentation layer 1358. These layers of the software architecture executing in virtual machine 1348 may be the same as or different from the corresponding layers described above.

[0146] 14 is a block diagram illustrating a computing device hardware architecture 1400 that may cause a machine to perform any one of the example methods described herein upon execution of a set or sequence of instructions. Hardware architecture 1400 represents a computing device that executes the aircraft autonomy system described herein. In some embodiments, hardware architecture 1400 is utilized by one or more of untrained model 314, trained model 320, routing system 323, and / or UTM 108 described above. In some embodiments, one or more of untrained model 314, trained model 320, and routing system 323 are incorporated into a single computing device as represented by hardware architecture 1400. In some embodiments, untrained model 314, trained model 320, and routing system 323 are each implemented on different, physically separate computing devices, each including one or more of the components of hardware architecture 1400 described below. In some embodiments, one or more of the above-described functions resulting from one or more of the untrained models 314, the trained models 320, and / or the routing system 323 are performed by a shared group or "pool" of hardware devices, each of which includes one or more of the components described below with respect to FIG. 14.

[0147] The architecture 1400 may operate as a standalone device or may be connected (networked) to other machines. In a networked deployment, the architecture 1400 may operate in the capacity of a server or client machine in a server-client network environment, or may act as a peer machine in a peer-to-peer (or distributed) network environment. The architecture 1400 may be implemented in a personal computer (PC), tablet PC, hybrid tablet, set-top box (STB), personal digital assistant (PDA), mobile phone, web appliance, network router, network switch, network bridge, or any machine capable of executing instructions (sequential or otherwise) that specify the operations to be performed thereby.

[0148] The exemplary architecture 1400 includes a processor unit 1402 having at least one processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), both, a processor core, a compute node). The architecture 1400 may further include a main memory 1404 and a static memory 1406 that communicate with each other via a link 1408 (e.g., a bus). The architecture 1400 may further include a video display unit 1410, an input device 1412 (e.g., a keyboard), and a UI navigation device 1414 (e.g., a mouse). In some examples, the video display unit 1410, the input device 1412, and the UI navigation device 1414 are incorporated into a touchscreen display. The architecture 1400 may also include a memory device 1416 (e.g., a drive unit), a signal generating device 1418 (e.g., a speaker), a network interface device 1420, and one or more sensors (not shown), such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors.

[0149] In some examples, the processor unit 1402 or another suitable hardware component may support hardware interrupts in response to which the processor unit 1402 may suspend its processing and execute an ISR, for example, as described herein.

[0150] Storage device 1416 comprises a machine-readable medium 1422 having stored thereon one or more sets of data structures and instructions 1424 (e.g., software) for performing or using any one or more of the methods or functions described herein. Additionally, the instructions 1424, in whole or at least in part, may reside in main memory 1404, static memory 1406, and / or processor unit 1402 during execution by architecture 1400, with main memory 1404, static memory 1406, and processor unit 1402 similarly constituting machine-readable media.

[0151] [Executable Instructions and Machine Storage Media] Various memories (i.e., 1404, 1406, and / or memory of processor unit 1402) and / or storage device 1416 may store one or more sets of instructions and data structures (e.g., instructions) 1424 that are used to perform or be used by any one or more of the methods or functions described herein. These instructions, when executed by processor unit 1402, cause various operations to implement the disclosed examples.

[0152] As used herein, the terms “machine storage medium,” “device storage medium,” and “computer storage medium” (collectively “machine storage medium 1422”) mean the same thing and are used interchangeably in this disclosure. These terms refer to one or more storage devices and / or media (e.g., centralized or distributed databases and / or associated caches and servers) that store executable instructions and / or data, as well as a cloud-based storage system or storage network that includes multiple storage devices or appliances. Accordingly, these terms should be interpreted to include, but are not limited to, solid-state memory and optical and magnetic media, including memory internal or external to a processor. Specific examples of machine storage medium, computer storage medium, and / or device storage medium 1422 include semiconductor memory devices (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), FPGAs, and flash memory devices), magnetic disks such as internal hard disks and removable disks, magneto-optical disks, and non-volatile memory, including CD-ROM and DVD-ROM disks, by way of example. The terms machine storage media, computer storage media, and device storage media 1422 expressly exclude carrier waves, modulated data signals, and other such media, at least some of which are covered by the term "signal media" below.

[0153] [Signal medium] The terms "signal media" or "transmission media" shall be interpreted to include any form of modulated data signal, carrier wave, etc. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.

[0154] [Computer-readable medium] The terms "machine-readable medium," "computer-readable medium," and "device-readable medium" mean the same thing and can be used interchangeably in this disclosure. These terms are defined to include both machine storage media and signal media. Thus, these terms include both storage devices / media and carrier / modulated data signals.

[0155] The instructions 1424 may further be transmitted or received over a communications network 1426 using a transmission medium via the network interface device 1420 using any one of many well-known transfer protocols (e.g., HTTP). Examples of communications networks include a LAN, a WAN, the Internet, a cellular network, a Plain Old Telephone Service (POTS) network, and a wireless data network (e.g., a Wi-Fi, 3G, 4G LTE / LTE-A, 5G, or WiMAX network). The term "transmission medium" shall be interpreted to include any intangible medium capable of storing, encoding, or carrying machine-executable instructions, including digital or analog communications signals or other intangible media that facilitate communication of such software.

[0156] Throughout this specification, multiple instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of these individual operations may be performed simultaneously, and the operations need not be performed in the order illustrated. Structures and functions presented as separate components in example configurations may be implemented as combined structures or components. Similarly, structures and functions presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements are within the scope of the subject matter of this specification.

[0157] This disclosure describes various components as being configured in particular ways. The components may be configured in any suitable manner. For example, a component that is or includes a computing device may be configured by suitable software instructions that program the computing device. A component may also be configured by its hardware configuration or in any other suitable manner.

[0158] The above description is intended to be illustrative and not limiting. For example, the above-described example (or one or more aspects thereof) can be used in combination with other examples. Other examples can also be used, such as by those skilled in the art, upon review of the above description. The Abstract allows the reader to quickly grasp the nature of the technical disclosure. It is presented with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.

[0159] The detailed description may also simplify the disclosure by incorporating various features. However, the claims may not recite all features disclosed herein, as multiple examples may characterize a subset of the features. Moreover, multiple examples may include fewer features than those disclosed in a particular example. Thus, the following claims are incorporated by reference into the detailed description, with each claim standing on its own as a separate example. The scope of the examples disclosed herein should be determined by reference to the appended claims, along with the full range of equivalents to which such claims are entitled.

[0160] Example 1 is a system comprising a hardware processing circuit and one or more hardware memories storing instructions that, when executed, configure the hardware processing circuit to perform operations including receiving measurements of dynamic feature data of a geographical area, determining static features of the geographical area, and generating a predicted background noise volume in the geographical area during a specified period of time using a model trained on training data including historical measurements of the dynamic feature data of a plurality of areas and static features of the plurality of areas over a plurality of training periods, wherein the geographical area is not included in the plurality of areas and the specified period occurs after the plurality of training periods.

[0161] In Example 2, the subject matter of Example 1 optionally includes generating the predicted background noise volume by predicting background noise volume at a specific time and date within the specified time period, and the historical measurements of the dynamic feature data are correlated with the times and dates of the historical measurements.

[0162] In Example 3, any one or more of the subject matter of Examples 1 and 2, wherein the operations further include determining a route for the aircraft based on the predicted background noise volume in the geographic region.

[0163] In Example 4, any of the subject matters of Example 3, wherein the operations further include predicting a first background noise volume in a first region during a time period based on the model; predicting a second background noise volume in a second region during the time period based on the model; determining that the first background noise volume is higher than the second background noise volume; and, in response to the determination, routing the aircraft through the first region during the time period.

[0164] In Example 5, optionally in the subject matter of any one or more of Examples 1 to 4, the operations further include: generating a predicted background noise volume for each of a plurality of regions in a map based on a model; identifying an origin and destination of an aircraft; identifying a plurality of routes from the origin to the destination, each of the plurality of routes including at least one of the plurality of regions in the map; comparing the predicted background noise volume for at least one region of the plurality of regions included in a first route of the plurality of routes with the predicted background noise volume for at least one region of the plurality of regions included in a second route of the plurality of routes; selecting the first route or the second route based on the comparison; and routing the aircraft on the selected route.

[0165] In Example 6, the subject matter of Example 5 is optionally further characterized in that the operations further include aggregating predicted background noise volumes for areas included in the first route and aggregating predicted background noise volumes for areas included in the second route, and selecting the first route or the second route is based on the first aggregation and the second aggregation.

[0166] In Example 7, optionally in the subject matter of any one or more of Examples 5 and 6, the operations further include determining a minimum expected background noise level along the selected route, comparing the minimum expected background noise level to a noise threshold, and determining an altitude of the aircraft along the selected route to exceed a predetermined altitude in response to the minimum expected background noise level being below the noise threshold.

[0167] Example 8 is a non-transitory computer-readable storage medium comprising instructions that, when executed, configure a hardware processing circuit to perform operations including receiving measurements of dynamic feature data for a geographical region; determining static features of the geographical region; and generating a predicted background noise volume in the geographical region during a specified period of time using a model trained on training data including historical measurements of the dynamic feature data of a plurality of regions and the static features of the plurality of regions over a plurality of training periods, wherein the geographical region is not included in the plurality of regions and the specified period occurs after the plurality of training periods, generating the predicted background noise volume.

[0168] In Example 9, the subject matter of Example 8 optionally includes the operations further comprising determining a route for the aircraft based on the predicted background noise volume in the geographic region. In Example 10, any of the subject matters of Example 9, wherein the operations further include predicting a first background noise volume in a first region during a time period based on the model; predicting a second background noise volume in a second region during the time period based on the model; determining that the first background noise volume is higher than the second background noise volume; and, in response to the determination, routing the aircraft through the first region during the time period.

[0169] In Example 11, optionally in the subject matter of any one or more of Examples 8-10, the operations further include: generating a predicted background noise volume for each of a plurality of regions in a map based on a model; identifying an origin and destination of an aircraft; identifying a plurality of routes from the origin to the destination, each of the plurality of routes including at least one of the plurality of regions in the map; comparing the predicted background noise volume for at least one region of the plurality of regions included in a first route of the plurality of routes with the predicted background noise volume for at least one region of the plurality of regions included in a second route of the plurality of routes; selecting the first route or the second route based on the comparison; and routing the aircraft on the selected route.

[0170] In Example 12, the subject matter of Example 11 is optionally further characterized in that the operations further include aggregating predicted background noise volumes of areas included in the first route and aggregating predicted background noise volumes of areas included in the second route, and selecting the first route or the second route is based on the first aggregation and the second aggregation.

[0171] In Example 13, optionally in the subject matter of any one or more of Examples 11 and 12, the operations further include determining a minimum predicted background noise level along the selected route, comparing the minimum predicted background noise level to a noise threshold, and determining an altitude of the aircraft along the selected route to exceed a predetermined altitude in response to the minimum predicted background noise level being below the noise threshold.

[0172] Example 14 is a method executed by a hardware processing circuit, comprising: receiving measurements of dynamic feature data of a geographical area; determining static features of the geographical area; and generating a predicted background noise volume in the geographical area during a specified period of time using a model trained on training data including historical measurements of the dynamic feature data of a plurality of areas and the static features of the plurality of areas over a plurality of training periods, wherein the geographical area is not included in the plurality of areas and the specified period occurs after the plurality of training periods, wherein the method generates the predicted background noise volume.

[0173] In Example 15, the subject matter of Example 14 optionally includes generating the predicted background noise volume by predicting the background noise volume at a specific time and date within the specified period, and the historical measurements of the dynamic feature data are correlated with the time and date of the historical measurements.

[0174] In Example 16, the subject matter of any one or more of Examples 14 and 15 optionally includes determining an aircraft route based on the predicted background noise volume in the geographic region.

[0175] In Example 17, the subject matter of Example 16 optionally includes predicting a first background noise volume in a first region during a time period based on the model; predicting a second background noise volume in a second region during the time period based on the model; determining that the first background noise volume is higher than the second background noise volume; and, in response to the determination, routing the aircraft through the first region during the time period.

[0176] Example 18 optionally includes the subject matter of any one or more of Examples 14 to 17, further including: generating a predicted background noise volume for each of a plurality of regions in a map based on a model; identifying an origin and destination of an aircraft; identifying a plurality of routes from the origin to the destination, each of the plurality of routes including at least one of the plurality of regions in the map; comparing the predicted background noise volume for at least one region of the plurality of regions included in a first route of the plurality of routes with the predicted background noise volume for at least one region of the plurality of regions included in a second route of the plurality of routes; selecting the first route or the second route based on the comparison; and routing the aircraft on the selected route.

[0177] In Example 19, the subject matter of Example 18 optionally further includes aggregating predicted background noise volumes for areas included in the first route and aggregating predicted background noise volumes for areas included in the second route, and selecting the first route or the second route is based on the first aggregation and the second aggregation.

[0178] In Example 20, the subject matter of any one or more of Examples 18 and 19 optionally includes determining a minimum expected background noise level along the selected route; comparing the minimum expected background noise level to a noise threshold; and, in response to the minimum expected background noise level being below the noise threshold, determining an altitude of the aircraft along the selected route to exceed a predetermined altitude.

Claims

1. 1. A computer-implemented method for aircraft routing, the computer-implemented method comprising: accessing static feature data and dynamic feature data relating to a geographic region, the dynamic feature data being captured via one or more sensors associated with the geographic region; calculating a predicted background noise volume for the geographic region based on the static feature data and the dynamic feature data using a model; calculating a route for the aircraft based on the predicted background noise level in the geographic region; calculating an airway based on the route, the airway defining a volume around the route within which the aircraft will remain so as to maintain acceptable noise levels while within the geographic region; selecting a particular aircraft from among a plurality of aircraft for the route and the airway, wherein selecting the particular aircraft is based on one or more performance characteristics of the predicted background noise volume and the particular aircraft; routing the aircraft through the geographic region based on the aircraft route and the airway; 11. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, further comprising calculating one or more operational constraints associated with the route based on the predicted background noise volume, the one or more operational constraints indicating at least one of (i) a takeoff maneuver or (ii) a landing maneuver associated with the route.

3. 2. The computer-implemented method of claim 1, further comprising calculating a frequency of a number of flights to be assigned to one of (i) the route or (ii) the airway based on the predicted background noise volume.

4. The computer-implemented method of claim 1 , wherein calculating the air route further comprises calculating an altitude associated with the air route based on the predicted background noise volume.

5. The computer-implemented method of claim 1 , wherein the static feature data indicates at least one of: (i) distance from one or more roads; or (ii) distance from one or more airports.

6. The computer-implemented method of claim 1 , wherein the dynamic feature data indicates at least one of (i) weather, or (ii) sound level, or (iii) traffic associated with the geographic region.

7. The computer-implemented method comprises: accessing map data, the map data comprising at least one of (i) locations of other aircraft or (ii) locations of one or more landing zones within the geographic region; routing the aircraft through the geographic region also based on the map data; The computer-implemented method of claim 1 , further comprising:

8. 1. A computing system, comprising: one or more processors; one or more non-transitory computer-readable media having instructions stored thereon; Equipped with the instructions are executable by the one or more processors to cause the computing system to perform actions; The operation is accessing static feature data and dynamic feature data relating to a geographic region, the dynamic feature data being captured via one or more sensors associated with the geographic region; calculating a predicted background noise volume for the geographic region based on the static feature data and the dynamic feature data using a model; calculating a route for the aircraft based on the predicted background noise level in the geographic region; calculating an airway based on the route, the airway defining a volume around the route within which the aircraft will remain so as to maintain acceptable noise levels while within the geographic region; selecting a particular aircraft from among a plurality of aircraft for the route and the airway, wherein selecting the particular aircraft is based on one or more performance characteristics of the predicted background noise volume and the particular aircraft; routing the aircraft through the geographic region based on the aircraft route and the airway; a computing system including:

9. 10. The computing system of claim 8, wherein the operations further include calculating one or more operational constraints associated with the route based on the predicted background noise volume, the one or more operational constraints indicating at least one of (i) a takeoff maneuver or (ii) a landing maneuver associated with the route.

10. 9. The computing system of claim 8, wherein the operations further include calculating a frequency of a number of flights to be assigned to one of (i) the route or (ii) the airway based on the predicted background noise volume.

11. The computing system of claim 8 , wherein calculating the air route further comprises calculating an altitude associated with the air route based on the predicted background noise volume.

12. The computing system of claim 8 , wherein the static feature data indicates at least one of: (i) distance from one or more roads; or (ii) distance from one or more airports.

13. The computing system of claim 8 , wherein the dynamic feature data is indicative of at least one of (i) weather, or (ii) sound level, or (iii) traffic associated with the geographic region.

14. The operation is accessing map data, the map data comprising at least one of (i) locations of other aircraft or (ii) locations of one or more landing zones within the geographic region; routing the aircraft through the geographic region also based on the map data; The computing system of claim 8 further comprising:

15. a non-transitory computer-readable medium having instructions stored thereon, the instructions being executable by one or more processors to perform operations; The operation is accessing static feature data and dynamic feature data relating to a geographic region, the dynamic feature data being captured via one or more sensors associated with the geographic region; calculating a predicted background noise volume for the geographic region based on the static feature data and the dynamic feature data using a model; calculating a route for the aircraft based on the predicted background noise level in the geographic region; calculating an airway based on the route, the airway defining a volume around the route within which the aircraft will remain so as to maintain acceptable noise levels while within the geographic region; selecting a particular aircraft from among a plurality of aircraft for the route and the airway, wherein selecting the particular aircraft is based on one or more performance characteristics of the predicted background noise volume and the particular aircraft; routing the aircraft through the geographic region based on the aircraft route and the airway; a non-transitory computer-readable medium,

16. 16. The non-transitory computer-readable medium of claim 15, wherein the operations further include calculating one or more operational constraints associated with the route based on the predicted background noise volume, the one or more operational constraints indicating at least one of (i) a takeoff maneuver or (ii) a landing maneuver associated with the route.

17. 16. The non-transitory computer-readable medium of claim 15, wherein the operations further include calculating a frequency of a number of flights to be assigned to one of (i) the route or (ii) the airway based on the predicted background noise volume.

18. 16. The non-transitory computer-readable medium of claim 15, wherein calculating the air route further comprises calculating an altitude associated with the air route based on the predicted background noise volume.

19. 16. The non-transitory computer-readable medium of claim 15, wherein the static feature data indicates at least one of (i) distance from one or more roads or (ii) distance from one or more airports.

20. 16. The non-transitory computer-readable medium of claim 15, wherein the dynamic feature data indicates at least one of (i) weather, or (ii) sound level, or (iii) traffic associated with the geographic region.

Images