Aircraft share with uncrewed positioning

Abstract

A example method includes accessing request data for a request for an available aircraft to fly, wherein the request is from a user device associated with a user; computing an identifier of an aircraft of a fleet of aircraft to fulfill the request, the aircraft being operable in an uncrewed flight mode compliant with a first flight standard or in a crewed flight mode compliant with a second flight standard, the first flight standard corresponding to regulations for beyond-visual-line-of-sight uncrewed flight and the second flight standard corresponding to regulations for crewed flight; based on the request data and the identified aircraft, computing routing data for the identified aircraft that identifies a planned route for the aircraft; and based on the routing data, selectively causing the aircraft to operate in the uncrewed flight mode or in the crewed flight mode for at least a portion of the planned route.

Description

Aircraft Share with Uncrewed PositioningPRIORITY

[0001] This application claims priority to United States Provisional Patent Application Serial Number 63 / 633,260 (filed April 12, 2024), which is hereby incorporated by reference herein in its entirety.FIELD

[0002] The present disclosure relates generally to aircraft and aircraft fleet systems. More particularly , example implementations of the present disclosure provide for on-demand use of aircraft that can be relocated with uncrewed flight legs.BACKGROUND

[0003] Transportation service applications allow individual users to request transportation. For example, service providers can match drivers / vehicles to requests for transporting a rider to a requested destination or delivering packages, goods, or prepared foods. Computing platforms can be used to help facilitate these services.SUMMARY

[0004] 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.

[0005] Example aspects of the present disclosure provide an example method. The example method can include accessing request data for a request for an available aircraft to fly, wherein the request is from a user device associated with a user. The example method can include computing an identifier of an aircraft of a fleet of aircraft to fulfill the request, the aircraft being operable in an uncrewed flight mode or a crewed flight mode. The example method can include accessing data indicative of a departure location for the user to board the aircraft. The example method can include, based on the aircraft being located away from the departure location, transmitting instructions causing the aircraft to fly to the departure location in the uncrewed flight mode and without any passengers. The example method can include, based on the aircraft being located at the departure location, transmitting instructions causing the aircraft to deactivate the uncrewed flight mode and operate in the crewed flight mode.

[0006] Example aspects of the present disclosure provide for an example one or more non-transitory computer-readable media storing instructions that are executable by one or more processors to perform operations, the operations including the example method.

[0007] Example aspects of the present disclosure provide for an example computing system that 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 including the example method.

[0008] Example aspects of the present disclosure provide for an example aircraft that includes a control actuator for controlling a component of the example aircraft. The example aircraft can include an uncrewed control system coupled to the control actuator using an uncrewed control interlock. The uncrewed control interlock can be configured to prevent, responsive to determining that a person is onboard the example aircraft, the uncrewed control system from controlling the example aircraft. The example aircraft can include a crewed control system coupled to the control actuator using a crewed control interlock. The crewed control interlock can be configured to allow, responsive to authenticating a credential of the person, crewed control of the example aircraft.

[0009] Example aspects of the present disclosure provide for an example aircraft computing system for controlling flight of an aircraft. The example aircraft computing system can include 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 cause the aircraft computing system to perform operations. The operations can include determining that no person is onboard the aircraft. The operations can include, based on determining that no person is onboard the aircraft, controlling, using an uncrewed control system of the aircraft, a flight of the aircraft from a first location to a second location. The operations can include determining that a person is onboard the aircraft. The operations can include disabling, responsive to determining that the person is onboard the aircraft, the uncrewed control system of the aircraft.

[0010] Example aspects of the present disclosure provide for an example remote computing system for disengaging an uncrewed control interlock of an aircraft computing system of an aircraft. The example remote computing system can include 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 cause the example remote computing system to perform operations. The operations can include receiving, from the aircraft computing system, an authentication request for disengaging an uncrewed control interlock of an aircraftcomputing system of an aircraft. The uncrewed control interlock can be configured to prevent, responsive to the aircraft computing system determining that a person is onboard the aircraft, the uncrewed control system from controlling the aircraft. The operations can include determining, based on occupancy data from the aircraft computing system, that no person is onboard the aircraft. The operations can include, based on determining that no person is onboard the aircraft, transmitting, to the aircraft computing system, an authentication key for disengaging the uncrewed control interlock.

[0011] Other example aspects of the present disclosure are directed to other systems, methods, vehicles, apparatuses, tangible non-transitory computer-readable media, and devices for a vehicle request coordination system for a multi-client service environment.

[0012] 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 draw ings, 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.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Detailed discussion of implementations directed to one of ordinary skill in the art is set forth in the specification, which makes reference to the appended figures.

[0014] FIG. 1A depicts a diagram of an example forward journey of a transportation service according to example implementations of the present disclosure.

[0015] FIG. IB depicts a diagram of an example return journey of a transportation service according to example implementations of the present disclosure.

[0016] FIG. 2 depicts a diagram of an example forward journey of a transportation service according to example implementations of the present disclosure.

[0017] FIG. 3A depicts a diagram of an example forward journey of a transportation sendee according to example implementations of the present disclosure.

[0018] FIG. 3B depicts a diagram of an example forward journey of a transportation service according to example implementations of the present disclosure.

[0019] FIG. 4A depicts an example aircraft for implementing aspects of example implementations of the present disclosure.

[0020] FIG. 4B depicts an example aircraft for implementing aspects of example implementations of the present disclosure.

[0021] FIG. 4C depicts an example aircraft for implementing aspects of example implementations of the present disclosure.

[0022] FIG. 5 depicts an example pilot application interface according to example implementations of the present disclosure.

[0023] FIG. 6 is a block diagram of an example certification validation system according to example implementations of the present disclosure.

[0024] FIG. 7 depicts an example pilot application interface according to example implementations of the present disclosure.

[0025] FIG. 8 depicts an example pilot application interface according to example implementations of the present disclosure.

[0026] FIG. 9 depicts an example vertipad verification system according to example implementations of the present disclosure.

[0027] FIG. 10 depicts an example pilot application interface according to example implementations of the present disclosure.

[0028] FIG. 11 depicts an example pilot application interface according to example implementations of the present disclosure.

[0029] FIG. 12 depicts an example pilot application interface according to example implementations of the present disclosure.

[0030] FIG. 13 depicts an example pilot application interface according to example implementations of the present disclosure.

[0031] FIG. 14 depicts an example pilot application interface according to example implementations of the present disclosure.

[0032] FIG. 15 is a block diagram of an example ecosystem of systems and devices according to example implementations of the present disclosure.

[0033] FIG. 16A depicts an example device register for organizing resources associated with example computing systems for providing a transportation service according to example implementations of the present disclosure.

[0034] FIG. 16B depicts an example service instance register for allocating resources associated with example computing systems for providing a transportation service according to example implementations of the present disclosure.

[0035] FIG. 17A depicts an example pilot application interface according to example implementations of the present disclosure.

[0036] FIG. 17B depicts an example vertiport according to example implementations of the present disclosure.

[0037] FIG. 18A depicts an example pilot application interface according to example implementations of the present disclosure.

[0038] FIG. 18B depicts an example pilot application interface according to example implementations of the present disclosure.

[0039] FIG. 18C depicts an example uncrewed relocation leg according to example implementations of the present disclosure.

[0040] FIG. 19 depicts an example pilot application interface according to example implementations of the present disclosure.

[0041] FIG. 20 A depicts a user performing a pre-flight procedure using an example pilot application interface according to example implementations of the present disclosure.

[0042] FIG. 20B depicts an example pilot application interface according to example implementations of the present disclosure.

[0043] FIG. 21 is a block diagram of an example system for a guided pre-flight procedure using an example pilot application interface according to example implementations of the present disclosure.

[0044] FIG. 22 depicts an example pilot application interface according to example implementations of the present disclosure.

[0045] FIG. 23 depicts an example cockpit of an aircraft according to example implementations of the present disclosure.

[0046] FIG. 24 is a block diagram of an example aircraft control system according to example implementations of the present disclosure.

[0047] FIG. 25 depicts an example flow diagram for robustly handing off control between uncrewed and crewed flight control systems according to example implementations of the present disclosure.

[0048] FIG. 26 depicts an example flow diagram for robustly handing off control between uncrewed and crewed flight control systems according to example implementations of the present disclosure.

[0049] FIG. 27 depicts an example flow diagram for robustly handing off control between uncrewed and crewed flight control systems according to example implementations of the present disclosure.

[0050] FIG. 28 depicts an example flow diagram for robustly handing off control between uncrewed and crewed flight control systems according to example implementations of the present disclosure.

[0051] FIG. 29 is a block diagram of an example computing system according to example implementations of the present disclosure.DETAILED DESCRIPTION

[0052] Generally, the present disclosure is directed to aircraft and aircraft fleet systems that can provide on-demand flight serv ices with uncrewed aircraft positioning. In an example implementation, a client device can transmit a request to an aircraft fleet system to reserve an aircraft for a pilot to fly on a trip. The aircraft fleet system can identify an aircraft that matches any constraints in the request. The aircraft fleet system can assign the aircraft to serv ice the request. The aircraft can autonomously or automatically fly from an initial location to rendezvous with the pilot at a departure location. The client device can execute a pre-flight process to prepare the aircraft and the pilot for the journey. The aircraft can enable one or more control interfaces to permit control of the aircraft by the pilot to complete the trip. After completing the trip and determining that the pilot has disembarked, the aircraft can relocate on an uncrewed flight leg for servicing one or more future requests.

[0053] Self-piloted flight can provide bespoke levels of flexibility and enjoyment that are not always attainable with high-volume transportation methods with fixed schedules and designated routes. However, aircraft ownership and maintenance can be very' expensive and time-consuming. Aircraft share or rental organizations can help a group of pilots defray a cost of ownership, but such organizations are generally limited in scale, involve inconvenient scheduling procedures to coordinate among participating pilots, require proximity to a shared hangar space, etc.

[0054] Advantageously, example implementations of the present disclosure can leverage uncrewed aircraft relocation to facilitate improved aircraft utilization rates with more efficient maintenance and scheduling. Aircraft according to example aspects of the present disclosure can be stored, energized (e.g., fueled / charged), and maintained at a service location. This service location can be adapted for aircraft storage and maintenance. This adaptation can allow for improved resource utilization at the service location. The aircraft can rendezvous with pilots at one or more different departure locations. The departure locations can be adapted for boarding and deboarding pilots and passengers. This adaptation can facilitate an improved pilot or passenger experience and isolate other aircraft and systems at the service location from delays or other interruptions that can occur during boarding or deboarding. The departure location for a particular pilot can be selected to improve an aspect of the pilot’s journey. This improvement can help decrease a likelihood of aircraft under-utilization due to overbooking, canceled trips, etc. After a flight leg, the uncrewed aircraft can return to the same or different service location. In this manner, for instance, a pilot can fly from a departure location to a destination location without having to arrange for the aircraft to be kept or serviced.

[0055] Furthermore, uncrewed relocation can allow for a broader range of departure locations and destination locations. For example, in some areas, brief boarding or deboarding events can be more acceptable or permitted than extended storage of an aircraft. For example, some areas can provide facilities or space for boarding or deboarding but lack facilities for extended storage. For instance, a scenic tourist attraction might accommodate transient boarding or deboarding events while long-term parking of aircraft could rapidly increase congestion. By relocating the uncrewed aircraft to a service location when not in use, users and pilots can enjoy broader flexibility to use aircraft to reach various destinations. This increased flexibility can increase utilization rates, thereby improving the economies of scale for maintenance, upkeep, etc. among a shared fleet of aircraft.

[0056] With reference to the Figures, example implementations according to aspects of the present disclosure are discussed in more detail.

[0057] FIG. 1A is a diagram of operations of an example on-demand flight service for an outbound user journey. A client device 102 can receive input from a user 104 that indicates a request for an aircraft to fly on a trip. Client device 102 can communicate over a network 106 with one or more transportation platform systems 108. Transportation platform system 108 can select and assign an aircraft 110 to service the request. Aircraft 1 10 can autonomously or automatically fly from an initial location 112 to rendezvous with user 104 at a departure location 114 for departure (e.g., at or nearby a residence of user 104). This initial flight leg can be an uncrewed aircraft relocation leg 116. User 104 can pilot aircraft 110 from departure location 114 to a subsequent destination 1 18 along a user-piloted travel leg 120.

[0058] Aircraft 110 can relocate away from destination 118 when not in use by user 104. For example, aircraft 110 can return to initial location 112 by initiating an uncrewed aircraft return leg 122. In this manner, for instance, aircraft 110 can return to a supply pool of available aircraft for servicing other requests when not in immediate use by user 104. This can also allow aircraft 110 to vacate a temporary-use landing area.

[0059] FIG. IB is a diagram of further operations of an example on-demand flight service for a user’s return journey. An aircraft 124 (which can be aircraft 110 or another aircraft) can relocate from an initial location 126 (which can be initial location 112 or another location) to a location of user 104 (which can be location 118 or another location) by executing uncrewedaircraft relocation leg 128. User 104 can then pilot aircraft 124 along user-piloted travel leg 130 to return home. After user 104 deboards, aircraft 124 can relocate away from location 114, such as to service other requests from other users or return to initial location 126. For example, aircraft 124 can return to initial location 126 by initiating an un crewed aircraft return leg 132.

[0060] The technology of the present disclosure can provide a number of improvements to aircraft and aircraft computing systems. The technology of the present disclosure can leverage a specific computing ecosystem that can include a number of computing resources, such as server computing systems, aircraft computing devices, user computing devices, etc. The technology described herein can be specifically adapted for implementation on aircraft, aircraft computing systems, and various computing devices that can interact with aircraft and aircraft computing systems.

[0061] An example improvement is improved efficiency of aircraft in flight. For example, uncrewed relocation legs can use different sets of flight constraints as compared to crewed aircraft. For example, crewed aircraft routes might be adapted to decrease a crew flight time due to, for instance, a high crew labor cost, crew work hour regulations, etc. As such, crewed aircraft routes might include flight at a speed higher than a most efficient speed or along a flight path different from a most efficient flight path (e.g., into the wind to shorten a flight distance). In contrast, uncrewed relocation legs can be freed from constraints relating to onboard flight crews, freeing the routing to be adapted for better flight efficiency. Furthermore, the aircraft can be more energy efficient during relocation by not transporting the weight of a crew.

[0062] An example improvement is improved efficiency of aircraft storage and upkeep. Aircraft can require complex supporting infrastructure for performing maintenance, refueling / recharging, and proper storage. By disaggregating service locations from departure locations, example implementations of the present disclosure can facilitate each location type to be adapted appropriately. This can involve laying out a service location infrastructure for improved efficiency in service without necessarily compromising the service efficiency to accommodate boarding / deboarding operations. For instance, charging or refueling infrastructure can be laid out in compact arrangements to decrease transmission losses without needing to provide abundant space for boarding / deboarding. Further, more of a sen-ice location’s area can be dedicated to performing service tasks, increasing the throughput of service tasks (e.g.. maintenance, charging / refueling) at a given service location.This can allow sendee locations to better leverage economies of scale to improve efficiency in all aspects, including labor, utilities, construction, etc.

[0063] An example improvement is improved efficiency of hydrogen fuel cell electric systems for aircraft. For example, hydrogen fuel cell refueling infrastructure can be limited. By disaggregating service locations from departure locations, hydrogen fuel cell refueling infrastructure can be centralized in the service locations and the aircraft, once refueled, can relocate as needed to departure locations. In this manner, hydrogen fuel cell refueling systems can benefit from economies of scale and thereby more fully realize the advantages offered over other energy sources.

[0064] An example improvement is improved efficiency of pilot / passenger boarding and deboarding. In the same manner that service locations can be adapted for service tasks, departure locations and destinations can be selected or constructed for improved flow and throughput as well as proximity to an origin or an ultimate destination. For example, a departure location or destination can be selected from locations distributed throughout a geographic area.

[0065] In an example implementation, a pilot’s origin location can be in a residential area. A departure location can be selected based on proximity to the residential area. For instance, a departure location can be the pilot’s driveway or a shared common area in the residential area that is within walking distance. In this manner, the pilot can initiate the flight leg without needing to engage another modality of transport or can decrease a travel time on the other modality of transport, thereby decreasing congestion of that other modality (e.g., decreasing congestion of a roadway).

