Decentralized Collaborative Task Allocation for Unmanned Aerial Vehicles

Decentralized Collaborative Task Allocation for Unmanned Aerial Vehicles Dan Coatta, Mark F. Godwin and David L. Nguyen ME290M Final Project December 16, 2005 i

Contents 1 Introduction 1 1.1 Assumptions............................ 1 1.2 Capabilities............................ 1 1.3 Constraints............................ 1 2 Description of Data Structures 2 2.1 UAV Agents............................ 2 2.2 Tasks................................ 3 2.3 Subtasks.............................. 3 3 Algorithms 5 3.1 Choose Function......................... 5 3.1.1 Utility Function...................... 6 3.2 Completion Function....................... 7 3.3 Target Subtask Activation.................... 7 3.3.1 Identification and Activation............... 7 3.3.2 Target Information Update................ 8 3.4 Synchronization and Conflict Resolution............ 8 3.4.1 Waypoint Controller................... 10 4 Implementation 10 4.1 UAV Model and Kinematic Update............... 10 4.2 Omniscient Functions....................... 11 4.3 Implementing Collaboration Collaboratively.......... 11 5 Results and Analysis 12 6 Conclusion 15 7 References 16 8 Log 17 8.1 Dan Coatta............................ 17 8.1.1 Week 1: 10/30-11/5................... 17 8.1.2 Week 2: 11/6-11/12................... 17 8.1.3 Week 3: 11/13-11/19.................. 17 8.1.4 Week 4: 11/20-11/26.................. 17 8.1.5 Week 5: 11/27-12/3................... 17 8.1.6 Week 6: 12/4-12/10................... 18 8.1.7 Week 7: 12/11-12/17.................. 18 8.2 Mark F. Godwin......................... 18 8.2.1 Week 1: 10/30-11/5................... 18 8.2.2 Week 2: 11/6-11/12................... 18 8.2.3 Week 3: 11/13-11/19.................. 18 ii

8.2.4 Week 4: 11/20-11/26.................. 18 8.2.5 Week 5: 11/27-12/3................... 18 8.2.6 Week 6: 12/4-12/10................... 18 8.2.7 Week 7: 12/11-12/17.................. 19 8.3 David L. Nguyen......................... 19 8.3.1 Week 1: 10/30-11/5................... 19 8.3.2 Week 2: 11/6-11/12................... 19 8.3.3 Week 3: 11/13-11/19.................. 19 8.3.4 Week 4: 11/20-11/26.................. 19 8.3.5 Week 5: 11/27-12/3................... 19 8.3.6 Week 6: 12/4-12/10................... 19 8.3.7 Week 7: 12/11-12/17.................. 19 iii

1 Introduction The goal of this project was to develop a system that allows a team of unmanned aerial vehicles (UAVs) to execute a user-defined mission in a collaborative manner. It was important that the system incorporate distributed task allocation in the context of limited communication between UAVs. The user defines the objectives of the UAV group in terms of a mission plan. The plan format was designed to capture the desired capabilities and constraints of the collaborative system. Specifically, the mission plan contains a set of tasks, and each task contains a number of subtasks. A subtask is a basic-level action that can be accomplished independently by a single agent. Each agent in the UAV group retains its own beliefs regarding the state of the mission. In particular, an agent has a set of beliefs about the status of each subtask in the mission. These beliefs are known as the mission state of that agent. Whenever possible, agents share their mission states, using an update protocol to propagate the best possible information throughout the group. [1,2,3,4,5] 1.1 Assumptions UAVs are homogeneous UAVs are represented using two-dimensional kinematic models with bounded turn rates and constant airspeeds UAVs have limited communication horizons All UAVs fly at different altitudes, so no collision avoidance algorithm is necessary All UAVs are programmed with identical recipes for accomplishing tasks, and UAVs will not perform tasks that are not in their recipe database UAVs may plan only one step ahead 1.2 Capabilities Surveillance: Travel to a target and stay there until the completion criteria are accomplished, for example until a specified time has past Target Tracking: Follow a moving target until completion criteria are accomplished, for example until a target exits a specified region 1.3 Constraints The number of UAVs that may perform a task is restricted to a maximum number 1

