Author: Thorsten Renk

Altiports

If you are up for some challenging approaches and tricky landings while you like to enjoy spectacular scenery, here is a good suggestion for a destination – try visiting the French altiports.

Altiports are small airfields for small aircraft and helicopters located high up in the mountains, often serving a ski resort. The runway is usually short and quite steeply sloped (in the case of Courchevel, the slope is a solid 18.5%), and all landings are done uphill with no go-around procedure. Since the alitports are by no means in the mountain summit region, the approaches must be done in the confined regions of a valley, which means they are usually curved and somewhat dangerous. As a rule, no navaids are available, thus altiports can only operate in good weather – all this adds up to a challenge. In fact, the History Channel program ‘Most Extreme Airports’ ranks Courchevel as the 7th most dangerous airport in the world, and once you do your first approach, you will quickly discover why.

Flying the French Alps is significantly more interesting by using the highly detailed custom scenery which is available for free under a Creative Commons Attribution-ShareAlike 3.0 here. There are six altiports in the French Alps, L’Alpe d’Huez, Courchevel, La Rosiére, Mégève, Méribel and Valloire, along with a number of airfields in the valleys. The first two of these, L’Alpe d’Huez (LFHU) and Courchevel (LFLJ), have been modelled in detail for the custom scenery and are available from the PAF team hangar here. This package also contains a detailed model of Grenoble Le Versoud Aerodrome (LFLG) which is a good place to take off for a first look at Courchevel or L’Alpe d’Huez.

Here is a picture of the layout of L’Alpe d’Huez as it appears in Flightgear:

The challenges of mountain-flying

Beginners are probably better off with a powerful turboprop STOL aircraft like the de Havilland DHC-6 ‘Twin Otter’ which has the climb rate to pull out of dangerous situations, but the real challenge is better experienced in a small aircraft like the Robin DR-400. With a constant pitch single propeller and no retractable gear, this plane is, especially when passengers and baggage are on board, seriously taxed to climb over the high mountain ridges which in many cases reach above 11.000 ft.

The fuel and payload menu item allows to adjust both the fuel level in the tanks as well as any additional weight on board. Asymmetric weight distribution in JSBSim is in fact taken into account properly, if for instance the copilot weight is reduced in flight, the plane starts to roll.

Here, a DR-400 is lined up for takeoff in Courchevel with L’Alpe d’Huez as destimation. Since the airport is at an altitude of about 6500 ft, it is important to adjust the mixture properly to the altitude in order to get the full engine power for takeoff.

Once the engine is running at full power, the brakes are released and the plane accelerates quickly down the steeply sloped runway, becoming airborn halfway. Departing from Courchevel, it becomes readily apparent why the altiport is challenging and why there is no go-around procedure available.

On the direct way, the high ridges of the Vanoise National Park with elevations well above 9000 ft have to be crossed – with the fully loaded DR-400, this is a slow climb over snow-covered mountains.

Snowcover in Flightgear can be generated by shader effects with a user-controlled snowline. Since the shader effect does not place snow on steep slopes, the outcome looks very compelling.

However, also the lower valleys during the descent to L’Alpe d’Huez have a lot to offer.

This is the final approach, aiming between rocky cliffs. At this point there is still a chance to break off.

The final moments – we are committed to a landing now. The trick is to aim low and reach the threshold in level flight, then pull up to follow the slope of the runway, let gravity develerate the plane and let it touch down softly (if you try a normal approach on a runway with such a steep slope, you will break the gear) and not throttle back engine too fast, because the plane still needs to reach the top of the runway, and once the plane comes to a halt on the slope, the engine often is not powerful enough to get it moving again.

All went well – time to enjoy the company of the other pilots and have a coffee before heading back to Courchevel.

In bad weather, things can be much worse. If the valley is cloud-filled, there is no choice but to turn back if no good view of the airport is possible early on. And in gusty crosswinds, hitting the runway just right is a challenge on its own.

The beauty of mountain flying

However, once one masters the challenges of high-altitude flight and navigating in the confines of valleys, flying the Franch Alps in nice weather is primarily a good way to see spectacular scenery. Let’s head back to Courchevel!

Here, the DR-400 accelerates down the sloped runway of L’Alpe d’Huez – going down, airplanes accelerate much faster than one is used to on level runways, so we can get airborn in just a few moments.

Leaving L’Alpe d’Huez, the village and ski resort becomes visible. The winding road up from the valley is actually a popular mountain stage of the Tour de France.

