Managing Power in a Swarm of Autonomous FPGA equipped Unpiloted Airborne Vehicles

1. Managing Power in a Swarm of Autonomous FPGA equipped Unpiloted Airborne Vehicles David KearneyApril 2006

2. About Us • University of South Australia • 5 campuses • 25,000 students • School of Computer and Information Science (CIS) • 10 programs, 2000 students, 50 active researchers in 9 research groups

3. Reconfigurable Computing Lab • Current Staffing • 3 academic staff, 4 F/T PhD students, 3 P/T PhD students, 4 masters students, 4 Honours students • Current projects include: • The use of reconfigurable technology in Unmanned Aerial Vehicles (UAV) • The ReconfigME operating system • Hardware Join Java language for describing partial dynamic reconfiguration • Missile Tracking using massively parallel computation on FPGAs • Acceleration of Infrared Scene generation using a cluster of FPGAs • RNA structure prediction and searching using FPGAs • Models of reconfigurable computing

4. Overview • Aim of this research • UAV hardware • Applications of swarms • Background research OS for reconfig. • Motivation • Mobility of tasks in swarms • Agents and rules • What is a bankable benefit for dynamic partial reconfiguration

5. Swarms of UAVs • Swarms can replace a single platform with better performance • Airframes and engines are well developed but high perforamce embedded computing environments are harder to find • Small UAVs (wing < 3m) have limited power and bandwidth

6. Aim of this research • Our aim is demonstrate the feasibility of a software/hardware environment that allows the total power available in the swarm to be shared. • Reconfigurable computing tasks move from one member of the swarm to another through the use of networking and partial run time reconfiguration. • We expect that this experience with partial run time reconfiguartion as a power management strategy may be useful in other applications.

7. The Vector-P airframe Wingspan: 2.56m (101”) Length: 2.2m (87”) Payload: 68cm x 22cm x 22cm and up to 20lb Flight Time: 4 hours

8. Airframe and hardware

9. Geo-location http://www.avtec.com/products/simulation_test_systems/ops_rf_geolocation_test

10. Geo-location accuracy • A system with more numerous but less accurate sensors can achieve 50% reduction in errors Overall accuracy Number of data collectors Miniature UAV’s & Future Electronic Warfare Dr Anthony Finn Dr Kim Brown Dr Tony Lindsay EW & Radar Division DSTO, Edinburgh, SA 5111 http://www.aerosonde.com/downloads/Aerosonde_DSTO_EW.pdf

11. Fire Ground Surveillance http://geo.arc.nasa.gov/sge/UAVFiRE/completeddemos.html

12. Uses of UAVs on the fire ground • Fire may not be scouted and sized up • Firefighter cannot see main fire nor are they in contact with anyone who can • UAV provides an IR map of the fire ground around the fire truck and acts as a radio relay to the truck of telemetered data.

13. Swarms of UAVs don’t fit many models of computation • No users associated with each platform • Dynamic creation and destruction of communication channels • No central coordinator • Perform actuation • Can spawn children in the form of motes • Can physically transport data • Bandwidth is variable and power dependent • Need both (reconfigurable) hardware and software

14. Background • Previous research by the group suggested it was feasible to dynamically load and remove hardware tasks from an FPGA • This has been demonstrated by prototypes of an Operating System for Reconfigurable Computing

15. Applications sharing the FPGA

16. Allocator Allocator Partitioner Partitioner Placer Placer Network Configurator Network Configurator Loader Loader PC platform FPGA RAM Application Running Radio Modem Camera

17. From a simulation

18. From the a running prototype

19. Initial state - no applications loaded • Memory controller (top right) • Dummy network stubs to the right and underneath the memory controller

20. State 1 Tracking algorithm loaded and active • No objects detected

21. State 2 object detected • Edge detection loaded for feature extraction

22. State 3 Swap out edge enhance • Encryption loaded and running • Note that blob tracking has been checkpointed and continues to run after the task swap: checkpointing is needed because partial run time reconfiguration is not available on the prototype hardware

23. Motivation Consider the limitations of UAVs… • Limited power budget • Limited physical space and lifting capacity for computer systems • Limited bandwidth to other UAVs and ground stations …and the typical computational tasks performed • Intensive processing, often involving large amounts of raw data (such as video) • Data coming from different sources and required at different places

24. Motivation (cont.) • Could the OS be extended from managing multiple HW circuits on one device to multiple HW circuits on many networked devices? • How is this best done? • What new capabilities can we explore? • Is this going to be feasible from a performance point of view?

25. UAV capabilities • Multiple heterogeneous platforms, each fitted with sensors, processing units, and effectors Camera IR Camera Processing units Microprocessor UAV 1 UAV 2 FPGA

26. Typical computing scenario • Algorithms execute in both hardware and software. Addressing schema for sensors and effectors allows resources to be accessed across radio/wireless networks Camera-001@UAV1 IR_Camera-001@UAV2 Data Fusion algorithm Preprocessing and compression algorithms

27. Mobility scenario • Resource addressing and the ability to remove and reload HW circuits provides us the ability to relocate HW/SW applications at run time sensor@uav2 Sensor data Sensor data Results State capture Restore state Restore IO Transmission of state

28. Management of Mobile Hardware • How should hardware be moved? • Avoid centralized management • Let each application developer define their own rules for migration which best suite the nature of the application • Rules are implemented as mobile HW/SW agents capable of storing the state of execution, transporting itself across a network, and resuming execution at a remote location

29. Agent Fuzzy Rule Base • A fuzzy rule set is associated with each mobile agent • Rules are tailored to the need of the particular application If stored-power is decreasing and power-cost-of-bandwidth-to-sensors is high Then rationale-to-migrate is high

30. Types of mobility

31. Reasons for task mobility • Why move applications • Move closer to sources of data (reduce the power cost of RF bandwidth) • Move to platforms with power surplus (power sharing) • Move from heavily utilized platforms to one with idle resources (compute resource sharing) • Why move state • Allows more flexibility in the timing of moves

32. Swarm supports all types of mobility

33. Managing Migration • Avoid centralized management • Agent is implemented in conjunction with a software thread attached to the hardware • The agent periodically interrogates the UAV network to find the best site for execution

34. Dynamic partial reconfiguration • Can reduce power consumption • Can reduce compile times • Can permit clustering of computation • So it should be a priority for future research • …..and VLSI innovations