Search and Resuce with UAVs, Worth it?

I gave an overview of the research I’m involved in in a previous post. In a nutshell its about looking at an agile design process for UAVs in the context of Search And Rescue (SAR) missions.

Part of the research involved building a detailed operational simulation model of the Solent area on the South coast of the UK. This simulation model is seeded with historical SAR incident information, weather patterns, as well as the locations of coast guard/RNLI stations & their capabilities. By running the simulation we can then analyze the spatial and temporal distribution of incidents, what the response times are, how often helicopters & lifeboats are needed, etc.

Continue reading

Another successful UAV flight test

One of the greatest things about this job is that a couple times every year we head out to the airfield and test if the aircraft (a UAV) we have been working on will fly.  Below two videos shot a couple of days ago. The civilian mission it will be used for is still hush-hush but it flew beautifully 🙂

Note the gimbal camera under the nose (orange dome) which can automatically lock onto a given object while flying.

–Dirk

TEAtime

A few months ago an email was sent out to all researchers here at the university to solicit volunteers to give lectures/workshops for visiting secondary schools, the TEAtime lectures.  As I always enjoy this kind of outreach I volunteered, went through some info sessions and did my lecture yesterday.  Basically I gave an overview of UAV technology and did a simplified walk through of the aircraft design process.  It was a bit ironic though, a computer scientist explaining airflow and aerodynamics :).  No slides on slideshare as they’re too big to upload and Im to cheap to pay for PRO :).

Continue reading

Using Javaprop in .net

JavaProp is tool for designing and analyzing propellers.  From the website:

JavaProp is a relatively simple program, which is based on the blade element theory. The blade is divided into small sections, which are handled independently from each other. Each segment has a chord and a blade angle and associated airfoil characteristics. The theory makes no provision for three dimensional effects, like sweep angle or cross flow. But it is able to find the additional axial and circumferential velocity added to the incoming flow by each blade segment. This additional velocity results in an acceleration of the flow and thus thrust. Usually this simplified model works very well, when the power and thrust loading of the propeller (power per disk area) is relatively small, as it is the case for most aircraft propellers.

It comes in the form of an applet that you can use through the website or as a jar file that you can link into your application.  While it seems like a small and simple program its actually quite powerful and get you a long way towards picking/sizing a propeller for your aircraft.

At some point there was the idea to integrate into Excel as a plugin that would link into our sizing equations.  Turns out that writing a java plugin for excel is actually a rather messy business and I really did not want to go down that route.  Instead I had the idea of trying to convert the java bytecode to bytecode that runs on the CLR.  This would make things a lot easier as the excel plugin can be written in C#, using all the bells and whistles that visual studio gives you.

Some googling led me to IKVM and I have to say I was very pleasently surprised. I was expecting lots of strange errors but everything worked smoothly and out of the box.  It generated a dll which I could test on linux using mono as well as with Visual Studio on Windows. The excel plugin never materialized however, since the control flow JavaProp assumed did not match the flow used in our sizing equations but it was still fun to mess around with.  In case anybody wants to do the same simply downlad the JavaProp jar as well as the mhclasses dependency and use the following ikvm command to convert it to a dll:

ikvmc -target:library javaprop.jar mhclasses.jar

To include it in a .Net application you just have to make sure you also add the reference to IKVM.OpenJDK.Core.dll.

–Dirk

Imperial College Robotics Society Talk

I meant to post this some time ago but craziness at work and an overdose of family during the festive period intervened.

Anyway, mid December I did a talk of our UAV work at the Imperial College Robotics society.  I had met Harry Eakins, founder and current president, at the last pyconuk conference in Coventry & he invited me to give a similar talk at Imperial.

As usual, the slides are available on slideshare:

“Click here” to build your UAV

View more presentations from dgorissen

In all I found it a great experience.  I tried to give a broad overview of the UAV related activity at the university as well as focus more on our research around DECODE.  Got a good audience with some great discussion during the reception afterwards.

