Patent Description:
Various embodiments of the present disclosure relate generally to obstacle detection and database management and, more particularly, to obstacle detection and database management using multi-source weightages.

Aircraft, such as urban air mobility (UAM) vehicles, need to navigate in complex environments and avoid obstacles and terrain. Such navigation is necessary to maintain safety and efficient route planning. For instance, onboard terrain awareness and warning systems use databases (e.g., obstacle and terrain databases) to avoid obstacles and terrain. The databases may be updated and released periodically by database suppliers. As the environments UAM vehicles operate in are constantly changing, new obstacles may be encountered between database release periods. Terrain awareness and warning systems may not issue alerts for such obstacles, as the database may not include the obstacle encountered. Therefore, there are flight safety risks associated with new obstacles, as only direct sensing (e.g., visual detection by a pilot or by automated systems onboard the vehicle) of the obstacle may enable the terrain awareness and warning systems to alert and avoid the new obstacle.

<CIT> describes methods, systems, and non-transitory computer-readable medium for managing data from vehicles.

<CIT> describes an automated detection and avoidance system that provides a pilot with high-fidelity knowledge of the aircraft's physical state, and notifies the pilot of any deviations in expected state based on predictive models.

<CIT> discloses an imaging component for use by an unmanned aerial vehicle ("UAV") for object detection. As described, the imaging component includes one or more cameras that are configured to obtain images of a scene using visible light that are converted into a depth map (e.g., stereo image) and one or more other cameras that are configured to form images, or thermograms, of the scene using infrared radiation ("IR"). The depth information and thermal information are combined to form a representation of the scene based on both depth and thermal information.

<CIT> discloses A method and a system for detecting wire or wire-like obstacles, which method and system are designed for an aircraft. The system for detecting wire or wire-like obstacles comprises a detection device, such as a video camera or a LIDAR device, a computer and a display device. The method includes a step of detecting at least one pylon in the surrounding environment of the aircraft via a detection device, a step of identifying a family of pylons to which each detected pylon corresponds, a step of characterizing at least one cable supported by the at least one detected pylon, and a step of determining a prohibited zone that can potentially contain each pylon and each cable and a safe zone not containing either a pylon or a cable. The prohibited zone and the safe zone may be displayed on the display device.

Moreover, transmission of database updates may consume communication bandwidth and updates to databases (e.g., additions for new obstacles) may consume scarce onboard storage resources. Therefore, conservation of communication bandwidth (and cost associated therewith) and onboard storage capacity may be an additional challenge.

Additionally, as the environment is constantly changing, navigation may be inefficient (e.g., take longer or go further). Therefore, there may be an additional challenge to provide efficient navigation.

The present disclosure is directed to overcoming one or more of these above-referenced challenges.

The invention is defined in the independent claims, to which reference should now be made. Advantageous features are set out in the dependent claims.

The invention relates to a system according to appended claim <NUM>.

Various embodiments of the present disclosure relate generally to obstacle detection and database management. Generally, as referred to in this disclosure, with respect to terrain awareness systems (as opposed to detect and avoid systems to avoid cooperative or non-cooperative aircraft), "objects" are environmental entities (e.g., 3D structures including buildings, structures, terra, fauna, flora, etc.) sensed outside a vehicle of reference, while "obstacles" are "objects" that have been confirmed to exist and have a corresponding set of parameters (location, shape, size, geometry, features, etc.).

In general, the present disclosure is directed to obstacle detection and database management using multi-source weightages. For instance, a vehicle (e.g., a UAV aircraft) can detect a new object (by comparing a detected object to known objects in an obstacle database) and report the new object to a cloud service (or off-board service). The cloud service can check for any other instances of this object being reported before (e.g., by another vehicle or by the vehicle on a previous flight) and determine a weightage using every instance of the object. The cloud service may then transmit a message to alert local vehicles of the object (e.g., update an onboard copy of the obstacle database to include the new object), so that the local vehicles may navigate safely with respect to the new object. Therefore, vehicles may reduce risk associated with the new objects that are not included in the obstacle database, by detecting the new object and sharing the information at least amongst local vehicles.

Moreover, as only the local vehicles may be alerted of the new object, communication bandwidth and onboard storage for non-local vehicles is conserved. In one aspect of the disclosure, when a weightage is high enough (e.g., the cloud service is highly confident regarding an object) the cloud service may inform the obstacle database provider, so that all vehicles may receive an update including the new object. In this manner, only when an object is confirmed (by a high weightage, such as above a threshold), are communication bandwidth and onboard storage consumed.

Additionally, the vehicles may use the weightages of obstacles and objects (determined by the cloud service) to display differentiated indicators to users and/or perform differentiated flight planning or navigation actions. Displaying differentiated indicators (e.g., a first color for confirmed obstacles, and a second color for objects) may inform users (e.g., pilots) to improve situational awareness, thereby increasing efficiency and safety. Performing differentiated flight planning or navigation based on the weightages, may enable the vehicles to plan routes/navigate routes faster with respect/closer to confirmed obstacles (as a location, size, shape, geometry is known), while the vehicles may plan routes/navigate routes slower with respect to/farther away from objects (as the exact location, size, shape, geometry is not known to a high degree of confidence). In this manner, vehicles may provide more efficient navigation (e.g., shorter distance, faster speed, and/or lower overall travel time) by using weightages of obstacles/objects.

While this disclosure describes the systems and methods with reference to aircraft, it should be appreciated that the present systems and methods are applicable to management of vehicles, including those of drones, automobiles, ships, or any other autonomous and/or Internet-connected vehicle.

As shown in <FIG> depicts an example environment in which methods, systems, and other aspects of the present disclosure may be implemented. The environment of <FIG> may include an airspace <NUM> and one or more hubs <NUM>-<NUM>. A hub, such as any one of <NUM>-<NUM>, may be a ground facility where aircraft may take off, land, or remain parked (e.g., airport, vertiport, heliport, vertistop, helistop, temporary landing/takeoff facility, or the like). The airspace <NUM> may accommodate aircraft of various types <NUM>-<NUM> (collectively, "aircraft <NUM>" unless indicated otherwise herein), flying at various altitudes and via various routes <NUM>. An aircraft, such as any one of aircraft 131a-133b, may be any apparatus or vehicle of air transportation capable of traveling between two or more hubs <NUM>-<NUM>, such as an airplane, a vertical take-off and landing aircraft (VTOL), a drone, a helicopter, an unmanned aerial vehicle (UAV), a hot-air balloon, a military aircraft, etc. Any one of the aircraft 131a-133b may be connected to one another and/or to one or more of the hubs <NUM>-<NUM>, over a communication network, using a vehicle management computer corresponding to each aircraft or each hub. Each vehicle management computer may comprise a computing device and/or a communication device, as described in more detail below in <FIG> and <FIG>. As shown in <FIG>, different types of aircraft that share the airspace <NUM> are illustrated, which are distinguished, by way of example, as model <NUM> (aircraft 131a and 131b), model <NUM> (aircraft 132a, 132b, and 132c), and model <NUM> (aircraft 133a and 133b).

