High Altitude Unmanned Air System

for Atmospheric Science Missions

A. Sobester∗, S. J. Johnston†, J. P. Scanlan‡,N. S. O’Brien§, E. E. Hart†, C. I. Crispin¶, S. J. Cox‖

Faculty of Engineering and the Environment,University of Southampton,

Southampton, Hampshire, SO17 1BJ, UK

This paper is a record of some of the design and operational aspects of developing an afford-

able unmanned air system capable of logging and processing atmospheric observations across a

range of altitudes. We consider the aeronautical and computational challenges of designing a

recoverable and re-usable lighter-than-air system for delivering lightweight science payloads to

the stratosphere and we examine the performance of the system through a physics-based Monte

Carlo flight simulation model and the analysis of two test flights (ASTRA 7 and 8). We then

review the development process to date of a self-recovering payload, based on a lightweight,

balloon (or aircraft) launched glider capable of autonomous return of the instruments to a pre-

ordained collection site. We also consider possible future extensions of the technology, including

a multi-vehicle system designed to enable the construction of an emulator (surrogate model) of

an atmospheric quantity across a specified block of airspace.

I. The Need for Wide Altitude Range Atmospheric Observations

The ability to collect physical, chemical and biological observations across a wide range of altitudes isessential for an understanding of atmospheric processes across all length scales from global (Earth systemmodeling) through cyclonic (synoptic meteorology), all the way down to the meso- and micro-scale of localizedphenomena. These are employed as boundary conditions or calibration targets in numerical models or as trainingdata for statistical emulators of atmospheric variables. In either case, atmospheric science may require theseobservations at a range of altitudes from the planetary boundary layer all the way up to the upper layers ofthe stratosphere or even the mesosphere. Here are a few examples of applications where extensive atmosphericobservations are of great importance, either on a routine basis or as part of targeted campaigns:

a) Atmosphere profiling for routine weather forecasting Weather balloon soundings obtained at a largenumber of locations and at regular time intervals are constantly assimilated into numerical weather predictionmodels, thus providing regular updates to their boundary conditions. A typical balloon-borne radiosonde oraircraft-launched dropsonde will record temperature, dewpoint, ambient pressure and GPS-derived wind speed.

b) Pollution and aerosol monitoring A typical example is the sampling of ash clouds. The consensus acrossthe aviation industry is that a safe level of ash density is around 2 × 10−3 g/m3 (corresponding to an enginecore throughput of about 1 kg/hour in an average jet engine) – extensive density observations are thereforerequired to draw up maps with contour lines around safe zones.1–4 Additionally, such density measurementscan be used to initialize ash dispersion models. An accurate understanding of the structure of the tephra plumeabove the volcano is the first step. It is a critical one too, as the eruption mass rate is related to the fourthpower of the plume height5 and this is the key input of any dispersion model. Similarly, fallout monitoring afternuclear incidents such as the recent event at the Fukushima Daiichi plant may demand accurate atmosphericobservations.

∗Lecturer, Computational Engineering and Design Group, AIAA member.†Research Fellow, Microsoft Institute for High Performance Computing.‡Professor, Computational Engineering and Design Group.§Research Student, Microsoft Institute for High Performance Computing.¶Student, Computational Engineering and Design Group.‖Professor, Microsoft Institute for High Performance Computing.

1 of 17

c) Observation of extreme weather phenomena A 4D map of wind velocities, temperatures and humiditiesacross thunderstorm cells, tornadoes and other extreme events can help in the more accurate understanding oftheir physics and thus in improving existing models for their forecasting.

d) Wind and temperature mapping around topography 3D/4D vector fields of atmospheric orographic (terrain-affected) flows can help enhance our understanding of phenomena such as gravity waves and mountain drag.

e) Clear Air Turbulence (CAT) The detection and forecasting of CAT is of great importance to aviationsafety. The challenge is to determine the mapping between certain measurable atmospheric parameters and thefrequency of occurrence of Kelvin-Helmholtz waves or other phenomena associated with CAT.

f) Aeronautical engineering research Establishing the envelopes within which icing or contrail formation islikely, relies on the ability to observe atmospheric variables.

g) Mesospheric observations The mesosphere, sometimes referred to as the ignorosphere, is the least wellunderstood layer of Earth’s atmosphere. Beyond measurements of the usual physical parameters, photographicobservations are also of importance here as, due to the extreme altitudes, very little imagery exists at present todocument the features of red sprites,6,7 blue jets8 and noctilucent clouds,9 to name only a few of the mesosphericphenomena, which demand enhanced observational systems.

Currently a range of capabilities cover many of the above needs to a greater or lesser extent, from satellitesto radars and lidars and from instrumented, manned aircraft to radiosondes and dropsondes. Each of thesehave their advantages and disadvantages, with high cost often being a key item on the list of the latter. Wenext review these shortfalls and discuss the aeronautical engineering challenges of developing a lighter-than-air,unguided system that addresses them.

II. Challenges and Current Capabilities