The user indicates the relative importance of each task by prioritizing them 2 Description of Data Structures In this section, we describe the subtask, task and agent structures used in our implementation, starting with from the high-level to low-level. 2.1 UAV Agents A UAV agent is a motion-constrained vehicle that flies with a constant velocity toward a desired coordinate called a waypoint. The agent contains a database of beliefs about the mission that allow it to make discrete logical decisions. Table 1 describes each field of a UAV agent structure. field id statevector gains waypoint controlinput tasks description this UAV s identification number current xy-coordinate, heading angle, airspeed k p gain used in waypoint controller current waypoint of this UAV current turning rate command a list of tasks to be completed Table 1: Description of UAV agent fields The value of the waypoint field depends on what the UAV has chosen to do. Based on the waypoint, the controlinput field is updated to reflect the turn rate command that will steer the UAV toward the waypoint. In this system, the targets used in tracking tasks share the same structure as UAVs except that they do not contain tasks or beliefs. Targets operate solely upon a blind control input command. Example: class: uav id: 4 statevector: [0 0 3.14 20] gains: 0.1 waypoint: [1000 2000] controlinput: 0.0 tasks: [1x5 struct] 2

The above data structure describes a UAV with identification number 4, located at the origin and moving West at 20 meters per second. The gains field contains a gain used in a UAV s waypoint contoller. All of a UAV s beliefs are stored within the tasks field. 2.2 Tasks A task is defined as a grouping of subtasks that are related by two fields within the task structure: type and maxagents. Table 2 describes each field of a task structure. field id subtasks type maxagents description this task s identification number a list of subtasks 1=SURVEILLANCE, 2=TRACK, or 3=LOITER maximum number of agents allowed to execute this task Table 2: Description of task fields When a task already has maxagent number of UAVs executing it, a UAV that has this information and is not executing the task will not choose to execute a subtask that is a part of this task. The SURVEILLANCE type describes an act of going to a waypoint and circling that waypoint for some amount of time. The TRACK type describes an act of following a target (moving waypoint) for some period of time or until the target is outside some predefined area. The LOITER type describes an act of circling the coordinates of the ground station if all subtasks have been completed. Example: class: task id: 2 subtasks: [1x7 struct] type: 1 maxagents: 3 The above data structure describes a task with identification number 2 that contains seven surveillance-type subtasks and may be executed by a maximum of 3 UAVs at the same time. 2.3 Subtasks A subtask is the lowest-level structure in the system. A subtask structure contains the coordinates of waypoints, as well as how long to remain at each 3

point. This structure also contains the UAV s beliefs about the subtask. Table 3 describes each field of a subtask structure. field id uavid status util timestamp inittime pri param paratimestamp description this task s identification number the id number of the UAV that is executing this subtask 0=DORMANT, 1=TODO, 2=ASSIGNED, or 3=DONE utility of this subtask with respect to the UAV executing it time of last update of util time the subtask was last set to TODO priority of subtask xy-coordinates of waypoint, timeout, timer time the xy-coordinates were last updated Table 3: Description of subtask fields The DORMANT status is initially assigned to all TRACK-type tasks. This is because the UAV does not know the location of the target until it is detected by coming within the UAV s sensor radius. Transitions between the possible values of status are defined in Section 3. The timeout and timer in the param field exist for subtasks of SURVEILLANCE-type tasks. The timeout specifies how long the UAV should survey the waypoint, and the timer stores how long the UAV has already been surveying the waypoint. The paramtimestamp is another field exclusive to TRACK-type tasks. When a UAV detects a target, it updates the x-y coordinates in the param field as well as the time it saw the target in paramtimestamp. Example: class: subtask id: 5 uavid: 4 status: 2 util: 0.68 timestamp: 0 inittime: 0 pri: 1 param: [3000 4000 120 15] paramtimestamp: 0 The above data structure describes a priority 1 SURVEILLANCE subtask at (3000, 4000) that needs to be circled for 120 seconds. It also describes the beliefs of the UAV whose database is storing this instance of this subtask; these beliefs are that the subtask with id 5 is currently ASSIGNED to UAV4, that 4

