Virtual CoPilot
| This article is a stub. You can help the wiki by expanding it. |
| 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
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
Background
|
|
FGCopilot makes interaction with the plane for the copilot possible in probably any aircraft. Copilot can:
|
|
|
|
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.
|
|
|
|
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) |
|
|
|
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). |
|
|
|
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) |
|
Objective
Runway Overrun Protection System
|
|
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.
|
|
|
|
@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.
|
|
|
|
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.
|
|
|
|
Some kind of separate Nasal submodule would seem to make - for details, see: Creating_new_Nasal_scripts#Nasal_sub_modules
|
|
|
|
It uses math, geo, and apt, so I guess it should live in Nasal/runway/runway_announcer.nas then.
|
|
FREDA Announcements
|
|
Who would be interested in contributing to/helping to test a new feature for FG? The Virtual Co-pilot!!
|
|
|
|
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. |
|
|
|
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)
|
|
|
|
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. # 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); |
|
|
|
If you want to make changes to it, you can directly fork the script here: http://codepad.org/sSM4Guru
|
|
|
|
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.
|
|
Porting FGFSCoPilot to Nasal
|
|
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
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
However, there is need for a design focus, and a few related questions may help (me, for one :) :
On a related issue, I have made the V.copilot setup (base design from the 787-8 menu) accessible via the CDU |
|