Ekranoplan Project

At the start of the summer I was looking for an interesting aircraft design project, to build my skills and project portfolio. After failing pretty hard at doing an electric aircraft project earlier in the year, I was bummed out and looking outside that domain. One interesting project idea that a floormate suggested was an ekranoplan, or wing in ground effect vehicle (WIG).

An ekranoplan is an air vehicle that flies very close to a smooth surface such as ice, water or tarmac in order to generate extra lift and fly more efficiently. When an aircraft comes into land it is effectively an ekranoplan, as it floats along the runway for a few seconds before settling. You can see the same thing in nature, with a goose or pelican cruising low across body of water.

Ground effect can dramatically increase the aerodynamic efficiency of a vehicle if  the vehicle is sufficiently close enough to the surface. The rule used by pilots is related to wing span, though experiments show that the effect is more closely related to wing chord or length. To really start to get ground effect benefits, you need to be flying at a height above the surface less than the wing chord. This immediately leads towards an interesting design tradeoff, as a wing with a long chord is normally detrimental due to higher induced drag from decreased aspect ratio, though in an ekranoplan scenario you actually get efficiency benefits.

I thought it would be interesting to see what would be possible with a homebuilt ekranoplan, as few have been made. I got started by making some remote controlled models with flew reasonably well, and then went into a full componentry, Solidworks and spreadsheeting (ugh) effort over the first month or two of summer. I gathered a kayak, 35 hp two stroke (from a snowmobile), composite homebuilt materials and tools, avionics and even a propeller. Though towards the end of the summer my efforts on the project slowed down. I realised that I hadn’t done nearly enough structural analysis before purchasing components, and that my design would be severely overweight with what I had. Most of this realization came after I wrote up the design problem as a geometric program, which let me see the whole problem at once.

During the semester I didn’t make much further progress on solving the weight problem, and generally got discouraged by the whole thing. But now it’s winter break and I have enough time that I think I can have another more disciplined crack at the problem, with the hope of getting a formal design with reviews done by the end of the break to start building during the semester for a flight in the summer.

Before I get into the work I’ve been doing, I guess I should provide a short introduction to the mission and the vehicle.

I figured out the mission I wanted pretty much by accident. My initial mission for the vehicle was a commuter role for linking up coastal cities such as Boston and New York. The idea was that you could fly down the coast at airplane speeds without airplane regulations [1]. You would also have a lot more options for little destinations such as islands and beaches. Additionally, such a vehicle would be much lower cost to operate than a full aircraft. Though as I was working on the Boston-NY range case (my home case), I realised that the relatively long range requirement was forcing the cruise speed down to be quite slow, almost to the point of a car. If that was the case, what’s the point of building the thing?

The cool thing is that if you can get from Boston to New York with an ekranoplan, you can get pretty much anywhere. The gap between the two cities by the closest ocean/river route is ~400 km.

Ekranoplan route from Boston to New York.

Ekranoplan route from Boston to New York.

If you look at a map of Earth and work out what the range you need to link from any one major land mass to another, then the largest gap is ~490 km, between Iceland and the Faroe Islands, just a little more than Boston-NYC. If you can make it that far, you can make it anywhere, provided each location has fuel and a suitable dock or landing beach.


This makes for the exciting possibility of a new (and quite weird) circumnavigation record. If you can hit that critical ~490 km range number (or a realistic number over), then all you have to do is link up from town to town around the world longer than 40,000 km and you’re in business for a record. So that’s what I’m trying to do, designing and building something that can hit that critical number reliably in realistic weather conditions.

I used to think that hitting the critical range of 500-550 km was super possible, though now the design is overweight so I’m not so sure. In the upcoming posts I’m going to try and tease out the correct solution.

1. If designed right with boating codes, and flown below 50ft, ekranoplans are technically boats even though they can often operate at an order of magnitude higher speed. The key is to keep the takeoff speed below “dangerous” boating speeds, but the flimsiness of anything flight-worthy generally makes that happen by default.

Posted in Uncategorized | Leave a comment

How to Set up a Fast Aircraft Design Environment with GPkit and OpenVSP

A common concept in software development is the idea of a development environment that allows for rapid iteration. Concepts like hot-reloading, live previews, A/B testing and so on are very fashionable and useful for companies that are moving fast in the product development department.

