Board index FlightGear Development Aircraft Flight dynamics model

We can start with the landing gear retracted

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

Re: We can start with the landing gear retracted

Postby Richard » Sun Nov 24, 2019 12:33 pm

abassign wrote in Sat Nov 23, 2019 9:30 pm:honestly I did not think of offending anyone by pointing out that JSBS reaction times are shorter than NASAL ones and so I would like to solve the problem with JSBSim and not with NASAL ... it is clear that my experience on RT systems has a different sensitivity in priority management.


You didn't offend me - the problem is with the posting of factually inaccurate information.

It is fine to say that you don't want to use JSBSim for this - but please don't say things that aren't true - as sometimes these things grow into myths that other developers start to believe.

In this case JSBSim is really not the right way to do this because JSBSim isn't event driven and Nasal can be event driven by using listeners; all code called within a listener on fdm-initialized will be executed immediately after and in the same frame as the initialisation finished. This is faster than JSBSim will permit because /sim/fdm-initialized will be non-zero for JSBSim modules the next frame and all subsequent frames. Therefore the JSBSim solution will be 0.008333 seconds (at 120hz) slower than the Nasal solution.

You can verify this yourself by looking at the JSBSim output log;
Code: Select all
Time    /sim/fdm-initialized  PilotGdamped
0          0                    1
0.0083     1                    0.999847234


abassign wrote in Sat Nov 23, 2019 9:30 pm:I try to do it in JSBSim, as in this example, but it doesn't work. I saw that "/controls/gear/gear-down" is binary, while JSBSim only works with Double types ... do you think this is the problem? If your answer is affirmative, do you know if there is a way to bypass the problem?


This is mainly because handling events in an iterative simulation loop isn't ideal; you will need to ensure that the code only runs during initialization and It may be possible to get the sequence correct by strategically placing the code in the right place in the initialization sequence; i.e. at the end of the simulation loop by putting the system that runs the init code at the end of the list. However this code will have to run when fdm-initialized is 0 which isn't quite the same as running it when fdm-initialized changes to true. It would be possible to get this system to execute when fdm-initialized changes to true by copying the last value and comparing it.

So to do this you're going to have to have a new switch to invert fdm-initializing; and a new channel that only runs when this new switch is true; something like.
Code: Select all
    <channel name="IsStartup">
        <switch name="fdm-intializing">
            <default value="1"/>
            <test value="0">
                /sim/fdm-initialized ne 0
            </test>
        </switch>
    </channel>

    <channel name="Startup" execute="fdm-intializing">
        <pure_gain name="bound/test-init">
            <input>sim-time-sec</input>
            <gain>1</gain>
        </pure_gain>
    </channel>


Nasal is the right way to handle fdm-initialized setup within FlightGear. I wouldn't recommend trying to do this in JSBSim as it will be unnecessary complex to get something that works the same.

You can set bool properties from JSBSim; the comparison for 'true' is not equal to zero (following C conventions) and that setting to 1 should be the equivalent of true.
Richard
 
Posts: 786
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: We can start with the landing gear retracted

Postby abassign » Mon Nov 25, 2019 10:22 am

Richard wrote in Sun Nov 24, 2019 12:33 pm:You didn't offend me - the problem is with the posting of factually inaccurate information.


Hello, meanwhile you certainly do not offend me ... the offender is another who thinks he is "the navel of the world" ... If he stopped writing useless and offensive things he could allow me to deepen my question.

However, due to my work experience, I absolutely prefer JSBSim (like all data driven languages) to NASAL for managing RT systems (a flight simulator like FGFS is absolutely an RT system), however this is just my free judgment, I am not interested in opening a discussion on this question.

The tests I have done, during the system start, JSBSim starts to work tens of seconds before NASAL and therefore if you activate a state with NASAL,
If for example JSBSim starts the simulation with the landing gear status closed, it is my case, even if the plane is on the runway, JSBSim proceeds with the simulation and the plane has plenty of time (tens of seconds) to crashing. I don't know why JSBSim has a different initial configuration than the one I want, but I don't think this is the problem, as the initial state is correct as it is controlled by the FGFS system which is composed of XML and NASAL (JSBSim is actually an external program that can be asynchronous to FGFS), but if JSBSim starts work without starting NASAL and the Tree property is complete ... it is obvious that there is a problem.

