Board index FlightGear Development Aircraft Flight dynamics model

JSBSim or YASim?

Good sims require good FDMs (the "thing" that makes an aircraft behave like an aircraft).

Re: JSBSim or YASim?

Postby hvengel » Wed Jan 22, 2014 8:52 pm

What I was thinking is that some kind of wrapper that was part of the FlightGear code base could be written that would encapsulate JSBSim standalone and feed in Nasal values as needed. I think you are correct about the frame rate issue since Nasal code tends to have lots of things that are driven based on frame rate and JSBSim standalone would typically run with time highly compressed and also with a significant amount of time variability.

I was mostly trying to point out that having Nasal in our JSBSim FDMs makes using JSBSim standalone very difficult if not impossible and that this removes what could be a very useful tool for FDM developers. But using Nasal is almost unavoidable as there are some things that can not be done in JSBSim that are needed for a high fidelity simulation. One example for the P-51D is the Nasal code that causes the engine to sputter when the fuel tank connected to the engine is almost empty.
hvengel
Retired
 
Posts: 1128
Joined: Sun Dec 24, 2006 4:35 am
Location: Minden Nevada

Re: JSBSim or YASim?

Postby Hooray » Wed Jan 22, 2014 9:03 pm

I think most JSBSim experts tend to favor using "native" JSBSim means in order to accomplish FDM/systems-related stuff like this, while Nasal is generally suggested to be used only for the FG specific side of things. I am not sure if we can realistically expect to come up with any "wrappers" here that would solve the problem.
To me, it seems like one of these instances where people's tendency to use certain method causes challenges in other aspects, such as standalone simulation. In fact, I do know that many people developing JSBSim-based FDMs generally refrain from touching Nasal altogether - and I think even Jon mentioned that he prefers using native JSBSim features in such instances, for exactly the reasons you outlined above - i.e. being able to use stuff without introducing tight coupling.
Note that I do not think that this is a Nasal/scripting specific issue - we do have quite a few other examples of this going on, whenever there are "competing" - and at times even "conflicting"- approaches available. One compelling example would be the Autopilot system in FG, which has meanwhile become strongly superior to anything available in JSBSim - even though it is developed by JSBSim contributors (Torsten in this case).
In fact, there were quite a few discussions on the JSBSim mailing list about taking the FG AP to replace the existing system. So, as can be seen, the problem is really not specific to scripting or Nasal.
Even though you could argue that Nasal scripting clearly also is so much superior to JSBSim's "FGScript" XML dialect. Then again, it's not really suitable for inclusion into JSBSim - it would need to be reworked to provide a more deterministic runtime mode, probably with pre-allocated memory regions or at least statically-sized types and data structures.

The underlying problem of having competing/conflicting systems and features with differing states of completes can be seen in many other FG parts, such as for example the AI traffic system's schedule manager, vs. the route manager (think in terms of having DPs, STARs or IAPs). In general, the problem is a lack of coordination and integration here. So it's really not a JSBSim/FDM specific issue.

In the long run, the most promising "solution" may be the ongoing HLA effort, because that should make it possible to have a standalone scripting interpreter -or a standalone autopilot/route-manager system- which could also work with other components, without FG having to be present.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11435
Joined: Tue Mar 25, 2008 8:40 am

Re: JSBSim or YASim?

Postby rebootl » Wed Jan 22, 2014 10:35 pm

Quoting hvengel:
At the very least it generates a good, but basic, template that gives a starting place for a new FDM. But at best this will require lots of modification and added data to produce a decent FDM.


I think the wiki is also somewhat crucial here. Maybe that should be made clearer there. Under aeromatic it says for example: "Be careful when tweaking the resulting configuration file, because it's easy to make changes that will result in an unflyable FDM. Common errors are: ..."
While true, it doesn't say something like: "Be aware that you only generated a template. You should dive into it and replace the coefficient tables. See there and there.. and use XFOIL!"

This alone would go a long way toward reducing the number of very poorly done JSBSim FDMs and it would give novice FDM developers a better idea what data is required for a good FDM.

I'm not sure. As a "novice FDM developer" I can say that I was really glad that the aeromatic config file wasn't spammed with huge tables cause it might would have confused me. Or made me insecure, should I replace them or not? :? Maybe I wouldn't have taken the effort to learn about polars and XFOIL and just have let them as is.
You might end up on a higher level but even more generic... A lot of people are quickly satisfied. They're already satisfied w/ an aeromatic config file as it is now... and that's why they stop developing it further.