[0066] Similarly, a destination can be selected based on a proximity to a user’s ultimate destination, such as a scenic attraction, a restaurant, an office building, etc. By disaggregating the service location from the destination, operating a destination location can be as simple as maintaining an open area for landing an aircraft. This can facilitate many different, potentially ad-hoc departure locations or destinations to be used that can significantly decrease an amount of travel to reach an ultimate destination. For example, a helipad on a building that is the user’s destination can provide for deboarding directly at the building. Uncrewed relocation can allow the helipad to be vacated and ready for others’ use without a crew onboard the aircraft.

[0067] Furthermore, while various aircraft provide low-impact operations in terms of near silent operations or zero emissions, disaggregating service locations and leg endpoints can help further improve low-impact operations. This can decrease a localized impact to anyone area. For example, traditional airports with traditional aircraft present challenges with managing acceptable noise impact, traffic, etc. By allowing aircraft to embark / arrive in areas selected for particular pilots or communities, exposure to low-altitude aircraft can be more diffuse, helping to maintain satisfactorily low noise levels and avoiding noise hotspots or other concentrations of emissions. This can benefit not only the comfort of people nearby but also decrease an impact to an environment in which the aircraft operate.

[0068] Another example improvement is increasing accessibility to and increasing the impact of the field of air-based transportation vehicles as a whole. The flexibility of departure locations and destinations with low or no infrastructure investment according to example aspects of the present disclosure can expand the accessibility of the entire field of air-based transportation. Instead of restricting air traffic only through expensive terminals that can require years of planning and construction, a business or community can quickly designate an open area as an available departure location or destination. This can enable people in the community to embark upon, and return from, air-based journeys in a location already integrated into the area. This can advantageously render such areas more accessible to out-of- area people as well by enabling direct flight thereto.

[0069] Furthermore, by enabling more direct flights from origin locations and to ultimate destinations, more travel journeys can more easily be conducted in the air rather than on the ground. This can help reduce ground-based traffic congestion. This in turn can help ground- based transportation modalities to operate more efficiently (e.g., operating in more efficient modes or under more efficient operating conditions), thereby increasing an overall efficiency of the field of transportation as a whole.

[0070] FIGS. 1A and IB demonstrate one example arrangement of an outbound and a return journey for user 104. Various other arrangements are contemplated. FIG. 2, for example, is a diagram of an example journey in which one or more user-piloted travel legs 120 begin and end at departure location 114. User-piloted travel legs 120 can include a single flight in which user 104 embarks from departure location 114, enjoys a flight, and returns to land at departure location 114. User-piloted travel legs 120 can include multiple individual flights that form part of a continuous interval during which user 104 can maintain control and possession of aircraft 110. For example, user-piloted travel legs 120 can include multiple flights, stopping at various locations for various periods of time (e.g., stopping to visit areas of interest).

[0071] Although the present disclosure refers to ‘"user-piloted travel legs’" and “pilots,” it is to be understood that the systems and techniques described herein for uncrewed legs canalso be applied to passenger-carrying legs that are also executed in autonomous flight modes. In some implementations, a rider can benefit from and engage with the systems described herein in the same or similar manner as would a pilot, except for aspects pertaining to direct control over the aircraft. Example implementations described herein with reference to a “pilot” are to be understood as being applicable, as appropriate, to a rider, except for aspects pertaining to direct control over the aircraft.

[0072] FIGS. 3A and 3B provide diagrams of example implementations in which a journey for user 104 includes one or more user relocation legs 302 to departure location 114. For example, FIG. 3A illustrates a forward journey during which user 104 and aircraft 110 each start at different respective initial locations to unite at departure location 114. FIG. 3B illustrates a forward journey during which user 104 travels directly to an aircraft storage or staging facility which also serves as a departure location.

[0073] Client device 102 can include one or more computing devices owned or otherwise accessible to a user of a transportation service. For example, client device 102 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. Client device 102 can execute one or more instructions to run an instance of a software application for a respective transportation platform and present user interfaces associated therew ith. Client device 102 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.).

[0074] Client devices 102 can be associated with one or more user accounts. For example, client devices 102 can execute a software application that uses a secure login process to authenticate a user of the device. After authentication, activity in the software application can be attributed to the user account. For instance, the user account can be a service account that facilitates a user’s engagement of transportation sen-ices provided by transportation platform systems 108.

[0075] User 104 can be a person, system, or entity that directly engages with client device 102 to engage a transportation service provided by transportation platform system 108. User 104 might not directly interact with client device 102. Another person or system can interact with client device 102 on behalf of user 104.

[0076] In an example, user 104 can be or include a plurality of users. One or multiple users may be transported by aircraft 110 (or multiple aircraft) on one or more travel legs onthe same itinerary'. For instance, a batch of aircraft can be dispatched to transport a user group together along a same itinerary’.

[0077] Network 106 can include one or more types of networks including telecommunications networks, internet, private networks, or other networks, as further described herein.

[0078] Transportation platform system 108 can be associated with one or more service entities that provide at least an aerial transportation service to users. Transportation platform system 108 can include a computing platform (e.g., a cloud services platform, server system, etc.) communicatively connected (directly or indirectly) over networks 106 to one or more other systems or devices, such as client device 102.

[0079] Transportation platform system 108 can include or implement one or more clientfacing software applications accessible to client device 102. Users can interact with transportation platform system 108 to receive various ty pes of information related to a transportation service. For example, a user (e.g., a pilot) can interact with transportation platform system 108 via an instance of a software application (e.g., a pilot app) running on client device 102 to request and book a flight.

[0080] Launching of the software application can initiate a user-network session with the associated transportation platform system 108. Transportation platform system 108 can include an interface layer that is configured to run processes to establish communication channels with individual devices. For example, the interface layer of transportation platform system 108 can establish secure sockets with client device 108, which can be used for coordinating services for user 104.

[0081] Transportation platform system 108 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.

[0082] Aircraft 110 can be any suitable type of aircraft. Aircraft 110 can include or be derived from aerial vehicles in a light sport aircraft category' or any other category'. Aircraft 110 can include aircraft having clean stall speeds of not more than about 60 knots CAS at a certified takeoff weight (e.g., at a maximum certified takeoff weight), such as speeds of not more than about 54 knots CAS at a certified takeoff weight (e.g., at a maximum certifiedtakeoff weight). Aircraft 110 can include aircraft having a gross weight of less than about 4000 pounds, such as less than about 3000 pounds.

[0083] Aircraft 110 can be powered by various different power sources. Aircraft 110 can include rotor or turbine propulsion units powered by internal combustion or electric power sources. Electric power sources can be energized by batteries, hydrogen fuel cells, or both, in whole or in part (e.g., hybrid electric).

[0084] Aircraft 110 can include an airplane. Aircraft 110 can include a rotorcraft (e.g.. a helicopter). Aircraft 110 can include a powered lift. Aircraft 110 can include a vertical takeoff and landing (VTOL) aircraft that can transition between a vertical flight mode (for takeoff, landing, and hovering) and a horizontal flight mode (for traversing distance more efficiently).

[0085] FIGs. 4A to 4C illustrate various different example aircraft 110. Aircraft 110 can include a multi-element lifting system. For example, aircraft 110 can be adapted for vertical take-off and landing using a combined wing and integrated propulsion system. Multiple wings (e.g., front wing 402 and rear wing 404) can include integrated propulsion systems. The wings can have upper and lower elements with thrust units 406 residing below the upper wing elements and above the lower wing elements. The w ing can include a control wing element 408 that resides behind the thrust unit. Control wing element 408 can be configured to be controllable into different positions, including a forward flight position in which thrust is directed rearward and a vertical takeoff and landing position in which thrust is directed downward.

[0086] Aircraft 110 can be configured for substantially horizontal flight with substantially vertical takeoff and landing (e.g., FIGs. 4A and 4C). This configuration can include rotatable wing elements or rotatable thrust controls such that thrust can be directed both horizontally and vertically (e.g., a range of thrust control motion of about 90 degrees). Aircraft 110 can be configured for horizontal flight with the fuselage pitched at a first angle such that the front and rear wings operate at different elevations (e.g., FIG. 4B), in which case aircraft 110 can be configured to tilt backward to a second angle for takeoff and landing such that the spanwise axes of the front and rear wings assume substantially the same elevation. This configuration can include rotatable wing elements or rotatable thrust controls such that thrust can be adjusted sufficiently for vertical takeoff with the fuselage at the second angle and horizontal flight with the fuselage at the first angle (e.g.. a range of thrust control motion of less than 90 degrees).

[0087] Aircraft 110 can include autonomous flight control systems. An autonomous flight control system can include one or more systems configured to control a motion of aircraft 110 independently of a human operator (e.g., onboard operator, remote operator, etc.). An autonomous flight control system can include computing systems that can receive sensor data describing an environment through which aircraft 110 is moving or describing the aircraft motion and subsystem characteristics. The autonomous flight control system can process the sensor data to perceive the environment and detect and identify objects in the environment. The autonomous flight control system can process the sensor data to localize aircraft 1 10 within the environment. The autonomous flight control system can identify an appropriate path through the perceived surrounding environment and navigate along the path without human intervention. An autonomous flight control system can detect and respond to off- nominal scenarios without relying on human intervention.

[0088] Aircraft 110 can include manual flight control systems. A manual flight control system can include at least one control interface that influences a motion of aircraft 110. A manual flight control system can exercise direct or indirect control on a motion of aircraft 110. A manual flight control system can include one or more control yokes or other movable control interfaces that cause various actuators to adjust one or more components of aircraft 110 upon command.

[0089] Aircraft 110 can include automated flight control systems. An autonomous flight control system can be an automated flight control system. A manual flight control system can be at least partially automated.

[0090] A manual flight control system can implement various levels of augmentation or automation. A manual flight control system can include a computing system implementing a software interface that can receive inputs from a pilot regarding a desired motion and can generate control signals to execute the desired motion. For instance, a software interface can receive inputs that indicate a desired waypoint to which aircraft 110 is to travel. The computing system can generate one or more control signals to adjust a motion of aircraft 110 to travel to the indicated waypoint. A manual flight control system can include a computing system configured to execute one or more predetermined maneuvers based on a reference waypoint (e g., circle, hover, land, take off, etc ).

[0091] A manual flight control system can have augmented flight controls. Augmented flight controls can include, for instance, controls configured such that a pilot can only control the flight path of aircraft 110 or intervene in its operation without direct manipulation of individual aircraft control surfaces or adjustment of the available power. Augmented flightcontrols can include, for instance, controls configured to prevent loss of control, regardless of pilot input. Augmented flight controls can include, for instance, controls configured such that the pilot can discontinue the flight quickly and safely. This feature can be designed to prevent inadvertent activation. Discontinuing or suspending a flight can include options such as an immediate landing, a return flight to the aircraft’s point of departure, a diversion to an alternate landing site, a course change, or initiation of a low altitude orbit or in-place hover until any hazards have passed. Augmented flight controls can include, for instance, simplified flight controls as defined under applicable regulations.

[0092] Augmented flight controls can, for instance, include built-in features such as flight envelope protections which can prevent the pilot from inputting a flight command that would be hazardous to the aircraft or its occupants. Augmented flight controls can, for instance, include control limiters that prevent the aircraft from being operated outside its designated flight envelope and its prescribed operational limitations. These control limiters can be preprogrammed and can include boundaries such as airspeed, altitude, vertical speeds, lateral displacements, accelerations, attitude, angular velocity, angular acceleration, angle of attack, angle of sideslip, subsystem temperature, voltage, current, etc. Actuator limiters can include boundaries on actuator range of actuation, such as control surface movement limits, motor torque limits, motor rotational velocity limits, etc. For aircraft equipped with multiple engines or rotor systems, aircraft 110 can respond, using the aircraft’s automation, to asymmetric power situations due to loss of engine power. Some augmented flight controls can prevent loss of control of the aircraft under all circumstances, even to the point of overriding erroneous or hazardous pilot inputs or only permitting the input of certain commands in specific flight conditions.

[0093] A manual flight control system can be operated by a human operator within aircraft 1 10 or remote from aircraft 110. A human operator of a manual flight control system can use a communications link to engage with air traffic control regarding the flight path of aircraft 110. A remote human operator can use a remote flight deck to control aircraft 110. A remote flight deck can be configured to supply aircraft 110 with control inputs. The control inputs can be, for example, way points to which aircraft 110 is to travel, maneuvers aircraft 110 is to perform with respect to one or more anchor waypoints (e.g., circle in holding pattern around a given waypoint), and the like.

[0094] Aircraft 110 can include a control system that can switch between uncrewed (e.g., autonomous, remote-operated manual control) and crewed (e.g., locally operated manual) control. For instance, aircraft 110 can include a control system that can switch betweenautonomous and local manual control. Aircraft 110 can include a control system that can switch between remote manual control and local manual control.

[0095] Autonomous flight control systems can be enabled for one or more relocation legs. Additionally, or alternatively, remote-operated manual flight control systems can be enabled for one or more relocation legs.

[0096] Locally-operated manual flight control systems can be enabled for one or more travel legs, when aircraft 1 10 is occupied by a pilot.

[0097] Any one or more of autonomous flight control systems or remote-operated manual flight control systems can be enabled during one or more travel legs as desired, or as needed (e.g., in the event of pilot error or other emergency condition, etc ).

[0098] Aircraft 110 can communicate with client device 102, transportation platform system 108, or both to facilitate the entry into and use of aircraft 110 by user 104. For example, aircraft 110 can include a lock system that permits entry into aircraft 110 only if the lock system is deactivated based on authentication of user 104 using client device 102. For example, entry to aircraft 110 can require authentication of user 104 using client device 102 (e.g., biometric authentication) while client device 102 is in proximity to aircraft 110 as well as cross-reference of the authenticated user 104 with a user associated with a trip on aircraft 110 as recorded by transportation platform system 108. Similarly, taking control of aircraft 110 can leverage authentication using client device 102 in conjunction with transportation platform system 108.

[0099] Initial location 1 12 can include a service location configured for storage, maintenance, refueling / recharging, inspection, or other service tasks for aircraft 110. Initial location 112 can include a prior destination at which a prior user deboarded aircraft 110 after completing a trip with aircraft 110.

[0100] Departure location 114 can include any location at which user 104 can board aircraft 110. Departure location 114 can include dedicated infrastructure configured for facilitating boarding / deboarding of aircraft. Departure location 114 can include ad hoc locations made available for boarding / deboarding of aircraft. This can include, for example, a vacant area in parking lots, open fields, rooftops, etc. Departure location 114 can be open to the public such that anyone can arrange to depart from departure location 114 or private such that only one or a restricted few people can arrange to depart from departure location 114. For example, a departure location can be at a home or workplace of user 104. A departure location can be in a parking lot of a business. A departure location can be a dedicated vertiport.

[0101] Departure location 114 can be subject to restricted use. Restrictions can include hours of operation, ty pes of aircraft that can land, etc.

[0102] Departure location 114 can be designated based on agreements between a transportation sendee provider and one or more third-party entities. For instance, a transportation service provider can engage other businesses to allow part of their property7to be used as a departure location. In turn, the businesses can enjoy increased traffic at their locations. Transportation platform system 108 can bias routing of flight traffic via such locations.

[0103] Uncrewed aircraft relocation leg 116 can include automatic repositioning of aircraft 110 from initial location 112 to departure location 114. Aircraft 110 can fly uncrewed aircraft relocation leg 116 in an autonomous flight mode or a remote-operated manual flight mode.

[0104] Although various examples described herein refer to implementations in which uncrewed flight legs (e.g., relocation leg 116) are initiated responsive to a trip request from a user, it is to be understood that uncrewed flight legs can be initiated responsive to various other triggers.

[0105] In an example, a maintenance system can determine a maintenance status that indicates that an aircraft is scheduled for maintenance, or should be scheduled for maintenance (e.g., due to a newly detected condition). The maintenance system can submit a service or inspection request that causes transportation platform system 108 to instruct aircraft 1 10 to fly in an uncrewed flight mode to a service or maintenance location for performance of service, inspection, or other maintenance tasks. Such requests can be triggered responsive to scheduled events (e.g.. event times stored in a calendar database entry), detected events (e.g., a detected operational condition of an aircraft component measured by a sensor on the aircraft or a sensor at a vertipad or vertiport), received messages from a user device (e.g., a message indicating an observed condition of an aircraft observed by a user or measured by a sensor of a user device, such as during a pre-flight or post-flight inspection as described herein, etc ).