the utility of the subtask is 0.68 for UAV4, and that UAV4 has already been circling the waypoint for 15 seconds. 3 Algorithms 3.1 Choose Function uava_struct = complete(uava_struct) The Choose function is the set of logical rules by which a single UAV chooses a subtask to perform. The goal of this function is to allow the UAV to choose the subtask with the highest utility function out of all the subtasks that, to the best of its knowledge, are still available for assignment. Each UAV runs the choose function at all times; it constantly reevaluates its options, allowing it to abandon a subtask that is in progress if a much more attractive subtask arises. Because a UAV s knowledge of the world may be limited by its communication range, it may use this function to inadvertently choose a subtask that has already been claimed by another UAV. The conflict that results from this scenario is managed in the Conflict Resolution function. The first item a UAV calculates when it runs the Choose function is the number of other UAVs it believes are assigned to each task. It compares these numbers with the maximum number of UAVs allowed for the tasks, and it eliminates from consideration any task that already has its maximum number of UAVs assigned to it. The remaining tasks are considered to be feasible. Once the UAV has generated a list of feasible tasks, it considers all the subtasks contained in these tasks. By looking at the status of each subtask, the UAV filters out any subtasks already assigned to other UAVs. At this point, the UAV has a list of subtasks with a status of TODO, along with the subtask the UAV is currently assigned to. These are the subtasks it evaluates using the Utility function. The details of this evaluation are presented in the Utility Function subsection. When the UAV has calculated the utilities of all these subtasks, it finds the subtask with the highest utility. At this point, one of three scenarios occurs. In the first case, the UAV is not already assigned to a subtask. It assigns itself to the available subtask with the highest utility by running the setassign function to change the subtask s status to ASSIGNED. In the second case, the UAV is already assigned to a subtask and it finds it gains the highest utility by continuing the same assignment. It reassigns itself to the subtask by running the setassign function. In the third case, the UAV is already assigned to a subtask, but it finds another subtask with a higher utility. It sets the status of its current task to TODO by running the settodo function, and then sets the status of the new task to ASSIGNED by running the setassign function. 5

3.1.1 Utility Function The Utility function computes the desirability of a subtask for a particular UAV. The value of the function is between 1 and 2. The higher the value of 3 the function, the more desirable the subtask. Equation 1 is the formula for the Utility function. U = P norm + 1 d norm + 2 + λ task + λ req (1) In Equation 1, the term P norm is an adjusted value of the priority assigned to the subtask. d norm is a normalized parameter based on both the distance the UAV must travel to arrive at the subtask and the distance the UAV must travel to complete the subtask. λ task is a bonus that is given if the UAV is assigned to the subtask being considered. λ req is a bonus that is given if the task is designated as Required. More details about each of these parameters may be found below. The value of P norm may vary between 0 and 1. For subtasks that are not designated as Required, P norm is exactly the same as the priority value assigned to the subtask. For Required subtasks, P norm is 1 even though the priority value is 2. This parameter d norm may take any value between 0 and 1. It is calculated using Equation 2. d norm = λd norm,to task + (1 λ)d norm,for task (2) In Equation 2, d norm,to task is the normalized distance from the UAV to the first waypoint of the subtask, which may vary between 0 and 1. d norm,for task is the normalized distance the UAV must travel from the time at arrives at the first waypoint of the subtask until the time it completes the subtasks; it, too, may vary between 0 and 1. These two normalized values are found by dividing the actual distance by the maximum possible value for the distance given the size of the simulation area and the task type. λ is a weighting factor that may vary between 0 and 1. The higher the value of λ, the more weight is placed on the distance from the UAV to the subtask; the lower the value of the λ, the more weight is placed on the distance the UAV must travel to complete the subtask after it arrives at the first waypoint. λ task is a bonus parameter that is designed to make it attractive for a UAV to continue to carry out a subtask it is already assigned to. The value of λ task is either 0 or 1. This parameter is set to 1 when the UAV is already assigned 3 3 to the subtask under consideration, and it is set to 0 if not. λ req is a bonus parameter that makes Required subtasks very attractive. The value of λ req is either 0 or 2. It is equal to 2 when the subtask is 3 3 Required, and it is equal to 0 in all other cases. 6

