Board index FlightGear Support Flying

Starting FG with a ''running'' aircraft

Controlling your aircraft, using the autopilot etc.

Starting FG with a ''running'' aircraft

Postby gierschi@flightgear » Wed Feb 24, 2016 2:24 pm

Hey guys,

i want to start FlightGear via the linux console in a way that all systems of the aircraft c172p are still running so that you can immediately fly/take off. The initial state should match to this one when you use the autostart tool and press s for a while but in addition with a initial speed of 50 knots. The background behind this is to start flightgear with an aircraft beeing in the air in a way that it is running like when you bring it to this position from the ground. The post viewtopic.php?f=25&t=18466 doesn't help and I try a lot of different properties:

--prop:/engines/engine[0]/running=True ??
--prop:/engines/engine[0]/rpm=3000 ??
--prop:/controls/engines/engine[0]/throttle=??
--prop:/controls/engines/engine[0]/throttle-lever = ??
--prop:/controls/engines/engine[0]/mixture=??
--prop:/controls/engines/engine[0]/starter=??
--prop:/controls/engines/engine[0]/condition=??
and so on

The ''best'' state I get is a moving cessna with a rotating propeller that gets slower and slower until it stops (on ground) only by setting --prop:/engines/engine[0]/running=True and --prop:/engines/engine[0]/rpm=3000. Please help.

best regards,
sebastian
gierschi@flightgear
 
Posts: 58
Joined: Tue Nov 03, 2015 10:40 pm

Re: Starting FG with a ''running'' aircraft

Postby Hooray » Wed Feb 24, 2016 3:06 pm

This sort of thing used to work using a bunch of so called "presets"-which are implemented in $FG_SRC/Main IIRC
Most of this is considered highly fragile, if not even broken, by all core developers - and it is also considered the main reason why saving/loading and resuming flights did never work again after that feature got committed: http://wiki.flightgear.org/Fixing_Presets

In the meantime, there are more recent developments, such as the "instant replay", "pre-recorded flights" and the "flight recorder" subsystem.

These basically deal with applying old state and replaying that, i.e. continuing from there.

Depending on the aircraft you are having in mind, getting "presets" to work may be relatively simple or next to impossible - people have been using the "variant-of" tag and custom -set.xml files to work around these limitations.

At some point, Jon tried to work out a way to establish a sane interface between FG and JSBSim, but didn't get much feedback: http://wiki.flightgear.org/FDM_engine_f ... .2F2013.29


The addition of "presets" more or less caused the challenges outlined below:
http://wiki.flightgear.org/Reset_%26_re-init
http://wiki.flightgear.org/FlightGear_Sessions

Like I said, you will probably want to look at "presets" - but I am not sure if that was ever designed to work in conjunction with an external FDM - IIRC, Curt implemented that feature, you may be better off asking directly on the devel list.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Starting FG with a ''running'' aircraft

Postby Hooray » Thu Feb 25, 2016 5:49 pm

ok, seems I was wrong, it's Environment/presets.cxx: http://wiki.flightgear.org/Turbulence#Properties


Most of this stuff hasn't been widely used in a while - so if you find something that works (or doesn't), feel free to add to the corresponding wiki article (or start a new one). You may also want to file a bug report if you find that something is really broken (see the issue tracker)

Apart from that, the integration code is here: https://sourceforge.net/p/flightgear/fl ... oninit.cxx

(look for anything with "presets" in it to learn how this works/worked)

The defaults are initialized here: https://sourceforge.net/p/flightgear/fl ... s.cxx#l109
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Starting FG with a ''running'' aircraft

Postby gsagostinho » Thu Feb 25, 2016 10:05 pm

AFAIK, the c172p has an option in the aircraft menu exactly for that.
User avatar
gsagostinho
 
Posts: 1806
Joined: Thu Jan 15, 2015 7:27 pm
Location: London, UK

Re: Starting FG with a ''running'' aircraft

Postby Hooray » Thu Feb 25, 2016 10:14 pm

yes, more or less - my answer was in response to the other question the OP asked a few days ago, i.e. using an external FDM and starting fg with a running aircraft to shoot approaches - which is why I mentioned the "presets" feature.

Otherwise, the more common, FG specific method, is providing an "autostart" feature for different scenarios/situations - usually, in the form of scripts and/or property rules.

More recently, this is commonly implemented on top of the "Aircraft Checklists" feature, i.e. by making checklists executable: http://wiki.flightgear.org/Aircraft_Che ... _execution

Image

IIRC, the extra500 has an even more sophisticated checklist/tutorial system using some kind of hybrid approach:
http://wiki.flightgear.org/Extra_EA-500 ... ist_dialog
Image


For the time being, none of this -unfortunately, too useful for the original presets use-case, i.e. shooting approaches by telling FG to position the aircraft on a 10 mile final with the engines running and the corresponding landing configuration applied.

Equally, this is not commonly supported at runtime via the "location (in air)" menu/dialog, because there's so much aircraft specific logic that needs to be hooked up the initial state desired: http://wiki.flightgear.org/Startup_Situations

For some background, here's Jon's original proposal to formalize/standardize this much better (pre-dating reset/re-init by several years):

The [Re-]Initialization Process in FlightGear: A Specification Proposal

Jon S. Berndt wrote:In order for the FDMs to consistently and completely handle a reset request
from FlightGear, there ought to be a specification that describes what is
supposed to happen. Here's a first cut at what a specification for the reset
function might say:

1) There MUST be separate functions to
a) initialize cockpit controls, and
b) initialize the FDM.


