Board index FlightGear Support Interfacing

FGFS Interface

Connecting two computers, using generic protocol, connecting with Matlab?

Re: FGFS Interface

Postby daweed » Mon Jul 03, 2017 4:04 pm

www2 wrote in Tue Jun 06, 2017 9:07 pm:@daweed
Is there a git repo of this project?


Now it is, first commit.

https://github.com/daweed38/FGInt

Can't fly theese day, i have some troubles with my scenery resources, i have so made a new panel. It will be used for exemple with the documentation :

Airbus Radio Panel :




EDIT : 2018/10/25 OLD Repos have been disabled. New repos will come soon
Last edited by daweed on Thu Oct 25, 2018 10:20 am, edited 1 time in total.
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGFS Interface

Postby daweed » Wed Jul 12, 2017 7:55 pm

FG Interface documentation update.

Raspberry PI Setup . Done
FGInterface Classes. Done

Writing Documentation on objects classes.
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGFS Interface

Postby www2 » Fri Oct 20, 2017 11:45 am

Any progress update?
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: FGFS Interface

Postby daweed » Mon Oct 23, 2017 4:30 pm

Hello,

Update to "actor" input should be available very soon.
And i am currently working on a management GUI to hide and replace manual configuration.

Daweed
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGFS Interface

Postby daweed » Thu Oct 25, 2018 10:18 am

Hello Guys,

Back into business after several month.

I am now working on FG Interface V2 and will rework the documentation on the wiki

I need some help to take the right way to setup some control.
Here is the radio frequency transfer switch definition in xml file :

Code: Select all
    <animation>
      <type>pick</type>
      <object-name>radio_exchange</object-name>
      <action>
         <button>0</button>
         <repeatable>true</repeatable>
         <binding>
            <command>nasal</command>
            <script>rmp.transfer(1);</script>
            <condition>
               <and>
                  <greater-than-equals>
                     <property>systems/electrical/bus/dc-ess</property>
                     <value>25</value>
                  </greater-than-equals>
                  <equals>
                     <property>controls/radio/rmp[0]/on</property>
                     <value>1</value>
                  </equals>
               </and>
            </condition>
         </binding>
      </action>
   </animation>


And the Nasal function called when the key in the cockpit (3D object) is pushed

Code: Select all
var transfer = func(rmp_no) {
   rmp_no = rmp_no - 1;
   var sel_chan = getprop("/systems/radio/rmp[" ~ rmp_no ~ "]/sel_chan");

   if (string.match(sel_chan, "vhf[1-3]")) {
      var mod1 = int(string.replace(sel_chan, "vhf", ""));
      var mod = mod1 - 1;

      var mem = getprop("/instrumentation/comm[" ~ mod ~ "]/frequencies/selected-mhz");
      setprop("/instrumentation/comm[" ~ mod ~ "]/frequencies/selected-mhz", getprop("/systems/radio/rmp[" ~ rmp_no ~ "]/vhf" ~ mod1 ~ "-standby"));
      setprop("/systems/radio/rmp[" ~ rmp_no ~ "]/vhf" ~ mod1 ~ "-standby", mem);
   }
}


As you can see action is a Nasal script execution. My question is to definie if it's better and more accurate to create a trigger that will execute the nasal function as a "setlistener" in an dedicate nasal lib file for the interface when a property will be toggle [ property define in an xml add on file for example ] or if i should recode directly the Nasal function in my own interface code by creating my own transfer function to be called directly in the main loop program.

Thanks in advance
Best regards

Daweed
Last edited by daweed on Fri Oct 26, 2018 6:43 pm, edited 1 time in total.
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGFS Interface

Postby daweed » Fri Oct 26, 2018 6:15 pm

Hello,

No one knowing FG internal can answer to this ?

regards
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGFS Interface

Postby Hooray » Sat Oct 27, 2018 7:13 pm

Nasal code embedded in XML bindings is usually re-parsed/re-compiled "on the fly", so if you have any substantial routines, it would be better to load your modules separately and only use function calls in your bindings rather than adding your blobs directly to your XML files.
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: FGFS Interface

Postby daweed » Sun Oct 28, 2018 10:59 am

Thanks for answering Hooray. but i am not sure to understand your answer.

Just to be sure , i will not ever recode function in FG "World":
My Own code is writen in python and talk to FG via Generic protocl.

In the Airbus Serie, Freq transfert is made via RMP 3d object button (here talking in the 3D cockpit environnement ) which call a nasal function (already coded and binded by the airbus author.)

I so have 2 choice to made the transfert in the intrerface management :

1°) Recode the function directly in my FG Interface world (so directly in the interface code) and not use the nasal function from the author when i press my real transfert button

or

2°) Delcare a property dedicate to the transfert button (the one on the real panel) and have a listener on that property that will call the author Nasal function to tranfert Freq.

If i understand clealy you position, i should code my own swap freq function outside of FG World and use the second option because, "XML bindings is usually re-parsed/re-compiled on the fly", and with wy own code, i will directly affect Active and Standby Freq skipping original Nasal transfer function.

Does this last statement is correct ?

