Board index FlightGear Support Interfacing

Vertical fgpanel

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

Re: Vertical fgpanel

Postby dhudach » Fri Feb 21, 2020 5:34 pm

Sooooo, have you had any luck running fgpanel from the tools folder? Information or anything you've learned that you post here could be helpful to others ....
Flight Instruction Elevator Control: pull back = houses get smaller, push forward = houses get bigger.
dhudach
 
Posts: 118
Joined: Tue Apr 14, 2015 12:46 am

Re: Vertical fgpanel

Postby Kaosiia » Tue Feb 25, 2020 10:16 pm

hey, so it looks like i do not have fgpanel with my flightgear.
I have no switched to using the web panel. Are you familiar with the web panel at all? I am utilizing the one for c172p.
I have been able to start it up with flight gear by using -httpd=8080.

1. I am wondering, is it possible to implement the web panel such that immediately flightgear opens, the web panel opens with it. So, both opens simuntaneously. Without me having to click 'Panel in a browser', when flight gear starts.
2. Is it also possible to have the aircraft removed from the screen, such that it is only the outside view showing. i have been able to do that once flight gear opens by clicking 'C' but i wonder if it is possible to implement this before opening flightgear. So, when flightgear does open, it opens up without the aircraft on the screen. Preferably, starting with the aircraft in the air.

Thank you so much!
Kaosiia
 
Posts: 71
Joined: Fri Jan 24, 2020 1:06 am

Re: Vertical fgpanel

Postby dhudach » Tue Feb 25, 2020 11:31 pm

What was fgpanel in the tools folder that you found?

At this point I don't have answers to all of your other questions. I used webpanel for a while but decided to try fgpanel. I had decent luck with webpanel.

I don't know if you can open fg and have your browser open at the same time. I'm not sure if fg can trigger a browser. It's something we would have to investigate. I believe there are ways to remove the aircraft from the screen, but I'm not sure how.

We'll have to do some additional research on those questions.
Flight Instruction Elevator Control: pull back = houses get smaller, push forward = houses get bigger.
dhudach
 
Posts: 118
Joined: Tue Apr 14, 2015 12:46 am

Re: Vertical fgpanel

Postby Kaosiia » Wed Feb 26, 2020 12:17 am

It was literally the same thing as command prompt. i dont know how to explain it but it was a command prompt, but instead of called command prompt, it was called fgpanel.
Kaosiia
 
Posts: 71
Joined: Fri Jan 24, 2020 1:06 am

Re: Vertical fgpanel

Postby dhudach » Wed Feb 26, 2020 12:34 am

That's odd indeed. You could hop over to the compiling flight gear forum to ask how to build fgpanel for Windows. They might have some answers for you there. Webpanel was ok, it was a good way to experiment with some of the features of flightgear, but I kind of like fgpanel a bit more.
Flight Instruction Elevator Control: pull back = houses get smaller, push forward = houses get bigger.
dhudach
 
Posts: 118
Joined: Tue Apr 14, 2015 12:46 am

Re: Vertical fgpanel

Postby Hooray » Wed Feb 26, 2020 2:45 pm

dhudach wrote in Tue Feb 25, 2020 11:31 pm:I don't know if you can open fg and have your browser open at the same time. I'm not sure if fg can trigger a browser. It's something we would have to investigate. I believe there are ways to remove the aircraft from the screen, but I'm not sure how.



yes, this can be done - and this is how the help menu opens included HTML files, too

Note that fgpanel and Phi were both developed by the same developer, and that he said on several occasions that he'd consider "fgpanel" deprecated by Phi (wiki)
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: Vertical fgpanel

Postby dhudach » Wed Feb 26, 2020 3:00 pm

