Board index FlightGear Development Aircraft Autopilot and route manager

Actual programming language for autopilot implementation?

Designing a stable autopilot is one of the hardest things. Need help?

Actual programming language for autopilot implementation?

Postby flameout » Thu Jul 26, 2012 2:26 am

Are there any scripting languages I could use to develop an autopilot for a JSBSim-based FG aircraft? I'd use Nasal, but I think it runs at the frame rate, not at the simulation rate. Are FG's autopilot and JSBSim's built-in control features my only options?

I think this is the case, but I haven't been around for a while and this may have changed in the meantime.

Thank you for any help.
Also known as Johnathan Van Why.
flameout
 
Posts: 443
Joined: Thu Dec 25, 2008 5:43 am
Location: Oregon, USA
Callsign: MSJF
Version: GIT
OS: Gentoo

Re: Actual programming language for autopilot implementation

Postby Hooray » Thu Jul 26, 2012 4:20 am

Hi!

You could use Nasal's worker threads to run some of your code outside the main loop, i.e. decoupled from the frame rate - you would then merely need to synchronize your computations with the main loop at frame rate, that should give you several 100 hertz for your computations.

Another option would be an arbitrary external scripting/programming language, which you interface to FlightGear via the property tree - so that you could implement your autopilot separately, as a separate process - and just process the inputs/outputs created at FG frame rate. So you could use Python, Fortran or whatever else is well-suited for your problem domain. You could also use something like MATLAB. For example, redneck used Java and the existing Java/Telnet bindings to implement his copilot project in this fashion.

When using Nasal, you'll need to make sure not to call any FG extension functions in your worker threads, but number crunching will be just fine - if you need to call extension functions (i.e. to access the property tree), you'll want to design your code such that these things are handled in the Nasal main thread, i.e. as part of the FG main loop.

Another option I am currently exploring is using OpenCL in FlightGear: viewtopic.php?f=38&t=13780
Also see: http://wiki.flightgear.org/Howto:Using_ ... FlightGear

OpenCL would be well suited for heavy computations, and the OpenCL kernels can be directly and easily run on other CPU cores, but also on your GPU.
The way this currently works here, is by adding a handful of Nasal bindings to access the OpenCL APIs (see the wiki), so that OpenCL kernels can be loaded and run from Nasal.

However, OpenCL is obviously a different programming language (ISO C based, similar to GLSL) heavily focused on massive parallelism - so the programming paradigm is definitely different. But anybody already knowing C, C++, Java or even JavaScript or Nasal should be able to pick up the fundamentals quickly, and there are tons of tutorials out there.

Also, you could in fact develop your standalone autopilot using OpenCL, which would have the advantage that there's no rebuilding of C++ code involved once your host application is working, all the interesting stuff happens inside these opencl kernels, which are dynamically recompiled using your OpenCL runtime. Obviously, you would also need a way to access the FlightGear property tree, i.e. via sockets.

Also, once the OpenCL bindings are fully accessible via Nasal, it should definitely be possible to directly run your OpenCL code in FlightGear.
If you'd like to play around with it a bit, here' something to get you started, it's a "hello world" example that I adapted for some separate OpenCL experiments yesterday:

Hooray wrote:Download: http://speedy.sh/HevFV/clsample.zip
1) extract and cd into the "clsample" directory
2) run make
3) run clsample
4) edit the file kernel.cl to change the kernel
5) use --gpu to enable GPU mode (instead of CPU (default))
6) use --kernel filename to run another kernel


It shouldn't take much longer than 2-3 hours to extend this source code to interface it to the FlightGear property tree, so that you can read in the FDM properties and update the output/control properties at frame rate via a socket connection. There's lots of code that can be directly adapted in a copy/paste fashion here (net_fdm, net_controls).

This would give you a separate C++ program that connects to a running FlightGear process and which can be used to implement an autopilot in OpenCL, without needing to rebuild any C++ code afterwards (i.e. like a scripting language, because the CL code is compiled by the runtime driver transparently in the background), it will just involve editing the OpenCL code once the FDM and /control properties are synchronized at frame rate with FG.

And like I said, your OpenCL kernel could later on also be run as part of FlightGear.

