Virtual CoPilot

From FlightGear wiki
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.
Runway Overrun Prevention System
Started in 09/2014
Description Scripted CoPilot systems
Maintainer(s) ...
Contributor(s) onox [1] (since 09/2014),
Status Under active development as of 09/2014

Problem

Note
Cquote1.png Update: There are now at least 3 different solutions to implement a virtual copilot for FG: "copilot" forum search This is a link to the FlightGear forum.
— Hooray (Wed Jan 04). Re: The Virtual Co-pilot!!!!!.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png At the moment, there are about 3 different approaches to implement a "copilot" module for FlightGear - all of them being developed separately, as standalone programs talking to FG using socket connections.


While that is good from a design point of view, I think it is somewhat unfortunate because the people who work separately creating 3 different copilot solutions, could certainly work together and create a single one.

The real issue is that FG being cross platform software, it is generally understood to be a good idea that contributions to FG can also be used by all FG users, regardless of their platform/OS.

I haven't taken a look at FGCopilot yet, but that is also because I am on Linux and I assume that I cannot easily run your code?

redneck's project is more promising in this aspect because it is built using Java, which is multi-platform in general.

Also, redneck's project is reusing code that has been developed by FG core developers - so it is more efficient from a certain angle.


— Hooray (Thu Dec 08). Re: FGCopilot.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png personally I would suggest to look into working together with redneck to improve his project - there are obviously many things that could be implemented here. And redneck got a head start already. If you already know Delphi, understanding and writing Java should be straightforward actually. So if you have any ideas or feature requests, I am sure that redneck's project would be a solid foundation actually.


Honestly, I don't think we even need to keep this separate from FG - anybody doing projects like these will inevitably need to deal with the FG property tree, which is usually done using a socket connection. This is more complicated than it needs to be. If you already know a programming language, learning Nasal is actually EASY - and Nasal has native support for dealing with the FG property tree and its API.

Bottom line being, 99% of the work you are doing could be done more easily by switching to Nasal instead. This would also have the added advantage of Nasal code being automatically cross-platform, too. Once people switch to using Nasal, they also ensure that ALL FG users can easily make use of their contributions.


— Hooray (Thu Dec 08). Re: FGCopilot.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Obviously, there are some things that are easy in a separate language/toolkit, which are more complicated or next to impossible from Nasal space, but usually that would only require modifying or adding 2-3 new Nasal extension functions, which would also be useful for all other Nasal scripts.


Seriously, even redneck mentioned a while ago that Nasal should be seriously considered here, especially because the telnet/props route has been shown to become too slow pretty soon


— Hooray (Thu Dec 08). Re: FGCopilot.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I am absolutely convinced that these autopilot/copilot tools are a great idea for FG, but I also believe anybody not coding this directly IN FlightGear by using Nasal, is making it more complicated than necessary. So, I will try to support anybody who is actually looking into porting this over to "native FlightGear space" by reimplemting such efforts in Nasal space instead - adding a bunch of extension functions to enrich the API is easy and well documented actually. Anybody knowing C++ (or Java for that matter), should be able to understand what's involved: Howto:Extending_Nasal



Finally, it is usually a good idea to add announcements to the FlightGear newsletter (created and maintained using the wiki)- you can even create a new wiki article introducing your project, and linking to it from the newsletter. Let us know if you need any help contributing to the newsletter: Next_newsletter


— Hooray (Thu Dec 08). Re: FGCopilot.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Hooray is onto something here really. I have noticed on several aircraft some autopilot Nasal scripts that are supposed to takeoff and land on their own, however no matter what I try these scripts fail to run, these are found on the A-10, SU-37, YF-23, B-2 and a couple others I believe. So the code is there, we just need to get it to run.


This really dives into the realm of UAV work, something I have been working on for about a year myself with the X-47B. I think maybe we should make a new wiki page devoted to UAV's and the like since there are many of us that like these kind of aircraft and systems. Thoughts?


— pygmyskunk (Sat Jan 07). Re: FGCopilot.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png One of the problems is going to be that such a feature is pretty aircraft specific. That's probably part of the reason why people keep coming up with their own implementations. To get something like this started, you'd first of all need to start VERY simple, i.e. by making this work with the simplest aircraft you can find (such as the ufo) and then incrementally start making it more configurable, so that support for more complex aircraft can be added. This could be accomplished by using aircraft specific setup files that could be declared in XML space and loaded by Nasal scripts.


So that aircraft developers could specialize the default setup, specifically for a certain aircraft.

The wiki article you mentioned would probably be a good thing to collect all ideas, the step would probably be collecting all existing steps and seeing if/how they could be generalized and integrated to form a single script.