3.2 Completion Function uava_struct = complete(uava_struct) The ability to decide when a subtask is complete is an important characteristic of intelligent agents. The Completion function accomplishes this by performing logical tests to determine if a subtask is complete. These parameters of these logical tests, called completion parameters, may include the time or distance flown, depending on the type of subtask Only the agent that is carrying out a subtask is allowed to decide if that subtask is complete. When an agent decides that it has completed a subtask, it sets the status of the subtask to DONE and updates other related fields. It then shares its updated mission status with other agents. As an example, let us consider agent A, which is assigned to the tracking subtask i. The subtask is considered complete if any of the following conditions are satisfied: Agent A tracks the target for some user-specified time period The target exits a specified region Agent A does not detect the target for some timeout period, and the target is assumed to be lost Although time and position are the most common completion criteria in this simulation, any logical condition using mission state of a UAV could be used for this purpose. 3.3 Target Subtask Activation 3.3.1 Identification and Activation uava_struct = activatetrack(uava_struct, target_struct) This function is executed the first time a target comes within the sensor radius of a UAV. Its purpose is to transition the status of TRACK subtasks from DORMANT to TODO. It assumes that once a target is detected, a UAV is able to identify this target and attach an id number to it. This id number is equal to the id number of a subtask within the TRACK task of a UAV s mission plan. The target detection assumption prevents any confusion that may occur when either multiple targets are detected by a single UAV or when a single target is independently detected by two different UAVs. In addition to updating the status of a TRACK subtask, activatetrack also updates the inittime, timestamp, and paramtimestamp fields of the subtask associated with the target, with the current time. The param field is also updated with the xy coordinates of the target. 7

3.3.2 Target Information Update uav_structa = updatetracksubtaskparam(uav_structa,target_struct) Since the activatetrack is only executed upon initial detection of a target, another function is required to constantly update the coordinates of the target while it is still within detection range. The updatetracksubtaskparam function simply updates the param and paramtimestamp fields of the subtask associated with the target. The paramtimestamp field is later used in the sync function to determine who has the latest information about a specific target. 3.4 Synchronization and Conflict Resolution uava_struct=syncstates(uava_struct,uavb_struct) Due to limited communication, it is generally not possible for all agents in a group to have access to complete and current information regarding the progress of the mission and the status of other agents. Therefore, at any given time, two agents may have different beliefs. Whenever communication is available between agents, the agents will share their beliefs of the mission by exchanging their mission state beliefs. Following this exchange, each agent will use an update protocol to produce an updated mission state estimate, based on its previous estimate and the estimate received from the other agent. Each agent is only allowed to share its mission state and a unique identifier to each agent within range. Consider an agent A, which has just received the mission state beliefs of agent B. Consider a one-to-one comparison of each of A s subtasks with each of agent B s subtasks. Using logical conditions based on its internal beliefs about the subtasks, agent A determines if it should take agent B s subtask state or keep its own. These logical conditions are based on time, subtask status, and utility. Examples of some logical conditions are shown below. For simplicity some fields of the data structures are excluded from the examples. Time: Time usually defines which subtask contains more valid information. Example: -- On Agent A -- -- From Agent B -- class: subtask class: subtask id: 4 id: 4 uavid: 3 uavid: 3 status: ASSIGNED status: ASSIGNED util: 1.000 util: 1.500 timestamp: 34 timestamp: 67 inittime: 0 inittime: 0 pri: 1 pri: 1 8