Thanks for the information. I experimented with fgpanel and webpanel. I then decided to write a python version of fgpanel. I realized that these features essentially animate graphics based on data. In essence they don't need to know anything about flight simulators. The python version worked fine, but may have had some lag, especially on smaller, less powerful PCs. I then wrote a version in C++ using SDL. When I continue on my cockpit simulator project in a couple months, I'll probably use my C++ (cppanel) implementation to animate all of my gauges and instruments. The actual reason I branched into python and C++ is because I wanted to try to compile fgpanel on Raspberry Pi but just had too many issues. And that's when it occurred to me that animating the gauges and instruments really didn't need Flightgear. The program is configuration and data driven.
Flight Instruction Elevator Control: pull back = houses get smaller, push forward = houses get bigger.
dhudach
 
Posts: 118
Joined: Tue Apr 14, 2015 12:46 am

Re: Vertical fgpanel

Postby Hooray » Wed Feb 26, 2020 3:08 pm

right, technically that's a very good call - it's completely irrelevant what kind of data source is used, this is also how some X-Plane software manages to also support FSX or other sims, i.e. you only need a generic mechanism to animate gauges and get data out of another process (usually over networking)

For the sake of completeness, you could review the devel list archives, I believe there's recently been some talk about "porting" fgpanel to support OpenGL ES, specifically to target mobile/embedded hardware, but I don't remember the details.

Other than that, if you are interested in sharing your work, you might want to document it using the wiki (dedicated article and/or newsletter entry).

The python version might even come in handy for the experimental FGPythonSys mode, where fgfs supports python for scripting purposes.

Speaking in general, SVG would seem like an ideal format to represent gauges - as a matter of fact, FlightGear's Canvas system uses internally OpenVG, which is used to implement support for a subset of SVG.

There is also a standalone re-implementation of the Canvas system using Qt, called FGQCanvas (check the wiki).

In other words, given that you already know C++, you might be interested in looking at existing work, either to review your own approach or possibly to join efforts with people working on related projects.

Obviously, we have a growing community of home cockpit builders interested in this sort of thing, so at the very least it would be great if you could document your work, so that others can more easily find it, and possibly get involved in adding to it.
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: Vertical fgpanel

Postby dhudach » Wed Feb 26, 2020 3:20 pm

Yes, all good ideas. Once I get some of my work organized and cleaned up I'll do that.

As I'm thinking back, I either used existing instrument image files, or modified some or created some of my own using Inkscape (svg) and exporting to png.

Thanks again for the information and suggestions.
Flight Instruction Elevator Control: pull back = houses get smaller, push forward = houses get bigger.
dhudach
 
Posts: 118
Joined: Tue Apr 14, 2015 12:46 am

Re: Vertical fgpanel

Postby Hooray » Wed Feb 26, 2020 3:39 pm

the existing 2D panel infrastructure is rather simple, and it is indeed based purely on "transformations" and various stacked textures that may respond to events (dialing a knob) - this is how most "steam cockpits" can be represented, however there are obviously shortcomings when it comes to modern/glass cockpit-style aircraft (PFD, ND, EFIS etc)

The Canvas system is hardware-accelerated, i.e. uses OSG/OpenGL internally - but in its current form its expects to run inside the fgfs main loop, FGQCanvas is a standalone reimplementation that renders Canvas primitives (text, raster images, paths) using Qt calls - also, it's not completely up to par with the original implementation, i.e. there are known inconsistencies/issues, especially when dealing with legacy Nasal/Canvas code that the re-implementation does not support.

In addition, there is support for "streaming" a canvas texture to another process - currently over http(d), but that could also easily be changed to use a different/more suitable protocol, e.g. to show avionics via VNC or VLC player

For your specific project, it would make sense to revisit looking at just streaming vector instructions, and OpenVG being commonly supported on embedded hardware, that would be one obvious candidate

Primarily, this is because you won't run into resolution/scaling issues with vector graphics - also, any canvas can be represented as an SVG image, i.e. if you can render SVG files, you could also stream the relevant parts to have them rendered by fgfs.

Depending on your background, and if you are able to patch/rebuild fgfs from source (using git), it would also not be very far-fetched to extract/isolate the canvas component in fgfs and also build it standalone, analogous to how fgpanel is basically an extracted version of the 2D panels system. This would require a few tweaks, and change to the cmake files - but it would not be that difficult to come up with a standalone "fgcanvas" binary that only requires OSG.