The vicinity of L’Alpe d’Huez has deep valleys, spectacular cliffs and Canyons and steep, rocky mountain faces – one can fly through the valleys or high above the mountain ridges.

Enroute to Courchevel, we leave the high ridges behind and cross to the Vanoise Park in the vicinity of Modane.

Descending again, Courchevel becomes visible (just to the left of the screenshot) while the lower valleys vanish in afternoon fog.

Final impressions

Of course, one of the must-see destinations in the vicintiy is Mt. Blanc, towering at 15.781 ft above most cloud development. Its rocky lower slopes and steep cliffs make for some really spectacular scenery, and especially at sunrise or sunset, the view from the summit is spectacular.

As the sun goes down, the last clouds light up over L’Alpe d’Huez which is to be closed over the night. High time to get back to Grenoble.

Ocean Debris

On March 12, 2012 suspected Japanese tsunami debris was discovered washed up on the beaches of Long Beach, CA.  On March 11 a deserted fishing vessel was spotted off the coast of British Columbia; by March 24 it had drifted within 120 miles of the coastline.  For many years NOAA.gov has been monitoring an every growing area in the North Pacific dubbed the “Great Pacific Garbage Patch” that appears to be collecting and concentrating all manner of plastic debris from all over the world.  Whether you are a dedicated environmentalist, or a person that leans more towards managing and sustaining the Earth’s valuable resources indefinitely, or are simply annoyed at having to photoshop garbage out of your pristine vacation pictures; the rapidly increasing amounts of trapped ocean debris should be a concern for everyone.  How does any of this relate to the FlightGear simulator?  Please read on!

What is “Computer Vision?”

Computer vision is a broad field that involves processing real world images or video to try to automatically extract data or intelligence.  Applications range from identifying items or features of interest (such as facial recognition) to extracting geometry and physically locating or reconstructing the layout of a scene to manipulating images in clever or useful ways.  In many ways computer vision is a fascinating and magical   area.  We all have seen software programs that can identify every picture of our Aunt Tina on our computer after we’ve identified her face in one or two pictures.  There are computer vision systems that can track people or objects that move through a network of many camera views; computer vision systems can estimate your head orientation and even figure out what direction you are looking or what object you are looking at..  Computer vision software can recognize cars, read printed text, and scan for subtle features hidden in images — and because these programs are automated, they can run around the clock and process vast amounts of imagery.  They never get fatigued, they never get bored, and they never start day dreaming about their weekend plans.

Developing a Computer Vision Application

Writing an application to do computer vision is similar to writing any other application.  The basic cycle of edit, compile, test, repeat exists like with any other program.  Computer vision algorithms apply logical rules and procedures to the image data in consistent ways to accomplish their tasks.  There really isn’t any magic, even though the results do seem magical when they outperform the abilities or pace of a human.  However, it can be a challenge to develop some computer vision applications if you do not have good access to the kind of imagery you plan to ultimately be processing.

As you can imagine, computer vision applications must deal with huge volumes of data.  Often they process live video data from multiple cameras and that data may need to be associated with other data sources in real time — something that may not be possible to test in a lab with prerecorded video.

Imagine you are developing an application which will process aerial imagery to extract some data (i.e. facial recognition) or locate and track items of interest (i.e. a big chunk of debris in the ocean.)  It could very likely be the case that you do not have much sample video to test with.  In the case of ocean debrid, it may be that you do have video from the correct altitude or taken at the correct air speed, or with the correct camera field of view or camera angle.  However, computer programs are most efficiently developed in the lab with repeatable test data and not in the field with whatever random imagery the day offers — this can lead to a disconnect between what imagery is needed for effective testing and what imagery is available.

Hunting and Tracking Ocean Debris

For several years I have been involved with a company that develops UAV’s and remote sensing and tracking systems for marine survey and research use.  One of our primary partners is NOAA.gov.  NOAA has a keen interest in understanding, tracking, and ultimately cleaning up debris in the ocean.  With the Japanese Tsunami last year, the issue of debris accumulating in our oceans has become even more important and critical, yet there is no effective strategy available for locating and removing debris from the ocean.

A satellite can survey huge areas, but not at the detail to identify specific pieces of debris.  A manned aircraft can fly at several hundred kts and cover a wide area at a low enough altitude to spot individual pieces of debris, but there is nothing you can do when debris is located.  A ship travels very slowly and has a very narrow range of view for onboard spotters.  A ship might do 10 kts (give or take) and with binoculars a human might be able to spot debris one or two miles away — if they are looking in the right direction at the exact moment a swell lifts the debris up into view in front of the nearer swells.  The upper decks of a ship offer some height for observing debris, but swells hide objects more than they reveal them.   You have to be looking in the right direction at the right time to even have a chance to spot something.  In addition to all the other challenges of ship-board debris spotting, the rolling/pitching motion of the ship makes the use of binoculars very difficult and very fatiguing.

