Patent ID: 12223846

DETAILED DESCRIPTION

FIG.1shows an aerial vehicle1according to the invention in the form of a multicopter with18drive units (actuators). InFIG.1, L, M and N denote the moments about the axes x, y and z (rolling axis, pitching axis and yawing axis) of the aerial vehicle1, and F denotes the overall thrust. Reference sign2symbolizes the (main) flight control of the aerial vehicle1, which preferably has at reference sign2aa control unit (computing unit) according to the invention and required control and planning algorithms2aaand also a database2aband generally is configured for carrying out the method according to the invention and its developments, in particular by using software. Additionally shown at reference sign2bis a human pilot, which is not of any further note in the present case. Reference sign3denotes one of the 18 (unrestrictedly identical) drive units or actuators, in each case comprising an (electric) motor3aand a rotor3b. Reference sign4denotes by way of example a sensor unit operatively connected to the main flight control unit2or the control unit2a, in order in a development of the method according to the invention to be able to take into account the available states of the aerial vehicle and environmental conditions by means of sensors. Although not shown, a multiplicity of such sensor units4may be provided, in particular inertial measuring units, GNSS, barometers, vibration sensors at the actuators, temperature sensors at the actuators, and the like. Reference sign5symbolizes a further computing unit (data pre-processing unit), which is not on board the aerial vehicle1but is stationed on the ground. Preferably taking place on this ground-based computing unit5is the preplanning further explained in detail above, the results of which are subsequently transferred to the control unit2aof the aerial vehicle1and are stored there in the database2ab. Although only one database2abis shown inFIG.1, there may also be a number of databases, or the database2abmay be divided into a number of databases, in particular the trajectories database mentioned further above and the maneuvers database likewise mentioned further above.

However, the invention is not in any way restricted to the presence of a ground-based computing unit5. It goes without saying that all of the planning operations, that is to say also the preplanning, can be carried out on board the aerial vehicle1, as long as it has sufficient computing power. As a person skilled in the art appreciates, the planning operations may also be divided as desired between the ground-based computing unit5and the control unit (computing unit)2aof the aerial vehicle1.

FIG.2shows on a conceptual level the division of the multi-dimensional planning space into separate planning approaches for operational states and flight phases and also the higher-level planning process, as it can be performed in the course of the method according to the invention. This is shown in the form of a conceptual mission planning architecture, in which, depending on an operational state of the aerial vehicle and a flight phase, different path planning methods are used in order to produce at any time a planning solution adequate for the situation. The mission planning architecture referred to is preferably formed by software within the control unit2a(compareFIG.1) (denoted inFIG.1as a whole by the reference sign2aa).

Shown at reference sign20inFIG.2are preprocessed and prepared aerial-vehicle and environmental data, which may for example and without restriction comprise for example a flight envelope, geo-data, risk maps or a landing site database. Reference sign21denotes the altitude profile planning referred to further above, while reference sign22stands for the maneuver calculation or maneuver machine calculation. Preferably, according to reference sign20, the data are included in the altitude profile planning21and the maneuver calculation22. In particular, the maneuvers calculated at reference sign22may be stored in the already mentioned maneuvers database.

Reference sign23stands for the nominal planning, while reference sign24stands for the contingency planning. The former comprises at reference sign23aa path planner with an objective function for nominal states of the aerial vehicle. The objective function is a function of the parameters of the objective in dependence on one or more input variables. In the nominal case, it is a metric that considers mission risk and energy efficiency. Also comprised at reference sign23bis a so-called corridor planner, which implements an operating concept for the bidirectional use of a flight path identified in advance in the nominal planning. For this, “travel paths” separated horizontally and vertically from one another, on which aerial vehicles can fly in opposite directions at a safe distance, are generated on the basis of the original flight path. The flying altitude is adapted in accordance with existing air traffic rules. Any difference in altitude there may be is bridged by means of helix maneuvers. The contingency planning24comprises at reference sign24aa first path planner (“contingency planner1”) with an objective function for contingency states. Furthermore, it comprises at reference sign24ba second path planner (“contingency planner2”) with an objective function for contingency states. Reference signs24aand24bdenote in the specific case the contingency off-line planner (24a) and the on-line planner (24b), as already explained further above. A precondition is the preplanning of a database with contingency flight paths in a tree structure. On each trajectory, paths to all available alternate landing sites are planned at constant time intervals. This call takes place as long as the still remaining time interval until landing is less than that of the planner call (new planning interval), or until another termination criterion (for example coverage) is reached. The exact planning approach for calculating the database is of secondary concern, as long as the database can be validated before departure. A planning solution must be verifiable and validatable by the competent authorities before departure. This arises from the requirements for precalculated flight paths in accordance with SC-VTOL. In the specific case, this means that the planning approach is of secondary concern as long as the planning solution before departure is in a format that can be checked for correctness and conformity with the rules either by machine or by a person.

In this context, so-called wavefront algorithms can be used, by means of which navigation functions can be calculated for a number of parameters of an objective. Also implemented in particular are navigation functions, which minimize the distance traveled, energy requirement and flying time. In accordance with the approach of dividing a large planning problem into many small problems, the number of planners is however not restricted here in principle to these two and can be extended to further sub-problem-specific planners, which is likely to happen in practice.