— Hooray (Sat Jan 07). Re: FGCopilot.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png There's actually quite some interest in UAV stuff recently. And in fact, Curt recently provided a fully working uav demo by scripting the f14b to do carrier ops too. Unfortunately, the source code was obfuscated - so it would be of little use here, but it goes to show that it's definitely possible to come up with something like this.


It's probably just a matter of getting people to collaborate, rather than starting scripts from scratch ;-)


— Hooray (Sat Jan 07). Re: FGCopilot.
(powered by Instant-Cquotes)
Cquote2.png

Background

Cquote1.png FGCopilot makes interaction with the plane for the copilot possible in probably any aircraft. Copilot can:
  • retract and extend flaps
  • arm/retract spoilers
  • retract/extend gear
  • put throttle on IDLE
  • toggle parking brakes
  • toggle reversers
  • toggle landing lights

— SP-WKA (Mon Nov 28). FGCopilot.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I like the idea but I think there needs to be some other way of merging the idea into FlightGear itself. Im on linux so I dont believe I can run the code you've supplied. I think if you hacked this into FG itself, perhaps as a property 'editor' instead of just a property browser, that would be a better way to go. I would imagine with some work this could be added as another protocol to link 2 players together.
— dr1 (Fri Dec 02). Re: FGCopilot.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png state machines would be helpful here, IMO, unless you just need something basic. Offtopic, but I've thought a little bit about this and I think a custom syntax (read: DSL) would be helpful... [/egoist] (oh wait, I still need to get it off the ground)

But I do not like the idea of using XML at all as I think you (Hooray) might've suggested before, my limit of XML tolerance is FDMs and PropertyList, not scripts, as those tags get comber some. Maybe having something in a Nasal object would be possible as well, something like a pseudo-linked list with loops would not be hard.


— Philosopher (Sat Jan 19). Re: Copilot announcements: Nasal don't works!.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Zakalawe has recently started adding state machine support to SimGear: SimGear commit 22ea8ebe258da45df9fc2b77904c2dcf79cd0f57

It will probably take a while until this becomes available to Nasal scripts, but Tom has added a module called "cppbind" to SimGear to more easily expose C++ stuff to Nasal scripts (and vice versa).

None of this is currently documented, but it may still be the best option for more complex needs eventually.
At the moment, this seems to be specific to the AP system though.


— Hooray (Sat Jan 26). Re: Copilot announcements: Nasal don't works!.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Basically, PropertyList XML files already support stateful expressions using the SGCondition syntax. While that's pretty verbose, it's still pretty straightforward.

