Board index FlightGear Development New features

INS Systems (from Unlimited Wishlist)

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

INS Systems (from Unlimited Wishlist)

Postby flameout » Sun Apr 05, 2009 3:34 am

Okay, since I have now made it to the point where I feel it belongs in an aircraft, I have modified this first post to release the updates. Here's the original post:

flameout wrote:I haven't read this whole topic, just some of the posts, but I think if I were to have one big feature added I would want an xml-configurable INS system. Rather than planes (many, including the Concorde, which I believe is simulated with GPS) unrealisticly using the GPS, they could have an xml file and a gauge. I know it would be a lot of work and would need people capable of designing the system, it would increase realism hugely. Features I would want: xml-based configuration, multiple unit and mixing support, radio updating (various types, such as DME/DME and radial/DME,) and realistic alignment/fast alignment options (some planes re-align quickly.) However, this would be difficult to implement, and I think it will be some time before developers are bored enough to work on one.


The Nasal source file is attached (sorry, I currently have to upload it to the forums -- I lost my link to my web site when my Dad's hard drive crashed. Additionally, a simple readme is attached.

ins.nas may be placed anywhere, and is run from within the aircraft-set.xml file. ins.xml must be in the aircraft root directory, with the aircraft-set.xml file and the FDM configuration (this can be changed in the code.)

The ins.xml file describes each INS and its capabilities. I also, in this sample file, include a definition for each of the inputs/output to it, so that aircraft gauges will never get a nil value and have an error. It is recommended you have an error display for when they are not in nav mode. There are two properties, attwork and navwork, that can be used for this.

Please comment on it and post suggestions and feature requests. Also, any documentation that is GPL-compatible will be helpful in designing this system.

Here is a sample ins.xml file:
Code: Select all
<PropertyList>


   <left>
      <drift>

         <drift-rate type="double">.5</drift-rate>
         <pitcherr type="double">0</pitcherr>
         <rollerr type="double">0</rollerr>
      </drift>
      <nolatlonin type="string">true</nolatlonin>
      <lat type="double">0</lat>
      <long type="double">0</long>
      <trutrack type="double">0</trutrack>
      <magtrack type="double">0</magtrack>
      <north-velocity-fps type="double">0</north-velocity-fps>
      <east-velocity-fps type="double">0</east-velocity-fps>
      <ground-speed type="double">0</ground-speed>
      <vspeed type="double">0</vspeed>
      <truheading type="double">0</truheading>
      <magheading type="double">0</magheading>
      <heading-rate type="double">0</heading-rate>
      <pitch type="double">0</pitch>
      <pitch-rate type="double">0</pitch-rate>
      <roll-angle type="double">0</roll-angle>
      <roll-rate type="double">0</roll-rate>
      <navwork type="string">false</navwork>
      <attwork type="string">false</attwork>
      <mode type="string">off</mode>

   </left>
   

   <center>

      <drift>

         <drift-rate type="double">.5</drift-rate>
         <pitcherr type="double">0</pitcherr>
         <rollerr type="double">0</rollerr>
      </drift>
      <nolatlonin type="string">true</nolatlonin>
      <lat type="double">0</lat>
      <long type="double">0</long>
      <trutrack type="double">0</trutrack>
      <magtrack type="double">0</magtrack>
      <north-velocity-fps type="double">0</north-velocity-fps>
      <east-velocity-fps type="double">0</east-velocity-fps>
      <ground-speed type="double">0</ground-speed>
      <vspeed type="double">0</vspeed>
      <truheading type="double">0</truheading>
      <magheading type="double">0</magheading>
      <heading-rate type="double">0</heading-rate>
      <pitch type="double">0</pitch>
      <pitch-rate type="double">0</pitch-rate>
      <roll-angle type="double">0</roll-angle>
      <roll-rate type="double">0</roll-rate>
      <navwork type="string">false</navwork>
      <attwork type="string">false</attwork>
      <mode type="string">off</mode>

   </center>
   

   <right>

      <drift>

         <drift-rate type="double">.5</drift-rate>
         <pitcherr type="double">0</pitcherr>
         <rollerr type="double">0</rollerr>
      </drift>
      <nolatlonin type="string">true</nolatlonin>
      <lat type="double">0</lat>
      <long type="double">0</long>
      <trutrack type="double">0</trutrack>
      <magtrack type="double">0</magtrack>
      <north-velocity-fps type="double">0</north-velocity-fps>
      <east-velocity-fps type="double">0</east-velocity-fps>
      <ground-speed type="double">0</ground-speed>
      <vspeed type="double">0</vspeed>
      <truheading type="double">0</truheading>
      <magheading type="double">0</magheading>
      <heading-rate type="double">0</heading-rate>
      <pitch type="double">0</pitch>
      <pitch-rate type="double">0</pitch-rate>
      <roll-angle type="double">0</roll-angle>
      <roll-rate type="double">0</roll-rate>
      <navwork type="string">false</navwork>
      <attwork type="string">false</attwork>
      <mode type="string">off</mode>

   </right>


</PropertyList>


Hope you enjoy this.
Last edited by flameout on Mon Aug 24, 2009 6:43 am, edited 2 times in total.
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: Unlimited Wishlist

Postby Hooray » Sun Apr 05, 2009 5:18 am

INS:
http://en.wikipedia.org/wiki/Inertial_navigation_system
http://wiki.answers.com/Q/How_does_iner ... n_function
http://everything2.com/title/Inertial%2 ... 2520system


It seems, you wouldn't really need a core developer to look into implementing most of this, much of it can be implemented without using any C++ (certainly while prototyping) by creating a new instrument type that is just driven by a Nasal script.
All computations can be done in Nasal and published to the property tree, where your gauges may retrieve the information and display it accordingly.
Most of this is mainly about "accelerometers" (various accelerations are already provided in the property tree):

Even if you want it to be XML configurable, you still don't need C++, because you can either use the existing property list format for your configuration syntax, or if you really want to get fancy, just use the Nasal XML module to parse XML using Nasal.
It seems, you'll mostly have to do some reading on the inner working of INS:
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: 11292
Joined: Tue Mar 25, 2008 8:40 am

Re: INS Systems (from Unlimited Wishlist)

Postby flameout » Sun Apr 05, 2009 6:35 pm

I know how you basically implement an INS, just integrate the accelerations and rotational moments. However, you have to do it accurately enough to simulate a real drift rate, and factor in radio updating (Kalman filters?,) the earth's curve, and multiple unit mixing (which, probably unrealisticly, could be just averaging.) My one real question is: is Nasal accurate enough? And also, who knows a realistic alignment procedure? I could probably research one, however. I may start writing one, but I don't think I have the mathematics knowledge to write one. I'll try reading through the articles you have given me.
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: INS Systems (from Unlimited Wishlist)

Postby Hooray » Sun Apr 05, 2009 8:21 pm

Wow, you seem to be envisioning a much more accurate and low level implementation than what I was thinking about when I first suggested to consider prototyping an INS using scripting.

For example, I was mostly thinking in terms of trying to use currently provided properties such as those found under /fdm/jsbsim/accelerations (jsbsim aircraft) to hopefully get started quickly, without starting completely at 0.
Also, simply using the GPS properties in the beginning would also simplify your project.

flameout wrote:My one real question is: is Nasal accurate enough?

I would guess so, as far as I know Nasal numbers are all floating point with double precision, based on IEEE754.

But before you rely on anything, I would first recommend to do some simple numerical tests to see if not only numerical precision but especially performance seem good enough.

flameout wrote: And also, who knows a realistic alignment procedure?

If I were to play with trying to implement an INS, I would try to get my hands on the manual for a real device, to hopefully emulate some of it eventually.

http://books.google.com/books?id=dfOg7X ... &lpg=PA171
http://www.airliners.net/aviation-forum ... ain/51611/

This flightglobal article has some details on the Litton Ltn 72 INS, including alignment procedures: http://www.flightglobal.com/pdfarchive/ ... 00898.html

The following stuff could also be useful:
http://www.scribd.com/doc/7157412/Inert ... ntegration
http://www.scribd.com/doc/2414376/Visio ... Navigation
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-696.pdf
http://www.control.aau.dk/uav/reports/0 ... report.pdf
http://www.pdf-search-engine.com/aircra ... s-pdf.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: 11292
Joined: Tue Mar 25, 2008 8:40 am

Re: INS Systems (from Unlimited Wishlist)

Postby flameout » Mon Apr 06, 2009 12:37 am

Thank you very much for all the information. I might try initially simulating a gimballed system rather than a strapdown one, as it is simpler to deal with. Also, is there an easy way to make JSBSim accurately integrate a value? I don't think Nasal will iterate fast enough (I got 30 then 40 times per second, alternating, on simple code,) unless there is a way to speed it up (I am using settimer to iterate.)
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: INS Systems (from Unlimited Wishlist)

Postby Hooray » Mon Apr 06, 2009 5:18 am

Also, is there an easy way to make JSBSim accurately integrate a value?


Do you mean for arbitrary new integrations set up at runtime or just setting the precision for existing values?

In both cases, I really don't know - I would think the latter is generally a good thing to have, the former is probably also useful in some scenarios, because it seems to me like a pretty useful API to have, especially if it can be customized so that the accuracy/precision can be configured at runtime.

In other words, some standard way to set up an integration and its precision using the property tree that is to be run by the FDM, so that the results are published back to the tree and can be used by FlightGear scripts and instruments there.

If it isn't already supported, providing a way to tune the accuracy of currently running integrations, would probably be considered a good enhancement of jsbsim, and would probably be much easier to implement than support for arbitrary new integrations.

It's probably best to check back with the jsbsim folks: http://sourceforge.net/mail/?group_id=19399
(Feature requests go here)

I don't think Nasal will iterate fast enough (I got 30 then 40 times per second, alternating, on simple code,) unless there is a way to speed it up (I am using settimer to iterate.)

How exactly are you using settimer at the moment?
Also, is there any shell output (or other IO) happening during iterations? (that would slow down everything significantly)

I assume this is running Nasal in FlightGear, not the standalone interpreter?
What's the framerate you are getting? Does it seem to be bound to your framerate?
What iteration rate are you getting without doing any computations at all?

In FG, the simulator's main loop itself is likely to have a significant effect on the nasal update rate you're getting.

Have you considered running your test code inside a different nasal thread?
As previously pointed out by another user, nasal threads seem to be supported in FlightGear, too.
So that might be worth a try if you find your update interval to be insufficient.

Note however that much of the FG API (props) isn't yet threadsafe.

If you haven't already, you might also want to download the Nasal source code from CVS in order to compile a Nasal standalone interpreter, while it will lack of course the FG API, it might show you how capable Nasal is a standalone tool performance-wise.

In general, I would suggest to check out the Nasal mailing list where your questions are likely to be answered more reliably. Also, by presenting your idea and requirements there, you'll get better answers on how feasible doing this in Nasal really is.

Like I said before, I was only thinking in terms of doing a basic emulation, while you are thinking of doing very accurate and advanced stuff like using Kalman filters etc.
Personally, I think this is going a bit too far in the beginning, I would try to keep it as simple as possible to get something going, you could always improve, redo and replace some parts of it later on.

I wouldn't be too surprised to learn that some of this really isn't ideally done in Nasal space, on the other hand there are other generic FlightGear systems like the FDMs or the autopilot code which provide for highly runtime configurable number crunching methods, while having all the inputs and outputs go through the property tree so that everything is exposed to instruments or scripts. So creating for example a similar system to do configurable integrations or software filters in C++ space, might be another option for the future.
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: 11292
Joined: Tue Mar 25, 2008 8:40 am

Re: INS Systems (from Unlimited Wishlist)

Postby flameout » Mon Apr 06, 2009 1:00 pm

For the JSBSim integrating, in case I can't get Nasal to work for me (I would prefer Nasal, as that would put all the code in one file and support other FDMs,) I was asking if there was a way to have JSBSim integrate it in the config file, without manually writing a left/right-hand sum (or trapezoidal, or Simpson's ...) into the file. For iterating in Nasal, I am using:
Code: Select all
ins = func {
     settimer(ins, (I've tried 0 and 120 here));
     (rest of code here)
}
There is shell output (the rate it is running,) but I thought about that and removed the print command, but without any IO it still was running too slow (the values were still off.) I will check about the rate without any computations, but using the delay between frames I have gotten this general rate (iterations per second:)
40.0000000035
30.0000000027
40.0000000024
30.0000000080
30.0000000023
40.0000000065
etc, sometimes dropping just below the numbers here, so I get 29.999... or 39.999... I will read up on Nasal threads, and try it in another thread without IO. For now, I'll just simulate the acceleration part of a gimballed system (assuming perfect gyros,) to make it much easier. I'll build onto that code for simulating a strapdown system.
Additionally, just to make sure, does FlightGear (or its FDMs) simulate the Earth's curvature, mainly the longer distance you have to travel at higher altitudes for a given change in lat/lon?
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: INS Systems (from Unlimited Wishlist)

Postby Hooray » Mon Apr 06, 2009 1:24 pm

flameout wrote:For the JSBSim integrating, in case I can't get Nasal to work for me

While I don't really know, I don't think you can already set up arbitrary integrations to have jsbsim compute them for you, but in any case it'll be better to ask this on the jsbsim mailing list or by filing a support request using the support tracker at sourceforge.

Code: Select all
ins = func {
     settimer(ins, (I've tried 0 and 120 here));
     (rest of code here)
}

As a general note, you'll want to prefix variables with the 'var' keyword, even if they refer to function names (check out the wiki for details).

I will read up on Nasal threads

http://plausible.org/nasal/lib.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: 11292
Joined: Tue Mar 25, 2008 8:40 am

Re: INS Systems (from Unlimited Wishlist)

Postby MAKG » Mon Apr 06, 2009 3:48 pm

Hooray wrote:
Also, is there an easy way to make JSBSim accurately integrate a value?


Do you mean for arbitrary new integrations set up at runtime or just setting the precision for existing values?

In both cases, I really don't know - I would think the latter is generally a good thing to have, the former is probably also useful in some scenarios, because it seems to me like a pretty useful API to have, especially if it can be customized so that the accuracy/precision can be configured at runtime.


Precision is not the issue. Accuracy for integrated rotations is mostly a timestep-discreteness and sampling issue. Not the number of digits stored.

As a rule, integrate ON PAPER whenever possible. An INS is a simultaneous rotation among three axes. You'll want to do this with quaternion math (it can be done with rotation matrices, but it's a mess -- it is NOT a sequence of Euler angles).

I had a student try something substantially similar a few years ago. It was simulating the gyroscopes on an airborne telescope, given attitude and location information fed from a simulated aircraft. He tried to integrate given accelerations in his first version. He couldn't point at the broad side of a barn (his telescope jittered far worse than the field of view, and drifted faster than earth rotation!). He replaced it with a preintegrated form, and we still have it working in the lab today, some four years later.

I would strongly suggest dispensing with gyroscope drift for the first version. At least to get a prototype out, assume the INS is truly inertial and work out the complete rotations from "turn-on." Separately, calculate instantaneous accelerations. Integrating Newton's 2nd Law discretely is VERY INACCURATE and you'll have a useless INS if you attempt to go that route. I seriously doubt a real one works that way (an analog computer would be far superior). You'll get secular drifts (and possibly instability) far worse and distinct from gyroscope drift.
MAKG
 
Posts: 1156
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast

Re: INS Systems (from Unlimited Wishlist)

Postby flameout » Tue Apr 07, 2009 3:56 am

Thank you for the help, but as for math beyond high school, I don't know much. When I learn more, I may try again. But if what I currently know isn't accurate enough, I'll have to try again later -- if one isn't already made. Again, thank you for your help, but I probably just don't know enough to write an accurate system.
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: INS Systems (from Unlimited Wishlist)

Postby MAKG » Tue Apr 07, 2009 2:09 pm

Actually, quaternions sound high-falutin' to Americans for some reason (like, they aren't taught in school, even at the postgraduate level), but they aren't really all that difficult.

If you want an introduction, they are VERY widely used by the gaming community. In a nutshell, it's a nice way to make a cockeyed rotation. You'll need some high school trigonometry, but not much beyond that (vector algebra, which really is trigonometry anyway).
MAKG
 
Posts: 1156
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast

Re: INS Systems (from Unlimited Wishlist)

Postby Hooray » Tue Apr 07, 2009 8:52 pm

According to the number of thread views, there seems to be some fair amount of interest in your idea, so I would assume that once you get a simple prototype going, people will start checking it out and make suggestions for improvements or maybe even get involved in contributing to your idea.

As MAKG's postings show, there are obviously other FlightGear users here on the forums who may have some of the expertise required to help improve such a script eventually.

So, I wouldn't bother too much about the more involved technical details and concentrate more on the stuff that you know you can realistically do, even if that means making some simplifications in the beginning.

Also, I was just playing around with nasal's threading support to see what iteration rate can realistically be achieved inside a nasal thread running in FlightGear, and it seems actually pretty promising, even though there appear to be some ways to optimize it further (it seems that nasal doesn't really optimize away function calls that always return identical/constant results).

I was getting an iteration rate of usually 500-600 hz, by repeatedly running a very simple loop such as this one inside a nasal thread:
Code: Select all
for (var i=0;i<=1024;i+=1) {
     var x = 512.32+i;
     var y = 31.1+i;
     var z = 71.23+i;
     var result = x*x + y*z;
   }


It seems however that it's a good idea to avoid repeatedly calling external functions, the function call overhead of executing the same loop in another function was pretty noticeable (just 300-400 hz) compared to just running the same loop inside the thread's main function directly, nested functions (or hash methods) don't seem to impose this performance penalty.
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: 11292
Joined: Tue Mar 25, 2008 8:40 am

Re: INS Systems (from Unlimited Wishlist)

Postby AndersG » Tue Apr 07, 2009 9:29 pm

Hooray wrote:I was getting an iteration rate of usually 500-600 hz, by repeatedly running a very simple loop such as this one inside a nasal thread:


What values is this thread going to work on? AFAIK the FDMs only publish their state (e.g. position, velocity and acceleration) at frame rate. Btw. it is not safe to read the property tree from a Nasal thread (or at least it wasn't the last time I tried).

I think a higher level approach might be easier. Are there approximate models for how fast the error grows subject to how the aircraft maneuvers?

Cheers,

Anders
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2418
Joined: Wed Nov 29, 2006 9:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: INS Systems (from Unlimited Wishlist)

Postby flameout » Wed Apr 08, 2009 12:26 am

For now, I will simulate an older gimballed ins so I don't need to calculate rotations. I will also simulate a perfect gyroscopic platform, so all I do is integrate the north acceleration and the east acceleration twice (for lat/lon position) and the vertical acceleration once (they also can run VSIs.) For the nasal iterating, I'll go with the 30-40 Hz refresh rate I am getting, and just have it run as fast as I can. For now, I'll just try and get the interface up and running -- I won't try to even integrate twice, I'll just use velocity to find lat/lon.
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: INS Systems (from Unlimited Wishlist)

Postby MAKG » Wed Apr 08, 2009 1:12 am

I'm afraid I don't understand that statement.

Gimballed gyroscopes work in rotations. That's what they do. You point them in one direction in inertial space and they stay there. The game is to calculate how the aircraft rotated with respect to the gyroscope.

Modern fiberoptic gyroscopes cough up rotation rates through a very clever application of interferometry.

"Integrating the north acceleration" means calculating a rotation to the north. Unless you're making an interplanetary navigation system, you are always making rotations on the surface of a sphere.

And I'll say it again: numerical integrations are inaccurate. They should be avoided whenever possible (and it's possible here). A few extra significant figures due to not having to timestep will make the difference between a gyroscope that "precesses" at a few arcminutes per hour and a few degrees per hour. For an 8 hour flight, do you really want an INS that accumulates errors up to 15 or 20 deg? You might as well not have it. Professionally built INSs have rates less than 1 deg/hour, but picking the best integration parameters is very much an art, and you'll have a very hard time doing as well under arbitrary circumstances.

I think you're trying too hard to be physically accurate. The INS reports position and orientation. You know the position and orientation. Cheat. This is a simulator, not a real device, and you can add a random-walk noise of sorts in a later iteration. Simulating on the level you want would be appropriate if you were designing some hot new gyroscope and you wanted a non-lethal way to test it.
MAKG
 
Posts: 1156
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast

Next

Return to New features

Who is online

Users browsing this forum: No registered users and 1 guest