rate my landings

[pommesschranke]

feature wish:

after each landing flightgear should display vertical and horizontal speed
at the moment of touchdown
so that it's easier for me to judge it it was a good or not so good landing.

maybe such a nasal script exist already ?

[Hooray]

A basic approach evaluation can be quickly coded using Nasal + the canvas system, basically you would need to:

• register a timer and sample altitude vs. speed
• put everything into a vector via append()
• and then display a canvas-driven graph

a better option would be hooking into the replay/flight recorder systems, because these already record all required data - but currently they are not exposed to Nasal yet.

See the following links for examples, code and related discussions:

Subject: kuifje09's FGPlot Development

To get you started, I have added a little tutorial and a screen shot, demonstrating that it's definitely possible to add a Nasal/Canvas-driven "fgplot" application to FlightGear, using just a simple XML dialog (because you're using FG 2.10, that doesn't yet have the more recent features):

http://wiki.flightgear.org/Howto:Adding ... log#FGPlot


It's just proof of concept, and pretty simple for now - but should get you going pretty quickly.

Subject: [closed] Flightgear plotter updated.

That's definitely a good idea, accessing the replay/flight recorder buffers via a dedicated Nasal/property tree interface would be pretty cool, not just for showing historical path data, but also for computing a flight profile, or even for doing a full flight evaluation - which could also be done via Nasal/Canvas then, we just need Nasal hooks (i.e. ghosts) to access the replay/flight recorder subsystem and get data from it.

I've been talking to ThorstenB about exposing the system to Nasal a while ago, and when Tom and I played around with graph plotting, we also figured that it would be kinda cool to access such info from Nasal.

The combination of these features (replay/flight recorder access + Nasal + Canvas), would also make it possible to create a full flight instructor console. The original graph-plotting experiments were pretty encouraging:

And 2D plotting is another long-standing feature request, originally brought up by Curt: http://www.mail-archive.com/flightgear- ... 03651.html

But, I was just thinking today that it might be cool to have a built
in grapher for simple / quick graphing needs.

With the property system it would be trivial to pick an arbitrary
property from the property tree and graph it over time -- superimposed
on top of everything else.

With the Canvas, it has now become trivial to create such graphs, but we still need to have Nasal-space access to the corresponding subsystems and data, i.e. the replay/flight recorder system.

So this could be added to FGPlot fairly easily:
http://wiki.flightgear.org/FGPlot

[Johan G]

...after each landing flightgear should display vertical and horizontal speed
at the moment of touchdown...

That is certainly doable.

...these already record all required data - but currently they are not exposed to Nasal yet.

I'm not sure I follow you, since TAS and VS for sure is available in the property tree.

I have not done nearly any nasal programming myself, but I guess a simple way to start would be to make a nasal module that would register a listener that upon first weight on wheels (WoW) would store the momentary values of true airspeed (TAS) and verical speed (VS) and print them on a pop-up message after a timer has gone for say 10 seconds (so the pop-up does not interfere too much with your landing).

[Hooray]

...these already record all required data - but currently they are not exposed to Nasal yet.

I'm not sure I follow you, since TAS and VS for sure is available in the property tree.

You didn't follow me: it is simply redudant to have a bunch of related subsystems/scripts sample the same properties to record them - instead, there sould be a single location where such stuff is kept, which should be exposed to scripting space. It is not about properties being in the tree, they are all there, it's about them having to be recorded for any type of evaulation.

[Johan G]

It is not about properties being in the tree, they are all there, it's about them having to be recorded for any type of evaulation.

a better option would be hooking into the replay/flight recorder systems, because these already record all required data - but currently they are not exposed to Nasal yet.

Aha, so in principle the 10 sec old data should be easy to sample, provided that the replay/flight recorder data would have been exposed to nasal. Now I get you.