Keep in mind that you'll need a working OpenCL environment/runtime, i.e. OpenCL drivers for your hardware (CPU/GPU).
Any NVIDIA CUDA GPU automatically supports OpenCL, too. For other manufacturers, check their website.
And even if your GPU doesn't support OpenCL, you can still install the AMD drivers (APP SDK), which will run all OpenCL computations on your multicore CPUs instead.

Let me know if you are interested in this, as I can share some more code with you - if you are interested in teaming up, you could in fact also get involved in adding a handful of OpenCL/Nasal bindings to FlightGear (which really is trivial to do if you already know C/C++) - the process is documented here: http://wiki.flightgear.org/Howto:Extend_Nasal

It just involves creating wrappers for the handful of OpenCL C++ classes, and making them accessible via Nasal:

http://www.khronos.org/registry/cl/api/1.2/cl.hpp
http://www.khronos.org/registry/cl/spec ... us-1.1.pdf

Obviously, you would need to be able to build FlightGear from source for this.
Also, compared to the standalone OpenCL host that needs to synchronize properties with FG via sockets, this approach would have the advantage that all of the property tree would be automatically available to your kernels via Nasal's getprop/setprop APIs.

Overall, if you are interested in doing really massive computations in FlightGear, i.e. for AI or CFD simulation, OpenCL would definitely be the way to go - and completing the OpenCL/Nasal interface can be quickly done within 2-3 days.

If you are just interested in getting started quickly, I would personally use Nasal and try to come up with a design that's using worker thread for computations, which synchronizes the autopilot inputs/outputs at frame rate.

Bottom line:
  • Nasal approach: fast & simple to get started, doesn't require any C++ coding or property interfacing via sockets because you have setprop/getprop - however, it does require some knowledge on multithreaded programming, and how to avoid deadlocks/crashes, especially given that the APIs are not threadsafe currently.
  • Separate program interfaced via property tree: Depends on your programming knowledge, if you know some language really well, this could get you started really quickly, but you'd still need to interface your external program to FlightGear and synchronize your inputs/outputs, i.e. not as simple as "getprop/setprop" in Nasal :-)
  • Standalone OpenCL kernel interfaced via property tree: OpenCL is a different programming language, but it offers massive parallelism and lots of speed for heavy computations, it would be easy to learn the basics quickly, while you won't need to constantly rebuild C++ code, you will need to synchronize your FDM/AP inputs and outputs with the FG process, that does involve some network/socket programming - but you could adapt an existing host program, like the one linked above.
  • OpenCL kernels run via FG: This would require some more extension functions to be added to the Nasal interface, so that kernels can be better loaded and run from Nasal - if you already know C++, that would be the most flexible and most promising long-term option, because it will also be useful for future, even unrelated projects, also there won't be any need to synchronize properties with an external process, because setprop/getprop can simply be used to access the FG property tree. Also, I will actually fully support you, because that's what I am currently working on, i.e. I will explain how to expose to new APIs to Nasal and how to use OpenCL. :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11923
Joined: Tue Mar 25, 2008 8:40 am

Re: Actual programming language for autopilot implementation

Postby flameout » Fri Jul 27, 2012 1:01 pm

Hooray,

I apologize for the slow response -- I didn't realize that I wasn't subscribed to this thread.

I'm not looking at doing particularly intensive computations, so I'm not sure that OpenCL is what I'm looking for. However, I've wanted to learn about OpenCL anyway, so I'll definitely take a look.

The thing I'm most concerned with is the ability to run at the same rate as the simulation, instead of the frame rate. It doesn't appear as if Nasal or external software can do this, as although they can run faster, their interface with the main code is still limited to the frame rate.

Perhaps we can set up OpenCL so that it can run at the simulation rate? I could see someone working on some sort of CFD-based FDM for FlightGear using OpenCL anyway...

Thank you for responding!
Also known as Johnathan Van Why.
flameout
 
Posts: 443
Joined: Thu Dec 25, 2008 5:43 am
Location: Oregon, USA
Callsign: MSJF
Version: GIT
OS: Gentoo

Re: Actual programming language for autopilot implementation

Postby Hooray » Fri Jul 27, 2012 1:17 pm

That would require interleaving the execution of your code with the FDM, that is for example done with the autopilot system and some instruments.

