Background

Designing our UAVs involves a number of different codes that interact & must be coordinated to solve what is essentially a Multidisciplinary Design Optimization (MDO) problem.  One of those codes is written in Python and involves a constrained optimization problem of the following kind:

Find the minimum of a problem specified by

x, b, beq, lb, and ub are vectors, A and Aeq are matrices, c(x) and ceq(x) are functions that return vectors, and f(x) is a function that returns a scalar. f(x), c(x), and ceq(x) can be nonlinear functions.

In our case we have 10 variables (x has length 10), 28 nonlinear constraint functions c(x), 4 nonlinear equality constraint functions ceq(x) and box constraints on most variables.  The objective function f(x) and all constraint functions are pure python functions.

Thus to optimize f(x) you need an optimizer that can handle python functions, and for that there is the excellent openopt library.  This is what I did and after trying out the different NLP solvers I settled on the scipy_slsqp solver for most runs as it seemed to consistently give the best results.

However, as the optimization problem was tweaked and as we did more runs, we did run into cases where it would not solve and the aeronautical engineers I work with were not always happy with its robustness.  Also nobody had ever worked with the openopt library but everybody knew and trusted the various Matlab solvers.  Besides, us being part of the Computational Engineering Design Group, a number of powerful in-house Matlab solvers had been developed and were available to me.  Thus, the least I could do was to try to use those and see if that improved anything.

Python-Matlab bridge

So I started searching the web for tools / libraries that allowed me to bridge python/Matlab, specifically tools that supported passing callbacks between the two languages.  A promising project seemed mlabwrap but while it was great for evaluating Matlab expressions,  it does (at the time of writing) not support callbacks.

In the end I decided to see if I could scratch my own itch.  I really did not want to deal with sockets or any kind of network protocol and I also wanted the solution to be crossplatform, so no COM.  Since both Python and Matlab have well documented interfaces with C/C++ code, that seemed to be the way to go.

So I sat down with the ctypes & mex documentation and with a little help from Mathworks support was able to cobble together a simple example using fminsearch.  By the way, I had never done any Python – C work before, but ctypes is awesome and a joy to use.  The little trick to make it all work is that you just have to treat the function handle as an integer (it’s just a memory address after all).  Then all you are really doing is passing an integer around which is straightforward.

With fminsearch working the goal was to extend to fmincon since that would give us all the basic functionality needed.  This took a bit of debugging and deciphering Matlab crash dumps but I finally got it working.  The final flow of events looks like this:

You start off with writing a matlab file that wraps the optimizer you are interested in (in this case fmincon) and exposes its signature.  This m file forwards all function handle arguments to a mex file which converts the integer to a function pointer and calls it.  This is how we get the callback to a C function.  A simple bridge library is then needed which is loaded by ctypes and converts the arguments into something the Matlab shared library file understands.

From my initial tests I see it is finding the same optima as scipy_slsqp was using openopt. Now I just need to do more extensive testing to see if performance is any more robust. After that I can start looking into the other solvers provided by Matlabs optimization toolboxes as well as our own solvers.

Source code

All the code is available on github.  I hope it is useful to somebody and I’d be very happy to receive patches or improvements.  I guess this may even be of use to the mlabwrap / openopt projects.

–Dirk

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

At some point in life everybody reaches a stage where they have to decide what do with their professional, i.e., working, life. Some have it figured out during high school: they know what they want to do, they have a passion, and they pursue it head first. Others only really figure out what they want to do by the time they retire, yet others meander from goal to goal and never really settle on something. Baz Luhrmann’s song “Wear Sunscreen” comes to mind:

Don’t feel guilty if you don’t know what you want to do with your life…

the most interesting people I know didn’t know at 22 what they wanted to do with their lives,

some of the most interesting 40 year olds I know still don’t.

As with most things in life there really is no right or wrong answer, each brings its benefits and challenges.

This blog post is a personal reflection on this issue. Why post it publicly? Well, it forces you to think about the question in a coherent way, vs just scribbling some notes down on a piece of paper. Also, judging from the google results it’s a question many people grapple with. Sharing my thoughts may help somebody else think about theirs and, ideally, trigger some dialogue. In my case it was reading Paul Graham’s excellent essay on doing what you love that gave me the final push.

What makes you happy?

I recently had another of these episodes where you take a step back and think “Do I like doing what I do? Will I still enjoy this 10 years down the line? Am I helping make the world a better place? Are there completely different things out there that I may want to do?”.

It was triggered by the fact that my contract for my current research project expires within a year. While I have the luxury of not worrying too much about becoming jobless, I did feel that, if I wanted to change something, then would be the time to do it, and now would be the time to think about it. Having recently become a dad and experiencing the responsibility that brings only strengthened that feeling. After all, I’m lucky to live in a prosperous part of world with many opportunities available to me. At the very least its something you should appreciate and reflect on instead of wandering through life on autopilot.