[0106] Destination location 118 can include any location that is or could be designated as a departure location. Destination location 118 can include locations not designated as departure locations.

[0107] User-piloted travel leg 120 can include locally-operated manually controlled flight of aircraft 110 from departure location 114 to destination location 118. User-piloted travel leg 120 can include one or multiple stops.

[0108] Although user-piloted travel leg 120 is generally described in the context of user- piloted travel, it is to be understood that the techniques described herein described with respect to user-piloted travel leg 120 can also be applied to user-occupied travel legs in which a user does not exert piloting control over an aircraft but rides or occupies the aircraft during the travel leg while the aircraft is self-piloted (e.g., automatically or autonomously) or piloted by another user.

[0109] Uncrewed aircraft return leg 122 can include automatic repositioning of aircraft 110 from destination location 118 to initial location 1 12. Uncrewed aircraft return leg 122 can include automatic repositioning of aircraft 110 from destination location 118 to any other location, such as another departure location (or departure location 114) for another trip. This can be performed for pre-positioning for expected flight demand. Uncrewed aircraft return leg 122 can include automatic repositioning of aircraft 110 from destination location 1 18 to a waiting area, parking area, or staging area while not needed by user 104.

[0110] Uncrewed aircraft travel leg(s) can be or include one or more unoccupied travel legs in which the aircraft is unoccupied. An unoccupied state can include a state of the absence of passengers; an absence of transported pay load; etc. In some implementations, an unoccupied state can include an absence of passengers and a presence of transported pay load (e.g., transporting items between locations while not transporting passengers).

[0111] Aircraft 110 can be configured to fly differently on crewed legs as compared to uncrewed legs. For example, aircraft 110 can be configured to use different airspace on crewed legs as compared to uncrewed legs. For example, uncrewed legs can be restricted to airspace (e.g., volumes of airspace, particular routes or skylanes associated therewith, etc.) that are designated for uncrewed air traffic. For instance, the designated airspace can be over less densely populated areas. The designated airspace can be restricted to only uncrewed air traffic. This may allow for more simplified operating environments for an autonomous or automated flight task.

[0112] During uncrewed flight legs, flight control parameters of aircraft 110 can be configured to improve energy efficiency. For instance, flight control parameters of aircraft 110 can be configured to fly at a speed selected for energy efficiency, even if that speed results in a longer flight duration. To accommodate a slower flight speed, aircraft 110 can depart from an initial location 112 according to instructions indicating an earlier departure time than would be required if flying at full speed or a passenger-carrying cruise speed. This extra time can be factored in when planning aircraft availability and scheduling aircraft trips.Similarly, a flight path of aircraft 110 can be configured to decrease energy expenditure, such as by avoiding headwinds, even if the path results in a longer flight duration.

[0113] During uncrewed flight legs, aircraft configuration parameters can be configured to, for instance, adjust a control stability. The aircraft can include actuators that can operate to reconfigure a weight distribution of the aircraft. For instance, an actuator can adjust a position of seats, bins, accessories, or other ballast. Adjusting the weight distribution can include filling a ballast tank with an amount of fluid, wherein the amount is based on the payload information and the weight distribution criteria. The ballast tank can be integrated into a seat or other portion of aircraft 110. The fluid can be a coolant, such as a coolant for a drive component (e.g., battery, motor) of aircraft 110.

[0114] Client device 102 can execute or otherwise access a pilot application that can facilitate access to aircraft 110 (e.g., managing reservation or scheduling of trip with aircraft 110) and operation of aircraft 110 (e.g., unlocking aircraft 110, providing a control interface, information resource interface, pre- or post-flight checklist interface, etc.). Various example implementations of a pilot application are described with reference to FIGS. 5 to 23.

[0115] FIG. 5 is an illustration of one example implementation of a pilot application executing on a client device 102 according to example aspects of the present disclosure. The application can provide a pilot account interface 500 for managing user account information for an example pilot. For instance, a pilot account can describe information regarding a pilot’s use of the transportation service, a pilot’s active certifications, a pilot’s preferred or personal departure / landing locations, and the like. The pilot application can store data in secured data formats. The pilot application can store encrypted data. The pilot application can, upon or prior to installation or execution, process an input indicating approval for the pilot application to store and use pilot account data. Some data stored by the pilot application can be anonymized.

[0116] A schedule panel 502 can render data describing the pilot’s past or presently pending trips. Schedule panel 502 can provide one or more input elements for retrieving and rendering additional information regarding the trips.

[0117] For example, a record of a past training session 504 can be rendered in association with an input element 506 configured to initiate an expanded rendering of additional data describing training session 504, such as a flight duration, a location record tracing the flight or other telemetry' data, a certification earned (or experience credited), progress toward a certification goal, etc.

[0118] For example, a record of a future trip 508 can be rendered in association with an input element 510 configured to initiate an expanded rendering of additional data describing future trip 508. The expanded rendering can include additional input elements configured to modify parameters of future trip 508, including modifying a time, location, aircraft configuration, etc. associated with future trip 508.

[0119] A certification panel 512 can render data describing the pilot' s active certifications. Certification panel 512 can present an input element 514 for adding new certifications. An example certification 516 can include a sport pilot license. Other pilot license levels can be used. Certification panel 512 can provide indication of upcoming action items related to example certification 516, such as an expiration date, necessary' training, or experience hours, etc.

[0120] Input element 514 can initiate the addition of a new certification. Pilot account interface 500 can facilitate entry- of certification data describing the new certification, such as a licensing authority, a license number, etc.

[0121] FIG. 6 is a block diagram of an example certification verification system according to example aspects of the present disclosure. Client device 102 can transmit, to transportation platform system 108, certification data 602. Certification data 602 can include data collected via pilot account interface 500. Transportation platform system 108 can store certification data 602 in association with pilot account data 604 associated with the example pilot account. This can include completing one or more data fields in a data structure to reflect such information. The data structure can be stored with or otherwise linked to the pilot’s account.

[0122] Transportation platform system 108 can validate certification data 602 and add certification data 602 to a certification registry’ 606. Transportation platform system 108 can validate certification data 602 by interacting with certification authority' system 608. For instance, certification authority system 608 can include databases or other systems maintained by one or more licensing bodies. Transportation platform system 108 can validate certification data 602 against corresponding records from certification authority’ system 608. For example, a transportation platform system 108 can generate a query based on calling an API of the certification authority' system 608. The query' can include an identifier associated with the pilot or the pilot’s certification. The transportation platform system 108 can transmit the query to the certification authority system 608. The certification authority system 608 can be configured to perform a look-up function within its databases using the identifier provided in the query to perform the validation. The validation can be completed, for example, if thereis a match between the pilot and the certification data, the certification data 602 is complete, etc. The validation may not be completed in the event a match was not found in certification authority system 608, certification data 602 is incomplete or otherwise deficient, etc.

[0123] If validation is not completed, a validation task for certification data 602 can be added to a certification validation queue 610. Certification validation queue 610 can contain validation tasks scheduled for review or completion by one or more other systems, such as a human review system. The human review system can include a computing platform configured to provide information to, and receive inputs from, human operators.

[0124] With reference again to FIG. 5, pilot account interface 500 can include a vertipad panel 518. A vertipad can generally refer to an area for aircraft to land or take off. A vertiport can include one or more vertipads. References to example features or aspects relating to a vertipad as described herein are to be understood as also applicable to vertiports. References to example features or aspects relating to a vertiport as described herein are to be understood as also applicable to vertipads. A vertiport can include additional infrastructure that can support operation of the aircraft. This can include charging infrastructure, refueling infrastructure, cooling infrastructure, etc.). Vertipad panel 518 can render a listing of vertipads associated with the pilot account. Vertipad panel 518 can include an input element 520 configured to initiate addition of another vertipad to the listing.

[0125] Vertipads in vertipad panel 518 can be public or private vertipads. Public vertipads can be open generally to the public or available to all or a subset of pilots associated with transportation platform system 108. Public vertipads can be hosted by a municipal or government entity, a private corporation, a cooperative, etc. Private vertipads can be personal to an individual pilot or associated with a designated group of pilots. Private vertipads can be hosted by an individual person on property that the person is authorized to control. This can include, for example, the pilof s home, a common area in the pilot’s neighborhood, etc.

[0126] An example public vertipad 522 can include one or more vertipads at a designated favorite vertiport associated with the example pilot account. For example, vertipad panel 518 can display a group of vertipads collectively as a vertiport, if a vertiport includes multiple vertipads that are functionally equivalent (e.g., such that the user may be interested primarily in the status of any vertipad at the vertiport, and not necessarily a single vertipad). For example, a public vertiport “Santa Cruz Vertiport East” can include a public facility that includes one or more vertipads. An input element 524 can be configured to initiate a status check for one or more public vertipads 522. For instance, transportation platform system 108 can receive updates from computing systems associated with public vertipads 522 regarding acurrent or scheduled availability of public vertipads 522. Transportation platform system 108 can transmit, to client device 102, data describing the current or scheduled availability of public vertipads 522. Transportation platform system 108 can receive weather data from computing systems associated with public vertipads 522. Transportation platform system 108 can transmit, to client device 102, data describing the weather at public vertipads 522.

[0127] Input element 520 can facilitate the addition of a public vertipad to vertipad panel 518 by initiating display of a list of operational public vertipads. Favorite vertipads can be selected from the list of operational public vertipads.

[0128] An example private vertipad 526 can include one or more vertipads at the pilot's home. An input element 528 can be configured to facilitate editing of one or more parameters of private vertipad 526. Parameters can include spatial parameters (e.g., where the vertipad is located), temporal parameters (e.g., when the vertipad is operational), permission parameters (e.g., which accounts can use the vertipad), equipment parameters (e.g., aircraft supported by the vertipad, what charging / refueling facilities are available at the vertipad), and the like.

[0129] Input element 520 can facilitate the addition of private vertipads to vertipad panel 518 by initiating rendenng of an onboarding interface.

[0130] FIG. 7 is an illustration of an example onboarding interface 700. Onboarding interface 700 can provide one or more input elements configured to receive inputs describing parameters of the new vertipad.

[0131] Spatial parameters can include a bounding region 702 of the new vertipad.Bounding region 702 can be entered (e g., drawn or otherwise marked) using an interactive mapping interface. The mapping interface can display an overlay of roadway information.The mapping interface can display an overlay of satellite imagery. The mapping interface can display an overlay of property record information (e.g., plat boundaries).

[0132] Onboarding interface 700 can receive a variety of inputs describing bounding region 702. Onboarding interface 700 can receive inputs indicating vertices of bounding region 702. Onboarding interface 700 can obtain location data from location sensors onboard client device 102. For instance, a user can carry client device 102 while walking over a perimeter of bounding region 702. A location trace of the user’s path can help define a boundary of bounding region 702.

[0133] Onboarding interface 700 can receive an input indicating selection of confirmation input element 704. Upon selection of confirmation input element 704, onboarding interface 700 can proceed with further onboarding operations.

[0134] Onboarding interface 700 can facilitate collection of additional data descriptive of the new vertipad. Additional data can include sensor data. Example sensor data includes image data, LIDAR data, altimeter data, etc. from one or more sensors onboard client device 102.

[0135] FIG. 8 is an illustration of an example sensor data collection interface 800. For instance, sensor data collection interface 800 can be configured for collecting image data or LIDAR or RADAR data descriptive of a landing area. Other information can be collected as well, such as ground material / loading capacity, time of use, property record information (e.g., ownership, easement rights, local ordinances, etc.), lighting levels, etc.

[0136] Sensor data collection interface 800 can include a viewfinder 802 that displays an image captured by an imaging sensor of client device 102. Upon detecting interaction with a shutter release 804, client device 102 can record sensor data descriptive of a scene 806. The recorded sensor data can include one or more images of the scene. The recorded sensor data can include other sensor data indexed to the interaction with shutter release 804. For instance, shutter release 804 can trigger recording of LIDAR data from one or more LIDAR sensors. The LIDAR data can be registered to the image data.

[0137] Sensor data collection interface 800 can facilitate collection of image captures over time, such as video data. For example, a series of image captures (and LIDAR captures) can be collected while client device 102 is moving around the landing area (e.g., while a user carries client device 102). The collection of image captures can represent different perspectives of the landing area.

[0138] The sensor data can include one or multiple captures of one or multiple different ty pes of sensor modalities. The sensor data can be indexed together, such as indexed by capture time, capture location, capture orientation, etc.

[0139] FIG. 9 is a block diagram of an example vertipad onboarding system according to example aspects of the present disclosure. Transportation platform system 108 can receive, from client device 102, sensor data 902 and map data 904. Sensor data 902 can include image data, LIDAR data, location data, orientation data, altimeter data, etc. Map data 904 can include boundary’ data describing bounding region 702. Transportation platform system 108 can associate sensor data 902 and map data 904 with pilot account data 906 that is associated with client device 102. For example, transportation platform system 108 can maintain a database of pilot accounts. Pilot account data 906 can be stored in the database. Private vertipad data 908 can be stored with pilot account data 906. Private vertipad data 908 can include a pointer to a location in vertipad registry 910 at which raw data describing a privatevertipad is stored. For instance, vertipad registry 910 can be a source of truth for vertipad data, and private vertipad data 908 can point to or inherit from vertipad registry’ 910. However, vertipad registry 910 can instead inherit from or point to private vertipad data 908. For instance, private vertipad data 908 can be a source of truth for data regarding a particular vertipad. Vertipad registry 910 can include a listing of, with pointers to, various different vertipads. Transportation platform system 108 can store private vertipad data 908 based on or including sensor data 902 and map data 904.

[0140] Transportation platform system 108 can validate a user’s request to add a vertipad. This validation can include confirming that the requested vertipad is located in an area that is approved for flight using one or more aircraft associated with transportation platform system 108, confirming that the area has suitable terrain for takeoff / landing, confirming that the area is zoned appropriately for use as a vertipad, etc.

[0141] For example, transportation platform system 108 can communicate with airspace system 912 to obtain data describing one or more airspace restrictions or permissions associated with an area in which the requested vertipad is located. Airspace systems 912 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 912 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 sendee before take-off based on one or more policies or standards set by a regulatory body. Example regulatory’ bodies can include the Federal Aviation Administration, European Aviation Safety Agency, etc.

[0142] For instance, transportation platform system 108 can identify coordinates associated with the requested vertipad. Transportation platform system 108 can identify a municipal or geographic unit associated with the vertipad. This can include identifying a neighborhood, city, county, state, region, zip code, etc. in which the vertipad is located.

[0143] Transportation platform system 108 can obtain, from airspace system 912, data describing one or more restrictions or permissions associated with flights within the corresponding coordinates or within the corresponding municipal or geographic unit. Transportation platform system 108 can communicate with airspace system 912 using various different digital communication protocols. Transportation platform system 108 can interact with an API endpoint hosted by airspace system 912 to send data to and request data from airspace system 912.

[0144] For instance, transportation platform system 108 can confirm that an area associated with the requested vertipad is in an area associated with approval for autonomous flight. For instance, transportation platform system 108 can confirm that an area associated with the requested vertipad is in an area associated with approval for autonomous flight using aircraft of the ty pe (e.g., size, weight, power level, seating capacity, etc.) operated in association with transportation platform system 108.

[0145] Transportation platform system 108 can communicate with geographic information system 914 to obtain data describing one or more aspects of the corresponding coordinates or within the corresponding municipal or geographic unit. For example, geographic information system 914 can store topographic data, flood plain data, zoning data, property boundary data, deed data, covenant data. etc. Transportation platform system 108 can access data from geographic information system 914 by submitting a structured query to search for an indication that the location would not be suitable for the requested vertipad, would not be suitable for at least one aircraft type (e.g., based on an aircraft size), etc. Transportation platform system 108 can determine a presence or an absence of an indication that the location would not be suitable for the requested vertipad.