Typically, this would then have its own property tree to copy relevant contents from the main/global property tree "on change" (aka lazy updates using listeners).

Note that the canvas system lives already inside simgear, so is intended to be built "standalone", it's just the fgfs integration that has to be extracted from fgfs, everything else is already in simgear: http://wiki.flightgear.org/FGCanvas

Besides, once you have a binary that has a standalone canvas integration, it is also trivial to write a parser to render all sorts of existing 2D resources, including 2D instruments, complete 2D panels or even HUDs/GUI dialogs - all running on another box: http://wiki.flightgear.org/Unifying_the ... via_canvas
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: Vertical fgpanel

Postby dhudach » Wed Feb 26, 2020 4:12 pm

Fascinating. I had seem some posts recently on the Canvas system and it looks very interesting.

I've done some QT coding. I don't mind it. I think for a while I was tinkering with a line drawing program so I probably used the QT Canvas system. But when I built the C++ panel implementation, I wanted to essentially work from as basic C++ code as I could and build from command line rather than IDE. For me sometimes it makes life easier and offers the potential to make it easier to build on another machine without installing too many peripheral components. But I'm retired, somewhat an old school developer. I'm not against newer tools and IDEs, I just have a comfort level. I guess what can happen is that venturing into other methods and tools means spending a great deal of time learning them and taking a lot of side trips getting them to work. Sometimes they end up becoming time consuming projects of their own, completely separate from the main goal. But I digress.

As far as graphics, SVG in Inkscape has been ideal. I would like to have been able to render using SVG, but I don't think I found a way to do it in fgpanel, my python and c++ panels. I think I was only able to display using rgp or png files. I think because of that some of the graphics, especially font characters just don't look crisp. But I haven't really dug into that too much.

I did manage to build my current fg using the download and compile script. I'm running Linux Mint. It took some effort but I got it built. I would be interested in doing some of the things you suggest - modify the code to leverage features that I need. But at this point I'm going get what I have working to get a functioning cockpit then spawn off projects that represent improvements. It can be too easy (for me anyway) to march off into separate projects and leave behind the original project!!

Ultimately, I do realize that it makes sense to customize some of this stuff for my needs.

I appreciate the information you are providing. I'll definitely look into it!!

Dave
Flight Instruction Elevator Control: pull back = houses get smaller, push forward = houses get bigger.
dhudach
 
Posts: 118
Joined: Tue Apr 14, 2015 12:46 am

Re: Vertical fgpanel

Postby Hooray » Wed Feb 26, 2020 4:36 pm

Note that the Canvas system integrated in fgfs is a custom-one, unrelated to any Qt code - because the addition of Qt code has been a controversial thing among long-term contributors, who ultimately required any Qt code to remain optional, so as not to "taint" the rest of the fg code base, but also in order not to introduce huge additional dependencies.

The FlightGear canvas system requires only what is required to build simgear, so that's primarily an OpenSceneGraph (ShivaVG - the OpenVG implementation is part of the source tree).

FlightGear's build system uses cmake, and so does simgear - it is indeed possible to build both using just the console, i.e. no IDE required.
I usually use vim and a few open terminals, one for each source tree (simgear, flightgear and fgdata) - that way you end up with a few "windows" (tabs really) to easily edit things, and only need 2 more to easily build/run your changes.

I am not sure about the d&c script, but on Linux you can set up ccache and distcc to speed compilation considerably, i.e. rebuilding fgfs will only take a few seconds afterwards, at the cost of keeping a cache of linker/object files.

I think I have previously seen projects here where people built some middleware to render vector graphics and animate those by getting the corresponding properties out of fgfs, so you don't need to do anything fancy there.

What the FlightGear canvas system does is simply run a scripted parser to interpret a subset of SVG/XML to look for supported directives, which are then mapped to flightgear equivalents (mainly text, raster images and path drawing instructions)