Reference sign25denotes an approach planner, which is specifically designed for the calculation of approach trajectories. Here, different approach directions to a vertiport (landing site) are precalculated, and may be selected according to the wind and occupancy by other aerial vehicles. Furthermore, reference sign26stands for a landing planner, which is specifically designed for the calculation of landing trajectories. AsFIG.2reveals, the approach planner25and the landing planner26overlap both with the nominal planning23and with the contingency planning24. This is synonymous to saying that planning modules that cover flight phases across operational states are used over operational states.

Shown at reference sign27is an emergency planning, which comprises at reference sign27aa path planner with an objective function for emergency states.

Finally, reference sign28stands for the already mentioned decision logic at mission level, which in the normal case is designed to select on the basis of physical states of the aerial vehicle1determined by sensors (compareFIG.1) and its environment between precalculated trajectory components from the database2ab(compareFIG.1) and to put together from them a flight path that is optimum currently under specific criteria.

As already stated further above, in response to an incoming planning request there is initially extensive preplanning, which is transferred to the database in the aerial vehicle and can be used during the flight to reduce the planning problem to a problem of purely deciding on the flight path in the database that is most suitable in each case (decision logic28). If events or emergency situations that the pre-planned database does not cover occur, this activates an on-line planning algorithm, which, on the basis of the likewise precalculated maneuvers database, restores a safe flying state that is provided in the database by using the maneuvers contained in the maneuvers database (in the form of corresponding control commands) to activate the aerial vehicle, or in particular its drive units, correspondingly.

The algorithm used within the framework of the emergency planning27(path planner27a) is preferably the same that is also used in the contingency case. However, in the contingency case the on-line planner plans within precalculated spaces and only between two pre-planned trajectories. In an emergency, less stringent constraints apply, and the on-line planner is used to calculate at the flying time an emergency landing trajectory to a landing site likewise identified at the flying time. In a possible specific case, the same function call is used in the contingency planner24band in the emergency planner27a.

FIG.3shows a macroscopic flow diagram of the mission planning process. Data records concerning the aerial vehicle and its environment are prepared and already provide a database for the planning process before a planning request for a specific mission comes in. Extensive preplanning reduces the computing effort (on board the aerial vehicle) during operational flight.

Reference sign30stands for a planning environment, for example a city, and the associated environmental data. Reference sign31stands for aerial vehicle parameters or for data concerning the aerial vehicle. The environmental data30are collected or stored in an associated database32, possibly after prior preparation. After corresponding calculation, the aerial vehicle parameters31lead to the already repeatedly mentioned maneuvers, which are likewise stored in a database33. If a planning request34then takes place on the basis of corresponding takeoff and destination coordinates35, the already repeatedly mentioned preplanning takes place at reference sign36. Subsequently, takeoff37takes place, after which the precalculated maneuvers from the database33are then also included in the further planning. Reference sign38stands for the already mentioned logical selection of trajectories or an additional on-line planning, if required.

Reference to these relationships has already been made in detail further above in the general part of the description.

FIG.4illustrates the assignment of the individual planning components on the basis of their execution time within the planning process and describes here in particular the division of the path and mission planning process into on-line and off-line components.

It has already been pointed out that in an extensive pre-calculating phase, on the assumption of an operating environment (for example a metropolitan region) that is largely known and subject to sufficiently slow changing processes, the nominal planning and also large parts of the contingency planning (compareFIG.2) are already carried out before departure and transferred to an (inspectable and validatable) trajectories database. In parallel, a maneuver library specifically designed for the aerial vehicle and associated maneuver machine are generated and are likewise stored in a database (compareFIG.3). Both databases are transferred to the aerial vehicle before departure (compare database2abinFIG.1). During the flight, preferably the decision module mentioned inFIG.2(decision logic, logic module28—preferably a software function) decides whether there is an emergency requiring intervention of the emergency on-line planning algorithm (reference sign27inFIG.2). If this is not the case, the global path planning problem can be reduced to a logic problem, which selects the most suitable trajectory from the trajectories database (reference sign38inFIG.3). As long as a suitable branching point can be reached, events/conflicts that are not critical to safety are resolved as so-called contingencies, likewise at the logic level, by diverting to a conflict-free trajectory. If a change between pre-planned trajectories is required between branching points, this can be carried out within likewise predefined zones by means of a contingency on-line planner43.

InFIG.4, the individual components are as far as possible denoted as they have already been denoted previously, in particular inFIGS.2and3. In this case, in particular the landing site planner mentioned inFIG.4may correspond to the already mentioned landing planner26(FIG.2). The already mentioned logic module28is also preceded at reference sign40by a decision module at mission level, which in turn may also be preceded by an updating of the flight envelope at reference sign41. Depending on how the decision taken at reference sign40turns out, either the logic module28or the emergency plan27comes into action, wherein the results of the latter act directly on the flight controller42, i.e. are used for activating the units concerned of the aerial vehicle. The logic module28is followed by a contingency on-line planner43, which accesses the trajectories database44and the maneuvers database33, if required. The logic module28or the contingency on-line planner43also act directly on the flight controller42, wherein the logic module28also accesses the trajectories database44. As already mentioned, the trajectories database44and the maneuvers database33may physically take the form of a common database (compare reference sign2abinFIG.1).

According toFIG.4, the nominal planner23and also the contingency planner24according toFIG.2, along with their subordinate planning modules, are arranged within a so-called horizontal planner45, which preferably performs the planning of the flight path in a (horizontal) plane perpendicular to the mentioned altitude profile.