So I thought about the different things I could do in the future and tried to imagine how that would make me feel and how it would impact my personal & family life. It turned out I found that rather difficult, it quickly boils down to the fundamental question: What do you want?. Solve that and it’s just a matter of connecting the dots. I found it easier to rephrase the question by making the reasonable assumption that what you want is whatever makes you happy. So then, what makes you happy?. Still a tricky question as there are so many variables involved, but easier to think about. There has been plenty of research into what constitutes happiness & what makes people happy but that is a can of worms I’d rather avoid. At the end of the day its a question you, yourself have to answer. Knowing which boundary conditions tend to make people happier on average may be useful but not very satisfying or specific.

A useful side effect of looking at things from the perspective of happiness is that it should also give you a good indication of what you are good at. Since it’s generally unlikely that doing something you suck at makes you happy. (Note: recall that I’m focusing on the professional and occupational instead of more personal and physical aspects like health, love, friends, etc.)

From interpolation to Extrapolation

While that made things more concrete, I still found it quite difficult to think about the present moment and try to extrapolate to the future while weighing different options. Instead, I figured I would get a more objective, meaningful answer of what made me happy if I looked at the past, particularly during childhood. When you were a child, most of what you would do just came naturally, you didn’t worry whether it would pay off or could support your family. I find that, in my case, as you get older your decisions and actions come more from the brain than from the heart. Often with good reason, since as you gain responsibility and find your place within society you have to make more compromises. So instead of trying to extrapolate directly from the present into the future. I figured I should first interpolate over the past, discern one or more trends, and only then think about how they may shape the future or if I should ignore them and do a 180.

So I sat down and mentally thought about the decisions I made in the past and what I liked to spend my time on. Starting from my very earliest childhood memories up to now, writing things down as I went along. If you do this it’s very important just to stick to basic facts, and not try to infer anything, just think back to concrete things you liked doing and remembering which decisions you made and why. Only when you feel you have listed everything you can think of can you start going through your list to see if there are any common themes.

In my case I discovered the following recurring themes:

Science/Technology: I vividly remember having “The Giant Book of Facts” as my bible when I was around 8 as well as playing with a chemistry set I got for christmas, having an interest in astronomy, and becoming a big fan of PMI which was offered as an afternoon activity at some point. I also really enjoyed putting all kinds of random things under a microscope. Later this morphed into some, shall we say, “creative chemistry” in high school (for which I got into quite a lot of trouble actually) and an interest in computers/programming. The progression into computer science at university was only natural.

A subtheme here was that I always preferred building stuff or making stuff versus thinking or theorizing. I never was that good at mathematical puzzles or the more abstract stuff (like infinite Hilbert spaces & ring theory) we got at uni. In that sense I sympathize with this blogger and always felt more like an engineer than a scientist, particularly fascinated by things that could fly or float. This also motivated my topic choices for my masters and PhD theses later on.

Nature: A second trend I discerned was one related to nature and the environment. From a very young age I always enjoyed being outside, taking walks in the forest & exploring the hills behind our house on my own. The fact that I was lucky to spend my childhood growing up around east Africa probably played a big role here. As I got older this evolved into camping trips & traveling to places where you could still venture into the bush or mountains. Even now I still love picking a random hill or mountain and trying to get to the top, whether there is a path or not.

A subtheme here was a particular interest in marine & aquatic life. I could (and still can) spend hours snorkeling or pottering about rocky pools at low tide and was an active SCUBA diver for many years.

Sports/Teaching: most of my childhood was spent in British international schools where you had classes until 1pm and a range of activities to choose from in the afternoons. I always enjoyed sports and tried a lot of things over the years. From javelin to cricket, badminton and orienteering. I was on the swimming, soccer, & basketball teams in high school and ventured into squash and martial arts over my university years. Looking back I always was a good all-rounder without excelling in anything in particular.

The subtheme here was that I also enjoyed coaching & teaching. Not only in sports (two friends and I coached the junior school basketball team for a year at some point) but also in class & by helping out younger cousins with private lessons during my uni days. I ended up going through the teachers training program and really enjoyed the interaction with high school students during my internships. These days I still participate in outreach activities whenever I can, such as explaining the research we are doing to high school students or pensioners.

On the whole I have always been more of a “jack of all trades” than a “master of one”. Preferring to engage in different activities & disciplines, instead of going all the way in one. I always found that double-edged sword. Sometimes you feel like you know a great deal, other times you realize you don’t really know anything. I was therefore happy to read in Mark Glen’s blog about Becoming Great that there is still good value in flexibility.
Secondly, I have always favoured pragmatism & solving real problems, over speculative theorizing and always like to keep my options open. I did the Myers-Briggs Type Indicator test some time ago and it tells me I am an ENTJ, which does not seem too far off base.

Reflecting on the above gives me a very good indication of what ingredients my perfect job should have: (1) multidisciplinary, (2) engineering: building stuff that has a connection with the physical world (vs writing financial software), (2) a connection to the environment and (3) a social dimension (outreach, teaching, …).

Interestingly, my current position as a research fellow already ticks quit a few of the boxes: I’m part of a multidisciplinary team in a University research group that designs and builds UAVs for civilian & scientific missions (search and rescue, atmospheric measurements, etc.).

So where is the problem then?