[0146] Transportation platform system 108 can approve a requested vertipad. Transportation platform system 108 can add approved vertipads to vertipad registry7910. Vertipad registry 910 can maintain a list of available vertipads and their characteristics, including an access list of user accounts authorized to access the vertipad. A vertipad characteristic can include one or more approved utilization characteristics, such as an access for loading or unloading pay load, types of aircraft supported at the vertipad, etc. For instance, different aircraft may require different vertipad characteristics due to aircraft operating requirements or characteristics (e.g.. noise, downblast, etc.). Different payloads may require different access requirements (e.g., paved surface for rolling equipment, etc.). A vertipad characteristic can include a flight frequency' limit (e.g., for compliance with one or more land use constraints, such as a noise restriction). Transportation platform system 108 can maintain a moving window measure of flight frequency (e.g., per hour, per day, per week, etc.) to ensure that the vertipad is not enabled for flights that would cause the metric to exceed a target threshold. A vertipad characteristic can include a time-of-day restriction that can be used by transportation platform system 108 to selectively enable or disable selection of a vertipad based on the restriction.

[0147] Transportation platform system 108 can hold approval of a requested vertipad. Transportation platform system 108 can add a requested vertipad to a vertipad validationqueue 916 for additional validation if a threshold confidence is not achieved in an initial validation stage. The threshold confidence can reflect a threshold confidence score associated with the suitability of the requested vertipad based on aircraft size, location, environment, etc. For instance, if an automated validation process does not validate the requested vertipad with a sufficient confidence, or if validation is not otherw ise completed, a validation task for the requested vertipad can be added to vertipad validation queue 916. Vertipad validation queue 916 can contain validation tasks scheduled for review or completion by one or more other systems, such as a human review system.

[0148] In general, transportation platform system 108 can implement a custom validation system for validating vertipads. The custom validation system can aggregate data signals from various sources, such as from one or more client device(s) 102, airspace system 912, geographic information system 914, or other systems. For example, the custom validation system can build a multilayer world model operable for validating potential vertipad locations against a variety of constraints.

[0149] In some implementations, an example data source can include a high-resolution satellite imagery system. Transportation platform system 108 can access high-resolution satellite imagery data and perform visual assessment of a potential landing zone (e g., using one or more machine-learned models trained to process input imagery and predict an assessment score). Transportation platform system 108 can access high-resolution satellite imagery data and identify surface types at or around a potential vertipad location.Transportation platform system 108 can access high-resolution satellite imagery data and detect obstacles or structures at or around a potential vertipad location.

[0150] In some implementations, an example data source can include a low er-altitude aerial imaging system. Transportation platform system 108 can access aerial imaging data and perform detailed visual assessment (e.g., at a higher precision as compared to satellite imagery, such as at a higher pixel or voxel to land area ratio), such as by using multi spectral, LIDAR, RADAR, or other imaging data. Transportation platform system 108 can access aerial photography data and identify smaller obstacles. Transportation platform system 108 can access lower-altitude aerial photography data and predict specific surface condition details.

[0151] In some implementations, an example data source can include a mapping data system. Transportation platform system 108 can access mapping data and determine ground elevation, such as by using topographic maps. Digital Elevation Models (DEMs), or LiDAR scan data.

[0152] In some implementations, an example data source can include a Geographic Information System (GIS) data layers system. Transportation platform system 108 can access GIS data and access geospatial information like property boundaries, building footprint, road networks, known utility lines, zoning information, etc. Transportation platform system 108 can access GIS data and determine potential extraction routes for recovering a disabled or otherwise inoperable aircraft.

[0153] In some implementations, an example data source can include an aeronautical charts system. Transportation platform system 108 can access aeronautical chart data and predict attributes of the airspace environment. Transportation platform system 108 can access aeronautical chart data and identify controlled or special use airspace. Transportation platform system 108 can access aeronautical chart data and locate airways. Transportation platform system 108 can access aeronautical chart data and find nearby airports or heliports. Transportation platform system 108 can access aeronautical chart data and process Maximum Elevation Figures.

[0154] In some implementations, an example data source can include aircraft travel records (e.g., a System Wide Information Management (SWIM) feed). Transportation platform system 108 can access aircraft travel records and detect areas of high traffic patterns. Transportation platform system 108 can access aircraft travel records and estimate vertipad utilization rates. Transportation platform system 108 can access aircraft travel records and identify potential interference between potential vertipad traffic and existing traffic.

[0155] In some implementations, an example data source can include an FAA obstruction database system (e g., the Digital Obstacle File (DOF)). Transportation platform sy stem 108 can access FAA obstruction database data and access lists of known obstructions.Transportation platform system 108 can access FAA obstruction database data and obtain precise location and height information for obstructions. Transportation platform system 108 can access FAA obstruction database data and check potential approach and departure paths for conflicts.

[0156] In some implementations, an example data source can include a Temporary Flight Restriction (TFR) data system. Transportation platform system 108 can access TFR data and check for current, temporary airspace restrictions. Transportation platform system 108 can access TFR data and process short-term operational constraints.

[0157] In some implementations, an example data source can include a historical weather database system. Transportation platform system 108 can access historical weather databasedata and process typical weather patterns. Transportation platform system 108 can access historical weather database data and process prevailing wind direction and speed.Transportation platform system 108 can access historical weather database data and determine the frequency of low visibility conditions. Transportation platform system 108 can access historical weather database data and process typical temperature extremes.

[0158] In some implementations, an example data source can include a real-time weather services system. Transportation platform system 108 can access real-time weather service data and process current meteorological conditions.

[0159] In some implementations, an example data source can include a noise assessment data system. Transportation platform system 108 can access noise assessment data and process potential noise impacts. Transportation platform system 108 can access noise assessment data or model data and estimate the effect of operations on surrounding communities.

[0160] In some implementations, an example data source can include a geological or soil surveys system. Transportation platform system 108 can access geological or soil survey data and obtain general information about local soil conditions. Transportation platform system 108 can access geological or soil survey data and understand soil type and stability characteristics. Transportation platform system 108 can access geological or soil survey data and make preliminary assessments of load-bearing capacity.

[0161] In some implementations, an example data source can include a property ownership records system. Transportation platform system 108 can access property ownership record data and identify the legal owner(s) of a parcel. Transportation platform system 108 can access property' ownership record data and identify any recorded legal burdens or constraints on a parcel (e g., use restrictions).

[0162] In some implementations, an example data source can include a results of an onsite survey or physical inspection system. Transportation platform system 108 can access onsite survey result data and ground-truth remotely sensed data. Transportation platform system 108 can access on-site surv ey result data and process measured site dimensions and clearances. Transportation platform system 108 can access on-site survey result data and identify unmapped obstacles. Transportation platform system 108 can access on-site survey result data and directly assess surface conditions.

[0163] In some implementations, an example data source can include a results of on-site signal strength measurement. Transportation platform system 108 can access on-site signalstrength data and measure signal availability. Transportation platform system 108 can access on-site signal strength data and verify adequate radio communication coverage.

[0164] In some implementations, an example data source can include a street view imagery system. Transportation platform system 108 can access street view imagery data and process the image data to predict a suitability for vertipad use or access. Transportation platform system 108 can access street view imagery data and estimate site dimensions and clearances. Transportation platform system 108 can access street view imagery data and identity' unmapped obstacles.

[0165] In an example, transportation platform system 108 can proactively build and maintain a world model based on such various data inputs. The world model can include multiple data layers registered in alignment with one another (e.g., parcel information spatially aligned with topographical information and meteorological information, as one example). As a result, a world model can capture multiple dimensions of attributes associated with a particular parcel or other land unit. The world model can be persisted by transportation platform system 108 and periodically updated based on changes detected in any one or more data sources used to generate the world model.

[0166] Transportation platform system 108 can generate inferred attributes based on combinations of different data sources. For example, based on meteorological data for a particular patch (e.g., from a weather data layer) and structural data (e.g., from one or more of a satellite data layer, aerial imaging data layer, aircraft lidar data layer, GIS data layer, street view data layer, etc.) transportation platform system 108 can predict likely architectural turbulence patterns in regions proximate to structures. Such predictions can be stored in the world model to evaluate potential effects on VTOL or other aircraft.

[0167] Other example inferred attributes relate to aircraft recovery. For example, it may be desired to avoid dispatching aircraft to vertipads at which an aircraft would be stranded if somehow rendered inoperable and unable to fly at the vertipad. Transportation platform system 108 can predict a likely time to recover (e.g., via road, via aircraft lift, based on proximity’ to nearest service facility capable of dispatching a recovery, etc.). Transportation platform system 108 can predict a viability of recovery (e.g., based on minimum lane width of route(s) to access vertipad, based on a proximity of vertipad to paved surface streets, etc.).

[0168] Transportation platform system 108 can process patches of the world model data using a scoring system to generate a score or a goodness metric value that characterizes a goodness of a particular area for operating a vertipad. Failure to pass particular thresholds can result in a score indicating such failure, such as a null or zero score that excepts a particulararea or patch from further evaluation (e.g., until expiration of a rein- interval, until new information is available, etc.). For instance, threshold criteria may include, for example, airspace restrictions that would exclude an area from use for a vertipad, proximity to nearby structures that would preclude use as a vertipad, terrain that is incompatible with a vertipad use, noise prohibitions or other restrictions (e.g., land use covenants) that would preclude use as a vertipad. zoning restrictions, etc.

[0169] Transportation platform system 108 can rank potential vertipad locations based on the computed score. The ranking can be used to allocate resources for further processing of potential vertipad locations. For example, a fixed amount of resources may be available for more in-depth processing of location data. For example, a fixed pool of devices may be available at a given time for collecting additional data (e.g.. on-site data collected using client device(s) 102, aircraft 110, etc.). Based on the goodness metric for a particular location, the particular location may be associated with a higher expectation of suitability for vertipad use, such that allocating more resources for confirming or validating that determination is associated with a higher confidence of successful completion. In contrast, a low goodness metric can be associated with a lower expectation of suitability for vertipad use, such that allocating more resources for confirming or validating that determination may not be associated with much or any confidence of successful completion.

[0170] Transportation platform system 108 can receive a request to onboard a vertipad and use the world model to assist in verifying and approving or rejecting the request.

[0171] With reference again to FIG. 5, a pilot account interface 500 can provide an input element 530 configured to initiate scheduling of a new trip or flight. Selecting input element 530 can initiate rendering, by client device 102, of a scheduling interface.

[0172] FIG. 10 is an illustration of an example scheduling interface 1000 according to example aspects of the present disclosure. Interactive scheduling interface 1000 can include interactive input elements 1002, 1004, 1006, 1008, 1010 configured to facilitate reserving an aircraft for a flight. Input element 1002 can be configured to receive inputs describing a desired departure time or cause client device 102 to load an interface for receiving inputs describing a desired departure time. Input element 1004 can be configured to receive inputs describing a desired departure location or cause client device 102 to load an interface for receiving inputs describing a desired departure location. Input element 1006 can be configured to receive inputs describing a desired destination location or cause client device 102 to load an interface for receiving inputs describing a desired destination location. Input element 1008 can be configured to designate a “round trip” such that the destination locationis the same as the departure location. Input element 1010 can be configured to initiate a scheduling action to reserve an aircraft for the trip.

[0173] Input element 1002 can be configured to receive inputs describing a desired departure time. A departure time can be relative or absolute. For instance, a departure time can be as soon as possible (ASAP). Interactive scheduling interface 1000 can receive an input associated with input element 1002 can trigger rendering of a more detailed scheduling interface.

[0174] FIG. 11 is an illustration of a more detailed scheduling interface according to an example implementation of the present disclosure. Interactive scheduling interface 1000 can generate an overlay 1102 that presents an interface for inputting specific dates and times at which departure is desired.

[0175] With reference again to FIG. 10, input element 1004 can be configured to receive inputs describing a desired departure location. Input element 1004 can include a text input field to, for example, input an address or keyword associated with a location. Input element 1004 can include an input element that causes interactive scheduling interface 1000 to open a map-based interface.

[0176] Input element 1004 can include an input element that causes interactive scheduling interface 1000 to open a map-based interface that is configured to select free or unconstrained (or substantially unconstrained) locations. For example, a location can be selected from among a set of locations that is not restricted to known or existing vertipad locations. The selected location can be processed as an initial location request that is used by transportation platform system 108 to determine a suitable departure location based on a proximity to the user’s selected location. For example, client device 102 can receive an initial location request that describes a current location or an expected future location of a user (e.g., at home, at a campsite, etc.). Client device 102 can package initial location request within a data payload and send the data payload to transportation platform system 108.

[0177] Transportation platform system 108 can process the initial location request to build an itinerary for a trip that adjusts for a proximity to the requested initial location. This function can be performed by a back-end software service that is configured to locate suitable locations associated with the request. For instance, the initial location request can help refine a search for a suitable departure location. The initial location can be a floating or soft constraint in the request. For instance, transportation platform system 108 can process the initial location request and determine a suitable departure location as part of building theitinerary for user 104, based on a timing of the journey, a size or other characteristic of the assigned aircraft 110, etc.

[0178] Transportation platform system 108 can build the itinerary to manage a frequency of travel with respect to one or more points in space. For example, a land area may be associated with one or more constraints with respect to operational frequency, noise, or other conditions. The conditions can be managed by reducing or maintaining frequency of operation below a threshold value. Transportation platform system 108 can maintain a frequency heat map and construct routes to avoid ’‘hot” spots on the heat map. Transportation platform system 108 can suggest alternative itinerary features (e.g., return a communication to a client device 102 containing a request to adjust an itinerary feature), such as suggesting an alternative time, an alternative location, an alternative route, etc. Transportation platform system 108 can receive, from client device 102, approval or adjustment of the suggested alternative.

[0179] Client device 102 can engage with one or more transportation platforms to schedule transportation from a first location to the departure location selected by transportation platform system 108 based on the initial location request. For example, transportation platform system 108 can be configured to arrange a ground vehicle to transport the user 104 to the departure location. The ground vehicle can be included in a fleet of ground vehicles of the service provider associated with the transportation platform system 108 or another service provider such as a separate ride hailing platform. Additionally, or alternatively, the user 104 can utilize the client device 102 to separately arrange a ground vehicle to transport the user 104 to the departure location via softw are application of the other serv ice provider.

[0180] FIG. 12 is an illustration of a map-based interface 1200 for selecting a location for an initial location request using a map 1202. Map 1202 can include data from one or more mapping databases. An input element 1204 can be configured to cause map-based interface 1200 to obtain a location corresponding to a current location of client device 102. This can be a location obtained from a positioning or localization system on client device 102. In this manner, for instance, the initial location request can be based on a location of client device 102. An input element 1206 can be configured to cause map-based interface 1200 to obtain a location corresponding to a location marker or pin “dropped” onto the map via interaction with map 1202 by, for example, tapping, dragging, pinching, or otherwise using a gesturebased touch interface on which map 1202 is rendered. In this manner, for instance, the initial location request can be based on a location specifically selected on map 1202.

[0181] With reference again to FIG. 10, input element 1004 can include an input element that causes interactive scheduling interface 1000 to open a vertipad selection interface that is configured to facilitate selection of a departure location from among a list of available departure locations. For example, available vertipads can be presented on the vertipad selection interface in a list that ranks available vertipads based on a proximity' to client device 102. In this manner, for instance, client device 102 can receive an input that directly indicates an actual departure location selected by a user. Client device 102 can present a vertipad selection interface responsive to selection of input element 1004. Client device 102 can present a vertipad selection interface based on an initial location request. For example, a vertipad selection interface can include vertipads located in a map region identified based on an initial location request.

[0182] FIG. 13 is an illustration of a vertipad selection interface 1300 for selecting a departure location using a map 1302. Map 1302 can be populated with available vertipads 1304 and 1306 that are approved for use by the user. Vertipad selection interface 1300 can facilitate selection of one of the available vertipads for a departure location for the new trip.

[0183] Client device 102 can load vertipad selection interface 1300 responsive to selection of input element 1004. For instance, selection of input element 1004 can directly load map 1302 based on a current location of client device 102 or a default location associated with a user account.

[0184] Client device 102 can use an initial location request (e.g., obtained using mapbased interface 1200) to load a refined map-based interface 1300. For instance, based on an initial location request, refined map-based interface 1300 can load a map portion at a much more granular scale to show nearby departure locations 1304 and 1306. Refined map-based interface 1300 can be configured to receive selection of a departure location, such as by selection of an input element associated with departure location 1304 or departure location 1306.

