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=13780Also see:
http://wiki.flightgear.org/Howto:Using_ ... FlightGearOpenCL 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.zip1) 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_NasalIt 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.hpphttp://www.khronos.org/registry/cl/spec ... us-1.1.pdfObviously, 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.