Thoughts on being an academic

In many ways doing research at a university is the perfect job. The flexibility of managing your time and work rhythm is second to none, you get to attend conferences all over the globe & you have pretty much total control over what you want to work on. In addition, the fact that you are surrounded by very intelligent people helps to push yourself further. In my case, the work we do on UAVs is really nice since its very tangible & the first reaction of people is always “cool!”, even from Googlers (who are typically considered as working with cool tech/problems). We also have a great team & great professors leading it. My peers in industry may be earning more & driving a fancier car but have nowhere near the freedom and flexibility of university life. As you climb up the academic ladder things can get more bogged down it seems, but as of now, like I said, in many ways the perfect job.

So what’s the catch? Well if your ambition is to drive a big fancy car, you probably want to look outside academia. Pay scales are and your progression through them is typically a very controlled process and you can pretty much lookup how much you will earn in X years time. Personally, I think one of my main gripes with working in academia is the obsession with papers. I’ve written many papers that I know nobody will read (sometimes it seems you would even be lucky if the reviewers read them) and I’ve read many papers that add little value but manage to get published anyway. You could argue that you should focus on high quality journals and conferences where the quality is higher so you don’t have that problem. However, writing really good papers which contain a significant contribution & get cited often is hard and something few can pull off consistently. From my experience and what I have been told by others is that as much as quality is important you may not neglect quantity. For every good paper you typically have several papers which are just variations of the same theme, the same techniques applied to a different problem, etc. And it is these papers that I hate writing. Sure, the fact that it is essentially a ticket to a nice conference where you can do some networking helps, but considering how much money it costs to register and attend the conference, I often doubt if the contribution is really worth it.

Secondly, it always annoyed me somewhat that there is generally little academic value in actually building stuff. You could put together a wonderful piece of software that is used by 100s or 1000s of people around the globe or build a beautiful, high performant aircraft that helps climate scientists do observations, but if you can’t monetize it in the form of publications it adds little to your academic track record. This of course brings us to the traditional tension between applied and basic research and you could argue that it is the university’s job to focus on the research side and for industry to focus on the monetization and application. Anyways, this is a whole debate in its own right and one I’m not going to get into here. I guess all I’m really saying is that it would be nice if the fact you actually built/created something that is actively being used counted as much as, say, a good journal paper. For actually putting your money where your mouth is by building something that others can use & test, vs merely describing results or an algorithm in a paper, is not as trivial as you might think at first.

Sidenote: Just to be clear, this is not a rant on academia, merely quibbles I have going through the system (which depends on your discipline).  While the whole scientific process of papers & peer review has its inefficiencies and criticisms, it still is a great process which has brought us many great advances. It’s not like I have a 20 year track record in academia so what do I know? I encourage you to share your constructive thoughts in the comments section

Looking forward

Having done some thinking on what I like doing I have pinned down what aspects I am looking for professionally. It has also been a good exercise in reflection, understanding past decisions and visualizing a path onwards.

For now Im very happy with what I am doing and how things are going. While I recently got an offer to work for an established startup company I decided to stay at university for now (for various reasons). I have become more conscious, though, about how I spend my time and still plan to keep my options open. This is actually one of the reasons why I started blogging and joined twitter. I also started following various podcasts & blogs more consistently, as well as keeping track of interesting books and articles that refresh computer science fundamentals or give insightful commentary on new tools, techniques and languages.

Where family life allows it I try to attend hackathons, coding dojo’s, and other networking events where possible as they provide a great way to learn new things, meet new people, and benchmark your skills. I also find it interesting to talk to recruiters and companies at career fairs or other events. If you are not actively looking for a job these discussions are very informal and a great way to hear first hand “what’s out there”.

On the academic side I have decided to have a good think about what kind of project proposals/papers I could write that bring me closer to industry and “building stuff that people use and does not end with ‘just’ a publication”. Some ideas floating around, we’ll see where it leads. As long as I feel I’m learning new stuff and pushing my boundaries I should be ok.

Additionally I plan to continue to volunteer for outreach activities where time allows. Engineers Without Borders no longer have a branch in Southampton and I think it would be great fun (and a great challenge!) to set one up and organize some events. Similarly I have been involved with a couple of open source projects that arose from the hackathons I attended. It would be great to contribute more to them as well. However, I have to be very realistic about my available time. I still have my daily project work as well as a family and house to DIY, so my tinker time is severely limited.

In sum, while this whole process hasn’t given me a concrete destination, it has provided a good bearing that I can reevaluate in a years time. This is all you should expect really, one of my favorite quotes is still: “If you want to make God laugh, tell him about your plans for the future“.

Finally, remember to be aware that this whole thought process is an incredible luxury and very selfish in a way. We have the freedom of doing this exercise, many on this planet do not. Which should make you think: how can I help change that?

–Dirk

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:

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 Python, Numpy, RabbitMQ, Redis, Flask, Django, Bootstrap,  Knockout.js, Vagrant 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.

Background & vision

The system I going to talk about came about as part of the EPSRC funded DECODE project here at the University of Southampton aerospace department. Many things were promised in the project proposal but the fundamental vision is phrased like this.

