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.

Re: INS Systems (from Unlimited Wishlist)

Postby jonsberndt » Wed Apr 08, 2009 11:54 am

JSBSim does have an integrator component, as you may know. This is the kind of thing (INS) that the JSBSim components were designed to support, and I'd like to see an INS inj our systems/ folder. :-)

Jon
Jon S. Berndt
Development Coordinator
JSBSim Project
http://www.JSBSim.org
http://www.facebook.com/jsbsim
User avatar
jonsberndt
 
Posts: 205
Joined: Tue Aug 07, 2007 1:44 am
Location: Westminster, Colorado

Re: INS Systems (from Unlimited Wishlist)

Postby flameout » Wed Apr 08, 2009 1:34 pm

I think that, for the future, I should keep the code that does the raw integrations/rotations separate from the code that does lat/lon conversions and other, higher-level work, so I can, as a future option, use JSBSim's integrator component or some other, more accurate, integrator. In response to MAKG's reply, I was not clear enough in my post. I will simulate a gimballed system, with a perfect platform simulated (always perfectly level.) I will then integrate the north/east velocities to get position, not orientation. As far as I see so far (I have not run it for a full hour yet,) it seems to be accurate enough. Before I wrote the code to convert to lat/lon, I flew for ten minutes with it reporting the feet offset since I started the sim. After landing, it reported my position as being approximately 10 feet off. From what I understand, since I am only doing one level of integration, I should have an error that is approximately proportional to time, so it is drifting less that 100 feet per hour! Although I probably can't get a realistic accuracy integrating acceleration twice, I do have a simulation that would work. I just have to finish the details to post an early version. Hopefully, I'll have time after school to finish and post it.
EDIT: Nope, I had too much homework. Maybe tomorrow, but it might be the weekend before I have time.
EDIT2: I currently have what is basically proof of concept code. It is obviously not complete, for example it doesn't correct when the longitude isn't in the range of -180 to 180, but when I did ten minute flights locally it ran well. Although I kind of feel using the GPS position and then adding in error is "cheating," I am staying at a high enough level that accuraccy isn't too big of a concern.
The most recent work I have done on it is testing it. I copied code from online that calculates the bearing to a destination lat/lon, and I made a simple homing program. I flew from an airport in the Willamette valley, up to Portland Intl. (KPDX) down back to the airport, back to KPDX, then down to KSFO. It stayed accurate the whole time. Soon, I will be adding other features, like vertical speed calculation and eventully the xml configuration.
I have now formed most of the properties so it is usable in an aircraft, and am finishing up the xml configuration part. It is now implemented as a object, so multiple inses can be simulated. When it is fully functional, I will post it again.
EDIT 4/19/09: I have a mostly functional version. It loads its configuration from ins.xml in the root directory of the aircraft ("data/Aircraft/787/ins.xml" for the 787,) here is a sample ins.xml, the format will change with more features:
Code: Select all
<inslist><!-- inslist needed because without it there's an error -->
<ins name="left">
   <drift-rate>1.7</drift-rate>
</ins>
<ins name="center">
   <drift-rate>1.7</drift-rate>
</ins>
<ins name="right">
   <drift-rate>1.7</drift-rate>
</ins>
</inslist>