As further shown in <FIG>, an airspace <NUM> may have one or more weather constraints <NUM>, spatial restrictions <NUM> (e.g., buildings), and temporary flight restrictions (TFR) <NUM>. These are exemplary factors that a vehicle management computer of an aircraft may be required to consider and/or analyze in order to derive the most safe and optimal flight trajectory of the aircraft. For example, if a vehicle management computer of an aircraft planning to travel from hub <NUM> to hub <NUM> predicts that the aircraft may be affected by an adverse weather condition, such as weather constraint <NUM>, in the airspace, the vehicle management computer may modify a direct path (e.g., the route <NUM> between hub <NUM> and hub <NUM>) with a slight curvature away from the weather constraint <NUM> (e.g., a northward detour) to form a deviated route <NUM>. For instance, the deviated route <NUM> may ensure that the path and the time of the aircraft (e.g., <NUM>-D coordinates of the flight trajectory) do not intersect any position and time coordinates of the weather constraint <NUM> (e.g., <NUM>-D coordinates of the weather constraint <NUM>).

As another example, the vehicle management computer of aircraft 131b may predict, prior to take-off, that spatial restriction <NUM>, caused by buildings, would hinder the direct flight path of aircraft 131b flying from hub <NUM> to hub <NUM>, as depicted in <FIG>. In response to that prediction, the vehicle management computer of aircraft 131b may generate a <NUM>-D trajectory with a vehicle path that bypasses a <NUM>-dimensional zone (e.g., zone including the location and the altitude) associated with those particular buildings. As yet another example, the vehicle management computer of aircraft 133b may predict, prior to take-off, that TFR <NUM>, as well as some potential <NUM>-D trajectories of another aircraft 132c, would hinder or conflict with the direct flight path of aircraft 133b, as depicted in <FIG>. In response, the vehicle management computer of aircraft 133b may generate a <NUM>-D trajectory with path and time coordinates that do not intersect either the <NUM>-D coordinates of the TFR <NUM> or the <NUM>-D trajectory of the other aircraft 132c. In this case, the TFR <NUM> and collision risk with another aircraft 132c are examples of dynamic factors which may or may not be in effect, depending on the scheduled time of travel, the effective times of TFR, and the path and schedule of the other aircraft 132c. As described in these examples, the <NUM>-D trajectory derivation process, including any modification or re-negotiation, may be completed prior to take-off of the aircraft.

As another example, the vehicle management computer of aircraft 131b may determine to use one of the routes <NUM> that are set aside for aircraft <NUM> to use, either exclusively or non-exclusively. The aircraft 131b may generate a <NUM>-D trajectory with a vehicle path that follows one of the routes <NUM>.

As indicated above, <FIG> is provided merely as an example environment of an airspace that includes exemplary types of aircraft, hubs, zones, restrictions, and routes. Regarding particular details of the aircraft, hubs, zones, restrictions, and routes, other examples are possible and may differ from what was described with respect to <FIG>. For example, types of zones and restrictions which may become a factor in trajectory derivation, other than those described above, may include availability of hubs, reserved paths or sky lanes (e.g., routes <NUM>), any ground-originating obstacle which extends out to certain levels of altitudes, any known zones of avoidance (e.g., noise sensitive zones), air transport regulations (e.g., closeness to airports), etc. Any factor that renders the <NUM>-D trajectory to be modified from the direct or the shortest path between two hubs may be considered during the derivation process.

<FIG> depicts an exemplary a system, according to one or more embodiments. The system <NUM> depicted in <FIG> may include one or more aircraft, such as aircraft <NUM>, one or more intruder aircraft <NUM>, a cloud service <NUM>, one or more communications station(s) <NUM>, and/or one or more ground station(s) <NUM>. The one or more aircraft <NUM> may be traveling from a first hub (e.g., hub <NUM>) to a second hub (e.g., hub <NUM>) along a route of routes <NUM>. Between, near, and/or on hubs, such as hubs <NUM>-<NUM>, the one or more ground station(s) <NUM> may be distributed (e.g., evenly, based on traffic considerations, etc.) along/near/on/under routes <NUM>. Between, near, and/or on hubs, such as hubs <NUM>-<NUM>, the one or more communications station(s) <NUM> may be distributed (e.g., evenly, based on traffic considerations, etc.). Some (or all) of the one or more ground station(s) <NUM> may be paired with a communication station <NUM> of the one or more communications station(s) <NUM>.

Each of the one or more ground station(s) <NUM> may include a transponder system, a radar system, and/or a datalink system.

The radar system of a ground station <NUM> may include a directional radar system. The directional radar system may be pointed upward (e.g., from ground towards sky) and the directional radar system may transmit a beam <NUM> to provide three-dimensional coverage over a section of a route <NUM>. The beam <NUM> may be a narrow beam. The three-dimensional coverage of the beam <NUM> may be directly above the ground station <NUM> or at various skewed angles (from a vertical direction). The directional radar system may detect objects, such as aircraft <NUM>, within the three-dimensional coverage of the beam <NUM>. The directional radar system may detect objects by skin detection. In the case of the ground station <NUM> being positioned on a hub, such as the hub <NUM>, the directional radar system may transmit a beam <NUM> to provide three-dimensional coverage over the hub <NUM>. The beam <NUM> may be also be skewed at an angle (from a vertical direction) to detect objects arriving at, descending to, and landing on the hub <NUM>. The beams <NUM>/<NUM> may be controlled either mechanically (by moving the radar system), electronically (e.g., phased arrays), or by software (e.g., digital phased array "DAPA" radars), or any combination thereof.

The transponder system of a ground station <NUM> may include an ADS-B and/or a Mode S transponder, and/or other transponder system (collectively, interrogator system). The interrogator system may have at least one directional antenna. The directional antenna may target a section of a route <NUM>. For instance, targeting the section of the route <NUM> may reduce the likelihood of overwhelming the ecosystem (e.g., aircraft <NUM>) with interrogations, as would be the case if the interrogator system used an omnidirectional antenna. The directional antenna may target a specific section of a route <NUM> by transmitting signals in a same or different beam pattern as the beam <NUM>/<NUM> discussed above for the radar system. The interrogator system may transmit interrogation messages to aircraft, such as aircraft <NUM>, within the section of the route <NUM>. The interrogation messages may include an identifier of the interrogator system and/or request the aircraft, such as aircraft <NUM>, to transmit an identification message. The interrogator system may receive the identification message from the aircraft, such as aircraft <NUM>. The identification message may include an identifier of the aircraft and/or transponder aircraft data (e.g., speed, position, track, etc.) of the aircraft.

If the radar system detects an object and the transponder system does not receive a corresponding identification message from the object (or does receive an identification message, but it is an invalid identification message, e.g., an identifier of un-authorized aircraft), the ground station <NUM> may determine that the object is an intruder aircraft <NUM>. The ground station <NUM> may then transmit an intruder alert message to the cloud service <NUM>. If the radar system detects an object and the transponder system receives a corresponding identification message from the object, the ground station <NUM> may determine the object is a valid aircraft. The ground station <NUM> may then transmit a valid aircraft message to the cloud service <NUM>. Additionally or alternatively, the ground station <NUM> may transmit a detection message based on the detection of the object and whether the ground station <NUM> receives the identification message ("a response message"); therefore, the ground station <NUM> may not make a determination as to whether the detected object is an intruder aircraft or a valid aircraft, but instead send the detection message to the cloud service <NUM> for the cloud service <NUM> to determine whether the detected object is an intruder aircraft or a valid aircraft.