Simple balloon- and aircraft-launched packages – radiosondes and dropsondes – are used to satisfy many ofthe science needs outlined in Section I. They are relatively easy to deploy, but they have disadvantages. In bothcases the package is rarely recovered and it is regarded as disposable – the scientific data is typically transmittedback to a ground- or aircraft-based receiver through various communications technologies. Apart from the costof these single-use sensor packages (up to 1000 USD), there is an increasing concern over the polluting effectof dropping non-biodegradable collections of instruments, plastic insulation, parachute, electronic circuits andbatteries∗ on land and into the ocean. Additionally, the sondes collect their information whilst drifting in anuncontrolled manner either beneath a balloon or a parachute. A good experiment should allow a scientist toplan the number, density and location of samples – however, the cost, uncontrollability and disposable natureof existing sondes severely constrains the number of measurements that can be taken. We discuss a possiblesolution to this problem in Section IV.

The existing UK regulatory framework covering the launch of weather balloons only refers to balloon trainswithout propulsion and/or guidance systems. Thus, in terms of payload recovery, a lighter-than-air systemposes a two-fold challenge. Firstly, a flight simulation model is required, which is capable of both providing anensemble of estimated trajectories for a given set of launch parameters and, conversely, of suggesting launchparameters that are likely to result in the desired altitude and flight time, as well as a touchdown location whererecovery will be practical (of course, the existence of acceptable solutions is highly dependent on the forecastatmospheric conditions). Secondly, a real-time tracking and data-link capability is needed to ensure fast andreliable recovery of the payload. In combination with the flight simulation model, real-time tracking can enablethe refinement of the trajectory prediction through data assimilation, thus producing a landing zone estimatethat converges towards the actual landing site as the flight progresses.

As part of the Atmospheric Science Through Robotic Aircraft (ASTRA) initiative we have built a compu-tational framework that addresses these challenges – we discuss this in the next section.

∗Biodegradable batteries are now used in some sondes.2 of 17

Fig. 1 Balloon ultimate strain experiment – the 350g latex balloon used for the flights describedhere burst at a diameter of approximately 4.2m.

III. High Altitude Unguided Sensorcraft:

Tracking, Retrieval and a Computational Framework

Flight Simulation in the Presence of Uncertainty

Following the launch of a basic, unguided high altitude sensorcraft, such as a weather balloon, the operatorhas no influence over its trajectory. It is therefore essential that we have a numerical model capable of a relativelyaccurate simulation of the flight, for several reasons. First, we need to know whether the mission requirementswill be met; the most important of these are usually the target apogee altitude, ascent and descent rates andthe time spent in a given altitude band. Second, from a recovery logistics standpoint, it is essential that wehave a landing zone prediction.

This model can be run prior to the launch and it can be used to make some of the key operational decisions:the choice of the size of the balloon, the quantity of the lifting gas or, as a surrogate, the inflation diameter.Although an accurate measurement of free lift is another possible surrogate for the lifting gas quantity, this isnot always obtainable at remote launch locations, particularly when surface winds are high.

The winds aloft and other atmospheric parameters expected at the time of the launch are probably the mostimportant inputs of such pre-flight simulations. There is a certain amount of uncertainty associated with theseas well as with some of the other inputs and internal parameters of the simulation. The longer the time periodbetween running the simulation and the launch, the greater this uncertainty will be. The simulation capabilitywe have developed for the flights described in this paper accounts for such uncertainties through a Monte Carloframework, where normally distributed inputs and physical parameters drive the numerical model.

For instance, the calculation of the drag of the ascending balloon, as a function of its Reynolds number,is based on a normal distribution of CD values centered on data reported by Scoggins.10 This accounts foruncertainties in the surface friction of the balloon, the Reynolds number, the regression curve fitted to Scoggins’soriginal data and the original experiments. Similarly, the burst diameter of the balloon is a normally distributedrandom variable, centered on a value obtained experimentally. Figure 1 is an image illustrating this ultimatestrain experiment – the uncertainty here accounts for manufacturing differences between balloons, as well as theeffects of low temperature on the balloon material, neither of which were replicated in this simple experiment.Table 1 lists these variables and the other random inputs of the simulation, representative of ASTRA 8, a testflight that took place on 8 March 2011 (we will discuss this in more detail shortly).

The equations of motion of the balloon and its payload train were solved using the Euler method along thepressure altitude domain, with the discretization determined by altitude levels of 0.1m from the launch pointelevation to 1,500m and levels of 1m up to the apogee. The higher resolution in the planetary boundary layer

3 of 17

Quantity Central value Standard deviation UnitAmbient temperature from sounding 1 oC

Wind direction from sounding 10 degreesWind speed from sounding 1 m/s

Balloon drag coefficient from Scoggins10 0.15 –Parachute drag coefficient 0.9 0.1 –Balloon burst diameter 4.2 0.1 m

Balloon circumference at launch 4.9 0.2 mPayload weight 0.864 0.01 kg

Table 1 Flight simulation parameters for the launch of ASTRA 8.

was required to cover the transition from zero height above ground level and zero vertical speed to steady ascent– with coarser resolutions this region was found prone to numerical instabilities in cases where the free lift ofthe balloon was very low and therefore so was the rate of ascent.