I am not aware of any way to accomplish this without resorting to C++ coding, i.e. one would need to modify the source code and rebuild FlightGear.
If that's not a problem, then one could just as well run another Nasal interpreter interleaved with the FDM/AP subsystems. While that would be fairly "easy", it would not be too elegant.

For some background information, see the comments here: https://code.google.com/p/flightgear-bu ... id=421#c11

Personally, I don't really like the limitation of Nasal being only able to run at frame rate. So, I think we should also try to interleave the execution of the Nasal subsystem with the FDM.

I am not sure if changing that would be complicated or not, but I think it should be doable to run the FGNasalSys class as part of the same SGSubsystemMgr group that is used to interleave the FDM, the AP and the instrumentation execution.


Hopefully, some of the FDM/AP experts (Torsten, ThorstenB, AndersG?) can comment on this.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11923
Joined: Tue Mar 25, 2008 8:40 am

Re: Actual programming language for autopilot implementation

Postby flameout » Wed Aug 08, 2012 3:39 am

You mentioned worker threads earlier... perhaps I could interleave one or more threads' execution with the FDM/AP subsystems (instead of a completely different interpreter). Whether I need a new interpreter or not, I'll definitely aim for integrating Nasal with FG's simulation loop.

I work at a lab that does realtime software, and the realtime/non-realtime division is very similar to FG's simulation-rate and frame-rate division.

Thank you for your help!
Also known as Johnathan Van Why.
flameout
 
Posts: 443
Joined: Thu Dec 25, 2008 5:43 am
Location: Oregon, USA
Callsign: MSJF
Version: GIT
OS: Gentoo

Re: Actual programming language for autopilot implementation

Postby Hooray » Wed Aug 08, 2012 9:33 am

if you have a powerful computer, then looking at the previous discussion should provide all the pointers to run the Nasal subsystem interleaved with the FDM/AP systems, which should not be too difficult in my opinion. You really only need to take a look at how this is done with the other systems and then adapt the FGNasalSys/SGSubsystem class instantiation accordingly
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11923
Joined: Tue Mar 25, 2008 8:40 am

Re: Actual programming language for autopilot implementation

Postby Hooray » Thu Aug 16, 2012 4:02 pm

Hooray wrote:
flameout wrote:The thing I'm most concerned with is the ability to run at the same rate as the simulation, instead of the frame rate. It doesn't appear as if Nasal or external software can do this, as although they can run faster, their interface with the main code is still limited to the frame rate.
The previous discussion should provide all the pointers to run the Nasal subsystem interleaved with the FDM/AP systems, which should not be too difficult in my opinion. You really only need to take a look at how this is done with the other systems and then adapt the FGNasalSys/SGSubsystem class instantiation accordingly


Just briefly, see: http://gitorious.org/fg/flightgear/blob ... x#line1134

Which uses: http://gitorious.org/fg/flightgear/blob ... xx#line362

Next, regarding the supported "GroupType" types, see: http://gitorious.org/fg/simgear/blobs/n ... xx#line350

Especially, note the comment saying "FDM, ///< flight model, autopilot, instruments that run coupled".