I will work on multiple ins mix, radio updating, then a drift simulation. Eventually I'll add smaller features and convert the integration to trapezoidal. Soon, I'll also separate the core integration from the rest, so it could be implemented in JSBSim if someone wants it that way. I probably won't code gyroscope rotation calculations, but someone else can. For the drift model, I'll probably drift at the defined drift rate and slowly vary the direction based on time (probably up to 360 degrees per hour.) The code is at http://ryan.vanwhydesign.com/ins/ins.nas , just run it (after correctly placing the ins.xml file) from the aircraft-set file.
Now that I've thought about it more and restarted work, I think trapezoidal integration is pointless -- it's identical to averaging the left and right hand rules and is only off by half of the first sample, which is about 0 anyway if it was aligned realistically. As of yet, realistic alignment and roll integration is not simulated, and I may have to remove the vertical speed calculation, as for not it is to accurate. I am working on radio updating. However, I don't want to struggle with the math of 20+ locating techniques (DME/DME, DME/VOR, DME/loc, VOR/VOR, VOR/LOC, DME/ADF, VOR/ADF just to list a few, but some of them have on and off-field DME options) so I am just looking at the tuned navaids to find the accuracy, then simulate (using the random function) the location estimate from that. I will then develop a very simple drift simulation, then probably work on multiple INS mix. However, I think I might (if it's not too hard) try to simulate the RNAV approach into ZUNZ. I am currently working on the interpolation of the points (bezier curves don't go directly through them) and I will then see if I can code it and make a simple approach system. Plus, in the summer, I will probably have to set my computer back up -- but I will then have internet access on my development machine and will get CVS. Oh well, a long todo list for me... I'll have it done sometime.
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 May 10, 2009 4:55 pm

flameout wrote:multiple unit and mixing support, radio updating (various types, such as DME/DME and radial/DME,)

Support for auto-tuning and for mixing multiple units will also require a way to query the navigational database.

This however isn't currently directly possible using Nasal scripts because the navigational database API isn't yet exposed to Nasal scripts, but if you find you're stuck implementing this, drop me a line and I can provide you with some patches to work around these limitations.

One very easy thing to do that doesn't take longer than 5 minutes, would be to simply also expose the gps coordinates for each active navaid using the property tree, so that you can get the actual position of the navaid from the property tree and use it as if you had queried the navdb. You could also reverse the computation by taking the bearing and distance to the navaid (both of which are provided in the property tree) and then calculate the gps coordinatees.

Similarly, you'll require a way to get a list of navaids that are within your range. So that you can directly alternate between them.

This could for example be done by having FlightGear write out all stations within a configurable range of say 50 nm to the property tree:
Code: Select all
/instrumentation/in-range-dme-stations
/instrumentation/in-range-vor-stations
/instrumentation/in-range-vortac-stations
/instrumentation/in-range-ndb-stations


However, in the beginning, you can probably easily work around these limitations by simply hardcoding a bunch of navaids and their frequencies into your scripts for your test airport (use airnav.com to look up available navaids for your sector).

That way, your script can alternate between a handful of navaids that are close to KSFO for example.
Once you want to generalize this, one could then add such properties to the property tree.

inslist needed because without it there's an error

This is because of how XML works, you may want to check out the docs in the $FG_ROOT/Docs folder, or the FlightGear wiki, or just spend 5 minutes reading http://www.w3schools.com/xml/default.asp
Generally, you'll want most XML files to be of the so called property-list encoded format, which boils down to:
Code: Select all
<?xml version="1.0"?>
<PropertyList>
  <ins>
   <name>left</name>
   <drift-rate>1.7</drift-rate>
  </ins>

  <ins>
   <name>center</name>
   <drift-rate>1.7</drift-rate>
  </ins>

  <ins>
   <name>right</name>
   <drift-rate>1.7</drift-rate>
  </ins>
</PropertyList>


While this is much more verbose than conventional XML requires (i.e. due to non-use of attributes), this format ensures that most of FlightGear can easily deal with this data, because it is natively being supported by the property tree and all related APIs.

Also, it is generally recommended to provide a type attribute for numeric values (e.g. type="double" in your case)

Just in case, if you haven't been following the jsbsim devel mailing list:

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: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: INS Systems (from Unlimited Wishlist)

Postby flameout » Sun May 10, 2009 7:35 pm

Thank you for the information. For now, I will probably change it to the format you gave, but I don't understand the FlightGear command that reads that format (fgcommand("loadxml", node???)). For radio updating, I will just use an algorithm to estimate the error that would come from the selected combination of navaids and then compute the "radio" coordinates by grabbing the actual coordinates and using the random function to put in error. It will do this once per second. I did try to begin writing a "real" method, but there's like 50 types of updating you can do (listing off the top of my head) and it would be a pain to get each one right individually. I started on one (dme velocity updating) but when I got an error in the math and didn't quickly see it I realised it would take forever. I will update the attached file when I get the radio updating working. Also, can anyone explain fgcommand("loadxml", node) -- particularly the node part. Is that to read the XML directly into the property tree? Thank you.
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 May 10, 2009 7:55 pm

flameout wrote:For now, I will probably change it to the format you gave, but I don't understand the FlightGear command that reads that format (fgcommand("loadxml", node???)).

It's actually fairly simple:

Also, can anyone explain fgcommand("loadxml", node) -- particularly the node part. Is that to read the XML directly into the property tree?


Yes, it will directly load a valid property list (XML file with PropertyList top level node) into the property tree, using the node that you provide as destination (i.e. targetnode).
Imagine "targetnode" as the path were you want to put the property list structure into the property tree, similar to a file system path.

You are basically telling FlightGear to load an XML file into the property tree at a configurable location.

For example, consider the following simple XML file named "test.xml":
Code: Select all
<?xml version="1.0"?>
<PropertyList>
  <test>
    <enabled type="bool">false</enabled>
    <range-nm type="double">55.5</range-nm>
  </test>
</PropertyList>


This can be directly loaded into the property tree and will result in the two new properties to be put beneath "targetnode":
  • test/enabled (bool)
  • test/range-nm (double)

For example, if you specify targetnode to be "/foo/" everything will be put into /foo (test/enabled ...)
If you specify targetnode to be "/instrumentation/abcd/" everything will be put there (test/enabled).

So you can also imagine it like a prefix that specifies the location.

fgcommands are documented in $FG_ROOT/Docs/README.commands.
loadxml - load XML file into property tree
filename: the path & filename of the file to load
targetnode: the target node within the property tree where to store the XML
file's structure. If targetnode isn't defined, then the data will be stored
in a node "data" under the argument branch.


However, if you are using Nasal, there's a more abstract wrapper on top of it available in $FG_ROOT/Nasal/io.nas, it's called read_properties:

Code: Select all
# Load XML file in FlightGear's native <PropertyList> format.
# If the second, optional target parameter is set, then the properties
# are loaded to this node in the global property tree. Otherwise they
# are returned as a separate props.Node tree. Returns the data as a
# props.Node on success or nil on error.
#
# Usage:   io.read_properties(<filename> [, <props.Node or property-path>]);
#
# Examples:
#
#     var target = props.globals.getNode("/sim/model");
#     io.read_properties("/tmp/foo.xml", target);
#
#     var data = io.read_properties("/tmp/foo.xml", "/sim/model");
#     var data = io.read_properties("/tmp/foo.xml");
#
var read_properties = func(path, target = nil) {
    var args = props.Node.new({ filename: path });
    if (target == nil) {
        var ret = args.getNode("data", 1);
    } elsif (isa(target, props.Node)) {
        args.getNode("targetnode", 1).setValue(target.getPath());
        var ret = target;
    } else {
        args.getNode("targetnode", 1).setValue(target);
        var ret = props.globals.getNode(target, 1);
    }
    return fgcommand("loadxml", args) ? ret : nil;
}


For writing XML property lists, you'll want to check out write_properties.
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: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: INS Systems (from Unlimited Wishlist)

Postby flameout » Sun May 10, 2009 9:54 pm

Thank you, when I get back home and have time to work on it I will switch it over to io.read_properties(file, "/ins"). I didn't know you could just specify the path, all I could find was that you have to make a "node" object or something. Also, my very quick search online didn't reveal how to iterate through the property tree, so how is that done? I mean, once I have all these properties defined after reading the XML file, how do I find all the properties for the inses? (I hope I'm clear enough.)
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 May 11, 2009 4:42 pm

flameout wrote:Also, my very quick search online didn't reveal how to iterate through the property tree, so how is that done?

Normally, you iterate over a tree structure, by using a tree walking API (a pretty complete Nasal wrapper for the FG property tree API is available in the $FG_ROOT/Nasal/props.nas module) - this is in fact similar to how an XML parser works.

However, this is only really required if you don't have all the required information on the nodes in the sub tree that you are interested in.

So, if you do know the structure and format beforehand (because you have completely defined it in the XML file), there's really no need to manually "walk" the whole tree structure, you can simply refer to all nodes directly because you know everything that you need to know.

Imagine it like a key/value pair, where the key is the property path (the variable name) and the value stored there is the actual value of that variable.

flameout wrote:I mean, once I have all these properties defined after reading the XML file, how do I find all the properties for the inses?


I think you may be misunderstanding how the translation from XML to the property tree happens, which is happening implicitly behind the scenes.

By following a very simple but explicit format in your XML file, like in the snippet that I posted above, you already know exactly what your nodes will look like in the property tree.

Basically, all nodes are translated to a hierarchy of children that are separated with a forward slash, while the tag's name will become the node's name.

Code: Select all
<?xml version="1.0"?>
<PropertyList>
  <test>
    <enabled type="bool">false</enabled>
    <range-nm type="double">55.5</range-nm>
  </test>
</PropertyList>


This will result in two properties to be created:
  • test/enabled (bool)
  • test/range-nm (double)

Do you see, how the tag names are translated to node names, and how the XML structure is translated into the path hierarchy using slashes?

Here's another example:

Code: Select all
<?xml version="1.0"?>
<PropertyList>
 <foo>
  <test>
    <enabled type="bool">false</enabled>
    <range-nm type="double">55.5</range-nm>
  </test>
 </foo>
</PropertyList>


This will result in the two properties to be wrapped in a top level node called "foo"
  • foo/test/enabled (bool)
  • foo/test/range-nm (double)


Code: Select all
<?xml version="1.0"?>
<PropertyList>
 <foo>
  <test>
    <even-deeper>
     <enabled type="bool">false</enabled>
     <range-nm type="double">55.5</range-nm>
    <even-deeper>
  </test>
 </foo>
</PropertyList>


This will result in the two properties to be wrapped in a top level node called "foo"
  • foo/test/even-deeper/enabled (bool)
  • foo/test/even-deeperrange-nm (double)

So, whatever your valid XML structure looks like, it will be directly translated into a corresponding property hierarchy, where forward slashes are used as terminators between nodes. Given that you are the one who is defining the internal structure of your XML files, you already know how to interpret the tree that's read in, in other words you know what to expect, and where to find it.

For example, if you do read in your XML file and have it loaded into a path called "/ins", you know that the structure of the XML file is now put beneath "/ins" in the global property tree.

So that's the thing that you use as prefix when referring to your properties.
If, on the other hand, you use a different targetnode (like for example "/my-ins"), everything will be put there instead.

Next thing is, to look at your XML file's structure: if you are interested in the "enabled" key from the previous example, you'll see that the path [u]inside the XML file[/b] is: foo/test/even-deeper/enabled

Now, you only have to add the prefix to the front of the string, beause that's the location where you actually stored your XML nodes:
/ins/foo/test/even-deeper/enabled

This is then exactly the property that you'll want to use when working with the property tree, using helper functions like getprop() or setprop():
Code: Select all
  var enabled_node = "/ins/foo/test/even-deeper/enabled";
  var value="true";
  setprop(enabled_node,value);


(I hope I'm clear enough.)

I am not sure, if I understood you correctly.

If it's still unclear, you may want to rephrase your question, or maybe refer to $FG_ROOT/Docs/README.introduction:
Internals
---------

The core of FlightGear is the property system. This is a tree like internal
representation of global variables. The property system is explained more
in detail later on.

FlightGear' way of doing things is breaking it up into small pieces. There is
(for example) animation code that reacts on property changes. There is also a
Flight Dynamics model (FDM) that (amongst other things) updates properties.
There is a menu system that can display and alter properties. Then we have
sound code that plays sound based on ... properties.

Maybe you see a pattern evolve by now.

All subsystems are almost self containing. Most of the time they only read the
values of some properties, and sometimes they alter other properties. This is
the basic way of communicating between subsystems.


Property System
---------------

The property system is best described as an in-memory LDAP database which holds
the state of global variables. The system has a tree like hierarchy (like a
file system) and has a root node, sub nodes (like subdirectories) and end-nodes
(variables).

All variables are kept internally as raw values and can be converted to any
other supported type (boolean, int, float double and string).

Like a file system, every node can be accessed relative to the current node, or
absolute to the root node.

The property system also allows aliasing nodes to other nodes (like symbolic
linking files or directories to other files or directories) and may be assigned
read-only or read-write.

If necessary it would be possible for parts of the program to hold it's own
property tree, which is inaccessible from the global property tree, by keeping
track of it's own root-node.

Property I/O code allows one to easily read the tree from, or write the tree to
an XML file.
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: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: INS Systems (from Unlimited Wishlist)

Postby MAKG » Mon May 11, 2009 5:28 pm

I probably should share an experience to elucidate why I'm so down on numerical integrators unless there is no alternative.

I don't know the conditions of your test, but the ones where you would expect the largest errors are those where the samples change most rapidly -- maximum-rate turns, turbulence, thunderstorms, etc. It sounds like you're measuring deviation from good or perfect conditions.

I wrote a relatively simple flight planner for a non-wind-correcting aircraft, some four years ago. It involves integrating a cycloid on the sphere (it keeps a specified star at constant bearing). It does so numerically because wind doesn't behave analytically, and the wind affects the ground track for this aircraft (it flies headings, not courses). The first version, of course, had zero wind and constant conditions (zero fuel flow, for instance). It worked so well that I put in a fancy 5th order Runge-Kutta integrator with adaptive step size. It could fly the aircraft around the world on three samples, and miss well within its error budget of 1 nm.

Then, I added fuel flow. Still, it was quite good; fuel flow is pretty slowly-varying for the flight profiles at hand after climbout. But then I added wind. on a 1x1 deg grid using seasonal means, it is not at all poorly behaved. But there goes the error budget, and it takes about as many samples to calculate as there are wind grid points. Why? Conditions aren't perfect anymore. The wind is fairly smooth, but not completely so. Subdividing the grid does not always yield an improvement in accuracy, even with quadrilinear interpolation (I would need 5th order interpolation to support a 5th order integrator, but that has its own drawbacks).

It's good that you're seeing only a tiny numerical error, but my skeptic alarm is going off. It's TOO good, which suggests that conditions are too perfect, and you're not looking at the limitations of your algorithm.
MAKG
 
Posts: 1156
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast

Re: INS Systems (from Unlimited Wishlist)

Postby flameout » Tue May 12, 2009 3:31 am

Thank you, Hooray, I will look in the props module and find how it is done. All I need to do is find the names of all the inses (I will change the format) so I can make them and give them the location of their properties.

As to MAKG's response, I don't understand what you are talking about. I know the left, right, trapezoidal, midpoint, and Simpson's (using parabolas) rule for integration. As for non-numerical methods, I don't know what you mean. I do notice that only the location (velocity was almost constand for cruise) stayed accurate for the flight. Vertical speed, in particular, was way off the right value. However, I don't know how to correct this problem, so I will wait until someone else improves my code or I learn a better method. I should test it in turbulence, too, and accelerate and decelerate to see how quickly I can make my velocity vary.
Thank you for all the help.
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 May 12, 2009 4:18 pm

When possible, it is always better to calculate integrations analytically on paper. That way, your stepsize is infinitesimal.

Failing that, it is usually better to keep cumulative state -- that is, keep track of where you are, rather than where you started and what your velocities were.

Altitude is MUCH MUCH harder to keep track of, just because of the precision you require. 1000 feet is enough to cause substantial collision risk. That's 1/6 mile, much tighter than horizontal tolerances. But you really want that from the pressure altimeter at high altitude anyway (it may be incorrect, but it's the same mistake everyone else is making, so you don't bang into anyone). Similarly, vertical speed is extremely slow compared to horizontal speed, for any "normal" aircraft (forgetting the U-2 or X-15 for the moment).
MAKG
 
Posts: 1156
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast

Re: INS Systems (from Unlimited Wishlist)

Postby flameout » Tue May 12, 2009 10:40 pm

I still don't understand what you mean by integrating analytically. The only way I know is just to repeatedly add up the steps, to keep a cumulative state.

Here is pseudocode for what I am doing: (calculating vertical speed)
Code: Select all
vspeed += vaccel * deltatime;

If there is a more accurate way to do this, please tell me or provide a link to somewhere where I can find it. The only way I can think of doing integrations on paper is getting the exact value of the integral given the integrand, but in this case I do not know the integrand. However, I do know some information about it -- do you mean using the model to somehow more accurately integrate?

Although I'm aiming to keep track of altitude, I wanted to keep track of vertical speed, because I know some instantaneous VSI's use INS information for their vertical speed. However, with the high change in vertical acceleration (vertical jerk?) it is very inaccurate, so for now I am just outputting the actual vertical speed.

Thank you very much.
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 May 13, 2009 4:11 pm

flameout wrote:I still don't understand what you mean by integrating analytically. The only way I know is just to repeatedly add up the steps, to keep a cumulative state.

Here is pseudocode for what I am doing: (calculating vertical speed)
Code: Select all
vspeed += vaccel * deltatime;

If there is a more accurate way to do this, please tell me or provide a link to somewhere where I can find it. The only way I can think of doing integrations on paper is getting the exact value of the integral given the integrand, but in this case I do not know the integrand. However, I do know some information about it -- do you mean using the model to somehow more accurately integrate?

Although I'm aiming to keep track of altitude, I wanted to keep track of vertical speed, because I know some instantaneous VSI's use INS information for their vertical speed. However, with the high change in vertical acceleration (vertical jerk?) it is very inaccurate, so for now I am just outputting the actual vertical speed.

Thank you very much.


No offense, but this is first-week freshman physics.

The uniform-acceleration approximation (which you are clearly using) is

alt = alt0 + vspeed*dt + 0.5*vaccel*dt*dt

But the approximation doesn't work with this case, as vaccel and vspeed drop off substantially with altitude at constant throttle. You could hide the altitude dependence in a differential form (which is what you're trying to do), but then you have a bunch of hard-to-set parameters like stepsize and "joining" changes in acceleration. It's an art, and many of the folks who do this for a living have advanced degrees in applied math.

I still think the best approach by far is to fake it. You don't seem to have the background to do it the "best" way (e.g., Simpson's Rule is not the best way to solve a differential equation, and forward differencing can be shown to be unstable -- i.e., you measure your integration method and not the physics), and the issue in the simulator is to simulate the interface. Besides, you'll use up resources for an answer that is noisier than reality anyway.
MAKG
 
Posts: 1156
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast

Re: INS Systems (from Unlimited Wishlist)

Postby flameout » Thu May 14, 2009 12:53 am

Now that I see how more of the errors come about (and how little I know about the more advanced methods,) I think I may probably switch to just using the lat/lon coordinates to compute its position.

I will change it soon, although I will keep it set up so it will work fine to replace the code with a more realistic method, when I know more or someone else helps.

I can probably just take the difference between the previous and the current position to get average velocity, and use that for computations. Without rounding errors, that should be 100% accurate, but since I am implementing the drift as a constant velocity error, it fits better than just using the lat/lon coordinates alone.

To clarify, here is what I will probably do: (pseudocode again)
Code: Select all
estlat+=(truelat-oldlat)+latdrift
oldlat = truelat
same for longitude


Thank you very much for helping me, but for now it is all lost on me. Eventually, I know I can get it working, however (whatever method I use.)
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 » Thu May 14, 2009 1:09 am

Sorry 'bout that. Integration methods are actually rather interesting IMO, but they have quite a number of subtle pitfalls. Your energy is impressive and your intuition isn't THAT far off the mark -- you're doing things that any reasonably educated but green simulationist might try. It's just that errors do come to bite you. Every numerical analyst has a story like that from their early years (mine was rediscovering that numerical grids have a false viscosity due to the grids themselves, and that can make for some interesting refractions when the grid spacing changes).

And if it helps, lately I've been making a career out of teaching subcontractors how to test and debug numerics properly. It's not easy.

Real FMS's use a method I'll be studying more closely in months to come -- Kalman filters -- to decide how to blend INS and GPS data. I'm toying with the idea of using the same technique to correct global wind predictions given local measurements from a GPS and INS (you can get a complete wind triangle only with both), but I don't understand it well enough to know whether I'm making a desktop problem into a supercomputer problem (I suspect I might be).

I don't know your background; if you're in college, understand your linear algebra (especially! -- it doesn't seem like it at the time, but it's by far the most important math a simulationist can know) and differential equations thoroughly.

As a hint, don't propagate longitude directly. Propagate lon/cos(lat). Or even better, work in Cartesian coordinates and constrain velocity to be tangent to the earth (somewhere I may have a talk on how to do that). A third alternative is to use a quaternion formulation -- great circle segments are thoroughly natural in that -- but that isn't routinely taught in the US even to math or physics Ph.D. candidates (I really don't understand that). The issue is how to cross the north pole without the integrator blowing up.
MAKG
 
Posts: 1156
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast

Re: INS Systems (from Unlimited Wishlist)

Postby flameout » Thu May 14, 2009 2:53 am

I read a little about Kalman filters, as I knew that was how the data was combined. However, the math was way over my head, so I am using a simpler (and more temporary) radio update routine.

Although I'm actually in high school, I'm currently taking math at the college level. Linear algebra 1 was definately a difficult class, but I do see that it has a large number of applications. Until I took it, most of the 3d transformation math in my old "The Black Art of 3d Game Programming" (or something like that) book (from the i386 days) didn't make any sense. Before it, more stuff didn't make sense (another recent one was the dot product used for backspace culling and cross product for normal computations.) I have noticed as more and more of the mathematics in that book make sense.

Even though I read about the problems with the spherical system (there's always points where it can break down, like the poles,) and it even said switching to 3d could solve them, I never actually did think to do that. Until I understand quaternions (they seem to be useful, from the rotation calculations and this,) I will probably switch it over to 3d calculations.

Thank you very much for the suggestions, it is very informative and appreciated. Hopefully, I'll have enough time to implement them soon. I will probably have a lot of time in the summer.
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

PreviousNext

Return to New features

Who is online

Users browsing this forum: No registered users and 2 guests