Sorry to ask twice, i really nice to be sure to follow the best way to interract wiith FG world to not have to modify all thing later

Thanks by advance

Daweed
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGFS Interface

Postby Hooray » Sun Oct 28, 2018 11:19 am

Sorry, I am still not sure if I am understanding correctly.
Speaking in general, whether certain heuristics/routines should be part of flightgear or implemented separately can also be answered by asking yourself if this is something that should work for different fgfs versions. If so, it's obviously easier to implement heuristics in your middleware.

Referring to the two options you listed, I guess my suggestion would be to come up with your own "interface mapping" and then reach out to the corresponding people to implement that, possibly by sharing patches with them.

In other words, I believe this is best discussed with the developers of the aircraft that you are hoping to support.

Speaking, again, in general - assuming that this were some off-the-shelf hardware, there is usually a standard hardware-side interface, and an aircraft-side interface, and a custom mapping to "bridge" these two.

So, I guess, I would suggest to reach out to the corresponding aircraft developers and have this discussion with them.

Once you do that, you will probably realize that your own design will evolve much more clearly by supporting more than just a single aircraft/developer, because you don't want to do any redundant work. Thus, it makes sense to tinker with at least 2 different aircraft and see what kind of interface would make sense to support those, without causing an unholy amount of work.
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: FGFS Interface

Postby daweed » Sun Oct 28, 2018 4:59 pm

Well, i see that i have difficulties to explain.

I take an example of the airbus series beacuse i am working on creating a cockpit for, but my question is made thinking for all aircraft as the interface project is made to be use to create a cockpit for any aircraft
.
Going to try to more explain.

Speaking more generaly, we have some 3d design that are binded directly to properties and some to Nasal function (that the case for example in the airbus IDG series), when pressing, for example, the transfert key on the radio panel (speaking in the 3d cockpit inside the simulator), as showned in the first post, that action call "tranfert" Nasal function that will switch between active and standby frequency .

I have reproduce (in real world) the radio panel and connected it to FG simulator with Generic Protocol.

Power switch, VHx selector are simple to manage, because as like in the 3d cockpit the action directly act on a property.

For example, setting the radio power switch in the 3d cockpit to On act the property "/control/radio/rmp[0]/on", so it's easy for me to reproduce, i just have to send the right value throught the generic protocol

Or selecting the VHF transmitter is done by setting the "/systems/radio/rmp[0]/sel_chan"

Here is my Input XML file [ without the Transfert Key management ]


Code: Select all
<?xml version="1.0"?>
<PropertyList>
 
<generic>
    <input>
        <binary_mode>false</binary_mode>
        <line_separator>newline</line_separator>
        <var_separator>:</var_separator>
        <chunk>
            <name>On Off RMP Switch</name>
           <node>/controls/radio/rmp[0]/on</node>
                <type>integer</type>
        </chunk>
        <chunk>
            <name>Channel Selection</name>
      <node>/systems/radio/rmp[0]/sel_chan</node>
                <type>string</type>
        </chunk>
    </input>
</generic>

</PropertyList>


so to act on this system, i just have to send 1 or 0 [integer] for the power switch and vhf1, vhf2 or vhf3 [string] for the channel.

Now, regarding to the transfert key [ and generally all action calling Nasal code instead acting directly on properties ], my is question is to underderstand if:

1°) i havve to add a property on the tree with an add on xml file, for example "/fgint/freqsw", and send to this property 1 when the "real key" is pressed, linked to a "setlistener" function on this property that will call the nasal function "transfer" when the "/fgint/freqsw" is set to 1

OR

2°) code direcly in python the transfert function and act throught the generic protocol on properties that are normaly managed by the original nasal "transfer" function [ and so in this cas, bypass each time the nasal function ], meaning sending, in this case, direct value to "/instrumentation/comm[" ~ mod ~ "]/frequencies/selected-mhz", and "/systems/radio/rmp[" ~ rmp_no ~ "]/vhf" ~ mod1 ~ "-standby"

So my question is , i think in the general range, to definie if it's better and more efficient to use already existing Nasal code, but this mean that i will need to add some properties to use them and a listener to execute Nasal code associate with them [ i.e i don't find other way to call nasal function from outisde the simulator ] or act directly to properties [ but that mean that each aircraft could need a specific interface coding ]

PS : Where can i find what happen when pressing the switch freq key on the FG radio panel (F12)

Hopping this will explain what i am doing and why i am asking myself about this.

The 2 methods can be easly setup , i need help to understand what will be more accurate and efficient.

Thanks for your patience

Regards

Daweed
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGFS Interface

Postby curt » Sun Oct 28, 2018 5:43 pm

Long ago when I did something similar for a Navajo twin simulator cockpit, my basic strategy was for the hardware interface to write to it's own property names when there wasn't a direct 1-to-1 relationship with something that already existed in flightgear. Then I had a set of nasal code that ran every frame that looked at these custom property names/values, did some scripting work, and wrote the result into the tree where the rest of flightgear expected it. In many cases, the inputs where physical switches, and the outputs were custom xml gauges, with some sort of system model in between (like a detailed electrical model.) So FlightGear itself never really even cared, it just hosted this information exchange through the property system.