So, to start playing around, use something like:
Code: Select all
diff --git a/src/Main/fg_init.cxx b/src/Main/fg_init.cxx
index 7b7f7ff..f0cccac 100644
--- a/src/Main/fg_init.cxx
+++ b/src/Main/fg_init.cxx
@@ -1273,7 +1273,7 @@ bool fgInitSubsystems() {
     // Do this last, so that the loaded scripts see initialized state
     ////////////////////////////////////////////////////////////////////////
     FGNasalSys* nasal = new FGNasalSys();
-    globals->add_subsystem("nasal", nasal, SGSubsystemMgr::INIT);
+    globals->add_subsystem("nasal", nasal, SGSubsystemMgr::FDM);
     nasal->init();
 
     // initialize methods that depend on other subsystems.



You'll probably want to do the same for the "events" subsystem which triggers Nasal callbacks via listeners and timers (and possibly props, too?):

Code: Select all
diff --git a/src/Main/fg_init.cxx b/src/Main/fg_init.cxx
index 7b7f7ff..18d9062 100644
--- a/src/Main/fg_init.cxx
+++ b/src/Main/fg_init.cxx
@@ -1244,7 +1244,7 @@ bool fgInitSubsystems() {
     globals->add_subsystem("lighting", new FGLight, SGSubsystemMgr::DISPLAY);
     
     // ordering here is important : Nasal (via events), then models, then views
-    globals->add_subsystem("events", globals->get_event_mgr(), SGSubsystemMgr::DISPLAY);
+    globals->add_subsystem("events", globals->get_event_mgr(), SGSubsystemMgr::FDM);
     
     FGAircraftModel* acm = new FGAircraftModel;
     globals->set_aircraft_model(acm);
@@ -1273,7 +1273,7 @@ bool fgInitSubsystems() {
     // Do this last, so that the loaded scripts see initialized state
     ////////////////////////////////////////////////////////////////////////
     FGNasalSys* nasal = new FGNasalSys();
-    globals->add_subsystem("nasal", nasal, SGSubsystemMgr::INIT);
+    globals->add_subsystem("nasal", nasal, SGSubsystemMgr::FDM);
     nasal->init();
 
     // initialize methods that depend on other subsystems.


Next rebuild. To see if it works, use the "performance monitor" (debug menu) and see if the flight/nasal/events subsystems are running coupled (i.e. same number of iterations, higher than all the others)

This is untested and really just intended to get you started,so that you can see if this works or not - let me know if you hit any real issues, so that I may have another look ...

You'll also want to check if you have frame-throttling enabled or not, and if simulation time is accelerated or not - and set /sim/model-hz according to your needs - obviously, these would have an impact here.


This is what I am getting when rebuilding and starting with --model-hz=500 (with frame throttling set to 50hz):

Image

Note: Keep in mind that Nasal callbacks invoked via settimer() will then by default probably not just run at framerate anymore, but at FDM rate if the interval is 0 (untested)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11923
Joined: Tue Mar 25, 2008 8:40 am

Re: Actual programming language for autopilot implementation

Postby flameout » Sun Aug 19, 2012 5:19 pm

Thank you! Recently, I've been working long hours (the past couple of days was a big deadline), so it'll probably be a while until I can implement something clean enough to make it into FlightGear's mainline (since just changing that settings will run stuff meant to be at frame rate at simulation rate).

For now, that will be sufficient for me to do the testing that I want to do.
Also known as Johnathan Van Why.
flameout
 
Posts: 443
Joined: Thu Dec 25, 2008 5:43 am
Location: Oregon, USA
Callsign: MSJF
Version: GIT
OS: Gentoo

Re: Actual programming language for autopilot implementation

Postby Hooray » Sun Aug 19, 2012 5:42 pm

This is true, like I said - there are several options here.
On the one hand, changing "settimer 0" behavior to use the "frame" signal instead - or maybe use a wrapper in Nasal/C space to change the semantics transparently.
Another (better) option would be having two (or more) "contexts" for different types of scripts (GUI, aircraft, fdm, autopilot etc).

So that scripts could request to be run at different rates.

A while ago there was a related discussion here: https://code.google.com/p/flightgear-bu ... 0Milestone

Thinking in terms of workarounds, it probably would be possible to change the implementation of the settimer/setlistener APIs such that an additional OPTIONAL argument could be set to request a certain update rate, that should be a fairly simple change in my opinion.


it'll probably be a while until I can implement something clean enough to make it into FlightGear's mainline

if that's one of your goals, you better get in touch with other core developers to see how they would want this to be implemented, i.e. see the devel list.
Andy Ross should be the definite authority here.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11923
Joined: Tue Mar 25, 2008 8:40 am

Re: Actual programming language for autopilot implementation

Postby flameout » Sun Aug 19, 2012 5:50 pm

Hooray wrote in Sun Aug 19, 2012 5:42 pm:Another (better) option would be having two (or more) "contexts" for different types of scripts (GUI, aircraft, fdm, autopilot etc).

So that scripts could request to be run at different rates.

This was exactly the idea I had (and why it will be more than a simple change).

it'll probably be a while until I can implement something clean enough to make it into FlightGear's mainline

if that's one of your goals, you better get in touch with other core developers to see how they would want this to be implemented, i.e. see the devel list.
Andy Ross should be the definite authority here.

When it looks like I'm going to have enough time to actually implement this functionality (which may be never, because I move into college in less than a month), I'll make a post to the development mailing list.

Again, thank you for all your help! It is truly appreciated.
Also known as Johnathan Van Why.
flameout
 
Posts: 443
Joined: Thu Dec 25, 2008 5:43 am
Location: Oregon, USA
Callsign: MSJF
Version: GIT
OS: Gentoo

Re: Actual programming language for autopilot implementation

Postby Hooray » Sun Aug 19, 2012 6:40 pm

The simplest option would probably be having multiple "event" subsystems, so that -by default- scripts would be run using the standard "events" subsystem (at framerate), while other scripts could also request being run in a "FDM coupled" event subsystem instead.

I think that would be a fairly simple change actually, it's just a matter of overloading settimer/setlistener such that "fdm_coupled=true/false" could be specified to use the FDM coupled events system , so that callbacks registered like this would be invoked at FDM rate. That's probably around at most 50-80 lines of C++ code in total.

That would be the simplest and most generic solution, and it would just involve a handful of steps:

For example, in setTimer() you'd then want to support your custom FDM-coupled event manager: https://gitorious.org/fg/flightgear/blo ... xx#line907
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11923
Joined: Tue Mar 25, 2008 8:40 am

Re: Actual programming language for autopilot implementation

Postby flameout » Sun Aug 19, 2012 6:48 pm

Okay, that makes sense. When I can (certainly not within the next week, unfortunately), I'll try that out.
Also known as Johnathan Van Why.
flameout
 
Posts: 443
Joined: Thu Dec 25, 2008 5:43 am
Location: Oregon, USA
Callsign: MSJF
Version: GIT
OS: Gentoo

Re: Actual programming language for autopilot implementation

Postby Hooray » Sun Aug 19, 2012 9:40 pm

I still don't think this needs to be very complicated, especially not with all the pointers that you have now - this is what I got after 5-10 minutes playing around (not really tested in depth yet) - but this should get you started on the right track:

Code: Select all
diff --git a/src/Main/fg_init.cxx b/src/Main/fg_init.cxx
index cb4a2e5..ddafce0 100644
--- a/src/Main/fg_init.cxx
+++ b/src/Main/fg_init.cxx
@@ -1069,6 +1069,10 @@ bool fgInitSubsystems() {
     globals->get_event_mgr()->init();
     globals->get_event_mgr()->setRealtimeProperty(fgGetNode("/sim/time/delta-realtime-sec", true));
 
+    // and now for the FDM-coupled event mgr:
+    globals->get_event_mgr(true)->init();
+    globals->get_event_mgr(true)->setRealtimeProperty(fgGetNode("/sim/time/delta-realtime-sec",true));
+
     ////////////////////////////////////////////////////////////////////
     // Initialize the property interpolator subsystem. Put into the INIT
     // group because the "nasal" subsystem may need it at GENERAL take-down.
@@ -1247,6 +1251,10 @@ bool fgInitSubsystems() {
     
     // ordering here is important : Nasal (via events), then models, then views
     globals->add_subsystem("events", globals->get_event_mgr(), SGSubsystemMgr::DISPLAY);
+
+    // another event system instance that runs coupled with the FDM
+    // to be used for Nasal scripts
+    globals->add_subsystem("fdm-events", globals->get_event_mgr(true), SGSubsystemMgr::FDM);
     
     FGAircraftModel* acm = new FGAircraftModel;
     globals->set_aircraft_model(acm);
diff --git a/src/Main/globals.cxx b/src/Main/globals.cxx
index 8c8ca52..698ef4a 100644
--- a/src/Main/globals.cxx
+++ b/src/Main/globals.cxx
@@ -126,6 +126,7 @@ FGGlobals::FGGlobals() :
     renderer( new FGRenderer ),
     subsystem_mgr( new SGSubsystemMgr ),
     event_mgr( new SGEventMgr ),
+    fdm_coupled_event_mgr( new SGEventMgr ),
     sim_time_sec( 0.0 ),
     fg_root( "" ),
     time_params( NULL ),
@@ -378,9 +379,10 @@ FGGlobals::get_soundmgr () const
 }
 
 SGEventMgr *
-FGGlobals::get_event_mgr () const
+FGGlobals::get_event_mgr (bool fdm_coupled) const
 {
-    return event_mgr;
+    if (!fdm_coupled) return event_mgr;
+    return fdm_coupled_event_mgr;
 }
 
 const SGGeod &
diff --git a/src/Main/globals.hxx b/src/Main/globals.hxx
index 2ec9cc3..73e69ad 100644
--- a/src/Main/globals.hxx
+++ b/src/Main/globals.hxx
@@ -91,6 +91,7 @@ private:
     FGRenderer *renderer;
     SGSubsystemMgr *subsystem_mgr;
     SGEventMgr *event_mgr;
+    SGEventMgr *fdm_coupled_event_mgr;
 
     // Number of milliseconds elapsed since the start of the program.
     double sim_time_sec;
@@ -181,7 +182,7 @@ public:
                                 type = SGSubsystemMgr::GENERAL,
                                 double min_time_sec = 0);
 
-    virtual SGEventMgr *get_event_mgr () const;
+    virtual SGEventMgr *get_event_mgr (bool fdm_coupled=false) const;
 
     virtual SGSoundMgr *get_soundmgr () const;
 
diff --git a/src/Scripting/NasalSys.cxx b/src/Scripting/NasalSys.cxx
index a398301..24d7fb3 100644
--- a/src/Scripting/NasalSys.cxx
+++ b/src/Scripting/NasalSys.cxx
@@ -897,6 +897,7 @@ void FGNasalSys::setTimer(naContext c, int argc, naRef* args)
     }
 
     bool simtime = (argc > 2 && naTrue(args[2])) ? false : true;
+    bool fdm_coupled = (argc > 3 && naTrue(args[3])) ? true: false;
 
     // Generate and register a C++ timer handler
     NasalTimer* t = new NasalTimer;
@@ -904,9 +905,17 @@ void FGNasalSys::setTimer(naContext c, int argc, naRef* args)
     t->gcKey = gcSave(handler);
     t->nasal = this;
 
-    globals->get_event_mgr()->addEvent("NasalTimer",
+    if (fdm_coupled) {
+     static_cast<SGEventMgr *>(globals->get_subsystem("fdm-events"))->addEvent("NasalTimer (FDM coupled)",
+                  t, &NasalTimer::timerExpired,
+                  delta.num, simtime);
+      SG_LOG(SG_NASAL, SG_DEBUG, "Registering FDM-coupled Nasal callback!");
+    }
+    else {
+      globals->get_event_mgr()->addEvent("NasalTimer",
                                        t, &NasalTimer::timerExpired,
                                        delta.num, simtime);
+    }
 }
 
 void FGNasalSys::handleTimer(NasalTimer* t)



Note: I only started with --model-hz=500 to make the difference really obvious
Image

Notice how the remaining subsystems (in particular nasal and events) still run at framerate, only scripts using the new optional settimer() argument will be run fdm-coupled
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11923
Joined: Tue Mar 25, 2008 8:40 am

Re: Actual programming language for autopilot implementation

Postby Hooray » Tue Aug 28, 2012 8:40 pm

And just for the record, there seems to be a much simpler and more elegant solution - just by introducing an "fdm-update" signal and registering a conventional listener, which would automatically trigger Nasal code at FDM rate. It's weird that this only just occurred to me - but searching the archives, the idea was previously discussed (5 years ago) and suggested by Melchior Franz (former FG core developer and primary Nasal maintainer back then): http://www.mail-archive.com/flightgear- ... 13022.html
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11923
Joined: Tue Mar 25, 2008 8:40 am

Re: Actual programming language for autopilot implementation

Postby flameout » Tue Aug 28, 2012 10:47 pm

Tomorrow night, I'll try to take a look at that concept. Just to clarify, by "signal", you mean a property that is written to each simulation cycle, right? I don't want to start out on that path then find out that Nasal has some concept of "signals" that I'm not aware of.

Thank you for your help,
Johnathan Van Why
Also known as Johnathan Van Why.
flameout
 
Posts: 443
Joined: Thu Dec 25, 2008 5:43 am
Location: Oregon, USA
Callsign: MSJF
Version: GIT
OS: Gentoo

Next

Return to Autopilot and route manager

Who is online

Users browsing this forum: No registered users and 0 guests