To illustrate the use of the model for the prediction of the key parameters of a flight, let us consider itsresponses to the set of inputs representing ASTRA 8, as shown in Table 1. The profiles of the key atmosphericvariables were obtained from a sounding taken approximately 40 minutes prior to the launch at a UK MetOfficestation about 110 km to the north-east of the launch site (the payload would go on to land just over three hoursafter the sounding was taken at approximately 50 km to the south-east of the sounding location). 3000 runsof the model yielded approximately 2500 feasible flights (with the remainder producing burst altitudes below3 000 m or values of free lift that were not sufficient to lift the 0.864 kg payload). Figure 2 shows the histogramsof key flight performance parameters resulting from these simulations.

It is helpful to visualize the relationships between these parameters too. Figure 3 is a scatter plot of ascentrates, apogee altitudes and apogee times representing the ensemble of simulated flights making up the MonteCarlo study. The crescent shape and coloring of this point cloud are a reflection of the fundamental trade-offbetween ascent rate (and thus time to apogee) and apogee altitude – for a given balloon and payload, increasingthe apogee altitude will inevitably mean increasing the duration of the flight. Additionally, though this is notshown on this image, increasing the duration generally means increasing the range too, as the slower ascent willmean longer time spent exposed to the high winds of the upper troposphere.

Finally, this type of Monte Carlo analysis also yields a landing site prediction. The touchdown ‘ellipses’shown in Figure 4 have also been obtained using the inputs listed in Table 1. Each simulation resulted in apair of landing coordinates, the smoothed density plot of which was converted into the three contours shownin Figure 4, each enclosing a certain percentage of the forecast landing sites. The orientation of the long axesof these elongated patches corresponds roughly to the wind direction in the lower troposphere and the lowerstratosphere (a middle layer – a weak jet stream blowing in a slightly different direction – was also present onthe day of the flight).

While the type of analysis described here can provide interesting insights into the performance of unguided,lighter-than-air systems, the relatively long wall time of the Monte Carlo simulations may limit the method’susefulness in an operational context. For launch day calculations the value of more recent inputs – for instance,of a sounding obtained immediately before the flight – might outweigh that of running a large ensemble severalhours beforehand. Thus, a single simulation (or perhaps a small ensemble generated around a single key variable)may be run using the central values of the inputs and a data assimilation approach could be used to improve thevarious flight performance estimates (including the landing site location) while the flight is in progress. Nextwe discuss a possible implementation of such a computational framework.

Flight Hardware – Requirements and Implementation

A wide range of data logging, computing and communications technologies could be considered when de-signing a system suitable for the operation of retrievable high altitude payloads flown on lighter-than-air aircraft– our particular choice here was determined by a number of specific constraints:

Low Cost The recoverability of the payload is the first step towards minimizing operating costs; any addi-4 of 17

60 65 70 75 800

50

100

150

200

Apogee altitude [ thousands of feet ]T+1:00 T+1:20 T+1:40 T+2:00 T+2:20

0

50

100

150

200

Apogee time [ h:mm ]

60 80 100 120 140 160 1800

50

100

150

200

Range [ km ]T+1:40 T+2:00 T+2:20 T+2:40 T+3:00

0

50

100

150

200

Landing time [ h:mm ]

2 3 4 5 6 70

20

40

60

80

100

120

Ascent rate [ m/s ]7 7.5 8 8.5 9

0

50

100

150

200

Descent rate [ m/s ]

Fig. 2 Results of a Monte Carlo simulation of ASTRA 8 based on a wind profile obtained 40minutes before launch. The diamonds on each figure indicate the corresponding value from theactual flight.

5 of 17

60 65 70 75 80

T+1:00

T+1:10

T+1:20

T+1:30

T+1:40

T+1:50

T+2:00

T+2:10

T+2:20

Apogee altitude [ thousands of feet ]

Apo

gee

time

[ T+

h:m

m ]

Ascent rate [ m/s ]

3

3.5

4

4.5

5

5.5

6

Fig. 3 Scatter plot of ascent rate, apogee altitude and apogee time resulting from a Monte Carlosimulation of ASTRA 8 based on a wind profile obtained 40 minutes before launch. The circlemarks the actual value corresponding to ASTRA 8.

−1.1 −1 −0.9 −0.8 −0.7 −0.6 −0.5 −0.4 −0.3 −0.2 −0.152.5

52.55

52.6

52.65

52.7

52.75

52.8

52.85

52.9

Longitude [ deg ]

Latit

ude

[ deg

]

ASTRA 8 landing site

25%

65%

95%

Fig. 4 95 percentile, 65 percentile and 25 percentile landing ‘ellipses’ resulting from a MonteCarlo simulation of ASTRA 8 based on a wind profile obtained 40 minutes before launch. Thecircle marks the actual landing site of ASTRA 8.

6 of 17

Model T8686Platform Windows Phone OS 7

Supported networks HSDPA/WCDMA/GSM/GPRS/EDGEProcessor Qualcomm Snapdragon QSD8250

CPU speed 1 GHzDisplay resolution 480 x 800 pixels

RAM 576 MBFlash storage 8 GB

Weight 140 gDimensions 61.5× 118.5× 11.96 mm