The following two pictures were taken seconds apart.  Can you spot the debris in the first image?  In the second? (You can click on them to see the full size version.)

A UAS offers numerous advantages over a human operator searching from the highest deck of a ship.  The UAS offers a much higher altitude perspective looking downward so that swells and waves can’t hide objects.  The UAS offers faster speeds to visually cover more area in the same amount of time.  The UAS can carry a variety of image sensors including IR cameras or multi-spectral cameras which offer increased ability to reliably detect certain types of objects under a variety of conditions.  Add computer vision software to process the UAV’s imagery and an effective debris location and tracking system begins to emerge.

The UAS has limited range though; and if a significant object is detected, it has no ability to tag or recover the object.  Thus it is important to combine UAV operations with a ship in the vicinity to support those UAV operations and be able to take action when something is found.

Visual Challenges of Computer Vision in a Marine Environment

As with any computer vision application, narrowing the scope and focus of the application as much as possible makes solving the problem easier.  Using the example of a UAV flying over the ocean and collecting imagery from a camera looking straight down, then the camera frame will always be completely filled with a straight-down view of the ocean surface.  We assume we don’t have to deal with the horizon, sky, or clouds or nearby coastline.  The result is that the ocean for the most part is some shade of blue — that is convenient.  Anything that is not blue is not ocean and then becomes highly interesting.  But despite limiting the scope of the problem in this way, the computer vision application still has to deal with several significant challenges: 1. Sun glint — the sun reflecting back at us off the water.  2. Windy days in excess of 12-15 kts produces breaking waves, foam, and even streaking (lines of foam) on the water.  Visually, sun-glint and foam impair our ability to spot objects in the water.

Why use FlightGear instead of real camera imagery?

FlightGear generates realistic views of the earth and offers complete control over the altitude, speed, camera orientation, and field of view of a simulated flight.  In addition, FlightGear can provide flight telemetry data and other data that is useful for testing or simulating real world environments.  We can also control the time of day, clouds, wind, precipitation and fly missions anywhere we like.  With FlightGear’s scripting engine, it’s possible to stage static or dynamic scenarios to create the sort of test cases we expect to be able to ultimately handle.  Of course only a small slice of computer vision applications relate to processing aerial imagery, but as UAV’s begin to attract the attention of more and more civilian and private organizations, the need for automatically processing huge volumes of imagery data will only increase.

FlightGear “Synthic Imagery” vs. real world camera imagery

As FlightGear continues to develop and evolve, the quality and realism of it’s graphics also are improving.  In the most recent version we have taken significant strides forward in drawing realistic ocean scenes that include accurate coloring, accurate rendering of different sea states and types of waves, very realistic sun glint, realistic sea foam (the result of breaking waves on windy days), and even rolling wake and foam created by large ships.  The quality of FlightGear ocean scenes can now (in many cases) make them almost indistinguishable from real camera imagery.

What is OpenCV?

OpenCV is a library of data structures and functions that offers most basic image processing tasks, as well as many of the more common advanced functions.  OpenCV provides the building blocks a developer needs in order to start writing a computer vision application.  OpenCV runs on Linux, Windows, Mac, and even Android.

How to connect an image processing application to FlightGear in “real time”.

Disclaimer: the nuts and bolts that I explain in this section are focused on the Linux platform.  These same tools are likely available on other platforms and may be leveraged in the same (or similar) ways to accomplish the same thing — but outside Linux your mileage may vary as they say.

I know how to capture a portion of my desktop as a movie and save it to a file.  My computer vision application knows how to read a movie file and process it frame by frame.  What is missing is that I want to be able to do this in real time without having to fly and save the video and the process it later.  My basic strategy is to first create a unix file system “fifo”, then write the captured video to this fifo, and simultaneously read from the other end of the fifo into my computer vision application.

1.  Start FlightGear at your simulated camera resolution.  I have a cheap web cam that does basic vga (640×480) video, so using that as my “standard” I can run: “fgfs –geometry=640×480″ to launch flightgear with the correct window size.  Next I drag the FlightGear window into the upper left corner of my screen so it is in a known location.
2. Make your fifo if it doesn’t already exist.  For instance: “mkfifo /tmp/ffmpeg-fifo.avi”
3. Start up the computer vision application:  ”my-vision-app –infile /tmp/ffmpeg-fifo.avi”
4. Start up the ffmpeg desktop movie capture utility (I have a little script I setup so I don’t have to remember all these options every time):  ”ffmpeg -f alsa -i default -f x11grab -s 640×480 -r 15 -b 200k -bf 2 -g 300 -i :0.0+1,58 -ar 22050 -ab 128k -acodec libmp3lame -vcodec mjpeg -sameq -y /tmp/ffmpeg-fifo.avi”