My impression, which perhaps you do not know as it is the result of a modification in the JSBSim code that we are preparing, has made the start of JSBSim seemingly faster as we generate random numbers differently. It seems a strange problem, but I noticed that the use of the C ++ rand () function could slow down the start, I don't know the reason, I think it is connected to the system timer access and for this we have profoundly modified the function. Since we entered the change I had the problem of not opening the landing gear, I don't know if it's a case ... However at the base of the problem I suppose that there is a lack of synchronization of JSBSim with the FGFS master system.

I've already explained the problem in previous posts, but apparently I wasn't clear, I'm sorry.

The information related to the initial state, the ones I reported in the previous post and which are present in the property-tree:

Code: Select all
/sim/preset


They are not visible to JSBSim and therefore JSBSim starts with a configuration that cannot be controlled or modified by NASAL. This seems to me to be the problem that I verified with the debug tests on the G91R1B.
Now we could solve the problem by blocking the execution of JSBSim's motion equation solution until a specific event occurs, this would synchronize JSBSim with NASAL.

What do you think about it ?

I think I can discuss the problem with the JSBSim development team I have been happily working with for more than a year.
abassign
 
Posts: 847
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: We can start with the landing gear retracted

Postby Thorsten » Mon Nov 25, 2019 10:51 am

The tests I have done, during the system start, JSBSim starts to work tens of seconds before NASAL and therefore if you activate a state with NASAL,


It would certainly help the discussion if you would stop repeating factually wrong things. The discussion will likely not proceed anywhere till you get your facts straight.

As Richard has explained (and demonstrated) above, Nasal is run immediately after the FDM is initialized and before JSBSim enters the first iteration - not 'tens of seconds later'. So likely you have done something wrong with your tests (or setup - see below).

I don't know why JSBSim has a different initial configuration than the one I want,


Likely because you didn't set the configuration you want, as the JSBSim configuration is completely dependent on how the various properties are set.

My impression, which perhaps you do not know as it is the result of a modification in the JSBSim code that we are preparing (...) However at the base of the problem I suppose that there is a lack of synchronization of JSBSim with the FGFS master system.


Then you should perhaps fix the root of the problem and not make any modifications to JSBSim that destroy the synchronization with FG, because that seems a really bad idea.

I think I can discuss the problem with the JSBSim development team I have been happily working with for more than a year.



If your problem is caused by private code modifications, then it'd be wise to mention that in the first place before asking in this forum. Since people do not know the nature of your modifications, you're probably on your own on that one.
Thorsten
 
Posts: 11765
Joined: Mon Nov 02, 2009 8:33 am

Re: We can start with the landing gear retracted

Postby bugman » Mon Nov 25, 2019 11:43 am

Abassign, are you aware of the work done to disable Nasal?


Have you considered creating your own experimental fork of the FlightGear project (obviously giving the project a new name), stripping out Nasal completely, and expanding JSBSim to be fully functional as a programming language? Though you would probably have to start your own forums and mailing lists as you would not get help here. Then again it might be easier for you to take JSBSim standalone and build a simple framework - including a rendering engine designed to your tastes - around it. You do have all the building blocks you need at your fingertips ;)

Regards,
Edward
bugman
Moderator
 
Posts: 1799
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: We can start with the landing gear retracted

Postby abassign » Mon Nov 25, 2019 1:19 pm

bugman wrote in Mon Nov 25, 2019 11:43 am:Abassign, are you aware of the work done to disable Nasal?


I often think about it, and I think it wouldn't be a bad idea, but it can give problems, NASAL is often used in FGFS for various system functions.
I completely agree with you that it is absurd to use a poorly documented programming language in use in a single application as a fundamental language for developing in FGFS, but in the world of electrical control this is the norm (mainly due to commercial convenience on the part of the component manufacturers) and I assure you that it is a big problem for all the technicians of that sector who have difficulty changing suppliers.

My suspicion of the problem I encountered in the development of the G91R1B is in the synchronization, that is, JSBSim starts too early, before the property-tree is completed, to understand it just try to make JSBSim read the "/sim/preset" properties during its start to discover that these properties have not yet been defined.

This fact is not the fault of Flightgear, but only because JSBSim has not synchronized its start with the completion of the FGFS start-up, so it must be solved by JSBSim by inserting a start/stop function according to an event.
When working with a platform in which at least three different programming systems coexist (XML, NASAL, JSBSim) it is not surprising that each of them must do something to understand when to start.