Since each agent agrees on which agent is doing the subtask and since AgentB.timeStamp > AgentA.timeStamp, Agent A will overwrite every element of its subtask 4 with the elements of agent B s subtask 4. Status: If a subtask has been completed, any updated timestamp is overruled by the belief that a subtask is already finished Example: -- On Agent A -- -- From Agent B -- class: subtask class: subtask id: 5 id: 5 uavid: 2 uavid: 3 status: TODO status: DONE util: 1.000 util: 1.500 timestamp: 230 timestamp: 30 inittime: 0 inittime: 0 pri: 1 pri: 1 Agent A has newer information about subtask 5. However, Agent B believes that this subtask has been completed, which overrules Agent A s beliefs. Agent A will overwrite every element of its subtask 5 with the elements of agent B s subtask 5. Utility: In some cases, an agent will believe that another agent has chosen the same subtask as it. The decentralized nature of the system requires that each agent decide individually to keep or give up a such a disputed subtask. A utility function is used to determine which agent is best suited to carry out the subtask. An agent will give up a subtask if the other agent has a higher utility for that subtask. To avoid problems with communication delays, each agent estimates the current utility of the other agent. This estimated value is used for the comparison of the two utilities. Example: -- On Agent A -- -- From Agent B-- class: subtask class: subtask id: 6 id: 6 uavid: 3 uavid: 4 status: ASSIGNED status: ASSIGNED util: 1.500 util: 1.000 timestamp: 67 timestamp: 67 inittime: 0 inittime: 0 pri: 1 pri: 1 9

Agent A believes that subtask 6 is assigned to it. At the same time, agent B believes that subtask 6 is assigned to it. Agent A must determine who is best suited for the subtask by comparing its utility for subtask 6 with its estimate of agent B s utility for subtask 6. Agent A has a higher utility for subtask 6 than agent B, so agent A will retain its belief and it will expect agent B to change its belief. When agent B performs the same comparison, it will overwrite its own beliefs with the beliefs of agent A. 3.4.1 Waypoint Controller function uav_struct = waypoint_controller(uav_struct) The waypoint controller is based upon proportional control. This controller calculates the turn rate of the UAV using Equation 3. ψ = k p (ψ ψ desired ) (3) The controller calculates a desired heading angle, ψ desired, finding the vector pointing from the current xy coordinate of the UAV to the desired waypoint. The heading error is determined by taking the difference between the current heading of the UAV and the desired heading angle. An actuation is then calculated by taking the product of the heading error and the proportional control constant, k p, which is stored in the gains field. This actuation is then stored in the controlinput where it will later be used in a kinematic update in the sim uav function. 4 Implementation The functions in this simulation are designed to adhere to the idea of decentralization. With the exception of the Omniscient functions and the broadcasting functions, each function can only access information about a single UAV at a time. This approach toward simulation will greatly simplify the implementation of the algorithms in a physical system with multiple agents. 4.1 UAV Model and Kinematic Update uava_struct = sim_uav(uava_struct) The UAV model used in this project is a nonlinear unicycle model given by Equations 4. ẋ = v cos(ψ) + W x (4) ẏ = v sin(ψ) + W y ψ = u ψ max 10

v = 20 meters/second u 0.2 radians/second The UAVs fly at a constant airspeed and have only one control input, a bounded turning rate u. The function sim uav implements these dynamics by performing a kinematic update of the form f = f 0 + fδt for each UAV at each time step in the simulation. The turning rate command is calculated in the waypoint controller function, and is located in the controlinput field of the UAV structure. 4.2 Omniscient Functions For the simulation to operate, two functions must have the ability to access more information than the local state of a UAV. We refer to these functions as Omniscient Functions. These functions simulate physical behavior in the system, and would not be present in a real implementation. The first omniscient function is called checktime. This function is used to determine if a UAV should broadcast its state information at a given time step of the simulation. Each UAV is assigned a separate broadcast slot so that, given a small enough time step, no two UAVs make broadcasts at the same time. Given the current time step and a UAV s broadcast time, the checktime function determines if the UAV should make a broadcast. The second omniscient function is called targetdetect. It is used to decide if a UAV is able to detect a target with its sensor. To do this, the function simply finds the distance between a given UAV and a given target and determines if this distance is within the sensor footprint of the UAV. 4.3 Implementing Collaboration Collaboratively In designing our simulation, we found that very close collaboration was necessary between our group members. We usually accomplished this by simply working together at the same location. This approach allowed us to avoid misunderstandings, as well as to help each other with the programming. On occasions when we could not work together at the same location, we found that many problems arose when we tried to combine our work. Even when we attempted to specify the requirements for each function in advance, we found that unexpected complications inevitably developed that prevented the functions from interfacing well with each other. In AI terms, we therefore found that to successfully carry out our Shared Plan, we needed to share state information very frequently because our ability to estimate each other s state proved to be very limited. 11

