Instructor Station

From FlightGear wiki
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.

Background

Cquote1.png

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)
Cquote2.png
Cquote1.png Frasca also has an instructor station,for training purposes in order to simulate engine failure and other, how does FG simulate this?
Cquote2.png


Cquote1.png 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.
— Raptor831 (Thu Dec 12). Virtual Panel/Control from Web Browser.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png 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.
— Hooray (Thu Jul 18). Re: A look at X-Plane.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— Djmax444 (Sat Dec 27). Instructor Station.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png What kind of instructor station are you thinking of?


Is it a general (ATC, IFR, VFR) procedure trainer or an aircraft specific systems trainer.?

Either way Flightgear can support you. The infrastructure is all there, but the aircraft specific stuff is very variable depending upon the authors.


— Alant (Sat Dec 27). Re: Instructor Station.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.

However, for people familiar with C++, Canvas + Nasal is probably a more flexible approach, because the C++ code can be easily extended where necessary.
Obviously, you should first of all be able to build FlightGear from source and be sufficiently familiar with git/gitorious.

Overall, an instructor console/station is a fairly popular request among professional users (or even just private pilost).
So it would be good to have some kind of prototype/proof-of-concept that could be extended over time.


— Hooray (Sat Dec 27). Re: Instructor Station.
(powered by Instant-Cquotes)
Cquote2.png

Use Cases

Cquote1.png 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.

  • It helps you learn the names of the fixes, the frequencies and codes of the navaids, et cetera.
  • It helps you discover little surprises such as stepdown fixes that require nasty steep descents.
  • It gives you a chance to practice the missed approach. My dictum is, if you're not ready for the miss, you're not ready for the approach.

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

  • unusual attitudes in real IMC
  • partial panel in real IMC
  • approaches to _below_ published minimums in low IMC
  • approaches with crosswinds, tailwinds, and/or turbulence
  • approaches in low visibility. A hood is OK for simulating a ceiling, but what if there is no ceiling, just bad haze?
  • et cetera.

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.

  • Practicing basic procedures
  • Continuing the scenario all the way to an off-airport landing

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.

  • Gear that "should" be down but isn't
  • Flaps that "should be down but aren't
  • Noticing the oil pressure gauge before it's too late.
  • Noticing the fuel gauge before it's too late.
  • et cetera

6) Multi-engine transition training.

7) Multi-engine emergency training

  • engine-out approaches
  • engine-out go-arounds

Cquote2.png

Problem

Cquote1.png

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)
Cquote2.png
Cquote1.png 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.
— Hooray (Mon Jul 07). Re: How can I retire from the forum?.
(powered by Instant-Cquotes)
Cquote2.png

Canvas

Cquote1.png you guys should be fine as long as you keep coding with a generic mindset, i.e. to support use-cases like:


  • multiple independent instances per instrument/layer
  • different instruments/aircraft (i.e. with different AP/RM or NAV/COM dependencies)
  • the GUI use-case (see map-canvas.xml in $FG_ROOT/gui/dialogs)
  • styling (custom colors, fonts, symbols etc)
  • different position sources (aircraftpos.controller/NDSourceDriver)


None of this is rocket science or even very difficult - these are fairly basic things, but most people fail to keep all of them in mind, so that they end up coming up with instruments that only support a single use-case unfortunately.

But as long as people keep following a handful of guidelines, we can even easily support new use-cases, including even a standalone FGCanvas mode, without it involving a ton of porting work. Likewise, GUI dialogs for configuring weather or showing a GUI console, would then automatically be able to also support holding patterns, vertical profiles (VSD) and weather overlays.


— Hooray (Mon Aug 11). Re: A330-200 with Canvas and other features.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.

People doing modern MFD-style avionics or any kind of mapping/charting displays should really have no reason NOT to use these frameworks - if something is missing, extending the framework is simple enough, and it means that your work is going to be used -and even maintained- by a number of contributors who have a track record doing similar stuff.


— Hooray (Mon Aug 11). Re: A330-200 with Canvas and other features.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png 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.
— Hooray (Mon Aug 11). Re: A330-200 with Canvas and other features.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.


On the MapStructure side, we'll probably want to add a few features:

  • adding different types of maps
  • supporting vertical projections
  • defining a clipped region for a "sub-screen"


We could then reuse the VSD code to also visualize approaches (e.g. ILS profile compliance etc) - for example, for some kind of instructor console


— Hooray (Thu Jul 17). Re: Cannot use .setText on SVG text element.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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:


my_canvas.set('enable-fullscreen',1);


This should help people like the ATC-FS guys who will need a fullscreen canvas window, and there are probably more applications, like an instructor console for example.


— Hooray (Tue Jul 16). Re: meta modes.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.


This kind of stuff has been discussed a number of times, and even Curt & Tim agreed (in the pre-canvas days) that this would be cool to support at some point: Canvas_Development#Placement.2FElement_for_Streaming:_Computer_Vision


— Hooray (Mon Jun 16). Re: Instruments for homecockpit panel..
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
Cquote2.png

Failure Management

Cquote1.png 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.
— galvedro (Tue Jan 21). Re: How does serviceable and failures work?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— Hooray (Wed Apr 30). Re: Engine wear.
(powered by Instant-Cquotes)
Cquote2.png