We ended up with several custom aircraft + xml configs + nasal systems models that ran with stock flightgear, but the data flow was from custom hardware -> nasal scripts -> custom xml (2d) panel (or -> custom hardware, like a radio stack 7 segment display.)

I know nasal listeners are popular for values that don't change very often, but most of my work involved systems models that I wanted to update every frame so I just kept my nasal code and property tree usage as simple as possible and ran things every frame.

Generally properties are created when you reference them and use them, so your code can make things up as it goes along so to speak.
Aerospace Engineering and Mechanics
University of Minnesota
curt
Administrator
 
Posts: 1168
Joined: Thu Jan 01, 1970 1:00 am
Location: Minneapolis, MN

Re: FGFS Interface

Postby daweed » Mon Oct 29, 2018 12:52 pm

Hooray, Curt, thanks for your time and your answer, i see now where i can go and how i can setup all this stuff..

Regards

Daweed
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGFS Interface

Postby daweed » Fri Jan 04, 2019 7:52 pm

Hello guys, some new from the dev cavern .. :D

First "production" board arrived at home for christmas

FGFS Interface Mother Board

Image

128 Digital Inputs (siwtch , rotary encoder, push btn .. etc)
256 Digital Outputs (led anounciator, display ... )

For example [ check the FG wiki ] you can connect RMP Panel to the mother board

Image

Image

Some system are so complex that they can totally autonomous as like the Airbus FCU

Logic Board
Image

Front Board
Image

Image

The Airbus FCU reproduce all function [ push / pull included ]

FG interface can be used with any plane, i use to fly Airbus series since i begun to fly with Flightgear, that why my project is based on Airbus and this will be the cockpit i am building, but there is no problem to create a Cesna cockpit or even the Shuttle one. [ that will just require lots of FGFS Interface for the Shuttle :P ]

More than one interface can be connected to FG ... limit is your imagination

All is not clear and perfect, and software [ FG Int ] need to be improve, but concept is fully working.
Last edited by daweed on Mon Jan 07, 2019 12:01 pm, edited 1 time in total.
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGFS Interface

Postby Hooray » Fri Jan 04, 2019 8:47 pm

For something like 128/256 potential new values (properties), it is probably a good idea to come up with a mechanism that doesn't rely on polling or listeners, e.g. something like PUB/SUB (publish/subscribe).

It would be relatively easy to extend an existing I/O mechanism accordingly, or even introduce a new binary protocol option.

Given the degree of progress you have been making, I would definitely suggest to reach out to the devel mailing list and introduce your project there. There are a handful of other cockpit builders who may be able to provide feedback that might end up saving you tons of hours of tinkering.

For instance, many professional sims end up using an actual aviation bus and the corresponding protocols - often to make it easier for actual hardware to be interfaced to the simulator (think ARINC-style comms).

Since you have made so much progress with this, it's obvious that you are very serious about this, so I would suggest to introduce your project on the devel list. For starters, you could use the wiki to create a nice intro/summary, including some screen shots, and then post that to the devel list. Who knows, maybe there are even people who would like to get involved ?

You might also want to add your project in the FlightGear newsletter (wiki).

Anyway, personally I would not use any of the existing I/O means "as is" to potentially encode 256 update channels (properties).

We ran into the same issue when we wanted to support ARINC style avionics bus, and for J661 we ended up adapting the telnet protocol to provide support for "subscriptions" implemented on top of listeners (C++).

Something like that should also work for binary protocols.

Fortunately, the project is overlapping with existing features (think flight recorder subsystem multiplayer protocol or multi-instance setups).

Thus, adding a few dedicated native hooks to fgfs might be a pretty good idea actually.
I believe there's also the long-term idea to provide USB/USB HID support via native hooks.

In other words, 256 I/O options is not some kind of typical toy-use, but could quickly approach professional requirements - so you might be better off talking with fellow cockpit builders.
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: FGFS Interface

Postby daweed » Fri Jan 04, 2019 10:35 pm

Hello Hooray,

Thanks for your reply and informations.

FGFS interface is already on the wiki [ have a look on my signature ]
Had to pause my dev during last year due to health reason and the wiki have not been updated as it should be, but now problems are behind me, i am now focus on the next step.
Wiki will be updated to reach the actual dev state.

FG interface will be package as free software with a GUI to configure the all thing [ even setting some "logic" between properties is possible ] but all of this is actually under dev.

"it would be relatively easy to extend an existing I/O mechanism accordingly, or even introduce a new binary protocol option."

Not sure about what u are talking here, but i don't have any skill in c/c++ and clearly no more to create binaries or modifying FGFS code [ even on add on like ]
But if you can show me the way where i could find usable documentation and example on how to implement a new protocol ... i am open to learn.

The solution is absolutely not built around "USB/USB HID " system .. as the interface is not connected to any computer. The interface is completely autonomous, based on a Raspberry and talk with the simulator through the network.

Best regards
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

PreviousNext

Return to Interfacing

Who is online

Users browsing this forum: No registered users and 1 guest