Start a rocket motor from JSBSim code without NASAL in Flightgear about jsbsim HOT 8 CLOSED

I solved the problem with the help of the friends of Discord, the problem is due to the fact that there is a binding between the Flightgear application and the JSBSim implementation. This means that the variable fcs/throttle-cmd-norm[n] (where n is the engine number) is continuously updated by Flightgear and therefore can not be changed directly. Unfortunately, the implementation of JSBSim for Flightgear does not currently have the ability to silence the fcs/ throttle-cmd-norm[n] variable synchronization function with the corresponding Flightgear variable /controls/engines/engine[n]/throttle So it's better to play cunning and edit the Flightgear assign /controls/engines/engine[n]/throttle directly by assigning the value that we would like to assume fcs/throttle-cmd-norm[n] at this point everything works perfectly.
For example, to activate a solid fuel rocket engine it is sufficient to set (even for a moment) the variable: /controls/engines/engine[n]/throttle to 1 via a switch method or a function fcs_function this is the code I used:

        <switch name="throttle cmd norm[1]">
            <default value="0"/>
            <test logic = "AND" value = "1">
                systems/jato/ignition-on == 1
                systems/jato/rocket_number_1 == 1
            </test>
            <output>/controls/engines/engine[1]/throttle</output>
        </switch>

This switch function reminds us of two important things to know:
If in JSBSim for Flightgear a variable starts with the character / it means that it is a variable that refers to the properties tree of Flightgear, this means that the variable /controls/engines/engine[1]/throttle can be so assigned or read directly by JSBSim. The Switch function that I put in the example can not be defined with the name or tied properties (which in the example has become only a generic reference), but the assignment must be done only through the <output> ... </output> method. If instead a reference to a variable does not start with the "/" character, then that variable has a reference relative to the JSBSim properties tree only (a sort of local variable).

from jsbsim.

from jsbsim.

@andgi Hi :)

I tried with this code, but it did not work:

<property value="0.0">fcs/throttle-cmd-norm[1]</property>
.
.
.
    <channel name="jato start" execrate="8">
        
        <fcs_function name="fcs boost throttle-pos-norm[1]">
            <function>
                <description>Final throttle position</description>
                <and>
                    <eq><property>fcs/throttle-cmd-norm[1]</property><value>1</value></eq>
                    <eq><property>systems/jato/rocket_number_1</property><value>1</value></eq>
                </and>
            </function>
            <output>fcs/throttle-pos-norm[1]</output>
        </fcs_function>

   </channel>

I thought the initial statement:

<property value="0.0">fcs/throttle-cmd-norm[1]</property>

I thought the statement could detach the connection between the variablefcs/throttle-cmd-norm[1] and the variable equivalent /controls/engines/engine[1]/throttle

but the JSBSim compilation gives me an error:

In file /home/abassign/Dropbox/fgfs-Aircraft-custom/G91-R1B_HD/Systems/G91-JATO.xml: line 13
      Property fcs/throttle-cmd-norm[1] is already defined.

it seems clear to me that there is something I do not understand or the method does not do what I want, that is the variable fcs/throttle-cmd-norm[0] control directly from JSBSim without going through the Flightgear.

It's funny to think that you can not directly affect a JSBSIm variable from JSBSim because it is still updated continuously by Flightgear. I think it's a matter of operational priorities, that is, the fact that who wrote the interface has privileged the Flightgear part over JSBSim and probably does not think that JSBSim can do the same job as NASAL and XML scripts.

It would be interesting if instead you declare the variable as Short Empire example, this actually gets detached from the framework of Flightgear and assumes its own identity. Similarly to how it is done with an object's instancing.

from jsbsim.

from jsbsim.

@andgi Hi,

Why do you want to control fcs/throttle-cmd-norm[0]?
It is an input property so why would you want to set it programmatically
from within the aircraft?