The responsibility to create a good FDM lies in the hand of the developer, you can't take it away by whatsoever tool. Provide great tools? Sure. But don't make it too easy. (A bit of The Arch Way: Make it harder. :wink:)

[...] The issue here is that getting good coefficient data is difficult and likely requires wind tunnel data, flight test data and some fluid dynamics modeling for the specific aircraft. [...]

Not easy, sure. But saying that you're basically saying it's impossible ?
I'm not convinced, what about DATCOM and XFOIL ? And commonsense! Don't underestimate it. One can evtl. make fairly good estimations, using textbook/references etc., don't you think?
rebootl
 
Posts: 110
Joined: Tue May 03, 2011 2:55 pm
Location: Switzerland
OS: Arch Linux

Re: JSBSim or YASim?

Postby KL-666 » Thu Jan 23, 2014 2:06 am

Hello rebootl,

I see no reason at all to be satisfied with aromatic. These unworked planes fly completely surrealistic. Yes, they kind of stay in the air. But that is what an ufo does too. You do not get any flying experience what so ever from that smelly fdm. Then the results of unworked yasim is a lot better, though not near perfect at all.

You say developing the individual fdm is the responsibility of the developer. Well i can tell you that if there are 3 developers that understand flight dynamics, that is many. So most planes depend on the basic generated fdm.

So i am happy that some people try to get that basic jsbsim at a little higher level.

Kind regards, Vincent
KL-666
 
Posts: 784
Joined: Sat Jan 19, 2013 1:32 pm

Re: JSBSim or YASim?

Postby daveculp » Thu Jan 23, 2014 3:42 am

KL-666 wrote in Thu Jan 23, 2014 2:06 am:Hello rebootl,

I see no reason at all to be satisfied with aromatic. These unworked planes fly completely surrealistic. Yes, they kind of stay in the air. But that is what an ufo does too. You do not get any flying experience what so ever from that smelly fdm. Then the results of unworked yasim is a lot better, though not near perfect at all.

You say developing the individual fdm is the responsibility of the developer. Well i can tell you that if there are 3 developers that understand flight dynamics, that is many. So most planes depend on the basic generated fdm.

So i am happy that some people try to get that basic jsbsim at a little higher level.

Kind regards, Vincent


Hi Vincent, thank you for your feedback on AeroMatic. Can you give me an example of an "unworked" airplane that flies in a surrealistic manner? I'd like to take one up for a while and see what's wrong. Do you have any specifics?
User avatar
daveculp
 
Posts: 503
Joined: Sun Feb 24, 2013 1:50 am
Location: Las Vegas, USA
Callsign: DCulp
Version: 2017.3.1
OS: Ubuntu 17.10

Re: JSBSim or YASim?

Postby jonsberndt » Thu Jan 23, 2014 1:40 pm

rebootl wrote in Sat Jan 18, 2014 6:49 am:Maybe that's a misunderstanding. I think the point when supercomputers came up in the discussion was only when trying to explain that it's not possible to calculate these data in real-time.


It still takes clusters of powerful computers a long time to determine high-fidelity aerodynamic characteristics - nothing close to real-time.

Jon
Jon S. Berndt
Development Coordinator
JSBSim Project
http://www.JSBSim.org
http://www.facebook.com/jsbsim
User avatar
jonsberndt
 
Posts: 205
Joined: Tue Aug 07, 2007 1:44 am
Location: Westminster, Colorado

Re: JSBSim or YASim?

Postby LesterBoffo » Thu Jan 23, 2014 3:47 pm

Hooray wrote in Mon Jan 20, 2014 5:59 pm:@adrian: The Nasal C source code is pretty straightforward, except for some of obscure exceptions like hash.c - I do not claim to understand everything there, but it's pretty readable actually, and contains a ton of helpful comments. Besides, I can always go and ask Philosopher if I need an explanation about something related to the Nasal core engine :lol:

Concerning "unit tests" (or even just scripted regression tests) - hvengel is 100% correct in my experience, you cannot expect to make any sane changes without having a way to verify and validate your changes - whenever there's a non-trivial code (FG) base or a complex problem (FDMs), having scripted regression tests can be an awesome experience. I do not claim that writing these and maintaining them is my favorite occupation - but whenever I am working with a project that has great regression tests, it's simply awesome - and it gives you a degree of confidence that you would not normally have, because you check and verify behavior that otherwise only the original programmer(s) would be able to validate.