DECODE addresses the design and integration of complex systems such where the problems of cost overruns, delays and performance shortfalls are particularly acute. The current value of an aerospace prime contract is now typically measured in £ Billions, yet surprisingly, many companies still use relatively traditional, ad-hoc and organic processes and design tools within their programmes.

The research to be undertaken under DECODE will investigate design decision making tools that provide holistic optimisation at a system level to maximise satisfaction of all the stakeholders associated with the system. Uniquely DECODE will provide active design exploration of systems level trade-offs between performance, unit cost and system life-cycle costs based on a “design mission control capability” .
To do this an innovative design decision support environment that focuses on Value metrics is being built. This will allow a Value-Driven “mission control capability” for design decision making to be researched. It will integrate early concept design exploration with full resolution, geometry backed design computations and detailed manufacturing and operations models.

So lets look what this means in a more practical sense. The traditional decision making process in aerospace design projects is that a group of engineers representing the different subsystems/domains sit together in a room and fire off powerpoint presentations and excel spreadsheets until consensus is reached.

The vision we are aiming for here is that you still put the same people in the same room, but you give them a flexible environment that they can query in real time and will allow them/give them access to:

1. Design rationale: quickly pull up the design rationale maps and drill down to the evidence behind a certain decision. For example: the rationale behind the decision to use a particular airfoil section may link to mission specification documents and CFD analysis.
2. Live geometry: its much easier to debate the merits of a particular design decision (e.g., the need for structural reinforcement around the landing gear mounting) if you can easily pull up the relevant CAD geometry and manipulate in real time
3. Probe the design & its performance in real time: engineers are able to vary the parameters of the design & get direct feedback on how they impact performance. They can opt for a rough answer now or an accurate later (e.g., over lunch, or over night). For example, What if we decrease the wing span by 10%?
4. Find out the value of a particular design choice: Essentially you want to answer the question “Is it worth it?”. We know a 10% increase of wing span will add to the weight/cost, allow us to land slower, etc. But is it worth it?

Its this last point that is the main novelty of the DECODE project, though its also the most crucial to get right. Answering the “is it worth it?” question depends on the mission and thus depends on a trustworthy operational simulation and realistic value model.

Together this is quite an ambitious vision and requires a sizeable amount of architecting and software engineering to get right. There are about 7 people on the team, each responsible for different domain specific components that are plugged into the system. The team responsible for actually building the system and linking everything together is…err…me

With about 18 months left on the project I doubt we will get all the way there. But we should definately have proved that you can get something working.  For the rest of the post I plan to focus more on the software system side of things.  I could talk at length about each of the 4 points above but that would lead us too far.

Unmanned Aerial Vehicle’s (UAVs)

The vision outlined above is very generic, it could apply to designing space shuttles or Volkswagen Polo’s. The focus of the project has been to use UAVs as the main use case.   Mainly because there is a lot of very cool and relevant technology around UAVs (like  Quadcopter ping pong) but also since they are complex enough to be taken seriously as an application but simple enough to designed and built within a year with a university research group budget. Not to mention they are a great way to teach students about complex systems design.  We are a university after all.

So far our group has focused on sub 25kg fixed wing UAVs.  As soon as you go above 25kg the certification and authorization issues become hairy.  Other groups at the university & NOC are working with Quadcopters and Autonomous Underwater Vehicles. Some of the aircraft we have designed and flown are:

The autopilot we use was developed at the NOC by one of our team members who has recently setup a separate company.

Making decisions

Given UAVs as the main use case the task of the Decode system is to help decide which UAV should be built and discrimintate between alternatives.  There are a bewildering number of decisions that have to be made when building a system like a UAV, ranging from obvious configuration choices (do we need an undercarriage?) to more obscure one like do we need square or round section tail booms.  Which ones are the important ones, which ones don’t matter, which ones are critical, etc.  The color of the paint you use may not seem like something important, but depending on the mission and flight conditions, it may very well be. This is a topic one of my colleagues is delving into and one which Im involved in from the sidelines.  The following figure illustrates the different geometry related decision variables on one of our airframes.

At heart this is really a multidisciplinary design optimization (MDO) problem that revolves around solving conflicting requirements.  The following cartoon illustrating the tensions between requirements is a classic:

Similar tensions exist when building software, the memory-speed trade being the obvious one.  Luckily, in the engineering world, there are powerful mathematical techniques that can help you solve this trade-off and find an optimum.  A luxury that the software world, as far as I am aware, does not have.

Dropping bombs vs saving lives

As soon as you say UAV or drone people immediately think of Predator type aircraft and have visions of souless robots dropping bombs on civilians & all things Orwellian.  This is (rightfully) a controversial topic and one I’m not going to get into.  I would not feel comfortable working on military applications so I am very happy that all our work focuses on the civilian applications of UAVs.  As with any bit of science or technology UAVs can, and are, used for military & law enforcement applications but people often don’t realize how many civilian applications there are.  And this market is only growing.