5 Results and Analysis Our simulation is designed so that all assigned tasks will eventually be completed regardless of the number of UAVs or their communication ranges. However, a simulation using many UAVs with large communication ranges should produce different results than one using few UAVs with small communication ranges. In this section, we discuss the effects of team size and communication range on overall performance. We will first examine the effect of the size of the UAV team on its performance. Figure 1 shows the simulation environment created for this test. 6000 task 1 task 2 task 3 ground station 4000 2000 0 2000 4000 6000 8000 6000 4000 2000 0 2000 4000 6000 8000 Figure 1: Simulation environment for team size test Each symbol in the figure represents a subtask; subtasks are grouped by type into tasks. The subtasks that make up Task 1 are completed after a UAV has circled the waypoint for two minutes. The subtasks in Task 2 require only that a UAV visit the waypoint momentarily. The subtasks in Task 3 require a UAV to circle the waypoint for eight minutes. Once all the subtasks have been completed, the UAVs return to the ground station and fly a loiter pattern around it. Figure 2 shows the time required for a team of UAVs to finish the subtasks shown in Figure 1. The size of the team varies from 1 to 6 UAVs. In each simulation, the communication range is set to 3750 m. Two sets of data are displayed in the figure. The line labeled Mission Complete corresponds to the time required for all the subtasks in the mission 12

4000 loiter complete mission complete 3500 time to completion (seconds) 3000 2500 2000 1500 1000 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6 number of UAVs Figure 2: Mission completion time for different team sizes to be completed. The line labeled Loiter Complete shows the time required to all planes to return to their default loiter mode after completing all tasks. The difference between these two lines is a measure of the system s efficiency; if two UAVs inadvertently work on identical subtasks, the difference between the lines will increase. In the figure, the time difference between the two lines remains fairly constant. Therefore, increasing the number of UAVs does not have a significant effect on the frequency of accidental subtask duplication. Looking at the Mission Complete line, we see that the time needed to complete all the subtasks drops greatly as the number of UAVs on the team increases. This decrease is especially drastic when the team size is small: the completion time falls by more than half as the number of UAVs increases from 1 to 3. As the team size increases from 3 to 6, the completion time begins to approach an asymptotic value, and its decrease becomes less steep. This asymptote is equal to the time required for a single UAV to travel from its starting point to the farthest subtask and return to its loiter point. We now examine the effect of the communication range of the UAVs on their performance. Figure 3 shows the simulation environment for this test. As before, each symbol in the figure makes up a subtask, and each subtask is grouped into a task. The subtasks belonging to Task 1 require a UAV to circle the waypoint for two minutes. For Task 2, the waypoints must be circled for 13

one minute before the subtask is complete. The subtasks in Task 3 have a completion time of three minutes. 6000 task 1 task 2 task 3 ground station 4000 2000 0 2000 4000 6000 8000 6000 4000 2000 0 2000 4000 6000 8000 Figure 3: Simulation environment for team size test Figure 4 shows the time required to complete the same series of tasks when the communication range of the UAVs is varied. In each simulation, the team size is held constant at 3 UAVs. Looking at the Mission Complete line, we see that the completion time drops from 5000 s to 2000 s when the communication range is increased from 0 m to 1000 m. Therefore, even a team of UAVs with a relatively small communication range performs far better than a team with no communication capability. As the communication radius is increased from 1000 m to 10000 m, though, the completion time remains almost constant. From this observation, we may conclude that the presence of some degree of communication is has a great impact on completion time, but the amount of communication does not have a large effect. On the other hand, the difference between the Loiter Complete and the Mission Complete lines changes drastically as the communication range increases. For the simulation with no communication, the two lines are very close; this occurs because the planes are not acting as a team, but as isolated agents with almost identical initial conditions. For communication ranges between 1000 m and 3000 m, there is a wide gap between the two lines. This result corresponds to many subtasks being accidentally duplicated by the UAVs due to poor communication. As the communication range increases past 5000 14