The datalink system of ground station <NUM> may communicate with at least one of the one or more communications station(s) <NUM>. Each of the one or more communications station(s) <NUM> may communicate with at least one of the one or more ground station(s) <NUM> within a region around the communications station <NUM> to receive and transmit data from/to the one or more ground station(s) <NUM>. Some or none of the communications station(s) <NUM> may not communicate directly with the ground station(s) <NUM>, but may instead be relays from other communications station(s) <NUM> that are in direct communication with the ground station(s) <NUM>. For instance, each of the ground station(s) <NUM> may communicate with a nearest one of the communications station(s) <NUM> (directly or indirectly). Additionally or alternatively, the ground station(s) <NUM> may communicate with a communications station <NUM> that has a best signal to the ground station <NUM>, best bandwidth, etc. The one or more communications station(s) <NUM> may include a wireless communication system to communicate with the datalink system of ground station(s) <NUM>. The wireless communication system may enable cellular communication, in accordance with, e.g., <NUM>/<NUM>/<NUM> standards. The wireless communication system may enable Wi-Fi communications, Bluetooth communications, or other short range wireless communications. Additionally or alternatively, the one or more communications station(s) <NUM> may communicate with the one or more of the one or more ground station(s) <NUM> based on wired communication, such as Ethernet, fiber optic, etc..

For instance, a ground station <NUM> may transmit an intruder alert message or a valid aircraft message (and/or a detection message) to a communications station <NUM>. The communications station <NUM> may then relay the intruder alert message or the valid aircraft message (and/or the detection message) to the cloud service <NUM> (either directly or indirectly through another communications station <NUM>).

The one or more communications station(s) <NUM> may also communicate with one or more aircraft, such as aircraft <NUM>, to receive and transmit data from/to the one or more aircraft. For instance, one or more communications station(s) <NUM> may relay data between the cloud service <NUM> and a vehicle, such as aircraft <NUM>.

The cloud service <NUM> may communicate with the one or more communications station(s) <NUM> and/or directly (e.g., via satellite communications) with aircraft, such as aircraft <NUM>. The cloud service <NUM> may provide instructions, data, and/or warnings to the aircraft <NUM>. The cloud service <NUM> may receive acknowledgements from the aircraft <NUM>, aircraft data from the aircraft <NUM>, and/or other information from the aircraft <NUM>. For instance, the cloud service <NUM> may provide, to the aircraft <NUM>, weather data, traffic data, landing zone data for the hubs, such as hubs <NUM>-<NUM>, updated obstacle data, flight plan data, etc. The cloud service <NUM> may also provide software as a service (SaaS) to aircraft <NUM> to perform various software functions, such as navigation services, Flight Management System (FMS) services, etc., in accordance with service contracts, API requests from aircraft <NUM>, etc..

<FIG> and <FIG> depict exemplary block diagrams of a vehicle of a system, according to one or more embodiments. <FIG> may depict a block diagram 300A and <FIG> may depict a block diagram 300B, respectively, of a vehicle, such as aircraft <NUM>-<NUM>. Generally, the block diagram 300A may depict systems, information/data, and communications between the systems of a piloted or semi-autonomous vehicle, while the block diagram 300B may depict systems, information/data, and communications between the systems of a fully autonomous vehicle. The aircraft <NUM> may be one of the piloted or semi-autonomous vehicle and/or the fully autonomous vehicle.

The block diagram 300A of an aircraft <NUM> may include a vehicle management computer <NUM> and electrical, mechanical, and/or software systems (collectively, "vehicle systems"). The vehicle systems may include: one or more display(s) <NUM>; communications systems <NUM>; one or more transponder(s) <NUM>; pilot/user interface(s) <NUM> to receive and communicate information from pilots and/or users <NUM> of the aircraft <NUM>; edge sensors <NUM> on structures <NUM> of the aircraft <NUM> (such as doors, seats, tires, etc.); power systems <NUM> to provide power to actuation systems <NUM>; camera(s) <NUM>; GPS systems <NUM>; on-board vehicle navigation systems <NUM>; flight control computer <NUM>; and/or one or more data storage systems. The vehicle management computer <NUM> and the vehicle systems may be connected by one or a combination of wired or wireless communication interfaces, such as TCP/IP communication over Wi-Fi or Ethernet (with or without switches), RS-<NUM>, ARINC-<NUM>, or other communication standards (with or without protocol switches, as needed).

The vehicle management computer <NUM> may include at least a network interface, a processor, and a memory, each coupled to each other via a bus or indirectly via wired or wireless connections (e.g., Wi-Fi, Ethernet, parallel or serial ATA, etc.). The memory may store, and the processor may execute, a vehicle management program. The vehicle management program may include a weather program <NUM>, a Detect/See & Assisted Avoidance (D/S & A) program <NUM>, a flight routing program <NUM>, a vehicle status/health program <NUM>, a communications program <NUM>, a flight control program <NUM>, and/or a vertiport status program <NUM> (collectively, "sub-programs"). The vehicle management program may obtain inputs from the sub-programs and send outputs to the sub-programs to manage the aircraft <NUM>, in accordance with program code of the vehicle management program. The vehicle management program may also obtain inputs from the vehicle systems and output instructions/data to the vehicle systems, in accordance with the program code of the vehicle management program.

The vehicle management computer <NUM> may transmit instructions/data/graphical user interface(s) to the one or more display(s) <NUM> and/or the pilot/user interface(s) <NUM>. The one or more display(s) <NUM> and/or the pilot/user interface(s) <NUM> may receive user inputs, and transmit the user inputs to the vehicle management computer <NUM>.

The communications systems <NUM> may include various data links systems (e.g., satellite communications systems), cellular communications systems (e.g., LTE, <NUM>, <NUM>, etc.), radio communications systems (e.g., HF, VHF, etc.), and/or wireless local area network communications systems (e.g., Wi-Fi, Bluetooth, etc.). The communications systems <NUM> may enable communications, in accordance with the communications program <NUM>, between the aircraft <NUM> and external networks, services, and the cloud service <NUM>, discussed above. An example of the external networks may include a wide area network, such as the internet. Examples of the services may include weather information services <NUM>, traffic information services, etc..

The one or more transponder(s) <NUM> may include an interrogator system. The interrogator system of the aircraft <NUM> may be an ADS-B, a Mode S transponder, and/or other transponder system. The interrogator system may have an omnidirectional antenna and/or a directional antenna (interrogator system antenna). The interrogator system antenna may transmit/receive signals to transmit/receive interrogation messages and transmit/receive identification messages. For instance, in response to receiving an interrogation message, the interrogator system may obtain an identifier of the aircraft <NUM> and/or transponder aircraft data (e.g., speed, position, track, etc.) of the aircraft <NUM>, e.g., from the on-board vehicle navigation systems <NUM>; and transmit an identification message. Contra-wise, the interrogator system may transmit interrogation messages to nearby aircraft; and receive identification messages. The one or more transponder(s) <NUM> may send messages to the vehicle management computer <NUM> to report interrogation messages and/or identification messages received from/transmitted to other aircraft and/or the ground station(s) <NUM>. As discussed above, the interrogation messages may include an identifier of the interrogator system (in this case, the aircraft <NUM>), request the nearby aircraft to transmit an identification message, and/or (different than above) transponder aircraft data (e.g., speed, position, track, etc.) of the aircraft <NUM>; the identification message may include an identifier of the aircraft <NUM> and/or the transponder aircraft data of the aircraft <NUM>.

The edge sensors <NUM> on the structures <NUM> of the aircraft <NUM> may be sensors to detect various environmental and/or system status information. For instance, some of the edge sensors <NUM> may monitor for discrete signals, such as edge sensors on seats (e.g., occupied or not), doors (e.g., closed or not), etc. of the aircraft <NUM>. Some of the edge sensors <NUM> may monitor continuous signals, such as edge sensors on tires (e.g., tire pressure), brakes (e.g., engaged or not, amount of wear, etc.), passenger compartment (e.g., compartment air pressure, air composition, temperature, etc.), support structure (e.g., deformation, strain, etc.), etc., of the aircraft <NUM>. The edge sensors <NUM> may transmit edge sensor data to the vehicle management computer <NUM> to report the discrete and/or continuous signals.