[0185] With reference again to FIG. 10, input element 1006 can be configured to receive inputs describing a desired destination location or cause client device 102 to load an interface for receiving inputs describing a desired destination location. Selection of a destination location can use the same or different interfaces as selection of a departure location.

[0186] Input element 1010 can be configured to initiate a scheduling action to reserve an aircraft for the trip. Client device 102 can render, after interaction with input element 1010, an aircraft selection interface.

[0187] FIG. 14 is an illustration of an example aircraft selection interface 1400 according to example aspects of the present disclosure. Aircraft selection interface 1400 can facilitate selection of individual aircraft or an aircraft type for the trip. Aircraft selection interface 1400 can render selectable input elements for different aircraft options.

[0188] Aircraft selection interface 1400 can render details describing the different aircraft options. For example, the aircraft options can have different characteristics, such as a different number of seats, a different top or cruising speed, a different weight or luggage capacity, a different flight cost for the trip, etc. A selectable input element 1402 can be rendered in association with description content 1404 for a first aircraft option. A selectable input element 1406 can be rendered in association with description content 1408 for a second aircraft option. A selectable input element 1410 can be rendered in association with description content 1412 for a third aircraft option.

[0189] An aircraft or aircraft type can be selected before transportation platform system 108 processes the input departure time, departure location, and destination location. For instance, an aircraft or aircraft type can be a constraint provided by client device 102 to transportation platform system 108 for scheduling the trip. Aircraft selection interface 1400 can facilitate a ranking of different options to provide contingencies if a first-ranked selection is not available for completing the trip.

[0190] An aircraft or aircraft type can be selected after transportation platform system 108 processes the input departure time, departure location, and destination location. For example, transportation platform system 108 can process at least one of a provided departure time, departure location, or destination location to determine one or more aircraft or aircraft types compatible with the request or one or more aircraft types that are available to service the request.

[0191] Aircraft selection interface 1400 can present aircraft or aircraft types that are filtered based on a certification status associated with a user account. For example, a user account associated with client device 102 can correspond to stored credentials for a pilot, such as a flight license. The license can have restrictions on a type, size, weight, capacity, speed, etc. of aircraft that can be flown. Aircraft selection interface 1400 can render aircraft options that are screened based on the license.

[0192] Aircraft selection interface 1400 can present aircraft or aircraft types that are filtered based on an estimated trip distance. For instance, a trip distance can be estimated based on an input departure location and an input destination location. Aircraft selectioninterface 1400 can screen candidate aircraft types based on a flight range associated with the aircraft types.

[0193] After receiving data indicating criteria or constraints for the new trip, transportation platform system 108 can initiate scheduling of the requested new trip.

[0194] FIG. 15 is a block diagram illustrating an example scheduling ecosystem 1500. Multiple network-connected systems can cooperatively interact within ecosystem 1500 to provide facilitate scheduling of the requested trip. As shown, ecosystem 1500 may include a distributed computing system with a plurality of different participating systems / devices, such as client device 102 and transportation platform system 108, communicatively connected over network 106. Ecosystem 1500 can include aerial facility devices 1502 associated with locations where aircraft can be located for storage, maintenance, departure, arrival, etc. Ecosystem 1500 can include aircraft devices 1504 associated with individual aircraft or groups of aircraft. Ecosystem 1500 can include third party system 1506 that can interact with one or more other devices or systems in ecosystem 1500. Ecosystem 1500 can include certification authority system 608 for confirming a certification status associated with a pilot for a new- trip. Ecosystem 1500 can include airspace system 912 for confirming approval to fly a route requested for a new trip. Ecosystem 1500 can include a scheduler system 1508 that builds on-demand flight itinerary structure 1510 based on communication with any one or more of client device 102, transportation platform system 108, airspace system 912, aerial facility devices 1502, aircraft devices 1504, or third party system 1506.

[0195] Aerial facility- devices 1502 can include one or more devices or systems associated with an aerial facility- used for providing a transportation service. Any one or more of initial location 112, a departure location 114. a destination location 118, etc. can include or be included by aerial facilities. Aerial facility devices 1502 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 1502 can include one or more charging devices associated with charging infrastructure of the aerial facility, one or more refueling devices associated with refueling 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. Aerial facility devices 1502 can include occupancy sensors that can detect a presence of an aircraft on a vertipad.

[0196] 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 1502 can include facility operator user devices, such as user devices used bythe facility operators, facility operator user devices can be used to communicate with a transportation platform or perform various functions at an aerial facili ty. For example, facility operator user devices can run one or more software applications to complete security checks, check in / out luggage, coordinate re-charging / re-fueling, present safety briefings, or the like.

