Modular Instruments

[majic79]

This is a common concept in software development, and I was wondering if it could be extended to the cockpit instrumentation: It would involve developing a library of current good instruments (eg, ADF's, ASI, VSI, HSI, Altimeter, etc and other meters commonly found in light aircraft)

Then, define an instrumentation panel and an interfacing .xml file that places the respective instrument in the panel (with it's representative model) and connects its inputs and outputs to the relevant systems.

At the moment I guess there's a fair bit of hacking around with the instruments that have been developed for the likes of the Cessnas and Pipers, and why not make this freely available to anyone that wants to use it - a little bit of documentation (perhaps a standard for something like the ADF, Vertical Speed, Altitude meters to make it really easy) and it's part of the root FG data repository and not re-distributed with every aircraft that uses the exact same instrument in the cockpit, for displaying airspeed.

The development process for a cockpit then becomes very simple - decide on the instrument you want in the cockpit, lookup the documentation, include /common/instruments/ADF/ki227 and connect it to an electrical supply and anything else it wants, and specify where the model is displayed on the panel.

Modifying the aircraft (eg, experimental aircraft and I want to try it with a KI228 with an automated sync) can be very easy, just switch the included ki227 for a ki228 and add a second connection

Aircraft developers can then worry about the airframe models, FDM designers can worry about the FDM, the cockpit display systems can be cobbled together very quickly and easily, and with the right methods, can be made to look very much like the real cockpits of some of the light aircraft.

It may not work for glass panels (heck, why not? They plug in a hole in the cockpit of the real thing and just have more inputs to them) but simple instruments ought to work well with this sort of system

[HHS]

Hmm...Maybe I do understand your posting not quite.

But we have a folder called "Instruments" and "instruments-3d" inside the "Aircraft"-folder so the aircraft-developer should/could just set a link to the needed one.
This contains a whole lot of instruments- altimeters, ASI's, Artificial Horizons, AP, etc....
A whole lot of aircraft cockpit links to this folder. (similar like that: <model><path>Aircraft/Instruements-3d/adf.adf.xml</path></model>)

That some aircraft developers decided not to link to this folder has different reasons. Depending on the aircraft type the electric systems and other depending systems differ and it is easier to maintain inside their aircraft package. Or they adjust colors, textures so it matches better with the cockpit.

It is up to the developers to make use of it or not.

[majic79]

Yes, I've noticed that - I'm also thinking of linking the model to the system .xml as well - so that when you include the instrument model in the panel, the system comes in at the same time, at the moment there's usually a seperate instruments.xml and seperate panel definitions. I think it may be possible to bring the two together and with some nice instrument libraries, pull them both in, in one go, that makes working with them a bit easier on cockpit designers.

[majic79]

So here's my updated model for the KI-206 Nav/Glidescope indicator



I want to have a pre-defined xml model for it with animation etc that sets up the instrument, and I want to include it, is this sufficient:

Code: Select all

  <model include="Aircraft/Instruments/KI-206/KI-206.xml">
    <offsets>
      <x-m>  0.300 </x-m>
      <y-m> -0.077 </y-m>
      <z-m>  0.133 </z-m>
    </offsets>
  </model>


But supposing it takes it's inputs from another instrument, eg a KC-55S, how does it know where it's data comes from?

Can I extend the code with something like this:

Code: Select all

  <model include="Aircraft/Instruments/KI-206/KI-206.xml">
    <instrument>
      <datasource>/instruments/nav/KC-55S</datasource>
      <data>/instruments/nav/KI-206</data>
    </instrument>
    <offsets>
      <x-m>  0.300 </x-m>
      <y-m> -0.077 </y-m>
      <z-m>  0.133 </z-m>
    </offsets>
  </model>


So that it can use something set by another instrument (radio, compass, etc) to control it's own display. The above example might take a nav output from the radio system and use that for glideslope/compass/nav information, and if it generated any information of it's own, then the next data tag defines where it sits for something else to use it.

[AndersG]

FlightGear supports part of what you want, but not all.

E.g. you can parameterise the properties a 3d model XML wrapper/animation file uses.
Here is an example from Aircraft/Short_Empire/Models/propeller.xml:

Code: Select all

<PropertyList>
 <parameters>
  <engine-rpm>engines/engine[0]/rpm</engine-rpm>
 </parameters>
...
 <animation>
  <type>select</type>
  <object-name>propdiscD</object-name>
  <condition>
   <greater-than>
    <property alias="../../../../parameters/engine-rpm"/>
    <value>675.00</value>
   </greater-than>
  </condition>
 </animation>


Each instance of the propeller model is then included with an overlay for engine-rpm:

Code: Select all

 <model>
  <name>Port Inner Propeller</name>
  <path>Aircraft/Short_Empire/Models/propeller.xml</path>
...
  <overlay>
   <parameters>
    <engine-rpm type="string">engines/engine[1]/rpm</engine-rpm>
   </parameters>
  </overlay>
 </model>


This mechanism allows you to use a single animation file for instruments that can occur in several instances in the same aircraft (e.g. left and right side altimeters etc). However, the cockpit builder still has to create both back-ends in his/her instrumentation file.

As an instrument maker you can still simplify for the users by collecting all files needed together with the instrument (in particular 3d animation, Nasal and property tree XML files can go together as a "package", although the user needs to ensure s/he loads all parts).
The Aircraft/Short_Empire/Instruments/SperryA-2Gyropilot is one example, although the AP implementation itself (for JSBSim) unfortunately is in Aircraft/Short_Empire/Systems/sperry-autopilot.xml due to limitations in how JSBSim searches for system files.

Cheers,

Anders

[majic79]

Ok, Thanks for that Anders,

Could this work?

the instrument defines parameters of what it requires from the top level panel:

Code: Select all

<PropertyList>
  <parameters>
    <gs-input/>
  </parameters>
..
  <animation>
    <type>translate</type>
    <object-name>KI206.gsneedle</object-name>
    <property alias="../../../../gs-input"/>
..


then the panel looks like this:

Code: Select all

  <model include="Aircraft/Instruments/KI-206/KI-206.xml">
    <overlay>
      <parameter>
        <gs-input type="string">/instrumentation/nav/gs-deflection</gs-input>
      </parameters>
    </overlay>
    <offsets>
      <x-m>  0.300 </x-m>
      <y-m> -0.077 </y-m>
      <z-m>  0.133 </z-m>
    </offsets>
  </model>


[AndersG]

Ok, Thanks for that Anders,
Could this work?

Almost, but you need to adjust the path in the alias attribute:

Code: Select all

<PropertyList>
  <parameters>
    <gs-input type="string"/>
  </parameters>
..
  <animation>
    <type>translate</type>
    <object-name>KI206.gsneedle</object-name>
    <property alias="../../parameters/gs-input"/>
..


The '..'s in the alias path are counted from the inside of the current element up to the level where the <parameters> element is. It might also be user friendly to supply a sane default for the gs-input parameter.

/Anders

[majic79]

Well, I gave it a try and when I tried to include the .xml as described, it fell over, specifying include="Aircraft/Instruments..." adds that to the current path of the file used for the panel (eg, if panel.xml is in $FG_ROOT/Aircraft/Something/Models/Panel then the error reported is: unable to find $FG_ROOT/Aircraft/Something/Models/Panel/Aircraft/Instruments/myinstrument.xml)

Prepending a "/" at the start of the path doesn't change it - perhaps this should be changed so that without a starting "/" it looks for a path based on the current location and then goes up from there. Putting a "/" starts at the root of the FG_DATA folder?

Putting enough ../'s in front of the path breaks the loading of the .ac model

Using the <path></path> tags works for an absolute file location (relative to $FG_ROOT, regardless of wether a / is at the front or not), but then I can't overlay the parameters on top of those defined (well, it doesn't appear to do anything)

[D-PH]

Just jumping into the topic:

The Orbiter space flight simulator has the MFDs (multi functional displays), which can be used to show a variety of instruments, including map, glass cockpit style gauges (horizon, speed, height, heading), even the occasional mp3 player or flight planner, autopilot etc.

These MFD programs can be extended via a plugin system.

While all models in Flightgear behave differently, they all allow to run the plugins in their MFDs.

I think something like that would actually be brilliant for FlightGear, especially when I think of all the glass cockpit elements currently in development. They could be put into FlightGear itself rather than only one plane and made available to other developers.

[Hooray]

I think something like that would actually be brilliant for FlightGear, especially when I think of all the glass cockpit elements currently in development. They could be put into FlightGear itself rather than only one plane and made available to other developers.

This is already the case: there's a standard "library" of instruments available in $FG_ROOT/Aircraft - and there are a number of hard coded instruments available, too. None of those are specific to a certain aircraft. That's the whole idea. Most instruments end up getting implemented for a certain aircraft, but then they get generalized and moved to the "shared library directory" with instruments.