Battery 4.8 WhAuxiliary battery 26.5 Wh

GPS updates 1 HzAccelerometer updates 47 Hz

Table 2 HTC 7 Trophy smartphone datasheet.

tional cost reductions contribute towards enabling the more extensive deployment of the system. To establisha frame of reference, the cost of a standard dropsonde is of the order of 1000 USD, with a balloon-launchedradiosonde costing in the region of 200 USD. In both cases the instruments are expected to be lost.

Ease of Deployment This suggests the need for a user-friendly interface for both the data logging andthe tracking / recovery operations. Another aspect of the usability of the system is the ability to perform avisual pre-launch system health check.

Scalability Standard sondes suffer from poor scalability. Their radio frequency telemetry systems aredesigned to transmit small packets and, as they are non-recoverable, the amount of observations they can beused to make is limited to data that can be transmitted at a rate of the order of hundreds of baud during thetime the vehicle is airborne. Any additional instruments a sonde might carry would have to send further data;because data is transmitted in near real-time, this would seriously reduce the (already limited) resolution of thesystem, generally around 100 − 150m.11 This also puts the cost into a different perspective: the hundreds ofdollars spent on a non-recoverable sonde may only buy the operator a few dozen observations.

To meet the above requirements we have selected a relatively inexpensive commodity device as the on-boarddata logger, tracker, system health display and communications platform, all in one, compact, lightweightpackage: an HTC 7 Trophy smartphone running the Windows Phone 7 operating system. Table 2 lists thecharacteristics of this handset.

In order to ensure the stable, prolonged operation of the phone in the extreme conditions of the stratosphere,an auxiliary battery was also included in the flight hardware; this, together with the phone, was encased in alaser-cut, lightweight, insulating foam housing, as shown in Figure 5. The foam used was tested in a low pressurechamber in order to ensure that it retained its mechanical properties in ambient pressures representative of theupper stratosphere. For the maiden flight of the system (ASTRA 7) a camera was attached to the housing atthe end of a carbon tube, with the goal of documenting the physical behavior of the phone during the flight.The camera was also encased in a similar foam housing. In addition to taking photographs, it also acted as alogger of its own physical data, recording throughout the flight the temperatures on its CCD, its lens and itsbattery, as well as the voltage on its battery (we shall discuss these in detail shortly).

The hardware used by the launch and recovery team consisted of similar smartphone handsets, running thesame software as the on-board device – we shall discuss this and its place within the broader data logging andtracking infrastructure in the next section.

Software Infrastructure

One of the main objectives of the ASTRA project is to produce an atmospheric testing capability which isflexible and durable enough to be adapted to many scientific scenarios. This means that the hardware has to

7 of 17

Fig. 5 ASTRA 7 payload, from top left, clockwise: the foam casing on the laser cutter, CADmodel of the payload assembly, full payload train and the payload being prepared for launch.

be extensible, for example to include additional sensors as well as durable enough to survive the harsh upperatmospheric environment. The software infrastructure is designed in a similar extensible way, for example toensure future sensors are supported and sufficient computational power and storage is available when required.

As indicated above the payload hardware includes a Windows Phone 7 smartphone for data acquisition,storage and communications. A custom software application runs on the phone, ensuring that data is loggedand – where possible – attempting to communicate critical data back to a cloud-based software service via theGSM data network. The smartphone selected for the ASTRA missions has a storage capacity of 8GB, which issufficient to log of all our sensor data at maximum frequency for long flights, without concerns of running outof storage space.

The application is designed so it is easy to turn data logging on or off and by default transmits its ID andlocation to our cloud-based service. One other feature is the ability to view the location of any other devicerunning the application based on its ID. These features combined with easy configuration means that the sameapplication can be run as a payload logger or, as a ground based progress tracker. The application can disablethe screen to save power, or, as with ASTRA 7, it can be configured to display sensor data. Figure 6 includesa picture of the application displaying latitude, longitude and altitude during flight. For testing it is handy tovisualize the data but for most missions the screen will be locked and disabled to avoid accidental interruptionof the application and to save power.

The smartphone sensors include GPS and a 3-axis accelerometer. The accelerometer provides an accelerationin each axis with an update frequency of 47 Hz, and the GPS provides latitude and longitude with an accuracyand altitude as well as velocity and time at 1Hz. The phone application records all this data and has the abilityto attempt transmission of key or summary values. The application can be extended to include any additionalsensors that can be connected to the phone, e.g., by Bluetooth, offering an extensible sensor capability. Theability to locate compatible, accurate sensors for smartphones proved to be restrictive and is the basis of futurework, discussed in the concluding section.

Communicating with potentially high speed devices over long distances is often a tradeoff between weight,power, bandwidth and costs. We can overcome many of these issues by using a commodity off-the-shelf smart-phone, which is low-cost, computationally powerful and provides access to a reliable, high bandwidth datanetwork which exists across much of the UK, even in rural areas.

When the smartphone has data connectivity the application attempts to send data back to a cloud-based8 of 17

Fig. 6 The Windows Phone 7 powered data logger / communications platform / system statusdisplay in the air – the display shows latitude and longitude (in degrees) and altitude (in meters).

