Outerra forum
User mods, screenshots & videos => Aircraft => Flight Model Development => Topic started by: bomber on March 02, 2015, 07:30:56 am
-
http://www.faa.gov/regulations_policies/handbooks_manuals/aviation/pilot_handbook/
Please read chapter 9
It's an easy read, yet very informative.. This is my bible on any subject with regards flight and I'd like to see it as the No.1 reference arbiter for discussion on a variety of subjects.
Once we're all clued up on CoG and Weights, I'll explain why I've split the vanilla JSBsim fight model file (see JSBsim manual http://jsbsim.sourceforge.net/JSBSimReferenceManual.pdf ) into separate files and what that means to you as a plane builder. We'll then talk about what assumptions have to be made and what simple tools are needed and any templates that can be provided to get a plane into the air with a very reasonable representation of it's performance.
Simon
-
Hi Simon.
That is a great resource I haven't seen before, great read. The next chapter, Chapter 10: Aircraft Performance, is also very informative. Thanks!
I see what you meant about calculating moments about the 'datum' point in the FDM.
I agree that splitting the FDM into multiple files for each section is best for many reasons. For one, a complex flight model could easily be tens of thousands of lines. Have you developed a different scheme than the one used in the original JSBSim FDMs? I'm really interested to hear what you have developed and how you suggest we go about developing more advanced flight models.
Regards,
Uriah
-
A point of confussion with CoG's is that it's a moving point on the plane defined from another 'given' point... a datum.
But if you find published data for a planes weight ballance (good luck with that) the datum isn't alway in the same place across different planes. sometimes the datum is taken from the engine mounting, prop spinner, pilot position...
I advocate using the pilots position as this allows the modeller to imagine that every object in front of him has a -ve X co-ordinate and every object behind him has a +ve X co-ordinate... this simplifies things and makes spotting errors a lot easier...
As to the FDM being different from the published JSBSim manual.... it's as different as chalk and cheese.
Let's get all the cards on the table with regards this, so as there's no confussion..
The JSBsim manual offers up one approach to flight modelling using it's very versatile programe. JSBsim can be used differently, and I've chosen to do so....
My flight models have no resemblence to the established accedemic norms and as such I've faced critism... but I'm quite happy to have people challenge the principle behind it.
I'm either an idiot, too simple to comprehend the mathmatical complexities or a genius.... the jurys out.
-
Hi Simon,
What is the principle behind it? Can you post an example and explain the basics of how it works?
Regards,
Uriah
-
Crickey ask a hard one why don't ya :)
In reality I only get one shot at this, it's either a hit or a miss, once people have made their minds up it's very difficult to change... once pronounced a crack-pot it's a tag very hard to shift.
The objective I set out to create was a system for producing flight models that an idiot could follow... a flight model at that point (idiot involvement only) that produced a flight model better than the best that could be produced at present but not as good as once a flight modeler got involved.
It's a 2 teir flight modelling design....
The principles...
Weight and Ballance are estimated using a spread sheet of build density.
2d force co-efficients are determined using java foil/prop programe for the airfoils and control surface positions.
Each wing is split into 8 sections, using 2d co-efficents the force generated using Angle of Attack (AoA), dynamic pressure and area is calculated and using trigonometry lift and drag vectors are resolved.
Each section of wing can have it's vectors adjusted acording to damage or surface condition
The resulting lift vectors for each wing are then summed to determine the overall lift of the wing and it's moments.
From the overall wing lift the co-efficient of lift is calculated and used to calculate the induced drag.
Form and Skin drag are calculated separately and applied to the airframe as armature distances to produce dampening moments.
So it's basically break the plane down to individual small pieces, calculate the forces, add them together, calculate the moments..... and apply forces and moments to the model.
-
I think that sounds like an excellent system! For one it would allow definition of different wing profiles and more complex aerodynamic geometry. I do not think that is a crazy idea whatsoever. Can it be more or less than 8 sections?
Regards,
Uriah
-
Yes.... less or greater than, however the front end of the flight model (tier 1) must match the back end (tier 2)
If you have say real stubby wings (like on a cruise) you might not wish to have 8 but instead 2 sections in which case you'd simply create a front end with 2 sections and ask a back end modeler to adjust these files whilst he's updating the co-efficients tables.
-
I see so Tier 1 is where define each section and Tier 2 integrates the forces?
With this type of configuration would it be possible to define all types of aircraft geometry? Fuselage, winglets, canards, and different configurations of stabilizers, also defining parameters such as dihedral, or wing that are above or below the fuselage. As we know, high set wings brine the center of lift above the center of gravity and such configurations are inherently stable. On the other hand low set wings, such as the F117 Nighthawk's make that configuration inherently unstable in pitch and roll, but this static instability leads to high maneuverability.
Also, how can we improve aerodynamics of swept wings as opposed to straight ones? Not to mention the Aerodynamic Center is further aft on swept or delta wings, but the drag is also reduced at higher Reynolds numbers. I would be interested in A B testing an aircraft with two different wing types having the same effective surface area and seeing how the flight characteristics compare. I am not sure if the JSB model currently can handle sweep, do you know?
You are aware that there was a big fix so we can now output flight data to CSV format?
Best regards,
Uriah
-
All geometry is configurable... so you want to put canards on or have a bi-plane with 2 wings one about above the other... then it's there for ya.
Incidence, sweep and dyhedral for wings, h-stabs plus wing flex are all included
-
It sounds incredible! Excellent work Simon.
So we start with the simplest possible aircraft, Wright Brothers for example, and once we have that where we want add complexity over time.
What needs to be done? What areas do you need help in?
Regards,
Uriah
-
The Wright Flyer was a suggestion because it taps into a market, ie those that go visit the museum.
We need a model importing, I'd suggest it to could be used as a step by step tutorial.
I'd like to take this forum through the process of the front end, step by step.
Simon.
-
I'd not however suggest the Wright Flyer as a tutorial for the few reason that it's not typical of the majority of single wing planes... it's a bi-plane, has two rudders and uses wing warping.....
It's not really going to help lead people into flight modelling their plane... I'll do it, on the side because i think is should be done, but frankly I'd like an easier life.
I'd suggest another glider...
-
The Wright Flyer already available for Flightgear is not suitable for adaptation?
-
I don't actually subscribe to using work created for another sim, the politics can be mind blowing.
-
You're right, albeit one of the first, the Wright Flyer is an unconventional configuration.
I really feel that we at least need to do something powered. Single engine, traditional airplane configuration, but at least powered. This is because in a glider it really limits our flight testing envelope, considering the angle of attack cannot exceed a small margin without stalling and the glide slope has a maximum far below what we need for level flight, which I consider the minimum benchmark for comparing flight characteristics and performance. Also, consuming fuel during level flight will lead to improved flight characteristics due to less wing loading, so we can run a test with the autopilot set to hold roll and pitch, and output the CSV data to analyze the changes over time as the mass decreases. The ASK-13 is an excellent glider, and really your proof of concept for the system. I don't see a reason to do another glider as an example for people to work from, as not many people are going to build gliders honestly, there is only the ASK-13 that I know of for Outerra and about 40 jet aircraft. It would be far more helpful if we could dial in a powered aircraft FDM, however simple it is.
I spent about two hours flying the ASK-13, and have to say I dismissed it far too fast before. It is a powerful proof of concept. I would defend it against any criticism on the basis that it is already superior to any FDM JSBSim has to offer in their library. The post stall handling characteristics are exceptionally poor, and by that I mean excellent! If you go into a dive and pull back up, the velocity actually decreases due to increased drag like it is supposed to. Also the stability near stall speed feels far more realistic than any of the other aircraft.
I looked through your FDM and I can write a program to generate those .xml files automatically from an input configuration file. We could include parameters to define as complex of geometry as necessary, but initially it could be simple and expanded in scope over time.
There is also another option, we develop a modular back-end to adapt for changes in the front end? This way, T2 would have the maximum number of sections for a wing, and you would define 'n' number of sections in T1, and T2 would handle 0 - n sections as necessary.
Best regards,
Uriah
-
The Ask-13 is as you say just a proof of aerodynamic concept,
A flight model consists of 3 parts
1) Weight & Ballance
2) Aerodynamics
3) Thruster
By not having the engine, errors in my thinking of what occurs in No.1 and No.2 become clearer, which helped ensure I wasn't misleading myself.
I'm up for any plane, maybe the cesna, as we could then compare ? I would prefer a piston/prop combination as there's a whole raft of issues surrounding both the creation of the engine and prop which people have to get their heads around.... plus there's the posibitly of gaining interest in improving this part of the JSBsim C++ code.
With regards Automatic backend generation I'm all for, but not at present as I think it needs to be kept all manual untill we've a cross section of planes.
Regards
Simon
That Ask-13 flight model does still have some compromises in it..... unlike the one on my hard drive, which I think should be issued if you're flying this plane.
-
Hi Simon,
By not having the engine, errors in my thinking of what occurs in No.1 and No.2 become clearer, which helped ensure I wasn't misleading myself.
We can do initial testing with engine throttle norm set to 0, and 0 fuel contents if necessary, and then expand the flight testing envelope as we debug and deterine the flight characteristics.
The Cesna 172 would be the perfect test platform, as we don't need to concern ourselves with modelling and scripting the basic functionality and we'll be able to directly compare flight data. Plus Levi's light mod will be released in the next OT update so it will really be a complete aircraft. I flew it today, and the flight characteristics aren't bad, but definitely far from what we can do.
Sounds fine, I am already developing the basic generation code, and it can be adopted for any use for various kinds of FDMs including helicopters.
Regards,
Uriah
-
The Cesna 172 would be the perfect test platform, as we don't need to concern ourselves with modelling and scripting the basic functionality and we'll be able to directly compare flight data. Plus Levi's light mod will be released in the next OT update so it will really be a complete aircraft. I flew it today, and the flight characteristics aren't bad, but definitely far from what we can do.
That's what I was about to suggest. Simple aircraft, obviously very popular wich means more data avaiable.
About the ASK-13, I was wondering if it's possible to apply additionnal progressive horizontal and vertical forces to let the player simulate assisted take-off and thermals effects, since Outerra doesn't really have any air simulation ATM. For example, binding these on trim keys (not used on the ASK-13, if I remember correctly). A progressive force will be applied when you press the key, allowing you to simulate the horizontal force created by a cable pulling the aircraft (trim left, for example), an ascending force like a thermal (trim up) or a low pressure area (trim down).
Sorry if this suggestion is kind of naive, my JBSIM knowledge is rather limited. The only way I've found to make the ASK-13 gain altitude during flight is to use the flight option window ("รน" key) to artificialy increase speed during a small period of time, allowing me to climb a bit.
Regards,
Acetone
-
I believe jsbsim has a functionality you require inbuilt as standard.... All we need to do is set the properties to non zero values, and a nice 2d control panel with sliders wouldn't go amiss
-
I'm a bit vague on this as well. I understand that JSBsim can simulate wind forces, but is it actually "talking" to Outerra while doing this? Could an accurate ridge lift with existing terrain be possible?
-
the talking to Outerra isn't an issue, it's just a poperty value.. Like turning lights on an off, a bit of java code for changing wind speed direction through change in alt, updated oscillation values etc...
Ridge lift... well if Outerra can do shadows from a light source... then consider the use of a 'black' sun that cast an unseen shadow, that could be used like a colour map within java code to determine ridge lift values....
What we need is for Cameni or someone from the outerra team to talk about user created 2d GUI's as a front end, a vector map using inkscape sending parameters to code.
-
You keep saying "java". Several times I was actually confused if you mean a standalone Java app, like that javafoil thing, or an in-game (HTML) window that uses Javascript to talk to the engine.
We can make a way for some "plugin" html widgets that will open on a shortcut while bound to an aircraft/vehicle, just like the alt+e script editor currently does. The window will have access to the JS interface of the bound vehicle, and therefore to the underlying JSBSim instance as well.
-
Sorry to confuse Cameni..... I mean your second meaning...
Could we not create a vector diagram thus having influence over the look and feel... i happen to have some gui artwork specifically for a wwii sim..
-
Whatever that can be created as a html page. If there's an online page that already visualizes graphs the way you want, it should be easy to reuse or implement a similar one, with added engine interface calls to set properties accordingly.
-
That would be really awesome! Aircraft parameters could be set with a simple GUI instead of reloading the script. Thanks!
Regards,
Uriah