For the past 5 weeks, we have been researching and working on the best way to prevent in-air collisions between UAVs. This presentation discusses our research on Dynamic Sparse A*, as well as our implementation of the algorithms that we have decided on. It addresses the differences between our methods and those represented in the literature, as well as our approach to making A* both dynamic and sparse. The second half of the presentation focuses on the challenges we have faced over the past 5 weeks and how we have overcome them.

1. PROGRESS REPORT
ANDREW KAIZER, THOMAS CRESCENZI,
AND TYLER YOUNG

2. HOW FAR ARE WE?

3. Divide and Conquer
• Andrew: (Sparse) A*
• Thomas: Plane prediction, ROS
integration
• Tyler: Best cost/danger grids, X-
Plane visualization

4. Refresher: Plane Prediction
l Works by evaluating the chances that a
plane will be in a specific grid
l Takes into account time which allows for
the plane to be seen as moving through
time
l Branches in the chance that a plane
could equally be in two places at one
time

5. New Additions
l Now planes are predicted to
their avoidance way point and
from there to their goal
l In addition planes are
predicted a second past their
goal

6. New Additions

7. Best Cost Estimates
If you find yourself in this square, the
best path you can find is of cost ____.

9. A* Search
• Divided into three parts:
– Sparse A* Setup
– Dynamic-Sparse A* Search
– Dynamic Collision Analysis

10. Sparse A* Setup: Steps 1-7
1. Get Start Point, Waypoint Point
2. Construct optimal grid forward path
3. Construct optimal grid back path
4. Fill in rest of optimal spaces
5. Calculate Optimal Continuous Space
Path
6. Determine if Optimal Path is Clear
7. Clear ? Return goal : continue to step 8;

11. Dynamic-Sparse A* Search: Steps
8-13
8. Look at current minimal (smallest) node
9. Calculate bearing of current node
10. Calculate legal expansion
11. Create successors
12. Goal ? Go to Step 13 : Go to Step 8
13. Push every single point, in order of time,
onto the A_STAR queue

12. A* Collision Analysis: Step 14-17
14. Pop OPT and A_STAR points
15. Compare o.x, o.y and a.x, a.y
16. DIFFER ? go to step 17 : go to step 14
17. Return Collision Avoidance Point
18. If queues empty: OPT ≈ A_STAR

13. Step One: Start/End

14. Step Two: Optimal Forward

15. Step Three: Optimal Backwards

16. Step Four: Full Optimal

17. Step Five: Optimal Path

18. Step 6/7: Determine Path Clarity
For time t = {0…n}
a) Calculate expected values
b) Retrieve real values from Danger/Best Cost
c) if REAL > EXPECTED
a) PATH is not clear; go to step 8
d) t++
e) Go back to step a

19. Step 8-13: (2,2,0)

20. Step 8-13: (3,3,1)

21. Step 8-13: (3,2,1)

22. Step 8-13: (4,1,2)

23. Or if you like Crudely Drawn GIFs

24. Steps 14-17
OPTIMAL PATH A STAR PATH
1: (2,2,0) -- START 1: (2,2,0)
2: (3,2,1) 2: (3,2,1)
3: (4,2,2) 3: (4,1,2) – Collision Point
4: (5,2,3) -- GOAL 4: (5,2,3) -- GOAL
5: … 5: …
RETURN: Point (4, 1, 2)

25. Sparse-Dynamic A*
• Sparse: Looks at a minimal area, instead
of wasting time on dead ends
• Sparse: Does not call A* if the path is
clear
• Dynamic: Makes educated guesses
based on time steps into the future
• Dynamic: Versatile, can respond to
change quickly

26. ROS Integration
l Two services are used
l requestwaypointinfo is used to get
the final goal of each plane for use
with predicting paths
l gotowaypoint is used to send the
planes to the right waypoint
l Telemetry updates are received
through a message

27. Classes to Help with Integration
l Plane class
l Represents a plane and contains all
of the information from telemetry,
and a bit more
l Position class
l Represents a position in both latitude
and longitude and x and y
l Used by the Plane class to aid in
storing information

28. Steps Done by ROS
l Get telemetry data
l Update the plane object
l Get and set the plane’s goal with the
requestwaypointinfo service
l Build the best cost grid
l Run A*
l Tell plane to go to the point A* says with
the gotowaypoint service

29. Integrating with ROS
A* works brilliantly in our
simulated world of dots,
starts, and goals.
What happens, though,
when we work with UAVs?

30. “Chicken”

31. Integrating with ROS
Playing nice with ROS—and
doing so reliably—is proving
more difficult.

32. Visualization in X-Plane

33. WHAT OBSTACLES HAVE
WE OVERCOME?

34. A* Works Really Well
Andrew has graphs to show
tomorrow!

35. BC Grids—Where Do We Stop?

36. BC Grids—Where Do We Stop?

37. BC Grids—Where Do We Start?

38. Giving Planes Breathing Room

39. Difficulties Predicting Planes
l Very few due to excessive
planning on paper
l Swaths created when time was
predicted incorrectly
l Only predicting to final goal
and ignoring intermediate way
points

40. Difficulties with ROS
Troubleshooting
l No debugger
l No call stack listing
l No outputting (if you’re doing
it wrong!)

41. Difficulties with ROS
Troubleshooting
l No debugger
l No call stack listing
l No outputting (if you’re doing
it wrong!)

42. Solutions
l assert(false) deeper and
deeper into the stack
l Turn outputting on and add
tons of colors to the terminal
l Add a good number of
compiler directives to direct
output

43. Learning to Troubleshoot… Again
Without a debugger, we end up
asserting everything we can.

44. Insidious Planar Assumptions
• Accidentally modeled a flat
earth
• Background in planar
(Euclidean) geometry makes
our intuitions unreliable

45. Insidious Planar Assumptions
Distance between two points:
Compare to planar distance:

46. Insidious Planar Assumptions
Bearing between two points

47. Insidious Planar Assumptions
Ending point given distance and
bearing:

48. Insidious Planar Assumptions
Ending point given distance and
bearing:

49. Computation Time and Parallelism
• Time complexity is linear with
respect to the number of
aircraft
• Each aircraft’s path is plotted
independently of others—can
have one plane per CPU with
no penalty

50. WHAT OBSTACLES DO WE
STILL FACE?

51. Testing in the Air
• Autopilots are untested
• No guarantee that behavior
observed in the simulator will
carry over to the real world

52. Improving Our Methods
• Plane prediction
• Heuristic (best cost grid)
generation
• Parallelism

53. Troubleshooting the Little Things
We're done with the things we
aimed to do—just need to bring
them together.
• E.g., plane 0 doesn't take more
than 1 goal...

54. HOW WILL WE
OVERCOME THESE?

55. We’ll see.
• Troubleshooting has to take
place as we encounter
problems.
– Same methods as ever: trace
the problem to its roots.

56. We’ll see.
• Research
– Use known methods of optimizing
code, predicting planes
– Use built-in methods for
parallelizing in ROS