6000 loiter complete mission complete 5000 time to completion (seconds) 4000 3000 2000 1000 0 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 communication radius Figure 4: Mission completion time for different communication ranges m, the difference between the two lines drops greatly; the improved communication leads to fewer subtasks being performed more than once. Taking the results of Figures 2 and 4 together, we conclude that the size of the UAV team affects the completion time but not the number of accidentally duplicated subtasks. Meanwhile, the communication range of the UAVs does not greatly affect the completion time, but it does change the number of duplicated subtasks. 6 Conclusion We find that a system of UAVs working collaboratively lends itself well to an artificial intelligence framework. Many concepts used by AI researchers are directly applicable to this project. While the knowledge operator is not explicitly used in our work, the ideas related to this work weigh heavily on the project. Recalling the Byzantine Generals problem, it is not possible for two agents with a nonzero data transmission time to ever achieve an infinite number of commutations of the knowledge operator, also called common knowledge. Because true common knowledge could never be achieved by the UAVs, we approximate it by assuming it exists after two data transmissions. For example, if one UAV broadcasts its belief 15

that it should carry out a certain subtask, and a second UAV broadcasts a confirmation that the first UAV should carry out that subtask, we assume that common knowledge about the subtask exists between the UAVs. Without this assumption, the first UAV would need to make another broadcast to verify that it received the second UAV s reply, and then the second UAV would need to make another confirmation, and so on. [6] The concepts of intentions-to and intentions-that play a role in this project as well. Each UAV develops a set of intentions about the subtasks that are broadcast by the ground station. Given perfect communication, the mission states of each UAV would all appear to be the same. However, the interpretation of this state information would be different for each UAV. If a UAV considers a subtask in its own mission state that is assigned to it, then this would be considered an intention-to by the UAV. However, from the point of view of another UAV carrying out a different subtask, the first subtask is considered to be an intention-that. [7,8] Finally, the idea of fully and partially shared plans applies to this project. Collaboration between the UAVs takes place by the sharing of their utility functions, but not of their state information. Therefore, the UAVs achieve teamwork using partially shared plans, but not fully shared plans. Fully shared plans require a great deal of data transmission, numerous rounds of communication, and a prohibitive degree of complexity. [8] Through numerous simulations, we confirmed our intuition that greater team size and better communication allow a group of agents to accomplish a mission faster. We conclude that increasing team size or the communication range increases the quality of collaboration and therefore the performance of the system. Through numerous simulations, we confirmed our intuition that increasing the team size and communication range allows a group of agents to accomplish a mission faster. We conclude that these factors are important in improving the degree of collaboration in a system. 7 References [1] B.P. Gerkey and M.J. Mataric, Sold! Auction Methods for Multirobot Coordination, IEEE Transactions on Robotics and Autmomation, 18(5), pp. 758-768, Oct. 2002. [2] K. Konolige, D. Fox, C. Ortiz, et al., Centibots: Very large scale distributed robotic teams, Proc. of the Intl. Symposium on Experimental Robotics, ISER 2004. [3] L.E. Parker, ALLIANCE: An architecture for fault-tolerant multi-robot cooperation, IEEE Transactions on Robots and Automation, 14(2), pp. 220-240, April 1998. [4] J. Kennedy and R.C. Eberhart, Swarm Intelligence, Academic Press, 2001. 16