The focus of DECODE is the use of UAV for search and rescue missions.  Using a helicopter to search for individuals lost at sea or in the mountains is extremely expensive, costing thousands of pounds per hour.  A fleet of UAVs should drastically be able to reduce the price and search time.  Not replacing helicopters and lifeboats, but complementing them.

As part of this we developed a detailed operational simulation model of the coast around Southampton (though it can be applied to any area) using the Anylogic agent based simulator.  This can be used to simulate missions and get an idea of what kind of performance is needed from a UAV.  For example, it allows us to answer the question whether we are better off with 10 small, cheap UAVs, or 3 expensive, high performance UAVs.

But lets not get ahead of ourselves just yet.  The question we should ask ourselves at this stage is, what does a good search and rescue UAV look like?

System design drivers

Designing an efficient and performant UAV is a multidisciplinary undertaking, requiring codes, solvers, & expertise from varying domains.  The following figure illustrates the building blocks that are needed.

Coming up with a good UAV design requires exercising these blocks in concert for every design decision and assessing the impact of changes.  Some blocks may be very simple web service calls which complete in less than a second.  While other blocks require many hours of computing time on high performance clusters.  A system is needed to  orchestrate all this and can be driven by the designer in an intuitive fashion.

We can come up with a a number of requirements for such a software system:

• the system should be pluggable and support a wide range of components/solvers on any platform
• the system must be capable of running on high performance clusters, grids, and clouds
• multiple users should be able to drive the system simultaneously, asking questions such as
• How many more lives can we save if the wing span is 10% longer?
• What is the optimal propeller diameter?
• Should we use a canard?
• How does the parasitic drag vary with cruise speed?
• there must be a clear provenance record to track the flow of data through the system

Which brings us to a number of desirable design principles:

• de-coupled and asynchronous
• fault tolerant
• horizontally scalable
• cross platform and cross language
• support multiple workflows
• user friendly

Which, in turn, can help us think about a suitable architecture for the system….

System Architecture

I will not go into all the details but fundamentally the system follows a typical 3-tiered architecture.

At the bottom there is a data layer which holds all the data related to a particular UAV design & all the data generated as part of analyzing the design (e.g., CFD results, CAD geometry, …). This information is best stored in a proper data repository such as Fedora Commons or similar.

Above that is the orchestration layer which is tasked with implementing the business logic.  In this case coordinating between the different solvers & components in order to a  answer the various questions a designer has about the design.

Finally, there is the presentation layer which presents an intuitive user interface to the available workflows and the underlying data repositories.  There may be multiple client interfaces, at least one of them being a web based UI.

Orchestration layer

As most work so far has concentrated on the orchestration layer I shall primarily talk about it.  I chose to implement this layer as a series of lightweight & independent components which interact with each other in a fully asynchronous and message based manner.  This automatically gives us flexibility over how we implement each component, performance (no blocking calls) and horizontal scalability (multiple components can feed from the same message queue).

I chose  python as the main implementation language as it seemed like a nice high level language to do such things.  Also, I was only starting off with it and wanted to learn more.  As messaging protocol I selected AMQP, using RabbitMQ as the implmentation and broker. While not perfect, I liked the concepts of queues, exchanges, acknowledgements,  it was easy to setup, it seems to be quite widely used and it had good support among all major programming languages.  As message format I selected protocol buffers.  Again, good support among the major programming languages, easy to use, good documentation, and the type safety + utility methods it gives you over basic JSON come in handy at times.

A very important decision I made here was to avoid using a central database & data model that every component relies on & that I would have to keep in sync.  I wanted to have the individual components as lightweight and stateless as I could possibly have them.  (Note: Looking back at this it strikes me that what I essentially did was implement the Actor pattern).

However, the only problem was that, yes, in an ideal world everything is stateless, but in reality you need to keep track of certain things.  For example, each component executes a part of the overall workflow.  But if one component dies you dont want to have to start all over again, you would like to continue where you left off, or at least let one of your peers continue if you cant.  Especially with long, expensive, CFD solves you want to avoid doing things twice.  Secondly, from a user/debugging perspective you would like to keep track of which components are available and what each is doing.

So some kind of persistent state is needed, and for that I chose redis, an open source and high performance data structure server.  I use it both as a registry to store information on the available components (the EXPIRE command can be used to implement a heartbeat) and as a way to store simple state information.  Lightweight is the key here.  I still want to avoid any kind of central data model, redis only stores simple JSON dictionaries and the system will not break if state information is suddenly lost (though a particular job may fail to complete).

The following figure illustrates all the components in the system and the communication between them:

There are two types of components: relay components and analysis components.  Relay components (like the balancer and controller in the image) are responsible for the orchestration of analysis components, they implement the actual system logic.  Analysis components are less intelligent in that they essentially wrap a particular solver (e.g., Fluent for CFD or Vanguard for costing).  The balancing code is a bit of a special case since it acts like an analysis code but also plays an important role in the overall orchestration.  Together with the Balancer component it is responsible for  ensuring the aircraft is balanced, i.e., it is a feasible aircraft where lift = weight, the center of gravity is in the right place, etc. (Note: this is where the Excel -> Python compilation code I blogged about previously comes in).