Fig. 7 ASTRA infrastructure, showing the balloon payload communicating via GSM to a cloud-based Windows Azure service. All data is logged in Blob storage and updates are sent to groundcrew via GSM.

service. Top priority is given to the most recent data packet which is attempted for a timeout period (default20 seconds), and then discarded if the transmission failed. Since the application logs all sensor data, failureto transmit a data packet does not result in data loss. The application ensures that during periods of dataconnectivity the most recent data is transmitted. When the payload is retrieved the complete dataset can beanalyzed.

The data is sent to a cloud-based REST-full service running on the Microsoft Windows Azure platform.12–14

There is an overhead to communicating data via the mobile phone network: the phone has to connect to thenearest available cell tower, handshake and then send data. As the smartphone gains altitude the number ofcell towers that are visible increases and there is a risk that much time is wasted hopping from one cell toanother. Using GSM to send and receive SMS has been reportedly successful at altitudes up to 5,000m, butthe maximum altitude at which 3G connectivity is possible remains unclear.15

Figure 7 shows the architecture of the cloud-based service which is deployed on Microsoft Windows Azureand is hosted in the Dublin data center. The service is responsible for receiving data packets from any devicerunning the application. Each data packet contains a device ID and these are all stored in a cloud-based filelike storage called blob storage, providing a persistent mission data repository. The service is also responsiblefor maintaining a mapping of devices to their followers. Any instance of the application can subscribe to receiveupdates for another device based on an ID. For example, if all ground based followers subscribed to follow thedevice launched on a balloon they will be able to view their current location relative to the last known locationof the payload. If the ground followers are traveling in separate vehicles they can subscribe to receive updatesfrom each other, resulting in a map showing the balloon and all ground based followers – see Figure 8.

A cloud-based solution offers us the opportunity to rent hardware for the duration of the flight without9 of 17

Fig. 8 Windows Phone 7 application showing predicted landing site, last known balloon locationand recovery crew.

ASTRA 7 ASTRA 8Total number of in-flight updates 11 24

Maximum update altitude 547m 1893mHorizontal velocity at maximum update altitude 4.4m/s 10.0 m/s

Maximum update velocity 8.4 m/s 10.4 m/s

Table 3 ASTRA test flight trajectory updates.

having to purchase or physically take ownership and incur administration overheads for hardware that is usedinfrequently. Cloud providers support fast provisioning of hardware allowing us to size the hardware differentlyfor each mission.

The ASTRA missions rely on a Monte Carlo simulation to provide launch characteristics. We have theability to run these calculations in-house or in the cloud. This infrastructure flexibility demonstrates futureextensibility, for example it is trivial to set up the hardware and software to cope with many launches in a day.Also as the missions become more involved, or as higher fidelity simulations are required, a cloud-based solutioncan grow with demand and complexity.

In this section we have described the software and hardware infrastructure behind the ASTRA missionsand discussed its ability to log sensor data, communicate data back to a large compute resource and updateground crew with flight data. We shall now consider how the system described here performed on its first twotest flights.

Flight Testing

The flight tests described here and conducted in March 2011 were aimed at evaluating the computationalinfrastructure described above, as well as at gathering data relating to the performance of the electronic equip-

10 of 17

ASTRA 7 ASTRA 8Peak altitude [km] 18.2 21.6

Minimum optics temperature [oC] 2 17Minimum battery temperature [oC] 9 22Minimum CCD temperature [oC] 4 22

Minimum atmospheric temperature [oC] -64 -64Range [km] 75 106

Flight time [h:mm] 1:16 2:40Maximum ground speed [m/s] 40 23Number of images recorded 1200 2300

Table 4 ASTRA test flights.

ment (the phone, serving as the data logger, communications platform and tracker, and the camera) and theirinsulating casings in the hostile conditions of the stratosphere (see Ref. 16 for more on the challenges of designingaircraft for very high altitudes).

Classified as ASTRA 7 and ASTRA 8, the two flights took place only a few days apart in a period of stableatmospheric conditions; a high pressure system was determining the weather over the British Isles at the time.As a result, the physical properties of the atmosphere and therefore the environmental conditions which thevehicles were exposed to, were very similar on the two flights. In particular, the minimum ambient temperaturesexperienced by the two flights were, for practical purposes, identical (Table 4 summarizes the key parametersof each flight).

This allowed us to gauge the impact of adding a small chemical heater to the camera casing for ASTRA 8,in order to test the feasibility of increasing the temperature of the electronics (and, in particular, of the battery)during long flights at high altitudes. Figures 9 and 10 show the temperature histories on both flights, indicatinga temperature difference of just over 10oC between the two maxima and minima. It is also worth noting thateven in the absence of the heater on ASTRA 7 the temperature remained above 0oC across the camera andabove 10oC on the battery (although, with a duration of 1h16’, this was a relatively short flight). The result ofthese relatively high on-board temperatures is that the rate of voltage decay through the flight does not reflectthe very significant changes in the ambient temperature. Nevertheless, on ASTRA 8, at T+ 2h10’, the batteryvoltage fell below 3.7V, at which point a short cycle of shutdowns and restarts was followed by a permanentshutdown of the camera. The phone continued to operate for the rest of the flight – in fact, it was still operatingwhen it was recovered several hours later. This was the result of its generous supplementary battery capacity,which reflected the mission-critical nature of the operation of the phone.

