Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Jon S. Berndt]

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

[Steve.Wilson]

Where might this be at this point?  Would building JSBSim as a .dll reproduce the .dll that is used by Outerra?

[Steve.Wilson]

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?

 

[Jon S. Berndt]

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?

 

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. 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

[Steve.Wilson]

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.

[Steve.Wilson]

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! 

[Jon S. Berndt]

... 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

[Steve.Wilson]

<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?

[Jon S. Berndt]

<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

[Steve.Wilson]

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!!!   

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.   

[Jon S. Berndt]

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!!!   

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.   

I haven't used the socket output in a while, but by design it is supposed to work the same way.

Jon

[Steve Jones]

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.

[CERDIP]

@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. 

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. 

To sum up - everything you've been talking about is of interest to me!

[ZeosPantera]

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.

[Steve.Wilson]

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.