Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Edding3000]

Its just an presentation to a book, still has a buch of problems in math.-terms free to get from the net :
http://www.princeton.edu/~stengel/MAE331Lectures.html
I think, for the debate, the 16, 19, 20 and 23 lectures are the ones to be worth looking at in detail. But all of them are really interesting. ... hope it helps a little.
As for te book : Robert F. Stengel-Aircraft Flight Dynamics
... pilots have a lot of math to do too. Getting it to a intuition level is actually the point of it, so they can fastly assume and correct effects in-flight.

It's not thát much . The most difficult thing is calculating holding procedures, and that involves only a sinus/cosinus and some multiplications!
It's not that hard!

[Cid250]

Interesting post about a developer of flight model:

http://www.hoofsperformance.wwiionline.com/flight_model_details.htm

This flight model was unfinished and limited to the hardware available at year 1999... with current hardware it can be improved a lot.

[...]

The numerical integrator used in WW2OL (at least the one it had when I left the company four years ago) is a 2nd order Trapezoid rule integrator.  A common integrator used in scientific applications is a Runge Kutta 4th order integrator.  This yields good accuracy, but has a major drawback: it requires several derivatives per timestep.  Due to a number of reasons, the WW2OL flight model had a very expensive (in CPU time) derivatives calculation routine.  In English, the forces and torques calculation is very expensive (especially when a vehicle has 30+ components).  We achieved a rate of 50 cycles per second for the flight model loop for the target computer of the time, meaning that the maximum timesteps the flight model could use using a 4th order Runge Kutta integrator would be 12.5.  Obviously waiting for 1/12.5th of a second before seeing responses to your control stick inputs would be unacceptable (imagine seeing a movie at 12.5 frames per second), so an integrator was needed that didn't require as many intermediate steps.  Ideally, an integrator that used only one derivative per timestep would maximize the responsiveness of the flight model to user input, however, the fewer timesteps determined, the lower the order of the integrator, and worse the results.  An implicit numerical integrator called the Trapezoid rule uses the last and current derivative in order to improve the accuracy of the integration while limiting the number of derivatives needed to one per timestep (it actually uses two, the second is from the last timestep).  This gives better accuracy (the technical term is a higher order truncation error) than the typical 1st order Euler integrator that also used only one derivative calculation per timestep (not to be confused with Euler's equations of Motion).

An example of a simple integrator (Euler integrator in this case) is to take the derivative and multiply it by the timestep to get a change in the variable.  Say you're updating an airplane's position and you have it's current velocity.  Multiply the velocity by the timestep, then add the result to the position.  You now have a new position.  This computed position is only an approximation of the actual result if the change was continuous.  Higher order integrators reduce the error and more closely represent a continuous situation (such as real life).  In addition, smaller timesteps also improve the accuracy of the integration.

The flight model runs at a rate of 50 cycles per second, with a time propagation of 50 timesteps per second.  This means the flight model works exactly the same regardless of machine or frame rate.  In order to produce a smooth visual effect, and to determine exact position and orientation on each render frame, the position and orientation of the vehicle is interpolated between the last computed state vector (last flight model cycle), and the current time.  This principal is similar to how the smoothing code interpolates between updates received from the host on another vehicle's position/orientation (which is at best, three to four updates per second and can be as low as one update every two seconds).  This means you can fly by a target at 20fps, 50fps, 85fps, or whatever the current frame rate and the view looks smooth (as smooth as the frame rate).  However, the flight model is only updated at 50hz, meaning it's average response time is 1/100th of a second and can be as low as 1/50th of a second if you get unlucky, but this means it has that response time even at frame rates lower than 50hz.
[...]

[PytonPago]

