Board index FlightGear Support Interfacing

FGFS Interface

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

Re: FGFS Interface

Postby Hooray » Sun Mar 29, 2020 8:36 pm

once suitable baseline to start with would be an aircraft's set of bindings/multiplayer properties and flight recorder/fgtape config (instant replay).
This is again something where looking at Emesary (wiki) may pay off quickly, very quickly.
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 Johan G » Sun Mar 29, 2020 8:43 pm

Johan G wrote in Sun Mar 29, 2020 8:18 pm: But mainly FGInterface is aimed at Airbus airliners.

daweed wrote in Sun Mar 29, 2020 8:28 pm:Nope nope :), that probably wrong explained by me [...] FGInterface can be use for any aicraft [...] the only limit is people's imagination.

Only thing to be know is which properties need to be affected ... and as each aircraft developer use their own ... [...]

No, that is my bad for skimming through your articles too briefly. :oops: :lol: Thanks for the clarification. :)
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: FGFS Interface

Postby Puffergas » Tue May 05, 2020 6:37 pm

This must be the Wiki, http://wiki.flightgear.org/Howto:Build_your_own_Panel_or_Cockpit ?

Is there something I could help with? Like uploading some of the OP's photos? I have not read through the whole post.
Puffergas
 
Posts: 56
Joined: Thu Jan 02, 2020 2:09 am

Re: FGFS Interface

Postby daweed » Sun Oct 04, 2020 5:55 pm

Hello Guys

ATC panel test in progress.
Sorry for the video quality :)

Enjoy

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 biloute974 » Sun Oct 04, 2020 8:27 pm

Very nice job ;)
Intel I7 7700 - 16Gb DDR4 - Nvidia GTX970 - FG 2017.4.0 from D&C
biloute974
 
Posts: 193
Joined: Mon Feb 23, 2015 9:49 am
Callsign: U974
Version: 2016.1.0
OS: Mint 17.2

Re: FGFS Interface

Postby daweed » Thu Nov 05, 2020 10:13 am

Hello Guys,

Some little news.

Working actually on Korry switch style, some pics of the prototype :

All seperated parts, from left to right :

the pcb

the body and the button, 3D printed (Black resin)