On arrival I got a tour of their hackerspace and it was great seeing people hacking and soldering away on various projects, ranging from quadcopters to a robotic dustbin.  Thinking back to my university days I always regret not having gotten involved more in such things or set them up if they did not exist.  There are so many cool things you could do and the technology & kit is very accessible.  These days my tinker time is very limited but Im optimistic in that will change 🙂

–Dirk

“Click here” to design and build your UAV

This blog post summarizes the work I have been doing the past 8 months or so on an automated design system for (civillian) UAVs.  Ive been meaning to do this post for a long time but wanted the tools to be in a beta quality state before writing about them.  In good software engineering tradition there have been a few hiccups and detours along the way but Im happy to say beta stage has been reached.

I will go over the vision behind the system, its architecture, and the various tools I have used to put it together.  For the impatient, this is the idea: we need a system that allows us to rapidly go through this process:

Agile UAV design if you want to call it that. Tools I will talk about include PythonNumpy, RabbitMQ, Redis, Flask, Django, Bootstrap,  Knockout.jsVagrant and how they link up with application specific codes such as Ansys Fluent, SolidWorks, Vanguard and Anylogic.

This post is an extension of the talk I gave at PyConUK 2011 a couple of months ago and is also what I will cover in my upcoming talk at Imperial College and at the upcoming AIAA conference in Honolulu in April 2012.

Continue reading

Pycel: Compiling Excel spreadsheets to Python and making pretty pictures

Background

As described in my previous post, my job is to assemble a software suite that is used by aerospace engineers to design civillian UAVs.  Our main use case being search and rescue.

Every aircraft design starts its life in a concept tool where the configuration choice (V-tail, canard, flying wing, …) is made and where the principal geometrical parameters (wing area, CoG, tail volume, …)  are decided.  This then allows the calculation of the approximate weight and performance of the aircraft (e.g., maximum speed, range, endurance, …).

While this concept stage is only a rough approximation it already involves (in our case) some 250 variables which are interlinked in a complex web of equations.  These sizing equations capture a great deal of knowledge about the physics of flying an aircraft as well as empirical relationships drawn from historical & experimental data.  Solving these equations is really a Multidisciplinary Design Optimization (MDO) problem, a whole field of research in its own right.

After working with the Pacelab Suite for a year we have (for various reasons) switched to spreadsheets for implementing & experimenting with the sizing equations.   This brings great flexibility for the designer but makes things more tricky to parallelize & optimize for me.  For example, I cant just throw Excel on the 8000+ core linux cluster we have here.  Also, while the inbuilt solver plugin is easy and quick for solving small scale systems.  As our equation system got more complex the process just breaks down.

It was also clear that our sizing complexity had outgrown the spreadsheet UI and had become hard to understand for a newcomer.

Early experiments

Being a programmer I feel more at home manipulating code than manipulating spreadsheets.   Early on I had already experimented with visualizing the sizing logic by customizing and extending the Trace addin.  This resulted in images like this:

With some more graphviz magic you could add some structure by grouping related parameters:

And trace the impact of a particular parameter:

However, I soon ran into limitations of the static graphviz model and VBA (the language Trace is written in) is not the most happy place to be (to put it politely).

Python to the rescue

This work then lay dormant as I was sidetracked by other stuff.  However, with Pacelab being abandoned and the spreadsheet itch still being there I could not resist having a go at rewriting my own excel visualization library and throwing in some compilation for good measure.  The goal being to:

  • Allow better visualization and exploration of the sizing equations, to understand how variables influence each other
  • Compile the spreadsheet into code that can be manipulated, transformed and executed independently from excel.

There are already a number of commercial tools for compiling spreadsheets but I did not find an open source library which did what I needed.  And anyways, I did not want to look too hard since it would be something fun to do myself.  Why python? Its the language I was using at the time and one I particularly enjoy.

Piecing things together

A core problem in making all of this work is tokenizing an excel formula properly. Luckily this had already been solved and after a small patch to the python port that was working. Throw in shunting yard, the conversion to an AST, and I was ready to emit code.  For example:

Formula:  =3 + 4 * 2 / ( 1 - 5 ) ^ 2 ^ 3
RPN:  3|4|2|*|1|5|-|2|^|3|^|/|+
Python code:  3+((4*2)/(((1-5)**2)**3))

or

Formula:  =If(SUM(A1:A5) > 0, sin(0.3), ln(2.5))
RPN:  A1:A5|SUM|0|>|0.3|sin|2.5|ln|If
Python code:  sin(0.3) if xsum(eval_range("A1:A5"))>0 else xlog(2.5)

As you can see this means mapping excel functions/operators onto python ones and adding python equivalents where necessary.

Dependency tracking

Besides the issue of function mapping there is the issue of dependency tracking when updating cells.  So if A1 contains the formula B1 + 5 then you need to be aware of this dependency and update A1 whenever B1 changes.  For this I used a graph as the base data model as it is most intuitive.  Thanks to pythons networkx this was very easy to do.

The final result is a small python library that:

  • takes an excel spreadsheet & one or more seed cells
  • follows the dependency graph, starting from the seeds
  • generates a graph where each node is a cell or range and contains the python equivalent of the excel formula

This graph can then be serialized to disk and run independently of Excel (e.g., on linux).  Caching and lazy evaluation ensures the calculation and update process is relatively fast.  I have tested extensively with a spreadsheet with multiple sheets and over 1000 formulae.  Full calculation times are around 50ms which is plenty fast for our application.  Also, I can now run multiple instances in parallel, something that was virtually impossible to do by orchestrating Excel via Pthon over COM (yes I know there is solution from Microsoft for running Excel on a cluster but I did just not want to go there).

Pretty pictures

This means its now time for an intermezzo with some pretty pictures, courtesy of Gephi. The node color is determined by the worksheet the node comes from and the size of a node is determined by how many cells it depends on.  Ever think an aircraft design problem could look pretty? 🙂

Using some layout algorithms you can start pulling things apart:

And look at the macroscopic structure:

Or zoom in for the microscopic structure:

Here the colors represent which variable group the node belongs to. Stripping out things further you can look at one particular variable, for example the wing area, and see how it influences others:

Finally, optimization

Ok, so I could now serialize an excel spreadsheet to a python graph.  However, the ultimate goal is to build an aircraft that can actually fly, or in aero speak, it is balanced (lift equals the weight, center of gravity is in the right place, etc.)  This still involves an optimization process which now had to be done in Python.  For this I added an extra layer on top of the compilation process using OpenOpt.  After some bugfixing and testing I am happy to report that, without doing anything fancy, it solves in 98% of the time and takes 30 seconds to 1 minute to solve.  Compared with the original 65% and 10 minutes.

As a sanity check I then did some parameter sweeps to generate surface plots such as these:

Roughly this plot tells you that as you increase the payload weight and the importance of a low landing speed, your dry weight (the weight without fuel) goes up.  Which is exactly as you would expect (ignore the ridge at the bottom left).

Where is the code?

My employer has been kind enough to let me release the code which is now available on github!  An example is included and the readme lists the pro’s and con’s of the current functionality.  May the patches roll in 🙂

Thoughts and Future work

So far this has been an interesting little side project and been very useful in the wider design system.  Recall from my previous post that this is just one small piece in the puzzle.  In the wider system this is linked up with CFD simulations, costing codes, an operational model and what have you.  One disadvantage of spreadsheets, though, is that designers tend to use large tables to interpolate out equations instead of writing a few lines of code.  This can add large numbers of nodes/edges to the graph, thus increasing the visual complexity, without adding much to the true problem complexity.

I think there is potential to explore this topic further, but this would really need an application specific layer on top of a graph-only tool like gephi.  However, it does not look like this is where my priorities will lay, but maybe it will inspire somebody else 🙂

There is a good chance I will be revisiting this type of work when we look at visualizing design rationale data and how it evolves during the aircraft design process.  But that is a separate topic for a separate post 🙂

Thoughts, comments, suggestions, constructive criticism, patches? Dont be shy!

–Dirk