The power systems <NUM> may include one or more battery systems, fuel cell systems, and/or other chemical power systems to power the actuation systems <NUM> and/or the vehicle systems in general. In one aspect of the disclosure, the power systems <NUM> may be a battery pack. The power systems <NUM> may have various sensors to detect one or more of temperature, fuel/electrical charge remaining, discharge rate, etc. (collectively, power system data <NUM>). The power systems <NUM> may transmit power system data <NUM> to the vehicle management computer <NUM> so that power system status <NUM> (or battery pack status) may be monitored by the vehicle status/health program <NUM>.

The actuation systems <NUM> may include: motors, engines, and/or propellers to generate thrust, lift, and/or directional force for the aircraft <NUM>; flaps or other surface controls to augment the thrust, lift, and/or directional force for the aircraft <NUM>; and/or aircraft mechanical systems (e.g., to deploy landing gear, windshield wiper blades, signal lights, etc.). The vehicle management computer <NUM> may control the actuation systems <NUM> by transmitting instructions, in accordance with the flight control program <NUM>, and the actuation systems <NUM> may transmit feedback/current status of the actuation systems <NUM> to the vehicle management computer <NUM> (which may be referred to as actuation systems data).

The camera(s) <NUM> may include inferred or optical cameras, LIDAR, or other visual imaging systems to record internal or external environments of the aircraft <NUM>. The camera(s) <NUM> may obtain inferred images; optical images; and/or LIDAR point cloud data, or any combination thereof (collectively "imaging data"). The LIDAR point cloud data may include coordinates (which may include, e.g., location, intensity, time information, etc.) of each data point received by the LIDAR. The camera(s) <NUM> and/or the vehicle management computer <NUM> may include a machine vision function. The machine vision function may process the obtained imaging data to detect objects, locations of the detected objects, speed/velocity (relative and/or absolute) of the detected objects, size and/or shape of the detected objects, etc. (collectively, "machine vision outputs"). For instance, the machine vision function may be used to image a landing zone to confirm the landing zone is clear/unobstructed (a landing zone (LZ) status <NUM>). Additionally or alternatively, the machine vision function may determine whether physical environment (e.g., buildings, structures, cranes, etc.) around the aircraft <NUM> and/or on/near the routes <NUM> may be or will be (e.g., based on location, speed, flight plan of the aircraft <NUM>) within a safe flight envelope of the aircraft <NUM>. The imaging data and/or the machine vision outputs may be referred to as "imaging output data. " The camera(s) <NUM> may transmit the imaging data and/or the machine vision outputs of the machine vision function to the vehicle management computer <NUM>. The camera(s) <NUM> may determine whether elements detected in the physical environment are known or unknown based on obstacle data stored in an obstacle database <NUM>, such as by determining a location of the detected object and determining if an obstacle in the obstacle database has the same location (or within a defined range of distance). The imaging output data may include any obstacles determined to not be in the obstacle data of the obstacle database <NUM> (unknown obstacles information).

The GPS systems <NUM> may include one or more global navigation satellite (GNSS) receivers. The GNSS receivers may receive signals from the United States developed Global Position System (GPS), the Russian developed Global Navigation Satellite System (GLONASS), the European Union developed Galileo system, and/or the Chinese developed BeiDou system, or other global or regional satellite navigation systems. The GNSS receivers may determine positioning information for the aircraft <NUM>. The positioning information may include information about one or more of position (e.g., latitude and longitude, or Cartesian coordinates), altitude, speed, heading, or track, etc. for the vehicle. The GPS systems <NUM> may transmit the positioning information to the on-board vehicle navigation systems <NUM> and/or to the vehicle management computer <NUM>.

The on-board vehicle navigation systems <NUM> may include one or more radar(s), one or more magnetometer(s), an attitude heading reference system (AHRS), and/or one or more air data module(s). The one or more radar(s) may be weather radar(s) to scan for weather and/or DAPA radar(s) (either omnidirectional and/or directional) to scan for terrain/ground/objects/obstacles. The one or more radar(s) (collectively "radar systems") may obtain radar information. The radar information may include information about the local weather and the terrain/ground/objects/obstacles (e.g., aircraft or obstacles and associated locations/movement). The one or more magnetometer(s) may measure magnetism to obtain bearing information for the aircraft <NUM>. The AHRS may include sensors (e.g., three sensors on three axes) to obtain attitude information for the aircraft <NUM>. The attitude information may include roll, pitch, and yaw of the aircraft <NUM>. The air data module(s) may sense external air pressure to obtain airspeed information for the aircraft <NUM>. The radar information, the bearing information, the attitude information, airspeed information, and/or the positioning information (collectively, navigation information) may be transmitted to the vehicle management computer <NUM>.

The weather program <NUM> may, using the communications systems <NUM>, transmit and/or receive weather information from one or more of the weather information services <NUM>. For instance, the weather program <NUM> may obtain local weather information from weather radars and the on-board vehicle navigation systems <NUM>, such as the air data module(s). The weather program may also transmit requests for weather information <NUM>. For instance, the request may be for weather information <NUM> along a route <NUM> of the aircraft <NUM> (route weather information). The route weather information may include information about precipitation, wind, turbulence, storms, cloud coverage, visibility, etc. of the external environment of the aircraft <NUM> along/near a flight path, at a destination and/or departure location (e.g., one of the hubs <NUM>-<NUM>), or for a general area around the flight path, destination location, and/or departure location. The one or more of the weather information services <NUM> may transmit responses that include the route weather information. Additionally or alternatively, the one or more of the weather information services <NUM> may transmit update messages to the aircraft <NUM> that includes the route weather information and/or updates to the route weather information.

The D/S & A program <NUM> may, using the one or more transponders <NUM> and/or the pilot/user interface(s) <NUM>, detect and avoid objects that may pose a potential threat to the aircraft <NUM>. As an example, the pilot/user interface(s) <NUM> may receive user input(s) from the pilots and/or users of the vehicle <NUM> (or radar/imaging detection) to indicate a detection of an object; the pilot/user interface(s) <NUM> (or radar/imaging detection) may transmit the user input(s) (or radar or imaging information) to the vehicle management computer <NUM>; the vehicle management computer <NUM> may invoke the D/S & A program <NUM> to perform an object detection process <NUM> to determine whether the detected object is a non-cooperative object <NUM> (e.g., it is an aircraft that is not participating in transponder communication); optionally, the vehicle management computer <NUM> may determine a position, speed, track for the non-cooperative object <NUM> (non-cooperative object information), such as by radar tracking or image tracking; in response to determining the object is a non-cooperative object <NUM>, the vehicle management computer <NUM> may determine a course of action, such as instruct the flight control program <NUM> to avoid the non-cooperative object <NUM>. As another example, the one or more transponder(s) <NUM> may detect an intruder aircraft (such as intruder aircraft <NUM>) based on an identification message from the intruder aircraft; the one or more transponder(s) <NUM> may transmit a message to the vehicle management computer <NUM> that includes the identification message from the intruder aircraft; the vehicle management computer <NUM> may extract an identifier and/or transponder aircraft data from the identification message to obtain the identifier and/or speed, position, track, etc. of the intruder aircraft; the vehicle management computer <NUM> may invoke the D/S & A program <NUM> to perform a position detection process <NUM> to determine whether the detected object is a cooperative object <NUM> and its location, speed, heading, track, etc.; in response to determining the object is a cooperative object <NUM>, the vehicle management computer <NUM> may determine a course of action, such as instruct the flight control program <NUM> to avoid the cooperative object <NUM>. For instance, the course of action may be different or the same for non-cooperative and cooperative objects <NUM>/<NUM>, in accordance with rules based on regulations and/or scenarios.