Controls_init includes things like yoke position, trim, engine controls, et
cetera. This is crucial when one or more inputs are coming from the keyboard
as opposed to from a joystick.

The first time around, the caller MUST call both, but subsequently the
caller MAY call FDM_init alone. FDM_init MUST behave the same on init and
re-init.

The rest of this spec is devoted to the FDM_init.

2) FDM_init MUST be "clean" and 100% reproducible. That means that the FDM
MUST NOT remember anything from before the init. This includes
systematically initializing (including re-initializing) anything in the
property tree that it cares about, as well as any internal variables
(including any cache values, history, rates, momenta, et cetera).

3a) The following properties "belong" to the FDM. The caller MAY specify
any/all of these, and the FDM MUST respect them:
-- latitude, longitude, and altitude;
-- heading, pitch attitude, and bank angle;
-- groundspeed.

3b) The following properties also "belong" to the FDM. The caller MAY
specify them, but the FDM MAY choose to ignore what the caller says:
-- yaw rate, pitch rate, and roll rate;
-- slip angle and rate of climb.

4) If the caller specifies any other properties, the FDM MAY ignore them or
MAY respect them.

5) The caller does NOT NEED to specify any of the properties mentioned in
item 3.

Assuming settings are passed via the property tree, the FDM MUST interpret
each of the following as "unspecified":
-- A property that is entirely absent from the property tree.
-- A property that is set to nil.
-- A property that is set to "".

Remark: The key point here is that the spec MUST provide clear
conventions for indicating which properties are in the unspecified
state.

In the case of floating-point variables _tied_ into the property
tree, none of those conventions would work, which seems like a
sufficient reason why these variables SHOULD NOT be tied.

6) The altitude, if unspecified, defaults to "ground level" at the specified
lat/lon.

The rest of the properties mentioned in item 3 should default to zero.
(This is not a particularly useful default for the position, so for
practical purposes the caller SHOULD always specify an initial
lat/lon.)

7) Other than the properties mentioned in item 3, the FDM MUST NOT mess with
any other properties. This includes cockpit controls and trim.

Specifically, any auto_trim, auto_throttle, or gs_capture functions MUST NOT
be bundled into the standard FDM_init. If the caller wants to invoke such
functions separately, that's beyond the scope of this document.

8) The interface MUST use the following units: degrees for angular
variables, knots(true) for groundspeed, and feet(true) for altitude.

Remark: The key point here is that the spec MUST specify a clear
choice of units. The units in item 8, as proposed above, are not so
much a recommendation as a reflection of the existing interface,
although that's undocumented and there could well be inconsistencies
in the existing usage.

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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Starting FG with a ''running'' aircraft

Postby gsagostinho » Fri Feb 26, 2016 12:12 am

Hooray wrote in Thu Feb 25, 2016 10:14 pm:yes, more or less [...]

Otherwise, the more common, FG specific method, is providing an "autostart" feature for different scenarios/situations - usually, in the form of scripts and/or property rules.


I didn't mean the autostart function, I literally mean starting with the engine running as soon as the sim loads up:

Image

Cheers,
Gilberto
User avatar
gsagostinho
 
Posts: 1806
Joined: Thu Jan 15, 2015 7:27 pm
Location: London, UK

Re: Starting FG with a ''running'' aircraft

Postby Hooray » Fri Feb 26, 2016 12:20 am

I see, thanks for clarifying - I think the OP specifically asked about a command line switch (set of switches) to start an aircraft in-the-air:

The background behind this is to start flightgear with an aircraft beeing in the air in a way that it is running like when you bring it to this position from the ground.


Assuming that you cannot patch fg_init.cxx to add startup options, you would then need to expose a handful of properties and read those to initialize the c172p in-air, with the engines running.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Starting FG with a ''running'' aircraft

Postby Parnikkapore » Fri Feb 26, 2016 5:03 am

The technique I'm using in my YouTube tutorials:
1:
-start on the ground,near where you actually want to start.
-Start the plane (often Autostart)
-Use the Set location in Air menu
-Fly!
2:
-Start with the launcher,better a few feet above target altitude
-Quickly Autostart as soon as it's possible
-Move the controls around,often the throttle
-Fly!
There are free alternatives to (almost) every program you encounter. You just have to find them.
Parnikkapore
 
Posts: 929
Joined: Thu Oct 29, 2015 11:16 am
Callsign: HS-FGS
Version: next
OS: Kubuntu

Re: Starting FG with a ''running'' aircraft

Postby gierschi@flightgear » Fri Feb 26, 2016 5:55 pm

Thanks for the helpful replies and the other useful background informations. I noticed the set location (in air) option like Parnikkapore described in ''1:'' above too and it works fine for my purposes. When you activate the autopilot directly it is nearly possible to fly in a stable way from the first second beeing in the air. But it also works the same with some option you can set in the linux console like this (although I thought i have set them this way):

fgfs --roll=0 --pitch=0 --offset-distance=2 --offset-azimuth=0 --vc=60 --prop:/engines/engine[0]/rpm=3000 --altitude=2000

When you do this without the --altitude option the aircraft is also already running on the ground. The most important option to get a running state seems to be the --prop:/engines/engine[0]/rpm=3000 one. Only setting this value makes your aircarft running, at least for me.

best regards.

best regards!
gierschi@flightgear
 
Posts: 58
Joined: Tue Nov 03, 2015 10:40 pm


Return to Flying

Who is online

Users browsing this forum: No registered users and 7 guests