Earlier we discussed the results of a Monte Carlo pre-flight analysis of ASTRA 8 – let us now consider howthe actual flight unfolded in terms of these parameters. The forecast landing ‘ellipses’ (first shown in Figure 4)and the actual touchdown location are laid out on a map in Figure 11 (for this and all other flight visualizationsneeded throughout this project we used the WorldWide Telescope software developed by Microsoft Research17).The map also shows the actual flight path of ASTRA 8, which ended approximately on the boundary of the 65percentile patch of the Monte Carlo simulation. The other key parameters of ASTRA 8 are shown against thehistograms of the simulation in Figure 2 and on the scatter plot shown in Figure 3.

In addition to these variables, the three components of the linear acceleration of the air vehicle were alsologged by the phone, at a sampling rate of 47 Hz. Figure 12 is a plot of the magnitude of the accelerations againstthe timeline of ASTRA8, synchronized with plots of other related flight parameters. Of particular note here isthe increase in the amplitude of the acceleration excursions in the first phase of the descent, with accelerationpeaks exceeding 2 g on several occasions in the first 10 minutes following balloon burst. This period of intenseactivity is also characterized by high descent rates (in excess of 10 m/s). Once the vehicle, the parachuteand the burst balloon (the latter, unusually, stayed with the payload throughout the descent) fall through thetropopause, the intense fluctuation in the acceleration values subsides, resuming only in the last 5 minutes ofthe flight, as ASTRA 8 descends through the lower tropopause.

In terms of the GSM data network connectivity, coverage for the ASTRA missions proved to be sparse: data11 of 17

−70

−60

−50

−40

−30

−20

−10

0

10

20

30

40

Time [ h:mm ]

Tem

pera

ture

[ o C

]

CAMERA O

N

T−0:2

0

LAUNCH

T+0:2

0

T+0:4

0

APOGEE

(T+0

:52)

T+1:0

0

TOUCHDOWN

(T+1

:16)

T+1:2

0

T+1:4

0

Ambient temp.CCD temp.Optics temp.Battery temp.

3.8

3.9

4

4.1

4.2

Cam

era

batte

ry v

olta

ge [

V ]

Sea level

10 000 ft

20 000 ft

30 000 ft

40 000 ft

50 000 ft

60 000 ft

ASTRA 7

Alti

tude

Pre−launch checks On the ground in Wales

Fig. 9 ASTRA 7 flight profile. The grey band indicates the apogee of the flight.

messages were received at a maximum altitude of 1,893 m. During the flight data was received for the initialascent and the final approach only. This was expected, but the maximum update altitude was disappointing, asshown in Table 3. Since the payload is retrievable and GSM connectivity poor, we are considering other lowerbandwidth but longer distance technologies. Another alternative is to consider SMS over GSM.

IV. Automated Payload Retrieval

The history of unmanned, fixed wing air vehicles as atmospheric research tools goes back at least to themid-1970s, with NASA’s Mini-Sniffer pollution monitoring project being perhaps the first serious attempt atdeveloping such a system.18 Then, as today, the greatest challenge was posed by the main competing objectivesof altitude and system cost. Three Mini-Sniffers were built before the termination of the programme, which wasforced to consider some extreme technical solutions in order to try to achieve its altitude range requirements.

12 of 17

−70

−60

−50

−40

−30

−20

−10

0

10

20

30

40

50

Time [ h:mm ]

Tem

pera

ture

[ o C

]

CAMERA O

N

(T−0

:18)

LAUNCH

T+0:2

0

T+0:4

0

T+1:0

0

T+1:2

0

T+1:4

0

APOGEE

(T+1

:55)

T+2:0

0

T+2:2

0

CAMERA

SHUTDOW

N

(T+2

:28)

TOUCHDOWN

(T+2

:40)

Ambient temp.CCD temp.Optics temp.Battery temp.

3.6

3.7

3.8

3.9

4

4.1

Cam

era

batte

ry v

olta

ge [

V ]

Sea level10 000 ft20 000 ft30 000 ft40 000 ft50 000 ft60 000 ft70 000 ft

ASTRA 8

Alti

tude

Fig. 10 ASTRA 8 flight profile. The grey band indicates the apogee of the flight.

13 of 17

Fig. 11 ASTRA 8 landing ‘ellipses’ (as per Figure 4) and the actual trajectory of ASTRA 8(the three circles indicate launch, apogee and touchdown).

The altitude requirements could only be met by using a non-air breathing, hydrazine-fueled power plant, whichmeant that the aircraft had to be handled with extreme care: it could only be flown from remote lake beds andcould only be approached in protective clothing. In the end, the prototype only flew to a maximum altitude of20,000 feet.