The flight routing program <NUM> may, using the communications systems <NUM>, generate/receive flight plan information <NUM> and receive system vehicle information <NUM> from the cloud service <NUM>. The flight plan information <NUM> may include a departure location (e.g., one of the hubs <NUM>-<NUM>), a destination location (e.g., one of the hubs <NUM>-<NUM>), intermediate locations (if any) (e.g., waypoints or one or more of the hubs <NUM>-<NUM>) between the departure and destination locations, and/or one or more routes <NUM> to be used (or not used). The system vehicle information <NUM> may include other aircraft positioning information for other aircraft with respect to the aircraft <NUM> (called a "receiving aircraft <NUM>" for reference). For instance, the other aircraft positioning information may include positioning information of the other aircraft. The other aircraft may include: all aircraft <NUM>-<NUM> and/or intruder aircraft <NUM>; aircraft <NUM>-<NUM> and/or intruder aircraft <NUM> within a threshold distance of the receiving aircraft <NUM>; aircraft <NUM>-<NUM> and/or intruder aircraft <NUM> using a same route <NUM> (or is going to use the same route <NUM> or crossing over the same route <NUM>) of the receiving aircraft; and/or aircraft <NUM>-<NUM> and/or intruder aircraft <NUM> within a same geographic area (e.g., city, town, metropolitan area, or sub-division thereof) of the receiving aircraft.

The flight routing program <NUM> may determine or receive a planned flight path <NUM>. The flight routing program <NUM> may receive the planned flight path <NUM> from another aircraft <NUM> or the cloud service <NUM> (or other service, such as an operating service of the aircraft <NUM>). The flight routing program <NUM> may determine the planned flight path <NUM> using various planning algorithms (e.g., flight planning services on-board or off-board the aircraft <NUM>), aircraft constraints (e.g., cruising speed, maximum speed, maximum/minimum altitude, maximum range, etc.) of the aircraft <NUM>, and/or external constraints (e.g., restricted airspace, noise abatement zones, etc.). The planned/received flight path may include a <NUM>-D trajectory of a flight trajectory with <NUM>-D coordinates, a flight path based on waypoints, any suitable flight path for the aircraft <NUM>, or any combination thereof, in accordance with the flight plan information <NUM> and/or the system vehicle information <NUM>. The <NUM>-D coordinates may include <NUM>-D coordinates of space (e.g., latitude, longitude, and altitude) for a flight path and time coordinate.

The flight routing program <NUM> may determine an unplanned flight path <NUM> based on the planned flight path <NUM> and unplanned event triggers, and using the various planning algorithms, the aircraft constraints of the aircraft <NUM>, and/or the external constraints. The vehicle management compute <NUM> may determine the unplanned event triggers based on data/information the vehicle management compute <NUM> receives from other vehicle systems or from the cloud service <NUM>. The unplanned event triggers may include one or a combination of: (<NUM>) emergency landing, as indicated by the vehicle status/health program <NUM> discussed below or by a user input to one or more display(s) <NUM> and/or the pilot/user interface(s) <NUM>; (<NUM>) intruder aircraft <NUM>, cooperative object <NUM>, or non-cooperative object <NUM> encroaching on a safe flight envelope of the aircraft <NUM>; (<NUM>) weather changes indicated by the route weather information (or updates thereto); (<NUM>) the machine vision outputs indicating a portion of the physical environment may be or will be within the safe flight envelope of the aircraft <NUM>; and/or (<NUM>) the machine vision outputs indicating a landing zone is obstructed.

Collectively, the unplanned flight path <NUM>/the planned flight path <NUM> and other aircraft positioning information may be called flight plan data.

The vehicle status/health program <NUM> may monitor vehicle systems for status/health, and perform actions based on the monitored status/health, such as periodically report status/health, indicate emergency status, etc. The vehicle may obtain the edge sensor data and the power system data <NUM>. The vehicle status/health program <NUM> may process the edge sensor data and the power system data <NUM> to determine statuses of the power system <NUM> and the various structures and systems monitored by the edge sensors <NUM>, and/or track a health of the power system <NUM> and structures and systems monitored by the edge sensors <NUM>. For instance, the vehicle status/health program <NUM> may obtain the power systems data <NUM>; determine a battery status <NUM>; and perform actions based thereon, such as reduce consumption of non-essential systems, report battery status, etc. The vehicle status/health program <NUM> may determine an emergency landing condition based on one or more of the power system <NUM> and structures and systems monitored by the edge sensors <NUM> has a state that indicates the power system <NUM> and structures and systems monitored by the edge sensors <NUM> has or will fail soon. Moreover, the vehicle status/health program <NUM> may transmit status/health data to the cloud service <NUM> as status/health messages (or as a part of other messages to the cloud service). The status/health data may include the actuation systems data, all of the edge sensor data and/or the power system data, portions thereof, summaries of the edge sensor data and the power system data, and/or system status indicators (e.g., operating normal, degraded wear, inoperable, etc.) based on the edge sensor data and the power system data.

The flight control program <NUM> may control the actuation system <NUM> in accordance with the unplanned flight path <NUM>/the planned flight path <NUM>, the other aircraft positioning information, control laws <NUM>, navigation rules <NUM>, and/or user inputs (e.g., of a pilot if aircraft <NUM> is a piloted or semi-autonomous vehicle). The flight control program <NUM> may receive the planned flight path <NUM>/unplanned flight path <NUM> and/or the user inputs (collectively, "course"), and determine inputs to the actuation system <NUM> to change speed, heading, attitude of the aircraft <NUM> to match the course based on the control laws <NUM> and navigation rules <NUM>. The control laws <NUM> may dictate a range of actions possible of the actuation system <NUM> and map inputs to the range of actions to effectuate the course by, e.g., physics of flight of the aircraft <NUM>. The navigation rules <NUM> may indicate acceptable actions based on location, waypoint, portion of flight path, context, etc. (collectively, "circumstance"). For instance, the navigation rules <NUM> may indicate a minimum/maximum altitude, minimum/maximum speed, minimum separation distance, a heading or range of acceptable headings, etc. for a given circumstance.

The vertiport status program <NUM> may control the aircraft <NUM> during takeoff (by executing a takeoff process <NUM>) and during landing (by executing a landing process <NUM>). The takeoff process <NUM> may determine whether the landing zone from which the aircraft <NUM> is to leave and the flight environment during the ascent is clear (e.g., based on the control laws <NUM>, the navigation rules <NUM>, the imaging data, the obstacle data, the unplanned flight path <NUM>/the planned flight path <NUM>, the other aircraft positioning information, user inputs, etc.), and control the aircraft or guide the pilot through the ascent (e.g., based on the control laws <NUM>, the navigation rules <NUM>, the imaging data, the obstacle data, the flight plan data, user inputs, etc.). The landing process <NUM> may determine whether the landing zone on which the aircraft <NUM> is to land and the flight environment during the descent is clear (e.g., based on the control laws <NUM>, the navigation rules <NUM>, the imaging data, the obstacle data, the flight plan data, user inputs, the landing zone status, etc.), and control the aircraft or guide the pilot through the descent (e.g., based on the control laws <NUM>, the navigation rules <NUM>, the imaging data, the obstacle data, the flight plan data, user inputs, the landing zone status, etc.).