Each component is thus a lightweight python process and has two queues at its disposal.  A direct input queue which is exclusive to that component, and an input queue which is shared between all components of the same type.  Each message received on either queue will be processed and returned to the component specified in the “reply-to” field of the message, so workflows are not hardwired.  A component also starts a small embedded HTTP server using flask, which gives you access to the local result directory and which I will probably use to add some simple monitoring and administration.

There can be an arbitrary number of instances of each component type running (horizontal scalability). Also, thanks to the semantics of AMQP acknowledgements, we can ensure we only acknowledge a message once we have successfully processed it and performed the next action in the overall workflow.  This leads to natural failover between different components.  To demonstrate components can really come and go as they please I wrote some proof of principle code linking the component lifetime with the local screensaver.

Architecture weaknesses

As with every solution, a decoupled, message based system also brings with it a number of weaknesses:

• Sometimes you may want synchronous, sequential behavior, emulating this in an asynchronous system is ugly
• Ideally you want to “fire-and-forget” but often you do want somebody to reply.  So you need to detect the fact that nobody replies which requires extra monitoring.
• Once you’ve sent out your messages you cannot simply recall them.  Cancelling an operation becomes tricky.
• As soon as you have some shared state you have to worry about race conditions and deadlock.  Something you cannot really avoid without using a distributed transaction manager like zookeeper.
• The RabbitMQ broker and, to a lesser degree, redis are still central points of failure.  Both have high availability features with failover and persistence but its not as clean and robust as using something like 0MQ for example.
• Loosely coupled systems are difficult to test since there are many moving parts.  You also have to beware of ending up in a message queue spaghetti.

So far none of these are a real problem, it will depend on how the project evolves to see if that changes.  In any case I have taken care to abstract the interactions with Redis and RabbitMQ in order to make any transition or change not too painful.

Clients

Almost all the interaction with the system is through the Controller component.  All it requires is a protobuf Query message, which is a simple message representing a system query.  Among other things it contains: inputs (constraints) to set, aircraft configuration to use, required fidelity level (quick answer now, or accurate answer later) and some other options.  You can then have different client libraries that interface with the controller, as long as they can produce a protobuf Query message and send it to an AMQP broker.

So far I have implemented three clients: a Matlab client (using the java API),