Basically, any canvas can be represented as an SVG file, and it is comparatively straightforward to add to the SVG parser to add support for missing instructions.
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: Vertical fgpanel

Postby dhudach » Wed Feb 26, 2020 5:25 pm

Outstanding. I think the key for me there is that there is no QT dependency which I like. I'm definitely going to look into the other build options (aside from download and compile).

My springtime goal is to build a new PC and create 3 bootable Linux OS systems. Harking back to my development days : dev,qa, production. This way once I get my initial production system running the way I like, I can use the development OS to tinker away without messing up my running project. This means I can experiment with various compile methods and options and delve into the canvas systems we are talking about here.

I do like the idea and flexibility of custom code to build exactly what I need. The good thing is that FG pretty much out of the box is very robust and has given me all I need to develop all of my initial arduino interfaces and code. Sometimes what "comes next" is based on what I might need next. At this point, what I imagine I'm going to do is place a few monitors behind my cockpit panel so that the instrument layout on each is close enough to the layout of the plane I'll be flying. That's going to be a bit tricky because of hardware placement (yokes, etc). But I'll do the best I can. What I hoped to do was use a Raspberry Pi to drive each monitor (on Pi per monitor). But when I couldn't build fgpanel on Pi, I branched off to pypanel and cppanel (my python and c++ fgpanel implementations). I was able to run python panel on the Pi and as expected it was kind of slow. I have not yet tried to build the C++ panel on Pi yet. To do that means installing the SDL components, but that shouldn't be too difficult. Once I do that, I'll know what I'm dealing with, at least as far as trying to use Pi to animate a handful of instruments. This is my python program running on my laptop where my instance of flightgear exists:


I don't think I have a cppanel video. I'll get to that at some point.
Flight Instruction Elevator Control: pull back = houses get smaller, push forward = houses get bigger.
dhudach
 
Posts: 118
Joined: Tue Apr 14, 2015 12:46 am

Re: Vertical fgpanel

Postby Hooray » Wed Feb 26, 2020 5:57 pm

I think that this is definitely the kind of project that many people around here will be interested in, so it would be great if you could regularly report back here - you will probably find many people willing to provide pointers, patches or just feedback/ideas.

Some of us are actually hoping to grow a community of DIY-ers, i.e. folks interested in home cockpit building, including the hardware and software side.

Depending on your goals, priorities and roadmap/schedule, you might even find a few folks interested in teaming up with for some parts of your project.

That being said, customizing the existing integrated canvas system to work "standalone" is not such a mammoth task at all, like I said, it already lives in simgear, which is the "library-part" of FlightGear, so it's prepared to be used by other software. And if I were to tackle that, I would simply reuse the existing sources in flightgear, and add a new optional build target, to come up with a canvas-only binary. This would not necessarily be "ideal" from an architectural standpoint for fgfs itself (which would tremendously benefit from the work needed to make this sort of setup possible using the existing binary/infrastructure), but it would be much less work compared to re-architecting fgfs itself.

Under the hood, the work would be equivalent to stripping out the 2d panels code into a separate binary, and adapt that as needed to make it run/work - which is what Torsten did originally.

The good thing here is that this is primarily about extracting/stripping off unneeded parts, i.e. it's not so much about writing new code, but more about disabling old code, to come up with a tiny subset of subsystems to run a simple main loop with 5-6 systems to make just the canvas system work.

For some background info about the "canvas system" itself, see: http://wiki.flightgear.org/Canvas_Development

Someone with working C++ knowledge, and with a checked out set of sg/fg/fgdata repositories could probably get going rather quickly - for instance, a while back, we used the same approach to implement a "fgradar" application, by reusing useful fgfs subsystems in a standalone binary, at the mere cost of also providing the usual flightgear specific main loop: http://wiki.flightgear.org/FGRadar

You can look at the tiny footprint of the architecture here: https://gitorious.org/fgradar/fgradar?p ... git;a=tree