[5] M. Godwin, S. Spry and J. K. Hedrick, Distributed Collaboration with Limited Communication using Mission State Estimates, Submitted ACC 2006 [6] J. Y. Halpern, Reasoning About Knowledge: A Survey, IBM Almaden Research Center, San Jose [7] A. Haddadi and K. Sundermeyer, Belief-Desire-Intention Agent Architectures, Comparison of Architectures and Related Work, Chapter 5, Page 169-184 [8] B. J. Grosz and S. Kraus, Collaborative Plans for Complex Group Action, Artificial Intelligence 86(2):269-357, 1996 8 Log All three members of our team worked on almost all aspects of the project. This section describes the portions of the project that each team member spent the most time on. 8.1 Dan Coatta 8.1.1 Week 1: 10/30-11/5 Dan attended the initial group meeting to create a plan for the project. He suggested an alternate idea with full state information sharing between planes, and created a small simulation to test this concept. 8.1.2 Week 2: 11/6-11/12 Dan attended several group meetings discussing strategy for the project. He presented his small simulation, but it was decided not to pursue this approach further. 8.1.3 Week 3: 11/13-11/19 Dan attended several group meetings discussing strategy for the project. He began to develop a sliding mode controller for potential use with the UAV model. Also, he helped specify the constraints and capabilities of the collaborative system. 8.1.4 Week 4: 11/20-11/26 The group did not meet due to the Thanksgiving holiday and other obligations. 8.1.5 Week 5: 11/27-12/3 Dan began to work on the Utility function and how it integrates into the Choose function. 17

8.1.6 Week 6: 12/4-12/10 Dan continued to work on the Utility function and began to work on the Omniscient functions in the simulation. He created the slides that the group presented on the last day of class. 8.1.7 Week 7: 12/11-12/17 Dan worked on this report. 8.2 Mark F. Godwin 8.2.1 Week 1: 10/30-11/5 Mark attended the initial group meeting to create a plan for the project. He did background research into related research projects to find where our work could make the most impact. 8.2.2 Week 2: 11/6-11/12 Mark attended several group meetings discussing strategy for the project. He continued his background research, and he began the process of defining tasks and subtasks for the purposes of the project. 8.2.3 Week 3: 11/13-11/19 Mark attended several group meetings discussing strategy for the project. He continued defining tasks and subtasks for the project (what kind of fields should be in a task and subtask structure), and began to work on strategies for conflict resolution between the UAVs. 8.2.4 Week 4: 11/20-11/26 The group did not meet due to the Thanksgiving holiday and other obligations. 8.2.5 Week 5: 11/27-12/3 Mark continued to work on synchronization and conflict resolution between UAVs. He began to work on the problem of deciding when a subtask has been completed (Completion function). 8.2.6 Week 6: 12/4-12/10 Mark finished the synchronization and conflict resolution functions and continued to work on the Completion function. 18

8.2.7 Week 7: 12/11-12/17 Mark worked on this report. 8.3 David L. Nguyen 8.3.1 Week 1: 10/30-11/5 David attended the initial group meeting to create a plan for the project. He began to create the code that served as a framework for the entire simulation. 8.3.2 Week 2: 11/6-11/12 David attended several group meetings discussing strategy for the project. He continued to develop the skeleton code that was used for the project. 8.3.3 Week 3: 11/13-11/19 David attended several group meetings discussing strategy for the project. He began to write functions to fit into the framework he designed, including the UAV structure (separation of state dynamics and information/beliefs) and the functions defining the kinematic update of UAVs. 8.3.4 Week 4: 11/20-11/26 The group did not meet due to the Thanksgiving holiday and other obligations. 8.3.5 Week 5: 11/27-12/3 David designed functions to allow the UAVs to transition tracking subtasks from DORMANT to TODO. He began work on implementing the Choose function and also integrating the other members code into the framework he had created. 8.3.6 Week 6: 12/4-12/10 David finished the target tracking, target position update functions and began work on designing mission plans for debugging and demonstration purposes. He continued to integrate the functions written by his teammates into his framework. 8.3.7 Week 7: 12/11-12/17 David worked on this report and generated plots for the performance analysis of the system. 19