Though whilst for aircraft design problems there may be a similar desire for speed in design iteration, it’s often tricky to get that speed with slow numerical optimization methods and large CAD programs.

I work with the GPkit team at MIT on geometric programming optimization methods that attempt to solve one part of the design speed problem. Geometric programs are a form of optimization problem that are incredibly fast to solve (<0.1s standard laptop for 10k variables), guarantee either a global solution or nothing at all, and require no initial values. This makes them quite useful for aircraft design exploration. You can read more about geometric programs here and here.

Though the direct output of a geometric program is not particularly visual, even though it may have some useful information. It can’t tell you how big something is, what shape it is or what it looks like. It just gives you numbers.


What an optimizer solution usually looks like.

To answer the questions of shape, fit and size a fast CAD tool for aircraft design such as Open VSP can be useful. OpenVSP is great, it allows you to set up pretty precise geometry models a lot faster than in software such as Solidworks, as it is designed specifically for the aircraft geometry domain.


Screenshot of OpenVSP.

No matter how fast your optimization method is, you’re going to face a bottleneck when it comes time to check that solution’s geometry. Do all the calculated volumes fit in the fuselage? Are the weight and balance positions reasonable? These questions are often answered by hand tuning a CAD model, which robs the designer of the potential speed of a fast optimization method. It would be good if we could get the computer to do this data transfer.


