Hi Gene,

On Wednesday, June 15, 2011 21:43:36 Gene Buckle wrote:
> In thinking about it a bit and being reminded of the existing HLA
> interface that FlightGear has, I'm leaning toward proposing something
> built with Python and the PyQT4 GUI library.  Both components are
> cross-platform and there is a Python binding for the CERTI HLA library
> (PyHLA).

Well you can use PyHLA - That should just work with any RTI-1.3 library.

But, did you try OpenRTI?

There is a python binding included for the newer rti1516 standard. And in fact 
I have some python glue code that makes it easy to do python clients with that 
binding. We have run all this at LinuxTag. Including a small python script 
that prvides an ogle doing cirgles around a fixed point just as a demo how this 
could be achieved. Also a very simple radar application using pyside (qt 
binding) was running there. I have not published yet, this stuff since I do not 
think that the interfaces to the glue are already settled and because I wanted 
to avoid that backwardcompatibility problems at this time.
I can provide this to you if you want.

> The idea here is to create a stand-alone application that replaces all the
> built-in GUI functionality and communicates with FlightGear via the HLA
> interface.  When the manager application meets that goal, the existing GUI
> can be either removed completely or simply "unbound" at compile time so
> it's not available.

Yes, in the long term this could be kind of a plan.
I can see several components in this area:

The viewer. That was the original reason I started fgviewer. I want to have a 
pure viewer application that does not do any simulation.

The simulated aircraft. This includes *all* subsystems that belong to this 
particular aircraft. This must be done in a way that you can run several of 
these in a single federation.

The weather module. That needs to provide wind and atmosphereic parameters for 
all simulation entities.

The AI module. Provides all the AI traffic that is around.

A manager. Probably without any gui. Is responsible to give unique startup 
positions and such. Using the unique object names that are owned by exactly 
one federate this will be easy to do.

A multiplayer gateway. Currently I am talking about a local federation that 
should help runnning in a paralell environment and for things like the 
LinuxTag booth. Components might need to be coupled with a hard time 
syncronization. At least carefully selected components. Since this would just 
hang the whole federation if one of the federates hangs, this is impossible to 
do for the multiplayer part over the wide internet. Therefore the multiplayer 
server needs to be coupled loosely into the local federation. That is what 
this is for in the longer term.

And many more that make sense to move into its own component.
The above additional AI ogle with a nice, easy to adapt may be python scripted 
logic ............

Here we need to start thinking carefully. And this is the reason I ask for 
OpenRTI. I have started this project, because I found that setup of the usual 
rti libraries is way to complex. So OpenRTI provides one mode where you can 
just access a process local federation from multiple threads. There is no 
network configuration needed and you do not setup any server in this operation 
mode (sure it also provides the usual networking mode). So the plan is to use 
this mode as an aid to parallellize flightgear on a local machine. The basic 
advantage is that each federate is strictly programmed single threadad. All 
the thread syncronization is handled by the rti library and hidden in that 
thing. The trick is that each of these threads must be done in a way that you 
can just compile that alternatively in a single standalone binary and run the 
same component in a networked rti - the LinuxTag booth for example.

Now I start returning to your initial question. From my point of view, such a 
gui manager application must be included somehow in the basic set of 
functionality that is still running in the threaded mode. You would just 
control your simulation with that component. May be restart with a different 
aircraft by just shutting down the running federate and start up a new one 
with a different fdm.
And as such, doing this core component in python is something I am not sure 
So, python in the area of *optional* rti components, is a great tool.
If I remember well, you do have some bigger install at home that might benefit 
from such components very much! And in fact this is one reasons I am pushing 
this direction.

Python also has one major problem with threads. There is the big interpreter 
lock in python which makes python essentially single threaded. While this is 
not a problem when such a component runs in its own process, python in core 
components that need to run in threaded mode is essentially a no go.

OTOH, I am very curious what creative people will do with that easy python 
stuff once we can easily integrate that into a federation in a seperate process 

So, yes. There is some work left :)



All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security 
threats, fraudulent activity and more. Splunk takes this data and makes 
sense of it. Business sense. IT sense. Common sense.. 
Flightgear-devel mailing list

Reply via email to