For this I will discuss the problem with the JSBSim group in order to be able to solve it at best.
These days I will do other tests to understand so as not to generate problems with the new JSBSim modifications and we will certainly have an improvement in the potential of JSBSim in FGFS as the actual conditions for starting the execution will be more certain.
In programming it is normal that everything runs smoothly, but then something changes and you have strange behavior.

In my opinion, JSBSim, which has a tidy and non-quarreling group of developers, must be able to solve its problems and not ask the FGFS development group to solve its problems. I could tell the FGFS group to start JSBSim when the property-tree has been completely described, but does it make sense? In distributed programming this is certainly not the technique, every actor must be able to start acting when the time is right and not starting with a kick in the ass!

Replacing NASAL could be an idea .. at least for the things that concern the individual aircraft developed for FGFS. We should understand well which modules to insert, many functions that NASAL performs are easily achievable in JSBSim but others should be built.
For example I'm thinking of building a function that makes the moving average that is very useful for solving some problems of the navigation control, inserting a Fuzy PID that was actually created in F15, some Flip-Flop modules should be made which are very useful for management of switches and memory modules. But the problem is that the JSBSim approach is heavy at the level of programming code writing, it is convenient only for short applications, but certainly not the best for long and complex applications, then JSBSim does not define data structures, arrays etc ... For this requires a more complete functional programming language like Erlang or rather Elixir which are languages that handle hundreds of thousands of objects well.
Otherwise there is the way of Python, which however is not RT (Real Time), but can completely replace NASAL. Python is not a language that I love, it has a rather confusing syntax (although the Python 3 is much improved) but it is a well-known language and with a very efficient interpreter and with an excellent amount of libraries and a very efficient compiled version.

In short, there is work to do :)
abassign
 
Posts: 847
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: We can start with the landing gear retracted

Postby Thorsten » Mon Nov 25, 2019 1:27 pm

I could tell the FGFS group to start JSBSim when the property-tree has been completely described, but does it make sense? In distributed programming this is certainly not the technique, every actor must be able to start acting when the time is right and not starting with a kick in the ass!


You could, but you'd be ignored because for the rest of us not using your modifications it happens as it should.

For example I'm thinking of building a function that makes the moving average that is very useful for solving some problems of the navigation control


Or you could use the existing moving average function...

Replacing NASAL could be an idea .. at least for the things that concern the individual aircraft developed for FGFS.


You seem to have missed the point - aircraft developers would not be concerned since it's about your own experimental fork of the FlightGear project (obviously giving the project a new name), So it's only the aircraft developers which use your code - the rest of us continues with what we have, :D
Thorsten
 
Posts: 11765
Joined: Mon Nov 02, 2009 8:33 am

Re: We can start with the landing gear retracted

Postby Hooray » Mon Nov 25, 2019 2:56 pm

/sim/presets is by most developers considered a huge hack, and has been causing issues since its introduction - there are many long-standing issues related to the way it is implemented, and it cannot be expected to work with many modern features - as a matter of fact, the introduction of "presets" support was the very moment, when saving/loading and resuming flights got crippled, David Megginson was not too happy about it at the time, because he was still very much in the process of establishing a corresponding SGSubsystem API that would provide event handlers for these purposes, but "presets" broke everything - so that saving/loading and resuming flights ended up in the backburner... for 15+ years, full background at:

http://wiki.flightgear.org/Fixing_Presets
http://wiki.flightgear.org/Reset_%26_re-init

bugman wrote in Mon Nov 25, 2019 11:43 am:Abassign, are you aware of the work done to disable Nasal?



This was primarily intended to be used as a troubleshooting aid, to see if/how and what issues are related to the built-in Nasal interpreter by being able to disable Nasal entirely, which is obviously useful to exclude Nasal as a whole from the troubleshooting equation. Furthermore, there was the original FGPythonSys discussion, as well as a number of related efforts, where being able to disable Nasal would seem like a worthwhile feature. I am not sure if this has ever been merged or not, but it would be relatively easy to provide a corresponding build option and/or a startup flag (--without-nasal mode) to make sure that Nasal is not initialized.

As such, it's primarily intended to help us, the FlightGear community, determine if certain issues are related to Nasal scripting or not - for instance, by comparing frame rate and frame spacing between two fgfs sessions with Nasal enabled/disabled respectively.