[0197] Aircraft devices 1504 can include one or more aircraft computing systems or aircraft operator user devices. For instance, aircraft devices 1504 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 1504 can include an aircraft operator’s user device (e.g., a pilot's mobile phone). Aircraft devices 1504 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. Client device 102 can be an aircraft device 1504.

[0198] Third-party provider systems 1506 can be associated with one or more third parties that provide resources for providing a transportation service. For example, third-party’ provider systems 1506 can be associated with a third-party aircraft provider, including one or more “third-party” aircraft. Third party aircraft can include aircraft provided, leased, loaned, or otherwise made available by an entity’ for use by transportation platform system 108 for transportation services.

[0199] Third-party provider systems 1506 can be associated with a provider of one or more third-party aircraft operators. Third-party aircraft operators can include, for example, a plurality’ of aircraft pilots that may be available to transportation platform system 108 for operation of an aircraft for the transportation services.

[0200] Third-party provider systems 1506 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. Transportation platform system 108 can communicate directly or indirectly (e.g.. through third-party- provider systems 1506, through scheduler 1508) with the third-party aircraft, operators, or infrastructure.

[0201] Third-party provider systems 1506 can correspond to a transportation platform system of another transportation service provider. For example, third-party provider system 1506 can correspond to a ground-based transportation platform provider system that canprovide transportation services for users to travel to departure locations and travel away from destination locations.

[0202] Scheduler 1508 can communicate with any one or more of client device 102, transportation platform system 108, airspace system 912, aerial facility devices 1502, aircraft devices 1504, or third party system 1506 to build an itinerary for a new trip for a user. Schedule 1508 can allocate resources of an aerial facility (e g., storage area, vertipad area, charging or refueling infrastructure, etc.) or allocate an aircraft for the requested new trip. Scheduler 1508 can be implemented external to transportation platform system 108, such as on its own independent server systems. Scheduler 1508 can be implemented internally by transportation platform system 108. Scheduler 1508 can be implemented by third-party' provider system 1506.

[0203] Facilitating an on-demand transportation service can involve complex coordination between multiple different systems and devices for allocating respective resources of each system to perform the various tasks associated with the on-demand multimodal transportation service. To help accommodate a particular service request, scheduler 1508 can generate itinerary data structures 1510. Itinerary data structures 1510 can include, for a particular user itinerary, a plurality of data objects that describe allocations of the respective resources from the participants in ecosystem 1500.

[0204] Itinerary data structure 1510 can include a variety of different data elements that specify aspects of a given itinerary. Itinerary data structures 1510 can include data computed based on or communicated by the systems / devices of ecosystem 1500. Itinerary data structures 1510 can store information associated with a particular user itinerary. This information may be stored in a platform system, remote from the user. Some or all of the information may be collected in real-time for use in implementing the technology’ of the present disclosure. Some, or all, of the information may be provided or made available to a user.

[0205] For instance, itinerary' data structures 1510 can include one or more data objects that include user device / request data 1512, transportation platform system data 1514. aerial facility device data 1516, aircraft device data 1518, airspace system data 1520. or third-party provider system data 1522.

[0206] User device / request data 1512 can include various types of information. For example, user device / request data 1512 can include data descriptive of a particular service request for which the itinerary is generated. User device / request data 1512 can include data descriptive of a user account for which the user itinerary is generated. User device / requestdata 1512 can include a user account identifier associated with a session during which a particular service request was submitted.

[0207] Transportation platform system data 1514, aerial facility7device data 1516, and aircraft device data 1518 can include data descriptive of assignments of aerial service system assets for servicing a particular service request. This can include identifiers of aerial facilities, aircraft, or operators, associated locations, statuses, availability, and / or other information. For some trips, aerial facility device data 1516 can designate facilities at multiple locations for stops along a journey.

[0208] Airspace system data 1520 can include various information associated with the airspace in which aircraft operate. This can include data descriptive of weather, air-traffic, or regulatory approval for flight operations in an airspace. In some implementations, airspace system data 1520 can include approved routes, flight paths, etc.

[0209] Third-party provider system data 1522 can include data descriptive of assignments of third-party system assets for serving a particular service request. This can include the identifiers, locations, statuses, availability, etc. of third-party aircraft or aerial facilities.

[0210] FIG. 16A illustrates an example device register 1602. The systems and devices of ecosystem 1500 may be registered for potential use when providing and coordinating a transportation service. Device register 1 02 can include a table or other data structure indicating devices / systems participating in the on-demand transportation platform ecosystem, such as ecosystem 1500. Device register 1602 can include fields such as Device ID, Entity, Location, Status, Availability, etc.

[0211] In some implementations, scheduler 1508 can maintain device register 1602 in a local or remote database. Systems and devices can register for participation in ecosystem 1500 by providing information to scheduler 1508 such as system / device identifiers, associated entities, IP addresses, downloading an application, signing-up or creating an account with scheduler 1508 (or an associated system), or other information for identifying and communicating with the system / device. Scheduler 1508 can update device register 1602 to provide a real-time reference for the characteristics and status of participating systems / devices. This can include, for example, determining whether a device is online or offline (e.g., powered on and connected, or not) or whether the device is available (e.g., not currently being utilized for another task) or unavailable (e.g., being utilized for another task).

[0212] When building a user itinerary, scheduler 1508 can generate a service instance register, such as an example service instance register 1604 shown in FIG. 16B. A serviceinstance register can include a data structure with one or more data objects that indicate the devices to be utilized for facilitating and progressing a user along their journey.

[0213] Scheduler 1508 can build a service instance register 1604 for servicing a particular service request. Service instance register 1604 can be associated with a unique or distinct sendee instance identifier for a particular user itinerary7for providing at least one leg of a transportation service. Service instance register 1604 can assemble a selection of participating devices from device register 1602. Service instance register 1604 can include at least a set of participating devices needed to complete at least a leg of a journey. Service instance register 1 04 may include all participating devices utilized to complete the entire leg of a journey. Scheduler 1508 can update and reconfigure service instance register 1604 as needed to accommodate for scheduling changes, delays, device substitution, etc. or as the joumey / itinerary progresses for a particular user.

[0214] Scheduler 1508 can generate itinerary data structure 1510 by querying one or more databases. A pilot account database can include entries associated with individual user accounts. The pilot account database can include data describing certifications associated with the corresponding user accounts. The pilot account database can include security keys or other cryptographic artifacts (e.g., biometric-based passkeys) that can be used for verifying communications to or from devices associated with a respective account. The pilot account database can include data describing an account level or tier indicating a priority status of requests associated with a respective account.

[0215] An aircraft database can include entries associated with individual aircraft or groups of aircraft. The aircraft database can include, for a respective entry for an aircraft, an aircraft ty pe indicator, characteristics of the aircraft (e.g., size, weight, power, speed, etc.), available control modes (e.g., autonomous, manual, etc.), location data, maintenance data, status data, etc.

[0216] Scheduler 1508 can determine aircraft availability based on the aircraft database. Available aircraft can include aircraft that are effectively available based on future movements of the aircraft. For example, aircraft that can be autonomously relocated to a vertipad within time / cost constraints can be effectively available at that vertipad. For instance, aircraft that are scheduled to arrive, finish charging, conclude maintenance procedures, etc. can be deemed effectively available if not available in fact. Assignment of aircraft that are available in fact can be prioritized based on a tier or level of the pilot account. For example, preferred-tier pilots can take priority for actually available aircraft (e.g., with a higher probability of being available in fact by the departure time). Standard-tier pilots can beassigned effectively available aircraft with a potentially increased risk of delay, cancellation, etc.

[0217] A vertipad database (e.g., vertipad registry 910) can include data describing vertipads registered for participation in ecosystem 1500. The vertipad database can include, for a respective vertipad, a capacity7(e g., how many aircraft it can support), a location, a status, a queue of trips using the vertipad, permissions associated with the vertipad (e.g., public, private, etc.), etc.

[0218] Scheduler 1508 can match, to a respective trip request, an aircraft and one or more aerial facilities to build an itinerary' for the trip request. The matching can be performed based on a set of constraints. The constraints can be obtained from the trip request or from other sources based on data in the trip request.

[0219] For example, a pilot certification constraint can include one or more hierarchical levels. For instance, in one aspect a pilot certification constraint can require that a pilot is qualified to fly the aircraft. In one aspect a pilot certification constraint can require that a pilot is eligible to fly the aircraft (e.g., all documents are in order and not expired). In one aspect a pilot certification constraint can require that a pilot is available to fly the aircraft at a given time (e.g., some regulations define a max time a pilot can fly per day, what the rest period should be, times of day during which flight can occur, etc.).

[0220] For example, a pilot certification constraint can include a requirement that a pilot possess a valid and current certification to fly an aircraft. A pilot certification constraint can include a requirement that a pilot possess a valid and current certification to fly an aircraft operated in association with transportation platform system 108. This can include a valid and current certification to fly an aircraft 110. Based on an account identifier associated with a trip request, a system (e.g., scheduler 1508, transportation platform system 108) can query a user account database to check one or more certifications or qualifications associated with a user account requesting a new trip. The system can confirm a status of the certifications by communicating with, for instance, certification authority7system 608. The system can receive updates from certification authority system 608 on a regular basis. The updates can occur daily, weekly, etc. The system can receive updates from certification authority system 608 on an on-demand basis such as, for example, at the time of trip scheduling time.

[0221] Scheduler 1508 can generate an itinerary7based on constraints from a trip request. For instance, a requested departure time, departure location, destination location, aircraft type, etc. can provide constraints for generating an itinerary. For example, an itinerary data structure 1510 can provide a solution (approximate or exact) to a constrained search overavailable aircraft, available vertipads, available maintenance or other ancillary equipment, available ground facility operators, etc.

[0222] Scheduler 1508 can generate an itinerary7based on one or more service requirements. For example, a service requirement may include maintenance, cleaning, inspection, or other services. Scheduler 1508 can generate an itinerary7to direct the aircraft to a location for performance of a service during or in between flight legs (e.g., an uncrewed leg). For example, after a user exits the aircraft and the aircraft is relocating to another location for performing a subsequent travel leg, scheduler 1508 can cause the aircraft to divert to a proximate service location, such as for cleaning of an interior of the aircraft. Scheduler 1508 can insert such diversions at periodic intervals based on one or more service requirements (e.g.. a cleaning can be performed after every passenger flight). A service location may be associated with transportation platform system 108 or may be operated by a third-party vendor.

[0223] A service location may be dynamically scheduled based on an availability7of a service at the service location at a time corresponding to the itinerary. A service location may be a location previously associated with a service provider or may be an ad hoc location dynamically selected based on a proximity7between the route of the aircraft and the ad hoc location and a proximity7between the service provider and the ad hoc location.

[0224] Scheduler 1508 can implement batch matching techniques. For instance, scheduler 1508 can accumulate requests over a designated time period. Scheduler 1508 can process the batch of requests over the time period to search for efficient assignments across the batch as a whole. Matches for the batch can be configured to improve metrics with respect to different parameters. The matches can be configured to improve a travel time. The matches can be configured to improve a net cost. The matches can be configured to improve a cost to a user. The matches can be configured to improve an availability of one or more aircraft for future trip requests.

[0225] Scheduler 1508 can relax one or more constraints of the trip request if no solution is achievable. This can include relaxing the departure time, aircraft type, departure location, destination location, etc. in an attempt to find a suitable match. Scheduler 1508 can generate multiple candidate itineraries that relax different constraints.

[0226] Scheduler 1508 can return one or more itineraries. Client device 102 can render an interactive interface configured to receive an input confirming the assembled itinerary.

[0227] For some journeys, upon confirmation of an itinerary, a user can travel to a location at which an assigned aircraft is located.

[0228] FIG. 17A is an illustration of an example review interface 1700 configured for receiving an input confirming an assembled itinerary. For example, review interface 1700 can include an input element 1702 configured to cause client device 102 to transmit a signal indicating confirmation of the itinerary.

[0229] Review interface 1700 can indicate that a departure is scheduled at a designated vertiport. “Santa Cruz East." Accordingly, after confirmation, a user can travel to the designated vertiport by the scheduled departure time. The vertiport can be the assigned departure location (e g., departure location 114).

[0230] FIG. 17B illustrates an example vertiport 1704. Example vertiport 1704 can include a number of aircraft that are staged or queued for one or more trips. Vertiport 1704 can include a storage area 1706 for storing aircraft. Vertiport 1704 can include a waiting area 1708 for pilots or passengers to await a designated departure time.

[0231] Vertiport 1704 can maintain on-demand inventory of aircraft. For instance, a user can arrive at vertiport 1704 and initiate a new trip without necessarily needing to schedule the trip in advance.

[0232] After confirming a new trip, a user can approach a selected aircraft and initiate the trip.

[0233] For some journeys, upon confirmation of an itinerary, an assigned aircraft can travel to the departure location to rendezvous with the user. For instance, after receiving an indication of a confirmed itinerary, transportation platform system 108 can initiate performance of the requested transportation service. For example, transportation platform system 108 can initiate autonomous relocation of an aircraft to the departure location.

[0234] FIG. 18A is an illustration of an example review interface 1800 configured for receiving an input confirming an assembled itinerary. For example, review interface 1800 can include an input element 1802 configured to cause client device 102 to transmit a signal indicating confirmation of the itinerary.

[0235] Review interface 1800 can indicate that a departure is scheduled at a designated vertipad, “Home." This can be a private vertipad added to the platform as described above. Accordingly, after confirmation, an assigned aircraft can be dispatched to rendezvous with the user at home.

[0236] FIG. 18B is an illustration of an example status indication interface 1810. Example status indication interface 1810 can provide, for a user, graphical or textual updates regarding a real-time status of the relocating aircraft. Status indication interface 1810 can include an input element 1812 configured to cancel the trip.

[0237] FIG. 18C is an illustration of an example uncrewed relocation leg. An uncrewed relocation leg can begin at a service location 1820. The service location 1820 can provide a dedicated area for the storage and upkeep of multiple aircraft. The uncrewed relocation leg can terminate at a departure location 1822. Departure location 1822 can be a private vertipad associated with a home of a user.

[0238] For departure locations 1822 that are onboarded with transportation platform system 108, a first trip to departure locations 1822 can include using a remote operator for a final approach. A first trip to departure locations 1822 can use piloted flight (with local or remote operator), whether the flight for the user journey or an overflight to collect information. A ground-based inspection can also provide information regarding the vertipad. For instance, a ground-based vehicle (autonomous or human-driven) can drive to the vertipad location to confirm data regarding the vertipad.

[0239] For departure locations 1822 that are onboarded with transportation platform system 108, a trip to departure locations 1822 can include collecting sensor data with one or more sensors of the aircraft to complete or confirm private vertipad data 908. The sensor data can include image data captured by image sensors of the aircraft, LIDAR data captured by a LIDAR sensor of the aircraft, RADAR data captured by a RADAR sensor of the aircraft, location data recorded from one or more location sensors or a localization system of the aircraft, etc. The aircraft can fly over the landing area one or more times to collect sufficient sensor data to complete or confirm private vertipad data 908. This can be performed each trip, for an initial trip, at regular intervals, etc.

[0240] Prior to or contemporaneously with a trip to departure locations 1822, operations can include collecting sensor data with one or more sensors of a different aircraft (of the same or different type, size, etc., such as a small drone specially equipped for this task) to complete or confirm private vertipad data 908. The sensor data can include image data captured by image sensors of the aircraft, LIDAR data captured by a LIDAR sensor of the aircraft, RADAR data captured by a RADAR sensor of the aircraft, location data recorded from one or more location sensors or a localization system of the aircraft, etc. The aircraft can fly over the landing area one or more times to collect sufficient sensor data to complete or confirm private vertipad data 908. This can be performed each trip, for an initial trip, at regular intervals, etc.

[0241] At some vertipads, local infrastructure can be installed. The local infrastructure can include a radar reflector, visual marker, weather station, RF beacon, etc. to provide an increased amount of data describing the vertipad for planning future journeys. The localinfrastructure can be deployed in a transportable unit that can be issued for private vertipads and installed with minimal site preparation or alteration. For instance, the local infrastructure can include post-mounted sensor packages that can be quickly installed. The local infrastructure can include solar power sources for off-the-grid power supply. The local infrastructure can include small uncrewed flying devices equipped with various imaging sensors to periodically or on-demand scout the vertipad location to provide updating mapping and occupancy information of the vertipad.

[0242] Departure location 1822 can also include other types of locations, such as public vertiports. For instance, a service location can be a location where aircraft are stored and maintained while a vertiport can be a departure location at which aircraft are positioned as needed in a ready -to-fly state.

[0243] Before landing, the aircraft can determine that the designated landing location is free of obstacles. The aircraft can determine that any people or animals are a sufficient distance away.

[0244] If there are obstacles, or if people or animals are not a sufficient distance away, the aircraft can trigger a communication to client device 102 (e.g., via transportation platform system 108) to cause client device 102 to render a message that instructs the user to clear the designated landing location.

[0245] The aircraft can initiate a loiter maneuver while awaiting clearance of a landing area. For example, the aircraft can await clearance of a landing area by other aircraft, by a user, etc. A loiter maneuver can include a hover or a circling path. The aircraft can compute a remaining energy reserve for performing the loiter maneuver. The aircraft can execute the loiter maneuver for such time as possible while reserving sufficient capacity to travel to a landing location at which the aircraft can be re-energized (refueled, recharged, etc.).

[0246] Upon landing, the aircraft can conduct a shutdown procedure. The aircraft can be in a deactivated or locked state after landing. The pilot application operating on client device 102 can facilitate activating or unlocking the aircraft.

[0247] FIG. 19 is an illustration of an example activation interface 1900 according to example aspects of the present disclosure. Activation interface 1900 can include an input element 1902 configured to initiate an unlocking procedure. The unlocking procedure can include authenticating an identity of the user and confirming that the user is within a threshold proximity to the aircraft. This allows for confirmation that the correct user is attempting to access the aircraft. Authentication can use biometric sensors of client device102, biometric sensors of the aircraft, or both. Cryptographic artifacts obtained or generatedby client device 102 or the aircraft can be compared against records on transportation platform system 108 to confirm an identity of the user. Based on confirming the identity of the user as the user scheduled to use the aircraft, the aircraft can be unlocked, and the user can be permitted to board the aircraft. For instance, transportation platform system 108 can transmit an unlock signal to the aircraft.

[0248] Activation interface 1900 can also include other functions. For instance, an input element 1904 can be configured to initiate an augmented reality walkthrough that can refresh a user’s memory of a control layout, emergency procedures, setup procedures, pre-flight procedures, etc. The augmented reality walkthrough can leverage an imaging sensor of client device 102 to display a currently captured image overlaid with helpful information describing features of the aircraft.

[0249] To facilitate and orchestrate pre- and post-flight procedures and checklists, aircraft fleet systems can interact with client device 102 associated with a pilot or other user. Client device 102 can use sensors or other components to verify operational statuses of aircraft components. For example, client device 102 can initiate a number of checks to confirm that the aircraft can fly the mission. The aircraft can perform one or more checks. The client device can perform one or more checks.

[0250] Example checks include confirmation or measurement of battery status (e.g., health, charge amount, etc ). Example checks include weight measurement and mapping. For example, seat sensors or cargo sensors in the aircraft can measure loaded weights. Client device 102 or the aircraft can process the measured weights to determine a total amount and a distribution of weight on the aircraft to determine if the loading is within approved ranges.

[0251] Client device 102 can use an interactive input interface to receive inputs from a user that confirms operational status of aircraft components. Client device 102 can guide a user through a checklist to remind the user of what needs to be reviewed, helping decrease errors and omissions.

[0252] Client device 102 can implement an augmented reality interface to highlight particular components to help ensure that the user is reviewing the correct components. Such interactive applications can facilitate faster turnaround times, increased consistency, and improved training for users.

[0253] An example improvement offered by example implementations of the present disclosure is increased reliability and decreased error rates by integrating a client device application with an aircraft computing system and an aircraft fleet system to perform pre- and post-flight procedures. This integration can permit error-checking across the devices andsystems, decrease operator error rates due to misunderstanding a checklist, forgetting a task item, etc. Error-checking can include using a client device to confirm that an aircraft sensor or component is working correctly. Error-checking can include using an aircraft sensor or component to confirm that a pilot or user is following appropriate procedures.

[0254] For example, activation interface 1900 can include an input element 1906 to initiate a guided orchestration of pre-flight procedures. Completion of the pre-flight procedures can be a prerequisite to fully unlocking the functionality of the aircraft. For instance, a final ignition or power state can be unlocked after completion of the pre-flight procedures.

[0255] FIGs. 20A and 20B illustrate an example implementation of a guided pre-flight procedure using a pilot application. To augment a visual inspection of the operability of the aircraft, a pre-flight procedure can include capturing image data of components of the aircraft and transmitting the image data to transportation platform system 108. For instance, a guided inspection interface 2000 can request imagery of a particular component 2002, and a user can use client device 102 to capture an image of the component.

[0256] FIG. 21 is a block diagram of a back end pre-flight procedure system. Transportation platform system 108 can communicate with client device 102 and aircraft devices 1504 to orchestrate a pre-flight procedure. For instance, a pre-flight procedure definition 2102 can include particular statuses or values that are to be confirmed in a preflight procedure. Client device 102 can render, in a pre-flight procedure interface 2104, interactive interface elements that request entry or capture of data descriptive of the particular statuses or values. Client device 102 can use sensors 2106 to collect sensor data 2108 to transmit to transportation platform system 108.

[0257] Sensor data 2108 can be processed on client device 108 or processed bytransportation platform system 108 to determine a status or value associated with a component described by the sensor data. Sensor data 2108 can include image data, video data, audio data, LIDAR data, inclinometer data, etc. For instance, images or videos of a component can be processed to determine a range of motion of the component, a deformation or deflection of a component, a color or brightness of a component, a noise made by the component when operating, a responsiveness of the component to inputs, etc. For instance, aircraft devices 1504 can provide actuation commands to one or more actuators of a component. Client device 102 can capture image, video, audio, LIDAR, or other sensor data describing an operation of the component. The sensor data from client device 102 can be indexed with the actuation commands from aircraft devices 1504 (e.g., by transportationplatform system 108) to evaluate a performance of the components (e.g., a latency, a responsiveness, etc.).

[0258] Pre-flight procedure definition 2102 can specify data items that can be collected from the aircraft directly. For instance, aircraft devices 1504 can include sensors 2110 that can collect sensor data 2112. One or more aspects of a pre-flight procedure can be performed automatically by aircraft devices 1504. For example, aircraft devices 1504 can poll one or more sensors on aircraft 110 to obtain data readouts from the sensors. Aircraft devices 1504 can evaluate the data from the sensors with respect to expected or normal values. This evaluation can reveal that one or more components of aircraft 110 could be outside of specification.

[0259] The self-evaluation of aircraft components by aircraft 110 itself can be associated wi th a confidence measure. For instance, aircraft 110 or transportation platform system 108 can analyze sensor data from aircraft 110 and generate a confidence value associated with the analysis. For instance, a determination that a component is within specification can be associated with a confidence value that the determination is within specification. The confidence value can derive from an internal state of a probabilistic machine-learned model that is inferring an operational condition status based on the sensor data. Confidence values can also be based on a quantify of information accessible to or acquired by aircraft 110. For example, an image sensor can capture washed-out images if a reflection or direct sunlight impinges its field of view. While the sensor can be perfectly operational, it may not instantly be able to capture sufficient information to confirm itself. As such, a measurement from the sensor can be associated with a low confidence.

[0260] Based on a confidence value associated with one or more aspects of the pre-flight procedure independently performed by aircraft devices 1504, transportation platform system 108 can send instructions to client device 102 to cause client device 102 to render an interface for confirming the aspects.

[0261] FIG. 22 is an illustration of an example interface 2200 for confirming various aspects of a pre-flight procedure. Such aspects can be selected based on a confidence associated therewith. Such aspects can be selected based on a lack of alternative data sources for obtaining the data.

[0262] After completing all pre-flight procedures, the flight can commence. The aircraft can activate manual control interfaces in the cockpit. The aircraft can activate the manual control interfaces by providing power to the manual control interfaces. The aircraft can activate the manual control interfaces by releasing an interlock preventing control signalsfrom the manual control interfaces from taking effect. The aircraft can set a software, firmware, or hardware indicator that causes the aircraft to respond in accordance with inputs to the manual control interfaces. The aircraft can enable a software, firmware, or hardware feature that monitors a state of a transducer associated with a manual control interface and generates one or more flight controls based on the state of the transducer.

[0263] The pilot can assume control of the one or more control interfaces. Client device 102 can be used as a control interface. Other computing systems or components of the aircraft can provide control interfaces. Control interfaces can use touch screens, physical buttons or controls, levers, pedals, yokes, microphones, etc. Control interfaces can receive and render one or multiple different modalities of inputs and outputs.

[0264] Availability of different control interfaces can be based on a region of land or airspace through which a planned route or flight plan is mapped. For instance, ‘'in network” flight plans that are contained within (e.g., do not exit) a designated autonomy -approved airspace can support fully automated or autonomous flight. The aircraft can enable a fully automated flight system responsive to a determination that the flight is within a region or airspace that is approved for fully automated flight.

[0265] To expand a range of possible flights or usage areas beyond limited or designated flight regions, the aircraft can enable or otherwise activate manual flight controls for “out of network” flight plans that are planned to exit designated autonomy-approved airspace. The aircraft can disable or otherwise deactivate autonomous flight system(s) for “out of network” flight plans that are planned to exit designated autonomy-approved airspace. The aircraft can initiate a flight within designated autonomy-approved airspace using an automated flight system and transition to manual flight control (e.g., with a control handoff) as the aircraft leaves the designated autonomy-approved airspace. If the control handoff is declined (e.g.. the aircraft receives an input signal indicating that the user is not assuming control), the aircraft can remain within the designated autonomy-approved airspace (e.g., returning to an origin, etc.).

[0266] The aircraft systems can be pre-loaded with flight plans for the requested flight. The aircraft systems can include guidance that guides a pilot in the procedures for following the flight plan. The aircraft systems can include guidance for how to interact with air traffic control or other aircraft (e.g., over a radio).

[0267] FIG. 23 is an example illustration of a cockpit of an aircraft according to example implementations of the present disclosure. A display interface 2300 can present one or morecontrols for controlling the aircraft. Display interface 2300 can provide augmented flight controls. For instance, display interface 2300 can provide waypoint-based control.

[0268] At the end of the flight, the aircraft can deactivate the manual control interfaces. The aircraft or transportation platform system 108 can conduct a post-flight procedure in a manner the same as or similar to the pre-flight procedure approach described above. Completion of the post-flight procedure can enable the pilot to "‘check in” the aircraft and relinquish responsibility for the aircraft. When appropriate, completion of the post-flight procedure can initiate scheduling of further transportation for the pilot to conduct a next leg of the j oumey .

[0269] Example implementations of the present disclosure can provide for a robust handover between pilot control and uncrewed operation as the aircraft transitions from a user flight leg to a relocation leg, and vice-versa. The aircraft can include systems that adjust a control system based on an occupancy status of the aircraft. For example, the aircraft can disable one or more uncrewed operations when a person is onboard the aircraft. For instance, the aircraft can use an interlock to prevent one or more uncrewed operations when the aircraft is occupied. This can help prevent unauthorized or unintentional travel on the aircraft outside the context of designated travel legs. Furthermore, this can help prevent the aircraft from flying or moving in a manner that surprises or is otherwise not expected by people onboard the aircraft. For instance, a control handover system can enable a manual control interface and assign flight responsibilities to a human pilot when the aircraft is occupied.

[0270] FIG. 24 is a block diagram of an example aircraft control system according to example aspects of the present disclosure. Aircraft control system 2400 can include a perception system 2402 that is configured to process and understand sensor data describing an environment surrounding the aircraft. Aircraft control system 2400 can include a decisionmaking system 2404 that can implement logic for responding to scenarios encountered in the environment. Guidance system 2406 can generate trajectories for controlling a flight of the aircraft over a rolling time horizon. Aircraft control actuators 2408 can execute the trajectories generated by guidance system 2406. For example, aircraft control systems can receive trajectories generated by guidance system 2406 and translate the trajectories into sequences of actuation instructions that can be submitted to aircraft control actuators 2408.

[0271] Perception system 2402 can include various different types of sensors. Perception system 2402 can include LIDAR sensors, RADAR sensors, visible light cameras, infrared cameras, inertial sensors, satellite-based location systems, etc. Perception system 2402 can receive sensor data inputs, process the sensor data to generate an understanding of thesurrounding environment, and output perception data that characterizes features of the environment in a format configured for further processing downstream in aircraft control system 2400.

[0272] Decision-making system 2404 can respond to various different types of scenarios to provide system-level instructions for resolving appropriate courses of action. Decisionmaking system 2404 can generate actions to facilitate, for instance, detect and avoid conflict resolution, ground collision avoidance, contingency management, occupied landing zone replanning, etc.

[0273] The operations of aircraft control system 2400 can include various levels of automation. The operations of aircraft control system 2400 can be guided by inputs from various different sources. A switching layer 2410 can determine whether aircraft control system 2400 is operated in autonomous mode 2412 by an autonomy system 2414, in remote- operated manual mode 2416 based on input signals 2418 received by a remote flight deck 2420 and relayed via a communication link 2422, or in locally-operated manual mode 2424 based on input signal 2426 received by an on-board flight deck 2428.

[0274] Switching layer 2410 can communicate with client device 102 and transportation platform system 108 to robustly perform mode switching.

[0275] Switching layer 2410 can include one or more control interlocks. Switching layer 2410 can include hardware interlocks. For instance, power cables can be disconnected by the interlock to protected systems disconnected until a conditional switching logic is satisfied. Switching layer 2410 can include firmware interlocks. For example, a firmware interlock can disable internal communication interfaces until condition is satisfied. Switching layer 2410 can include software interlocks (e.g., do not execute portion of code until condition satisfied).

[0276] Switching layer 2410 can include interlocks that can enforce a desired switching logic based on a status as crewed or uncrewed. For instance, an uncrewed control interlock can prevent uncrewed flight unless no people are on board (e.g., unless the aircraft is empty).

[0277] An uncrewed control interlock can interact with one or more occupancy detection systems to determine an occupancy of the aircraft. The occupancy detection systems can include weight sensors, image sensors, thermal sensors, audio sensors, etc. The uncrewed control interlock can actuate based on the occupancy status. A remote computing system (e.g., transportation platform system 108) can receive a snapshot or stream of the occupancy detection system outputs. The remote computing system can return a signal confirming the occupancy status.

[0278] A crewed control interlock can prevent crewed flight unless an authorized pilot is onboard. A crewed control interlock can be integrated with onboard sensor systems for detecting and identifying people and their credentials. A crewed control interlock can communicate directly or indirectly with client device 102 to determine a presence of client device 102 onboard. A crewed control interlock can be integrated with biometric sensors onboard the aircraft.

[0279] A remote server can release the interlocks. For instance, transportation platform system 108 can verify an absence of people onboard an aircraft (e.g., based on sensor data obtained from the aircraft) and transmit a signal that releases an uncrewed control interlock. Transportation platform system 108 can authenticate pilot credentials or facilitate a conversation with a human authenticator who can confirm the pilot's credentials.

[0280] Releasing an interlock can include providing, to the aircraft, a cryptographic artifact (e.g., security key) that can be used to decrypt one or more control interfaces. For example, the control interfaces can be inoperable when encrypted. For example, the control interfaces can include code or other instructions that can execute only when decrypted. In this manner, for instance, the interlock can prevent function of the aircraft absent the key.

[0281] An example aircraft can include a control actuator for controlling a component of the aircraft. For example, a control actuator can include a linear actuator, a motor, etc. that affect a position of another component of the aircraft. An example aircraft can include an uncrewed control system coupled to the control actuator using an uncrewed control interlock. For instance, the uncrewed control interlock can be configured to prevent, responsive to determining that a person is onboard the aircraft, the uncrewed control system from controlling the aircraft using the actuator. An example aircraft can include a crewed control system coupled to the control actuator using a crewed control interlock. The crewed control interlock can be configured to allow, responsive to authenticating a credential of the person, crewed control of the aircraft.

[0282] In some implementations of the example aircraft, the aircraft can include a sensor system configured to generate occupancy data that indicates a presence of any person onboard the aircraft. In some implementations of the example aircraft, the aircraft can include an aircraft computing system configured to process the occupancy data for determining that the person is onboard the aircraft. In some implementations of the example aircraft, the sensor system can include one or more sensor types selected from the following list: a weight sensor, an image sensor, or an audio sensor.

[0283] In some implementations of the example aircraft, the aircraft computing system can be configured to communicate with an authentication server to receive an authentication key for disengaging the uncrewed control interlock. In some implementations of the example aircraft, the aircraft computing system can be configured to communicate with an authentication server to receive an authentication key for disengaging the crewed control interlock. For example, the aircraft computing system can initiate a secured communication session with the authentication server using a web-based protocol. The aircraft computing system can request an authentication key from the authentication server. The authentication server can determine if the example aircraft is approved to receive an authentication key. The authentication server can conduct a multi-factor authentication procedure to determine that the aircraft is approved to receive an authentication key. The authentication server can transmit an authentication key to the aircraft. The aircraft can use the authentication key to engage or disengage one or more interlocks. For instance, the aircraft can use the authentication key to decrypt one or more values that are used for execution.

[0284] In some implementations of the example aircraft, the aircraft can include a sensor configured to detect a user device associated with the credential. The authentication of the credential can be based on detection of the user device in the aircraft. The aircraft can detect a presence of the user device using one or more short-range transponders, such as an NFC tag, an ultra-wide-band radio, etc. The aircraft can interact with a remote server system to confirm that the user device is in the aircraft. The remote server system can share a GPS location of the user device, which can be compared against a GPS location of the aircraft. The aircraft can display a transient encoding (e.g., a QR code), and the aircraft computing system or a remote computing system can compare an image captured by the user device to the transient encoding to determine whether the user device captured an image of the transient encoding. The authentication of the credential can be based on association of the credential to an authorized user account.

[0285] In some implementations of the example aircraft, the aircraft can include a biometric sensor associated with a crewed control interface. The biometric sensor can be configured for validating that the authenticated credential is associated with a person operating the crewed control interface.

[0286] The switching layer 2410 can determine whether aircraft control system 2400 is operated in autonomous mode 2412 by an autonomy system 2414, in remote-operated manual mode 2416 based on input signals 2418 received by a remote flight deck 2420 and relayed viaa communication link 2422, or in locally-operated manual mode 2424 based on input signal 2426 received by an on-board flight deck 2428.

[0287] In some implementations of the example aircraft, aircraft control system 2400 can leverage the same guidance system 2406 for both manual and automated flight modes. For instance, guidance system 2406 can operate as a waypoint-following system. The source of the waypoints can be a manual input or an automated decision from a decision-making system. For instance, an uncrewed flight mode can enable waypoint-based automated flight controls. For example, the decision-making system can output waypoints for the guidance system to follow7. Similarly, manual control interfaces can output waypoints for the guidance system to follow.

[0288] In this manner, for instance, guidance system 2406 and its interface with actuators 2408 can be disentangled from a particular selection of flight mode, allowing seamless transition between flight modes as needed. Further, this disentanglement can provide for dedicated optimization of the guidance system and the actuation systems independent from upstream control sources.

[0289] FIG. 25 depicts a flowchart diagram of an example method 2500 for coordinating providing a robust control handoff according to example embodiments of the present disclosure. Method 2500 can be performed by a computing system that includes one or more computing devices such as, for example, the computing systems described with reference to the other figures. Each respective portion of method 2500 can be performed by any (or any combination) of one or more computing devices. Moreover, one or more portions of method 2500 can be implemented as an algorithm on the hardware components of the devices described herein (e.g., as in any of the other FIGs., etc.).

[0290] FIG. 25 depicts elements performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that the elements of any of the methods discussed herein can be adapted, rearranged, expanded, omitted, combined, or modified in various ways without deviating from the scope of the present disclosure. FIG. 25 is described wi th reference to elements / terms described with respect to other systems and figures for example illustrated purposes and is not meant to be limiting. One or more portions of method 2500 can be performed additionally, or alternatively, by other systems.

[0291] At 2501, method 2500 can include accessing request data for a request for an available aircraft to fly. In method 2500, the request can be from a user device associated with a user. For example, a pilot can use a mobile phone to execute a pilot application. Thepilot application can facilitate booking trips to reserve aircraft to fly. For example, FIG. 5 illustrates an example personal homepage for a pilot in the pilot application.

[0292] At 2502, method 2500 can include computing an identifier of an aircraft of a fleet of aircraft to fulfill the request. The aircraft can be operable in an uncrewed flight mode or a crewed flight mode. For example, computing an identifier can include query ing a database that contains state data for a fleet of aircraft. The state data can include, respectively for individual aircraft of the fleet of aircraft, a respective status and a respective location.

[0293] For instance, a pilot can use the pilot application to request a trip with certain constraints on departure location, departure time, destination location, or aircraft ty pe. These constraints can be used to compile a query for query ing a database of aircraft. The query can contain various conditions that are to be satisfied based on the constraints. For instance, computing the identifier of the aircraft can include accessing a query result indicating the identifier of the aircraft, wherein the aircraft satisfies a query condition on at least one of the respective status of the aircraft or the respective location of the aircraft.

[0294] In some implementations of method 2500, querying the database can include querying the database with a query' that includes a query' condition that indicates a desired aircraft status (e g., available) or a desired aircraft location (e.g., nearby).

[0295] At 2503, method 2500 can include accessing data indicative of a departure location for the user to board the aircraft. For instance, an aircraft can be assigned to service the pilot’s trip request. A system can access data that indicates the departure location for the trip.

[0296] At 2504, method 2500 can include, based on the aircraft being located away from the departure location, transmitting instructions causing the aircraft to fly to the departure location in the uncrewed flight mode and without any passengers. For example, the aircraft selected to service the pilot’s request can be located at a service location that is removed from the departure location. To efficiently facilitate provision of the transportation service, the uncrewed aircraft can automatically fly to the departure location (e.g., as shown in FIG. 18C).

[0297] At 2505, method 2500 can include, based on the aircraft being located at the departure location, transmitting instructions causing the aircraft to deactivate the uncrewed flight mode and operate in the crewed flight mode. For example, once the aircraft arrives at the departure location (e.g., as shown in FIG. 18C), the aircraft can receive instructions from transportation platform system 108 to deactivate the uncrewed flight mode and operate in the crewed flight mode so that the pilot can fly the aircraft.

[0298] In some implementations of method 2500, method 2500 can include computing a flight plan for the aircraft from the departure location. For example, transportation platform system 108 can compute a flight plan for the aircraft from the departure location to the pilot’s destination.

[0299] In some implementations of method 2500, method 2500 can include transmitting, to the aircraft, an authorization key to unlock a crewed control interlock onboard the aircraft. For example, to enable the pilot to control the aircraft, a switching layer can deactivate a control interface from an autonomy system or a remote flight deck and enable control via an onboard flight deck. The switching layer can use a security key (e.g., a cryptographic artifact, such as public key. a private key, etc.) to decry pt or otherwise unlock a crewed control interface, thereby enabling the functionality. A transportation platform system 108 can transmit the key after an authentication process.

[0300] In some implementations of method 2500, transmitting the instructions causing the aircraft to deactivate the uncrewed flight mode and operate in the crewed flight mode can be initiated upon detection of a triggering condition. For example, the triggering condition can include accessing an indication from the aircraft that a user device associated with the user has been detected onboard the aircraft. The triggering condition can include accessing an indication from a user device associated with the user that the user device associated with the user is onboard the aircraft. For example, the pilot can come near the aircraft and engage an unlock function. The unlock function can use single or multi-factor authentication protocols to both confirm the identity of the pilot and confirm that the pilot’s user device is in or near the aircraft.

[0301] In some implementations of method 2500, method 2500 can include accessing an authentication request from the aircraft computing system. The authentication request can request disengagement of an uncrewed control interlock of an aircraft computing system of an aircraft. The uncrewed control interlock can be configured to prevent, responsive to the aircraft computing system determining that a person is onboard the aircraft, the uncrew ed control system from controlling the aircraft. For instance, as soon as the pilot boards the aircraft or comes wdthin a threshold distance of the aircraft, any uncrewed control system can be disabled, preventing the aircraft suddenly taking off or beginning to fly unless the pilot is safely deboarded.

[0302] In some implementations of method 2500, method 2500 can include computing, based on occupancy data from the aircraft computing system, an indication that no person is onboard the aircraft. In some implementations of method 2500, method 2500 can includetransmitting, based on the indication and to the aircraft computing system, an authentication key for disengaging the uncrewed control interlock.

[0303] FIG. 26 depicts a flowchart diagram of an example method 2600 for providing a robust control handoff according to example embodiments of the present disclosure. Method 2600 can be performed by a computing system that includes one or more computing devices such as, for example, the computing systems described with reference to the other figures. Each respective portion of method 2600 can be performed by any (or any combination) of one or more computing devices. Moreover, one or more portions of method 2600 can be implemented as an algorithm on the hardware components of the devices described herein (e.g., as in any of the other FIGs., etc.).

[0304] FIG. 26 depicts elements performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that the elements of any of the methods discussed herein can be adapted, rearranged, expanded, omitted, combined, or modified in various ways without deviating from the scope of the present disclosure. FIG. 26 is described with reference to elements / terms described with respect to other systems and figures for example illustrated purposes and is not meant to be limiting. One or more portions of method 2600 can be performed additionally, or alternatively, by other systems.

[0305] At 2601, method 2600 can include accessing request data for a request for an available aircraft to fly. The request can be from a user device associated with a user. For example, a pilot can use a mobile phone to execute a pilot application. The pilot application can facilitate booking trips to reserve aircraft to fly. For example, FIG. 5 illustrates an example personal homepage for a pilot in the pilot application.

[0306] At 2602, method 2600 can include computing an identifier of an aircraft of a fleet of aircraft to fulfill the request. The aircraft can be operable in an uncrewed flight mode compliant with a first flight standard and in a crewed flight mode compliant with a second flight standard. The first flight standard can correspond to regulations for beyond-visual-line- of-sight uncrewed flight and the second flight standard can correspond to regulations for crewed flight. The regulations can include one or more policies or standards set by a regulatory body. Example regulator}' bodies can include the Federal Aviation Administration, European Aviation Safety Agency, etc.

