AIAA Infotech@Aerospace Conference <br>and<br>aiaa Unmanned...Unlimited Conference 6-9 April 9, Seattle, Washington AIAA 9-1918 Exploring Health-Enabled Mission Concepts in the Vehicle Swarm Technology Laboratory Stefan R. Bieniawski 1, Paul Pigg, and John Vian 3 Boeing Research and Technology, Seattle, WA, 9814 Brett Bethke 4, Jon How 5 Massachusetts Institute of Technology, Cambridge, MA, 139 The use of health based information in mission planning offers the opportunity to significantly enhance overall mission assurance. Developing mission concepts, even at a simple level, requires coordination of multiple assets and determination of common interfaces suitable for heterogeneous fleets. For systems that are subject to real failures, simulation offers the challenges of developing realistic scenarios and realistic health emulation. An alternative explored here is the use of indoor, rapid prototyping labs for exploring larger scale, heterogeneous mission concepts. Of particular interest are persistent missions were faults are a key driver in the aggregate mission performance. Results of flight tests with several different sample missions will be presented. These missions range from non-cooperative to cooperative and include a range of tasks. I. Introduction umerous different types of unmanned systems are being developed that are characterized by a host of different N mobility capabilities. These diverse vehicles can interact in complex ways when tasked to perform higher level missions. Understanding the system and its performance with respect to mission requirements is challenging in simulation due to inherent limitations or biases. This is particularly true for health enabled systems where failure rates and modes dominant the system behavior. A potential alternative is testing using surrogate vehicles. A significant challenge then becomes how to do the testing in a cost effective manner and to not spend extensive effort on developing the hardware and software required to fly a single vehicle let alone a large number of vehicles. The vagaries of testing outdoors, such as range management and the turbulent environment also pose significant challenges. One alternative presented here is the use of indoor flight test facilities. Recent advances in motion capture technology can be combined with continued developments in small scale electronics to enable rapid design and evaluation of flight vehicle concepts [1]. These evaluations can be extended to the mission level with additional vehicles and associated software. Boeing has been collaborating other researchers since 6 on the development of an indoor flight test capability for rapid evaluation of multi-vehicle flight control [, 3, 4]. Several other researchers have also been developing multi-vehicle test environments including several outdoors [5, 6] and indoors [7, 8]. The effort at Boeing has focused on indoor, autonomous flight capability where the burden of enabling flight is placed on the system rather than on the vehicles themselves. This allows novel concepts to be flown quickly and with little or no modification. This also enables rapid expansion to large numbers of vehicles with minimal effort. Boeing has also focused on enhancing the health and situational awareness of the vehicles [4]. The expanded state knowledge of the vehicles now includes information related to power consumption and performance of various aspects of the vehicle. Automated behaviors are implemented to ensure safe, reliable flight with minimal oversight. The dynamics of these behaviors must be considered in any mission software. This added information plays a key role in maximizing individual and system performance. 1 Associate Technical Fellow, AIAA Member. Research Engineer. 3 Technical Fellow, AIAA Member. 4 Doctoral Candidate, Aeronautics and Astronautics Department. 5 Professor, Aeronautics and Astronautics Department. 1 Copyright 9 by The Boeing Company. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.
The paper begins with an overview of the indoor flight facility in Section II. This is followed by a description of the mission management architecture in Section III. Flight test results for three different missions that utilize the architecture are then presented in Section IV. A. Overview II. Indoor Flight Capability Boeing Research and Technology has been developing a facility, the Vehicle Swarm Technology Laboratory (VSTL), to provide an environment for testing a variety of vehicles in an indoor, controlled, safe environment [3, 4]. The facility is also capable of supporting flights of numerous vehicles simultaneously. Successful, repeated, and sustained flights of 1 vehicles have been completed. This type of facility provides a significant growth in the number of flight test hours available over traditional ranges and reduces the time required to first flight of a concept. Further, the burden in terms of payload required to fly in the facility is significantly reduced and simplified through the use of off-board processing. In the context of exploring mission concepts, this type of facility offers a tremendous advantage in scalability and risk mitigation. Primary components of the VSTL are shown schematically in Figure 1 and pictorially in Figure. The components include a position reference system, the vehicles and associated ground computers, and operator interface software. These elements are connected using two network busses, one carrying the position information and the other the commands and other messages. The architecture is very modular supporting rapid integration of new elements and changes to existing ones. A simulation is available that connects directly into the two network busses and emulates the vehicles dynamics and the position reference system. The simulation is used to test the mission software interfaces and basic functionality prior to flight. Due to the complex nature of the multi-vehicle interactions and failure rates and dynamics, the simulation only provides the means for initial evaluation, flight test is still required for full evaluation. Observed Positions & Attidues REAL-TIME ENVIRONMENT AND DYNAMICS Position Reference System UAV #1 UAV #N UGV #1 UGV #N OPERATOR Application to reformat and broadcast position data Ground control for UAV #1 Ground control for UAV #N Ground control for UGV #1 Ground control for UGV #N Command and control software Situational display software Network for position and attitude data Network for heath, condition, and capability data, and commands Figure 1. Schematic view of Boeing Vehicle Swarm Technology Lab (VSTL). B. Position Reference System The position reference system consists of a motion capture system that emits coordinated pulses of light. This light is reflected from markers placed on the vehicles within viewing range of the cameras. Through coordinated identification by the multiple cameras, the position and the attitude of the marked vehicles is calculated and broadcast on a common network. The position reference system allows for modular addition and removal of vehicles, short calibration time, and sub-millimeter and sub-degree accuracy. Data at frame rates of a 1Hz with latency less than 4 ms are obtained for an arbitrary number of vehicles within a specified volume. A sufficient
volume is available at the VSTL to enable flight of both rotorcraft and fixed wing aircraft designed for slow flight. Ground vehicles of various types are also supported. Cameras Position reference system Processing Command and control Vehicles Ground computers Figure. Pictorial view of Boeing Vehicle Swarm Technology Lab (VSTL). C. Vehicle Description One type of flight vehicle flown extensively within the testbed is a modified remotely-controlled quad-rotor helicopter shown in Fig. 3a. While commercially available, the onboard electronics are replaced with custom electronics to allow communication with the ground control computers and to enable additional functionality. Other types of air and ground vehicles have also been operated autonomously [3, 4]. Figure 3b shows an image of the primary vehicle components. A collection of common, modular vehicle hardware and software components have been developed as part of the VSTL facility in order to expedite the vehicle integration process. One of two custom built vehicle hardware packages can be applied to a commercially purchased remote controlled vehicle or to a custom vehicle. Both packages include a microprocessor loaded with common laboratory software, current sensors, voltage sensors and a common laboratory communication system. The only difference between these packages lies in how the hardware interfaces with the vehicle actuators. One package includes four motor speed controllers suitable for driving DC motors directly. The other package includes four servo pulse outputs suitable for interfacing with commercially available servos and speed controllers. Communication is done via either serial radio or Bluetooth. For highly unstable vehicles such as the quad-rotors, on board logic is implemented and combined with rate gyro sensors to provide additional sensing and control capabilities. (a) (b) Figure 3. Complete health-enabled quad-rotor helicopter (a) and its primary components (b). 3
The flight vehicle electronics are paired with a ground computer where the outer loop control, guidance, and mission management functions are executed. The vehicle software and hardware architecture including all of these various elements is shown in Figure 4. The high quality of the data provided by the indoor flight facility enables the synthesis of control loops that provide high authority and excellent disturbance rejection. The performance of the control loops enables the precision coordinated flight of multiple vehicles [4]. The indoor VSTL facility has been instrumental in allowing a rapid development of suitable control laws with limited requirements on modeling. A key component developed as part of the VSTL is enhanced vehicle self-awareness. A number of automated safety and health based behaviors have been implemented to support simple, reliable, safe access to flight testing. The various algorithms are described in more detail in Reference 4. An essential part of the self-awareness exercised in the missions in this paper is knowledge of the energy consumption and energy remaining (flight time remaining) for the vehicle. As an illustration of the performance of the algorithms, a quad-rotor vehicle was flown in and out of ground effect, a source of environmental energy exploited commonly by birds and sailplane pilots. The vehicle was hovered at two different altitudes, 1. meters and. meters. For the latter altitude the proximity to the ground reduced the thrust requirements to maintain the hover. The result is given in Figure 5 which shows the estimated flight time remaining versus elapsed flight time. At all times the slope of the curve should be unity with a step change being indicative of a change in the rate of energy consumption. An increase of almost 5 seconds is seen in the flight time remaining due to ground effect. Position and attitude data Position and attitude data Commands and health data Assigned vehicle tasks Safety algorithms Automated behaviors Task manager Automated behaviors Status, processed health, and response notifications Ground Computer Software Guidance and Control Health algorithms Data for emergency behaviors On-board software Status and health data On-board Software Roll, pitch, yaw, collective commands Controller and mixer Measured gyros Health data processing Figure 4. Vehicle software and hardware architecture. Motors Sensors On-board Hardware Estimated Flight Time, s 6 5 4 3 Algorithm Initialization Transient Altitude Changed to. Meters Reference Line Slope = -1 Altitude Reset to 1. Meters 5 1 15 5 Time, s Figure 5. Performance of flight time remaining algorithm in ground effect 4
D. Command and Control Several command and control applications are used to provide an interface between the operator and the vehicles. One application used extensively provides a two-dimensional view of the test facility with high level vehicle information overlaid. The software supports the complete messaging interface to the vehicles including task commands, health messages, and reports from the vehicles regarding any state changes or automated actions. The software enables a single operator to control a large number of vehicles simultaneously. A second application enables high fidelity visualization and situational display. Further details of these software elements can be found in Reference 3. A third application supports higher level mission management functionality. This application was used to perform the missions described in this paper and it is described in detail in Section III. III. Mission Management The various missions detailed in Section IV were each completed using the same mission management software and architecture. The mission software connects to the laboratory environment or its simulation surrogate using the two network busses described earlier, one providing the positioning information and the other the various commands and vehicle messages. The mission management flow is comprised of three elements that receive inputs from the mission operator and the network and then output task commands to the vehicles. These elements include i) a mission manager, ii) a resource manager, and iii) a task manager and are shown schematically in Figure 6. Separating the mission software into three primary elements enables a variety of different approaches to be explored for each function. The mission begins with an overall sequence layout provided by the operator. The layout includes requests for required resources and tasks to be completed. The fulfillment of these requests is handled respectively by the resource and task managers. The resource manager surveys available resources in the system and deploys additional ones as needed, continually updating a list of taskable resources. The resource manager also interfaces with other components used to support the vehicles such as the landing locations and recharging assests. The task manager takes these taskable resources and assigns to them specific tasks from the overall set of requests. The result of the framework are a set of vehicle-task assignments that then executed by the vehicle control software. As the mission evolves changes occur in the available resources or requested tasks and the mission management is architected to address these automatically. The modularity of the architecture allows the automated responses for each manager to use different approaches within defined interfaces. Each of the three functionalities is described in more detail below. Tasks to specific vehicles Task Manager Taskable resources Resource manager Other resources Landing locations Recharge assets Task requests Resource requests Mission manager Mission definition Mission operator Figure 6. Mission management framework. The mission manager acts as the operator interface and provides two primary functionalities. First it allows for the definition of the mission elements prior to execution. For generality a standardized mission element definition has been adopted and is then used to build up the complete mission. The elements have standardized interfaces and their individual execution can be customized using a higher level scripting language. The mission elements consist of tasking for specified number and types of vehicle with specified entry and exit criteria. This is shown conceptually in Figure 7. Within the element, specific tasks are defined and these can be modified as long as the overall number and type of vehicles is not altered. The element begins execution when the entry criteria are satisfied. These can consist of a timed trigger, a sequential trigger, or on completion of another element. The exit criteria consist of element completion or sequential trigger. Timed completion is not separately handled as it is a 5
degenerate set of element completion by simply incrementing a timer internally. Each element is written using a higher level scripting language that supports execution logic such as for loops, while loops, etc. The requested resources for the element are combined with those from other elements and provided to the resource manager. The VSTL can support a range of vehicle types including multiple helicopters, ground vehicles, aircraft, and other assets. Tasks are generated within each element during its execution and are loaded into a queue that is used by the task manager. The VSTL architecture can support a variety of task complexities ranging from simple waypoints to more complex group search algorithms. The rich set of tasks enables the mission management software to focus on overall execution and performance. The second role of the mission manager is to provide a means for monitoring the mission execution and interacting as required. This interaction typically includes overall execution flow (e.g. start, stop, advance sequence) and simulated fault insertion. The latter is used for demonstration purposes to exercise the response of the system. Element execution and task generation for specified number and type of vehicles Mission element Entry criteria: Time elapsed Sequence advanced Prior element complete Exit criteria: Execution complete Sequence advance Figure 7. Mission element primitive used to define complete missions. The resource manager ensures that the number and types of vehicles needed within the mission definition are provided. It looks across the various mission elements and totals the requested number and type of vehicles. It then checks the number in active use and deploys additional ones as needed. To provide continuous support of the various mission elements, the resource manager checks for the remaining operational time of each vehicle, commanding those with low time remaining back to a base for recharge and automatically deploying a replacement to a default location. The resource manager is also responsible for the take-off and landing locations, ensuring no conflicts for the available spaces, and for refueling assets. The refueling can be either automated via a recharge station/landing pad [] or can be manual via replacement of the batteries. Persistence is included to ensure that the requested number and types are provided at all times throughout the mission. Changes as the mission evolves in terms of requests or due to faults or low battery are automatically replaced and the resource list updated. Significant complexity can be included to enhance the performance and reliability of the resource management. These can include look ahead in the mission plan and pre-deployment to minimize the time for a replacement to arrive. Other researchers [9] have enhanced the resource manager already and other approaches are also possible. For the experiments described in Section IV no advanced approaches were included. The task manager takes the available resources provided by the resource manager and the requested tasks from the mission manager and assigns responsibilities to specific vehicles. There is a large body of work related to task allocation and numerous methods can be applied. In the current architecture emphasis is placed on persistence and utilizing complex, efficient, individual vehicle tasks. For the missions in Section 4, simple task allocation approaches are used, although the modular framework supports including more complex methods. Continued reallocation of the various tasks is avoided since this can cause the transient inefficiencies to become a larger portion of the overall execution time. It is more important to maintain continued execution of the tasks and only re-assign in the case of replaced vehicles or changes in the task requests. Only a small subset, often comprised of just one vehicle, is therefore being considered for allocation at any one time and a sophisticated scheme is therefore not required. The most important aspect of the implemented allocation approach is the persistent assignment of the requested tasks. As resources are replaced, the tasks are automatically re-assigned to the new vehicles. Typically existing assignments are not shuffled since this can cause confusion to the operator and result in other complications. The individual task functionality also addresses most of the need for re-allocation as well since group tasks are handled at that level and not at the mission management level. For instance a coordinated search is a group task and the specific algorithm to perform it is handled at the vehicle level. Coordination is then through vehicle to vehicle messaging. One of the missions described in Section IV does, however, include a continued task re-allocation at the mission level to illustrate the capability for the mission manager to execute tightly coordinated tasks. 6
IV. Mission Concepts To illustrate the flexibility of the architecture and of the indoor facility to test a variety of concepts rapidly, three distinct missions were evaluated. Each mission included a specific mission metric to quantify the performance. The first mission was non-collaborative and consisted of a number of vehicles performing independent flight plans. The metric was focused on evaluating flight safety and the performance of collision avoidance methodologies. Architecture elements related to persistence, either by resource or task, were not utilized for this mission. The second mission utilized the persistent resource manager and consisted of an abstracted extended duration coordinated surveillance mission. The mission metric is associated with the level of surveillance provided in the presence of faults. The third mission exercised the full capability of the task and resource managers. It also highlights the ability of the vehicles and architecture to support a diversity of possible tasks. The mission involves assessment of a hazardous area using multi-modal vehicles. Success is measured as the completion of the various tasks included in the mission and robustness to faults. Each of the missions is described in more detail in the following sections. A. Non-collaborative, point-to-point multi-vehicle mission The first type of mission consisted of vehicles individually tasked to takeoff, fly to a designated location, perform a touch and go, and then return to land. The mission performance of each is then affected by the interaction with the other vehicles as their individual tasks are performed. To illustrate this type of mission, multiple vehicles were placed in the flight volume and each tasked with repeatedly performing the sequence with a location diametrically opposed to their starting point. The result was that all vehicles would be crossing the center of the flight volume and therefore forced to interact. The mission element definition and a schematic overview of the mission are shown in Figure 8. An element was associated with each vehicle and was set as complete when the flight time remaining was less than two minutes. The vehicles were staggered slightly in altitude in some cases to provide some safety margin and to allow for higher density. With each repeated sequence the interactions would differ as a result of differing flight times and departure times. The performance was measured in terms of the closest approach and the number of vehicles interacting. Also examined were the required flight times compared with nominal expected values. A key element in the performance of this non-collaborative mission is the behavior of the deconfliction algorithms embedded within the individual vehicles. The mission was developed specifically to test various approaches in a more stochastic encounter environment. Efforts were not made to utilize deconfliction algorithms that required exchanges of detailed state or flight plans between vehicles. In the case of this mission, the persistence aspects of either the resource manager or task manager were not required since the vehicles perform individually. The goal was to illustrate that the architecture was flexible enough to support this type of mission and could be used for evaluating various algorithms. Mission Elements Vehicle 6 Vehicle 5 Vehicle 4 Vehicle 3 Vehicle Vehicle 1 Each performs a takeoff, touch and go, land, and then repeats. Individual element complete when flight time remaining less than minutes. Elapsed duration depends on the distance between points. Vehicles Flight volume Take-off and land Fly to waypoint Perform touch and go Elements triggered by start mission Elapsed Time (a) (b) Figure 8. Non-collaborative mission comprised of multi-vehicle point-to-point flights. Mission element definition (a) and overview (b). Figure 9 shows a two-dimensional view of the flight paths for 6 vehicles as they were performing this mission. The path deviation of each vehicle was restricted to the X-Y plane by the algorithm used. The mission performance was evaluated by examining the pairwise distances between the vehicles in flight and the number of pairs actively 7
avoiding one another at any moment in time. These metrics are shown versus elapsed time in Figure 1. Pairwise distances are shown when both vehicles of the pair are airborne, defined as being at altitude greater than. meters. Active pairs, shown in the lower portion of Figure 1, are defined as pairs with X-Y separation distances of less than 1.5 meters, altitude separations of less than meters, and both airborne. The figure indicates that separation distances of greater than 1.5 meters are maintained. The frequency of the encounters is seen to be stochastic and provide a challenging test for the collision avoidance algorithms. 3 Quad_Rotor_13 Quad_Rotor_7 1 X (m) Quad_Rotor_ -1 Quad_Rotor_8 - Quad_Rotor_3 Quad_Camera_4-3 -5-4 -3 - -1 1 3 4 5 Y (m) Figure 9. View of the vehicle flight paths in the X-Y plane for the non-collaborative mission. Figure 1. Metrics for the non-collaborative mission; separation distances (upper) and active pairs (lower). Similar results are seen in general for a longer duration flight shown in Figure 11, however a smaller separation distance was observed with the closest approach being just.5 meters. These two vehicles interacted on many occasions during the flight, in most cases maintaining the desired 1. meter separation, although a second close approach is seen near the end of the mission. Another vehicle pair also experienced a small separation distance, in this case due to a vehicle fault and auto-land. The auto-land was initiated due to the high disturbances experienced by the congested flight and vehicle wakes. It is important to notice that the close encounters are strongly correlated 8
with number of interacting pairs. This suggests, as one might expect, that including the additional interactions is important to fully test the algorithms. Even for this non-collaborative mission the health awareness plays a significant role in executing the mission safely and gives insight into the time delays associated with the avoidance actions. The elapsed time, given by the lower set of curves of Figure 1, is particularly interesting as it shows the variations as the vehicles fly the same leg. One vehicle, highlighted as dashed lines, sees an almost 4% variation in the time required. Several of the vehicles complete their mission as indicated by their flight time remaining dropping below minutes. Recall that this was the termination criteria for the vehicle mission elements and the mission management then ended their participation. Figure 11. Key avoidance metrics from a longer duration run of the non-collaborative mission. Time remaining, minutes 15 1 5 5 1 15 5 3 35 Time, seconds Time elapsed, minutes 1.5 5 1 15 5 3 35 Time, seconds Figure 1. Elapsed time and flight time remaining from non-collaborative mission. 9
B. Collaborative, persistent surveillance mission The mission architecture and the role of health awareness was further explored in an example collaborative persistent surveillance mission. The mission was purposely kept simple to clearly illustrate the health based behaviors and the challenges encountered when collaborative missions are performed in congested environments. The goal was to understand automated health behaviors and their effects on mission performance for fault prone vehicles. A key metric was then to ensure the surveillance, in this case a coordinated observation, had minimal disruptions as vehicles experienced faults or required recharging. The mission consisted of four vehicles tasked with maintaining a progressing orbit about the center of the flight volume at a set altitude and with even spacing between them. This represents an abstracted form of a variety of coordinated search or tracking type missions. A single element, as shown in Figure 1, was used to define the mission. It requested four quad-rotors and issued fly to waypoint tasks to each and continually updated these in order to progress the vehicles around the orbit pattern. During this update it also performed the allocation using a greedy algorithm, assigning each vehicle to the nearest waypoint. This was usually evident at transitions when vehicles were replaced. A priority is assigned to the four locations around the circle and if an inadequate total number of vehicles exist, the lower priority locations are not assigned. This can lead to transients as well, sometimes involving vehicles crossing the pattern as this is the lowest aggregate cost assignment. Spare vehicle Take-off and land Mission Elements Element complete on sequence advance. Persistent Surveillance Resources: Four Quad-rotors. Tasks: Fly to waypoints, continually updated. Element triggered by mission start Elapsed Time Spare vehicle Waypoints precessed around circle (a) (b) Figure 1. Collaborative surveillance mission abstracted as four equally spaced vehicles continually orbiting in a circle. Mission element definition (a) and overview (b). Figure 13 shows an overhead view of the flight trajectories during a single realization of the system. The orbit pattern is well defined along with transition paths from the landing locations and also across the orbit. The starting location of each vehicle is labeled by its name. In all cases except one the vehicles returned to a landing location when the mission was terminated. One vehicle experienced a fault and performed an emergency landing. Figure 14 shows the evolution of the flight time remaining and elapsed time during the mission. Several key events are labeled including the emergency landing, recharges, returns to base, and auto-deploys. The latter were performed automatically in response to the emergency landing and the returns to base. The recharges were completed by manually replacing the batteries. As discussed earlier the metric associated with this mission was the number of vehicles within the orbit pattern. This is given by the number of vehicles at altitude within 1% of the desired orbit radius. Figure 15 shows the metric and indicates some periods of lost mission coverage. The goal was not to show superior coverage but rather to provide a framework for evaluating technologies and mission definitions and their potential impact on mission performance. The benefit of an automated system to manage the resources is indicated in these results by the significant amount of activity in the span of 1 minutes. More effort in this case is spent on maintaining the asset availability, either by recharge or ensuring flight readiness, than in the actual execution of the mission. 1
4 Quad_Rotor_8 Quad_Rotor_1 3 X (m) 1 Quad_Rotor_6 Quad_Rotor_3-1 - -3-4 6 Quad_Rotor_5 4 Y (m) - -4 Quad_Rotor_ -6 Figure 13. Sample collaborative surveillance mission flight trajectories. Auto deploy Recharges Auto deploy Emergency land Return to base Figure 14. Flight time remaining and elapsed time for sample collaborative surveillance mission. 11
Number of active vehicles 4 3 1 1 3 4 5 6 7 Time, seconds Figure 15. Performance metric for collaborative surveillance mission given by number of vehicles actively participating in orbit pattern. C. Multi-task collaborative mission The third type of mission explored in this paper consisted of exploration of a hazardous area using a variety of tasks and vehicle types. The elements that form the mission definition is shown in Figure 16. The mission begins with an initial survey of the overall flight volume performed by 1 or quad-rotors. A lawnmower type search is preformed in a designated time and on completion the mission management immediately transfers the assets to and initiates the next element, persistent observation of an area of interest. The observation in this case is from a static perspective, unlike the previous persistent surveillance mission. Both of these first elements are supported by the resource and task managers to ensure they are supported throughout the mission duration. In case of faults or low batteries, vehicles are automatically replaced with spares. At some time following the initial survey, the operator initiates the next elements by commanding an sequence advance. This element requests 1 quad-rotor and two ground vehicles. The vehicles are deployed and commanded to maintain a formation position relative to the operator as he/she advances into the mission area. After an initial approach and at his/her discretion, the operator commands the next sequence. The assets are divided into air and ground and separately tasked. The ground vehicles perform a ground search of the remaining mission area, again using a lawnmower type of search algorithm. The ground clearance automatically terminated when the task is completed and the vehicles return to a default location The air asset is set in a mode to support direct control from the operator via a manual input device such as a joystick. The control is provided in an augmented manner to make it simple and in case input is removed the vehicles will remain in position. The operator is free to maneuver the vehicle to complete a detailed inspection, utilizing on board video to complete the task. When inspected to his/her satisfaction, the operator advances the sequence again, providing sufficient time to proceed through the mission area and then terminate the mission. These latter elements are once again supported at all times by the resource and task managers to provide consistent support. In the case of a fault even when under manual control, a replacement is automatically deployed. Mission Elements Triggered by mission start Triggered by advance sequence Initial approach Triggered by prior completion Triggered by advance sequence Detailed inspection Ground clearance Final approach Terminated by task completion Triggered by advance sequence Mission complete Initial aerial survey Persistent observation Terminated by mission completion Elapsed Time Figure 16. Multi-task collaborative mission element definition. 1
The multi-task collaborative mission includes a wide range of task types, performed by different vehicles with differing modalities. They are all contained under one framework and supported throughout by the resource and task managers. A sample realization of the mission is shown in Figure 17. The realization is for four quad-rotors with three being actively used and one that remained as spare. Two ground vehicles were also active and used to complete the mission. The goal of the realization was to explore an area defined in the left of Figure 17 as the Building elements. These were included in the volume for visualization and collision avoidance purposes. 4 3 Ground_ X (m) 1 Building_4 Building_3 Building_ Ground_1-1 - Building_1 Quad_Rotor_7 Quad_Camera_14-3 6 4 Y (m) Quad_Camera_15 - -4 Quad_Camera_5-6 Figure 17. Sample realization of the multi-task collaborative mission. V. Summary and Conclusions An indoor facility for performing the rapid evaluation and development of health-enabled mission concepts has been described. The use of an indoor facility provides a controlled environment for developing the vehicles and the mission management concepts and requirements. Sample collaborative and non-collaborative mission concepts were flight demonstrated. References 1 J. T. Troy, C. A. Erignac, and P. Murray, Closed-loop motion capture feedback control of small-scale aerial vehicles, AIAA Paer 7-95, AIAA Infotech@Aerospace 7 Conference and Exhibit, Rohnert Park,CA, 7-1 May 7. J. How, B. Bthke, A. Frank, D. Dale, and J. Vian, Real-time indoor autonomous vehicle test environment, IEEE Control Systems Magazine, vol. 8, pp. 51-64, April 8. 3 Saad, E., Vian, J., Clark, G., and Bieniawski, S. R., Vehicle Swarm Rapid Prototyping Testbed, Proceedings of the AIAA Infotech@Aerospace Conference and Exhibit and AIAA Unmanned...Unlimited Conference and Exhibit, AIAA-9-184, Seattle, WA, 9. 4 Halaas, D. J., Bieniawski, S. R., Pigg, P., and Vian, J., Control and Management of an Indoor, Health Enabled, Heterogenous Fleet, Proceedings of the AIAA Infotech@Aerospace Conference and Exhibit and AIAA Unmanned...Unlimited Conference and Exhibit, AIAA-9-36, Seattle, WA, 9. 5 Hoffmann, G., Rajnarayan, D. G., Waslander, S. L., Dostal, D., Jang, J. S., and Tomlin, C. J., The Stanford Testbed of Autonomous Rotorcraft for Multi-Agent Control (STARMAC), 3 rd Digital Avionics System Conference, Salt Lake City, UT, November 4. 6 D.R. Nelson, D.B. Barber, T.W. McLain, and R.W. Beard, Vector field path following for small unmanned air vehicles, in Proc. 6 American Control Conf., Minneapolis, MN, 6, pp. 5788-5794. 7 V. Vladimerouy, A. Stubbs, J. Rubel, A. Fulford, J. Strick, and G. Dullerud, A hovercraft testbed for decentralized and cooperative control, in Proc. 4 American Control Conf., Boston, MA, 4, pp. 533-5337. 8 O. Holland, J. Woods, R. De Nardi, and A. Clark, Beyond swarm intelligence: The UltraSwarm, in Proc. 5 IEEE Symp., Pasadena, CA, June 5, pp. 17-4. 9 B. Bethke, L. Bertuccelli, and J. How, Experimental Demonstration of Adaptive MDP-Based Planning with Model Uncertainty, AIAA- 8-63, AIAA Guidance, Navigation and Control Conference and Exhibit, Honolulu, Hawaii, Aug. 18-1, 8. 13