The right question, the reason is that I have to turn on JATO rockets as a function of a series of commands and checks on the electrical system that is performed much more easily in JSBSim than in NASAL (and most likely engaging fewer CPU cycles ...). To ignite the JATO rockets it is sufficient to set the fcs/throttle-cmd-norm[n] in state 1 one cycle (I use a button with a filter simpler than JSBSim). I had done a NASAL program, but it was honestly complicated and did not do all the checks that I do very easily in JSBSim.

In the end I think the best thing not to do the double lap, it would be just to be able to divide the variable fcs/throttle-cmd-norm[1] from the corresponding /controls/engines/engine[1]/throttle of Flightgear, division that it could be done by a declaration as variable: <property value = "0">systems/jato/rocket_number_1</ property>

Seen from a semantic point of view, it does not seem to me to be nonsense, because it declares a failure to be local and not global, but from the implementation point of view it may not be easy to do. Of course if you do something like that it becomes much easier and immediate to use JSBSim instead of NASAL.

from jsbsim.

from jsbsim.

@andgi Hi,

Yes, and what I'm asking is: Are you sure the rocket engine is ignited by
the fcs/throttle-cmd-norm[x] property and not the corresponding
fcs/throttle-pos-norm[x] property?

For the solid propellant rocket engine (only for him) the start is via fcs/throttle-cmd-norm [x] when it has the value = 1 It is not possible to modulate the power of the solid rocket engine so it is possible to set the fcs/throttle-cmd-norm [x] variable only for one cycle (as I do) and then reset the variable to zero. As I said in the Wiki, unfortunately the binding between the flightgear variable /controls/engines/engine [1]/throttle rewrites continuously (at each cycle 20 Hz I suppose ...) on the variable JSBSim fcs/throttle-cmd-norm[x]. This explains why by removing the Execrate parameter everything seems to work ... but it's not so true ... because the binding probably happens after the evaluation process by JSBSim and certainly before the interpretation process from the module that manages the rocket engine.
Unfortunately I do not know who binds, if it is a Flightgear module that does not control the JSBSim program, it can not do anything simple to solve the problem. If instead it is JSBSim that reads the properties tree of Flightgear, then it is enough to anticipate the read binding from Flightgear to JSBSim property tree so that it may be JSBSim to write over the variable. Theoretically, if Execrate is active, holes are generated that can bring the value desired by Flightgear to the variable JSBSim equivalent and therefore (as we have seen) to falsify the result.
In order to make the implementation of execrate more robust, I think we need to change the way to handle execrate ...
There are many ways to do this:

1. Inhibit execrate automatically if there is at least one variable in the channel starting with "/" ...
2. Keep track (with a temporary memory) the variables starting with "/", if one of these variables has changed their value, then the channel is activated. This second option requires that the compilation of the channel, build a table of values ​​of variables that start with "/" and that this table is always checked at each cycle (120 Hz ...), it is not very heavy because the variables of this type are not many.

Option 2 can also be used to define a dynamic execrate, that is:
Define in the declarative part of execrate a vector of the variables that we want to check, as it is with and without the "/" character (with absolute reference or without absolute reference) and reset the execrate when one of the variables in the list has changed. This solution I find it easier to implement and allows an execrate with a virtually very long time.

from jsbsim.

@abassign Does my suggested method work without the execrate attribute on the channel? I have not tried it with rocket engines but it works well for piston engines.
If execrate is the problem simply do not use it for this channel. I still think that your problem is not that FlightGear copies /controls/engines/engine[x]/throttle to /fdm/jsbsim/fcs/throttle-cmd-norm[x] but that JSBSim as a default copies /fdm/jsbsim/fcs/throttle-cmd-norm[x] to /fdm/jsbsim/fcs/throttle-pos-norm[x] each FDM interation - meaning that any override you insert also need to be evaluated each FDM iteration, i.e. do not use execrate for these.

There is no easy way for JSBSim code to distinguish between "JSBSim" properties and "FlightGear" properties (no, a leading '/' does not signify that) and, additionally, as JSBSim is also used without FlightGear it would be annoying to have FlightGear-specific code stuck inside the JSBSim code base.

from jsbsim.