Just look at some of the -few- instances in recent FG/SG commits where unit tests were used - such as for example commits made by TheTom or Zakalawe, basically these allow you to play with things like cppbind without having to understand the whole thing - you can simply run the cppbind test suite to ensure that everything is still working as expected.

Now, like hvengel said: FDMs are better tested by scripting test flights that can be run in a standalone fashion - indeed, Philosopher and I have been looking into coming up with a standalone Nasal interpreter for exactly the same reason - indeed, Andy actually came up with a Nasal-based regression tests to stress-test things like the GC or the hash algo.

If you are interested in Nasal internals, the 3.0 release will contain a PFD file in $FG_ROOT/Docs specifically about just that: Nasal internals, Philosopher started working on this a while ago, and while it's still work in progress, it is already pretty useful.


Someone involved with Notepad++ had a small language script chunk that was customized to be used in debugging Nasal, I tried copying it into the language.xml in Notepad++'s user settings folder, but it crashed Notepad++... :roll:

Concerning Nasal.. How come there are so many Nasal faults involving 'nil in a numerical instance'? I run into this repeatedly, the scripts seem to run despite this fault, but I can't help but think that these are somehow crippling their intended function.
User avatar
LesterBoffo
 
Posts: 2128
Joined: Sun Oct 02, 2011 4:02 pm
Location: Oregon, USA
Callsign: LesBof
Version: 2018.3.2
OS: Win10 Pro

Re: JSBSim or YASim?

Postby hvengel » Thu Jan 23, 2014 4:50 pm

Quoting rebooti:

A lot of people are quickly satisfied. They're already satisfied w/ an aeromatic config file as it is now... and that's why they stop developing it further.


That was my point. We have way too many FDMs that are basically Aeromatic generated with very little additional work that have been created by "people (who) are quickly satisfied". And many of these fly like crap. I remember flying a JSBSim SeaFury few years ago that should have had great performance, similar to if not slightly better than the P-51D, that could hardly get off the ground and would not break 200MPH at sea level. I would much rather have these underdeveloped aircraft flying in a generic but plausible way. In addition, the people who will take the time to learn about how this works and do things like get out a text book to find the formulas, gather the data needed to set up accurate models for DATCOM+ or XFLR5, research looking for pilots manuals, wind tunnel data and test data ... will not be happy with a generic but plausible FDM and they will still continue to put in the effort needed to produce a high quality FDM. Providing better default Aeromatic FDMs will raise the floor without lowering the ceiling. You are also correct that no matter how good Aeromatic gets there will always be lots of work needed to make the FDM a high fidelity one and an improved Aearomatic will not have a significant impact on how much effort is needed to get to that level.

I also agree that the wiki should be clear that an Aeromatic FDM is a starting place not a destination. It should also be clear that the destination is a long way off and that it will require lots of work to get there. When I started my JSBSim journey the wiki had perhaps 5 or 6 pages with information of JSBSim and most of it was very basic. I had an understanding of the content of those pages in perhaps 4 or 5 hours. There is now lots more info available but this could be greatly improved and it might be worth while pointing potential FDM devs at resources can that help them move down the path to a really good FDM.
hvengel
Retired
 
Posts: 1128
Joined: Sun Dec 24, 2006 4:35 am
Location: Minden Nevada

Re: JSBSim or YASim?

Postby Hooray » Thu Jan 23, 2014 5:03 pm

LesterBoffo wrote in Thu Jan 23, 2014 3:47 pm:Someone involved with Notepad++ had a small language script chunk that was customized to be used in debugging Nasal, I tried copying it into the language.xml in Notepad++'s user settings folder, but it crashed Notepad++... :roll:


So what ? Are you trying to say that this is Nasal's fault ? It definitely isn't - Notepad's XML parser is definitely at fault here, or if it's not the parser that's crashing, it's notepad itself.
Just imagine for a second you were to write piece of text and then send it to me, and I am pasting it into Word - and Word crashes subsequently - would you say that this is your fault ? :D

Concerning Nasal.. How come there are so many Nasal faults involving 'nil in a numerical instance'? I run into this repeatedly, the scripts seem to run despite this fault, but I can't help but think that these are somehow crippling their intended function.