As I mentioned elsewhere, just threading Nasal out isn't going to happen for a plethora of reasons - primarily because of the unstructured fashion we've come to use Nasal inside FlightGear.
However, as I mentioned yesterday, there are low-hanging fruits, such as providing a new runtime model for scripting inside FlightGear, even without necessarily using HLA/RTI, DIS or Python - i.e. by providing a "restricted" Nasal environment that has no access to any global data structures, but that merely communicates with other threads using I/O channels (think sockets).

This is pretty straightforward to do actually, and we do have patches for a proof-of-concept, i.e. running a bare minimum Nasal interpreter in a background thread that has no access to the usual extension functions, subsystems etc - that way, it is easy to run Nasal asynchronously - however, the difficult part is still hooking it up to the rest of the sim, because the type of coding required is very different to what people are used to, i.e. more akin to message passing than actually calling APIs - which is touching on Richard's Emesary work: A320-family development
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: 12058
Joined: Tue Mar 25, 2008 8:40 am

Re: We can start with the landing gear retracted

Postby abassign » Mon Nov 25, 2019 7:47 pm

Hooray wrote in Mon Nov 25, 2019 2:56 pm:/sim/presets


Hi,

I found the two links to be very useful and show the problems that occurred in implementing the features /sim/preset
Regardless of NASAL that is useful or not, or if it is better to limit it to only certain functions, it is a discussion that finds me completely unprepared and that I prefer to have it resolved by the kernel developers.
I personally try to improve JSBSim support and increase its usefulness for the many functions that are currently being performed at NASAL. But as I have already written NASAL is used a lot in FGFS and therefore it is right that it is always present and improved. At the performance level, if NASAL is used carefully, I don't think it's a big problem, at least for the things I developed. Of course I am better at developing with JSBSim, but they are personal tastes that come from study and work experiences.

I tried to read the /sim/preset/onground property in JSBSim, but at the start JSBSim doesn't find the property and report an error. I could do a trick, but the problem remains, JSBSim starts to work too soon!
For this reason I cannot set up JSBSim to interpret startup or restart information. And this is a problem for me because, since a few days, I can't get the current version of the G91R1B to take off because the landing gear is closed. I'm thinking of some programming tricks, but once and for all I would like to solve the problem as it is absurd to approach from 20 nm and 300 mph with an open landing gear!

As I have already written my idea is to run JSBSim only if a parameter described in the XML of the JSBSim initialization file becomes true. Interesting thing also to be able to eventually stop JSBSim from NASAL. With this feature, the JSBSim system is allowed to synchronize with the rest of the FGFS system and to acquire information only when it is actually ready, without the FGFS kernel developers having to do anything.

Do you think that is the right way to solve my problem of the landing gear status according to the actual flight situation?
abassign
 
Posts: 847
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: We can start with the landing gear retracted

Postby wlbragg » Mon Nov 25, 2019 7:54 pm

So why don't you just set up a "state" "On Approach" as per the examples of any aircraft that use state support?
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 5873
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: We can start with the landing gear retracted

Postby Thorsten » Mon Nov 25, 2019 8:42 pm

Do you think that is the right way to solve my problem of the landing gear status according to the actual flight situation?


No, as already said, if that is true

And this is a problem for me because, since a few days, I can't get the current version of the G91R1B to take off because the landing gear is closed.

you should find out what broke a few days ago, not pile a hack upon a bug.
Thorsten
 
Posts: 11765
Joined: Mon Nov 02, 2009 8:33 am

Re: We can start with the landing gear retracted

Postby abassign » Mon Nov 25, 2019 9:05 pm

wlbragg wrote in Mon Nov 25, 2019 7:54 pm:So why don't you just set up a "state" "On Approach" as per the examples of any aircraft that use state support?


Because it seems not to be always active for JSBSim, the current development version of the G91R1B starts with a closed landing gear even though I have placed the landing gear option extracted in the initial configuration file. If it works, however, I do not solve the problem of the landing gear that must be closed if the initial state is in flight. Therefore it seems useful to me that before starting JSBSim it has the possibility to access /sim/preset in order to give a complete and correct configuration of the plane. Second problem, when JSBSim becomes operational the /sim/preset does not yet exist ... and therefore an error returns. It is clear that if I can start JSBSim only when a parameter becomes true, I solve all these problems.
abassign
 
Posts: 847
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: We can start with the landing gear retracted

Postby wlbragg » Mon Nov 25, 2019 9:44 pm