How to link GPkit and OpenVSP:

  1. Get stable installs of GPkit and OpenVSP running on your computer if you haven’t got them already. Instructions are here and here.
  2. Create a representation of your aircraft’s geometry with OpenVSP.
  3. Save the OpenVSP representation as a .vsp3 file.
  4. Create a representation of your aircraft’s physics using GPkit in a .py file. There’s a lot more on how to use GPkit here.
  5. Now extract the variables in your design that you find significantly affect geometry using OpenVSP’s “Design Variables” tool (under “Model” tab) into a .des file. A good place to start for a basic aircraft would be the wing’s span, projected span, chord and area.
  6. Now for the magic. We’re going to let our GPkit optimization code modify the .des file after each optimization run. You’ll want to add the following function to your .py GPkit file:
    def updateOpenVSP(inputDict):
    	filename = 'design.des'
    	with open(filename,'r+') as f:
    		result = f.read()
    		a = result.split('\n')
    		outputLines = []
    		for line in a:
    			words = line.split(':')
    			if len(words) > 1:
    				key = words[0]
    				value = float(words[-1])
    				if key in inputDict:
    					value = " " + str(inputDict[key])
    				words[-1] = value
    			outputLine = ":".join(words)
    			outputLines += [outputLine]
    		output = '\n'.join(outputLines)
    		print('OpenVSP .des output:')

    You’ll also want to add in a dictionary after the solving step that maps between the variable IDs from OpenVSP and your GPkit variables. For example:

    resultsDict = {'VHNJACDDXEA':float(sol(S).magnitude),'FDGQUUBYWFT':float(sol(b/A).magnitude),'ZVJTAUAEWVE':float(sol(b).magnitude),'CSWCUOQMTDT':float(sol(b).magnitude)}

    The last thing to add to your Python code is a call to the updater:

  7. We now have a way for the optimization run to update the geometry, but it would be nice if there was a way to load that geometry without having to close and reopen OpenVSP or go through multiple menus each time we want to see a change. To streamline the process we’re going to use a .vspscript file:
    void main() {
    	Print("Update .vsp3 file\n",true);
    	Print("Apply .des file\n",true);
  8. Now all you have to do when you run a GPkit solve and you’d like to see geometry is go to the “File” tab in OpenVSP, click “Run Script” and then select your updater script (I just called mine reload.vspscript). It would be nice to get rid of that action too, but I haven’t yet figured out a way of fully scripting OpenVSP whilst its UI is open.
Physics and geometry of the design problem linked together.

Physics and geometry of the design problem linked together.

As your model inevitably gets more complex, you can extend the design variables file and linking dictionary to capture more detailed geometry.

If you didn’t follow the tutorial super closely or want to play around with the concept without writing code, here’s an example project: https://github.com/lochieferrier/teaching/tree/master/gpkit-openvsp

Please let me know if you have any feedback or suggestions!

Posted in Uncategorized | Leave a comment

Mars Survey Aircraft Speed Design

It’s finals week at MIT, which means I am in full looking for projects other than school mode. I’ve been wanting to try out doing quick designs of aircraft concept ideas with GPkit for a while now, but haven’t gotten around to it.

When humans get to Mars, I think that one of the things that could be nifty is if they have some sort of aerial capability. A way to see what’s over the next hill, cruise around looking at valleys they can’t reach, or perform terrain surveys.

The problem is that Martian aircraft are pretty confusing to an Earth-based aircraft designer. Mars has a much thinner atmosphere, only around 1% the density of Earth’s, and the gravity is also around 2.5x less. This makes it hard to estimate performance based on “looks like” back of the napkin sketches of potential designs.

Using geometric programming as a design framework was handy for working around this, as it let me rely on the physics of the problem rather than what I thought the solution might look like. I made range with a full 1 kg payload my objective.

At first I started out with a sketch of the general configuration, a high boom pusher prop with a 1U (CubeSat) payload. I then plugged this into a GP formulation of Breguet range and got decent range. I then added in wing aero, propulsion, boom and tail sizing to get a complete picture of the relations. This led me to fix to an OS 120A nitromethane powered design that got 4302 km range on only 1.3 L of fuel. It looked like this:



Then I realized I was pretty dumb, and that you can’t just use an Earth air-breathing engine on Mars (the atmospheres are super different). So I went and looked at an electric LiPo powertrain, and found a reasonable solution with a Turnigy CA80. This motor was more powerful and heavier than the gas engine, and lead to an increased wing span and area. The range took more than an order of magnitude hit though, going down to 138 km so it would be really desirable to use gas if you wanted to do far reaching imaging.



This was the first time I’ve played around with OpenVSP seriously, and I really like using the software in tandem with an optimizer like GPkit. You can see all the GPkit scripts and OpenVSP files in this repo under today’s date: https://github.com/lochieferrier/concepts/. The file naming convention is electric stuff is electricx.y and the gas stuff is x.y.

It was getting complex enough that I probably should have modeled in an object-oriented way, and the model was missing a drag model for the fuselage, but other than that I was surprised with the level of detail available in a few hours work. Also, I’d like to get a better stability model than this rough approximation. Hopefully I can get faster at closing the loop between concept and physical results in future.

Posted in Uncategorized | Leave a comment

Skopje Day 6

Today’s post will be fairly brief, because it was a good day for only a few reasons. I ran up the hill yet again. That’s the first thing, but maybe I should really get a map and go somewhere else, my muscles know what’s coming. The main attraction was finally getting a full day of work in the lab with the students. Amazing how much got done. We went from a pile of parts at the start of the day, to a nice, almost finished product.

The first impressive thing about this was the stepper motor setup. I assumed that the students wouldn’t have enough skills to be able to build their own boards from scratch, so I bought off the shelf Arduino Stepper Motor shields, which are the simplest solution for making a CNC. Though when one of them noticed that there would need to be a little hacking to stack two shields on top of each other, and that this hacking would take a few hours, he just went off and designed and made his board in one night.


The board that Orhan, one of the students, made. Really nice.

With two fresh L293D chips that board got the steppers up and running fast, and they got to work on turning the DVD casings into a frame and mounting the drives on the casing. It felt a lot like my summer back in Boston, hanging out in the heat messing around with janky engineering. By the end of the day, it looked like this:


Super simple little plotter/mill, made from DVD drives. Total cost (excepting shield mess up): 7 USD

It can move around just like any 3D printer / CNC rig, and take g codes. Looking forward to finishing it up tomorrow.

Posted in Uncategorized | Leave a comment

Skopje Day 5

Today was awesome. I got up at six to see the sunrise, and it delivered. There is a new building project that really stands out in height in the morning light. First I got this from the house:


Then I ran up the hill to capture these:

I wasn’t really up for the sunrise, I was up to go on the morning TV show. But I had to miss that because my throat crapped out and I couldn’t talk. I got to sit in the studio and watch it though. All the camera guys were eating burgers, and there was the morning cooking show guy cooking next to me.


It was cool to actually see inside a set, I think the last time I did that was Channel 7’s sunrise. This one had super tall roofs.


After that we went and bought some electronics for the project at the single electronics store in the country (I think it’s the only one for real stuff like chips). The boards that we got worked as expected with the setup, which was great because I’m no stepper motor driver genie.


Relieved me after making working stepper setup.

The main idea of the day was to launch and show off the school. The TV show was the first part of that, the next thing that I did was do a little talk about future tech. I focused on space exploration, electric aircraft and artificial intelligence.


A lot of these people have no idea what I am saying, partially because of the bad voice but also because of English.


My bad throat rushed me through the last two topics, and giving any meaningful insight on either of those things in twenty minutes is a bit of a joke.

It was surprising that there were so many questions about AI safety, probably 10 or 15 questions. People wanted to know whether you could make it safe with various methods (task scope restriction, isolation or moral limiters) and I gave the standard Bostrom answers (no you can’t, it’s all about edge cases and social engineering holes). Though there were some oddballs such as the question of whether AI is inevitable. Probably is, but of course there is some probability we will die off before it happens.


The fashionable way of protesting against the government is to throw paint bombs, and there was clearly some government department in the same building as the conference place.


Jovana, master organizer

The day ended up with a conference where various people talked about tech and the importance of project based learning.


Panel about studying at MIT, with Boyan (super smart guy) and Kliment

There was also some art and music, but I didn’t get photos of that, because my camera was super flat.

There was no major run today, unless you count a scramble up the hill.

Posted in Uncategorized | Leave a comment

Skopje Day 4

Yesterday was the first proper day I had in the lab with students, which was really cool. It’s amazing how useful personal teaching can be, not just for its intended purpose, but also for instructing the instructor. 

The innocent questions are actually kind of the hardest to answer or explain. For example, supersonic effects on an airplane. Everyone gets that there is a shock and a noise produced. Explaining things like supersonic aircraft wing sweep or inlet geometry is pretty intuitive. Thoughexplaining the fundamental principle is hard, what causes the shock in the first place. The way I best understand it is through information transfer. When a plane is flying at subsonic speed, the air in front of it learns about its presence in advance, through a change in pressure.This change is transmitted at the speed of sound, as a pressure wave (same as sound wave). Though when the aircraft is supersonic, that wave can’t get in front, so instead the molecules undergo an instantaneous change in conditions (pressure, velocity, or density). This is what causes the shock wave, which is a spike because the change doesn’t happen gradually. 

This was the explanation I had, and tried to explain. It just wasn’t clicking. I don’t have the internet now to figure out whether it was right or not. Though it was this great reminder that hey, I don’t even really know the fundamentals that well.

You never go back to basics unless you try to explain stuff, because you can just assume that you know them and refer to some formula when you work higher up. This is a padticularly scary phenomenon because the basics are usually where the great advances happen.

Today I tried and failed yet again to get up to the cross, I took what I thought was the pensioners trail, which is meant to go to the top. I was clearly not pensioner enough, because I missed the trailhead and ran up another hill instead. Next time I will take the super steep trail.

Posted in Uncategorized | Leave a comment

Skopje Day 3

Things are starting to settle down and I am getting into life here. My favourite thing is definitely still running up the hill. It’s so quiet compared to American roads, except for the occasional goat, and the gradient is a steady curving rise instead of kicks or rollers. You can think about things and still hit a wonderful view at the top. That’s something I’ve never had close by before, a long gentle hill. So much fun as a way to wake up. 

I ended up at the little bar and hotel halfway up the hill, after running 2 and a half miles. From there, the trails split off into the main paved road,  ‘pensioner’ trail and various steep hiking trails. Too pooped I left those for tomorrow, to try and make it up to the Cross proper.

The wildlife around Macedonia is not too different to other European countries so far. There are a lot of swifts around and they tend to fly in little groups of 20 around the hill in the morning. Other than that, the main unusual wildlife is stray dogs and cats. Most of the stray dogs are puppy like but some look like wolves, which can wake you up when you see one standing there. 

I’ve gotten into a pretty good routine of doing coding for the aircraft design project I am working on and teaching. In the mornings the first thing I do is go out and run. Then I code for a little while, maybe one or two hours, before I go and do teaching for five or six hours. Then I either come home and code or go out to see stuff. It’s about the same complexity as I had in my summer schedule back in Boston, but something makes it feel simpler.

Posted in Uncategorized | Leave a comment