an Excel client (using the C# API),

and a web client (using the native python API) built with Django, jQuery, Kockout.js, and Bootstrap.  More about my experiences with this in a next blog post.

The Excel client is deprecated at the moment, though, as there seems to be little or no need for it.  It is quite cool to use though.  Simply drag down a formula with your mouse and kick of 100′s of number crunching jobs without even noticing.  The python interface is great for testing and scripting, while the web interface is easy to use for non techy people and for proving the concept.  The Matlab interface is great if you want to get all nitty gritty with parameter sweeps, response surface modeling and and optimization.  A topic that I devoted 4 years of my life to previously.

Where the code hits the runway

So you now have this design system which allows you to explore the impact of various design decisions in a quick and intuitive manner.  By iterating through the system you can gradually pin down the UAV you want to build.  Then of course you actually have to build it.

Here we also try to stay agile by leveraging rapid manufacturing technologies such as 3D printing as much as possible.  Additive manufacturing has the great advantage that you can prototype things really quickly and you can have a lot of complexity in the design, essentially for free.  This is great for a designer since it gives him more freedom in designing complex CAD parts without having to worry too much about if it can be made.

The extreme case here is to build the whole airframe with rapid manufacturing.  This is what we did with our SULSA aircraft, with which we gained quite a lot of publicity as we were the first in the world to do it and fly successfully.

But its important to not get carried away.  Additive manufacturing is great but you have to be aware of the limits of the technique and the materials used.  Traditional materials such as aluminium, carbon, etc. still have their place.

From the point of view of the system, the ultimate goal here is to have a button on the web page like this:

And thats it, no more interaction needed, go straight from design to flying in the space of a couple of days.

Unfortunately, though that vision is not 100% possible (yet).  The main problem is that this requires a fully parametric CAD model.  This is something we are actively doing (maybe I will give a sneak peek in a future blog post) but unfortunately not everything can be parametrized.  Well you can try but either the tool breaks or you break from all the complexity.  The thing is that designing a CAD model that can be manufactured requires a very large amount of detail, for example: servo mounts and screw holes.  And this detailing will always require manual intervention.

However, that being said, you still are able to get a much shorter turnaround time than you would do traditionally, not too mention the savings in cost.

Current status

The obvious question now is, I want to try this out, where’s the github repo? Well, the current answer is that you’d have to be on the campus network to be able to use the system, and even then, you would have to ask me nicely  As I said at the beginning of this post, the system has just reached beta state.  Everything seems to work and we are starting to get useful and sensible results.  My main concern now is doing a proper deployment.  Currently I have most components running on my own machine with some of the more expensive ones automatically being farmed out over our 8000+ core Linux cluster (using ssh & Torque).

With cloud computing being all cool these days I now want to setup an automated VM generation workflow using Vagrant and Puppet. The goal being that I simply run a script and it will generate a nice clean VM, containing all the components & which I can then easily deploy to one or more of our own servers or a public cloud.  Using something like supervisor or, more likely Salt, I can then remotely administer these instances, starting and stopping components when needed.

Such a deployment process will come in useful when more people, including students, will start using the system and break it

The plan is also to gradually open the system to the public, i.e., you, but that is still a couple of months away probably.  As for the system code itself, I hope that it may some day be open sourced and made publicly available.  But that will depend on how things evolve.

Open issues

The main open issue, especially when we come to public use, is related to security.  What I really need is an end-2-end single sign on system, across all components and all clients.  This is something I really need to think about.  Suggestions welcome

Other open issues:

• Think about handling result files.  A CFD run easily generates a few GB of data, serving this through flask for multiple users  does not seem like a good idea
• Do I want to make the controller more intelligent (e.g., to handle sweeps or optimization’s) or do I keep that intelligence in the client.  Both have pro’s and cons.
• Add support for sessions so you can have multiple clients active at the same time for the same user.
• Think about how to deal with having different versions of components running at  the same time.  How and when to (dis)allow this.
• Evolve the web client into a more powerful design exploration tool.  Initially we were going to use a third party tool for this but the company went bust.
• Add support for automatically integrating flight test data recorded by the autopilot as a special type of “analysis code”
• Possibly get involved in the parametric CAD side of things.

Future work

The longer term vision is to explore different MDO paradigms, and extend this to more types of missions, and configurations, possibly including rotary aircraft such as quadrocopters.  However, these kind of things will require a brand new concept design tool and that is still a long way away.  In February we will know if we get EU funding to be involved in the 2 Seas project. If so, that will drive my activities as well.

Phew… while I haven’t been able to cover everything, this has become quite a lengthy post but should give a good overview of what has been going on.  Please follow me on Twitter if you would like to keep up to date.

I would be very interested in any suggestions, comments, constructive criticisms, etc. So dont hold back

–Dirk

The organization was the same as other hackathons I had been to: organizers welcome everybody, idea owners pitch their ideas, chaos, teams are formed.  I quickly settled on the NGO Clarity idea by TechSoup Global Data Acquisitions Manager Dinesh Venkateswaran. With the drive to increasing transparency in the aid sector, there is a lot of data made available on NGOs.  The problem is that the format and quality of the available data varies wildly between and within countries.  Standardization efforts like IATI are trying to change this, but there is still a long way to go.

The goal of the NGO Clarity problem was to setup a system that would analyse the available data on a particular NGO and, depending on a set of rules, output a number of scores indicative of the quality of the provided data (notof the quality of the NGO itself). Such a system would allow a donor or organization like TechSoup quickly evaluate how much effort would be needed to evaluate an NGO.  Are there just a few small details missing or are there large gaping holes/inconsistencies in the data?  Solving this involved a three step process:

1. Data Aquisition: Dinesh had about 40000 records on Indian NGO’s with him that needed to be loaded and pre-processed
2. Inference: using heuristics, predefined rules & machine learning to assign scores to each NGO
3. Presentation: presenting the results in an intuitive manner in the form of a website

While we could not solve every step in detail, my hope was to at least setup an end to end proof of principle.

Our initial team consisted of 4 people, including Dinesh, but unfortunately one soon left to join another project.  After some discussion it was decided that all three steps would be implemented using XPath/XQuery & the XML eXist database.  Since this was the particular specialty of 3rd team member Chris Wallace.  By the first show and tell we had a prototype working, but unfortunately Chris had to leave by then and would not return the next day.  Two others (Russel and Tim) were then kind enough to join me to continue the work.

However, the problem was that none of us was particularly familiar with XQuery.  I setup the eXist database & managed to run Chris’ scripts but we were pretty much stuck trying to extend it in some meaningful manner.  Russel then gave up and left, & Tim had another project to attend to, so it was essentially just me to continue.  After some more poking at the code I also decided to give up as well. Progress was just too slow and as nobody else at the event had any knowledge of XQuery or was willing to help pick it apart I would never get it finished.

Thus, on the train home I decided to start from scratch.  Since I’ve been doing a lot of python lately it was natural to use that.  Though if I were to start this from scratch as a hobby project I would have used Rails or Play, just to get to know those as well. Anyways, I used Django on the backend and jQuery/Bootstrap on the frontend.  About 2 hours later, just when my train arrived I was at feature parity with the xquery stuff. Some more furious hacking the next morning, Ben Foxall helping out with the templates, and about 10 seconds before the presentation was due to start I pushed the demo code to github.  I tried to get a map view to work as wel (geocoding the NGO addresses & plotting them using Google Maps) but couldn’t quite get it to work in time).

Our final presentaion, excellently prepared by Dinesh is up on slideshare:

In sum, it was another great learning experience.  In good hackathon tradition the code is rather hairy so I plan to take some time to clean things up & hopefully improve the rules & structure.  I think its a great idea so I would like to continue working on it as there is much that still needs to be done (see slides).  Unfortunately time is in short supply these days, but let see how it goes…

–Dirk