The one or more data storage systems may store data/information received, generated, or obtained onboard the aircraft. The one or more data storage systems may also store software for one or more of the computers onboard the aircraft.

The block diagram 300B may be the same as the block diagram 300A, but the block diagram 300B may omit the pilot/user interface(s) <NUM> and/or the one or more displays <NUM>, and include a vehicle position/speed/altitude system <NUM>. The vehicle position/speed/altitude system <NUM> may include or not include the on-board vehicle navigation systems <NUM> and/or the GPS systems <NUM>, discussed above. In the case that the vehicle position/speed/altitude system <NUM> does not include the on-board vehicle navigation systems <NUM> and/or the GPS systems <NUM>, the vehicle position/speed/altitude system <NUM> may obtain the navigation information from the cloud service <NUM>.

In one aspect of the disclosure, the aircraft <NUM> may detect objects, report new objects to the cloud service <NUM>, and update the obstacle database <NUM> based on feedback from the cloud service <NUM>.

In particular, turning to <FIG> depicts an exemplary block diagram of a system <NUM> for obstacle detection and database management using multi-source weightages, according to one or more embodiments. The system <NUM> depicts particular elements of <FIG> with additional elements to illustrate obstacle detection and database management using multi-source weightages. The system <NUM> may include position sensors <NUM>, onboard sensors <NUM>, a terrain awareness (TA) system <NUM>, the display <NUM>, and the communications system <NUM> onboard a vehicle <NUM> (such as one of 300A or 300B depicting the aircraft <NUM>), and the cloud services <NUM>. The system <NUM> may detect objects, determine whether the detected objects are new objects (e.g., by comparing with known objects in the obstacle DB), and distribute new object information to vehicles, such as vehicle <NUM>, so that onboard obstacle databases may be updated accordingly.

For instance, the vehicle <NUM> may detect new objects and report them to the cloud service <NUM>. The cloud service <NUM> may determine whether the object has been reported by any other sources (e.g., other vehicles <NUM>) and determine a weightage to assign the new object based on every reported instance of the object. The weightage may indicate a confidence of object location, size, shape, and/or features. The cloud service <NUM> may then broadcast information about the new object to all vehicles or only vehicles within a threshold range from a location of the object (including the vehicle <NUM> that reported the new object), and/or report a new object to a database provider (which may be the same entity as the cloud service <NUM>). In response to receiving the broadcast information regarding the object, the vehicle <NUM> may, based on the weightage, output an alert, display an indicator corresponding to the new object, update flight plans of the vehicle, and/or update navigation computations.

The position sensors <NUM> may include the GPS systems <NUM> and on-board vehicle navigation systems <NUM> (in the case of vehicle 300A) or (in the case of vehicle 300B) the vehicle position/speed/altitude system <NUM>. Generally, the position sensors <NUM> output vehicle state information on a continuous or periodic basis so that the vehicle <NUM> is aware of its current state. The vehicle state information may include position, speed, heading, and/or orientation data for the vehicle <NUM>.

The onboard sensors <NUM> may include the camera(s) <NUM> to output the imaging output data (e.g., the imaging data and/or the machine vision outputs), and the one or more display(s) <NUM> and/or the pilot/user interface(s) <NUM> to receive user inputs (referred to collectively as "sensor data").

The user inputs may indicate an approximate location and geometry for a new object (e.g., an object not already indicated on a display as a known object). For instance, the user input may be an input on a digital map, and a position of the user input on the digital map may indicate the position of the new object in an external environment. Additionally or alternatively, the user input may enter absolute or relative coordinates from the vehicle <NUM> (e.g., an estimate of latitude and longitude, or an estimate of a distance/range and heading from the vehicle, etc.). The user inputs may indicate the object features by indicating one or more of: shape (2D or 3D shapes), size, obstacle outline, dominant edges, and/or dimensions (e.g., height, length, width, or geometry).

The TA system <NUM> may include a TA function 415A, a terrain database 415B, an obstacle function 415C, and (a copy of or access to) the obstacle database <NUM>. The TA function 415A of the TA system <NUM> may use the terrain database 415B and the obstacle function 415C (based on data received from the position sensors and the onboard sensors <NUM>) to detect and avoid, automatically or via alerting a pilot/user via the display <NUM>, terrain and obstacles.

In particular, turning to <FIG> depicts a flowchart <NUM> for obstacle detection and database management using multi-source weightages, according to one or more embodiments. In particular, the flowchart <NUM> of <FIG> is performed by the obstacle function 415C and the cloud service <NUM> of the system <NUM>. The flowchart <NUM> starts with the obstacle function 415C obtaining the vehicle state information and the sensor data (Block <NUM>). The obstacle function 415C may then proceed to analyze the sensor data to compare object feature(s) of detected objects with known objects indicated by vehicle state information and obstacle database (Block <NUM>). For instance, the obstacle function 415C may process the sensor data to detect objects including object features for each detected object; and responsive to a detection of an object, determine whether the object is a known object or an unknown object based on the object features and known objects indicated by the vehicle state information and an obstacle database.

To process the sensor data to detect objects including object features for each detected object, the obstacle function 415C may, for images, detect objects using the machine vision function (e.g., using machine learning, etc.) and, for detected objects, extract object features from the imaging data. For images, the object features may include image features such as obstacle outline, position, dominant edges, and/or dimensions (e.g., height, length, width, or geometry). The image features may be stored in pixel form using digital processing techniques. For user inputs, the obstacle function 415C may detect the object in response to the user input and determine the object features entered by the user input.

To determine whether the object is a known object or an unknown object based on the object features and known objects indicated by the vehicle state information and an obstacle database, the obstacle function 415C may: determine known objects by extracting known objects from the obstacle database; compare the detected objects with the known objects; if the comparison indicates a match, determine the detected object is a known object; and if the comparison indicates not a match, determine the detected object is an unknown object.

To extract known objects from the obstacle database, the obstacle function 415C may extract known objects that are within a threshold distance of the vehicle <NUM> and/or extract known objects that are within an envelope of the onboard sensors <NUM>. The envelope of the onboard sensors <NUM> may be defined based on the type of camera(s) <NUM> that output the imaging data (e.g., a max sensing distance for each type). For instance, the obstacle function 415C may determine a position of the vehicle <NUM> from the vehicle state information (e.g., extract position or derive position from speed, heading, etc.) and extract known objects that are within the threshold distance of the position/within the envelope of the onboard sensors <NUM>.

To compare the detected objects with the known objects, the obstacle function 415C may compare the object features of the detected object (as input by the user or determined by the obstacle function 415C) to object features of the extracted known objects. For instance, for object features determined by the obstacle function 415C, the obstacle function 415C may compare the image features of the detected object to image slices of the known objects to determine whether there is a match. To determine whether there is a match, the obstacle function 415C may determine a match when all, a majority, or a threshold number of obstacle outline, position, dominant edges, and/or dimensions of the image features are sufficiently close (e.g., the same as or within a range of) to an obstacle outline, position, dominant edges, and/or dimensions of an image slice of a known object. Similarly, for object features input by user input, the obstacle function 415C may compare image features generated based on the user input object features to the image slices of the known objects to determine whether there is a match. Alternatively, the obstacle function 415C may compare the image features of the detected object to image slices of the known objects to determine whether there is a match by: (<NUM>) generating a feature vector based on the detected object (e.g., the imaging data associated with the detected objects, the object features for the detected objects, and/or the image features for the detected objects) and the image slices of the known objects; (<NUM>) process the feature vector through a matching machine learning program (e.g., a neural network) to output a score for each known object; and (<NUM>) if a score is above a threshold (e.g., a confidence threshold), determine the detected object matches a known object that corresponds to the score about the threshold.