Because people are not aware that nil is the default value for incorrect expressions - so that nil propagates, until it ends up in some expression where it's no longer supported.
People need to use proper defaulting instead:

Code: Select all
var value = getprop("/sim/foo") or 0.00;
value += 100;


In the case of getprop, it's actually trivial, because it supports an optional default value - but many other extension functions will simply return "nil" under these cirumstances.
Now, "a real programmer" would always validate results before using them, as in common in C/C++:
Code: Select all
var value = getprop("/sim/foo");
if (value)
 value += 100;
else
 die("value was nil !!!!!!!!!");


or even do stuff like this:
Code: Select all
var value = getprop("/sim/foo");
if (!value)
value = 0.00;

 value += 100;


Using "or" for defaulting an expression is just more succinct, i.e. short-hand.
The general problem is not so much about Nasal actually - it's just having people write code that are not aware of such things.
We have quite a few people who are experienced programmers and who do not seem to run into any of these issues.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11435
Joined: Tue Mar 25, 2008 8:40 am

Re: JSBSim or YASim?

Postby Philosopher » Thu Jan 23, 2014 5:19 pm

(getting OT: ) Those errors are usually caused by getting uninitialized properties (using getprop() or props.nas) and not handling it. There's generally three ways to deal with it:
  1. "Default" the variable:
    Code: Select all
    var p = (getprop(someprop) or sane_value)

    Where sane_value is usually 0. My issue with this is that sometimes 0 is not a sane value, and in that case, this hack-y syntax (using a sane_value other than 0) will force the property's real value to sane_value when it is "false" – which includes 0 and "" in addition to nil – even when the user might have explicitly set the property to request that behavior. A common example of this is when a delay is provided as an argument, because that delay could potentially be nil (aka use a default value) or 0 (aka use a 1-frame delay).
  2. Return early:
    Code: Select all
    var p = getprop(someprop);
    if (p == nil) return;

    This avoids doing anything altogether, instead of attempting to provide some sane result.
  3. Or just initialize the property, either in Nasal or the -set.xml. This again requires a sane default, but it's a little nicer because it ensures that the property is actually in the tree.

For the record, in the above snippets by Hooray, the behavior of the if() statements is much the same as the behavior of the "or" workaround. To properly check against nil it should be (value == nil) or (value != nil), because of the reasons explained in the first bullet point. (Specifically, in the second snippet, if value was 0, the code would think it was nil :P)
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: JSBSim or YASim?

Postby KL-666 » Thu Jan 23, 2014 5:32 pm

Hi Daveculp,

Unfortunately i can not see which planes are completely unworked (not a developer), but i can recommend some horrible planes.


I would have recommended the 707 of constace weeks ago. One of its "features" was to fly forever with engines idle. But Honzaku started working on it, so it may now not be as weird as it was.


I can recommend the a320 family though. I just verified the a320-200 CFM.

- Filled the plane with 100% fuel, selected full flaps and took off. Did i nice climb of 2000-3000 ft/min after takeoff. This is quite ridiculous, i should barely or not be able to climb out with full flaps.

- Took gear and flaps in, picked up some speed and climbed effortless to fl 400 at 3000 ft/min. Again this is very curious, because above fl 300 one should be very glad to have 1000 ft/min. And with 100% fuel load, you may barely reach fl 300 at all.

- Descended to a more reasonable fl 360, and at level flight there speeded the plane up. I could have gone well over mach 1, but i thought mach 1 in level flight is weird enough already.

- Slowed to a more decent speed and descended 2000 ft/min without speeding up. That seems reasonable to me.

- At 4000 ft reduced fuel to 25% and experimented with the flaps at constant throttle setting and constant height at around 200 kts. There i found out that flaps give no drag at all. They only want to pitch the nose up, but if you stay at constant height and constant throttle, you actually go faster with flaps, because you have less angle of attack. Only angle of attack seems to have effect on drag in this plane, and it is quite too dramatic. Maybe someone tried to balance the whole behaviour of the plane by angle of attack drag only.

- Stall happened at about 130 kts full flaps. That is maybe just a little bit fast.

- On glide slope had a rather extreme nose-up at 140 kts full flaps. Must have to do with being near stall already at that speed. At flare, the trick with angle of attack drag made it seem to slow down normally.