C´mon guys ! ... we want some Outerra videos and photos to be seen. That stuff can be settled in PM´s and by a "cup" of beer  . Cameni, i just thought, it would be nice to see some of our birth-place screenshots (in the screenshot thread that is, and if it doesnt be a timepresser of course|, like Namestovo city space whyte the look catching the dam. Must be an interesting look to see the terrain before it was flooded after the 2.W war ... at the Orava castle is an great plastic-map from 1906 (if im remembering it right, is about 1, x 1,2 m big| i liked to look at that certain place, and the towns that must have been deserted.

[cameni]

I moved the infected part of this thread to offtopic, so some people can learn how to explain things in a simple, effective, polite way there. Or not.

Anyways ..

C´mon guys ! ... we want some Outerra videos and photos to be seen. That stuff can be settled in PM´s and by a "cup" of beer  . Cameni, i just thought, it would be nice to see some of our birth-place screenshots (in the screenshot thread that is, and if it doesnt be a timepresser of course|, like Namestovo city space whyte the look catching the dam. Must be an interesting look to see the terrain before it was flooded after the 2.W war ... at the Orava castle is an great platic-map from 1906 (if im remembering it right, is about 1, x 1,2 m big| i liked to look at that certain place, and the towns that must have been deserted.

The problem is that we don't have satellite data from that period
With lakes not yet supported, the terrain is flat there. I'm was thinking about some algorithms that would create the lake beds out of the available data, though it's going to be random. Or have people submitting the data for their regions, produced from old maps.

[PytonPago]

Well ... so then. Must hawe been some nivelation screening of the terrain for the dam-building. Maybe there will be some data on that in some Oravan archives ... will try find some if possible.

[[deleted]]

Ok someone didn't understand what I said but anyway...
I was meaning to the time 2.03 of the video where he does a loop and entering stall. So I said "ok let's get a proof" and here you go.




You can easily stall with the cessna and here is the proof.

P.S. you said too the speeds were low, so now don't contradict yourself please

[Edding3000]

Speed has nothing to do with an aircraft stalling. It is all about angle of attack, which has nothing, nothing, nothing to do with speed!

And yes this are stalls that are not corrected properly (opposite rudder, lower nose, apply power).

[[deleted]]

Speed has nothing to do with an aircraft stalling. It is all about angle of attack, which has nothing, nothing, nothing to do with speed!

And yes this are stalls that are not corrected properly (opposite rudder, lower nose, apply power).

Nothing ? I can't approve.

http://en.wikipedia.org/wiki/Stall_(flight)

[Lieste]

Stalls are 100% angle of attack - the whole wing need not stall at once and it is usual that the designer will induce the root to stall first (rectangular wings particularly, but semi-tapered wings to some extent). Twist can be used to allow this desirable characteristic in elliptical wings, but this is at the expense of their marginally better induced drag in the untwisted condition.

Even an aircraft that 'cannot' be stalled (because of inadequate pitch authority), will do so if it is zoomed to a steep attitude and held there. If this is insufficient, then applying crossed rudder and aileron will normally induce a spin, which is an auto-rotative spin where MOI may hold the nose up.

A benign aircraft will usually unstall and exit a spin by itself (or at worst with moderate control movements in the correct directions for the aircraft arrangement (aerodynamic and mass distribution)).

[Aman]

Sure, the angle of attack is the major thing bringing a plane to a stall.
BUT, the slower you fly, the faster this will happen.
If you fly fast enough and have plenty of power in the rear, you will never get a plane to stall.
So, speed IS a part of getting a plane into stall.

Speed has nothing to do with an aircraft stalling. It is all about angle of attack, which has nothing, nothing, nothing to do with speed!

And yes this are stalls that are not corrected properly (opposite rudder, lower nose, apply power).

[Lieste]

At a given apparent weight (ie mass x g load) the stalling AOA and stalling speed are nearly constant (ignoring hysterysis and rapid onset variations)

However, as an aircraft can fly at varying mass (payload/fuel/structural/equipment) according to configuration, and it manoeuvres almost entirely by altering the g-load (by changing the AOA) it can be seen that stalling speed will vary enormously (a 6g capable airframe with a 50% useful load will have a range of stalling speeds with a factor of 3 (ie 100KIAS and 300KIAS) - It will probably not be capable of much more than 6g at low weights, even if it remains capable at nominal MTO, as many fittings (eg equipment, engines, fuel tanks and lines, pilot seat, instruments are only mounted to '6g' (plus the usual safety factors) mountings.) By comparison, the AOA at which airflow separates will be nearly constant - the character of the stall will usually be sharper and with more buffet and rates after the break when loaded to above 1g, but the orientation or load/airspeed will have little difference to 'when' the aircraft stalls. (Ie you can stall while diving vertically, if the AOA increases too much during a pull-out manoeuvre.

[Simbuilder5]

That is truly amazing. I would love to see working dials, rain, clouds, and tunnels.

[OGREMAN]

Well, whatever the behavior is or should be, it ought to be addressed to JSBSim that does the simulation. Though it's entirely possible that we are using a wrong physics model, or not enabling what we should. In any case, this can get fixed when some JSBSim people get their hands on it.

I will first offer my appologies to the Outerra Team because having made a negative comment about the apparent motion prtrayed in this video I failed to clarify my remark with any explanation and that is not a fair or responsible thing to do. I have not followed this as closely as I should have as I was distracted by the arrival of my first grandson into the world and the installation of my new PC into my dedicated flight cockpit replica.

I have now re-watched and thought carefully about the apparently strange motions of the aircraft shown in this otherwise brilliant video.
The problem with it boils down to two issues, 1st is :- camera behaviour ... the camera is positioned in a tethered state but the tether is clearly perfectly fixed in space when in reality it is almost impossible to maintain a perfectly fixed reletive camera position on an object in flight, there should allways be RELETIVE MOTION betwee two objects in flight.

2nd issue is :- Aircraft centre of mass pivot point, whenever the aircraft was changing attitude in pich or roll it was painfully clear that this motion was occuring around a fixed unmoving point in space (presumed to be the aircrafts centre of mass). Such a crude movement contradicts what all pilots know to be true, that the aircrafts motion while loosely acting around its centre of mass is greatly variable because of the effects of inertia and aerodynamic forces, (in short the fixed pivot point that the aircraft is revovlving around is wrong) and is instantly recognised by any pilot as completely counter to their experience.

I hope this attempt to clarify my comment is usefull and please accept my regrets at not having written this up before.

[mctash]

What I find important in this project is that this is the first engine to my mind that demonstrably replicates in some part the true beauty of the natural world. In that respect Outerra is a revolutionary feat (specifically around 1:20). Some of the scenes in this film make hairs stand up on that back of my neck. Truly amazing stuff.

[Chris M]

Interesting post about a developer of flight model:

http://www.hoofsperformance.wwiionline.com/flight_model_details.htm

This flight model was unfinished and limited to the hardware available at year 1999... with current hardware it can be improved a lot.

The numerical integrator used in WW2OL

W/o reading this full thread and only roughly your quote:

The quoted text is about the choice of integrator to solve the differential equations of the flight model.

You can either study maths (especially the dicipline numerics) to figure out the best integration method for the special type of probelm you've got.

Or take the easy approach: as long as you aren't leaving the stability region it doesn't really matter. Especially as we have the big constraint of doing it in real time we are bound by a explicit method with a fixed step size. So just use an Euler1. That's how the whole engineering world is doing it.

And if you figure out that the current problem doesn't fit for an Euler1 you can still figure out ways to get around it (e.g. by embedding an implicit solution in the explicit solver).

As JSBSim has much more useage than Outerra you can be sure that if such a problem would pop out, it's seen somewhere else first and then solved...

And one more point: the flight dynamics are a real simple set of differential equations. The hardware of 1999 could easily handle those... The biggest difference in the "old" and the current hardware is a explosion in graphics capabilities. And the advancement of CPU could be used for AI.