The obstacle function 415C may then proceed to determine whether a new object is detected (Block <NUM>). In response to determining a new object is not detected (Block <NUM>: No), the obstacle function 415C may proceed to do nothing (block <NUM>), then return to obtain vehicle state information and sensor data (Block <NUM>) to start the process over again with new data.

In response to determining a new object is detected (Block <NUM>: Yes), the obstacle function 415C may proceed to check occurrence(s), if any, from history stored onboard and, if present, extract weightage (Block <NUM>). For instance, the obstacle function 415C may store previously detected new objects in the history or store new objects detected by other vehicles <NUM> (and broadcast by the cloud service <NUM>) in the history. The history may be a part of the obstacle database <NUM> with an indication that the particular objects have not been confirmed by the database provider as an obstacle. The previously stored new objects may include a weightage (as computed by the cloud service <NUM>, discussed below), which may be extracted by the obstacle function 415C.

The obstacle function 415C may then proceed to transmit a new object message to the cloud service <NUM> (Block <NUM>). For instance, the obstacle function 415C may generate the new object message and transmit the new object message to the cloud service <NUM> via the communications system <NUM>. To generate the new object message, the obstacle function 415C may compile the new object message with a copy of the vehicle state information and one or more of: the imaging data associated with the new objects, the object features for the new objects, and/or the image features for the new objects (referred to as "unknown object information"). The obstacle function 415C may store the unknown object information in the history discussed above. Note, an obstacle function 415C of another vehicle <NUM> may have previously transmitted a new object message for this new object to the cloud service <NUM> as well (Block <NUM>).

The cloud service <NUM> may receive the new object message from the obstacle function 415C (e.g., via the communications systems <NUM>). The cloud service <NUM> may then proceed to check if other instances of the new object(s) have been reported earlier by another vehicle (either the vehicle <NUM> previously or other vehicle <NUM>) (Block <NUM>). For instance, the cloud service <NUM> may store new object files in a cloud database for new objects detected and reported the vehicle <NUM> and other vehicles <NUM>. The new object files may include previously reported new object messages or the constituent components thereof. The cloud service <NUM> may then determine whether any of the stored new object files correspond to a same new object as indicated in the new object message. If any of the stored new object files correspond to the same new object, the cloud service <NUM> may extract the stored new object files.

The cloud service <NUM> may then proceed to assign weightages to the new object(s) accordingly (Block <NUM>). For instance, the cloud service <NUM> may set the new object message and each, if any, new object files, as an iteration; (optionally) assign identifications (IDs) to each iteration; search image pixels of each iteration for frequent occurred image pixels patterns (frequent occurred image pixels patterns may be templates (e.g., for buildings, structures, etc.), to check for common shapes/edges/geometries/etc., and/or extracted pixel patterns from one or more of the iterations, to check for agreement between iterations); determine occurrence numbers for the image pixels for the frequent occurred image pixel patterns across all iterations based on the search; assign the occurrence numbers to corresponding image pixels (e.g., to the image pixels that make up a match to the frequent occurred image pixel patterns); determine whether any occurrence number, for the image pixels, is above an occurrence threshold; in response to an occurrence number being above the occurrence threshold, retain the image pixels that have occurrence numbers for frequent occurred image pixel patterns above the threshold; and determine the weightage by averaging the occurrence numbers for the retained image pixels. Additionally, the cloud service <NUM> may make adjustments to the image pixels (for each iteration) based on a location, altitude or orientation of the onboard sensors <NUM> for each iteration, so that differences of location, altitude or orientation between the iterations does not degrade with the weightage computation.

The cloud service <NUM> may then proceed to broadcast a local message to all local vehicles (Block <NUM>). For instance, the cloud service <NUM> may generate the local message and transmit the local message to vehicles <NUM> within a threshold range of the new object or expected to travel near (e.g., within the threshold range) of the new object. To generate the local message, the cloud service <NUM> may compile the local message to include a position of the new object and object features for the new object. To determine the local vehicles, the cloud service <NUM> may have copies of flight plans or track a position of each vehicle, and determine local vehicles as those that are within the threshold range or will be on the flight plan.

The obstacle function 415C may receive the broadcast local message from the cloud service <NUM>. The obstacle function 415C may then proceed to calculate an average weightage of onboard and received from cloud weightages (Block <NUM>). For instance, the obstacle function 415C may retrieve the weightage stored in the history and calculate an average of the stored weightage and the weightage in the local message. The obstacle function 415C may then proceed to store the average weightage in the obstacle DB (e.g., in the history, if the first time, or update the history, if already stored) (Block <NUM>).

The obstacle function 415C may then proceed to perform at least one action based on the weightage (Block <NUM>). For instance, the obstacle function 415C may, based on the weightage of the unknown object, output an alert, display an indicator, update flight plans of the vehicle, and/or update navigation computations. The obstacle function 415C may then proceed to return to obtain vehicle state information and sensor data (Block <NUM>) to start the process over again with new data.

For instance, the obstacle function 415C may output an alert for the new object if a trigger condition indicates the vehicle <NUM> is too close to the object or will be (e.g., based on current speed and heading, or the flight plan indicates a path to close to the new object). The trigger condition may be adjustable based on the weightage of the unknown object. For instance, for higher weightages, the obstacle function 415C may allow the vehicle <NUM> to get closer to the new object than lower weightages, as a confidence regarding the position and geometry of the new object is more certain. On the other hand, for new objects with a lower weightage, a confidence regarding the position and geometry is less certain, so more separation may be needed.

For instance, the obstacle function 415C may display an indicator of the new object when the vehicle <NUM> is approaching the new object. The display may also display other new objects and known objects, e.g., on a digital map. The new objects (e.g., those not yet confirmed) may be displayed in a different manner from known objects. For instance, new objects may be displayed in a different color from the known objects, so that users may have increased situation awareness (e.g., the system <NUM> has less confidence regarding new objects than known objects).

For instance, the obstacle function 415C may update flight plans of the vehicle and the navigation computations by informing the flight routing program <NUM>, so that the planned flight path <NUM> and the unplanned flight path <NUM> may be updated in accordance with the weightage. For instance, as indicated above, a higher weightage new obstacle may allow the vehicle <NUM> to approach the new object in a closer manner than a lower weightage new object. Therefore, the vehicle <NUM> may provide more efficient navigation, as the vehicle <NUM> may perform differentiated actions in accordance with the weightages of the new objects.

Note, after assigning weightages to the new object(s) accordingly (Block <NUM>), the cloud service <NUM> may also then proceed to determine whether the assigned weightages are greater than a provider threshold (Block <NUM>). For instance, the cloud service <NUM> may compare the weightage to the provider threshold to determine whether a confidence regarding a new object is high enough to update the obstacle database <NUM> of every vehicle <NUM>, instead of only the local vehicles.