So no issue if you use nasal and state system. The issue is only if you want to use JSBSim plus state system without nasal?
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 5873
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: We can start with the landing gear retracted

Postby Thorsten » Tue Nov 26, 2019 6:11 am

@wlbragg:

I think his issue is as usual [1] - he changed something, doesn't remember what and now requests a whole new redesign of everything rather than undoing the change.

The rest of us certainly has aircraft that init on the runway with gears extended, and the rest of us also can use the state system or presets to achieve even complicated initial states like 'on the back of a carrier aircraft... So the fact that he sees the aircraft initializing with gear up on the runway is very peculiar for his setup.

Of course, once you refuse to believe in the simple solution that you've made a mistake which you need to undo and insist that only a screwdriver is suitable for hammering nails,, the space of possible solutions to this problem becomes very exotic.

Given that there are plenty of tried and tested init solutions which can simply be studied, there's really not much help missing here.

[1] When he had activated patchy fog in ALS, he insisted that there is no such setting and asked that the whole fogging routine is re-written...
Thorsten
 
Posts: 11765
Joined: Mon Nov 02, 2009 8:33 am

Re: We can start with the landing gear retracted

Postby abassign » Tue Nov 26, 2019 2:18 pm

Thorsten wrote in Tue Nov 26, 2019 6:11 am:@wlbragg:
I think his issue is as usual [1] ...


Meanwhile, I asked you to stop writing on this post,
if you don't have useful information for the question I asked at the beginning!


I would then like to point out to everyone that your language is absolutely offensive and meaningless.
I just hope you stop it immediately, you're ridiculous.
However you remember that you have the fog in your brain and it doesn't remind you of all the falsehoods you wrote in my posts in these months.
For example, I remind you of your denying the evidence on my question regarding the lack of visibility of airport lights when approaching ... but then, fortunately, with the help of others, it was solved with only some code correction.
I could say other things about your behavior, which is not only with me of course, but I just want to solve problems, about you and your problems, I don't care, you're just a black shadow in front of the splendor of this project.

For which I am grateful to many others who, like me, work with passion, attention and a great desire to help each other. This is the spirit of Opensource, it is the desire to grow and learn together in a common project.
abassign
 
Posts: 847
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: We can start with the landing gear retracted

Postby Thorsten » Tue Nov 26, 2019 2:34 pm

Meanwhile, I asked you to stop writing on this post,


Sorry, can't do as long as you give wrong impressions to others.

I would then like to point out to everyone that your language is absolutely offensive and meaningless.


Some examples of offensive language?

Here they are:

that you have the fog in your brain
you're just a black shadow in front of the splendor of this project.
you're ridiculous

And the author is... you! while nobody else is using that language with respect to you.

So I'll flag your post for moderation, I'm tired of you using rude language.

For example, I remind you of your denying the evidence on my question regarding the lack of visibility of airport lights when approaching ... but then, fortunately, with the help of others, it was solved with only some code correction.


Thank you - I was going to bring the example, because it illustrates quite well the damage you're doing.

After your report, I believe as many as five people checked on your claims - nobody was able to reproduce the issue you've been seeing. So you tied up quite a lot of time from different people who all convinced themselves that your issue couldn't be seen elsewhere. Then a different discussion (this time with something reproducible) was sparked off that - and people like myself - without you - proceeded to solve a different issue - blinking lights.

After that was done, you claimed against all reason that people without me had fixed your problem- which - as Jonathan pointed out to you, is logically impossible since the lights you reported were not actually changed (and it denies that I've spent several hours tracking down the root cause of the issue).

The most probable theory of what happened on your side is that somehow using the new code un-did whatever you changed on your system to make it break for you.

You clearly have no idea what the nature of that bugfix was, who did what and what was affected - and spreading your half-knowledge of how things tie together to other people is dangerous for this community, because we don't need to send people on wild goose chases on their time that could be spent more productively.

(In case you're wondering, that's the very same message you got from Richard a bit above).

For which I am grateful to many others who, like me, work with passion, attention and a great desire to help each other. This is the spirit of Opensource, it is the desire to grow and learn together in a common project.


Trying a game of 'good cop, bad cop'? There's several people who told you the exact same thing I've been telling you - JSBSim is a bad tool for what you want to do. You just don't like the message - but I somehow doubt you'll b able to divide this community.
Thorsten
 
Posts: 11765
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to Flight dynamics model

Who is online

Users browsing this forum: No registered users and 1 guest