NASA revisited the problem of high altitude atmospheric research aircraft in the late 1990s through theERAST (Environmental Research Aircraft and Sensor Technology) programme, which culminated in the He-lios prototype UAV reaching an altitude of 96 863 feet. The aircraft was later destroyed by turbulence on asubsequent flight. Beyond its obvious fragility, Helios’s dimensions made it of very limited practical use: ithad a wingspan of 75m (aspect ratio of 40) and weighed approximately 600 kg. Before its termination in 2003,ERAST went on to develop several further large vehicles, powered largely by gas turbine engines.

The ASTRA system described in this paper has similar altitude (if not payload) capabilities at several ordersof magnitude lower costs. However, it has its drawbacks. The recovery of the instruments can be relatively time-consuming and the trajectory flown by the instrument package is limited to a linear ascent and a relatively fast,linear descent. To alleviate these shortfalls, the ASTRA team is currently working on the development of a newgeneration of the system, called BALUGA (Balloon- and Aircraft Launched Unmanned Glider for Atmosphericresearch). BALUGA is a high altitude, unmanned, unpowered instrument platform concept, capable of carryinga modular instrument package back to the launch site from its release altitude, which it reaches either attachedto a helium balloon, or on-board a manned aircraft. The autopilot controlling the BALUGA glider is capableof following a trajectory designed to maximize the extent of the block of airspace which the instruments canbe exposed to, while managing the energy of the aircraft in such a way that return to the launch site (or someother collection site) remains possible.

The key design goals of the BALUGA concept are rapid prototyping and modularity (the ability to instan-tiate a member of a family of gliders to suit a given sensor package) and low cost. The prototype BALUGAOne (see Figure 13) is currently under development at the University of Southampton.

The aircraft, with a wingspan of 1.5 m and an all-up weight of 2 kg is fitted with a camera, a temperaturesensor and a humidity sensor. Its central spine is designed to accommodate further sensor payloads as required,with an adjustable wing geometry allowing for center of gravity shifts caused by such additions. The controlsystem is based on a SkyCircuits SC-2 autopilot. Featuring three-axis accelerometers, three-axis gyroscopes,three-axis magnetometers, and dynamic and static pressure sensors and a fully-quaternion extended Kalmanfilter with centripetal acceleration compensation, the SC-2 enables BALUGA One to follow a pre-ordainedtrajectory. Depending on the measurements recorded by the on-board sensors, the trajectory can be alteredmid-mission, allowing for more effective sampling.

14 of 17

0

0.5

1

1.5

2

2.5

LAUNCH

T+0:2

0

T+0:4

0

T+1:0

0

T+1:2

0

T+1:4

0

APOGEE

(T+1

:55)

T+2:0

0

T+2:2

0

TOUCHDOWN

(T+2

:40)

Time [ h:mm ]

Acc

eler

atio

n m

agni

tude

[ g

]

−15−10

−505

GPSinop.

Ver

tical

spe

ed[ m

/s ]

0102030405060

Win

d sp

eed

[ kno

ts ]

−60−40−20

0

Tem

pera

ture

[ o C ]

32200400600800

1000

Pre

ssur

e[ m

bar

]

Stratosphere

JS JS

Fig. 12 ASTRA 8 accelerations and other flight parameters. ‘JS’ indicates the (rather weak)jetstream in the tropopause, traversed by the flight on the ascent and on the descent. The greyblock on the vertical speed chart denotes the part of the flight spent above 60 000 feet (18 288 m) ,where the GPS unit of the phone was inoperative.

V. Conclusions and future work

The goal of the first phase of the ASTRA project, as described here, was to test technologies that wouldform the building blocks of a future unmanned system capable of collecting extensive atmospheric observationsacross a broad range of altitudes. We have shown the feasibility of a lighter-than-air system as a means ofdelivering instruments to the stratosphere and retrieving them after the flight. This also shows promise interms of using a lighter-than-air system as a high altitude ‘launch pad’, a means of extending the altitudecapabilities of unmanned airplanes.

We have also shown how the capabilities of a basic, unguided, high altitude lighter-than-air vehicle can bebetter exploited through the use of probabilistic flight simulation, a technology that fits well with the cloudcomputing architecture we have developed for the first ASTRA flight tests.

We have also investigated the use of a smartphone as an on-board communications and data logging and15 of 17

Fig. 13 BALUGA One balloon-launched glider prototype.

processing platform, as well as a ground-based tracking device. Using such a commodity device contributestowards reducing the costs of such systems. Another advantage of using a smartphone as the basis for a loggingand communication device is the ability to program using a high level object-oriented language, such as C#,thus reducing the application development time. However, the smartphone did not easily support customor bespoke sensors and this could prove a limitation in the future. There are a series of rapid prototypingplatforms on the market, many of which support the .NET Micro Framework. This increases the developmenttime, as hardware has to be built, configured and tested for durability, but potentially supports any sensor,communication method and storage device. We are testing a rapid prototyping solution called Gadgeteer19

