Published on

At the University of Southampton we design, build, and fly high end unmanned aerial vehicles (UAVs) for civilian usage. For this we are developing DECODE (Decision Environment for COmplex Design Evaluation), a toolset that integrates the different codes needed to successfully design and build an efficient UAV: costing code, fluid simulation codes, operational simulation model, geometry engine, etc. The goal is to have a fully automated end-2-end UAV design system that can be used to rapidly design custom built UAVs that can be quickly and cheaply manufactured using techniques like 3D printing. Our main case study is the use of UAVs for search and rescue (to replace/augment expensive helicopters) and for this we are working together with the Solent coast guard. We are also exploring other case studies with the Met Office, BBC, and others.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Designing Unmanned Aerial Vehicles with Python<br />Dirk Gorissen (@elazungu)<br />-<br />PyCon UK<br />-<br />25 September 2011<br />
  2. 2. Outline<br />Who are we<br />Project focus & scope<br />UAV design system<br />Other uses of Python<br />Status / Open isues<br />
  3. 3. Who are we?<br />
  4. 4. What do we do?<br />
  5. 5. DECODE Project team<br /><ul><li>PhD Students:
  6. 6. Jeroen van Schaik
  7. 7. Mario Ferraro
  8. 8. Marc Bolinches
  9. 9. Ben Schumann
  10. 10. Associated:
  11. 11. Alex Forrester
  12. 12. Ivan Vouchkov</li></ul>Professors:<br />Jim Scanlan<br />Andy Keane<br />Kenji Takeda<br />Post doc:<br />Erika Quaranta<br />Dirk Gorissen<br />
  13. 13. The DECODE Project<br />Looking at how complex aerospace systems are designed<br />In particular, the decision making process related to the design<br />How are decisions made?<br />Who makes them?<br />How final are the?<br />How arbitrary are they?<br />How important are they?<br />Are they recorded?<br />…<br />
  14. 14. Design decisions<br />Important to rationalize decisions<br />Motivate them during design review meetings<br />However,<br />Design of something is never “finished”<br />Time pressure leads to arbitrary detail decisions<br />No immediate payoff for recording rationale<br />
  15. 15. Making decisions<br />Which ones matter?<br />Heatmap?<br />
  16. 16. Making decisions<br />
  17. 17. DECODE System<br />A computer system to help understand the impact of a decision<br />“Is it worth it?”<br />
  18. 18. Case Study: UAVs<br />UAV: Unmanned Aerial Vehicles<br />Mostly for military use but many civilian applications<br />Mapping/surveying, atmospheric measurements, search and rescue, wildlife management, … <br />
  19. 19. UAVs: Why?<br />Complex enough to be taken seriously<br />‘Simple’ enough to be tackled within a university research project<br />We can go through the full lifecycle<br />Design -> build -> fly -> crash!<br />Necessary to appreciate the impact and constraints of decisions<br />
  20. 20. UAVs: Why?<br />Its cool <br />Great for students<br />
  21. 21. UAVs<br />
  22. 22. Wind tunnel<br />
  23. 23. The ‘U’ in UAV<br />Sky Circuits Autopilot<br />
  24. 24. Autopilot telemetry<br />
  25. 25. Auto-takeoff<br />
  26. 26. The DECODE Project<br />Looking at how complex aerospace systems are designed<br />£800,000 government grant (your money)<br />
  27. 27. Case study:<br />Search and Rescue<br />
  28. 28. Search and Resuce<br />The RLNI has to come look for you<br />Helicopter costs £21 million and £6000 per hour<br />Lifeboat costs £150,000 and £8000 per hour<br />
  29. 29. Search and Rescue: UAVs<br />Design low cost UAVs for search and rescue<br />UAV costs < £10,000, and< £100 per hour<br />Deploy to RNLI stations<br />Reduce load on helicopters and lifeboats<br />
  30. 30. Designing a S&R UAV<br />What does a Search and Resuce UAV look like?<br />How big, how heavy, how fast, …<br />Decisions guided by an operational simulation<br />
  31. 31. DECODE System<br />How many more lives can we save by reducing the wing span by 15% ?<br />“Is it worth it?”<br />
  32. 32. System building blocks<br />Manufacturing<br />
  33. 33. System Requirements<br />Support wide range of analysis codes<br />Aerodynamics, structures, weights, costing, opsim, …<br />Very slow (CFD) -> very fast (costing)<br />Flexibility to add new solvers/codes<br />Provenance<br />Multi-client<br />Cluster/cloud capable<br />Make different MDO models possible (sync & async)<br />
  34. 34. System components<br />Lightweight component for each building block<br />Written in Python (using Kombu)<br />Any client with a an AMQP implementation will work<br />Minimal (shared) state<br />Each component<br />‘talks’ protobuf over AMQP<br />Input queue: shared with peers (failover)<br />Direct queue: exclusive<br />Respects reply-to header<br />
  35. 35. Messaging<br />Multiple control flows between components<br />Farmer-worker, sync MDO, async MDO<br />RabbitMQ as message broker<br />Persistent messages/queues<br />Acknowledgements<br />Pubsub<br />Virtual hosts<br />Clustering<br />
  36. 36. Registry<br /><ul><li>Ideally each component is stateless but some state cannot be avoided (e.g., during optimization)</li></ul>We also want transparent failover between components<br />Also need a registry for the components themselves<br />Which components are running/available<br />Analysis components need to publish their inputs (& outputs) <br />Redis:<br />open source, fault tolerant data structure server<br />
  37. 37. Control Flow<br />API<br />Controller<br />Balancer<br />Analysis Manager<br />API<br />Message Broker<br />Registry<br />CFD<br />Costing<br />Value<br />Opsim<br />Balancing<br />code<br />
  38. 38. Message based system<br />Strengths:<br />De-coupled & asynchronous<br />Flexible, easy to add new solver/components<br />Fault tolerant<br />Horizontally scalable<br />Platform/language independent<br />Weaknesses:<br />Enforcing synchronous, sequential behaviour<br />Detecting the fact that nobody replies<br />vs “fire-and-forget”<br />Recalling requests<br />Shared state implies race conditions<br />Broker model vs P2P model<br />
  39. 39. Deployment<br />Decode VM<br />API<br />Controller<br />Balancer<br />Analysis Manager<br />API<br />Message Broker<br />Spitfire<br />Jeroens PC<br />Registry<br />Marcs PC<br />Costing<br />FP<br />Balancing<br />Code<br />CFD<br />Opsim<br />Value<br />Iridis<br />
  40. 40. Deployment<br />Very easy to add/remove components at any time<br />System should cope<br />Side effect: difficult to force a job to run on your machine<br />Proof of principle:<br />PC joins the Decode system on screensaver start<br />
  41. 41. Clients<br />Client requirements:<br />Able to send a protobuf message over AMQP<br />Covers C++, Java, C#, Python, Ruby<br />Clients<br />API client (Python, Java, C#)<br />Matlab client (uses Java API)<br />Excel addin (uses C# API)<br />
  42. 42. Matlab Client<br />
  43. 43. Excel client<br />
  44. 44. More Python: ANSYS<br />Python also used in ANSYS workbench<br />Automate geometry, meshing, CFD analysis<br />
  45. 45. More Python: Sizing<br />Balancing component implemented in Excel<br />Well known, flexible, easy to work with<br />Not a concept design tool, tied to Windows, a pain to distribute<br />Use Python to compile a spreadsheet to standalone Python code<br />
  46. 46. More Python: Sizing<br />Exploring the sizing equations with NetworkX, Gephi & Neo4J<br />
  47. 47. Open issues<br />Deal with requests that never return & query cancelling<br />Add web UI to components (Flask?)<br />Deployment container?<br />Analysis cache<br />Explore possibilities of sizing graph<br />Data management layer<br />Archiving result data in digital repo (e.g., Fedora Commons)<br />Link to manufacturing<br />
  48. 48. Building UAVs<br />Focus on rapid manufacturing, 3D printing<br />cheap, fast<br />complexity comes for ‘free’<br />cool <br />
  49. 49. SULSA<br />Worlds first (?) 3D printed aircraft<br />
  50. 50. SULSA<br />
  51. 51. Project status<br />Halfway through building the system & starting design on second DECODE UAV (20 kg)<br />Special course on Unmanned Systems starting this year<br />Students will use & extend the system<br />Interest from the BBC, Police, Met Office, and US Navy<br />
  52. 52. Questions?<br />