Patent Application
20240371276
The present disclosure relates generally to aviation transport networks, and in particular to dynamic aircraft routing using a network of skylanes.
A vertical takeoff and landing (VTOL) aircraft can transition from a vertical takeoff state to travel vertically and a cruise state to move forward. For example, a vertical takeoff state can use propellers to generate lift. The cruise state uses wings to generate lift and rotate the propellers to generate thrust. Similar elements can be used for landing the VTOL. The VTOL can utilize this functionality to transport passengers from one location to another. Transportation service applications can allow passengers to request transportation and computing platforms can be used to help facilitate these services.
Aspects and advantages of implementations of the present disclosure will be set forth in part in the following description, or may be learned from the description, or may be learned through practice of the implementations.
One example aspect of the present disclosure is directed to a method for generating a network of skylanes for electric vertical takeoff and landing (eVTOL) aircraft travel in a particular geographic area. The method includes accessing airspace data defining an available portion of the particular geographic area for the eVTOL aircraft travel. The method includes computing skylane route data for a particular skylane defined by a plurality of waypoints in three-dimensional space between a first vertiport location and a second vertiport location for the eVTOL aircraft travel in the particular geographic area, wherein the skylane route data for the particular skylane is computed based at least in part on the airspace data. The method includes updating a network of available skylanes for eVTOL aircraft travel in the particular geographic area by adding the skylane route data for the particular skylane to the network of available skylanes. The method includes deploying a particular eVTOL aircraft to travel on the particular skylane upon selection of the particular skylane from the network of available skylane of routes.
Another example aspect of the present disclosure is directed to one or more non-transitory computer-readable media storing instructions that are executable by one or more processors to perform operations. The operations include accessing airspace data defining an available portion of the particular geographic area for the eVTOL aircraft travel. The operations include computing skylane route data for a particular skylane defined by a plurality of waypoints in three-dimensional space between a first vertiport location and a second vertiport location for the eVTOL aircraft in the particular geographic area, wherein the skylane route data for the particular skylane is computed based at least in part on the airspace data. The operations include updating a network of available skylanes for eVTOL aircraft travel in the particular geographic area by adding the skylane route data for the particular skylane to the network of available skylanes. The operations include deploying a particular eVTOL aircraft to travel on the particular skylane upon selection of the particular skylane from the network of available skylane of routes.
Yet another example aspect of the present disclosure is directed to a computing system. The computing system includes one or more processors and one or more non-transitory computer-readable media storing instructions that are executable by the one or more processors to perform operations. The operations include accessing airspace data defining an available portion of the particular geographic area for the eVTOL aircraft travel. The operations include computing skylane route data for a particular skylane defined by a plurality of waypoints in three-dimensional space between a first vertiport location and a second vertiport location for the eVTOL aircraft in the particular geographic area, wherein the skylane route data for the particular skylane is computed based at least in part on the airspace data. The operations include updating a network of available skylanes for eVTOL aircraft travel in the particular geographic area by adding the skylane route data for the particular skylane to the network of available skylanes. The operations include deploying a particular eVTOL aircraft to travel on the particular skylane upon selection of the particular skylane from the network of available skylane of routes.
Other example aspects of the present disclosure are directed to other systems, methods, vehicles, apparatuses, tangible non-transitory computer-readable media, and devices for dynamically determining and updating a network of skylanes, as well as assigning eVTOL aircraft to such skylanes for air travel.
These and other features, aspects and advantages of various implementations will become better understood with reference to the following description and appended claims. The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate implementations of the present disclosure and, together with the description, serve to explain the related principles.
Detailed discussion of implementations directed to one of ordinary skill in the art are set forth in the specification, which makes reference to the appended figures, in which:
Generally, the present disclosure is directed to improved solutions for aviation transport networks, particularly for vertical takeoff and landing (VTOL) aircraft. More particularly, the computing technology described herein dynamically determines a skylane network for improved aviation transport by VTOL aircraft. The skylane network can include all the skylanes for a particular geographic area. As described herein, a skylane includes a three-dimensional volume of airspace that encapsulates a route for the VTOL aircraft to travel from one location to another. The technology of the present disclosure can dynamically generate a skylane network for VTOL aircraft by leveraging airspace data from other types of aircraft. The resultant skylane network can be particularly useful for routing VTOL aircraft in a particular geographic area, such as a dense urban environment.
More particularly, a computing system (e.g., of an aerial transportation network) can generate a directed graph representation of a skylane network. The skylane network can include all the skylanes for a particular geographic area. Each skylane can be represented by a three-dimensional volume of airspace surrounding an aircraft route. More particularly, a skylane can be defined by a plurality of waypoints in three-dimensional space between a first location (e.g., an origin vertiport) and a second location (e.g., a destination vertiport). The directed graph representation of the skylane network can include nodes and edges for each respective skylane.
For a new skylane in the network, the computing system can access airspace data including aircraft track data and/or restricted zone data. The aircraft track data can indicate locations of one or more aircraft (e.g., eVTOL aircraft, helicopters or other rotary-wing aircraft, or other aircraft having similar operational parameters as eVTOL aircraft) during one or more routes previously traveled in a particular geographic area. The restricted zone data can indicate locations within a particular geographic area that are unavailable for eVTOL aircraft travel, such as no-fly zones or locations associated with takeoff and landing paths for other aircraft (e.g., fixed-wing aircraft such as turbo planes and/or jets).
The computing system can generate skylanes for eVTOL aircraft travel based on the aircraft track data and/or restricted zone data by creating waypoints between first and second locations, each corresponding to nodes within the directed graph. In some implementations, the computing system can generate map-based representations of the skylanes for presentation via a user interface.
The skylane network can be updated in real-time based on constraints that are unique to operating VTOL aircraft for relatively short-range, ridesharing transport applications. Moreover, the technology can improve aircraft operations by intelligently assigning VTOL aircraft to particular skylanes based on timing sequences, aircraft type, and other parameters to improve transportation efficiency, while avoid violating the operating constraints.
Air travel has conventionally been limited compared to ground travel. Air travel can have a number of requirements making air travel difficult. For instance, aircraft can require significant resources such as fuel and infrastructure (e.g., runways) and require significant time for passenger entry and exit, each presenting technical challenges for achieving a larger volume of air travel within particular geographic areas or between neighboring locations. However, providing such air travel may reduce travel time over purely ground-based approaches as well as alleviate problems associated with traffic congestion.
Vertical takeoff and landing (VTOL) aircraft provide opportunities to incorporate aerial transportation into transport networks for cities and metropolitan areas. VTOL aircraft require much less space to take off and land relative to traditional aircraft. In addition, developments in battery technology have made electric VTOL (eVTOL) aircraft technically and commercially viable. EVTOL aircraft may be quieter than aircraft using other power sources or propulsion systems, which further increases their viability for use in built-up areas where noise may be a concern. Although some aspects of the present disclosure are described relative to VTOL and/or eVTOL aircraft, the subject technology can be applied to any aircraft including all types of VTOL and non-VTOL aircraft, such as but not limited to electric VTOL, hydrogen-electric VTOL, rotary-wing aircraft, and smaller/slower fixed wing aircraft (e.g., propeller planes).
Operating e VTOL aircraft within a dense urban environment involves more complex operating constraints than traditional commercial aviation. For instance, aerial rideshare services may utilize eVTOL aircraft to fly at lower altitudes and tighter flight corridors, which introduces additional noise and maneuverability constraints. Vertiports for takeoff and landing of eVTOL aircraft may also be designated in unique locations relative to traditional aviation. Traditional aircraft routing techniques lack the computational flexibility to properly allocate airspace for these more dynamic operating conditions.
The techniques described herein to generate and update a skylane network are intended to address the aforementioned challenges in aircraft routing for eVTOL aircraft. Additional aspects of the present disclosure are also intended to address the aforementioned challenges.
For instance, the computing system can dynamically change skylanes during operation of a multi-modal transportation service. For example, the computing system can continuously refine the skylane network by dynamically updating individual skylanes and/or segments of associated routes based on aircraft location data, runway use data, noise limit data, weather data, payload data, or other constraint parameter data. Dynamic skylane updates include changes that are made to compensate based on other factors (e.g., to make up for user/aircraft delays, additional charging, avoid user ETA violations, etc.). This can also include changing the skylanes based on changes in visual and auditory noise, demand, etc.
To change the skylane, the network computing system can revise, remove, or replace skylanes as well as individual segments of a particular skylane. By way of example, the computing system can adjust particular waypoints of a skylane to re-route the skylane to avoid an eVTOL flying in an area experiencing a temporary restriction on environmental noise (e.g., to do a graduation). In another example, the computing system can adjust the dimensions of the skylane (e.g., to increase the height of a volume above the route) to allow an aircraft to fly at higher altitudes to decrease noise impacts at the ground level. In another example, the computing system may adjust the waypoints for a plurality of skylanes such that a particular skylane has a more direct route to a destination to compensate for a delayed departure (e.g., due to a late arriving passenger).
Another example aspect of the present disclosure is directed to systems and methods for assigning and deploying aircraft into skylanes. The computing system can include assignment generation engines, which can determine particular skylanes and/or aircraft for servicing trip requests within a transportation ecosystem. For example, the computing system can may access data indicative of a request for aerial transportation indicating a user desires to travel from a first vertiport (e.g., aerial transport hub) to a second vertiport. The computing system may identify that a particular skylane is available for such a route and will be available within the desire timeframe. Additionally, or alternatively, the computing system can determine that a particular aircraft (e.g., an eVTOL of manufacturer A) is available and suitable to transport the user and would be appropriate for the particular skylane given the aircraft's noise envelope, size, etc. In some implementations, the aircraft may be selected first and the computing system may determine (or refine) a particular skylane for the selected aircraft. These skylane and aircraft determinations can be based on aircraft itinerary, types of aircraft and operators/owners, aircraft operating characteristics, etc.
The computing system may also be configured to intelligently deploy aircraft into skylanes based on a timing sequence. For instance, as further described herein, the computing system may determine a timing sequence for deploying aircraft into the same, or adjacent, skylanes to avoid, for example, noise constrain violations. The computing system can do so while also ensuring that riders are able to reach their ultimate destinations within the estimated times of arrival. Deploying an eVTOL aircraft in accordance with the described techniques thus means to strategically initiate motion or launch of the eVTOL aircraft, by providing deployment instructions to: (i) a pilot operating the eVTOL aircraft and/or (ii) a control system onboard the eVTOL aircraft.
These and other aspects of the disclosed technology offer numerous technical effects and benefits, including but not limited to improved route planning, an improved framework for route selection, and an improved representation of skylanes in a planning network. For example, the improved route planning described herein, allows transportation network to achieve ultra-high aircraft throughput by properly organizing flows of air traffic into skylanes, which may be changed during real-time operation to accommodate changing demand patterns, weather, airspace restrictions, or other dynamic considerations.
The skylane network can be dynamically generated and updated using a combination of considerations that do not need to be known or reanalyzed for each new flight request. The considerations can include, for example, distance from origin to destination, noise sensitivity along a flight path, distance to a backup landing site, separation from traditional air traffic (e.g., arrival and departure flow at airports), and avoiding terminal airspace. This can help save computing resources by avoiding unnecessary processing rework, which can lead to latency during real-time operations.
Furthermore, a skylane network improves integration with air traffic control (ATC) by providing insight into intentions of aircraft using the network. Moreover, the skylane network can allow the ATC to determine if these aircraft are not in conformance, and simplifies aircraft tracking, trajectory prediction, intent inference, conflict detection and resolution, and other airspace services and functional requirements. This can lead to increased computational efficiency for ATC, allowing it to better focus its resources on its core functionalities.
The visualization of the skylane network can also improve operations of a transportation network. For instance, as described herein, the skylane network can be represented by a directed graph of nodes and edges. Nodes can correspond to various locations within a particular geographic area as well as waypoints along a skylane between locations. Directed edges can correspond to direction of travel between various nodes in the directed graph representation. The directed graph representation can be rendered on an interactive user interface that allows for waypoint manipulation through interaction with the directed graph. This configuration allows for more efficient route planning techniques such as shortest path determinations, or other travel path determination algorithms, as well as improved path adjustment in real-time. As such, an operator is able to more quickly approve a new skylane or skylane update leading to increased skylane deployment and usage.
A combination of ground vehicles, aircraft, or other types of vehicles can perform the various legs of the multi-modal transportation service. Each transportation leg of the multi-modal transportation service can be associated with a respective transportation modality. For instance, the first transportation leg 102 can be associated with a first transportation modality using one or more of ground vehicles 108 such as an automobile. A second transportation leg 104 can be associated with a second transportation modality using an air-based modality such as an aircraft 107. The third transportation leg 106 can be associated with a third transportation modality, which can be the same or different from the first or second modalities. For example, the third transportation leg 106 can use a ground modality such as another automobile, bicycle, walking route, etc.
The multi-modal transportation service can be provided in an on-demand manner. The service can include a ridesharing, ride-hailing, or delivery service. The multi-modal transportation service can be coordinated for a user 110 by one or more service providers. A service provider can be an entity that offers, coordinates, manages, etc. a transportation service. This can include a transportation network company, vehicle fleet manager, etc. For example, a user 110 may desire to travel on a journey from an origin location 112 to a destination location 114. The user 110 can interact with a user device 116, via a user interface of a software application, to book transportation for the journey. The user 110 can interact with user device 116 over one or more user sessions.
Based on the user sessions, at least one service entity can compile one or more options for an itinerary for the journey for user 110. At least one option for the journey can include the multi-modal transportation service. Responsive to selection of the multi-modal transportation service option, the service can be initiated for transportation for user 110.
Building itineraries on-demand across modalities can involve centralized or distributed scheduling of resources associated with each modality. For instance, example implementations can involve systems and devices that interface with user 110, systems and devices associated with a first modality of transportation, and systems and devices associated with a second modality of transportation.
The itinerary of the user 120 can be based on the user's origin location, destination location, available intermediate locations for transitioning between transportation modalities, vehicle routes, and/or other information. For example,
Multiple users can be pooled together for multi-modal transportation services, such that different user itineraries can share at least one transportation leg. This can include pooling users to share an intermediate transportation leg (e.g., a flight on an aircraft), even though the users may have different origin or destination locations.
By way of example, a first user itinerary for a first user can include three transportation legs 215, 220, and 225 (shown in bold in
A second user itinerary for a second user can include three transportation legs 240, 220, and 245 (shown in bold in
The first user and the second user can be pooled together for the intermediate transportation leg 220. For example, the first user itinerary and the second user itinerary can respectively indicate that the first user and the second user are to travel in the same flight of an aircraft traveling along route 210A, to transport the users between aerial facility 205A and aerial facility 205B. In this manner, the first and second users can share at least one transportation leg for cost and power efficient multi-modal transportation.
The intermediate locations within a multi-modal transportation service can be configured to help seamlessly transition users from one transportation leg or modality to another. As described herein, these intermediate locations can include aerial facilities for facilitating the takeoff (e.g., departure) and landing (e.g., arrival) of aircraft utilized in a multi-modal transportation service. By way of example,
The aerial facility 300 can include a structure or area for transitioning a user to and from an aerial transportation leg of a multi-modal transportation service. The aerial facility 300 can be located in a geographic area where multi-modal transportation services are offered. For instance, the aerial facilities can include a building or designated area within a geographic environment. In some implementations, the aerial facility 300 can be a portion (e.g., a roof, dedicated floors, etc.) of a building or structure that may be used for other purposes (e.g., commercial, residential, industrial, parking, etc.).
The aerial facility 300 can include one or more sensors 345. The sensors can include visual, audio, or other types of sensors. For example, the sensors can include cameras, microphones, vibration sensors, motion sensors, RADAR sensors, LIDAR sensors, infrared sensors, temperature sensors, humidity sensors, other weather condition sensors, etc. The sensors 345 can be configured to obtain sensor data (e.g., noise data, weather data, aircraft-related data, etc.) within and around the aerial facility 300.
The aerial facility 300 can include one or more output devices. The output devices can include display screens, speakers, lighting elements, or other infrastructure to communicate information to users, facility operators, vehicle operators, or other individuals at the aerial facility 300. For example, display screens can be utilized to indicate an aircraft assigned to a user and a parking location assigned to an aircraft. The aerial facility 300 can include paths for users to travel to and/or from aircraft. In some implementations, the output devices (e.g., lighting elements) can help indicate the paths to the users.
The aerial facility 300 can include one or more access points 350 for user ingress and egress. The access points 350 can include designated areas, elevators, stairwells, etc. The access points 350 can also help users to transition between transportation legs and the different modalities associated therewith. For example, after being dropped-off at the aerial facility 300 by a ground-based vehicle for a first transportation leg, a user can utilize an access point 350 to enter an area 355 for checking-into a flight for the next transportation leg, an area for boarding an aircraft, etc. After unloading from the aircraft at the aerial facility 300, a user can utilize an access point 350 to access an area 360 for boarding a ground-based vehicle for a last transportation leg.
An aerial facility 300 can be operated by various entities. For example, a service entity that manages a fleet of aircraft and/or coordinates a transportation service can own, control, operate, etc. the aerial facility 300. In some implementations, the aerial facility 300 can be owned, controlled, operated, etc. by a third-party facility provider. The third-party facility provider may not have its own aircraft fleet but may operate the aerial facility 300 and/or permit other entities to utilize the aerial facility 300.
The aerial facility 300 can be utilized by a single entity or shared among a plurality of entities. For example, a service entity that manages/operates a fleet of aircraft can own, lease, control, operate, etc. the entire aerial facility 300. The service entity and its associated fleet may exclusively utilize the aerial facility 300, such that aircraft outside the service entity's fleet are not permitted at the aerial facility 300, except in emergency circumstances. In another example, a first service entity that manages/operates a first fleet of aircraft can share the aerial facility 300 with a second service entity that manages/operates a second fleet of aircraft. In some implementations, certain resources at the aerial facility 300 can be assigned to a particular fleet or service entity. For example, a first set of landing pads, parking pads, infrastructure, storage areas, waiting areas, etc. can be designated for the first service entity and its associated fleet. A second set of landing pads, parking pads, infrastructure, storage areas, waiting areas, etc. can be designated for the second service entity and its associated fleet. In some implementations, the resources at the aerial facility 300 can be shared such that the shared resources can be assigned dynamically, throughout an operational time period based on user/aircraft itineraries, charging needs, etc.
The aerial facility 300 can include an aerial facility computing system, not shown in
Service provider systems 400 can include a scheduler 402 that builds on-demand multi-modal itineraries. Scheduler 402 can communicate with ground transportation platform (GTP) systems 404 to allocate one or more ground vehicles (or other ground modalities), corresponding to one or more ground vehicle devices 406, for servicing the first leg 102. Scheduler 402 can communicate with aerial transportation platform (ATP) systems 408 to allocate an aerial facility, corresponding to one or more aerial facility devices 410, for transitioning user 110 from first leg 102 to second leg 104. Scheduler 402 can communicate with ATP systems 408 to allocate space on an aircraft 107, corresponding to one or more aircraft devices 412, for servicing the second leg 104. Scheduler 402 can communicate with ATP systems 408 to allocate another aerial facility, corresponding to one or more other aerial facility devices 410, for transitioning user 110 from second leg 104 to third leg 106. Scheduler 402 can communicate with GTP systems 404 to allocate a ground vehicle 108, corresponding to one or more ground vehicle devices 406, for servicing the third leg 106. The GTP systems 404 (and types of ground modalities) associated with first leg 102 can be the same as or different from the GTP systems 404 (and types of ground modalities) associated with third leg 106.
Scheduler 402 can be a back-end coordination layer that communicates with GTP systems 404 and ATP systems 408. Scheduler 402 can be implemented external to either one or both of GTP systems 404 and ATP systems 408, such as on its own server systems. Scheduler 402 can be implemented internally by either one or both of GTP systems 404 and ATP systems 408. For instance, a first system associated with a first type of transportation modality (e.g., ground transport) can be a primary orchestrator that compiles an itinerary using scheduler 402 to request, from a second system associated with a second type of transportation modality (e.g., aerial transport), availability data for assets associated with the second modality. User devices 116 can thus communicate with the first system to obtain a complete multi-modal itinerary.
In some implementations, GTP systems 404 can implement scheduler 402. User devices 116 can communicate with GTP systems 404 to request a transportation service for a journey. For instance, user devices 116 can execute an application associated with the GTP systems 404 (e.g., an application associated with a service entity that controls GTP systems 404). GTP systems 404 can request, from ATP systems 408, availability of aircraft for compiling, with scheduler 402, a multi-modal itinerary for providing the transportation service. User devices 116 can receive the proposed multi-modal itinerary from GTP systems 404. For instance, user devices 116 can view the proposed multi-modal itinerary in the application associated with the GTP systems 404.
In some implementations, ATP systems 408 can implement scheduler 402. User devices 116 can communicate with ATP systems 408 to request a transportation service for a journey. For instance, user devices 116 can execute an application associated with the ATP systems 408 (e.g., an application associated with a service entity that controls ATP systems 408). ATP systems 408 can request, from GTP systems 404, availability of ground vehicles (or walking instructions) for compiling, with scheduler 402, a multi-modal itinerary for providing the transportation service. User devices 116 can receive the proposed multi-modal itinerary from ATP systems 408. For instance, user devices 116 can view the proposed multi-modal itinerary in the application associated with the ATP systems 408.
In an example, the second system can be the primary orchestrator. The first system associated with a first type of transportation modality (e.g., ground transport) can request, from the second system associated with a second type of transportation modality (e.g., aerial transport), a transportation service that includes transportation along a leg of a multi-modal journey that uses the second type of transportation modality. The second system can compile a complete multi-modal itinerary that includes transportation along a leg of a multi-modal journey that uses the second type of transportation modality. The second system can communicate with the first system to schedule transportation services for one or more legs of the itinerary. The second system can then return one or more completed itineraries to the first system. User devices 116 can thus communicate with the first system to obtain a complete multi-modal itinerary.
For instance, user devices 116 can communicate with GTP systems 404 to request a transportation service for a journey. For instance, user devices 116 can execute an application associated with the GTP systems 404 (e.g., an application associated with a service entity that controls GTP systems 404). GTP systems 404 can request, from ATP systems 408, an aerial transportation service along a leg of the journey. ATP systems 408 can obtain availability data for its aircraft to service the requested leg. Based on the availability data, ATP systems 408 can request, from GTP systems 404, availability of ground vehicles (or walking instructions) for a transportation service along a leg preceding the aerial leg and along a leg succeeding the aerial leg. ATP systems 408 can, with scheduler 402, compile a multi-modal itinerary for providing the transportation service. ATP systems 408 can communicate the compiled itinerary to GTP systems 404. User devices 116 can receive the proposed multi-modal itinerary from GTP systems 404. For instance, user devices 116 can view the proposed multi-modal itinerary in the application associated with the GTP systems 404.
User devices 116 can include computing devices owned or otherwise accessible to a user of a transportation service. For example, a user device 116 can include a hand-held computing device (e.g., a phone, a tablet, etc.), a wearable computing device (e.g., smart watch, smart glasses, etc.), personal desktop devices, or other devices. User devices 116 can execute one or more instructions to run an instance of a software application for a respective transportation platform and present user interfaces associated therewith. User devices 116 can include personal devices (e.g., a mobile device) or shared devices on which a user has initiated a personal session (e.g., by logging into a public kiosk or display device in a vehicle, etc.).
As described herein, GTP systems 404 can be associated with a service entity that provides a ground transportation service. GTP systems 404 can include a computing platform (e.g., a cloud services platform, server system, etc.) communicatively connected over networks 502 to one or more of the systems or devices of networked ecosystem 500.
GTP systems 404 can include or implement one or more client-facing software applications accessible to the devices of networked ecosystem 500. Users can interact with the GTP systems 404 (e.g., using user devices 116, ground vehicle devices 406, aircraft devices 412) to receive various types of transportation services (e.g., delivery, ridesharing, or ride-hailing, etc.) including the multi-modal transportation services described herein. For example, a GTP system 404 can match one of its associated ground vehicles or operators with users for a ground transportation service.
GTP systems 404 can be associated with ground infrastructure for facilitating the performance of a ground transportation service. The ground infrastructure can include one or more parking areas, vehicle transfer hubs, charging/fueling locations, storage facilities, etc.
GTP systems 404 can be associated with a fleet of ground vehicles (e.g., cars) and the vehicle operators can include a network of ground vehicle operators. The network of ground vehicle operators can include drivers or remote operators that facilitate, oversee, or control the movement of ground vehicles available to perform ground transportation services.
Ground vehicle devices 406 can include computing devices or systems associated with a ground vehicle or operator. For example, ground vehicle devices 406 can include one or more vehicle computing systems such as, for example, an onboard computer for operating the vehicle, an autonomy system, an infotainment system, etc. Additionally, or alternatively, ground vehicle devices 406 can include an operator's user device (e.g., a driver's mobile phone, etc.). In some implementations, ground vehicle devices 406 can include a user device that remains onboard a ground vehicle such as, for example, a tablet that is available to a passenger or operator.
ATP systems 408 can be associated with one or more service entities that provide at least an aerial transportation service to users. ATP system 408 can include a computing platform (e.g., a cloud services platform, server system, etc.) communicatively connected over networks 502 to one or more of the systems or devices of networked ecosystem 500.
ATP systems 408 can include or implement one or more client-facing software applications accessible to the devices of networked ecosystem 500. Users can interact with ATP system 408 (e.g., using user devices 116, ground vehicle devices 406, aircraft devices 412) to receive various types of information related to a transportation service. For example, a user (e.g., a rider) can interact an ATP system 408 via an instance of a software application (e.g., a rider app) running on user device 116 to request and book a multi-modal transportation service. A facility operator can interact with an ATP system 408 via an instance of a software application (e.g., an operations app) running on an aerial facility device 410 (e.g., a facility operator user device) to view/adjust flight information, seat assignments, etc.
ATP systems 408 can be associated with one or more aircraft, aircraft operators, aerial facilities (or portions thereof), facility operators, etc. for facilitating the performance of at least an aerial transportation service. For example, the aircraft can include a fleet of aircraft and the vehicle operators can include a network of aircraft operators. The network of aircraft operators can include pilots or remote operators that facilitate, oversee, or control the movement of aircraft available to perform aerial transportation services.
Aerial facilities used for providing a transportation service can include one or more aerial facility devices 410 or one or more facility operators. Aerial facility devices 410 can be positioned at various locations within or around the aerial facility to collect and receive information associated with an aerial transportation service. Aerial facility devices 410 can include one or more charging devices associated with charging infrastructure of the aerial facility, one or more vehicle positioning devices (e.g., motorized tugs, etc.), one or more sensors or surveillance devices (e.g., noise sensors, cameras, etc.), etc. Facility operators can be associated with an aerial facility to assist users with security checks, check-ins, boarding/de-boarding, performing aircraft checks, etc. Aerial facility devices 410 can include facility operator user devices, such as user devices used by the facility operators. Facility operator user devices can be used to communicate with a transportation platform or perform various functions at an aerial facility. For example, facility operator user devices can run one or more software applications to complete security checks, check in/out luggage, coordinate re-charging/refueling, present safety briefings, or the like.
Aircraft devices 412 can include one or more aircraft computing systems or aircraft operator user devices. For instance, aircraft devices 412 can include a computing system onboard an aircraft such as a pilot interface, an avionics system, an infotainment system, a navigation system, an autonomy system, or any other sensors or devices located on an aircraft and capable of sending or receiving information. Aircraft devices 412 can include an aircraft operator's user device (e.g., a pilot's mobile phone). Aircraft devices 412 can include a user device that remains onboard the aircraft such as, for example, a tablet or display that is available to a passenger or operator.
Airspace systems 504 can include one or more airspace data exchanges or otherwise be associated with regulatory bodies configured to collect real-time, historical, or regulatory airspace data. The airspace systems 504 can include, for example: (i) aggregating systems that pool airspace data associated with an airspace; (ii) third-party monitoring systems configured to monitor aspects of an airspace (e.g., noise, etc.); or (iii) regulatory systems that can confirm, validate, or approve an aerial transportation service before takeoff based on one or more policies or standards set by a regulatory body (e.g., Federal Aviation Administration, European Aviation Safety Agency, etc.).
Third-party provider systems 506 can be associated with one or more third parties that provide resources to ATP systems 408 or GTP systems 404. Third-party provider systems 506 can be associated with a third-party aircraft provider, including one or more “third-party” aircraft or one or more third-party aircraft operators. Third party aircraft can include aircraft provided, leased, loaned, or otherwise made available by an entity for use by ATP systems 408 for transportation services. Third-party aircraft operators can include, for example, a plurality of aircraft pilots that may be available to ATP systems 408 for operation of an aircraft for the transportation services.
In some implementations, third-party provider systems 506 can be associated with a third-party facility provider that can provide facilities (or facility resources) for use in performing transportation services. For example, the third-party facility provider can own, operate, etc. one or more aerial facilities (or portions thereof) that can be rented, leased, or otherwise utilized by a transportation platform system for providing an aerial transportation service. ATP system 408 or the GTP system 404 can communicate directly or indirectly (e.g., through the third-party provider systems 506) with the third-party aircrafts, operators, or infrastructure.
To facilitate an on-demand multi-modal transportation service for a particular service request associated with user devices 116, scheduler 402 can generate itinerary data structures 508. As illustrated in
Aspects of dynamic aircraft routing system 600 are described herein as pertaining to a particular geographic area. Such particular geographic area can include a comprehensive geographic area associated with aviation transport or a smaller subset of such a geographic area. A particular geographic area analyzed by dynamic aircraft routing system 600 can include a country, state, county, city, town, or other municipality, a portion of a grid overlayed on a geographic area (e.g., a square mile, a square kilometer, or other portion of an area), a portion of an area defined with a point of interest as the center (e.g., a geographic area having a particular radius defined to surround a particular vertiport for operation of eVTOL aircraft). Although some examples of geographic areas are depicted herein, the subject systems and methods can apply to other particular geographic areas.
Airspace database 610 can include one or more portions of data associated with the airspace of a particular geographic area in which eVTOL aircraft can be configured to travel. In one implementation, airspace database 610 is included within dynamic aircraft routing system 600. In another implementation, the data stored within airspace database 610 is stored remotely from dynamic aircraft routing system 600 and can be accessed over one or more wired or wireless communication networks, such as network 680.
Airspace data stored in airspace database 610 can include, for example, regional map data 612, aircraft track data 614, and restricted zone data 616. Airspace data stored in airspace database 610 can be configured to define one or more available portions of a particular geographic area for eVTOL aircraft travel. In some implementations, available portions of a particular geographic area suitable for eVTOL aircraft travel can be computed based on where a first type of other aircraft have previously flown within the airspace of a particular geographic area. In some implementations, available portions of a particular geographic area suitable for eVTOL travel can be computed based on where a second type of other aircraft have previously flown within the airspace of a particular geographic area.
Regional map data 612 can include high-definition (HD) map data for use by the dynamic aircraft routing system or other aspects of the subject aviation transport network. For example, regional map data 612 can include customized maps created for purposes of aviation transport by a first-party or third-party fleet of aircraft (e.g., eVTOL aircraft). In other examples, regional map data 612 can include publicly available map data accessed for purposes of skylane generation and updating in accordance with the disclosed techniques. Regional map data 612 can include data in the form of ground charts and/or aeronautical charts. Regional map data 612 can include one or more layers of feature data, image data, raster data, and/or vector data provided in a variety of suitable file formats including but not limited to CSV, TSV, KML, KMZ, ESRI, TIFF, GPX, and/or XLSX files or other file formats suitable for interfacing with Geographic Information Systems (GIS) applications. In some implementations, regional map data 612 can be accessed by skylane network generation system 620 for computational processing to generate and/or update skylanes within a network of skylanes.
Regional map data 612 can further include landmark data associated with landmarks within a particular geographic area. Landmarks identified within the regional map data 612 may correspond to an object or feature of a landscape or region that is easily seen and recognizable from a distance. Landmarks and associated data can be especially useful for eVTOL pilots to establish their location by way of visual reference relative to one or more landmarks. Landmark data stored within regional map data 612 can include one or more categories of identifying information including, but not limited to, landmark name, landmark location, landmark parameters, and/or landmark designations (e.g., permissions or restrictions) for various skylane routing and travel.
The landmark data within regional map data 612 can be processed as part of dynamically determining and/or updating skylanes as described herein. Landmarks can be selectively activated and/or deactivated for use as waypoints or other locations along a skylane. For example, a landmark such as the White House in Washington, D.C. may be associated with a flight restriction such that it cannot be set as a skylane waypoint or part of an activated skylane for travel. In another example, landmarks such as the Statue of Liberty or the Hudson River in New York are readily identifiable in that geographic area and can enhance visual flight readiness while traversing skylanes near such landmarks. Such landmarks may be associated with a landmark designation (e.g., permission) that permits selection of the landmark as a waypoint or other point for incorporation in a dynamically generated or currently activated skylane. As such, skylane network generation system 620 can compute skylane route data for a particular skylane by determining waypoints in three-dimensional space relative to the landmark data or other data provided within regional map data 612.
Aircraft track data 614 can include geographic or map-based data indicative of locations traveled by an aircraft in a particular geographic area. Aircraft track data 614 can thus correspond to historical data indicative of previous routes flown that are repurposed in a unique manner as described herein. An example of aircraft track data 614 is depicted in
Aircraft track data 614 can correspond to locations traveled by an aircraft in the particular geographic area within a particular time or range of time (e.g., in a given hour, a given day, a given week, etc.). Aircraft track data 614 can correspond to locations traveled by a particular type of aircraft. For instance, aircraft track data 614 can correspond to locations traveled by a same type of aircraft (e.g., eVTOL) for which skylanes are generated and updated as described herein. In other instances, aircraft track data 614 can correspond to locations traveled by a type of aircraft having operational parameters in a particular range (e.g., aircraft configured for travel at airspeeds of less than about 300 knots (e.g., between 100 knots and 200 knots). This particular range may include rotary-wing aircraft and some smaller/slower fixed wing aircraft (e.g., propeller planes) but exclude larger/faster fixed-wing aircraft such as turbo props and/or jets. Utilizing aircraft track data 614 for aircraft that have at least some degree of similarity to eVTOL aircraft can help to identify potential suitable corridors for eVTOL aircraft travel within the particular geographic area. As such, skylane network generation system 620 can compute skylane route data for a particular skylane by determining waypoints in three-dimensional space relative to the aircraft track data 614.
Restricted zone data 616 can include geographic or map-based data indicative of portions of a particular geographic area that are unavailable for eVTOL travel. As such, skylane network generation system 620 can compute skylane route data for a particular skylane by determining waypoints in three-dimensional space relative to the restricted zone data 616.
Restricted zone data 616 can include location data associated with takeoff and landing paths for other aircraft operating in the particular geographic area. The other aircraft associated with takeoff and landing paths within restricted zone data 616 can correspond to a different type of aircraft than eVTOL aircraft. For example, restricted zone data 616 can include location data associated with takeoff and landing paths for a type of aircraft having operational parameters in a particular range (e.g., aircraft configured for travel at airspeeds of greater than about 300 knots). This particular range may include larger/faster fixed-wing aircraft such as turbo props and/or jets but exclude eVTOL aircraft, rotary-wing aircraft and some smaller/slower fixed-wing aircraft such as propeller planes. An example of restricted zone data 616 corresponding to location data associated with takeoff and landing paths for other aircraft operating in the particular geographic area is depicted as takeoff and landing paths 722 in
Restricted zone data 616 can additionally or alternatively include location data associated with a no-fly zone designated by a regulating body of the airspace within the particular geographic area (e.g., Federal Aviation Administration (FAA), European Aviation Safety Agency, etc.). Restricted zone data 616 can identify excluded airspace location data defined by other types of Notices to Airmen (NOTAM) including a Temporary Flight Restriction (TFR) or other data defining a geographic area restricted to air travel due to a hazardous condition, special event, or other airspace restriction. An example of restricted zone data 616 corresponding to no-fly zones is geographically depicted in
In some implementations, additional airspace data stored within airspace database 610 can include information provided by the airspace systems 420. The airspace systems 420 can include one or more airspace data exchanges or otherwise be associated with regulatory bodies configured to collect real-time, historical, or regulatory airspace data. The airspace data can include information regarding the weather, air-traffic, or regulatory approval for flight operations in an airspace. The airspace systems 420 can include, for example: (i) aggregating systems that pool airspace data associated with an airspace; (ii) third-party monitoring systems configured to monitor aspects of an airspace (e.g., noise, etc.); and/or (iii) regulatory systems that can confirm, validate, or approve an aerial-based transportation service before takeoff based on one or more policies or standards set by a regulatory body (e.g., Federal Aviation Administration, European Aviation Safety Agency, etc.).
Additional airspace data provided by the airspace systems 420 or otherwise included within airspace database 610 can include real-time airport or vertiport configuration data. Airports can select among different possible configurations for incoming and outgoing flight traffic at different days and different times. As such, access to real-time airport configuration data can be important to dynamic determination and updating of skylanes within a given geographic area associated with other airports and/or vertiports. As such, skylane network generation system 620 can generate and/or activate skylane route data for a particular skylane based at least in part on a determination that the skylane (or waypoints, segments, or portions thereof) do not interfere with airspace currently occupied by incoming or outgoing air traffic based on a particular airport configuration as identified within the airspace database 610.
Referring still to
Skylane route generation system 622 can be configured to generate a network of skylanes for eVTOL aircraft travel in the particular geographic area. For example, skylane route generation system 622 can be configured to compute skylane route data for a particular skylane (e.g., a new skylane) within the network of skylanes based at least in part on the airspace data accessed from airspace database 610. Additional aspects of computing the skylane route data for a particular skylane are described herein with reference to
The generation of a new skylane can be triggered due to the detection of one or more initiating events by skylane route generation system 622. For example, skylane route generation system 622 can detect an initiating event corresponding to the designation of a new vertiport for eVTOL aircraft operation. New vertiports can correspond, for example, to one of the aerial facilities 205A-E depicted in
Additionally, or alternatively, skylane route generation system 622 can detect an initiating event corresponding to a request for a new skylane relative to an existing vertiport within the eVTOL transport network. A new skylane may be needed to address changing operation of the eVTOL transport network. For instance, a new skylane may be needed to accommodate an increased volume of trip requests relative to the existing vertiport, a decommissioning of an existing skylane (e.g., for failure to satisfy operating constraints associated with the existing skylane), an updated configuration of a nearby airport, an updated availability of parameter data, etc. The request for a new skylane relative to an existing vertiport can be initiated automatically based on route assessments computed by the skylane route assessment system 624, or can be initiated based on a manual request for new skylanes from an entity, such as but not limited to an aircraft provider or aerial facility operator. Skylane route data for a new skylane can then be determined from a first vertiport location associated with the existing vertiport to a second vertiport location within the particular geographic area that can be serviced from the first vertiport location of the existing vertiport.
Still further, skylane route generation system 622 can detect an initiating event corresponding to a trip request for transport of passengers and/or goods within a particular geographic area. For example, trip request data 684 from a user device 682 (or from another entity such as a service provider of ground and/or aerial vehicles) can include a first vertiport location and a second vertiport location between which aerial transport is requested. In response to receipt of the trip request data 684, skylane route generation system 622 can be triggered to generate skylane route data for a new skylane between the first vertiport location and the second vertiport location.
In response to detecting one or more of the initiating events, skylane route generation system 622 can be configured to send a request to the airspace database 610 to access airspace data defining an available portion of the particular geographic area for the eVTOL travel. For example, the skylane route generation system 622 can request access to regional map data 612, aircraft track data 614, and/or restricted zone data 616. Based on the airspace data accessed from airspace database 610, skylane route generation system 622 can be configured to compute skylane route data for a particular skylane defined by a plurality of waypoints in three-dimensional space between a first vertiport location and a second vertiport location for the eVTOL aircraft in the particular geographic area. In some implementations, computing skylane route data for a particular skylane can include computing first skylane route data and second skylane route data. The first skylane route data can define a first plurality of waypoints for travel in a first direction from the first vertiport location to the second vertiport location. The second skylane route data can define a second plurality of waypoints for travel in a second direction from the second vertiport location to the first vertiport location.
In some implementations, the skylane route data for the particular skylane also includes a plurality of altitude profiles associated with the plurality of waypoints in three-dimensional space. For example, skylane route data can include fixed waypoints in latitudinal and longitudinal dimensions and a plurality of altitude profiles from which to select among. The plurality of altitude profiles can include, for example, a first altitude profile at a first altitude, a second altitude profile at a second altitude that is different than the second altitude, a third altitude that is different than the first altitude and the second altitude, etc.
Skylane route data for a particular skylane can additionally or alternatively include an operational volume defining a three-dimensional corridor of airspace around a route associated with the particular skylane between the first vertiport location and the second vertiport location. The operational volume represents a piece (or segment) of airspace that surrounds a flight path, route, or trajectory. In one example, an operational volume is a three-dimensional representation of the skylane between two locations (e.g., first vertiport location and second vertiport location). In other examples, the operational volume is defined by the four-dimensional coordinates of its sectional geometry. The types of geometry include, for example, a polygon with a rectangular section having eight vertices (e.g., four on a bottom section and four on a top section) and a tube with a circular section defined by a radius and a length of the tube.
Different types of geometry can be used for different types of aircraft and/or based on the preference of an entity associated with the aircraft (e.g., vendor, manager, manufacturer, third-party operator). In some examples, a vehicle (e.g., aircraft) configuration performance can be taken into consideration to define an operational volume. For example, if the aircraft flies vertically (e.g., a VTOL), it may not need as large of volume to fly in as other types of aircraft. As such, the volume can be reduced around the configuration performance since the aircraft is good at climbing vertically. As such, the operational volume generation process can build static volume around routes but can also create volumes that are appropriate around aircraft type to match its profile instead of being bigger to encompass more possibilities.
Skylane route data for a particular skylane can additionally or alternatively include a directed graph representation of nodes and edges, the first vertiport location and the second vertiport location corresponding to nodes within the directed graph representation. In some implementations, the waypoints between the first vertiport location and the second vertiport location also correspond to nodes within the directed graph representation. Waypoints can correspond to landmarks or other intermediate geographic locations between respective vertiport locations. In this way, segments of skylanes defined between waypoints can be generated and/or subsequently evaluated and/or updated such that portions of skylanes can be advantageously analyzed on a more granular level. The directed edges between nodes in the directed graph representation (e.g., nodes corresponding to first and second respective vertiport locations) can include, for example, a first directed edge corresponding to a first direction of travel from the first vertiport location to the second vertiport location and a second directed edge corresponding to a second direction of travel from the second vertiport location to the first vertiport location.
Skylane route data for a particular skylane can additionally or alternatively include one or more operating constraints associated with the particular skylane. For instance, an operating constraint associated with respective skylanes of a skylane network can include a type of eVTOL aircraft designated for travel on the respective skylanes. In another example, an operating constraint associated with respective skylanes can include a speed for eVTOL aircraft designated for travel on the respective skylanes. In yet another example, an operating constraint associated with respective skylanes can include a noise limit defining a threshold visual noise level or a threshold audible noise level established for the particular geographic area. Still further, an operating constraint associated with respective skylanes can include a weather condition limit defining an acceptable level of a temperature, a pressure, a wind condition, or a visibility condition established for the particular geographic area. Operating constraints associated with particular skylanes can be defined in terms of one or more ranges of acceptable values or one or more threshold values (e.g., a minimum threshold value a parameter must be greater than or a maximum threshold value a parameter must be less than). Operating constraints associated with particular skylanes can be stored in the form of metadata defining the operating constraint saved in conjunction with skylane route data for the particular skylanes in the skylane network.
After new skylanes are computed by skylane route generation system 622, the skylane route generation system 622 can be configured to process the new skylanes in accordance with one or more quality analysis computations. For example, skylane route generation system 622 can be configured to implement a flight simulation of a simulated eVTOL aircraft traveling on the particular skylane. If the automated flight simulation is successful, then a newly generated skylane can be added to a skylane network. In some instances, the automated flight simulation may identify one or more updates to the newly generated skylane that must be made before being retested and potentially later added to the skylane network.
Referring still to
Parameter data stored in parameter database 640 can be obtained in different fashions. For example, parameter data can be gathered periodically in a variety of manners. For instance, parameter data can be actively provided or passively requested from sensors or other databases at particular intervals (e.g., daily, hourly, every minute, every second, or even every fraction of a second). Some or all parameter data in parameter database 640 can include a timestamp that indicates the time at which the parameter data was acquired, location data (e.g., GPS coordinates) that indicates a location at which the parameter data was acquired, and/or fidelity data descriptive of an accuracy level associated with the parameter data.
Parameter data in parameter database 640 can be computed based on information from one or more onboard sensors 676 and/or one or more offboard sensors 678. As shown in
The network 680 can be any type of network or combination of networks that allows for communication between devices. In some implementations, the network 680 can include one or more of a local area network, wide area network, the Internet, secure network, cellular network, mesh network, peer-to-peer communication link and/or some combination thereof and can include any number of wired or wireless links. Communication over the network 680 can be accomplished, for instance, via a network interface using any type of protocol, protection scheme, encoding, format, packaging, etc.
Aircraft data 642 can be provided by individual aircraft at particular time points, such as when an aircraft comes online and is ready to provide vehicle services. Aircraft data 642 can additionally or alternatively be provided by individual aircraft in response to periodically transmitted requests for information sent to aircraft by the dynamic aircraft routing system 600. Aircraft data 642 can include identification and status information associated with aircraft operating in the particular geographic area (e.g., eVTOL aircraft in a particular fleet or airspace). Aircraft data 642 can be provided by individual aircraft at particular time points, such as when an aircraft comes online and is ready to provide vehicle services. Aircraft data 642 can additionally or alternatively be provided by individual aircraft in response to periodically transmitted requests for information sent to aircraft by the dynamic aircraft routing system 600. Aircraft data 642 can include a unique vehicle identification (VID) and/or data indicative of the vehicle type, vehicle gross weight, aircraft configuration data including seating capacity and seating arrangement, vehicle battery capacity, and/or operator information. Aircraft data 642 can also include aircraft state information including the current charge level, the maintenance status and/or health condition of the VTOL aircraft, and the distance to the next service or maintenance event. In some examples, aircraft data 642 can include location parameter data defining takeoff and landing paths for other aircraft operating in the particular geographic area, similar to aircraft track data 614 for other aircraft that are a different type than the eVTOL aircraft. Aircraft data 642 can alternatively include runway use data indicative of current runways in use at an aircraft facility for aircraft operating within the particular geographic area.
Weather data 644 can include data defining a temperature, a pressure, a wind condition, or a visibility condition associated with the particular geographic area. In general, weather data 644 can characterize the weather and microclimates around vertiports. This may assist with safe and efficient aircraft (e.g., eVTOL) operation. In dense urban environments, a sudden change in weather conditions can result in wind conditions which may significantly alter the way aircraft land and depart from vertiports. In one embodiment, weather data 644 can be gathered via temperature, barometric, LIDAR (moisture monitoring), and radar data (S or X band). Changes in weather may additionally or alternatively be indirectly calculated based on perceived changes in IR or multispectral data from aircraft. This indirect delta may take into account the aircraft's routing history, age, and temporal effects. Weather data 644 can included monitored ground effect and gusts at final approaches and take offs (FATOs) and touchdowns and liftoffs (TLOFs). Using sensors to characterize velocity and pressure fields close to the ground plane can then be compared to predictive characterizations of the vertiport may help schedule vehicle takeoffs and landings and reduce the likelihood of performance challenges.
Wildlife data 646 can include data from one or more of multispectral sensors, IR, radar, cameras, and microphones to sense ground and air wildlife. The synthesis of sensor data from more than one source may assist in the correct identification of the type of wildlife and determine a proper response. Real-time presence of wildlife and/or determinations of historical trends of wildlife presence in particular portions of airspace can help shape the generation of skylanes and/or activation of particular skylanes for a particular timeframe. Use of wildlife data 646 in skylane generation, assessment, and or selection can help reduce the likelihood of aircraft, sensing, and infrastructure assets being negatively affected by direct or indirect effects of wildlife proximity, such as habitation or waste.
Noise data 648 can include data descriptive of an aircraft's noise signature and/or perceived noise impact from a particular ground location (e.g., vertiport location) within a particular geographic area. Noise data 648 can be descriptive of audible noise such as determined by microphones or other acoustic sensors. Noise data 648 can be additionally or alternatively descriptive of visual noise such as determined by cameras, LIDAR sensors, or other image-based sensors. Noise data 648 can be collected and aggregated by multiple onboard and/or offboard sensors, which can be affixed to ground based infrastructure (e.g., at vertiports), ground vehicles, air vehicles, and/or user devices (e.g., smartphones). At any given time, a data collection radius around a vertiport may be defined to determine which sensors to use for data collection relevant to the vertiport. In the case of noise collectors (e.g., microphones), the sensors may receive a signal to turn on (if not already on) and then begin collecting noise data 648. This data may be processed onboard the collector initially to filter out irrelevant or irregular noise patterns before sending to the parameter database 640. At the network level, additional processing may occur to generate a location-based noise or perception map which can then be made available to the vertiport to help with operational or airspace related decision-making.
Payload data 650 can include another type of aircraft data descriptive of one or more payload constraints and/or payload tracking associated with respective aircraft. For example, the payload data 650 can include at least one of a payload capacity (e.g., maximum allowable payload, weight, etc.), a seating capacity (e.g., a maximum number of passengers per flight), one or more vehicle control parameters (e.g., operational capabilities such as turning radius, lift, thrust, or drag capabilities), one or more speed parameters (e.g., maximum, minimum, or average speed, etc.), of respective aircraft. Payload data 650 can include payload tracking in the form of payload estimates for flights and/or actual sensor-obtained payload measurements for pilots, passengers, and or luggage or other goods transported by respective aircraft.
Pilot/passenger application data 652 can include data obtained by pilots and/or passengers that have an aviation transport application on a user device operated by such respective users. For example, pilot/passenger application data 652 can include location data from an application associated with a pilot or a passenger currently traveling on a particular skylane of the plurality of skylanes. The pilot/passenger application data 652 can include location data that can be used as an alternative to or addition to location data provided within aircraft data 642.
Referring still to
In the context of skylane route generation system 622, skylane route data for a new skylane can be computed based at least in part on parameter data from parameter database 640. For example, a plurality of waypoints in three-dimensional space between a first vertiport location and a second vertiport location can be computed to define a skylane for an eVTOL aircraft in the particular geographic area, wherein the skylane route data for the particular skylane is computed based at least in part on the parameter data. For instance, noise data 648 can be accessed by the skylane route generation system 622. Skylane route data for a new skylane can be computed based on the noise data 648 to ensure that a new skylane is generated in an area that does not already approach a noise limit based on current noise data measurements or predictions. In another example, wildlife data 646 can be accessed by the skylane route generation system 622. Skylane route data for a new skylane can be computed based on the wildlife data to ensure that a new skylane is generated in an area that does not include a significant regular presence of wildlife (e.g., a migratory bird corridor) that may interfere with aircraft operation.
In the context of skylane route assessment system 624, respective skylanes can be evaluated relative to one more operating constraints of the respective skylanes. For example, skylane route assessment system 624 can be configured to access skylane network data stored within skylane route generation system 622, including data defining an operating constraint associated with respective skylanes in a network of skylanes.
Skylane route assessment system 624 can also access parameter data from parameter database 640. The parameter data accessed by skylane route assessment system 624 can include estimated parameter data 672 defining expected operating parameters associated with a particular geographic area at a particular travel time. The parameter data accessed by skylane route assessment system 624 can also include updated parameter data 674 defining current, real-time, or near real-time operating parameters associated with the particular geographic area at a particular travel time.
In some instances, the estimated parameter data 672 can serve as predicted parameter data used to evaluate skylanes in a first iteration as part of a first route assessment at a first time that is farther from a particular travel time for an aircraft and/or skylane. The updated parameter data 674 can be used to evaluate skylanes in at least a second iteration as part of a second route assessment at a second time that is closer to a particular travel time for an aircraft and/or skylane. In other words, estimated parameter data 672 can be used for a first route assessment at a first time, while updated parameter data 674 can be used for a second route assessment at a second time that is subsequent to the first time of the first route assessment. Additional iterations of route assessments at a third time, fourth time, etc. can also be employed. By conducting multiple route assessments across multiple different times, route assessments can be conducted as early as possible for planning purposes but refined for greater accuracy closer to an actual travel time.
Route assessments computed by skylane route assessment system 624 can be configured to evaluate an operating constraint associated with respective skylanes relative to the estimated parameter data. In some implementations, the route assessment determines that an operating constraint for a particular skylane can be met given the parameter data from parameter database 640. In some implementations, the route assessment determines that an operating constraint for a particular skylane cannot be met given the parameter data from parameter database 640. For example, consider an operating constraint for a particular skylane that includes a noise limit defining a threshold audible noise level established for the particular geographic area including the particular skylane. If current noise data 648 for the particular skylane indicates that the noise level remains below the noise limit established by the operating constraint, then the particular skylane can remain open. If current noise data 648 for the particular skylane indicates that the noise level exceeds the noise limit established by the operating constraint, then the particular skylane can be closed. Opening and closing of skylanes is further described herein with respect to skylane route activation system 626.
In the context of skylane route activation system 626, respective skylanes can be activated (or opened) and/or deactivated (or closed) based at least in part on the route assessments conducted by skylane route assessment system 624. For instance, a subset of skylanes less than or equal to all skylanes in a network of skylanes can be activated when parameter data associated with those skylanes indicates that those skylanes satisfy the various operating constraints relative to parameter data as evaluated by skylane route assessment system 624. For skylanes having parameter data that violate or otherwise fail to satisfy operating constraints, that subset of skylanes can be deactivated or closed within the network of skylanes. Activation of a subset of skylanes can define that subset as available skylanes for e VTOL travel, while deactivation of a subset of skylanes can define that subset as unavailable skylanes for eVTOL travel. It should be appreciated that the activation and/or deactivation implemented by skylane route activation system 626 can be computed on a periodic basis such that the activation/deactivation can change as parameters are updated over time.
Activation and/or deactivation of skylanes by skylane route activation system 626 can be implemented on entire skylanes or particular portions thereof. For instance, skylane route assessment system 624 can evaluate segments of a skylane. Segments can correspond to a portion of a skylane defined by a particular length or volume (e.g., every 100 yards, every cubic decimeter, etc.) Instead of evaluating an entire skylane at once, segments of skylanes are evaluated on an individual basis to determine if the segments respectively satisfy an operating constraint relative to current parameter data. If a segment is computed to satisfy the operating constraint, then the segment can be activated as available for eVTOL travel by skylane route activation system 626. If a segment is computed to violate the operating constraint, then the segment (and by default the entire skylane) can be deactivated as unavailable for eVTOL travel. Skylane route assessment system 624 can additionally or alternatively evaluate multiple altitude profiles for a particular skylane. When an altitude profile satisfies an operating constraint relative to parameter data, that altitude profile can be activated as available for eVTOL travel. When an altitude profile violates an operating constraint relative to parameter data, that altitude profile can be deactivated as unavailable for eVTOL travel.
Activation and/or deactivation of skylanes by skylane route activation system 626 can be implemented on nodes and edges of a skylane network when the network is represented using a directed graph representation of nodes and edges. For example, if vertiports or other locations in a particular geographic area correspond to nodes in a directed graph representation and skylanes or segments of skylanes correspond to edges in the directed graph representation, activating a subset of skylanes in a network of skylanes can correspond to activating and/or deactivating a subset of the nodes and edges within the directed graph representation as available/unavailable for aircraft travel. Examples of node and edge activation such as implemented by skylane route activation system 626 are depicted in
In the context of dynamic skylane updating system 628, skylane network data 670 or skylane route data for particular skylanes in the skylane network can be updated based on the route assessments computed by skylane route assessment system 624 and/or the activation/deactivation of skylanes or portions thereof computed by skylane route activation system 626. The instances of skylane network data 670 or portions thereof can be maintained in a skylane network database within skylane network generation system or can be relayed to a separate location, such as a trip assignment generation system 660 that uses skylane network data 670 to assign and deploy a particular eVTOL to travel on a particular skylane (e.g., a skylane in an activated subset of skylanes) in the skylane network. Dynamic skylane updating system 628 can additionally or alternatively be configured to generate visual content for presentation via a user interface (e.g., a map-based user interface) accessible by a computing system of an aircraft, an ATP platform, a passenger device, pilot device, or the like. For instance, the visual content can include the directed graph representation of the particular skylane, including nodes, edges, and waypoints associated with the particular skylane. The dynamic skylane updating system 628 can also be configured to initiate presentation of the visual content including the directed graph representation of the particular skylane on the map-based user interface. For example, the directed graph representation of the particular skylane can be overlayed on or integrated with (e.g., as a layer or feature of) map data for display on the map-based user interface.
Referring still to
Trip assignment generation system 660 can be configured to select one or more particular skylane(s) to service a trip request and to select particular aircraft for servicing the trip request. Trip assignment generation system 660 can also compute a departure time for deployment of the particular aircraft into the selected skylane(s). These skylane and aircraft determinations can be based on aircraft itinerary, types of aircraft and operators/owners (e.g., 1P vs. 3P aircraft), aircraft operating characteristics, etc. Additional details can be related to a timing sequence of deploying aircraft into skylanes and coordinating across multiple skylanes (e.g., adjacent skylanes).
Trip assignment generation system 660 of
Trip assignment generation system 660 can also be configured to compute a selected skylane 662 from the candidate skylanes for servicing the trip request. When the plurality of skylanes are respectively depicted as a directed graph representation of nodes and edges, computing the selected skylane for serving at least a portion of a trip request can include determining a path along edges in the directed graph representation that minimize a cost function between a node corresponding to the origin location and a node corresponding to the destination location. In some examples, determining the selected skylane 662 can be based on historical trip data indicative of previous trips between the origin location and the destination location.
Trip assignment generation system 660 can also be configured to compute a selected aircraft 664 for servicing the trip request. In some instances, a plurality of candidate aircraft 632 are computed from among a fleet of aircraft for servicing the trip request at the particular travel time. For example, aircraft network database 630 can store aircraft data for an entire fleet of aircraft and/or for a subset of the fleet corresponding to candidate aircraft 632. Candidate aircraft can be determined based on an aircraft assessment configured to evaluate an operating constraint associated with respective aircraft of the fleet of aircraft relative to parameter data for the particular geographic area at the particular travel time. For instance, an aircraft operating constraint may require that aircraft have a current battery charge greater than a threshold level (e.g., a threshold voltage level, a threshold percentage level of total charge capacity, etc.) in order to be considered in the subset of candidate aircraft 632 for servicing a trip request. A selected aircraft 664 can then be determined from the plurality of candidate aircraft for servicing the trip request at the particular travel time. Methods for computing the selected aircraft 664 can be based on cost function analysis, machine-learned models, or other evaluation methods.
Trip assignment generation system 660 can also be configured to compute a departure time 666 for deployment of the selected aircraft 664 from the origin location into the selected skylane 662. The departure time 666 can be determined based on the particular travel time and updated parameter data associated with the plurality of skylanes at the particular travel time. Departure time 666 can be computed based on one or more adjustments to a particular travel time (e.g., a travel time defined by the trip request data 684). A first example adjustment to the particular travel time used to determine departure time 666 can be based on availability of an aircraft, pilot, and/or additional passengers. For instance, although a particular passenger may request a particular travel time, that time may need to be adjusted sooner or later based on an arrival time at a departure vertiport of an aircraft, pilot, and/or additional passengers assigned to the same aircraft. A second example adjustment to the particular travel time used to determine departure time 666 can be based on other aircraft assigned for deployment into the selected skylane before the particular travel time. For instance, if another aircraft is assigned for deployment into the same skylane thirty seconds before a particular travel time and one minute is required between aircraft deployments, then the departure time 666 for selected aircraft 664 can be adjusted later by thirty seconds or more to accommodate the required spacing. A third example adjustment to the particular travel time used to determine departure time 666 can be based on other aircraft assigned for deployment into the selected skylane after the particular travel time. For instance, if another aircraft is assigned for deployment into the same skylane thirty seconds after a particular travel time and one minute is required between aircraft deployments, then the departure time 666 for selected aircraft 664 can be adjusted earlier by thirty seconds or more to accommodate the required spacing between successive deployments. A fourth example adjustment to the particular travel time used to determine departure time 666 can be based on updated parameter data for a particular geographic area associated with the selected skylane. For instance, if updated parameter data indicates a weather condition associated with the selected at a particular travel time, then departure time 666 can be adjusted to a time when the parameter data is predicted to change and satisfy an operating constraint of the skylane.
With more particular reference to
Referring now to
Referring now to
Referring now to
Turning now to
Turning now to
An example of a network of flight paths or skylanes is shown in
Example embodiments are directed to generating an optimized network of skylanes and an operations volume around each of these skylanes in which an aircraft should operate. A network system (e.g., a transport network coordination system) creates a source network of paths, whereby the source network comprises a set of possible paths between two locations. The network system assigns a cost for traversing each edge of each path of the source network and aggregates the cost for traversing each edge of each path to obtain a cost for each path of the source network. Based on the cost for each path, the network system identifies a path having the lowest cost, whereby the path having the lowest cost is the computed route between the two locations. The network system then generates an operations volume or other syklane route data for the particular skylane. The skylane route data can be transmitted to a further system for use. As such, example embodiments provide the technical effect of enhancing flight planning and improving flight paths.
At step 902, a computing system can detect an initiating event that triggers generation of a new skylane. For example, detecting an initiating event at step 902 can correspond to the designation of a new vertiport for eVTOL aircraft operation. New vertiports can correspond, for example, to one of the aerial facilities 205A-E depicted in
At step 904, a computing system can access airspace data defining an available portion of the particular geographic area for eVTOL aircraft travel. In some examples, the airspace data accessed at step 904 can include aircraft track data indicative of locations traveled by an aircraft in the particular geographic area. An example of aircraft track data obtained at step 904 can include aircraft track data 614 described with reference to
At step 906, a computing system can compute skylane route data for a particular skylane. The skylane route data computed at 906 can include a plurality of waypoints in three-dimensional (3D) space between a first vertiport location and a second vertiport location, wherein the skylane route data is based on the airspace data accessed at step 904. The skylane route data computed at 906 for a particular skylane can be based on aircraft track data. More particularly, determining a plurality of waypoints in three-dimensional space relative to the aircraft track data can include determining a plurality of waypoints that are within a threshold distance of at least one of a plurality of previously flown aircraft tracks between a first vertiport location (or location near a first vertiport location) and a second vertiport location (or location near a second vertiport location). Tracking with previously flown aircraft tracks for aircraft having similar operating parameters can help generate new skylanes for eVTOL aircraft based on previously tested aircraft tracks that have been proven as safe and effective for aircraft operation. The skylane route data computed at 906 for a particular skylane can also be based on restricted zone data. More particularly, determining a plurality of waypoints in three-dimensional space relative to the restricted zone data can include determining a plurality of waypoints that exclude or avoid the restricted zones. In some examples, the plurality of waypoints determined at step 906 are greater than a threshold distance away from the restricted zones. For example, unavailable airspace volumes may be determined around restricted zones, such as represented by unavailable portions 744 and 746 of
In some implementations, computing skylane route data for a particular skylane at step 906 can include computing first skylane route data and second skylane route data. The first skylane route data can define a first plurality of waypoints for travel in a first direction from the first vertiport location to the second vertiport location. The second skylane route data can define a second plurality of waypoints for travel in a second direction from the second vertiport location to the first vertiport location.
In some implementations, computing skylane route data for a particular skylane at step 906 can include computing a plurality of altitude profiles associated with the plurality of waypoints in three-dimensional space. For example, skylane route data can include fixed waypoints in latitudinal and longitudinal dimensions and a plurality of altitude profiles from which to select among. The plurality of altitude profiles can include, for example, a first altitude profile at a first altitude, a second altitude profile at a second altitude that is different than the second altitude, a third altitude that is different than the first altitude and the second altitude, etc.
In some implementations, computing skylane route data for a particular skylane at step 906 can include computing an operational volume defining a three-dimensional corridor of airspace around a route associated with the particular skylane between the first vertiport location and the second vertiport location. The operational volume represents a piece (or segment) of airspace that surrounds a flight path, route, or trajectory. In one example, an operational volume is a three-dimensional representation of the skylane between two locations (e.g., first vertiport location and second vertiport location). In other examples, the operational volume is defined by the four-dimensional coordinates of its sectional geometry. The types of geometry include, for example, a polygon with a rectangular section having eight vertices (e.g., four on a bottom section and four on a top section) and a tube with a circular section defined by a radius and a length of the tube. Different types of geometry can be used for different types of aircraft and/or based on the preference of an entity associated with the aircraft (e.g., vendor, manager, manufacturer, third-party operator). In some examples, a vehicle (e.g., aircraft) configuration performance can be taken into consideration to define an operational volume. For example, if the aircraft flies vertically (e.g., a VTOL), it may not need as large of volume to fly in as other types of aircraft. As such, the volume can be reduced around the configuration performance since the aircraft is good at climbing vertically. As such, the operational volume generation process can build static volume around routes but can also create volumes that are appropriate around aircraft type to match its profile instead of being bigger to encompass more possibilities.
In some implementations, computing skylane route data for a particular skylane at step 906 can include computing a directed graph representation of nodes and edges, the first vertiport location and the second vertiport location corresponding to nodes within the directed graph representation. In some implementations, the waypoints between the first vertiport location and the second vertiport location also correspond to nodes within the directed graph representation. In this way, segments of skylanes defined between waypoints can be generated and/or subsequently evaluated and/or updated such that portions of skylanes can be advantageously analyzed on a more granular level. The directed edges between nodes in the directed graph representation (e.g., nodes corresponding to first and second respective vertiport locations) can include, for example, a first directed edge corresponding to a first direction of travel from the first vertiport location to the second vertiport location and a second directed edge corresponding to a second direction of travel from the second vertiport location to the first vertiport location.
In some implementations, computing skylane route data for a particular skylane at step 906 can include computing one or more operating constraints associated with the particular skylane. For instance, an operating constraint associated with respective skylanes of a skylane network can include a type of eVTOL aircraft designated for travel on the respective skylanes. In another example, an operating constraint associated with respective skylanes can include a speed for eVTOL aircraft designated for travel on the respective skylanes. In yet another example, an operating constraint associated with respective skylanes can include a noise limit defining a threshold visual noise level or a threshold audible noise level established for the particular geographic area. Still further, an operating constraint associated with respective skylanes can include a weather condition limit defining an acceptable level of a temperature, a pressure, a wind condition, or a visibility condition established for the particular geographic area. Operating constraints associated with particular skylanes can be defined in terms of one or more ranges of acceptable values or one or more threshold values (e.g., a minimum threshold value a parameter must exceed or a maximum threshold value a parameter must subceed). Operating constraints associated with particular skylanes can be stored in the form of metadata defining the operating constraint along saved in conjunction with skylane route data for the particular skylanes in the skylane network. Still further aspects of computing skylane route data for a particular skylane at step 906 are described with reference to
At step 908, a computing system can update a network of available skylanes for eVTOL aircraft travel in the particular geographic area by adding the skylane route data for the particular skylane to the network of available skylanes. Instances of a skylane network and skylane route data for particular skylanes in the skylane network can be stored, updated, and maintained in a skylane network database within skylane network generation system or can be relayed to a separate location, such as a trip assignment generation system or the like. Adding skylane route data for a particular skylane to a network of available skylanes can include storing additional information associated with a skylane, including but not limited to additional details for the plurality of waypoints as well as metadata indicative of one or more operating constraints defined for the particular skylane (e.g., type of aircraft, speed limit of aircraft, noise limit for skylane, weather limits for skylane, volume of air traffic on skylane, etc.)
At step 910, a computing system can deploy a particular eVTOL aircraft to travel on the particular skylane upon selection of the particular skylane from the network of available skylanes. In some examples, deploying a particular e VTOL aircraft at step 910 can include providing deployment instructions to initiate takeoff of the eVTOL aircraft into the particular skylane (e.g., to fulfill a trip assignment). Deploying a particular aircraft at step 910 to travel on the particular skylane upon selection of the particular skylane does not necessarily limit step 910 to occurring immediately upon selection of the particular skylane. Instead, deploying a particular aircraft at step 910 may occur after implementing additional intervening operations or determining additional conditions being met in between selection of a particular skylane and deploying an aircraft into the particular skylane. In other words, additional or alternative conditions may be needed beyond selection of a particular skylane to trigger aircraft deployment. Further aspects of deploying a particular eVTOL aircraft to travel on a particular skylane are described with reference to
At step 912, a computing system can fit skylane route data between first and second vertiport locations to aircraft data for other aircraft having similar operational parameters. Fitting skylane route data at step 912 can include determining a plurality of waypoints in three-dimensional space that are within a threshold distance of at least one of a plurality of previously flown aircraft tracks between a first vertiport location (or location near a first vertiport location) and a second vertiport location (or location near a second vertiport location). Tracking with previously flown aircraft tracks for aircraft having similar operating parameters can help generate new skylanes for eVTOL aircraft based on previously tested aircraft tracks that have been proven as safe and effective for aircraft operation.
At step 914, a computing system can adjust skylane route data to exclude areas defined as restricted zones. Adjusting skylane route data at step 914 can include adjusting the plurality of waypoints determined at step 912 to exclude or avoid the restricted zones. In some examples, the plurality of waypoints determined at step 912 can be adjusted at step 914 to be greater than a threshold distance away from the restricted zones.
At step 916, a computing system can verify a skylane by implementing a flight simulation of a simulated eVTOL aircraft traveling on the skylane. If the automated flight simulation implemented at step 916 is successful, then a newly generated skylane can be added to a skylane network. In some instances, the automated flight simulation may identify one or more updates to the newly generated skylane that must be made before being retested and potentially later added to the skylane network.
At step 922, a computing system can access skylane network data indicative of a plurality of skylanes for eVTOL aircraft travel among a plurality of vertiports. For example, the skylane network data accessed at step 922 can include accessing the skylane network data generated by skylane route generation system 622 of
The skylane network data accessed at step 922 can include an operating constraint associated with respective skylanes of the plurality of skylanes. For instance, an operating constraint associated with respective skylanes of a skylane network can include a type of eVTOL aircraft designated for travel on the respective skylanes. In another example, an operating constraint associated with respective skylanes can include a speed for eVTOL aircraft designated for travel on the respective skylanes. In yet another example, an operating constraint associated with respective skylanes can include a noise limit defining a threshold visual noise level or a threshold audible noise level established for the particular geographic area. Still further, an operating constraint associated with respective skylanes can include a weather condition limit defining an acceptable level of a temperature, a pressure, a wind condition, or a visibility condition established for the particular geographic area. Operating constraints associated with particular skylanes can be defined in terms of one or more ranges of acceptable values or one or more threshold values (e.g., a minimum threshold value a parameter must exceed or a maximum threshold value a parameter must subceed).
At step 924, a computing system can access parameter data indicative of current or expected operating parameters associated with the particular geographic area at a particular travel time. Parameter data accessed at step 924 can be accessed from a parameter database, such as parameter database 640 depicted in
In some implementations, the parameter data accessed at step 924 can include estimated parameter data and updated parameter data. Estimated parameter data (e.g., estimated parameter data 672 of
At step 926, a computing system can compute a route assessment of the plurality of skylanes to evaluate the operating constraint relative to the parameter data. Further aspects of computing a route assessment of a plurality of skylanes at step 926 are described with reference to
Route assessments computed at step 926 can be configured to evaluate an operating constraint associated with respective skylanes relative to the estimated parameter data. In some implementations, the route assessment computed at step 926 determines that an operating constraint for a particular skylane can be met given the parameter data accessed at step 924. In some implementations, the route assessment computed at step 926 determines that an operating constraint for a particular skylane cannot be met given the parameter data accessed at step 924. For example, consider an operating constraint for a particular skylane that includes a noise limit defining a threshold audible noise level established for the particular geographic area including the particular skylane. If current noise data accessed at step 924 indicates that the noise level for a particular skylane remains below the noise limit established by the operating constraint, then the particular skylane can remain open. If current noise data accessed at 924 indicates that the noise level exceeds the noise limit established by the operating constraint, then the particular skylane can be closed. Opening and closing of skylanes is further described herein with respect to step 928 of method 920.
At step 928, a computing system can activate a subset of skylanes of the plurality of skylanes as available skylanes for the eVTOL aircraft travel based at least in part on the route assessment at step 926. Further aspects of activating a subset of skylanes at step 928 are described with reference to
At step 930, a computing system can deploy a particular eVTOL aircraft to travel on a particular skylane upon selection of the particular skylane from the subset of available skylanes. Further aspects of deploying a particular eVTOL aircraft to travel on a particular skylane at step 930 are described with reference to
At step 932, a computing system can determine in a first iteration whether an operating constraint for a particular skylane is satisfied based on estimated parameter data. The estimated parameter data utilized in the computation of step 932 can serve as predicted parameter data used to evaluate skylanes in a first iteration as part of a first route assessment at a first time that is farther from a particular travel time for an aircraft and/or skylane. In other words, a first computation iteration based on estimated parameter data at step 932 can be used for a first route assessment at a first time.
At step 934, a computing system can determine in a second iteration whether an operating constraint for a particular skylane is satisfied based on updated parameter data. The updated parameter data utilized in the computation of step 934 can be used to evaluate skylanes in at least a second iteration as part of a second route assessment at a second time that is closer to a particular travel time for an aircraft and/or skylane. In other words, a second computation iteration based on updated parameter data at step 934 can be used for a second route assessment at a second time at is subsequent to the first time of the first route assessment. Additional iterations of route assessments at a third time, fourth time, etc. can also be employed.
At step 936, a computing system can determine a particular skylane as satisfying or violating an associated operating constraint based on the first iteration determined at step 932 and/or the second iteration determined at step 934. By conducting multiple route assessments across multiple different times to implement the computation at step 936, route assessments can be conducted as early as possible for planning purposes but refined for greater accuracy closer to an actual travel time.
At step 938, a computing system can close a particular skylane of a plurality of skylanes that violates the operating constraint relative to the parameter data. In some examples, the computing system can close one or more segments, altitude profiles, and/or other portions of a skylane. Referring to the example depicted in
At step 940, a computing system can open a particular skylane of a plurality of skylanes that satisfies the operating constraint relative to the parameter data. In some examples, the computing system can open one or more segments, altitude profiles, or other portions of a skylane. Referring to the example depicted in
At step 942, a computing system can access trip request data for passenger travel between an origin location and a destination location. Trip request data accessed at step 942 can correspond, for example, to trip request data 684 depicted in
At step 944, a computing system can select the particular skylane from the network of available skylanes for servicing at least a portion of the trip request. Further aspects of computing a selected skylane at step 944 are described with reference to
At step 952, a computing system can access trip request data defining a trip request for aerial transport at a particular travel time from an origin location to a destination location within a particular geographic area. For example, the trip request accessed at step 952 can include trip request data 684, such as that depicted in
At step 954, a computing system can access skylane network data indicative of a plurality of skylanes for eVTOL travel in the particular geographic area. For example, the skylane network data accessed at step 954 can include the skylane network data generated by skylane route generation system 622 of
The skylane network data accessed at step 954 can include an operating constraint associated with respective skylanes of the plurality of skylanes. For instance, an operating constraint associated with respective skylanes of a skylane network can include a type of eVTOL aircraft designated for travel on the respective skylanes. In another example, an operating constraint associated with respective skylanes can include a speed for eVTOL aircraft designated for travel on the respective skylanes. In yet another example, an operating constraint associated with respective skylanes can include a noise limit defining a threshold visual noise level or a threshold audible noise level established for the particular geographic area. Still further, an operating constraint associated with respective skylanes can include a weather condition limit defining an acceptable level of a temperature, a pressure, a wind condition, or a visibility condition established for the particular geographic area. Operating constraints associated with particular skylanes can be defined in terms of one or more ranges of acceptable values or one or more threshold values (e.g., a minimum threshold value a parameter must exceed or a maximum threshold value a parameter must subceed).
At step 956, a computing system can compute a subset of the plurality of skylanes as candidate skylanes for serving a trip request. The candidate skylanes computed at step 956 can be determined based on a route assessment configured to evaluate an operating constraint associated with respective skylanes relative to parameter data for the particular geographic area at the particular travel time. Aspects of computing a subset of the plurality of skylanes as candidate skylanes for servicing the trip request can include some of the features and techniques described with reference to steps 924-928 of
At step 958, a computing system can compute a selected skylane from the candidate skylanes for servicing the trip request at the particular travel time. Further aspects of computing a selected skylane at step 958 are described with reference to
At step 959, a computing system can generate a trip assignment for deployment of an eVTOL aircraft from the origin location into the selected skylane. A trip assignment generated at step 959 can include data and/or instructions for facilitating the fulfilment of the request for aerial transport set forth in the trip request accessed at step 952. For example, the trip assignment can include trip assignment data including the selected skylane, a selected e VTOL aircraft, the origin location, the destination location, time of aircraft deployment, passenger/payload details for the particular trip, and other related information as determined, for example, by the trip assignment generation system 660 of
Referring now to
At step 962, a computing system can compute a selected aircraft from the plurality of candidate aircraft for servicing the trip request at the particular travel time. Further aspects of computing a selected aircraft at step 964 are described with reference to
At step 963, a computing system can compute a departure time for deployment of the aircraft from the origin location into the selected skylane. Further aspects of computing a departure time for deployment of the aircraft at step 966 are described with reference to
At step 964, a computing system can access updated parameter data at a time subsequent to the generation of the trip assignment at step 959 of
At step 965, a computing system can compute the selected skylane from the candidate skylanes for servicing the trip request at the particular travel time based on the updated parameter data accessed at step 964. Step 965 can be similar to step 958, further aspects of which are described with reference to
At step 966, a computing system can generate an updated trip assignment for deployment of the aircraft from the origin location into the selected skylane. The updated trip assignment generated at 966 can be similar to step 959, but updated to include any additional changes based on the updated parameter data accessed at step 964 and or recomputation of a selected skylane at step 965.
At step 967, a computing system can provide deployment instructions to initiate takeoff of the eVTOL aircraft into the selected skylane to fulfill the trip assignment. Providing deployment instructions at step 967 can serve to effectively deploy an eVTOL aircraft by initiating motion or launch of the eVTOL aircraft. Deployment instructions can be provided at step 967 to: (i) a pilot operating the eVTOL aircraft and/or (ii) a control system onboard the eVTOL aircraft.
At step 970, a computing system can assign one or more weights to the nodes and/or edges within a directed graph representation of the skylane network.
At step 972, a computing system can determine a cost function for a travel path defined between a node corresponding to the origin location and a node corresponding to the destination location. In some instances, the cost function can be determined based on graph theory, such as a cost function defined in terms of determining a shortest path between nodes. Cost functions can be defined using one or more algorithms for determining shortest paths in a graph, including but not limited to Dijkstra's algorithm, Bellman-Ford algorithm, Floyd-Marshall algorithm, Johnson's algorithm, Viterbi algorithm, etc.
At step 974, a computing system can determine a path in the directed graph representation that optimizes (e.g., minimizes) the cost function. In some examples, determining a path at 974 can include determining a path between two nodes in a directed graph representation such that the sum of the weights of its constituent edges are minimized.
At step 976, a computing system can determine in a first iteration whether an operating constraint for a particular aircraft is satisfied based on estimated parameter data.
At step 978, a computing system can determine in a second iteration whether an operating constraint for a particular aircraft is satisfied based on estimated parameter data.
At step 980, a computing system can determine a particular aircraft as satisfying or violating an associated operating constraint based on the first iteration implemented in step 976 and/or the second iteration implemented in step 978.
At step 972, a computing system can determine a cost function for evaluating aircraft traveling between a node corresponding to the origin location and a node corresponding to the destination location.
At step 974, a computing system can determine a selected aircraft that minimizes the cost function determined at step 972.
At step 976, a computing system can determine a first adjustment to the particular travel time based on availability of an aircraft, pilot, and/or additional passengers. For instance, although a particular passenger may request a particular travel time, that time may need to be adjusted sooner or later based on an arrival time at a departure vertiport of an aircraft, pilot, and/or additional passengers assigned to the same aircraft.
At step 978, a computing system can determine a second adjustment to the particular travel time based on aircraft assigned for deployment into the selected skylane before the particular travel time. For instance, if another aircraft is assigned for deployment into the same skylane thirty seconds before a particular travel time and one minute is required between aircraft deployments, then the departure time 666 for selected aircraft 664 can be adjusted later by thirty seconds or more to accommodate the required spacing.
At step 980, a computing system can determine a third adjustment to the particular travel time based on aircraft assigned for deployment into the selected skylane after the particular travel time. For instance, if another aircraft is assigned for deployment into the same skylane thirty seconds after a particular travel time and one minute is required between aircraft deployments, then the departure time 666 for selected aircraft 664 can be adjusted earlier by thirty seconds or more to accommodate the required spacing between successive deployments.
At step 982, a computing system can determine a fourth adjustment to the particular travel time based on updated parameter data for a particular geographic area associated with the selected skylane. For instance, if updated parameter data indicates a weather condition associated with the selected skylane 662 at a particular travel time, then departure time 666 can be adjusted to a time when the parameter data is predicted to change and satisfy an operating constraint of the skylane.
The computing system 1005 can include one or more computing devices 1010. The computing devices 1010 of the computing system 1005 can include one or more processors 1015 and a memory 1020. The processors 1015 can be any suitable processing device (e.g., a processor core, a microprocessor, an ASIC, a FPGA, a controller, a microcontroller, etc.) and can be one processor or a plurality of processors that are operatively connected. The memory 1020 can include one or more non-transitory computer-readable storage media, such as RAM, ROM, EEPROM, EPROM, one or more memory devices, flash memory devices, etc., and combinations thereof.
The memory 1020 can store information that can be accessed by the processors 1015. For instance, the memory 1020 (e.g., one or more non-transitory computer-readable storage mediums, memory devices) can include computer-readable instructions 1025 that can be executed by the processors 1015. The instructions 1025 can be software written in any suitable programming language or can be implemented in hardware. Additionally, or alternatively, the instructions 1025 can be executed in logically and/or virtually separate threads on processors 1015.
For example, the memory 1020 can store instructions 1025 that when executed by the processors 1015 cause the processors 1015 to perform operations such as any of the processes/methods described herein or any of the operations and functions of any of the computing systems (e.g., aerial transportation platform system, ground transportation platform system, third-party provider system, airspace system, computing system 1005, etc.) and/or computing devices (e.g., user devices, ground vehicle devices, aircraft devices, aerial facility devices facility operator user devices, computing device 1010, etc.), as described herein.
The memory 1020 can store data 1030 that can be obtained, received, accessed, written, manipulated, created, and/or stored. The data 1030 can include, for instance, any of the data/information described herein. In some implementations, the computing devices 1010 can obtain from and/or store data in one or more memory devices that are remote from the computing system 1005 such as one or more memory devices of the computing system 1050.
The computing devices 1010 can also include a communication interface 1035 used to communicate with one or more other systems (e.g., computing system 1050). The communication interface 1035 can include any circuits, components, software, etc. for communicating via one or more networks (e.g., 1045). In some implementations, the communication interface 1035 can include for example, one or more of a communications controller, receiver, transceiver, transmitter, port, conductors, software and/or hardware for communicating data/information.
The computing system 1050 can include one or more computing devices 1055. The computing devices 1055 can include one or more processors 1060 and a memory 1065. The one or more processors 1060 can be any suitable processing device (e.g., a processor core, a microprocessor, an ASIC, a FPGA, a controller, a microcontroller, etc.) and can be one processor or a plurality of processors that are operatively connected. The memory 1065 can include one or more non-transitory computer-readable storage media, such as RAM, ROM, EEPROM, EPROM, one or more memory devices, flash memory devices, etc., and combinations thereof.
The memory 1065 can store information that can be accessed by the processors 1060. For instance, the memory 1065 (e.g., one or more non-transitory computer-readable storage mediums, memory devices) can store data 1075 that can be accessed e.g., obtained, received, written, manipulated, created, stored, pulled, etc. The data 1075 can include, for instance, any data or information described herein. In some implementations, the computing system 1050 can obtain data from one or more memory devices that are remote from the computing system 1050.
The memory 1065 can also store computer-readable instructions 1070 that can be executed by the processors 1060. The instructions 1070 can be software written in any suitable programming language or can be implemented in hardware. Additionally, or alternatively, the instructions 1070 can be executed in logically and/or virtually separate threads on processors 1060. For example, the memory 1065 can store instructions 1070 that when executed by the processors 1060 cause the processors 1060 to perform any of the operations and/or functions described herein, including, for example, any of the processes/methods described herein or the operations and functions of any of the computing systems (e.g., aerial transportation platform system, ground transportation platform system, third-party provider system, airspace system, computing system 1050, etc.) or computing devices (e.g., user devices, ground vehicle devices, aircraft devices, aerial facility devices facility operator user devices, computing device 1055, etc.), as described herein.
The computing devices 1055 can also include a communication interface 1080 used to communicate with one or more other systems. The communication interface 1080 can include any circuits, components, software, etc. for communicating via one or more networks (e.g., 1045). In some implementations, the communication interface 1080 can include for example, one or more of a communications controller, receiver, transceiver, transmitter, port, conductors, software and/or hardware for communicating data/information.
The networks 1045 can be any type of network or combination of networks that allows for communication between devices. In some implementations, the networks 1045 can include one or more of a local area network, wide area network, the Internet, secure network, cellular network, mesh network, peer-to-peer communication link and/or some combination thereof and can include any number of wired or wireless links. Communication over the networks 1045 can be accomplished, for instance, via a network interface using any type of protocol, protection scheme, encoding, format, packaging, etc.
The use of computer-based systems allows for a great variety of possible configurations, combinations, and divisions of tasks and functionality between and among components. Computer-implemented operations can be performed on a single component or across multiple components. Computer-implemented tasks and/or operations can be performed sequentially or in parallel. Data and instructions can be stored in a single memory device or across multiple memory devices.
Aspects of the disclosure have been described in terms of illustrative implementations thereof. Numerous other implementations, modifications, or variations within the scope and spirit of the appended claims can occur to persons of ordinary skill in the art from a review of this disclosure. Any and all features in the following claims can be combined or rearranged in any way possible. Accordingly, the scope of the present disclosure is by way of example rather than by way of limitation, and the subject disclosure does not preclude inclusion of such modifications, variations or additions to the present subject matter as would be readily apparent to one of ordinary skill in the art.
Moreover, terms are described herein using lists of example elements joined by conjunctions such as “and,” “or,” “but,” etc. It should be understood that such conjunctions are provided for explanatory purposes only. Lists joined by a particular conjunction such as “or,” for example, can refer to “at least one of” or “any combination of” example elements listed therein. The term “or” should be understood as “and/or” unless otherwise indicated. Also, terms such as “based on” should be understood as “based at least in part on.”
Those of ordinary skill in the art, using the disclosures provided herein, will understand that the elements of any of the claims, operations, or processes discussed herein can be adapted, rearranged, expanded, omitted, combined, or modified in various ways without deviating from the scope of the present disclosure. At times, elements can be listed in the specification or claims using a letter reference for exemplary illustrated purposes and is not meant to be limiting. Letter references, if used, do not imply a particular order of operations or a particular importance of the listed elements. For instance, letter identifiers such as (a), (b), (c), . . . , (i), (ii), (iii), . . . , etc. may be used to illustrate operations or different elements in a list. Such identifiers are provided for the ease of the reader and do not denote a particular order, importance, or priority of steps, operations, or elements. For instance, an operation illustrated by a list identifier of (a), (i), etc. can be performed before, after, or in parallel with another operation illustrated by a list identifier of (b), (ii), etc.
This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63/499,955 filed on May 3, 2023. This application is incorporated by reference herein in its entirety and for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 63499955 | May 2023 | US |