The challenge settled on for last night was to solve a Boggle puzzle. For those not familiar with the game, the idea is that you get an n-by-n grid of letters and you have to form as many words as you can by ‘snaking’ through the grid.  Every grid cell may only be used once for a word.  For example, this is how you would form the word MURALS, starting from M:

Everybody got about an hour to hack on a solution after which each team presented their code to the rest.  It was interesting to see the diversity of style and solution. There was a team that used 5 or 6 classes in their solution with extra facilities for caching, ours was more straightforward & procedural, while another did the proper thing and used a Trie.

Since our code did not quite work yet I finished it on the train home and then took some time this morning to clean it up.  For kicks I also used python’s multiprocessing module to have a version that would solve large grids in paralllel.

I pushed the code to github and, while nothing fancy or super optimized, it should do the job.  As always, patches & improvements are welcome

Props to @ntoll and @tjguk for organizing the event and hopefully I can make the next one as well.

–Dirk

The only thing I needed to change was that I wanted the confirmation dialog (on ok) to trigger the original click() handle instead of redirecting to a different URL.  My basic patch is:

@@ -52,6 +52,17 @@
                                var o = options;
                                var $elem = $(this)

+                               //is there an existing click handler registered
+                               if ($elem.data('events') && $elem.data('events').click) {
+                                       //save the handler (TODO: assumes only one)
+                                       var targetClickFun = $elem.data('events').click[0].handler;
+                                       //unbind it to prevent it firing
+                                       $elem.unbind('click');
+                               }else{
+                                       //assume there is a href attribute to redirect to
+                                       var targetClickFun = function() {window.location.href = $elem.attr('href');};
+                               }
+
                                $elem.bind('click', function(e) {
                                        e.preventDefault();
                                        if(!$('#confirm-dialog').length) {
@@ -89,7 +100,8 @@
                                                $dialog.find('p.message').html(o.message);

                                                $dialog.find('a.btn:eq(0)').text($elem.text()).bind('click', function(e) {
-                                                       window.location.href = $elem.attr('href');
+                                                       $dialog.remove();
+                                                       targetClickFun();
                                                });

                                                $dialog.find('a.btn:eq(1)').text(o.cancelButton).bind('click', function(e) {

Cleaner would be to add some options and what have you.  And maybe I will come to that.  For now I put the full code in a public gist on github.  So fork ahead

–Dirk

Code on github.  The real goal here is to replace the Excel solver plugin with a plugin based on pycel and openopt.  I have this working but its too specific to our own spreadsheet structure to release.

–Dirk

I was one of the first to arrive, and although there weren’t too many people we quickly had a good mix of water and tech people.  The event started with pizza and calling in to various countries around the globe so the problem submitters could briefly describe the motivation behind their problem statement.  There were quite a few problems, some with curious names such as “Map the crap”.  Initially my interest went out to a problem that involved writing a Google Earth plugin that would enable water management people & researchers to quickly and automatically identify catchment areas for a given location.  A challenging algorithmic problem I figured.  Unfortunately I was one of the few (or only?) person interested in the problem & the problem submitter was not physically available.  So progress would have been difficult & slow.

Instead I decided to join fellow attendee and problem owner Mark Iliffe.  Mark had just started working at the World Bank and his problem revolved around extending the Ushahidi platform to improve the reporting and feedback process of complaints.  If you have never heard of Ushahidi, dont worry, neither had I.  Turned out is quite a useful and successful CMS system that allows users to file reports about problems in their area (broken pipes, blocked public toilets, etc.).

From the start it was great to see how enthusiastic Mark was about his team (about 4 of us).  Quickly we were sketching out use case diagrams, sequence diagrams, flow charts, TODO lists, etc.  I think we pretty much filled up all the white boards available.  We were only about 20 minutes into this and our progress was already caught on the akvo.org blog by Mark Charmer.  Great stuff.

As people were working stuff out Mark would bring on beer, biscuits, wine, and gently coerce other hackers in joining us (at peak we had about 12 people!).  Star of the team was probably Caz.  Ushahidi is written in php and my php foo is … well … not stellar  But no worries for Caz who did a great job of coding stuff up.  The hardest part about the whole exercise was understanding the code structure (Ushadhidi uses a custom framework based on Codeigniter and Kohana).  I helped around with various bits and pieces and added support for geocoding sms messages by using a custom location code (Tanzania lacks an official postcode system).  We worked right up to the deadline, with our tweaked Android application only finally working during our presentation (props to Gitmeister Florian!).

Anyways, long story short.  We won  The other teams had some good stuff too but I think we had the edge with Marks mad selling skills and a very clear route to sustainability.  So what did we win?  Not quite sure yet.  Some gadgets from Google and a teleconference with some IBM guys next week.  Lets see what happens.  After a great social gathering at the local pub it was time to head home.

As I undertook the 2 hour journey back to Southampton it struck me again how important these kinds of events are.  First of all for meeting new and interesting people, secondly for learning new stuff and learning to get something together quickly.  I still have a long way to go but thats a great excuse for attending a next event

More pictures here.

-Dirk