I think the tutorial system uses them, too (? - havent' checked)
Arguably, XML code is easier to use and edit for non-programmers than scripting "code".

Anyway, the property conditions stuff is also accessible from Nasal.
Regarding state machines and DSLs, there's tons of stuff available actually. But we would obviously need to come up with something that can be properly integrate in FG.

Now, regarding the OPs questions, I'd suggest to stop using the current approach and instead check out the tutorial system - it was written with such use-cases in mind, and it should be much more straightforward to develop a corresponding tutorial and extend/improve the tutorial system once the need arises.

At the end of the day, it's all still XML, properties and some Nasal "glue" code: Tutorials
People who are able to write simple Nasal scripts on their own should actually find it pretty straightforward to work with the tutorial system and extend it as required.


— Hooray (Sat Jan 19). Re: Copilot announcements: Nasal don't works!.
(powered by Instant-Cquotes)
Cquote2.png


Objective

Runway Overrun Protection System

Cquote1.png is it possible to add one interesting system to our lovely FG aircarft? The system works quite similar to the GPWS,with the difference that is counting the runway length on landing,and it call-out the reaming legth of the rw,like 400m remaining ,300m remaining and so on. In this video ,you hear it,it's quite interesting.
— FGRS (Thu Nov 07). Runway overrun protection system.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png @onox: if you've got any updated code that you'd like to share, I suggest to post it on the wiki so that we can help peer-review and extend the code, so that this could become the foundation for a little tutorial for people wanting to do similar stuff - alternatively, we could also add this to the upcoming newsletter. Let me know if you should have any Nasal related questions or if you need help using the wiki accordingly.
— Hooray (Sun Aug 17). Re: Runway overrun protection system.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The code that I have shown in a previous post should be part of a tutorial, but the actual code (TakeoffRunwayAnnounceClass and LandingRunwayAnnounceClass) should eventually live in Nasal/runway_announcer.nas or something in the giant monolithic beast called fgdata.
— onox (Mon Aug 18). Re: Runway overrun protection system.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Some kind of separate Nasal submodule would seem to make - for details, see: Creating_new_Nasal_scripts#Nasal_sub_modules
— Hooray (Mon Aug 18). Re: Runway overrun protection system.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png It uses math, geo, and apt, so I guess it should live in Nasal/runway/runway_announcer.nas then.
— onox (Mon Aug 18). Re: Runway overrun protection system.
(powered by Instant-Cquotes)
Cquote2.png

FREDA Announcements

Cquote1.png Who would be interested in contributing to/helping to test a new feature for FG? The Virtual Co-pilot!!


The Virtual Co-Pilot would assist with pre-flight route-planning, checklists and change nav and comms frequencies en-route as well as keep the captain awake on long -haul flights with witty banter.
Right now this is only an idea and I'm looking for folk to do the actual work, suggest an initial interface and further features.

For instance, on GA aircraft, Virtual Co-Pilot would prompt you to do FREDA checks every 15 mins.

Work is in the pipeline which should allow expansion/integration of the Route Manager and Interactive Map. Lets be ready to take advantage of these new features.

Anyway, over to the FG community for ideas......


— willie (Mon Sep 20). The Virtual Co-pilot!!!!!.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png That should actually be pretty possible to do, with just a piece of Nasal code.

I don't think this would need to be very complicated. If you have previously done some Nasal programming, that's fairly easy to do.

One could even think about letting the "copilot" script do checks like pre-taxi, pre-takeoff, approach etc.

It would just be a matter of writing the corresponding "checklists" in the property tree XML format (for example for V speeds), then Nasal could do the whole check upon firing a listener - and even use a sound configuration file saying "CHECKED, CLEAR ..." (or use the festival text to speech facility).


— Hooray (Mon Sep 20). Re: The Virtual Co-pilot!!!!!.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I would suggest to write all aircraft specific checks to an XML file that can be customized for each aircraft, then a piece of Nasal code could load the file into the property tree and do the corresponding checks (or issue a reminder)
— Hooray (Mon Sep 20). Re: The Virtual Co-pilot!!!!!.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png I just put together a very simple first version of a "FREDA" copilot script for use in FlightGear, you may want to play with it.

It's not really complicated at all, if you know some JavaScript it will be really easy to understand how the whole thing works.

All of this is basically written in about 20 lines of Nasal code, so it's compact too.
You will need to save the file as "copilot.nas" in $FG_ROOT/Nasal

# copilot.nas (to be placed in $FG_ROOT/Nasal)

##
# implements a very simple prototype of a timer based virtual 'copilot' script in Nasal issuing "FREDA" reminders to the console, screen and to the festival TTS
# see: {{forum url|t=9556}}
# 
# for details on FREDA please see: 
#   http://www.worldlingo.com/ma/enwiki/en/Freda
#   http://www.squidoo.com/learning-to-fly-freda-pats-the-cat
#

# TODO: these settings should probably become property based, so that they can be easily configured using a GUI dialog 
# configuration settings (0: disabled, 1: enabled for boolean settings)
var config = {enable_freda:1, print_to_console:1, print_to_screen:1, use_festival:0, reminder_delay_mins:1, gui_message_delay_secs:5 };

# vector with FREDA messages
var FREDA = [ 
        "FREDA (fuel):ensure fuel is sufficient and being consumed at the expected rate. 'Lean out' the carburettor  to the most economical setting. Set the fuel selector switch to take fuel from one or other of the wing tanks, or both, depending on fuel remaining and aircraft balance limits",
        "FREDA (radio):ensure the radio is tuned to the correct frequency for the nearest airfield. Listen for announcements. Communicate with airfield when entering or leaving restricted airspace",
        "FREDA (engine):check oil temperature and pressure, and other engine indicators.",
        "FREDA (DI):check directional indicators (compass, gyroscope, artificial horizon, etc.) to ensure correct heading.",
        "FREDA (altimeter):check altimeter shows correct altitude. Gain or lose height if necessary. Adjust altimeter to the correct atmospheric pressure setting for the local area", 
];

var minutes_to_seconds=60;
var delay_secs = config.reminder_delay_mins*minutes_to_seconds;


var remind = func(msg) {
    if (config.print_to_console) print(msg);
        if (config.print_to_screen)  screen.log.write(msg); #gui.popupTip(msg, config.gui_message_delay_secs);
    if (config.use_festival)     setprop("/sim/sound/speech", msg);
};

var print_freda_reminders = func {
  foreach (var msg; FREDA )
    remind(msg);

   settimer(print_freda_reminders, delay_secs);
};

var init_copilot = func {
  if (!config.enable_freda) return; 
  if (config.use_festival and getprop("/sim/sound/voices/enabled")!=1) print("Warning: /sim/sound/voices/enabled is 0");

  settimer(print_freda_reminders, delay_secs);
  print('Copilot script initialized and running, next reminder due in ',config.reminder_delay_mins, ' minutes' );
};

# register the callback for running the init function
_setlistener("/sim/signals/nasal-dir-initialized", init_copilot);

— Hooray (Mon Sep 20). Re: The Virtual Co-pilot!!!!!.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png If you want to make changes to it, you can directly fork the script here: http://codepad.org/sSM4Guru


There are many possibilities for really improving this significantly, just starting to use XML based files for really doing whole checks would be really powerful and useful. And making the whole script configurable using a gui dialog would also be a good idea.

All of this is fairly easy to do, what I have provided so far is just meant to be a "proof of concept" - and maybe it's useful enough to be used as the foundation for new features. Let me know what you think.

It would probably also be a good idea to integrate this with:
index.php/Howto:_Calculate_V-speeds
index.php/Howto:_Implement_copilot_announcements


— Hooray (Mon Sep 20). Re: The Virtual Co-pilot!!!!!.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png this was really just meant to get you started ... it's obviously a very simple script. But there are many features that could be added to such a "virtual copilot" scripts. Many of which could even already be implemented without requiring any additions to the C++ code.


As a first step, I would suggest to integrate this with the V speeds callouts tutorials (see the two links I posted), as a next step one could then support the use of XML files for doing aircraft specific checks or copilot activities. Personally, I would suggest to base the whole thing initially on the C172p, because it's well developed and pretty well featured, too.

I think there is indeed lots of potential for such an addon!


— Hooray (Wed Sep 22). Re: The Virtual Co-pilot!!!!!.
(powered by Instant-Cquotes)
Cquote2.png

Porting FGFSCoPilot to Nasal

Cquote1.png I applaud you for actually considering the port now! I'd suggest to use a Nasal sub module, so that you can easily structure your code and use separate Nasal source files for the main features: Nasal_scripting_language#Nasal_sub_modules
— Hooray (Wed Mar 21). Re: Porting FGFSCopilot over to XML/Nasal.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I've already started work on the Nasal portion. That was before I even read your post. I'd say I got about an eighth done right now. I've been having a lack of focus today.... Otherwise, I probably would have had the whole thing done in the few hours I spent on it. It's got several functions - mainly for all the different phases of flight. I think I'll just finish what I have for now, and test it. At least I know what's suppose to go where in the dialog.
— redneck (Wed Mar 21). Re: Porting FGFSCopilot over to XML/Nasal.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The whole idea of "sub modules" is just to allow code to be loaded "on demand", so that users can decide if they want to load certain code (think local weather) or not - in part, this is also meant to allow users to allow users to improve frame rate, i.e. by reducing the pressure on the Nasal garbage collector. This is because all *.nas files in $FG_ROOT/Nasal will be loaded by default, including many timers and listeners. The added advantage of sub modules is that your code can be split up into several different files, which will be loaded in the same namespace automatically.
— Hooray (Thu Mar 22). Re: Porting FGFSCopilot over to XML/Nasal.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The broader functionality of the V.copilot is interesting and one seeks to contribute towards an FGFS generic design. Optimistically (or me just being naive), any teknikal and syntax problem is relatively easy to resolve; when the underlying design issues are addressed. One can always substitute alternative tekniq and code if the current one proves to be too trouble-some.
— awexome (Mon Mar 26). Re: Porting FGFSCopilot over to XML/Nasal.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png However, there is need for a design focus, and a few related questions may help (me, for one  :)  :
  • For this V.copilot, Is there a particular purpose for having some of the various info on the gui (e.g., aircraft type, fuel, cruise alt. and airport info)? Such info could be reliably accessed from the prop. tree and route-manager; and in doing so, one minimises data entry errors and data duplication.
  • How would the various nav. selections be useful for the V.copilot operation? Any relation to course-tracking, landing and radio nav. setup?
  • What particular functions (e.g., FREDA checks, etc.) are being performed by this V.copilot implementation?
  • Are the autopilot locks (see,in your 'nasal' code) applicable to other AC types? (I will be posting a generic FGFS autopilot helper module that is relevant, and may be useful, in this context.

On a related issue, I have made the V.copilot setup (base design from the 787-8 menu) accessible via the CDU


— awexome (Mon Mar 26). Re: Porting FGFSCopilot over to XML/Nasal.
(powered by Instant-Cquotes)
Cquote2.png