[0307] At 2603, method 2600 can include, based on the request data and the identified aircraft, computing routing data for the identified aircraft that identifies a planned route forthe aircraft. The planned route can include a relocation leg to relocate the aircraft to the requesting pilot.

[0308] At 2604, method 2600 can include, based on the routing data, selectively causing the aircraft to operate in the uncrewed flight mode or in the crewed flight mode for at least a portion of the planned route.

[0309] In some implementations of method 2600, transmitting instructions causing the aircraft to fly to the departure location in the uncrewed flight mode can include transmitting instructions causing the aircraft to fly in one or more skylanes designated for uncrewed flight. In some implementations of method 2600, transmitting instructions causing the aircraft to fly to the departure location in the uncrewed flight mode can include transmitting instructions causing the aircraft to fly in a region of airspace designated for uncrewed flight.

[0310] In some implementations of method 2600, at least one control parameter of the uncrewed flight mode is different from at least one parameter of the crewed flight mode. For instance, the at least one control parameter of the uncrewed flight mode can be adjusted for improved energy efficiency of the aircraft.

[0311] FIG. 27 depicts a flowchart diagram of an example method 2700 for coordinating providing a robust control handoff according to example embodiments of the present disclosure. Method 2700 can be performed by a computing system that includes one or more computing devices such as, for example, the computing systems described with reference to the other figures. Each respective portion of method 2700 can be performed by any (or any combination) of one or more computing devices. Moreover, one or more portions of method 2700 can be implemented as an algorithm on the hardware components of the devices described herein (e.g., as in any of the other FIGs., etc.).