for a future mission. Gadgeteer is different from many rapid prototyping solutions, as the wide range ofsensor modules have standard connectors, providing solderless construction. This reduces the hardware testingrequirements as standard sensors simply plug together. The .NET Micro Framework, upon which Gadgeteer isbuilt, supports C#, has a managed memory model and supports eventing. This high level functionality reducesdevelopment time. Very simply and with minimal code, modules can be configured and incorporated into adesign. Where sensors or other capability is missing and not included in Gadgeteer it is possible to createcustom modules or devices that can seamlessly work with the existing Gadgeteer kit as standard protocols, suchas I2C, are supported. These features make Gadgeteer an ideal candidate for future missions.

Much effort is devoted to creating a lightweight housing for the payload. It has to be strong yet lightweight,easy to produce and fit the payload hardware. The Gadgeteer modules and mainboard all have CAD templateswhich can be used to create optimal housing designs. The focus of these templates is to support the 3D printingand/or laser cutting of Gadgeteer housings. This capability will enable us to create better housings and providereassurances of strength and suitability.

In terms of the automatic recovery of ASTRA payloads and an improved sampling of target airspaceblocks, an extension of the BALUGA concept (currently under conceptual development) involves a systemcomprising several BALUGA sensorcraft launched simultaneously from one or several balloons or aircraft, withtheir trajectories optimized for space-filling. More specifically, the system currently under development will becapable of designing a family of trajectories optimized to encompass a space-filling sampling plan generated asthe basis of an emulator of the atmospheric quantity being measured.

Acknowledgements

We would like to thank Microsoft for their support of the ASTRA initiative. The work of Dr. AndrasSobester was funded by the Royal Academy of Engineering and the UK Engineering and Physical SciencesResearch Council.

16 of 17

References1Gratton, G., “The Age of Volcanic Ash – what do we Know?” Proceedings of Flying through an Era of Volcanic

Ash, Royal Aeronautical Society, London, UK, 9 November 2010.2Kelleher, P., “The Impact of Volcanic Ash and Other Contaminants on Airworthiness,” Proceedings of Flying

through an Era of Volcanic Ash , Royal Aeronautical Society, London, UK, 9 November 2010.3Lambourne, D., “Volcanic Ash and Engines,” Proceedings of Flying through an Era of Volcanic Ash , Royal Aero-

nautical Society, London, UK, 9 November 2010.4Haines, A., “The Regulator’s Challenge,” Proceedings of Flying through an Era of Volcanic Ash , Royal Aeronautical

Society, London, UK, 9 November 2010.5Carey, S. and Sparks, R. S. J., “Quantitative models of the fallout and dispersal of tephra from volcanic eruption

columns,” Bulletin of Volcanology , Vol. 48, 1986, pp. 109–125, 10.1007/BF01046546.6Franz, R. C., Nemzek, R. J., and Winckler, J. R., “Television Image of a Large Upward Electrical-Discharge above

a Thunderstorm System,” Science, Vol. 249, No. 4964, JUL 6 1990, pp. 48–51.7Stanley, M., Krehbiel, P., Brook, M., Moore, C., Rison, W., and Abrahams, B., “High speed video of initial sprite

development,” Geophysical Research Letters , Vol. 26, No. 20, 1999, pp. 3201–3204.8Raizer, Y. P., Milikh, G. M., and Shneider, M. N., “Streamer- and leader-like processes in the upper atmosphere:

Models of red sprites and blue jets,” Journal of Geophysical Research – Space Physics , Vol. 115, JUL 7 2010.9Gadsden, M., “Noctilucent clouds,” Journal of the British Astronomical Association , Vol. 99, No. 5, 1989, pp. 210–

214.10Scoggins, J. R., “Spherical Balloon Wind Sensor Behavior,” Journal of Applied Meteorology , Vol. 4, No. 1, 1965,

pp. 139–145.11Smit, H. and Kley, D., “JOSIE: The 1996 WMO international intercomparison of ozonesondes under quasi flight

conditions in the environmental simulation chamber at Julich,” WMO Global Atmosphere Watch report series , Vol. 130,

1998.12Microsoft, “Windows Azure platform,” 2010, www.microsoft.com/windowsazure Accessed 23 Aug 2010.13Aloisio, G. and Fiore, S., editors, Grid and Cloud Database Management , chap. Scientific computation and data

management using Microsoft Azure, Springer, July 2011.14Redkar, T., Windows Azure Platform, Apress, 1st ed., January 2010, p. 193.15Gonzalez, F., Walker, R., Rutherford, N., and Turner, C., “Assessment of the suitability of public mobile data

networks for aircraft telemetry and control purposes,” PROGRESS IN AEROSPACE SCIENCES , Vol. 47, No. 3, APR

2011, pp. 240–248.16Sobester, A., Stratospheric Flight: Aeronautics at the Limit , Springer-Praxis, 2011.17Fatland, D. R., Fay, J., and Fay, D., “Geoscience visualization with World Wide Telescope,” Tech. rep., Microsoft

Research, 2011.18Gregory, T. J., Nelms, W. P., and Karmarkar, J. S., “Remotely piloted aircraft in the civil environment,” Mecha-

nism and Machine Theory , Vol. 12, No. 5, 1977, pp. 471–479.19Microsoft, “Microsoft .NET Gadgeteer,” http://www.netmf.com/gadgeteer, Last accessed Sep. 2011.

17 of 17