1. Deciding to Land a UAV Safely in Real Time Jonathan Sprinkle, J. Mikael Eklund, S. Shankar Sastry University of California, Berkeley sprinkle@EECS.Berkeley.Edu http://www.eecs.berkeley.edu/~sprinkle

2. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley2Overview  Problem description  Solution ideas  Engineering problems  Ongoing work  Conclusions Source: http://maps.google.com/http://maps.google.com/

3. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley3Motivation/Background  SEC Capstone Demonstration  Landing/Wave-off scenario (safety calculation)  Joint work with Dr. Mike Eklund, Dr. Ian Mitchell, Prof. Shankar Sastry

4. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley4Question:  Are any of the reviewers in the audiences?  Rephrased as:  Does anyone know when the first automatic landing took place?

5. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley5Answer: August 23, 1937  Another question then:  Why is this problem still hard?  Answer(s)  Lots of planes  Faults during the process

6. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley6 Landing Scenario  Consider a fixed-wing UAV following its glideslope

7. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley7 Motivating Example  It is directed off its landing path

8. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley8 Motivating Example  And after some time redirected to land Can the decision to safely land: - be made in real time? - be guaranteed as true? - be guaranteed as true?

9. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley9 Motivating Example  Protocol  If landing is impossible, a go-around maneuver should be performed  If landing is possible, the plane should recapture the glideslope and land

10. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley10Requirements  An answer must be absolutely safe  The answer must come “in time”  Design vetting and testing  Rate of false positives should be zero  i.e., an answer of “safe to land” should never be given if it is unsafe  Rate of false negatives should be minimally acceptable  “Better safe than sorry”, but as infrequently as possible

11. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley11 Engineering Problems Answering “in time” The computation interval should influence the state data used for the calculation (derived from validation interval) i.e., you should use the validation interval to ask about the time at which you would actually be able to do something

12. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley12 Technology and Analysis Solutions for Reachability  Online-synthesis (did not pursue)  Safe sets  Forward reachability  Backward reachability  Computational load  Addressing computational load  Reduce number of dimensions  Variable resolution  Safe sets  Used to determine whether system will be at a certain state in the future  Consist of the union of all possible safe states of the system (within a time/operational frame)  Safety is obtained by a time/state pair being located either in or out of the safe set

13. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley13 Technology and Analysis Solutions for Reachability Figures by Ian Mitchell  Forward:  Must be recomputed for each start point  Both dimensionally exponential  5 dimen: ~hours to compute  6 dimen: ~weeks  Backward:  Must be recomputed for each end point

14. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley14 Forward or Backward?  Given that the runway is stationary, the use of forward reach sets seems inappropriate  Long computation times to recalculate set  Always checking the same point  Using backward reach sets makes sense  Compute reach set offline  Check different points each time

15. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley15 Logical Implementation (a) safe-set of operation relative to the desired point of landing on the virtual runway (f). (b) vector-off maneuver requested (c) command to land (if possible) is given (d) aircraft will continue to vector-off (if landing is unsafe) or will issue commands to recapture the glideslope at some point (e).

16. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley16 Addressing Computational Load  How many dimensions are required?  x, y, z   ’ (constraint: max rate of change of pitch)   ’ (constraint: max turn rate)  v (constraint: min velocity)  z’ drop (max rate of change of altitude)  This is a constraint, calculated from  and v  Six! This could take weeks!  How (or is it possible) to reduce?

17. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley17 Addressing Computational Load  Safe approximation  Airspeed remains relatively constant during recapture of glideslope (reduces by 1 dimension)  No loss approximation  Input control vector dimensions are orthogonal  e.g., changes to  will not change   Guaranteed by the open-loop controller  Allows separation of remaining 5 dimensions into two 3 dimensional problems with one overlap  Variable resolution  Choose different step-size for different complexity  Grid spacing is on the order of 5-ft close in, 100-ft far out

18. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley18 Implementation and Results InitialRunway

19. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley19 Implementation and Results All pieces fit together, step size changes by power of 10 to match required resolution [0,3) [3,10)

20. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley20 Implementation and Results All pieces fit together, step size changes by power of 10 to match required resolution [0,1) [1,3) [3,10)

21. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley21Implementation  Use backward reach set to make one lookup table for each 3D vector  ~7MB total size  Lookup time: ~10ms (~5ms each)  Time to generate:  ~15 mins for the reach set 1.  ~2 hours to compile into an executable (due to compiler issues)  Total development time  ~2 man months of coding, plus design and research required for safe sets 1. Times are representative of typical results. See store for details.

22. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley22 Demonstration & Results  Flown on live T-33 aircraft  Landing on “virtual” runway at a high altitude  Ground controller gives vector-off and recapture commands  1 successful landing  1 go-around after “unsafe” answer (later verified offline as a correct result)

23. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley23 Aftermath & Conclusions  Safety of ground and vehicle increased  reduced stress and decision load for pilot  aircraft training less of a factor than before  hyper-accurate safe set calculations  Design lends itself to multiple aircraft  simply create new sets based on constraints  no increase in computation (simple lookup)  uniform integration strategy  Level of autonomy increased  multiple sets for different scenarios (hazardous weather, wartime, etc.)  guaranteed within operational parameters

24. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley24 Ongoing Work  Invited Paper to “Innovations in Systems and Software Engineering” out in August  Helped us flesh out a bunch of new and interesting issues in these reach set calculations and their usage  Added Aaron D. Ames, and Ian Mitchell as authors Matlab-- Have at you! Jon, what controls classes have you taken?

25. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley25 Ongoing Work  Variable grid scaling  Allows capture in one reach calculation, rather than gluing three together

26. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley26 Ongoing Work  Bigger, Better ® control law calculations  Now, calculations based on smooth controller, and closer to obeying inertial restrictions

27. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley27 Future Work  Choose control law to use, based on reach set answer, rather than just having one control law. Enlarged to show detail. Some restrictions apply Tax title and registration not included.

28. ACC - 12 June 2005Jonathan Sprinkle, UC Berkeley28Questions? “Well HAL, I’m damned if I can find anything wrong with it.” “Yes. It’s puzzling. I don’t think I’ve ever seen anything quite like this before.” -- 2001: A Space Odyssey