That’s all it takes and the computer vision application is up and processing live FlightGear generated imagery.  One thing I discovered with fifo’s.: it seems to work best to start the reader (the CV app) before starting the writer (ffmpeg).  This way the buffers don’t fill up and cause delays.

Results

Here is a snapshot of the anomaly detection and tracking in action:

The original image:

The image partitioned into water vs. not-water.

Dilating the mask (connects the noisy dots):

Eroding the dilated mask (to shink it back to approximately the original size and location in the image):

The final composite image showing the detected blob on top of the original frame:

Lastly, here is a youtube video showing all the pieces working together.  In FlightGear: I have created a random debris field scattered across an area of open  ocean about 6nm x  6nm.  I have added a downward looking camera to my test aircraft.  Then I built a route that flew several “transacts” (straight line paths) through the debris field.  I used the above mentioned procedure to feed the live FlightGear imagery into my computer vision algorithm that detects and tracks anomalies.  The debris you tend to see from the air looks very small — usually just a few pixels at best in your image, so the algorithm needs careful tuning to avoid false positives and missing objects.

Please watch this video in full screen resolution so you can see the specks of debris and the tracking algorithm in action!

Part I: Convective clouds

Author: Thorsten Renk

The screenshots shown in the following use shaders, textures and scenery which are for various reasons (incompatible license, too recent development,…) not part of the official Flightgear 2.6 release. However, these are available for download and every feature works with Flightgear 2.6. The following packages need to be installed in addition to get to see the same: lightfield shader package v1.1, Juneau custom scenery, and textures from regional textures v0.1.

An integrated weather system

Without a doubt, clouds, haze and fog are the most easily noticed features of weather in a flight simulation, followed by winds. Advanced Weather v1.4 is however more than a tool to draw clouds and set wind parameters – it is a system with a (limited) understanding what the weather which it currently tries to render is, and it aims to simulate features of atmospheric physics.

This means that different weather phenomena tie together – winds and terrain influence the way cloud formation is taking place, cloud formation and the formation of thermal updrafts is connected, and weather is always understood as part of a large-scale weather pattern involving high and low pressure systems.

At the same time, clouds and atmospheric haze also influence the atmospheric light (and now also the scenery) in an essential way – strong fogging changes the color of sunrises to a blue-grey, wave patterns on the ocean follow the wind strength and direction and rain causes visibly wet runways. Let us have a look at how this works in fair weather.

The formation of convective clouds

Fair weather is typically characterized by convective cloud development: The sun heats the terrain and the air layer just above, thus warm air rises up in ‘bubbles’ and forms thermals, as the air rises, it expands and cools and eventually the moisture condenses into droplets, forming the characteristic, cauliflower-shaped Cumulus clouds. Cumulus clouds are the most common example of clouds formed by pronounced vertical motion of air.

As every glider pilot looking for thermals has to learn quickly, the formation of convective clouds depends on many different factors. The terrain type is crucial – while rock or concrete surfaces heat well in sunshine and may easily lead to well-developed thermals and cloud formation, open water or ice is much less likely to heat up in sunshine and seed Cumulus formation. High points in the terrain mark the spots where the bubbles of warm air are most likely to lift off the ground. Another important factor is the time of the day: The sun needs sufficient time to heat the terrain, therefore Cumulus formation is densest around noon, but the thermal updrafts are strongest in the afternoon, and while pronounced Cumulus clouds are unlikely to form in the morning, the thermal energy accumulated over a day may still give rise to well-developed clouds in the evening.

Let’s follow the development of convective clouds during a day in Juneau (Alaska). At sunrise, only very few clouds form, and they are transient, whispy phenomena (click to enlarge images):

Later in the day, the cloud formation is somewhat stronger. Note how clouds tend to form over mountain peaks, but do not form over open water. Also, no strong cloud development occurs over Taku glacier in the upper left, despite its high altitude, as the ice surface does not heat well in the sun.

At noon, the thermal updrafts become stronger and consequently the clouds become more well-defined. While in the morning the upward motion of air rarely exceeds 0.5 m/s, around noon this becomes rather 1 m/s, to strengthen even more in the afternoon.

