On 01/14/2009 09:49 PM, Alex Perry wrote: > Laser gyros do indeed behave the way that the wiki page describes. > Mechanical gyros, such as you find in light aircraft, have other drift > sources that are considerably larger than the diurnal one. And, since > the aircraft tend not to move far from their home latitude, there is > an attempt by mechanics to adjust the gyro for zero net drift rate (on > average).
I think there are at least three issues on the table: a) Apparent temporal wander (d/dt) [called "diurnal" above] b) Apparent transport wander (d/dφ) c) Actual erratic drift. > The purpose of implementing the drift in FlightGear is for operational > realism, more than scientific accuracy, and therefore the drift value > is designed to make the gyro compass be inaccurate if the light > aircraft pilot does not reset it regularly. That's mostly about talking about item (c). Actually, in the existing code, the drift rate is carefully calculated to be equal to the earth's rotation rate. It's not some wild guess that "5 degrees every 20 minutes is about right". The hypothesis that it is a buggy attempt to account for temporal wander is very much alive. Meanwhile, there is no attempt to model transport wander, as you can verify by looking at the code and/or by flying over the pole. If you want to fly the stock c172p this time of year, I suggest flying over the _south_ pole since there are still no interior lights or instruments lights in the c172p. If you fly over the pole, the heading indicator card spins 180 degrees in a fraction of a second. It's hilarious. > If you want to include > the sin(lat) term, be sure to add a flag so we can distinguish between > the laser and mechanical variants. a) It would be easier -- and much better -- to include the sin(lat) term and then to include a latitude-nut property which could be set appropriately. Then anyone who wanted to null out the (d/dt) term could do so ... and could also properly model the effects of taking the aircraft away from its native clime. b) As for transport wander, rather than keeping track of the "heading" of the gyro, as is done now, it would be much nicer to keep track of the physics. I'm hoping this would be pretty easy. Keep track of the gyro axis as a vector in x,y,z space, and project it on to the axes of the aircraft, and voilà! Can some FDM guru tell me how to obtain the quaternions and/or the vectors that specify aircraft orientation? I see lots of examples where instruments etc. refer to the Euler angles (yaw, pitch, and roll) but not much in the way of quaternions or vectors. I found some code in Main/viewer.cxx that constructs quaternions from yaw, pitch, and roll, but that's ugly and not the sort of thing you would want to do near the poles. It also requires calling a passel of transcendental functions at frame rate. JSBSim has a thing called GetTec2b which looks promising, but the other FDMs don't, not by that name anyway, which means instruments shouldn't depend upon it. **** Should we perhaps add this to the incipient FDM spec? **** c) Modeling the erratic drift by a constant rate is adequate for some purposes, but it would be more fun to make the erratic drift more, well, erratic. In Real Life it is sensitive to pitch and bank angles ... so during cruise you get complacent and start trusting the gyro, but then when you start maneuvering during the approach, it goes to pot. The magnitude of the erratic drift should be controlled by a parameter ... not by a compiled-in constant that pretends to be a constant of nature. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
