Instructor Station
| This article is a stub. You can help the wiki by expanding it. |
Background
|
A good instructor station is another items that is missing from the open-source world. — Curtis Olson ( Mon, 05 Oct 2009 11:36:03 -0700). October $250 Flight Gear Developers.
(powered by Instant-Cquotes) |
|
|
|
Frasca also has an instructor station,for training purposes in order to simulate engine failure and other, how does FG simulate this?
|
|
|
|
What I am after is basically a virtual panel that could receive data to display (gauges, lights, switch positions) and send data to the sim (mostly switches, dials, etc and not control inputs). The catch is that I wanted this in a web browser, which my laptop can actually run.
|
|
|
|
there are tons of options and features in XP/FSX that we simply don't have, and probably won't have very soon, including an instructor console and flight path evaluation - however, these things are obviously crucial for people using a simulator for proficiency training.
|
|
|
|
I was thinking of making a instructor station for Flightgear. The only problem is i don't know how to get buttons(from Microsoft Forms) to interface with Flightgear. I am using Microsoft Visual Studio C++ 2010.
|
|
|
|
What kind of instructor station are you thinking of?
|
|
|
|
Fortunately, these days, you don't need to use any external tools to create an instructor console - you could easily create one using HTTP + JavaScript using the built-in httpd server. That will be the easiest option for people less familiar with coding, i.e. basic JavaScript + HTML should suffice. |
|
Use Cases
|
|
In case there's anybody who doesn't already know, here are some of the things that look doable to me:
1) Instrument procedure familiarization. Suppose you (the pilot) are flying into an unfamiliar field for the first time. It is a big help to run through the instrument approach on the simulator.
For that matter, flying into JFK for the first time, you could get seriously lost on the taxiways. Real pilots are willing to practice taxiing. Gamers not so much. 2) Instrument emergency training. There are some things that instructors don't like to practice in the real aircraft, such as
These things are much more safely done in the simulator. Also, a subtly failed instrument is incomparably more dangerous than one that is merely covered with a suction cup. There are lots of pilots out there who have never seen this, and have no idea how bad it is. 3) VFR emergency training.
4) Complex aircraft transition training. Gear handle, prop handle, cowl flaps, speed brakes, et cetera. I'd much rather have the low-time pilot abuse such things in the simulator than in the real airplane. 5) Systems failures.
6) Multi-engine transition training. 7) Multi-engine emergency training
— John Denker (2009-01-18). [Flightgear-devel] real pilot training using FlightGear ... or not.
(powered by Instant-Cquotes) |
|
Problem
|
|
Having the training session as a separate network app instead of being integrated into FG is going to put off a lot of less technically minded people. It requires that the user first install Python + pyao + pyogg + pyvorvis. Then they have to install the training packages and try to start FG together with the simulator. I'd much rather code it in Nasal have it part of the FG package itself or as an addon that can be unzipped into the FG tree and run as is. — Paul Surgeon (Thu, 05 Jan 2006 10:46:41 -0800). Lessons in FlightGear.
(powered by Instant-Cquotes) |
|
|
|
I don't quite see how we could come up with different versions, binaries and packages of FG easily - but we could certainly prepare the main binary to become increasingly configurable, so that it can be used for such purposes - it would even be possible to use built-in FG dialogs in an external window, running in a standalone process - e.g. for an instructor console, but also for a Canvas-driven TerraGear GUI.
|
|
Canvas
|
|
you guys should be fine as long as you keep coding with a generic mindset, i.e. to support use-cases like:
|
|
|
|
you really only need to know a subset of Nasal to apply these guidelines, and it will get you pretty far. The main feat of the ND framework, and even MapStructure, is not so much its design (sorry, P. :mrgreen: ) - which isn't particularly "standard" or even elegant - the main accomplishment is its loose coupling, i.e. the decoupled nature of these modules makes it possible for people -who are interested in very different aircraft, avionics and use-cases, to still collaborate effectively, simply because things are so flexible. So these two "frameworks" are primarily collaboration enablers, because people that would normally not collaborate can all of a sudden easily work on a common code-base pretty easily. |
|
|
|
The whole MVC separation established by the ND/MS frameworks allows people to collaborate despite possibly working with very different aircraft and instruments/avionics, which even includes people who don't do any aircraft/instrument development at all, but "merely" GUI dialogs like an instructor console for example.
|
|
|
|
we should be able to reuse the same routines for different projections/symbol files, i.e. the data will be identical and probably even be shared. Philosopher once mentioned that he wanted to support reusing controllers for different layers. So it should be possible to extend the framework accordingly.
|
|
|
|
Referring to the last PFD/FGCanvas discussions, I'd also suggest to support an optional "enable-fullscreen" attribute, which would be useful for fullscreen apps obviously - either as part of the Nasal canvas API tracking /sim/startup/xsize and ysize via listeners, or by adding it to the C++ code, so that we just need to:
|
|
|
|
Being able to stream Canvas images/video to an external browser/viewer (via a worker thread) would also allow us to support a variety of other interesting use-cases, such as UAV stuff, OpenCV post-processing etc. The only thing that's missing to pull this off is a new placement type that exposes a canvas as either an osg::Image buffer that is serialized to a browser-format like PNG, or to some video stream. At that point, a browser could -in theory- even render live FG camera views streamed via UDP to implement a browser-based instructor console that can view individual Canvas MFDs/instruments, but even scenery views.
|
|
|
|
a few months ago we had someone working on exposing FlightGear's view manager to Canvas, which would basically render views to a CanvasImage element (raster image) and update the whole thing dynamically - something like that would only be feasible to support via mongoose/browser by serving some kind of streamed live image, and given the existing screen shot serving code (jpg-httpd) we seem to be halfway there, which would also mean that an instructor console implemented on top of JavaScript/mongoose could show FlightGear scenery streamed via http push.
— Hooray (Mon Sep 22). Re: FGWebPanel aka FGPanel 2.0 or: FGPanel goes html.
(powered by Instant-Cquotes) |
|
Failure Management
|
|
As I see it, the failure system, as provided by the sim, serves as a central place for controling the occurrence of random events. While it is certainly desirable to give it flexibility, it is also important to keep it simple to use. For example, a by the book use case for the failure control interface is an instructor console. As an instructor, what you want is (I guess) a comprehensive list of possible failures to force, together with a simple interface for controling which one to fire and when. You don't really want the entire aircraft to go nuts when you only want the flaps to stop responding.
|
|
|
|
this can be hooked up to different front-ends, including a telnet/web-based front-end (e.g. instructor console), or even just an integrated Canvas/GUI dialog.
|
|