Yet a few hours later, the number of clouds decreases again as the thermal irradiation by the sun weakens, but then typically fewer but stronger thermals with larger cap clouds are found.

Towards sunset, there is still significant thermal energy left to lead to sizeable cloud development, although the number of clouds as well as the typical strength of thermals is decreasing again. During the night, the development of convective clouds breaks more or less down completely as there is no thermal energy from the sun available.

Interaction of convective clouds, wind and the terrain

Wind meeting a terrain barrier corresponds to an upward-moving airflow, and hence is able to alter the development pattern of convective clouds in an essential way. Consider the following scene above Maui (Hawaii) in the absence of winds. Clouds rim the peak of Haleakala, but do not actually reach all the way up to the mountaintop (note also that due to the different latitude of Hawaii, there is far more thermal energy coming from the sun than in Juneau, leading to a much higher overall density of clouds):

With 20 kt winds coming from the north, the picture changes quite drastically: clouds are now pushed up all the way to the summit of Haleakala by the rising air, whereas the falling air south of the crater creates a lee effect in which convective clouds disappear. The vegetation pattern of Maui reflects these prevaling conditions – while moist air is carried up all the way to the summit of Haleakala, it rains off and irrigates the northern slopes of the mountain, leading to a bright green forest belt. The southern slopes on the other hand see typically falling air and dissolving clouds, and are consequently much drier.

Convective clouds in flight

If the appropriate option is selected, thermals are automatically generated along with Cumulus clouds so that thermal soaring is possible. Combined with the effect of ridge lift, this can make for rather realistic mountain soaring conditions in which a good degree of skill is required to stay in the air.

But the detailed interplay between convection and the terrain leads to interesting scenes also in other planes. Around noon, the peaks of high mountains are often covered in rather dramatic clouds piling up against the slopes.

Further down, the altitude of the cloudbase is no longer determined by the terrain but by the air layers.

And yet, the terrain elevation and the change between land and water imprint a pronounced pattern onto the distribution of density, shape and size of convective clouds.

Convection may also occur due to vertical instabilities in upper air layers, leading to the development of Altocumulus clouds, or at even higher altitudes Cirrocumulus clouds. Here’s an example of the development of Altocumulus fields at 15.000 ft. At such high altitudes, the clouds are no longer influenced by the terrain underneath, but rather by the properties of the air layers between which the Altocumuli form. For instance, Altocumulus development may be caused by the instabilities associated with an approaching cold front, and may thus signal the danger of severe thunderstorms in the near future. The Advanced Weather offline weather generation automatically includes this and other rules of large-scale weather patterns.

Next: Layered clouds, haze, fog and precipitation

The Challenge

As a skydiver adds more gear such as front packs and items strapped to legs or arms, the jumper’s basic stability in free-fall is reduced.  It becomes easier to tumble out of control and there is less margin for error.  Similarly, the aerodynamic wake of the jumper may interfere with pilot chute opening (known as “hesitation”). Investigating different gear configurations generally involves vertical wind tunnel testing, or actual tests with jumpers. To avoid some of the cost, and mitigating safety concerns, a tool to computationally analyze these jumpers and their gear is highly desired. Creare, Inc., an R+D research firm in Hanover, NH, under funding from the US Army, developed a Computation Fluid Dynamics toolkit for analyzing jumpers and their equipment, and model the resulting configurations in FlightGear.

Note: a flyable parachutist model is available to download and test at the end of this article.

Fluent (CFD) and Stability Derivatives

CFD = Computational Fluid Dynamics.  ANSYS Fluent is a high end CFD that models flow, turbulence, and heat transfer in 3d.   Imagine being able to take a 3d model of a sky diver (or an aircraft) and place it at different orientations and different poses.  Then for each orientation and pose, run a computer simulation of exactly how the air flows around the sky diver, where pockets of turbulence are generated, and what forces and moments are produced.  Imagine all the combinations of roll and pitch and body poses possible — it leads to a huge number of combinations.  Now imagine repeating that for several different arrangements of front and back packs and other equipment.  You will need a cluster of computers running for days or even weeks to compute all the permutations just for a single pack configuration.  This is essentially a “virtual wind tunnel” running on a super computer cluster of PC’s.

In the case of the parachutist simulation: the amount of computation time required to generate 2 scenarios (with a back pack and without) was approximately 25,000 cpu-hours — or around 2 years of compute time on a single processor PC.  1000 individual simulations were run, each involving approximately 4 million “elements”.

Validation