Specifically, look at main.cxx and fgradar_app.cxx which contain all the boilerplate needed to reuse FlightGear subsystems in a standalone fashion: https://gitorious.org/fgradar/fgradar?p ... 69;hb=HEAD


Code: Select all
#include <iostream>
  39 #include <simgear/structure/exception.hxx>
  40
  41 #include "fgradar_app.hxx"
  42
  43 int
  44 main(int argc, char **argv)
  45 {
  46     using namespace fgradar;
  47     
  48     try {
  49         fgradar_app = new FgradarApp(argc, argv);
  50         fgradar_app->run();
  51     } catch (const sg_exception &e) {
  52         std::cerr << e.what() << "\nAborting..." << std::endl;
  53         return 1;
  54     }
  55
  56     delete fgradar_app;
  57     
  58     return 0;
  59 }



Code: Select all
  26 #include "fgradar_app.hxx"
  27
  28 #include "multiplayer/traffic.hxx"
  29 #include "scripting/NasalSys.hxx"
  30
  31 namespace fgradar {
  32
  33     FgradarApp *fgradar_app = NULL;
  34
  35     FgradarApp::FgradarApp(int argc, char **argv) :
  36         SGCmdApplication("FGRadar", argc, argv, true)
  37     {
  38         checkDataDirectoryExists();
  39         init();
  40     }
  41
  42     FgradarApp::~FgradarApp()
  43     {
  44     }
  45
  46     void
  47     FgradarApp::init()
  48     {
  49         createSubsystems();
  50
  51         m_subsystem_mgr->init();
  52     }
  53
  54     void FgradarApp::createSubsystems()
  55     {
  56         /*m_subsystem_mgr->add("fgms-traffic", new FGMultiplayerTraffic,
  57           SGSubsystemMgr::GENERAL, 1.5);*/
  58         m_subsystem_mgr->add("nasal", new FGNasal,
  59                              SGSubsystemMgr::GENERAL, 0);
  60     }
  61
  62 } // namespace fgradar



The corresponding infrastructure helpers are generic, and not specific to "fgradar", i.e. could be reused for your needs - they don't even require OSG: https://gitorious.org/fgradar/fgradar?p ... d5;hb=HEAD
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: Vertical fgpanel

Postby dhudach » Wed Feb 26, 2020 6:19 pm

Thanks for the information. I'm in my 'winter break' now and will get back to the project at the beginning of May. And when I get the C++ code a bit more formalized, I will definitely make it available.

And I know exactly what you mean about projects where it's not so much new code, but ripping out unnecessary code. Writing the "Hello World" program can start from the ground up, or it can start from existing code and stripping it down to .... "Hello World!"

In order to get a lot of my stuff working (arduino, etc), I made reference to the generic protocol pages. The information was very helpful. And for something like that, once the concept is grasped, it's just a matter of running with it. I probably have looked at some of the other pages you listed as well.

To simply run the sim with some off the shelf rudder pedals, yoke and monitor is pretty straight forward. But the end game really is to have the cockpit scenery monitor only show scenery and possibly some of the aircraft window elements. The instrument panel on the main display is disabled and the instrument data is sent to the various monitors in the panel. And I think all of that is quite possible, I'm just not at that point yet.

But again, I digress. My first flight sim was ...... WAY back when on a Commodore 64 with the MS simulator. Yikes. But about 10 years ago or so I installed flightgear and used it a lot. But I only used it with CH yoke and pedals. But about a year ago I really thought that building a cockpit would be the way to go, complete with arduino and home built hardware. Most of spring and summer was spent learning and developing the arduino code to interact with flightgear. In addition, I built some C++ and python programs to sit between flightgear and arduino to only send data when the data changes.

In any event, once I get back into the project, I'll know much more what I'm going to need.

Thanks again. I appreciate it.
Flight Instruction Elevator Control: pull back = houses get smaller, push forward = houses get bigger.
dhudach
 
Posts: 118
Joined: Tue Apr 14, 2015 12:46 am

PreviousNext

Return to Interfacing

Who is online

Users browsing this forum: No registered users and 4 guests