Apart from this a320, i can recommend almost all jetliners. They all suffer more or less the same issues. But they do not have this extreme angle of attack drag. These planes are insanely hard to slowdown from 120 kts in flare, so you float halfway the rw until speed has dropped just 5 kts. This can best be fixed with flap drag and not by pumping up the angle of attack drag.

Kind regards, Vincent
KL-666
 
Posts: 784
Joined: Sat Jan 19, 2013 1:32 pm

Re: JSBSim or YASim?

Postby daveculp » Thu Jan 23, 2014 6:13 pm

Nice report, but I was hoping for some raw AeroMatic models to test. In your previous post you claimed to be knowledgeable about them.
User avatar
daveculp
 
Posts: 503
Joined: Sun Feb 24, 2013 1:50 am
Location: Las Vegas, USA
Callsign: DCulp
Version: 2017.3.1
OS: Ubuntu 17.10

Re: JSBSim or YASim?

Postby KL-666 » Thu Jan 23, 2014 7:45 pm

Hi Daveculp,

If these are "worked" planes, i hold my heart for a truly unworked plane. I use the word "unworked" as opposite to someone having put in all the windtunnel data. Else i get reactions from him like: "Look at my plane, it is perfect, so jsbsim generated must be perfect". Semi-worked planes fall in the category unworked.

Almost all jsbsim jetliners (except the rare really well done) suffer the same "mistakes". All mistakes at least occur in more than one plane. In some planes this mistake is taken out, in others another mistake is taken out. I do not think it is correct to deduce from this that jsbsim developers make all the same mistakes. More logically the sum of mistakes comes from a common source.

I dare to bet that if you point me to a truly unworked jetliner, i'll find all mistakes culminated.

Kind regards, Vincent
KL-666
 
Posts: 784
Joined: Sat Jan 19, 2013 1:32 pm

Re: JSBSim or YASim?

Postby daveculp » Fri Jan 24, 2014 12:17 am

Yes, It's very common in JSBSim models for sections of configuration files to be cut and pasted, meaning errors will propagate. I downloaded an A-320 model to inspect its files (I don't know if it's the same one you tested). I see two problems right away. First, it uses the raw AeroMatic turbine configuration, which was built to model everything from a Whittle engine to the most modern turbofans. As a result it produces thrust up to unlimited mach number. As long as the user flies the A-320 within its flight envelope this isn't a problem, but if he tries to see how fast it'll go it's a problem. The old 737 model I made with Innis Cunningham shows how to alter the thrust table to stop producing thrust when nearing Mach 1.

Another problem with the model is the drag-due-to-mach table is missing. This will make supersonic flight much easier.

That's as far as I looked.

I agree that it's very annoying to hear people say their FDM is perfect, because none of them are perfect.

When I wrote AeroMatic many years ago it was initially intended just to save people a lot of typing. After working on it a little I realized I could also offer some choice of airplane types. I made examples of each type and flew them around a bit (within their flight envelope) and found them satisfactory. Of course the FDM's always need tweaking, but in order to tweak you have to know what you're doing. This may make JSBSim a poor choice for non-pilots or non-aero engineers.
User avatar
daveculp
 
Posts: 503
Joined: Sun Feb 24, 2013 1:50 am
Location: Las Vegas, USA
Callsign: DCulp
Version: 2017.3.1
OS: Ubuntu 17.10

Re: JSBSim or YASim?

Postby KL-666 » Fri Jan 24, 2014 3:17 am

Hello Daveculp,

The world is changing. Remember the time when there were no iPhones? nowadays these iPhone kiddies make planes in flightgear. Do they know anything about flight dynamics? I fear not, but they make those horny little liveries, and we all say aaah.

Basics of a flight simulator should be flight dynamics in my opinion. The basics can be laid by the people that know about that subject. The test can be done by people that know how a plane should behave in different circumstances.

But in no way can a script kiddie ruin the respectability of flightgear. That is what i thought, until i learned about loads of horrible jsbsim planes being pushed by script kiddies.

So you can say, well the script kiddies need to get better. But you know as well as me, they will not. So the only guaranteed solution against those script kiddies is to force a better fdm onto them. By making the available fdm as good as it gets.

You did a good effort with Aeromatics. But it needs to get better now.

Kind regards, Vincent
KL-666
 
Posts: 784
Joined: Sat Jan 19, 2013 1:32 pm

PreviousNext

Return to Flight dynamics model

Who is online

Users browsing this forum: No registered users and 2 guests