Real world testing and data collection was performed in a vertical wind tunnel (such as the one linked here.)  This real world data could then be compared to the the Fluent (CFD) results to validate and possibly improve the computer model.

Real Time Simulation

Build-Up of Coefficients:

• For each component of the model, the local angle of attack and sideslip angle are calculated from the combination of the limb orientation and the overall angle of attack and sideslip of the entire model.
• For each of the six degrees of freedom, the contribution of the model component to the overall aerodynamic response is calculated from tables of non-dimensional coefficients:
  C_Fx,y,z = F_x,y,z / ( q_∞ * A_comp )
  C_Mx,y,z = M_x,y,z / ( q_∞ * A_comp * L_comp )
• The two-dimensional lookup tables are compiled from data extracted from the CFD results in the Solution Database.

Forces and Moments:

• Aerodynamic forces and moments are transformed from the local frame to the global frame and then summed.
• Resultant forces and moments then determine accelerations, velocity and turn rates are calculated, and the model iterates.

Creare partnered with Jon Berndt (the founder of JSBSim–one of the core physics engines used by FlightGear) to contribute some clever additions to JSBSim that permit a “blade element” approach to parachutist modeling.  Jon helped tremendously optimizing and integrating the required new code into JSBSim which then ultimately led to its inclusion in FlightGear.  The parachutist physics model is an order of magnitude more complex than a typical aircraft model.

Figure Animation and Posing

The character model is built out of several animated subcomponents: left & right forearms, left & right upper arms, left & right lower legs, left & right upper legs, head, torso, and pelvis.  The model parts are attached in a cascading fashion like a real figure, and each joint can be rotated through all 3 axis (roll, pitch, and yaw.)  In order to avoid unrealistic contortions, sensible joint range of motions are defined.

There are a number of predefined poses where the appropriate joint angles have all been worked out in advance.

• Box: a neutral pose minimizing rotational or translational motion.
• Left & Right Translation: mirrored poses that induce a “slide” either to the left or right.
• Anterior Translation: a pose that induces a forward slide.
• Posterior Translation: a pose that induces a rearward slide.
• Left & Right Dorsoventral: mirrored poses that induce a left or right rotation (yaw.)
• Dorsal: a “spread eagle” pose that maximizes surface area and thus minimizes decent rate.
• Ventral: a “compressed” pose that minimizes surface area thus maximizes decent rate.

You might notice that these poses map rather neatly into well understood pilot controls similar to flying a helicopter.  For the FlightGear simulation we can mix these poses together in proportion to the corresponding joystick axis deflection and throttle position and fly the sky-diver intuitively.  For those that doubt, this actually works quite well!

Visualizing CFD Flow-lines

One of the neat things that a CFD analysis can produce are airflow lines that pass around the model.  We can take the 3d flowlines that are produced by the CFD and attach them to the 3d model of the figure.  This allows visualizing the flow lines from any FlightGear perspective.  One interesting technical challenge is that the flow lines need to keep a fixed vertical orientation even though the model may roll or pitch, yet the flowlines must track the heading/yaw of the model.  This can be done by setting up appropriate inverse transformations in the FlightGear model animation configuration file.

Smoke and Trajectory Markers

FlightGear offers additional visualization aids.  The model is set up to support emitting smoke.  FlightGear smoke drifts with the prevaling winds (which can often be substantial at higher altitudes.)  The model is also setup to emit “trajectory markers” at a fixed rate.  The trajectory markers stay fixed in 3d space and represent the actual path the sky diver follows.  In addition they represent the orientation of the sky diver at that point in space.

Where is the Parachute?

This exercise is setup as a free-fall simulation, not a parachute simulation so there is no chute modeled.  Instead the simulation is mercifully paused when the altitude reaches 100′ above the surface.

Download and Fly

Follow these instructions to download, install, and fly the Creare Parachutist model:

• Note: the parachutist model is not compatible with FlightGear v2.4, you must fly this model with one of the v2.6 release candidates, or the official v2.6 release scheduled for February 17.
• Download the Creare_Parachutist-v1.0.zip file.
• Unzip it into your FlightGear “Aircraft” folder.
• Start FlightGear and select either –aircraft=Parachutist-Scenario1 or –aircraft=Parachutist-Scenario2
• Make sure you specify  an initial altitude (such as –altitude=10000), otherwise you will just be sitting at the end of the runway working on your tan.
• Press F1 and F2 to toggle the two available dialog boxes on/off.
• You can manipulate the joint poses individually or select from a set of pre-defined poses, or select “Joystick” control and fly with a joystick (or keyboard or mouse) similar to flying a helicopter or airplane.

