The mission was a textbook operation, with the the payload eventually returning to terra firma within a few hundred metres of the awaiting team, at a spot predicted by the impressive Cambridge University Space Flight Landing Predictor.
Since 2008, when Rob Anderson first wrote the predictor, it’s been continually updated to improve performance, and now offers anyone wanting to send a balloon aloft the chance of seeing very quickly indeed just where it’ll burst and where they should head to recover their precious load.
It’s clever stuff, but how does it work? We had a chat with Daniel Richman, who earlier this year followed in the footsteps of Rob Anderson, Fergus Noble, Ed Moore, Jon Sowman, Adam Greig in upgrading the predictor.
The US’s National Oceanic and Atmospheric Administration (NOAA) provides (freely) wind forecasts, containing a huge amount of information, but crucially, (horizontal) wind velocity at various levels in the atmosphere. To a close enough approximation, the balloon will move at the same speed as the wind.
Combined with a simple model of how fast the balloon will rise, and how fast it will fall after it has burst, we take the position of the balloon at a certain time, the speed of the wind, and calculate where it will be a short time later using secondary school level maths (“SUVAT”); though the proper name for this is “solving an ordinary differential equation using the Euler method”.
There are a couple of other subtleties: for example, instead of the wind data being provided at certain altitudes, it is provided at certain pressures, and then the actual altitudes of those pressure layers at each point on the Earth is provided separately. So we have to first work out the air pressure corresponding to the altitude of the balloon, and then look up the wind velocity at that pressure level. I assume this is to do with how the forecasting works.
Furthermore, since the velocities are provided at every half-degree of latitude/longitude, we have to interpolate to guess the wind velocity at the position of the balloon. Also there are some little details to do with converting distances in meters to changes in latitude and longitude and so forth.
The current “one-shot” prediction facility, such as the Area 51 example above, went live in 2010, and provided the data for our ill-fated playmonaut’s encounter with the English Channel last December.
According to Daniel, the problem was with the NOOA servers:
For a while we had been using the OpeNDAP servers of the NOAA. Basically, the OpeNDAP server is some Java thing that the NOAA give their forecast data to, and then you can ask it for “all the data in this latitude/longitude range”, which is neat, since it keeps the amount of data we have to download low. Although we are of course very grateful to the free data provided by the NOAA, these servers were becoming – for whatever reason – a bit slow and unstable. Alternatives were investigated, and we found that we could just download the underlying data from a NOAA FTP server.
Going straight to the FTP server has its downsides, as Daniel elaborated when explaining the 2013 predictor update:
Now have to download ~6-7GB, but the server that the predictor now runs on has lots of disk space and gigabit internet, so this isn’t really a problem.
I wrote the new code to download and decompress (the downloaded files are in the GRIB2 format; the compression method itself is actually a variant of JPEG) this data in advance; it runs every six hours to download the new forecast from the NOAA.
The download takes about an hour, and is mainly limited by the fact that it takes about an hour for the NOAA to upload it to their FTP servers.
The download in advance means that when you push ‘Run prediction’, instead of waiting a minute for data to download, it starts instantly. Furthermore, we decompress the data into a 18GB binary file (referenced in my original email) purely because this means it’s very quick and easy for the predictor to access the data (essentially, the binary file is a giant 5 dimensional array of double precision floats, “double dataset_array_t[65][47][3][361][720]”).
By quick, I mean that the calculating stage itself now takes between 20 milliseconds and 2 seconds (depending on whether the wind data has to be read from disk or is stored in the page cache) instead of tens of seconds to load it from several files.
The long-term aim for the predictor is “to rewrite the underlying prediction code – the bit that does the actual calculation – to add features like predictions for balloons that achieve float, and so forth”.
The “floater” option will certainly prove useful for LOHAN team members Dave Akerman and Anthony Stirk, who have a penchant for drifting across European airspace on long-range missions.
Back at LOHAN headquarters meanwhile, as well as one-shot predictions, we’ve been availing ourselves of all this hard work to examine seasonal wind conditions for the eventual launch of our Vulture 2.
Our intended launch is at 40°25’20.49″N, 5°18’0.27″W, and we’d rather like the balloon to pass within gliding distance of the Vulture 2‘s landing site* at 40°45’15.06″N, 5°25’3.90″W, or at the very least stay within our designated operational areas (dark blue primary, light blue extended secondary):
Here are some predictions from between April and October (.kmz here)…
…which become a bit clearer when broken down:
As you can see, the predictor demonstrated that September is the best month for the job, confirming our research on historical wind data showing predominantly south-westerly winds for pretty much the whole month.
Of course, should the wind direction not play ball, we can always shift the launch location to optimise the balloon’s flight path, and with the improved predictor, we’re confident it’ll perform as expected. ®
http://www.actioncameras.co.uk/action-camera-reviews-infographic-best-helmet-cameras/
.
Balloon News 