The 2 last parts are printed too, in clear resin , the square part will be finally the only one, and will be painted in black and engraved (i don't made the job for the moment :) )

Image

Image

Image

Image
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 D-AINR » Mon Nov 30, 2020 2:40 pm

Hi Daweed,

Your work is just amazing!
I forked your GitHub repository and would like to have the PCBs produced by an online service.

Have you published any other parts?
The 128 I / O board and the 7-segment board and the Airbus panels maybe?

I am planning to build an A320 cockpit with FlightGear and would like to start with the IT infrastructure.

regards
Robert
D-AINR
 
Posts: 3
Joined: Fri Nov 06, 2020 7:30 pm

Re: FGFS Interface

Postby daweed » Tue Dec 01, 2020 2:15 pm

D-AINR wrote in Mon Nov 30, 2020 2:40 pm:Hi Daweed,

Have you published any other parts?
The 128 I / O board and the 7-segment board and the Airbus panels maybe?

Robert


Hello,

Well my health doesn't really give me much time at the moment to work on the simulation.

i need to update my repo, but yes, I have several things in my boxes.

Pay that all in the software is not totally finished (specially the documentation), but all that is on the wiki is working as it said.

So hardware talking [ i will try to upload in the hardware repo for the end of week ] and fully tested and working :

* 128 I/O Motherbord (but this version is not able to take advantage of interruption pin)
* Display motherboard
* EFIS (both CPT & FO)
* FCU (fully working, P/P included)
* Korry switch

Actually working on :

* ATC
* RMP ( the old version does not fit to last mother board connections and need to be remap)

Best 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 » Thu Jun 23, 2022 5:23 pm

Hi guys,

I know it's been a while since I've given any news and I apologize for this laziness. I had promised things and I didn't do them. So here's some news

firstly, the project is not dead, it has been "sleeping" for more than a year mainly for lack of time but also for laziness it must be admitted anyway. It didn't prevent me from working a little on the project, mainly on the transponder panel, the management of the matrix keyboard has been reviewed and improved. I haven't taken the time to update the repository yet, but it will be done in the coming weeks and the repository will also be updated with all the hardware cards I have developed.

Second, I'm going to dive back into the wiki and update it.

Thirdly I am finalizing a GUI which will allow to configure the interface at first then gradually to create the management logic directly via the GUI. FGInt will be so more friendly to use.

Fourth, now that the bulk of the systems have become manageable (switch, double switch, korry, rotary encoder, push button, led, display, etc.) I'm tackling the biggest piece: the MCDU.

I've been thinking about it for a few months now. I've come to the conclusion that it's not going to be as easy to implement as the rest. after studies, it seems to me that I only have two more or less equivalent solutions with the raspberry which is the basis of my interface system (I have voluntarily banned the simple touch display via another pc / screen, but we agree it is a solution but I would not retain it). So I was saying that I see two solutions which, in my opinion, both present great difficulties.

The first would be to be able to run a complete Canvas system with Qt on the pi. I have not managed to find documentation allowing me as a simple user to implement the thing to run the display of the MCDU remotely on the Raspberry. Having no knowledge in the Canvas system, it does not help matters.

The second solution would be to reimplement the MCDU as a completely standalone interface with full logic & management system, but that's a titanic job. It would be necessary to analyze the code (in my case) of the airbus MCDU, And it would have to be done for each CDU... remind you that until now and to guarantee perfect compatibility with any aircraft, the interface only replaces the click of the mouse or the key on the keyboard, at no time the logic implemented in aircrafts have been installed in the interface, the logic remains in the plane. For the MCDU it's not that simple. For now for the display with the second solution would be to use Qt (PySide2) to create and manage the display; this point is mastered; the problem is connecting this display to the simulator and retrieving the data. With Qt, GUIs run in a loop waiting for an event, but it seems that nothing is planned for these events to come from outside, Qt will handle an event because a button on the GUI has been pressed , or a time event, but I haven't found the solution yet so that this "trigger" can come from Flightgear

So if anyone knows with examples and adequate documentation how I could display the MCDU canvas of the 320 or 330 remotely on the raspberry screen, I'm interested in the solution and I'll never be tired of a life to thank him for it. From my side and as my knowledge in Qt I would try to find a solution with a GUI in Qt. After a few readings, I could go back to the basic principle of my interface (communication via TCP sockets) and use threads in the code python.

Here is where I am currently...

Here is a quick test I was able to do, it's totally static, a Qt application done quickly with PySide

Image

Image

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 » Fri Jun 24, 2022 8:49 am

you need to distinguish between the different approaches to replicating a Canvas display outside fgfs:

- streaming a static image
- streaming an mjpeg ("movie"-style)
- streaming properties to another process to re-render the canvas out-of-process

obviously, streaming an mjpeg is pretty easy and supported out-of-the-box - but it's mainly an option in a LAN setting, due to latencies involved:
Image

Using something like FGQCanvas is the 3rd option, i.e. re-rendering the Canvas outside fgfs by sync'ing properties between fgfs and the RPi:
Image

However, the thing is, FGQCanvas is a re-implementation of the Canvas system (using Qt), and as such it is not fully compatible with the native Canvas system integrated inside fgfs, i.e. it doesn't support certain features, or is using a different back-end/implementation internally, so that looks/function may differ.

Thus, if you prefer the 3rd option, the best option for fidelity is simply running a down-stripped version of fgfs on the RPi, with just the Canvas and its dependencies running there, and other subsystems entirely disabled, with key state synchronized between the main fgfs session and its "slaves".

You'd end up with a fgfs binary that can optionally disable many subsystems:
Image

We have previously succeeded doing this using the props/telnet protocol, basic setup is outlined here: https://wiki.flightgear.org/Canvas_prop ... ave_setups

That idea, is called "FGCanvas" - i.e. minus the "Q" (Qt), just a different fgfs startup mode for the sake of 100% compatibility, it's outlined here: https://wiki.flightgear.org/FGCanvas


That's certainly the best option if you are bound by round-trip latencies or if FGQCanvas is not an option - but it will definitely require modifications to the C++ source code.

That being said, Erik Hofman came up with DDS support a while ago: https://wiki.flightgear.org/Data_Distri ... es_support

It should be fairly straightforward to take his work and use it to come up with a "canvas-sync" protocol, to replicate a Canvas across multiple fgfs instances - back when we prototyped this in the pre-DDS days, we were merely using the props/telnet option, and that wasn't very efficient/clever, but it worked well enough.

These days, something more sophisticated would seem more appropriate - i.e. DDS, Emesary over sockets or HLA/RTI - realistically, only the first two are actual options, HLA/RTI has been pie-in-the-key for over a decade now.

If DDS seems too sophisticated, but you are already familiar with fgfs internals, you could use sockets an fgcommands in conjunction with Nasal and Emesary: https://wiki.flightgear.org/Emesary

On the other hand, none of this is relevant if you have never patched/rebuilt fgfs from source, or if you don't have working C++/git knowledge - in that case, I'd suggest to use the httpd based approach outlined here: https://wiki.flightgear.org/Read_canvas_image_by_HTTP
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 » Sat Jun 25, 2022 10:20 am

Hello Hooray,

Thanks for all the information, I will study this information.

Static image streaming does not seem to me to adapt to the situation (need to have a real-time update)
The system via a web browser would cause me a "style" problem (I don't know if I will be able to "hide" the window borders)

I also don't have the skills required to modify the FG code (lack of knowledge in C / C++ languages)

it seems that an image is missing (at least I don't see it) below the sentence:

"Using something like FGQCanvas is the 3rd option, i.e. re-rendering the Canvas outside fgfs by sync'ing properties between fgfs and the RPi:"

Modifying the FG code to make it a "lite" version to run the canvas in standalone ur RPI is not necessarily within everyone's reach and FG Interface being designed to be "user friendly" and easy to use, which this solution does not seem adequate to me either.

I appreciate however, be sure, all the effort made to give me these solutions.

I continued on my side to look at how I could solve my problem and indeed the most viable solution remains in my opinion the synchro of properties. I think I can get out of this problem with the python thread system, I need to do some tests to validate, but I think I'm on the right track.

So as the FGQCanvas is not planned before a Flightgear 4.x according to the article, I will first start by reimplementing the screens by trying to synchronize the properties, in any case there is no question of reimplementing the logical whatever happens to a device it would undermine compatibility with other aircraft, if there are only Qt screens to develop there is nothing insurmountable from the moment I I manage to synchronize the properties in real time as I did for the other organs (FCU, EFIS, Transponder .. etc)

So thanks again really for all your efforts & informations,

I will give news soon.

At the same time for those interested, I updated the FGINT-HARDWARE repositories for the PCBs, the EFIS CPT & FO are available as well as distribution circuits and a circuit dedicated to connecting Korrys.

The Korry PCB has also been pushed (the 3D elements are available in the FGINT-3D repository)

With my respect

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 » Sat Jun 25, 2022 2:40 pm

Static image streaming does not seem to me to adapt to the situation (need to have a real-time update)
The system via a web browser would cause me a "style" problem (I don't know if I will be able to "hide" the window borders)


You could also fetch/stream the live image using a different application and merely display/update the image, you don't need to use a full browser just for that.

I will first start by reimplementing the screens by trying to synchronize the properties, in any case there is no question of reimplementing the logical whatever happens to a device it would undermine compatibility with other aircraft, if there are only Qt screens to develop there is nothing insurmountable from the moment I I manage to synchronize the properties in real time as I did for the other organs (FCU, EFIS, Transponder .. etc)


I'd suggest to look at Erik's recent DDS work:

Hooray wrote:Erik previously talked about his DDS work and how that's limited to fixed structures, subsequently he mentioned Google Proto buffers and the new "property server" implementation using DDS.

Since a Canvas is nothing more than a property tree hierarchy (path with child nodes), maybe we could think of using this to "sync" (replicate) a local property tree node like /canvas/by-index/texture[0] to another fgfs instance using DDS ?

Image

I had this previously working using just the telnet/props protocol, i.e. by manually hooking up two locally-running fgfs instances and replicate a canvas from the master to the slave instance. But with DDS, that sounds like a better option ?

I guess, one proof-of-concept could replicate a single property path (node) to another fgfs process by using just the ID of the canvas texture, something like --native-canvas=dds, ID, out,30
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 » Tue Jul 19, 2022 10:20 pm

Hello, some news

Well PCB & Faceplate have been received.
I ordered a 5 inch display in 4:3, hdmi connected to raspberry pi.

Image Image

I am not closing the door to send display to the pi, but well, i actually choose to re create each screen with QT. I have some adjustement with font to do, but here it is some quick test :

Image Image Image

Now that i know that is working, i need to focus on MIPS création, but it's hard to find A330 cotation & size .... all website are massively talking about the A320 ... Maybe I should go back to the A320 which is actually more precise and more developed than the A330... that will be the next step and the decision to be made this summer. I plan to start construction this winter.

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

Re: FGFS Interface

Postby daweed » Wed Jul 20, 2022 3:07 pm

Hello ,

Is there a way to set a listener on a function rather than a property? I would need to detect when a specific function is executed and I do not want to modify the original code of this function so as not to have a problem with each update of the aircraft ?

Regards

David
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 TheEagle » Wed Jul 20, 2022 6:19 pm

Make a wrapper around the function like this:
Code: Select all
globals.controls._startEngine = globals.controls.startEngine;
globals.controls.startEngine = func(v = 1, which...) {
    debug.dump(v);
    globals.controls._startEngine(v, which);
};
Cessna 210 (Wiki)
My other aircraft: my wiki profile !
Other: FGTools (GitHub)
World tour: View on SkyVector
Please consider donating $1 / €1 to help me finance a new camera !
User avatar
TheEagle
 
Posts: 3411
Joined: Sat May 01, 2021 3:27 pm
Location: France
Pronouns: You, he
Callsign: F-EAGLE
IRC name: none
Version: Git next
OS: Ubuntu Studio 22.04

PreviousNext

Return to Interfacing

Who is online

Users browsing this forum: No registered users and 3 guests