Credits

• Dietz, A. J., Kaszeta, R. W., Cameron, B., Micka, D. J., Deserranno, D. and Craley, J.”A CFD Toolkit for Modeling Parachutists in Freefall”, presented at the 21st AIAA Decelerators Conference in Dublin, Ireland, 23-26 May 2011. Paper AIAA 2011-2589.
• The Creare Freefalling Parachutist model was developed by Anthony Dietz (Principal Investigator), Richard Kaszeta , Benjamin Cameron, Daniel Micka, and Dimitri Deserranno of Creare, Inc., as part of an SBIR Phase II project sponsored by the U.S. Army RDECOM Acquisition Center under Contract No. W91CRB-08-C-0135. Additional contributions we made by Curt Olson and Jon S. Berndt as consultants. The resulting parachutist model is unvalidated and therefore, should not be used other than for demonstration purposes. Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the US Army RDECOM Acquisition Center.  Due to the significant contributions made to the project by several open source developers,  Creare has released a version of the resulting parachutist model to the open source community for continued development and use.  The FFTK itself continues development as a proprietary Creare project. For information on the FFTK itself, please contact Richard Kaszeta at rwk@creare.com, or 603-643-3800.
• Flightgear modeling, animation, and scripting – Curtis L. Olson

Do you want to earn your astronaut’s wings?

Author: Thorsten Renk

Real spaceships aren’t actually piloted into orbit. The risk that a human being, strapped to his acceleration seat and under a crushing acceleration of 4 g for a prolonged period of time is unable to fly with the precision required to reach orbit is far too great, and real spacecraft reach orbit on autopilot.

But what would it be like? Welcome to a scenario in which a Russian Vostok spacecraft has been acquired by the USA and fitted for a manually flown mission.

This is the launch vehicle assembled at Edwards Airforce Base. The actual capsule is hidden under an aerodynamically formed protective cover. Below it is the third stage of the rocket, with its exhaust nozzle visible. All this is mounted on top of the huge first and second stage. Unlike many US rockets, which use sequentially burning stages, the first stage of the Vostok launch vehicle consists of four boosters which burn along with the long, cylindrical second stage.

The inside of the spacecraft is a very small place. There are no big windows (and currently the protective cover blocks the view outside in any case), so there is not so much to see except the instruments. In front of me is the main instrument panel, and to the right is the stage control panel, left of it the control handle.

Here’s a closeup onto the main instrument panel. Since I won’t be able to see anything of the outside during much of the ascent and the descent, this is what I will have to navigate with. The most important instruments are in the lower half of the panel – altimeter, inertial speed indicator, vertical speed indicator, dynamical pressure, orientation and acceleration. This isn’t enough to fly with any precision, say to rendezvous with ISS – but that’s not what the Vostok is for, it’s made to carry a human into orbit and back, and this is what I will do.

One of my most important aids however is a handwritten cue sheet which tells me roughly at what altitude, velocity and orientation the rocket should be at a given time. Without such reference, it is very hard to gauge whether the rocket is on a good ascent path or not.

Unfortunately, the ‘not being able to see too much’ is also a technical limitation. The Flightgear rendering engine is not designed to handle views from low Earth orbit, and even with the cutting edge development high altitude and extreme visibility rendering I’m using in the following, the view doesn’t really measure up to real views of Earth from orbit.

After igniting the engine, the thrust takes a few seconds to ramp up, but the Vostok rocket delivers a solid 2 g initial thrust with first and second stage burning, so I lift off quickly. After the first few seconds, I rotate the rocket around its main axis such that I am facing my launch heading. To make use of Earth’s rotation, launches are done eastward. As soon as I reach the desired heading, I push the ascent path out of the vertical along my launch vector to about 60 degrees with the horizon. During ascent, I will thus be more and more hanging face-down in the capsule, facing Earth at all times. Which is very reasonable, because in case of any instrument malfunction, this gives me at least a rough visual reference. Of course, the actual forces in the capsule are nothing like hanging face-down, the acceleration always pushes me back into the seat.

After passing about 20.000 ft, the dynamical pressure starts growing large, and I have to throttle back to avoid damage to the rocket. After all, a rocket is little more than a thin shell around fuel tanks: For instance, the second stage weighs roughly 100 tons at liftoff, but its empty weight is a bit over 7 tons. The air thins rapidly, however, and thus the dynamical pressure decreases quickly and I go to full thrust again. Once above the pressure peak, I push the nose of the rocket further down to 30 degrees with the horizon and start building up forward velocity while Edwards AFB vanishes below.