In response to determining the assigned weightages are above a threshold (Block <NUM>: Yes), the cloud service <NUM> may also then proceed to transmit a database provider message to a database provider (Block <NUM>) and store the new object for future processing (Block <NUM>). For instance, the cloud service <NUM> may generate the database provider message by compiling the database provider message to include all iterations in the cloud database (or the constitution components thereof), so the database provider may verify and/or generate a database entry for the new object.

In response to determining the assigned weightages are above a threshold (Block <NUM>: Yes), the cloud service <NUM> may also then proceed to only store the new object for future processing (Block <NUM>). For instance, to store the new object for future processing, the cloud service <NUM> may update the cloud database to include the new object message as a new object file (e.g., as another iteration).

Therefore, the methods and systems of the present disclosure increase safety, reduce bandwidth consumption, reduce onboard storage, and provide more efficient navigation. As the vehicles <NUM> report new objects, along with imaging data (or object features thereof), the cloud service <NUM> is above to determine a multi-source weightage to determine a confidence regarding a position and geometry of a new object. The cloud service <NUM> may then report the new object to local vehicles only, which may then increase safety (by issuing alerts), increase situation awareness (by displaying differentiated indicators, and increase efficient navigation (by updating flight planning and navigation computations). The cloud service <NUM> may also report new objects that have a high confidence to a database provider so that an update my generated for all vehicles <NUM>, when an object is confirmed to be an obstacle.

<FIG> depicts an example system that may execute techniques presented herein. <FIG> is a simplified functional block diagram of a computer that may be configured to execute techniques described herein, according to exemplary embodiments of the present disclosure. Specifically, the computer (or "platform" as it may not be a single physical computer infrastructure) may include a data communication interface <NUM> for packet data communication. The platform may also include a central processing unit ("CPU") <NUM>, in the form of one or more processors, for executing program instructions. The platform may include an internal communication bus <NUM>, and the platform may also include a program storage and/or a data storage for various data files to be processed and/or communicated by the platform such as ROM <NUM> and RAM <NUM>, although the system <NUM> may receive programming and data via network communications. The system <NUM> also may include input and output ports <NUM> to connect with input and output devices such as keyboards, mice, touchscreens, monitors, displays, etc. Of course, the various system functions may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load. Alternatively, the systems may be implemented by appropriate programming of one computer hardware platform.

The general discussion of this disclosure provides a brief, general description of a suitable computing environment in which the present disclosure may be implemented. In one embodiment, any of the disclosed systems, methods, and/or graphical user interfaces may be executed by or implemented by a computing system consistent with or similar to that depicted and/or explained in this disclosure. Although not required, aspects of the present disclosure are described in the context of computer-executable instructions, such as routines executed by a data processing device, e.g., a server computer, wireless device, and/or personal computer. Those skilled in the relevant art will appreciate that aspects of the present disclosure can be practiced with other communications, data processing, or computer system configurations, including: Internet appliances, hand-held devices (including personal digital assistants ("PDAs")), wearable computers, all manner of cellular or mobile phones (including Voice over IP ("VoIP") phones), dumb terminals, media players, gaming devices, virtual reality devices, multi-processor systems, microprocessor-based or programmable consumer electronics, set-top boxes, network PCs, minicomputers, mainframe computers, and the like. Indeed, the terms "computer," "server," and the like, are generally used interchangeably herein, and refer to any of the above devices and systems, as well as any data processor.

Aspects of the present disclosure may be embodied in a special purpose computer and/or data processor that is specifically programmed, configured, and/or constructed to perform one or more of the computer-executable instructions explained in detail herein. While aspects of the present disclosure, such as certain functions, are described as being performed exclusively on a single device, the present disclosure may also be practiced in distributed environments where functions or modules are shared among disparate processing devices, which are linked through a communications network, such as a Local Area Network ("LAN"), Wide Area Network ("WAN"), and/or the Internet. Similarly, techniques presented herein as involving multiple devices may be implemented in a single device. In a distributed computing environment, program modules may be located in both local and/or remote memory storage devices.

Aspects of the present disclosure may be stored and/or distributed on non-transitory computer-readable media, including magnetically or optically readable computer discs, hard-wired or preprogrammed chips (e.g., EEPROM semiconductor chips), nanotechnology memory, biological memory, or other data storage media. Alternatively, computer implemented instructions, data structures, screen displays, and other data under aspects of the present disclosure may be distributed over the Internet and/or over other networks (including wireless networks), on a propagated signal on a propagation medium (e.g., an electromagnetic wave(s), a sound wave, etc.) over a period of time, and/or they may be provided on any analog or digital network (packet switched, circuit switched, or other scheme).

Program aspects of the technology may be thought of as "products" or "articles of manufacture" typically in the form of executable code and/or associated data that is carried on or embodied in a type of machine-readable medium. "Storage" type media include any or all of the tangible memory of the computers, processors or the like, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives and the like, which may provide non-transitory storage at any time for the software programming. All or portions of the software may at times be communicated through the Internet or various other telecommunication networks. Such communications, for example, may enable loading of the software from one computer or processor into another, for example, from a management server or host computer of the mobile communication network into the computer platform of a server and/or from a server to the mobile device. Thus, another type of media that may bear the software elements includes optical, electrical and electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links. The physical elements that carry such waves, such as wired or wireless links, optical links, or the like, also may be considered as media bearing the software. As used herein, unless restricted to non-transitory, tangible "storage" media, terms such as computer or machine "readable medium" refer to any medium that participates in providing instructions to a processor for execution.

The terminology used above may be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific examples of the present disclosure. Indeed, certain terms may even be emphasized above; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section. Both the foregoing general description and the detailed description are exemplary and explanatory only and are not restrictive of the features, as claimed.

As used herein, the terms "comprises," "comprising," "having," including," or other variations thereof, are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements, but may include other elements not expressly listed or inherent to such a process, method, article, or apparatus.

In this disclosure, relative terms, such as, for example, "about," "substantially," "generally," and "approximately" are used to indicate a possible variation of ±<NUM>% in a stated value.

The term "exemplary" is used in the sense of "example" rather than "ideal. " As used herein, the singular forms "a," "an," and "the" include plural reference unless the context dictates otherwise.

Claim 1:
A system (<NUM>), the system comprising:
at least one memory storing instructions; and
at least one processor configured to execute the instructions to perform a process, the process including:
obtaining vehicle state information for a vehicle (<NUM>), the vehicle state information including position, speed, heading, and/or orientation data for the vehicle;
obtaining sensor data from one or more sensors (<NUM>) onboard the vehicle; the one or more sensors scanning an environment external to the vehicle;
processing the sensor data to detect objects including object features for each detected object;
responsive to a detection of an object, determining whether the object is a known object or an unknown object based on the object features and known objects indicated by the vehicle state information and an obstacle database (<NUM>);
responsive to a determination that the object is an unknown object, updating the obstacle database with unknown object information, checking occurrences of the unknown object from a history stored in the obstacle database and extracting an onboard weightage of the unknown object and transmitting the unknown object information to an off-board service (<NUM>);
receiving a response from the off-board service, the response including an off-board service weightage assigned to the unknown object based on every reported instance of the unknown object, wherein the off-board service weightage indicates a confidence of object location, size, shape, and/or features;
updating the obstacle database with an average of the onboard weightage and the off-board service weightage assigned to the unknown object; and
performing at least one action based on the average weightage of the unknown object, wherein performing the at least one action based on the average weightage of the unknown object includes:
performing, based on the average weightage of the unknown object, one or more of: outputting an alert; displaying an indicator; updating flight plans of the vehicle; and/or updating navigation computations.