Unmanned Air-traffic Management (UTM): Formalization, a Prototype Implementation, Verification, and Performance Evaluation
11 Unmanned air-traffic management (UTM):Formalization, a prototype implementation, andperformance evaluation
Chiao Hsieh ∗ , Hussein Sibai † , Hebron Taylor ‡ and Sayan Mitra § Coordinated Science LaboratoryUniversity of Illinois at Urbana-ChampaignUrbana, IL 61801Email: { chsieh16,sibai2,hdt2,mitras } @illinois.edu Abstract
Unmanned Aircraft Systems (UAS) are being increasingly used in delivery, infrastructure surveillance, fire-fighting, and agriculture. According to the Federal Aviation Administration (FAA), the number of active smallcommercial unmanned aircraft is going to grow from 385K in 2019 to 828K by 2024. UAS traffic management (UTM)system for low-altitude airspace is therefore immediately necessary for its safe and high-density use. In this paper,we propose the first formalization of FAA’s Concept of Operations for UTM for building and analyzing trafficmanagement protocols and systems. We formalize FAA’s notion of operation volumes that express aircraft intent interms of 4D blocks of airspace and associated real-time deadlines. We present a prototype coordination protocol usingoperation volumes, involving participating aircraft and an airspace manager. We formally analyze the safe separationand liveness properties of the protocol. Our analyses showcase how the de-conflicting and liveness of the system canbe proven assuming each aircraft conforms to the operation volume deadlines. Through extensive simulations we alsoevaluate the performance of the protocol in terms of workload and response delays. Our experiments show that theworkload on the airspace manager and the response time of each aircraft grow linearly with respect to the number ofparticipating aircraft. The experiments also delineate the trade-off between performance, workload, and violation rateacross different strategies for generating operation volumes. Lastly, we implement a UTM violation detection andresolution mechanism on top of our protocol. We include a simple fault injection technique that introduces failureswith different probabilities. We demonstrate how to use it to empirically evaluate the impact of aircraft failure onthe safety of surrounding aircraft, and how the performance of the airspace manager changes under different failureprobabilities.
I. I
NTRODUCTION
Unmanned Aircraft System (UAS) Traffic Management (UTM) is an ecosystem of technologies that will enableunmanned, autonomous and human-operated, vehicles to be incorporated in a variety of services in transportation,surveillance, and delivery. By 2024, 1.48 million of recreational and 828K of commercial unmanned aircraft areexpected to be flying in the national airspace [1]. Unlike the commercial airspace, this emerging area will have toaccommodate diverse and innovative vehicles relying on real-time distributed coordination, federated enforcementof regulations, and lightweight training for safety. NASA, FAA, and their partners are investigating and prototypingvarious UTM concepts, use cases, information architectures, and protocols that will enable large number of vehiclesto safely operate beyond visual line-of-sight. NASA was awarded the 2020 Government Invention of the Year forits patent on UTM .Existing regulations do not cover fully autonomous air-vehicles, which is one of the goals of the UTM framework FAA’s Concept of Operations for UTM (ConOps Ver 2.0) [2] defines the basic principles for safe coordination inUTM and the roles and responsibilities for the different parties involved such as the vehicle operator, manufacturer,the airspace service provider, and the FAA. The document does not provide concrete protocols for de-conflictingaircraft paths or rigorous analysis of UTM for safety or efficiency. UTM ConOps were successfully field testedin Summer 2019 with different scenarios in three different sites in the US [3]. These early promising experimentshave created a need for formal safety analyses and larger scale empirical evaluations of the coordination protocolswith a larger number of aircraft in different types of scenarios. https://utm.arc.nasa.gov/index.shtml a r X i v : . [ c s . M A ] S e p UTM operations are managed through interactive planning and orchestration of intent information that enablestrategic (i.e., long term) de-confliction for multiple UAS. Intent sharing and strategic de-confliction reduce the needfor tactical separation management (see Section II) and reduce the likelihood of in-flight intent changes. A keyconcept in ConOps is that the intent is expressed as operation volume segments which are 4D blocks of airspacethat have real-time specifications for entry and exit for the UAS. The ConOps report [2] describes how operationvolumes can be used for monitoring, de-conflicting, and operating UAS.In this paper, we present an executable formal model inspired by the ConOps and study its safety, scalability,and performance. To our knowledge, we are the first to formalize the notion of operation volumes and show howintention expressed as operation volumes can be used for detecting anomalous behavior of air-vehicles and fordistributed de-conflicting. We then use a concrete representation of operation volumes to develop a de-conflictingprotocol. This baseline protocol precisely specifies the interaction between the participating agents (the aircraft),with the airspace manager (the UAS service supplier in the UTM parlance). Our formal analyses of the safety andliveness of this protocol illustrate how formal reasoning can be applied to the family of protocols using operationvolumes. Our safety analysis shows that the use of operation volumes helps decompose the global de-conflictingof the UAS into local real-time requirements on each agent. We prove that the safety of the protocol is achievedprovided individual agents follow their declared operation volume. The liveness analysis further shows that everyagent can eventually find a non-conflicting operation volume, under a stricter set of assumptions.We also present a open and flexible reference implementation of this protocol in a simulator (see Figure 1)that can accommodate heterogeneous UAS. We use this simulator to perform detailed empirical analysis of theUTM concepts and our de-conflicting protocol in a number of representative scenarios. Our experiment quantifiesthe performance, workload, and violation rates of operation volumes, and we measure these metrics with respectto the number of participating agents and different kinds of operation volumes. Our experiments suggest thatthe computation load on the airspace manager scales linearly with the number of participating agents. They alsoreaffirm the protocol’s safety and liveness guarantees. The overall performance of the UAS is determined by theaggressiveness of each agent, i.e., the proposed operation volumes are more restrictive with tighter deadlines. Wecompare two strategies, namely C
ONSERVATIVE and A
GGRESSIVE , for generating operation volumes. The resultshows that A
GGRESSIVE provides 1.5-3X speedup, but it also leads to 2-5X increased workload on the airspacemanager and up to 10% of violation rate.Finally, we provide an implementation of UTM violation detection and resolution mechanism based on ourprotocol with extra communication for reporting to the airspace manager, alerting possibly affected agents, andre-planning with new operation volumes. We also develop a simple technique to introduce failures with differentprobabilities. Our preliminary result shows that the number of all affected aircraft from a failure of one mainlydepends on the quality of the planned paths and physical distances between aircraft. It does not depend as muchon the total number of aircraft. We also show that the workload increases on the airspace manager with increasingprobability of failure due to the increased number of requests for new operation volumes when resolving violations.II. R
ELATED WORK
Collision avoidance protocols:
Prior to the development of the UTM ecosystem, traffic management protocolsfor manned aircraft include the family of Traffic Alert and Collision Avoidance Systems [4]. The development withthe Beacon Collision Avoidance System (BCAS) in the 1970, which was enhanced to become the Traffic CollisionAvoidance System (TCAS) in the 1990s; and the latest version is the Next-Generation Airborne Collision AvoidanceSystem (ACAS X) [5]. ACAS X includes separate protocols for large aircraft (ACAS Xa) and for unmanned vehicles(ACAS Xu) [6], [7].The ACAS family of protocols specify the sensors an aircraft should use to detect nearby aircraft and the sensingstrategy to be used. For example, active interrogation of intruder aircraft such as in TCAS and ACAS X, or passivesensing as in BCAS. Second, the protocols specify the collision detection strategy which includes rules for howfuture states of the involved aircraft are predicted. Finally, they specify the collision avoidance strategy using verticaladvisories for the aircraft such as “Do Not Climb” and “Climb with 1500 ft/min”. A survey of existing protocolscan be found in [8]. ACAS X is an optimized version of TCAS using dynamic programming. It minimizes thenumber of alerts while not compromising the collision avoidance capability. The optimization is done offline andits result, that maps states to advisories, is stored in large tables [9], and later in neural nets [6]. Several surveyarticles cover these and other collision avoidance protocols air vehicles [10], [11].Unlike ACAS, our protocol (in Section IV) is not designed to activate only for potential collision avoidance.Our protocol is more aligned with the UTM vision and coordinates longer range strategic planning and ensuressafety against a wider range of hazards including loss of separation with other aircraft and static obstacles, weather
Fig. 1.
Visualization of two air-vehicles in a delivery-like scenario in a city block in our simulator. The operation volumes areannotated with orange wireframes and the waypoints are shown in green. events, and anomalous behaviors. Our framework and existing collision avoidance protocols, such as ACAS, wouldcomplement each other. For instance, if an aircraft violates its operation volume in our protocol, then an ACAS-likeprotocol can be used to avoid collision.
Formal approaches to UTM and collision avoidance:
The formal methods research community has engagedwith the problem of air-traffic management in a number of different ways. There have been several works on formalanalysis of TCAS [12]–[15], ACAS X [16]–[18], and other protocols [19], [20] . These verification efforts rely onsimplifying assumptions such as precise state estimates, straight-line uniform trajectories of aircraft for predictingfutures states, constant velocity of the intruder aircraft, and constant horizontal velocity of the ownership aircraft.Methods for verifying and monitoring drones following specific protocols are developed in [20]–[25].Synthesis algorithms for generating safe-by-construction plans for multiple drones flying in a shared airspacehave been developed in [21], [26]–[28]. Typically, these frameworks rely on predicting or communicating futurebehavior of participating aircraft while accounting for different sources of uncertainty whether in state estimates orfrom disturbances and modeling errors. For example, [22] uses reachability analysis to check for collisions whileaccounting for sensing and synchronization errors. The paper [26] uses Signal Temporal Logic (STL) to synthesizetrajectories that are far from the communicated future trajectories of other drones. It accounts for discretization errorsof continuous trajectories while restricting them to be simple (straight lines, or with free end velocities but zeroacceleration). The paper [21] synthesizes safe drone trajectories given those of the other drones while accountingfor synchronization errors. Our contributions are complementary to the synthesis approaches that generate mutuallydisjoint plans. In [29], the authors present an approach for decentralized policy synthesis for route planning ofindividual vehicles modeled as Markov decision processes. Our approach decouples the low-level, dynamicallyfeasible planning from the distributed coordination, and solves the latter problem using a centralized coordinator(airspace manager) that performs distributed mutual exclusion over different parts of the airspace (Section IV).III. O PERATION VOLUMES
In this section, we formalize the notion of operating volumes introduced in ConOps [2]. We refer to an UASparticipating in the UTM system as an agent and the physical device of the UAS as air-vehicle . Every agent in thesystem has a unique identifier. The set of all possible identifiers is ID . We assume that each agent has access toa common global clock which takes non-negative real numbers. The relevant part of the airspace is modeled as a https://ti.arc.nasa.gov/news/acasx-verification-software/ compact subset X ⊆ R . The airspace is different from the state space of individual air-vehicles which may havemany other state components like velocity, acceleration, pitch and yaw angles, etc.Informally, an operating volume contract (OVC) is a schedule for an air-vehicle for occupying airspace. Bypublishing an OVC, an agent makes its intentions known. Definition 1. A operating volume contract (OVC) is a finite sequence of pairs C = ( R , T ) , ( R , T ) , . . . , ( R k , T k ) where each R j ⊆ X is a compact subset of the airspace, and T j ’s is a monotonically increasing sequence of timepoints. The total time duration T k − T of the OVC C is denoted by C. dur , and the length k of C is denoted by C. len .We denote the set of all possible contracts as OV .An air-vehicle meets an OVC at real-time t if (i) t ∈ [ T i , T i +1 ) for any i < k implies that the air-vehicle islocated within R i , and (ii) t > T k implies that the air-vehicle is located within R k . In other words: Definition 2.
Any OVC C represents a compact subset (cid:74) C (cid:75) of space-time: (cid:74) C (cid:75) (cid:44) k − (cid:91) i =1 { ( r, t ) | r ∈ R i ∧ T i ≤ t < T i +1 }∪ { ( r, t ) | r ∈ R k ∧ T k ≤ t } It is straightforward that (cid:74) C (cid:75) = ∅ if and only if R i = ∅ for all ≤ i ≤ k . And, given the current position pos andclock reading clk of an air-vehicle, we say that the air-vehicle meets the contract C if and only if ( pos , clk ) ∈ (cid:74) C (cid:75) . In the above definition, we purposefully identify the name of the OVC C with the space-time volume it represents.Large airspaces may have to be divided into several smaller airspaces and one has to deal with hand-off acrossairspaces. In this paper, we do not handle this problem of air-vehicles entering and leaving X . Definition 3.
Given any OVC C = ( R , T ) , . . . , ( R k , T k ) , we define prepend ( C, T pp ) where T pp < T , split ( C, T sp ) where T i < T sp < T i +1 , and append ( C, T ap ) where T k < T ap , prepend ( C, T pp ) (cid:44) ( ∅ , T pp ) , ( R , T ) , . . . , ( R k , T k ) split ( C, T sp ) (cid:44) ( R , T ) , . . . , ( R i , T i ) , ( R i , T sp ) , ( R i +1 , T i +1 ) , . . . , ( R k , T k ) append ( C, T ap ) (cid:44) ( R , T ) , . . . , ( R k , T k ) , ( R k , T ap ) Finally, we define insert ( C, T ) function over any T , insert ( C, T ) (cid:44) prepend ( C, T ) if T < T split ( C, T ) , if T i < T < T i +1 append ( C, T ) if T k < TC, otherwise . Notice that by definition the OVC produced by split , append , and insert functions represents the same set ofspace-time by C . With the help of insert , we can always align a OVC with a given sequence of time points. Wecan then implement intersection, union, and difference on OVCs on top of the same operators for airspace. Definition 4.
Given two OVCs with aligned time points, C a = ( R a , T ) , . . . , ( R ak , T k ) , C b = ( R b , T ) , . . . , ( R bk , T k ) ,and a set operation ⊕ ∈ {∩ , ∪ , \} , C a ⊕ C b (cid:44) ( R a ⊕ R b , T ) , . . . , ( R ak ⊕ R bk , T k ) . Proposition 1.
Given any OVC C , any time point T , any set operation ⊕ ∈ {∩ , ∪ , \} , we have the followingequivalences: (cid:74) insert ( C, T ) (cid:75) = (cid:74) C (cid:75)(cid:74) C a ⊕ C b (cid:75) = (cid:74) C a (cid:75) ⊕ (cid:74) C b (cid:75) . The proof is to trivially expand the definition of (cid:74) C (cid:75) and skipped here. Given Proposition 1, OVCs are closedunder all set operations; hence we drop the (cid:74) · (cid:75) notation in the later sections. Several concepts are therefore defined naturally in OVCs as set operations. For example, checking if a OVC C a refines C b is to simply check if C a usesless space-time than C b does, i.e., C a ⊆ C b , or equivalently C a \ C b = ∅ .IV. A S IMPLE C OORDINATION P ROTOCOL USING
OVC S We present a simple protocol for safe traffic management using OVCs and its correctness argument. The coreof the protocol is based on distributed mutual exclusion over parts of the airspace using contracts. The protocolinvolves a set of agents interacting with an airspace manager or controller (AM) . That is, the overall system is theparallel composition of the airspace manager (AM) and all agents (Agent i ): Sys (cid:44) AM ||{ Agent i } i ∈ ID . In Section IV-A, we first describe the protocol under the assumption that the agents and the manager interactthrough reliable request and reply messages, which are delivered instantly and modeled here by discretetransitions for simplicity. We then analyze the correctness of the protocol under instant delivery as well as boundedcommunication delay in Section IV-C.
A. Airspace Manager
We design the airspace manager as the automaton defined in Figure 2. The AM keeps track of all contracts andchecks for conflicts before approving new contracts. It uses a mapping contr_arr in which contr_arr [ i ] records the contract held by agent i , and a set reply_set to store the agents whose requests are processed andpending reply. automaton AirspaceManager variables : contr_arr : [ ID → OV ] reply_set : Set (cid:104) ID (cid:105) input request i ( contr : OV ) eff : reply_set : = reply_set ∪ { i } if contr ∩ ( j ∈ ID (cid:83) j (cid:54) = i contr_arr [ j ]) = ∅ : contr_arr [ i ] : = contr_arr [ i ] ∪ contr output reply i ( contr : OV = contr_arr [ i ]) pre : i ∈ reply_set eff : reply_set : = reply_set \ { i } input release i ( contr : OV ) eff : contr_arr [ i ] : = contr_arr [ i ] \ contr Fig. 2. Airspace Manager automaton
Whenever AM receives a request i ( contr ) from agent i (line 7), agent i is first added to reply_set . Then, contr is checked against all contracts of other agents by checking disjointness (line 10). If the check succeeds,then it is approved and included in contr_arr [ i ] via set union (line 11). Otherwise, nothing is changed.When reply_set is not empty and contains agent i , AM triggers the reply i ( contr ) action to reply to agent i with its new contract contr = contr_arr [ i ] (line 13). Note that AM replies with contr_arr [ i ] in line 13no matter whether the requested contract contr in line 7 was approved or not (i.e. irrespective of whether contr in line 7 was included in contr_arr [ i ] or not). Finally, if AM receives a release i ( contr ) , then it removes contr from contr_arr [ i ] via set difference (line 18). B. Agent Protocol
The agent’s coordination protocol sits in between a high-level planner/navigator that generates the waypointsand a low-level controller that drives the air-vehicle to the target waypoints. A simplified state diagram of the agentprotocol is shown in Figure 3. At a high level, agent i ’s protocol starts in the idle state and initiates when a plan action with a given set of waypoints is triggered by the agent’s planner. Then, the protocol computes a contractneeded for visiting the waypoints, requests this contract from the AM, and waits for the reply. If the contract isgranted by the AM’s reply , the agent protocol enters the moving state. At this point the agent’s controller starts IDLE startREQUESTINGWAITINGMOVINGRELEASING plan ( waypoints ) request i ( contr ) reply i ( contr ) next_regionsucceed failrelease i ( contr ) reply i Fig. 3. Simplified state diagram for Agent. moving the air-vehicle, ideally, satisfying the contract. Once the air-vehicle reaches the last waypoint successfully,the protocol releases the contract and goes back to idle state.In the case that the requested contract is not granted by the AM, the protocol directly releases and retries. If theagent fails to comply to the contract while moving, it then notifies AM that it violated its contract. Moreover, itplans for recovery. We will discuss this further in Section VI.The detailed automaton is shown in Figure 4. The agent protocol has a status variable to keep track ofthe discrete states in Figure 3. In addition, it uses three contract-typed variables for the following purposes:(1) curr_contr is a local copy of the current contract maintained for i by AM, (2) plan_contr is a contractthat i wants to propose to AM to be able to visit the planned waypoints, and (3) free_contr tracks the releasableportion of the current contract curr_contr . In addition, the agent i can read its current position from the variable pos and the current global time from the variable clk . To provide a simple abstraction of arbitrary controllers forthe agent, we create the variable traj_ctrl that stores a list of waypoints that the agent would follow when itis in the MOVING status. traj_ctrl has two abstract interfaces: set_waypoints to store the plan waypointsand calculate the necessary control signal (using PID, for example) and start to start moving the agent to followthe stored list of waypoints.Each agent i is initialized in IDLE status. When it receives a plan action with given waypoints (line 13), ituses waypoints2contract ( pos , waypoints ) to create a contract representing the airspace that it may visitwhen following the waypoints starting from its current position, stores it as plan_contr (line 16), stores thewaypoints in traj_ctrl (line 17), and enters the REQUESTING status (line 18). A number of strategies maybe followed to create contracts from waypoints lists, for example using reachability analysis for a given waypoint-tracking controller for the aircraft, or creating fixed-sized 3D rectangles centered at the segments connecting thewaypoints. We will discuss this further in Section V. Agent i then makes a request request i ( contr ) with contr = plan_contr to denote the planned contract is sent as output, and enters WAITING status to wait for areply from the AM (line 20).When agent i receives a reply i ( contr ) from AM, the contract contr represents the contract of agent i recorded by AM (line 24). It is the union of all contracts agent i have acquired and not yet released. Agent i firstchecks whether the contract curr_contr is a subset of contr or not. If not, it means the local copy is lessrestrictive, so AM may grant contracts to other agents conflicting with agent i . This may lead to a safety violation,and hence agent i raises a warning (line 24). Otherwise, the agent checks if the contract contr approved by theAM contains plan_contr , i.e. plan_contr ⊆ contr (line 31). If yes, then it updates its curr_contr tobe equal to the new approved contr . The agent then calls traj_ctrl . start to start following the waypoints,and transitions to the MOVING status. If no, i.e. there is a part of plan_contr that is not approved contr andnot approved by the AM, then agent i does not change curr_contr . It only checks the part of the contract savedby the AM that is no longer a part of curr_contr of the agent. It then stores this portion of the contract in free_contr (line 36), and directly goes to the RELEASING status to release and re-plan (line 37).When the agent is in the
MOVING status, the next_region action will be triggered whenever the global timepasses the time bound of a region in the contract (line 39). That action will remove that pair of region and timepoint from plan_contr (line 42). Once there is only a single pair left in the planned contract plan_contr andthe contract is not violated, the succeed action is triggered to indicate the plan is executed successfully (line 44). automaton Agent i variables : // Discrete variables status : { IDLE , REQUESTING , WAITING , MOVING , RELEASING } : = IDLE curr_contr : OV plan_contr : OV free_contr : OV // Continuous variables clk : T ≥ pos : R // Position sensor traj_ctrl // Trajectory control internal plan ( waypoints : List (cid:104) R (cid:105) ) pre : status = IDLE ∧ len ( waypoints ) ≥ eff : plan_contr : = waypoints2contract ( pos , waypoints , clk ) traj_ctrl . set_waypoints ( waypoints ) status : = REQUESTING output request i ( contr : OV = plan_contr ) pre : status = REQUESTING eff : status : = WAITING input reply i ( contr : OV ) eff : if status = WAITING : if curr_contr (cid:54)⊆ contr : warning ( ‘‘Acquired contract cannot sustain current contract’’ ) curr_contr : = contr if plan_contr ⊆ contr : curr_contr : = contr traj_ctrl . start () status : = MOVING else : free_contr : = contr \ curr_contr status : = RELEASING internal next_region () : pre : status = MOVING ∧ len ( plan_contr ) ≥ ∧ clk ≥ plan_contr . T eff : plan_contr . pop_front () internal succeed () : pre : status = MOVING ∧ len ( plan_contr ) = ∧ ( pos , clk ) ∈ plan_contr eff : free_contr : = curr_contr \ plan_contr status : = RELEASING internal fail () : pre : status = MOVING ∧ ( pos , clk ) / ∈ curr_contr eff : error ( ‘‘Current contract is violated’’ ) output release i ( contr : OV = free_contr ) pre : status = RELEASING eff : curr_contr : = curr_contr \ free_contr status : = IDLE
Fig. 4. Agent automaton
Agent i then calculates the releasable contract free_contr to be its contract curr_contr excluding the lastpair of plan_contr (line 48). Finally, it enters RELEASING status. It sends release i ( contr ) to notify AMthe contract that agent i can release, and goes back to IDLE status (line 60).If at any point in time the current contract is violated, the fail action would be triggered (line 51). Rememberthat the contract is violated if the current pair of position and time of the agent is outside of the space-time specifiedby the contract. This can happen in case the agent moves outside a region in a time interval of the contract, or theagent could not reach a region before its specified time point in the contract. It then declares a violation to AMthen re-plans for recovery. We will discuss this further in Section VI.
C. Protocol correctness: safety and liveness
We now discuss the safety property ensured by the protocol shown in the previous section. Here, we denote curr_contr of the i th agent by agent i . curr contr . Assuming that none of the agents triggered their fail action, then they always follows their local contracts curr_contr ’s. In that case, collision avoidance is definednaturally as the disjointness between the curr_contr ’s of all agents. Our goal therefore is to show that thefollowing proposition is an invariant of the system: Proposition 2.
If none of the agents triggered their fail action, the current contracts followed by all agents arepairwise disjoint, i.e., (cid:94) i ∈ ID (cid:94) j (cid:54) = i,j ∈ ID agent i . curr contr ∩ agent j . curr contr = ∅ . Our proof strategy is to show that first the global record of contracts maintained by AM are pairwise disjoint.Then, we ensure the local copy by each agent is as restrictive as the global record and hence preserves disjointness.We start from an auxiliary invariant about AM.
Proposition 3.
If none of the agents triggered their fail action, all contracts recorded by AM are pairwise disjoint,i.e., (cid:94) i ∈ ID (cid:94) j (cid:54) = i,j ∈ ID AM. contr arr [ i ] ∩ AM. contr arr [ j ] = ∅ . This is a direct result from examining all actions of AM automaton. The request i action ensures that a contr is only included into contr_arr [ i ] if it is disjoint with all other contr_arr [ j ] . The reply i action does notmodify contr_arr at all, and release i action only shrinks the contracts.Now we argue that the local copy is always as restrictive as the global record. Proposition 4.
If none of the agents triggered their fail action, the local curr_contr of agent i is always asrestrictive as contr_arr [ i ] , i.e., (cid:94) i ∈ ID agent i . curr contr ⊆ AM. contr arr [ i ] . This is also straightforward by examining all actions of agent automaton regardless of the order of execution.The curr_contr is only modified in reply and release actions. In reply action, curr_contr is assignedwith contr sent by AM and thus preserves Proposition 4. In release action, curr_contr removes contr first, and AM has to wait until release is delivered to remove contr . As a result, it also preserves Proposition 4.With Proposition 3 and Proposition 4 being true, it is straightforward that Proposition 2 is implied using basic settheory.To further extend the proof with communication delay in consideration, we first observe that Proposition 3 isa local invariant for AM; thus communication delay does not invalidate the proof. We therefore simply revisitthe proof for Proposition 4. Because the current contract of each agent is only updated after receiving reply i from AM and shrunk when sending release i , the potential counterexample shown in Figure 5 can only happenif reply i is delivered to agent i to update its local copy while release i is delivered to AM to shrink theglobal copy concurrently, i.e., T rel < T rep and T rep < T rel . It is easy to see discrete transitions will preventthis counterexample as an action must be finished before another action. Our proof is to show the impossibility ofthis counterexample under the reliable communication with bounded delay. Recall Figure 3, our protocol ensures request i , reply i , and release i happen in such order by design. We can prove this order of actions byinduction on the formally defined automaton but skip the proof here for simplicity. Therefore, we know that thermust be a request i sent after release i , and reply i is the response to this request. Now we provide a simplifiedreliable communication assumption for this proof. Assumption 1.
The reliable communication guarantees the messages sent by the same agent is delivered in order.In particular, if agent i sends a release i first and request i second, we denote T rel as the time release i issent and T rel as the time received, similarly T req and T req for request i . Formally, T rel ≤ T req ⇒ T rel ≤ T req Also by definition, T ∗ ≤ T ∗ because sending must happen before receiving. The order between actions canbe formally specified as T rel ≤ T req ≤ T req ≤ T rep because the request must have been delivered to AMfor it to trigger the reply i . We can then derive T rel ≤ T req ≤ T req ≤ T rep < T rel . This contradicts to our assumption of reliable communication because messages from agent i are delivered out of order. To be more precise, release i is sent before ( T rel ≤ T req ) but delivered later ( T req < T rel ) than request i . This contradicts to T rel ≤ T req ⇒ T rel ≤ T req . Hence, we prove by contradiction. agent i curr_contr = C AM contr_arr [ i ]= C T rel T rep T rep T rel release i ( C ) r e p l y i ( C ) curr_contr = C \ C curr_contr = C contr_arr [ i ]= C \ C Fig. 5. Sequence diagram for an impossible unsafe OVC release. By definition, T rel ≤ T rel and T req ≤ T req For liveness property, we would like to see every agent follows its waypoints and eventually reaches the lastwaypoint. In our protocol, this is formulated as every agent eventually reaches the last region of its plan_contr and triggers its succeed action. It is worth noting that the liveness property depends on the given waypoints foreach agent and the strategy to convert waypoints to contracts. Some simple scenarios where liveness cannot beachieved are when two agents are given some waypoints that are very close. The last region where one agent staysat the end could block the other agent forever. Therefore, we discuss liveness property under following assumptions.
Assumption 2 (single goal (list of waypoints) per agent) . For each agent i ∈ ID , there is a single list of waypoints wps i left to follow before it stops and land. Hence, once a contract for wps i sent by agent i is accepted by AM,whether it failed or succeeded in following, it does not send another one again. Assumption 3 (disjointness of other agents’ OVCs from an agent’s initial OVC and final destination) . ∀ clk , clk ∈ R ≥ , ∀ pos i ∈ curr contr i . dest .P, pos j ∈ curr contr j . dest .P , (cid:94) i (cid:94) j (cid:54) = i waypoints2contract ( pos i , wps i , clk ) .P ∩ (cid:0) waypoints2contract ( pos j , wps j , clk ) . dest .P ∪ curr contr j . dest .P (cid:1) = ∅ . Now, let us define τ i = max pos i ∈ curr contr i . dest .R, clk i ∈ R ≥ waypoints2contract ( pos i , wps i , clk i ) . dur . (1)A τ i is the maximum duration of a planned contract that would be generated starting from any position in the lastregion of the initial contract curr contr i . dest . P at any time by the i th agent. Proposition 5 (liveness) . If none of the agents triggered their fail action and Assumptions 2 and 3 are satisfied,then the maximum time before all agents get their planned contracts for the lists of waypoints { wps i } i ∈ ID acceptedby AM is (cid:80) i ∈ ID curr contr i . dur + τ i .Proof. Initially, the array contr arr of the air manager AM stores the initial contracts { curr contr i } i ∈ ID of allagents. Now, assume that as time passed, ≤ k < | ID | agents got their planned contracts of the lists of waypoints { wps } accepted by AM, and thus saved in its contr arr . We call this set of agents AccAgents . Let j ∈ ID be anagent that either did not send a new planned contract to AM yet, or have sent one or more but none got accepted.Agent j might 1) violate its current contract curr contr , 2) continue following curr contr till its last region,trigger the succeed action, and transition to RELEASING status, or 3) be in the
IDLE status where it sends anothercontract to AM. If agent j violated its contract, it would trigger its fail action, which violates the hypothesis of theproposition. If agent j stayed MOVING till the action succeed is triggered, it will transition first to the
RELEASING ,then to the
IDLE status. Reaching the
IDLE status or triggering the fail action would take at most curr contr j . dur time. If agent j is IDLE , it will send the planned contract waypoints2contract ( pos j , wps j , clk j ) to AM, whereits position pos j ∈ curr contr j . dest .P . AM in turn would reject the sent contract if it intersects one of thecontracts in contr arr , or accept it, otherwise. If AM rejects it, then it would accept a future version of it. That is because in the future, the only physical space reserved for AccAgents would be the last regions of their plannedcontracts. Based on Assumption 3, the planned contract of agent j is disjoint from these regions. No agent in AccAgents that succeeds would send a contract again to AM because of Assumption 2. Those that violate theircontracts instead, would trigger the fail action and thus are not considered in this proposition. If there is noagent that is not in
AccAgents that sent its contract to AM and got accepted before that of agent j did, none ofthe contracts in contr arr would intersect its sent contract because of Assumption 3. Moreover, it would takea maximum of τ AccAgents = max h ∈ AccAgents contr arr [ h ] . dur for the all AccAgents to succeed or fail. Thus,it would take a maximum of curr contr j . dur + τ AccAgents time for an extra agent to get its contract accepted.Therefore, the theorem. V. E
XPERIMENTAL E VALUATION
Our experiment is conducted in the Gazebo and ROS-based simulation framework from [28] We choose theHector Quadrotor model [30] integrated in the framework with its default controller to support trajectory control.In this section, we first describe the scenarios used in our experiment and present the result followed by a briefdiscussion.
A. Evaluation scenarios
Following the protocol defined in Section IV, a scenario for evaluation is specified by (1) the set of agents ID whichwe only consider A = | ID | (2) the world map and the predefined sequence of waypoints for each agentdenoted as the map , and (3) the strategy waypoints2contract the agents use to to generate OVCs from theirwaypoints. For example, the Left figure in Figure 9 shows a scenario with A = 6 drones in the C ORRIDOR map.It uses A
GGRESSIVE strategy to generate OVCs visualized as the red and blue frames.We evaluate our protocol in the following maps shown in Figure 9:(1) C
ORRIDOR simulates two sets of drones on the opposite sides of a tight air corridor trying to pass through.This may happen in a garage like space where a fleet of air-vehicle enter or leave.(2) L
OOP simulates each drone following the vertices of the same closed polygonal chain. This models commonsegments in the routes for all air-vehicles such as pickup packages or return to base.(3) R
ANDOM N are sequences of N − random points inside a m × m arena for each drone to follow. Thisis to validate the robustness of our protocol through random testing.(4) C ITY S IM is the map in Figure 1 that simulates a city block.In addition, a designated landing spot for each drone is specified as the last waypoint in all maps to ensure theliveness property. This avoids the situation where a landed drone blocks other air-vehicles. Fig. 6. Regions for waypoints generated by A
GGRESSIVE ( Solid rectangles ) and C
ONSERVATIVE ( Dashed rectangles ) strategies. C ONSERVATIVE and A GGRESSIVE operation volumes:
We implement two strategies, namely C
ONSERVATIVE and A
GGRESSIVE , for generating OVCs from given waypoints and positions. Both strategies are deterministic anduse only hyper-rectangles for specifying regions in OVCs. We skip the implementation details and only give thehigh-level ideas here. Figure 6 depicts the intuition behind the two strategies. C
ONSERVATIVE simply reserves largerectangles covering consecutive waypoints with longer durations between time points. As a result, it is less likelyto violate a given OVC, but it may acquire unnecessarily large volumes and may obstruct other agents. In contrast,A
GGRESSIVE heuristically selects smaller rectangles and shorter durations based on the physical dynamics of theair-vehicle. Therefore, A
GGRESSIVE is less likely to block other agents, but the resulting OVC is more likely to be A T i m e [ s ec ] C ORRIDOR L OOP R ANDOM ANDOM Fig. 7. Response time per agent for each map using C
ONSERVATIVE strategy: Max. (
Solid marks and lines ) and Avg. (
Hollow marks anddotted lines ) A Q e /s A Rect /s Fig. 8. Number of emptiness queries (
Left ) by AM and rectangles checked (
Right ) per second using C
ONSERVATIVE strategy. violated. A
GGRESSIVE also increases the workload of AM because the operating volume to be checked (numberof rectangles) can be more complex.
B. Experimental resultsSetup:
The simulation experiments discussed here were conducted on a machine with 4 CPUs at 3.40GHz,8GB main memory, and a NVidia GeForce GTX 1060 3GB video card. The software platform is Ubuntu 16.04LTS with ROS Kinetic and Gazebo 9. For the reported time usage, we report the simulation time from Gazebo(time elapsed in the simulated model), instead of wall clock time. This helps reduce the variations in the resultsdue to different computing hardware and effects of concurrency in simulating multiple agents. To address thenondeterminism arising from concurrency, we simulate each scenario three times, and report the average value ofeach metric.
Response time and workload:
Figure 7 shows the response time for each drone starting from sending the firstrequest to finish traversing all waypoints using C
ONSERVATIVE strategy in C
ORRIDOR , L
OOP , and R
ANDOM N maps. As expected, the maximum response time per agent grows linearly with respect to the number of participating Fig. 9. Maps: C
ORRIDOR ( Left ), L
OOP ( Mid ), R
ANDOM N ( Right )TABLE IC
OMPARISON OF SIMULATION TIME AND VIOLATION RATE BETWEEN C ONSERVATIVE AND A GGRESSIVE .C ONSERVATIVE A GGRESSIVE
IncreasedMap A Time(s)
Rect /s %F Time(s)
Rect /s %F Speedup
Rect /s2 27.52 0.00 0% 21.30 0.00 0% 1.29X N/A4 39.78 2.99 0% 27.24 6.16 3.57% 1.46X 2.71XC
ORRIDOR
OOP
ITY S IM A is the number of agents, Time(s) is the total time for simulation according to the simulated clock in seconds, Rect /s is the number ofrectangles per second in OVCs which AM has to check the disjointness of, and %F is the violation rate. agents. This is because in the worst case, all agents are sequentially accessing the shared narrow air-corridor, andthe last agent has to wait until all other agents finish traversing. The average response time shows that it is possibleto finish faster if agents can execute concurrently when they request disjoint airspaces. For example, the averagetime for 10 agents is smaller the time for 8 agents in R ANDOM Q e ) and the total numberof hyper-rectangles to check (denoted as Rect ) per second. Because the check of disjointness between two 3Dhyper-rectangles is a constant number of comparisons.
Rect provides a more precise estimation of computationresources needed at the AM than Q e . The growth of Q e as expected is roughly quadratic against A in the worstscenario because of the check for pairwise disjointness. However, the growth of Rect is not as fast and seeminglylinear to A in the worst scenario. Therefore, it is very likely the workload of AM increases only linearly instead ofquadratically with more agents when we use simple representation of operating volumes such as hyper-rectangles.C ONSERVATIVE vs. A GGRESSIVE : We compare the time as well as the rate of violations between C
ONSER - VATIVE and A
GGRESSIVE strategies in the C
ORRIDOR , L
OOP , and C
ITY S IM from Figure 1 in Section I. Dueto the heavier demand for computational resources required, we only simulated with two drones for C ITY S IM .The violation rate ( %F ) is defined as the percent of rectangles in OVC the agent failed to stay within, duringwaypoint traversal. This is calculated by first counting the rectangles when a fail action happens and dividingit with the total number of rectangles in OVC. Table I shows that A GGRESSIVE strategy can reduce the overallresponse time and provide 1.3-2.8X speedup. Specifically, A
GGRESSIVE strategy can lead to higher speedups withlarger number of particiating agents. However, A
GGRESSIVE can also cause almost 10% of violations in the L
OOP scenario. In terms of workload, it doubles the number of rectangles for AM to process. This experiment shows thatour framework is suitable for comparing and quantifying the trade-off between performance, safety, and workloadunder different OVCs generation strategies. TABLE IIC
OMPARISON OF SIMULATION TIME AND AGENTS NOTIFICATION RATE BETWEEN DIFFERENT FAULT PROBABILITIES AND DIFFERENTNUMBERS OF AGENTS .Failure Prob. A Resp. T.(s)
Rect /s %F A is the number of agents, Resp. T.(s) is the averageresponse time per agent, Rect /s is the number of rectangles per second in OVCs which AM has to check the disjointness of, %F is theviolation rate, and VI. F
AILURES AND M ONITORING
Failures in UTM:
In UTM, aircraft operators are responsible on ensuring that they abide their volume contracts,or according to our notation, their OVCs. When a failure causes the aircraft to violate its contract, it should notifythe USS, which in turn have to notify affected users. The USSs can help the operator to track the aircraft and plana safe alternative volume contract to follow without affecting other aircraft [2].
Failures in protocol : In our protocol, we handle violations of contracts similar to UTM. These violations canbe caused by aggressive maneuvers an agent chooses to do as described in the previous section, or because of anykind of failures, such as software or hardware ones, that can occur to the agent. The agents themselves report theirviolations of contracts to the airspace manager AM. In their reports, they send alternative, or recovery , contractsthat they are expected to follow after the violations. When AM receives a violation report with the recovery contract rec contr i from agent i , AM replaces its saved contract contr arr [ i ] with rec contr i . Moreover, AM notifiesthe agents with contracts in contr arr that intersect with rec contr i to alert them of the potential collisiondanger. Experimental results and analysis:
We implemented the violation detection and mitigation mechanism ex-plained above in our framework. We tested our monitoring implementation in C
ORRIDOR scenarios with four andsix drones. We used the C
ONSERVATIVE strategy to create operation volume. From Table I, we can see that thereare zero violations of the contract. This ensures that the violations are not because of maneuvers chosen by theagents, but because of failures simulation as we will discuss next. This allows for a better comparison of the resultsunder differ failure probabilities in Table II.In order to generate violations that mimic faults in the aircraft, we generate fake waypoints outside the contracts.Whenever an agent reaches a waypoint in its path, we flip a biased coin with a head probability of 0.4 or 0.9. Thishead probability represents the failure probability. If the toss is a tail , we provide it with the exact next waypoint next wp in the path to follow. If it is a head we create a noisy version of next wp by adding independent Gaussiannoise with mean zero and standard deviation five to each of the three dimensions of next wp . An agent i ∈ ID checks if its position and time is in its volume contract regularly. Whenever it recognizes it violated it, it generates itsrecovery contract rec contr i using waypoints2contract with arguments being its current position, currenttime, and the list of waypoints in the path that have not been visited yet. It sets plan contr i and curr contr i to rec contr i and sends the latter to AM to update contr arr [ i ] accordingly.The results of our monitoring experiments are shown in Table II. In addition to the average response time peragent (Resp. T. (s)), the number of rectangles per second in OVCs which AM has to check the disjointness of( Rect /s), and the violation rate ( %F ), we report the number of alert notifications sent to agents per violation( %F increases as the probability of failure increase. Moreover, thenumber ORRIDOR scenario, where there are at most two close air-vehicles at any time independent of the total numberof air-vehicles. Closeness of air-vehicles in turn depends on the severity of the considered failures and the extentof contract violations before recovery. Such extent is determined in our experiments by the mean and the varianceof the added Gaussian noise to the waypoints. Table II uses the same Gaussian distribution to generate noise. Weleave such comparison for future investigation. With more number of violations, more checks have to be done by AM to know which agents should be sent alerts. This is can be seen in Table II by comparing the average responsetime Resp. T.(s) of the scenarios with failure probability 0.4 and those with 0.9. The latter are significantly largerthan the former. Lastly, as the number of air-vehicles increase,
Rect /s increases because of the increasing numberof needed checks done by the airspace manager.Finally, our framework allows also for violations monitoring by the airspace manager. This monitoring can be asimilar, but centralized approach, of what the agents do of checking inclusion of their position-time pairs in theircontracts. Or, it can be based on forecast to the future using simulation forward or reachability analysis to predictviolations of contracts. VII. D
ISCUSSIONS AND CONCLUSIONS
UTM technologies conceptualized by NASA and FAA can transform and benefit a number of aspects of society.Some of the proposed concepts and operations were successfully field tested in the Summer of 2019, and nowthere is a strong need for formal safety analyses and larger scale empirical evaluations. In this paper, we present anexecutable formal model of UTM operations and study its safety, scalability, and performance. Our formal analysesillustrate how formal reasoning can be applied to the family of UTM de-conflicting protocols. We also presentedan open and flexible reference implementation of this protocol in a simulator. Our experiments suggest, perhapsunsurprisingly, that the computation load on the airspace manager scales linearly with the number of participatingagents. The simulator also makes it possible to study different strategies for blocking operating airspace volumes.For example, compared to a conservative strategy our aggressive strategy provides 1.5-3X speedup, but it also leadsto 2-5X higher workload on the airspace manager, and up to 10% more violations.We showed how violations can be handled through reporting to the airspace manager, alerting possibly affectedagents, and re-planning with new contracts. We demonstrated a simple technique to induce failures following givenprobabilities by adding waypoints. We presented experimental results that show how the workload on the airspacemanager increase with increasing probability of failure due to additional communication. Our preliminary resultfurther showed that the safety or performance is more correlated with the planned paths of each air-vehicle thanthe total number of air-vehicle in the airspace, and we suspect that the intersections between paths is a moredominant factor than the density of air-vehicles in the air-space, and further experiment with finer data and metricsfor measuring paths are in our future plan.Some of the simplifying assumptions made in this work can be removed with careful engineering, while othersrequire brand new ideas. Handling timing and positioning inaccuracies, heterogeneous vehicles, fall in the firstcategory. While development of predictive failure detection and failure mitigation strategies, incorporation of humanoperators, and fall in the latter category. R , 2016, pp. 1–10.[7] G. Manfredi and Y. Jestin, “An introduction to acas xu and the challenges ahead,” in , 2016, pp. 1–9.[8] J. K. Kuchar and L. C. Yang, “A review of conflict detection and resolution modeling methods,”
IEEE Transactions on IntelligentTransportation Systems , vol. 1, no. 4, pp. 179–189, 2000.[9] M. J. Kochenderfer, C. Amato, G. Chowdhary, J. P. How, H. J. D. Reynolds, J. R. Thornton, P. A. Torres-Carrasquillo, N. K. Ure, andJ. Vian,
Optimized Airborne Collision Avoidance , 2015, pp. 249–276.[10] M. Skowron, W. Chmielowiec, K. Glowacka, M. Krupa, and A. Srebro, “Sense and avoid for small unmanned aircraft systems: Researchon methods and best practices,”
Proceedings of the Institution of Mechanical Engineers, Part G: Journal of Aerospace Engineering , vol.233, no. 16, pp. 6044–6062, 2019. [Online]. Available: https://doi.org/10.1177/0954410019867802[11] X. Yu and Y. Zhang, “Sense and avoid technologies with applications to unmanned aircraft systems: Review and prospects,”
Progress inAerospace Sciences
Proceedings of the 36th IEEE Conferenceon Decision and Control , vol. 2, 1997, pp. 1829–1834 vol.2.[13] C. Livadas, J. Lygeros, and N. A. Lynch, “High-level modeling and analysis of TCAS,” in
Proceedings of the 20th IEEE Real-Time SystemsSymposium (RTSS’99),Phoenix, Arizona , December 1999, pp. 115–125. [14] N. Lynch, “High-level modeling and analysis of an air-traffic management system,” in Hybrid Systems: Computation and Control , F. W.Vaandrager and J. H. van Schuppen, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 1999, pp. 3–3.[15] C. Livadas, J. Lygeros, and N. Lynch, “High-level modeling and analysis of the traffic alert and collision avoidance system (tcas),”
Proceedings of the IEEE , vol. 88, pp. 926–948, 2000.[16] J.-B. Jeannin, K. Ghorbal, Y. Kouskoulas, R. Gardner, A. Schmidt, E. Zawadzki, and A. Platzer, “A formally verified hybrid system forthe next-generation airborne collision avoidance system,” in
Tools and Algorithms for the Construction and Analysis of Systems , C. Baierand C. Tinelli, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2015, pp. 21–36.[17] J. Jeannin, K. Ghorbal, Y. Kouskoulas, R. Gardner, A. Schmidt, E. Zawadzki, and A. Platzer, “Formal verification of acas x, an industrialairborne collision avoidance system,” in , 2015, pp. 127–136.[18] G. Katz, C. Barrett, D. L. Dill, K. Julian, and M. J. Kochenderfer, “Reluplex: An efficient smt solver for verifying deep neural networks,”in
Computer Aided Verification , R. Majumdar and V. Kunˇcak, Eds. Cham: Springer International Publishing, 2017, pp. 97–117.[19] T. Johnson and S. Mitra, “A small model theorem for rectangular hybrid automata networks,” 2012.[20] P. S. Duggirala, L. Wang, S. Mitra, C. Munoz, and M. Viswanathan, “Temporal precedence checking for switched models and itsapplication to a parallel landing protocol,” in
International Conference on Formal Methods (FM 2014), Singapore , 2014. [Online].Available: http://link.springer.com/chapter/10.1007%2F978-3-319-06410-9 16[21] A. Desai, I. Saha, J. Yang, S. Qadeer, and S. A. Seshia, “Drona: A framework for safe distributed mobile robotics,” in
Proceedings of the8th International Conference on Cyber-Physical Systems , ser. ICCPS ’17. New York, NY, USA: Association for Computing Machinery,2017, p. 239–248. [Online]. Available: https://doi.org/10.1145/3055004.3055022[22] H.-D. Tran, L. V. Nguyen, P. Musau, W. Xiang, and T. T. Johnson, “Decentralized real-time safety verification for distributed cyber-physicalsystems,” in
Formal Techniques for Distributed Objects, Components, and Systems , J. A. P´erez and N. Yoshida, Eds. Cham: SpringerInternational Publishing, 2019, pp. 261–277.[23] M. Webster, M. Fisher, N. Cameron, and M. Jump, “Formal methods for the certification of autonomous unmanned aircraft systems,” in
Computer Safety, Reliability, and Security , F. Flammini, S. Bologna, and V. Vittorini, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg,2011, pp. 228–242.[24] O. McAree, J. M. Aitken, and S. M. Veres, “A model based design framework for safety verification of a semi-autonomous inspectiondrone,” in , 2016, pp. 1–6.[25] S. Umeno and N. A. Lynch, “Safety verification of an aircraft landing protocol: A refinement approach.” in
HSCC 2007 , 2007, pp. 557–572.[26] Y. V. Pant, H. Abbas, R. A. Quaye, and R. Mangharam, “Fly-by-logic: Control of multi-drone fleets with temporal logic objectives,” in
ACM/IEEE International Conference on Cyber-Physical Systems (ICCPS) , 2018.[27] T. Schouwenaars, “Safe trajectory planning of autonomous vehicles,” Ph.D. dissertation, Massachusetts Institute of Technology, 2006.[28] R. Ghosh, J. P. Jansch-Porto, C. Hsieh, A. Gosse, M. Jiang, H. Taylor, P. Du, S. Mitra, and G. Dullerud, “Cyphyhouse: A programming,simulation, and deployment toolchain for heterogeneous distributed coordination,” 10 2019.[29] S. Bharadwaj, S. Carr, N. Neogi, H. Poonawala, A. B. Chueca, and U. Topcu, “Traffic management for urban air mobility,” in
NASAFormal Methods Symposium . Springer, 2019, pp. 71–87.[30] J. Meyer, A. Sendobry, S. Kohlbrecher, U. Klingauf, and O. von Stryk, “Comprehensive simulation of quadrotor uavs using ros andgazebo,” in