Outerra forum
Outerra Engine => Technology => Topic started by: Steve.Wilson on December 23, 2012, 04:27:39 pm
-
Brano, Angrypig...
I've been spelunking around inside the JSBSim Reference Guide, attempting to correlate the interface that my cockpit currently uses to interact with X-Plane to what it would need to interface and interact with JSBSim.
My understanding at this point is that I would need to connect to JSBSim via a socket, and that the socket would be configured in XML scripts for the aircraft that I'm flying in Anteworld.
Would it be fair to deduce at this point that Anteworld fully integrates JSBSim, and that the methods one would use to communicate with JSBSim/Anteworld are those found in the JSBSim Reference Guide? I find that the mental gymnastics might be easier if I consider Anteworld to be the same as JSBSim operating in server mode.
Naturally, any light you can shed on this will be useful. The learning curve to get to where I am with X-Plane was rather steep, and I can tell that the curve to get to the same place in Anteworld is going to be a good deal steeper.
-
Angrypig will have to clarify it, as it's his part, but we are using JSBSim as a library. Normally JSBSim can be compiled as an executable or a static library. In order to satisfy the license we are wrapping the static library in a thin dll wrapper, so one can make his own JSBSim derivative and link it with OT.
However, I'm not sure if in this mode it can operate in server mode.
-
Thanks, Brano. I'm just trying to drill down to the architecture of how I'm going to establish that link, whether with my own compilation of JSBSim or with a new interface that talks to Anteworld as it runs. The link's the thing. I have a hunch that if you've incorporated the full JSBSim code base, even as a DLL, then the data sharing functionality is likely intact.
It just seems to me that there will be a lot of flight simulation enthusiasts that will appreciate the Anteworld/Outerra environment when it's complete. A lot of natural phenomenon to explore and enjoy. Other flight sim worlds seem so "dead" by comparison. And there's a subset of FS enthusiasts that build up full cockpit systems to sit in and really "suspend disbelief." I look forward to enjoying this world very much.
-
It just seems to me that there will be a lot of flight simulation enthusiasts that will appreciate the Anteworld/Outerra environment when it's complete. A lot of natural phenomenon to explore and enjoy.
The most interesting part is going to be when you fly boys land and can actually get out of your aircraft to admire it all. It will be very forth wall breaking for you guys I am sure.
-
Indeed. I can envision a virtual campfire, virtual hotdogs, virtual marshmallows and sleeping out under the virtual stars! ;)
-
Thanks, Brano. I'm just trying to drill down to the architecture of how I'm going to establish that link, whether with my own compilation of JSBSim or with a new interface that talks to Anteworld as it runs. The link's the thing. I have a hunch that if you've incorporated the full JSBSim code base, even as a DLL, then the data sharing functionality is likely intact.
I imagine you could use JSBSim, but there will be also our own interface to talk to OT vehicle simulation core. One interface for using OT as an IG, for example. And while currently one can bind to OT interfaces via c++ and javascript, we will have also a networked connection to it. It should give a plenty of options how to connect in various environments. I wonder what kind of connection or what kind of client would be best/simplest to use for hobbyists here.
-
What kind of interface would hobbyists want? One that's easy! 8)
Fortunately, anyone trying to connect an external process to Anteworld is likely to be a fairly technically capable individual, with C/C++ at their disposal, as well as maybe Java, Python and other scripting languages.
My vote, of course, is for the C/C++ based interface since it's the most commonly supported and what I've been using exclusively. Keep in mind that a good deal of the external interfaces - mainly for LED's and special controllers - all have their own SDK, and in my experience I've seen them mainly support C/C++ and Python. Those two give the best of both worlds: a lower level coding capability with lots of power, and access to predefined functions through a more straightforward scripting facility.
How to integrate this will be a design challenge. But, philosophically speaking, my strongest recommendation is to implement a strategy for external interfacing that mimicks, if not outright copies, similar interfaces for something like either X-Plane or FSX. X-Plane has a robust plugin SDK, FSX users have an application that *I think* accesses some form of shared memory, and reads/sets values by reference to offsets. In the main, though, just don't reinvent the wheel. :)
If you have used the entire JSBSim code base as a library in Anteworld, a straightforward networking interface is already built in, and I actually think you may have connectivity available already on a per aircraft basis via XML script. Take a look at page 58 of the JSBSim Reference Manual and see what you think.
By the way....what do you mean by "IG?"
-
Image Generator. Getting lots of requests for that, people using their own physics and system simulation and wanting just the world rendering from OT. Normally IG is a simple one-directional link, but if one wants to utilize ground level detail generated by OT, there will have to be a feedback loop providing collision data.
-
Wow. I see. That brings us full circle, Brano. When I joined this forum I was hoping to do something like that for X-Plane, although I still think that would be a tough blend since you'd have two different collision systems in play.
The ideal interface would be something that would be open source, and exposed all data for reading, writing where appropriate, and all commands. Further, there would be the ability to create and track new data items as well as new commands. This heavy customizing would be something completely up to the user, but would interact cleanly with Outerra/Anteworld once successfully compiled. Hey....I can dream, can't I? :)
-
When I joined this forum I was hoping to do something like that for X-Plane, although I still think that would be a tough blend since you'd have two different collision systems in play.
It is definitely less ideal blend than a FDM directly integrated into OT, increased latency and problematic collisions and all that. Still, in some cases it's usable.
A better coupling will be something we call a black-box interface into OT: an interface that treats your object geometrically as some shapes you define (bounding volume) with specified mass, and gives you ability to generate forces each frame from your simulation. The first part allows integration into the existing physics system, the objects are visible to other and react as they should, gravity and inertia is accounted for.
And externally provided active and passive forces allow people to run their own simulations.
But of course most simmers can be fine with JSBSim running the simulation for them. Though technically JSBSim simulated bodies are treated internally as black boxes too.
-
To be sure. In the end, the better running simulation will be the simplest one. I have little doubt that what cannot be simulated system-wise for a cockpit by JSBSim could be relegated to external applications, as long as there is enough data and control interchange.
-
More!
Brano, I just realized something. You mentioned that you were using JSBSim as a library. When I was wandering around the Anteworld main directory, I noticed the JSBSim.dll. It struck me that if I could compile JSBSim as a standalone, then I should certainly be able to compile it as a .DLL. That's what an X-Plane plugin is anyway...a DLL that the simulator loads at runtime.
So..... if the JSBSim.dll is something I could compile....and modify to my own unique needs....then I could sidestep the whole agony of TCP/IP.
Further ....I guess I'm just wondering how much you added/changed to make this particular .DLL. If it's just the JSBSim open source code base, life may just be a lot simpler than I was expecting after the first exchange in this thread.
-
AFAIK it's just added dll build mode to the normal JSBSim library. Previously it was also a thin wrapper but last time Angrypig wanted to submit the necessary changes to JSBSim directly so that no extra project was needed. Going to wake him out of his Christmas mode to reply here ...
-
Will Jingle Bells help? ;)
Thanks! So are you saying that there were changes to the code that Angrypig submitted for inclusion in the JSBSim code base? It might be a good idea to know what to look for since I've already downloaded the latest stable tarball. Happily, it already has a Visual C project!
-
In the "For What It's Worth" category, I can report that I've been able to compile JSBSim as a .dll.
My question now drives to what I need to do/not do to make my version of this .dll compatible with Anteworld? Another question for Angrypig. :)
-
Update: After wading through the JSBSim code base for a while, I believe I've zeroed in on the section I would need to modify to accommodate my cockpit related activities.
Essentially what I need to do is to add code that initializes an IData runtime and interfaces with IData "named memory." This completely side-steps any built-in interface that JSBSim currently uses and also removes the need for any sort of added "black box" tie in to Anteworld.
Brano, Angrypig, this may not conform to your intentions and likely no one else's needs. I suspect I'm the only hobbyist in the world that is using IData for personal flight simulation. Simply said, I had a pretty interesting consulting gig a few years ago! Named memory spreads itself via UDP among a cluster of systems that are also operating the IData runtime. So I can treat a three-PC cluster as one entity where instrumentation values are concerned. It's pretty neat and a heckuva lot easier than writing code to trade data packets. Faster too. Currently working wonderfully under X-Plane....and I want to extend that joy to Anteworld before digging in and getting my jet ported over.
First things first, though. If I can get a JSBSim .dll that is unmodified and working with Anteworld, I'll know I've got a base to work from.
Then I need to get it to do something unique every frame to validate where I'm going to start my surgery. 8)
-
Got some docs about that IData thing?
-
Let me see what I can scare up. ;) Note that I acquired this app in conjunction with paid work, and I continue to be an available resource for same. IData is a glass cockpit instrumentation development application used for The Real Thing (tm). So this isn't something that's available to the masses unless one wants to part with a *staggering* sum. I use it in my cockpit to stay "fresh" for the possibility of future contracts, aside from the obvious benefit. :D
Aside from IData, though, if this ends up working, it may provide the basis for an example to show other advanced cockpit builders where to put a nice deep hook into Anteworld.....one upon which they can hang some serious interface capability. As long as they don't mind dealing with OO C++. :o
-
The JSBSim version we are currently using is old. As Cameni said i want to remove the wrapper around the JSBSim and use it directly as a dynamic library. I already have done all necessary changes to be able to compile JSBSim as a DLL but it needs a few changes on our side too. The second problem is more complicated, we are running multiple instances of JSBSim (one for every plane instance which is not very efficient but there is no other way for now) and as i know JSBSim doesn't have support for this i think this will cause problems if you will try to use JSBSim's network layer, we are probably lucky that we didn't encounter problems so far.
-
Fortunately, a flight simmer only needs one instance. A gaming situation may be different. Air traffic could be handled by a different interface that doesn't need flight modeling if one feels driven to add such. There's a fellow doing that sort of thing for X-Plane already. That said, I have no desire at this point to use JSBSim's network layer, and if I compile my own version of the .DLL, no reason to. The trick is to make sure that the core of my version is the same as the DLL that Anteworld uses, with the exception, of course, of the cockpit interface code that I add. That way things should mesh smoothly.
Let's compare. I'm using what's listed as the latest current stable version: JSBSim 1.0 RC2. The only changes I made to compile as a .DLL were to reconfigure my Visual Studio solution to produce a .DLL, excluded JSBSim.cpp from the build, and added XML_STATIC to the preprocessor definitions. This will build successfully. By no means am I an expert at this, I used and extended Bill Galbraith's excellent writeup on compiling with VSE 2008 (attached). If there are other changes, I'm certainly interested to learn and incorporate. As JSBSim is open source already, this gives a powerful tool to Outerra devs!
So, at what point do you think Outerra development will begin using the "unwrapped" DLL, Angrypig? That's when I can begin testing my own modifications, and I'm eager for that, naturally.
-
If you attach your interface to FGFDMExec class it should be ok, but in case of multiple instances the named shared memory should have a unique name to avoid conflicts between instances.
I had to add __declspec(dllexport) to classes because i need direct access to them for performance reasons. The set/get property way is used in script only and not everything is available through this interface...
I think the transition to the "unwrapped" DLL will be done in sometimes in January i cannot give you precise date...
-
I understand....I think! And I agree the FGFDMExec is a likely place to add my IData calls. I can use unique names for my named memory instances, if I'm not mistaken.
Sounds like you did a lot of work if you changed every class definition!
Did you check your version into SourceForge? It might be smarter for me to work with what you've done that to try to mimic your coding efforts.
-
The DLL version is not published yet, i have to sync my repository with the JSBSim's trunk first. I plan to do that in January but i want to consult this with Jon Berndt first...
-
Got it, and that makes sense. I certainly have lots of other things to do while I'm waiting. Thanks for all you've shared to this point!
-
Greetings,
First, I'd recommend synching with the latest version of JSBSim ... shortly. I believe that most or all of our recent developments are solid, but we need to do some testing.
Second, I'm interested in the changes being proposed to support additional capabilities or ease integration. I strongly urge anyone considering changes to JSBSim to at least email me, but preferably subscribe to the JSBSim developer mailing list so we can discuss this in a broader sense and perhaps make everyone's tasks easier. This would also help to preclude the JSBSim codebase from diverging into different builds, which would not be an easy thing to manage.
Best regards,
Jon
jon@jsbsim.org
Development Coordinator and Chief Architect
JSBSim Project
www.jsbsim.org (http://www.jsbsim.org)
-
Jon, will that latest version incorporate the latest changes suggested by the Outerra team?
-
Jon, will that latest version incorporate the latest changes suggested by the Outerra team?
Can I get a summary of the proposed changes?
Jon
-
Jon
jon@jsbsim.org
Development Coordinator and Chief Architect
JSBSim Project
www.jsbsim.org (http://www.jsbsim.org)
Welcome. I am sure there will be some direct questions and private conversations between yourself and Mr Kemen.
-
Mr Kemen.
Actually Jsbsim intricacies are handled by Mr Hrabcak (aka Mr Angry Pig), who is also subscribed to the jsbsim mailing list. When he finishes with his current task he plans to sync with the latest jsbsim version and also to propose some changes there to simplify the integration. This may be also a place for Steve to plug in with his needs ...
-
Thanks, Brano!
My needs are simple at this point. I need to be using whatever version that Mr Kemen and Mr Hrabcak are using for Outerra to create the DLL that is used for flight simulation.
My intended use of JSBSim code will be as an independent, one-user fork that will allow a unique data interface with a professional instrumentation development package. Ultimately this interface will be discarded once Outerra's main external command and data sharing interface for flight simulation is developed since my flight simulator cockpit will need both command and data capabilities. I see this as somewhat downstream time-wise, so the temporary fork will allow me to export data to my cockpit and fly with external instrumentation in Outerra in the much shorter term.
-
Mr Kemen.
Actually Jsbsim intricacies are handled by Mr Hrabcak (aka Mr Angry Pig), who is also subscribed to the jsbsim mailing list. When he finishes with his current task he plans to sync with the latest jsbsim version and also to propose some changes there to simplify the integration. This may be also a place for Steve to plug in with his needs ...
That also reminds me ... I thought that I read at one time that Outerra was using different code for ground reactions. If that is integrated with JSBSim for this use, I'd like to see it.
Jon
-
I'm glad to see that more communication will go on between the JSBSim developers and Outerra team, because continued/future integration of 3rd party developers work will be hard to manage.
I'm currently developing on the DCS (http://www.digitalcombatsimulator.com/) platform and I have become aware of numerous instances where the JSBSim engine, while extremely effective at what it does, just would not allow for the flexibility that we would need without modifying the source code heavily or writing entirely new modules to plug into and overwrite JSBSim functionality. Is there a plan for how hardcore developers could do this kind of work with JSBSim and Outerra without requiring the cooperation of both teams in source code management?
The way that DCS handles 3rd party flight modelling is pretty straightforward. The simulator has an C++ API of functions passing the developer everything he needs to calculate forces and moments. These then get returned to the sim where all other calculations for position, orientation, velocities, and accelerations are performed.
Our project progress can be seen here (http://forums.eagle.ru/showthread.php?t=92197) and here. (http://forums.eagle.ru/showthread.php?t=89846)
-
JSBSim is quite flexible in how it is used by itself, or interfaced with FlightGear (for example). There are many calls to the C++ classes that are available. You can explore that here: http://jsbsim.sourceforge.net/JSBSim/. (http://jsbsim.sourceforge.net/JSBSim/.)
Beyond that, however, we are also developing a plug-in capability that might be of interest. It's still a ways off, though - maybe a few months.
Jon
-
Jon, would the plugin capability be in any way similar to that employed by X-Plane via it's SDK?
So....by extension....I wonder if a JSBSim plugin would be called by Outerra when using a .dll version of JSBSim code?
-
JSBSim is quite flexible in how it is used by itself, or interfaced with FlightGear (for example). There are many calls to the C++ classes that are available. You can explore that here: http://jsbsim.sourceforge.net/JSBSim/. (http://jsbsim.sourceforge.net/JSBSim/.)
Beyond that, however, we are also developing a plug-in capability that might be of interest. It's still a ways off, though - maybe a few months.
Jon
Now this raises my eyebrows. A connector would be the start of many possibilities with Outerra. Do you thing in agreement with the Devs this could be integrated into the engine as part of the default install or would it remain a separate component?
-
If you're asking me, the plugin glue would always be part of an Outerra installation. It would detect the presence of plugins, and integrate their functionality. If no plugins detected, no fuss.
Plugins would take the form of C/C++ dynamic libraries, .dll or some other extension. X-Plane, for example, uses ".xpl."
Scripting plugins could implement Python, SASL, Lua and the like.
Seems user friendly to me.
Outerra could have it's own plugin glue for scenic and game world items, JSBSim could have a plugin glue for flight simulation.
Glue, in this instance, means a bridge between the core Outerra or JSBSim engines that allows for two way sharing of data and commands.
-
That also reminds me ... I thought that I read at one time that Outerra was using different code for ground reactions. If that is integrated with JSBSim for this use, I'd like to see it.
Jon
Hi Jon
Sorry for late answer but there was a lot of work and i didn't have time to look at the JSBSim until now.
We used different implementation for suspension at the beginning, frankly I don't remember exactly why, but it had something to do with the collisions on the sloped terrain / bumps etc. Currently we are using pure JSBSim library with minor changes.
I managed to catch up to the latest version in the GIT repo and made the branch for the DLL configuration, removed warnings and added a few functions to FGPropertyManager/Node. The jsbsim_wrapper is now using JSBSim.dll that can be replaced with new/modified version. There can be future compatibility issues with new versions because i'm using direct C++ objects from headers but it can be handled easily on my side.
Currently i have an issue with multiple aicraft instances, I saw in the mailing list you were working on it. I'm trying to figure out where is the problem. This new jsbsim_wrapper/jsbsim.dll will be available once I manage to make it stable. Then I will attach patch with all my changes...
The next step will be to remove the jsbsim_wrapper altogether and use the JSBSim library directly as DLL.
-
Btw if someone is interested in those changes just tell me I give you the path but it's not stable and it's win32 specific for now...
-
That's nice of you, Laco! And with all of the gorgeousness that I'm seeing in OT these days, I can't wait to port my whole jet, avionics displays and other cockpit goodies over to OT/AW. I'll need that stable direct JSBSim DLL to do that. Fortunately, I have to hold off on an effort like that. I'm trying to establish a new career as a draftsman, and AutoCAD, Solidworks and Creo Elements currently own my attention. Back to school at 57. Such fun!
But it does sound like the last step you mention will need to happen before "plugin glue" can be developed. I could hack the JSBSim fork that I mentioned earlier, but it would be better if that could be more universal since I are not the only cockpit builder on the orb.
-
Everything is working including multiple instances but apache si grounded (cannot start engine :)
-
Everything is working including multiple instances but apache si grounded (cannot start engine :)
Kick it. That always works.
-
Kicking usually doesn't work, reading and thinking usually yes :)
-
words of wisedom from angrypig. so fitting :) Ive always been curious about how your nickname came about.
-
words of wisedom from angrypig. so fitting :) Ive always been curious about how your nickname came about.
I'm curious about that, too. :-)
I'm surprised to hear about the Apache engine not starting. Was it a result of the update to the most recent code?
[By the way, I sometimes forget to check here for weeks at a time; if there are some urgent questions, please feel free to contact me through email or via the JSBSim web site contact information.]
Jon
-
words of wisedom from angrypig. so fitting :) Ive always been curious about how your nickname came about.
I'm curious about that, too. :-)
You don't want to know :)
I'm surprised to hear about the Apache engine not starting. Was it a result of the update to the most recent code?
[By the way, I sometimes forget to check here for weeks at a time; if there are some urgent questions, please feel free to contact me through email or via the JSBSim web site contact information.]
Jon
The helo engine issue was purely my problem, i was using too old version and the new FDM has
"collective-cmd-norm" property for collective control.
BTW did you have a time to review my changes?
-
words of wisedom from angrypig. so fitting :) Ive always been curious about how your nickname came about.
I'm curious about that, too. :-)
You don't want to know :)
I'm surprised to hear about the Apache engine not starting. Was it a result of the update to the most recent code?
[By the way, I sometimes forget to check here for weeks at a time; if there are some urgent questions, please feel free to contact me through email or via the JSBSim web site contact information.]
Jon
The helo engine issue was purely my problem, i was using too old version and the new FDM has
"collective-cmd-norm" property for collective control.
BTW did you have a time to review my changes?
I reveiwed your changes as soon as I got them, but then got busy with other responsibilities. Thanks for reminding me. I'll take a nother look at them.
Jon
-
Where might this be at this point? Would building JSBSim as a .dll reproduce the .dll that is used by Outerra?
-
I continue to dig on this. I may need to attempt to reach Jon Berndt directly, but in the past 24 hours I found the "magic keys" into JSBSim, and by extension, into Anteworld aircraft if they are properly modified.
This is rough. I haven't tested it and it needs badly to be verified. But it seems that if one includes certain XML blocks in the aircraft configuration file, then one can set up input and output communications ports. Output ports can include the IP addresses and sockets of other PC's. Input ports can be used to set up telnet connections.
Data and control are thus provided.
Output would need to be captured and parsed by an application on the receiving PC.
Input telnet connections would need to be established automatically and programmatically by a external controlling PC.
No reason the receiving and controlling PC couldn't be the same machine since different sockets can be used.
The output connection can send a variety of aircraft flight parameters.
The telenet connection can set "properties," hence, is capable of issuing commands.
Ultimately, this provides the ability for an external flight simulator cockpit to control Anteworld aircraft.
My deduction sounds grand, perhaps, but since JSBSim is wrapped by Anteworld as a .dll, then all current functionality of JSBSim should logically be available.
Whaddya think of that, Angrypig?
;D ;D ;D
-
I continue to dig on this. I may need to attempt to reach Jon Berndt directly,
I dunno. He's a pretty hard guy to find...
but in the past 24 hours I found the "magic keys" into JSBSim,
We need to hide the magic keys a little better next time... ;-)
and by extension, into Anteworld aircraft if they are properly modified.
This is rough. I haven't tested it and it needs badly to be verified. But it seems that if one includes certain XML blocks in the aircraft configuration file, then one can set up input and output communications ports. Output ports can include the IP addresses and sockets of other PC's. Input ports can be used to set up telnet connections.
Data and control are thus provided.
Output would need to be captured and parsed by an application on the receiving PC.
Input telnet connections would need to be established automatically and programmatically by a external controlling PC.
No reason the receiving and controlling PC couldn't be the same machine since different sockets can be used.
The output connection can send a variety of aircraft flight parameters.
The telenet connection can set "properties," hence, is capable of issuing commands.
Ultimately, this provides the ability for an external flight simulator cockpit to control Anteworld aircraft.
My deduction sounds grand, perhaps, but since JSBSim is wrapped by Anteworld as a .dll, then all current functionality of JSBSim should logically be available.
Whaddya think of that, Angrypig?
;D ;D ;D
The <input> and <output> elements in a JSBSim configuration file are there to control JSBSim execution and query/set property values, and to specify output characteristics, respectively (meant for data logging).
Is it not the case that Outerra already includes a way to interact with the flight dynamics model (JSBSim)? You are correct that the JSBSim API is the window into JSBSim functionality. The API is documented here: http://jsbsim.sf.net/JSBSim. (http://jsbsim.sf.net/JSBSim.) You ought to have access to function calls to set the needed variables before each frame. The socket interface might be made to work.
Jon
-
Thanks!
Outerra/Anteworld must already have an interaction with the FDM, otherwise the aircraft would not fly nor would they be controllable if they did. :)
However, there is functionality that JSBSim offers, notably autopilot functions, that I need will need to control from my cockpit. I will be creating a standalone application to connect to JSBSim to implement these controls prior to their being offered in Anteworld. I have a hunch that the team has far more important things to do at the moment than to accommodate cockpit flight simmers such as myself by adding a suite of commands.
The data logging feature, when directed to a TCP/IP address and socket provides the means for accessing properties every frame if I understand the documentation correctly. I just need to deduce how to capture and parse the data. I have the source code for Netcat, so that will likely be a start.
As for using the FGInput class, I'm a bit in the dark. I understand that you can specify a socket with the <input> tag, but the only connection means I'm aware of at this time is telnet. A persistent connection from a external machine is low bandwidth, and a polling rate of five times a second is plenty rapid enough to capture and issue a command to turn the autopilot on or off, or set any of it's other properties. I hope I can find an autopilot file that is as robust as that in a 737, although I concede my aircraft isn't in that league.
I keep surfing and hoping to find good examples. I really want to have a complex flight sim experience in Outerra/Anteworld, maybe even full motion some day.
Are you the guy behind that emerald curtain, Jon? ;) Thanks for the reply. I'm in over my head, but that hasn't stopped me before.
-
Attempted to configure an output file. Found an example where this had been done with one of the C172 models. Unfortunately, any use of the <output> tag renders an aircraft configuration unloadable.
Drat. I'll have to wait for Brano and Angrypig to implement their external interface. I really want to migrate my cockpit to Outerra.... soon!
-
... Unfortunately, any use of the <output> tag renders an aircraft configuration unloadable.
That's strange. Can you post the <output> section? What error message or other indication do you get?
Jon
-
<output>
</output>
It *is* odd, Jon. The above was the very last try, added to the MiG config file. I got a message that the MiG config file could not load.
I also tried...
<output name="c:\\users\\jsbsim.csv" type="CSV" rate="5">
<velocities> ON <velocities>
<ground_reactions> ON </ground_reactions>
<position> ON </position>
</output>
This would crash the sim.
I did find that some variations on the Cessna 172 actually have <output> sections defined....so I'm at a loss.
Perhaps I need to try a bit harder?
-
<output>
</output>
It *is* odd, Jon. The above was the very last try, added to the MiG config file. I got a message that the MiG config file could not load.
I also tried...
<output name="c:\\users\\jsbsim.csv" type="CSV" rate="5">
<velocities> ON <velocities>
<ground_reactions> ON </ground_reactions>
<position> ON </position>
</output>
This would crash the sim.
I did find that some variations on the Cessna 172 actually have <output> sections defined....so I'm at a loss.
Perhaps I need to try a bit harder?
Go ahead and email me the offending file and I can take a look.
jon@jsbsim.org
Jon
-
No need, Jon.
I looked at the C172P version and found an <output> tag that looked correct, so I changed the .js script for that package to point to that version of the Cessna. A bit weak, but flyable. Drat, no outfile.
Then I discovered that the <output> block was commented out!!! :o :o :o
So, just to make sure I was definitely not using the wrong Cessna, I copied the block to the MiG-29 configuration file. And after a quick jog around the pattern, I found the output .csv file in the MiG's aircraft directory.
To be sure, now I need to start sending data to a socket.
Would the socket output be formatted the same as the .csv, by any chance? That would help the data capture and parsing quite a bit.
Cool to see this working. I'm not ready to unleash mad plans to conquer Anteworld just yet....but now I have more hope!
Thanks for the reply. Once I get to the point where I'm ready to go further, I'll probably need to start a new thread. ;D
-
No need, Jon.
I looked at the C172P version and found an <output> tag that looked correct, so I changed the .js script for that package to point to that version of the Cessna. A bit weak, but flyable. Drat, no outfile.
Then I discovered that the <output> block was commented out!!! :o :o :o
So, just to make sure I was definitely not using the wrong Cessna, I copied the block to the MiG-29 configuration file. And after a quick jog around the pattern, I found the output .csv file in the MiG's aircraft directory.
To be sure, now I need to start sending data to a socket.
Would the socket output be formatted the same as the .csv, by any chance? That would help the data capture and parsing quite a bit.
Cool to see this working. I'm not ready to unleash mad plans to conquer Anteworld just yet....but now I have more hope!
Thanks for the reply. Once I get to the point where I'm ready to go further, I'll probably need to start a new thread. ;D
I haven't used the socket output in a while, but by design it is supposed to work the same way.
Jon
-
Image Generator. Getting lots of requests for that, people using their own physics and system simulation and wanting just the world rendering from OT. Normally IG is a simple one-directional link, but if one wants to utilize ground level detail generated by OT, there will have to be a feedback loop providing collision data.
We handle ground collisions, which include aircraft taxiing, etc, with a network interface between the IG and flight dynamics simulator. The flight sim. has the physics ground model. It makes queries about the elevation data for various points around the aircraft. I am not completely certain but JSBSim and Flightgear may do something similar. The special query sends a point in space (lat/lon) for a point on the aircraft (wing tip, gear wheel lower point, tail point, etc) and the IG responds back with the elevation for that point directly below. The simulator uses north, east, down (local tangent plane) coordinates. This "elevation" point could actually be a point on the roof of a building so it does not necessarily have to mean terrain elevation point. For us the queries happen at the highest rate of our flight simulator which is 50 Hz. The frequency may seen low but our flight sim is busy performing many other simulations such as aircraft sensors, datalink, and other things.
-
@Steve.Wilson
I'm doing the same thing that you are doing, minus your proprietary contract stuff. I also have done similar control/display work for military simulation use, but haven't recently. Alas, I cannot use any of the code I developed at all - I have to start that work from scratch. Even though I'm a pilot IRL, most of what I did was for AFVs (tanks, etc). Anyway, it sounds like the two of us had similar careers at some point in the past--we're even roughly the same age. :o
My home cockpit is only a collection of computers, tablets & printers at the moment. Next step hardware wise is to collect the instrument hardware - I'm going for the relatively "new" USB flight instruments that have come on the market in the past decade. There is no physical cockpit yet, and I don't anticipate tackling that for at least a year. Right now its a collection of chairs, music stands, laboratory stands and the odd cardboard box. ;D
To sum up - everything you've been talking about is of interest to me!
-
This is the right type of Ex-Military Coder Cooperation that needs to be done before the kiddies step up and do 3 second coding of BS.
-
Given the academic load I had until just recently, I've shelved Outerra planning. I do feel OT looks tremendous, but I would hate to leave the fidelity of X-Plane behind. So my interest at this point is likely to be ganging X-Plane flight dynamics and navigation with the exterior visuals of OT. The ability to custom develop a "world" is also of interest as I'm a big fan of Oblivionesque future worlds. Something with... elbow room. :) But for real world simulation, it's going to be a bit before OT/Anteworld starts to have the same level of ability to navigate using GPS or other navaids. My military background in the Air Force isn't all that much of a player here though as I was only a mediocre air weapons controler and a barely above average squadron adjutant. The big stimulus from the USAF was the fun I had as an AFROTC cadet the few times I got to fly a simulator at Pease AFB, not to mention a few rides in "other than transport aircraft" that I was able to wangle. Flight sim gives me the chance to relive at least some of the feel of those exceptional experiences, and developing for flight sim gives me some control. Alas, these days, though, my PC time is relegated to AutoCAD, attempting to earn a living. ;)
-
Hi Guys,
Has there been any movement in this area over the past year or so?
I've got FSX/P3D driving the Outerra in game camera via a plugin but now I'm looking to get the FSX AI driving a few aircraft or even better a human driving another aircraft or two.
The <input> <output> tags sound interesting...
Off to sus that out right now...
-
That also reminds me ... I thought that I read at one time that Outerra was using different code for ground reactions. If that is integrated with JSBSim for this use, I'd like to see it.
Jon
Hi Jon
Sorry for late answer but there was a lot of work and i didn't have time to look at the JSBSim until now.
We used different implementation for suspension at the beginning, frankly I don't remember exactly why, but it had something to do with the collisions on the sloped terrain / bumps etc. Currently we are using pure JSBSim library with minor changes.
I managed to catch up to the latest version in the GIT repo and made the branch for the DLL configuration, removed warnings and added a few functions to FGPropertyManager/Node. The jsbsim_wrapper is now using JSBSim.dll that can be replaced with new/modified version. There can be future compatibility issues with new versions because i'm using direct C++ objects from headers but it can be handled easily on my side.
Currently i have an issue with multiple aicraft instances, I saw in the mailing list you were working on it. I'm trying to figure out where is the problem. This new jsbsim_wrapper/jsbsim.dll will be available once I manage to make it stable. Then I will attach patch with all my changes...
The next step will be to remove the jsbsim_wrapper altogether and use the JSBSim library directly as DLL.
Has this DLL project come to a stable state that you can share with world? If it is already done, can you please point us to the location where it can be accessed?
-
We haven't removed the wrapper yet, but the jsbsim modifications are on github https://github.com/Outerra/jsbsim