The full power of the JSBSim flight dynamics and atmosphere model affects this part of the ascent, and so the interaction between rocket and atmosphere is as realistic as the available data on the Vostok can make it.

After about 90 seconds, the fuel of the first stage boosters is almost spent, and the reduced mass of the launch vehicle ramps up the acceleration to 4 g and beyond. Once again, I throttle back to stay below 4 g to avoid damage to the rocket. At about 120 seconds, the first stage is out of fuel, and I separate the boosters. I am now high enough that air friction is negligible, and so I also blast the protective cover off the capsule and can take the first look outside (nothing much to see though). The second stage is still heavy at this point, and so the thrust goes back to about 2 g as we climb the 100 km altitude limit into space.

The whole flight dynamics changes quite drastically during a mission from the initial launch vehicle to the re-entry of the capsule. Also the weight of spent fuel is a significant factor. All these effects are quite distinctly felt during ascent to orbit.

At this stage, I have to start watching my ascent casefully. The second stage separation should bring me roughly to my orbital altitude with about zero vertical speed so that the third stage burn just keeps me at this altitude while accelerating me to orbital velocity of a bit more than 28.000 km/h. However, the second stage reaches more than 4 g thrust towards the end of its burn, while the third stage starts with barely 0.5 g thust, so any mistake I make at this stage will at best take very long to correct with the 3rd stage burn, at worst be unrecoverable. Thus, I control the pitch angle very carefully and monitor altitude and vertical speed.

About 5 minutes after launch, the second stage burns out and I separate it as well and ignite the third stage. Flying a rocket is very different from flying an airplane – while an airplane reacts to its immediate surroundings and doesn’t remember much of what was five minutes ago, the rocket’s current state is pretty much determined by what happened the last five minutes. If the ascent to this stage was bad, there’s nothing much I can do to correct it now. But my altitude and speed after 2nd stafe separation are within reasonable parameters, and so I continue build up speed while keeping my altitude with the half g thrust the third stage provides.

Another five minutes later, close to reaching orbital velocity, I have to throttle down. The speed must be reached quite accurately, otherwise I might go into an elliptical orbit rather than an almost circular orbit. And this is problematic, because the TDU has even less thrust than the 3rd stage, so if the 3rd stage brings me too high, I might not be able to de-orbit at all.

There are also technical reasons – Flightgear currently isn’t designed to handle an altitude above 150 km, so I have to reach an orbit below 150 km and above 100 km where the atmosphere is thin enough.

I watch the perigee indicator carefully, and as it starts rapidly climbing, I separate the 3rd stage – I am in orbit! Apogee and perigee indicators read 128 km and 140 km, so while not completely circular, this is reasonably good.

Flying to this stage isn’t easy – only three Flightgear pilots have to my knowledge reached a stable orbit with the Vostok spacecraft. You have to work for your astronaut’s wings!

From this point, I only have the minimal thrust of the TDU available to turn the spacecraft and decelerate. Rather than aerodynamical controls, I now have to fire thrusters to change my attitude, so the spacecraft handles once again completely different.

JSBSim handles the attitude control thrusters just as well as the aerodynamical controls, and the spacecraft handles again very plausibly at this stage of the mission.

There’s not much to do while drifting along in the orbit. Look out and watching the sunrise is nice though.

The cutting-edge development experimental lightfield shader brings out the Earth shadow moving across the terrain, the stark shadows in low light and the differential light dependent on altitude very nicely.

To de-orbit, I turn the spacecraft around and fire the TDU main engine to use up the remaining fuel. This lower my perigee such that it intersects with the atmosphere – the friction will have to take care of the rest. Then I separate the TDU as well. At first, the first gentle touches of the atmosphere lead to a tumbling motion of the capsule, this then stabilizes as the drag increases, and I start falling faster and faster.

If you though the 4 g during ascent where tough, then you haven’t experienced re-entry yet. As the capsule finally reaches the lower atmosphere, a deceleration force of 8 g and more brutally brings me from orbital speed to a few hundred km/h. I simply black out during this stage.

Flightgear optionally simulates blackout and redout due to extreme acceleration at set limits.

By the time I get conscious again, I have an altitude of about 10 km and most of the speed is gone. Time to get the brake parachute out and kill the rest of the forward motion. After the braking parachute has done its job, I get the main parachute out, and once my vertical motion has slowed down, the final task is to activate the soft landing sensor.

Close to the US west coast, I gently splash into the ocean. Nothing to do now except to sit tight and wait for the recovery crew to pick me up…