[0312] FIG. 27 depicts elements performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that the elements of any of the methods discussed herein can be adapted, rearranged, expanded, omitted, combined, or modified in various ways without deviating from the scope of the present disclosure. FIG. 27 is described wi th reference to elements / terms described with respect to other systems and figures for example illustrated purposes and is not meant to be limiting. One or more portions of method 2700 can be performed additionally, or alternatively, by other systems.

[0313] At 2701, method 2700 can include determining that no person is onboard the aircraft.

[0314] At 2702, method 2700 can include, based on determining that no person is onboard the aircraft, controlling, using an uncrewed control system of the aircraft, a flight of the aircraft from a first location to a second location. For instance, the flight of the aircraft from a first location to a second location can include a relocation leg.

[0315] At 2703, method 2700 can include determining that a person is onboard the aircraft. For instance, one or more occupancy sensors can detect a presence of a person onboard the aircraft.

[0316] At 2704, method 2700 can include disabling, responsive to determining that the person is onboard the aircraft, the uncrewed control system of the aircraft.

[0317] FIG. 28 depicts a flowchart diagram of an example method 2800 for coordinating providing a robust control handoff according to example embodiments of the present disclosure. Method 2800 can be performed by a computing system that includes one or more computing devices such as, for example, the computing systems described with reference to the other figures. Each respective portion of method 2800 can be performed by any (or any combination) of one or more computing devices. Moreover, one or more portions of method 2800 can be implemented as an algorithm on the hardware components of the devices described herein (e.g., as in any of the other FIGs., etc ).

[0318] FIG. 28 depicts elements performed in a particular order for purposes of illustration and discussion. Those of ordinary skill in the art, using the disclosures provided herein, will understand that the elements of any of the methods discussed herein can be adapted, rearranged, expanded, omitted, combined, or modified in various ways without deviating from the scope of the present disclosure. FIG. 28 is described with reference to elements / terms described with respect to other systems and figures for example illustrated purposes and is not meant to be limiting. One or more portions of method 2800 can be performed additionally, or alternatively, by other systems.

[0319] At 2801, method 2800 can include receiving, from the aircraft computing system, an authentication request for disengaging an uncrew ed control interlock of an aircraft computing system of an aircraft. The uncrewed control interlock can be configured to prevent, responsive to the aircraft computing system determining that a person is onboard the aircraft, the uncrewed control system from controlling the aircraft.

[0320] At 2802, method 2800 can include, based on determining that no person is onboard the aircraft, controlling, using an uncrewed control system of the aircraft, a flight of the aircraft from a first location to a second location.

[0321] At 2803, method 2800 can include determining, based on occupancy data from the aircraft computing system, that no person is onboard the aircraft.

[0322] At 2804, method 2800 can include, based on determining that no person is onboard the aircraft, transmitting, to the aircraft computing system, an authentication key for disengaging the uncrewed control interlock.

[0323] In some implementations of method 2800, method 2800 includes receiving, from the aircraft computing system, credential data descriptive of a credential of a person onboard the aircraft. In some implementations of method 2800, method 2800 includes authenticating the credential data by associating the credential data with a user account authorized to manually control the aircraft. In some implementations of method 2800, method 2800 includes transmitting, to the aircraft computing system, an authentication key for disengaging a crewed control interlock of an aircraft computing system of an aircraft. The crewed control interlock can be configured to allow, responsive to authentication of the credential of the person onboard the aircraft, crewed control of the aircraft.

[0324] FIG. 29 depicts example system components of an example system 1 according to example implementations of the present disclosure. The example system 1 can include the computing system 5 and the computing system 50 that are communicatively coupled over one or more networks 45.

[0325] The computing system 5 can include one or more computing devices 10. The computing devices 10 of the computing system 5 can include one or more processors 15 and a memory 20. The processors 15 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 20 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.

[0326] The memory720 can store information that can be accessed by the processors 15. For instance, the memory720 (e.g., one or more non-transitory computer-readable storage mediums, memory devices) can include computer-readable instructions 25 that can be executed by the processors 15. The instructions 25 can be software written in any suitable programming language or can be implemented in hardware. Additionally, or alternatively, the instructions 25 can be executed in logically or virtually separate threads on processors 15.

[0327] For example, the memory 20 can store instructions 25 that when executed by the processors 15 cause the processors 15 to perform operations such as any of the operations and functions of any of the computing systems or computing devices described herein.

[0328] The memory 20 can store data 30 that can be accessed (e.g., obtained, received, written, manipulated, created, or stored). The data 30 can include, for instance, historical requests, context data, or other data / information described herein. In some implementations, the computing devices 10 can access from or store data in one or more memory devices that are remote from the computing system 5 such as one or more memory devices of the computing system 50.

[0329] In some implementations, the computing devices 10 can store one or more models. The models can include one or more machine-learned models, as described herein. In some implementations, the machined-leamed models can be trained, or re-trained, using computing devices 10. The machine-learned models can be trained using training data as described herein. In some implementations, the machined-leamed models can be stored on another device (e.g., computing system 50) and can be transmitted, or otherwise accessed by the computing system 5.

[0330] The computing devices 10 can also include a communication interface 35 used to communicate with one or more other systems (e.g., computing system 50). The communication interface 35 can include any circuits, components, software, etc. for communicating via one or more networks (e.g., 45). In some implementations, the communication interface 35 can include for example, one or more of a communications controller, receiver, transceiver, transmitter, port, conductors, software or hardware for communicating data / information.

[0331] The computing system 50 can include one or more computing devices 55. The computing devices 55 can include one or more processors 60 and a memory 65. The one or more processors 60 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 65 can include one or more non-transitory computer-readable storage media, such as RAM, ROM, EEPROM, EPROM, one or more memory7devices, flash memory7devices, etc., and combinations thereof.

[0332] The memory 65 can store information that can be accessed by the processors 60.For instance, the memory 65 (e.g.. one or more non- transitory computer-readable storage mediums, memory devices) can store data 75 that can be accessed. The data 75 can include,for instance, historical request data, context data, or other data or information described herein. In some implementations, the computing system 50 can access data from one or more memory devices that are remote from the computing system 50.

[0333] The memory 65 can also store computer-readable instructions 70 that can be executed by the processors 60. The instructions 70 can be software written in any suitable programming language or can be implemented in hardware. Additionally, or alternatively, the instructions 70 can be executed in logically or virtually separate threads on processors 60. For example, the memory 65 can store instructions 70 that when executed by the processors 60 cause the processors 60 to perform any of the operations or functions described herein, including, for example, any of the operations and functions of any of the computing systems or computing devices described herein.

[0334] In some implementations, computing devices 50 can store one or more models. The models can include one or more machine-learned models, as described herein. In some implementations, the machined-1 earned models can be trained, or re-trained, using computing devices 50. The machine-learned models can be trained using training data as described herein. In some implementations, the machined-leamed models can be stored at another device (e.g., computing system 5) and can be transmitted, or otherwise accessed by computing system 50.

[0335] Computing devices 55 can also include a communication interface 80 used to communicate with one or more other systems. Communication interface 80 can include any circuits, components, software, etc. for communicating via one or more networks (e g., 45). In some implementations, communication interface 80 can include for example, one or more of a communications controller, receiver, transceiver, transmitter, port, conductors, software or hardware for communicating data / information.

[0336] Networks 45 can be any type of network or combination of networks that allows for communication between devices. In some implementations, networks 45 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 or some combination thereof and can include any number of wired or wireless links. Communication over networks 45 can be accomplished, for instance, via a network interface using any type of protocol, protection scheme, encoding, format, packaging, etc.

[0337] FIG. 29 illustrates one example system that can be used to implement the present disclosure. Other computing systems can be used as well. Computing tasks discussed herein as being performed at one computing devices can instead be performed at another device, orvice versa. Such configurations can be implemented without deviating from the scope of the present disclosure. 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 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.Additional Disclosure

[0338] 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 follow ing claims can be combined or rearranged in any w ay 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, w'ith “or” being understood as “and / or” unless otherwise indicated. Also, terms such as “based on” should be understood as “based at least in part on.”

[0339] 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. Forinstance, 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.

[0340] The technology of the present disclosure may include the collection of data associated with a user. Collected data may be anonymized, pseudonymized, encrypted, noised, securely stored, or otherwise protected. Such collection may occur in the event that the user authorizes such collection or expressly opts into such collection. Authorization may be provided by the user via explicit user input to a user interface. The user input may be provided in response to a prompt that expressly requests such authorization. A user may opt out of such data collection at any time.

Claims

1. WHAT IS CLAIMED IS:

1. A computer-implemented method comprising: accessing request data for a request for an available aircraft to fly, wherein the request is from a user device associated with a user; computing an identifier of an aircraft of a fleet of aircraft to fulfill the request, the aircraft being operable in an uncrewed flight mode or a crewed flight mode; accessing data indicative of a departure location for the user to board the aircraft; based on the aircraft being located away from the departure location, transmitting instructions causing the aircraft to fly to the departure location in the uncrewed flight mode and without any passengers; and based on the aircraft being located at the departure location, transmitting instructions causing the aircraft to deactivate the uncrewed flight mode and operate in the crewed flight mode.

2. The computer-implemented method of claim 1, wherein computing the identifier of the aircraft comprises: query ing a database comprising state data for the fleet of aircraft, the state data comprising, respectively for individual aircraft of the fleet of aircraft, a respective status and a respective location; accessing a query result indicating the identifier of the aircraft, wherein the aircraft satisfies a uery condition on at least one of the respective status of the aircraft or the respective location of the aircraft.

3. The computer-implemented method of claim 2, wherein querying the database comprises: query ing the database with a query comprising the query' condition, the query condition indicating a desired aircraft status or a desired aircraft location.

4. The computer-implemented method of any of the preceding claims, comprising: computing a flight plan for the aircraft from the departure location.

5. The computer-implemented method of any of the preceding claims, comprising: transmitting, to the aircraft, an authorization key to unlock a control interlock onboard the aircraft.

6. The computer-implemented method of any of the preceding claims, wherein transmitting the instructions causing the aircraft to deactivate the uncrewed flight mode and operate in the crewed flight mode is initiated upon detection of a triggering condition.

7. The computer-implemented method of claim 6, wherein the triggering condition comprises: accessing an indication from the aircraft that a user device associated with the user has been detected onboard the aircraft.

8. The computer-implemented method of any one of claims 6 or 7. wherein the triggering condition comprises: accessing an indication from a user device associated with the user that the user device associated with the user is onboard the aircraft.

9. The computer-implemented method of any of the preceding claims, comprising: accessing an authentication request from the aircraft computing system, the authentication request requesting disengagement of an uncrewed control interlock of an aircraft computing system of an aircraft, wherein the uncrewed control interlock is configured to prevent, responsive to the aircraft computing system determining that a person is onboard the aircraft, the uncrewed control system from controlling the aircraft; computing, based on occupancy data from the aircraft computing system, an indication that no person is onboard the aircraft; and transmitting, based on the indication and to the aircraft computing system, an authentication key for disengaging the un crewed control interlock.

10. A computer-implemented method comprising: accessing request data for a request for an available aircraft to fly, wherein the request is from a user device associated with a user;computing an identifier of an aircraft of a fleet of aircraft to fulfill the request, the aircraft being operable in an uncrewed flight mode compliant with a first flight standard or in a crewed flight mode compliant with a second flight standard, the first flight standard corresponding to regulations for beyond-visual-line-of-sight uncrewed flight and the second flight standard corresponding to regulations for crewed flight; based on the request data and the identified aircraft, computing routing data for the identified aircraft that identifies a planned route for the aircraft; and based on the routing data, selectively causing the aircraft to operate in the uncrewed flight mode or in the crewed flight mode for at least a portion of the planned route.

11. The computer-implemented method of any of the preceding claims, wherein transmitting instructions causing the aircraft to fly to the departure location in the uncrewed flight mode comprises: transmitting instructions causing the aircraft to fly in one or more skylanes designated for uncrewed flight; or transmitting instructions causing the aircraft to fly in a region of airspace designated for uncrewed flight.

12. The computer-implemented method of any of the preceding claims, wherein: at least one control parameter of the uncrewed flight mode is different from at least one parameter of the crewed flight mode, wherein the at least one control parameter of the uncrewed flight mode was adjusted for improved energy efficiency of the aircraft.

13. The computer-implemented method of any of the preceding claims, wherein: at least one control parameter of the uncrewed flight mode is different from at least one parameter of the crewed flight mode, wherein the at least one control parameter of the uncrewed flight mode corresponds to a stability margin of the aircraft.

14. The computer-implemented method of any of the preceding claims, wherein the crewed flight mode enables waypoint-based manual flight controls using an input interface onboard the aircraft.

15. The computer-implemented method of any of the preceding claims, wherein the uncrewed flight mode enables waypoint-based automated flight controls.

16. The computer-implemented method of any of the preceding claims, wherein the waypoint-based manual flight controls and the waypoint-based automated flight controls are configured to both provide waypoint-based control commands to a waypoint following flight system of the aircraft.

17. One or more non- transitory computer-readable media storing instructions that are executable by one or more processors to perform operations, the operations comprising the method of any of the preceding claims.

18. A computing system, comprising: 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 comprising the method of any one of the preceding claims.

19. An aircraft, comprising: a control actuator for controlling a component of the aircraft; an uncrewed control system coupled to the control actuator using an uncrewed control interlock, wherein the uncrewed control interlock is configured to prevent, responsive to determining that a person is onboard the aircraft, the uncrewed control system from controlling the aircraft; and a crewed control system coupled to the control actuator using a crewed control interlock, wherein the crewed control interlock is configured to allow, responsive to authenticating a credential of the person, crewed control of the aircraft.

20. The aircraft of any of the preceding claims, comprising: a sensor system configured to generate occupancy data that indicates a presence of any person onboard the aircraft.

21. The aircraft of any of the preceding claims, comprising: an aircraft computing system configured to process the occupancy data for determining that the person is onboard the aircraft.

22. The aircraft of any of the preceding claims, wherein the sensor system comprises one or more sensor types selected from the following list: a weight sensor, an image sensor, or an audio sensor.

23. The aircraft of any of the preceding claims, wherein the aircraft computing system is configured to communicate with an authentication server to receive an authentication key for disengaging the uncrewed control interlock.

24. The aircraft of any of the preceding claims, wherein the aircraft computing system is configured to communicate with an authentication server to receive an authentication key for disengaging the crewed control interlock.

25. The aircraft of any of the preceding claims, comprising: a sensor configured to detect a user device associated with the credential; wherein authentication of the credential is based on: detection of the user device in the aircraft, and association of the credential to an authorized user account.

26. The aircraft of any of the preceding claims, comprising: a biometric sensor associated with a crewed control interface; wherein the biometric sensor is configured for validating that the authenticated credential is associated with a person operating the crewed control interface.

27. An aircraft computing system for controlling flight of an aircraft, comprising: 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 cause the aircraft computing system to perform operations, the operations comprising: determining that no person is onboard the aircraft; based on determining that no person is onboard the aircraft, controlling, using an uncrewed control system of the aircraft, a flight of the aircraft from a first location to a second location; determining that a person is onboard the aircraft; anddisabling, responsive to determining that the person is onboard the aircraft, the uncrewed control system of the aircraft.

28. A remote computing system for disengaging an uncrewed control interlock of an aircraft computing system of an aircraft, comprising: 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 cause the authentication server to perform operations, the operations comprising: receiving, from the aircraft computing sy stem, an authentication request for disengaging an uncrewed control interlock of an aircraft computing system of an aircraft, wherein the uncrewed control interlock is configured to prevent, responsive to the aircraft computing system determining that a person is onboard the aircraft, the uncrewed control system from controlling the aircraft; determining, based on occupancy data from the aircraft computing system, that no person is onboard the aircraft; and based on determining that no person is onboard the aircraft, transmitting, to the aircraft computing system, an authentication key for disengaging the uncrewed control interlock.

29. The remote computing system of claim 28, wherein the operations comprise: receiving, from the aircraft computing system, credential data descriptive of a credential of a person onboard the aircraft; authenticating the credential data by associating the credential data with a user account authorized to manually control the aircraft; and transmitting, to the aircraft computing system, an authentication key for disengaging a crewed control interlock of an aircraft computing system of an aircraft, wherein the crewed control interlock is configured to allow, responsive to authentication of the credential of the person onboard the aircraft, crewed control of the aircraft.

Images