RE: [Flightgear-devel] EasyXML.cxx
I'm not surprised it breaks with malformed XML files.
A suggested fix is below.
if (!input.good()) {
sg_io_exception ex(Problem reading file,
sg_location(path,
XML_GetCurrentLineNumber(parser),
XML_GetCurrentColumnNumber(parser)),
SimGear XML Parser);
XML_ParserFree(parser);
throw ex;
}
--Richard
Has the disposition of this been resolved, yet?
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML.cxx
Jon Berndt wrote:
I'm not surprised it breaks with malformed XML files.
A suggested fix is below.
if (!input.good()) {
sg_io_exception ex(Problem reading file,
sg_location(path,
XML_GetCurrentLineNumber(parser),
XML_GetCurrentColumnNumber(parser)),
SimGear XML Parser);
XML_ParserFree(parser);
throw ex;
}
--Richard
Has the disposition of this been resolved, yet?
It's committed to CVS.
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
On Fri, 2005-09-16 at 04:41 +0100, Lee Elliott wrote:
Hello List,
I think there's a small bug in the moving-average filter in
...
xmlauto.cxx
else if (filterType == movingAverage)
{
output.push_front(output[0] +
(input[0] - input.back()) /
(samples - 1));
unsigned int i;
for ( i = 0; i output_list.size(); ++i ) {
output_list[i]-setDoubleValue( output[0] );
}
output.resize(1);
}
I'm not trying to flame, but why would you be using a moving average
filter? That's the most complicated filter I've ever seen - it calls
other functions! I always liked the simplicity of a low pass filter:
output += (measurement - output) * gain;
Using floats, doubles, or fixed point of course.
No need to call a function either, just in-line it where you need it.
Want fast convergence on startup? Just sweep the gain from 1.0 down to
whatever the steady state value needs to be. I bet this is nothing new -
it's probably in the code under else if (filterType == IIRfilter) or
something.
So why do people use moving average filters? Why does FGFS?
Thanks,
Paul
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Digitrak and three axis gyro
On Wed, 2005-09-14 at 20:35 -0400, Steve Knoblock wrote: The Digitrak is described as employing gyroscopic rate sensors are installed so as to sense motion about each of the major axes (roll, yaw and pitch). I assume they mean there is a spinning gryo around which three sensors are arranged, to sense motion in each axis, pitch, roll and yaw. The sensors report how much the aircraft has moved around the gyro for each axis. Gyroscopic rate sensors measure rotation rate around a single axis with respect to whatever they're mounted on. To measure 3 axis motion requires a minimum of 3 sensors. There are no gimbals or spinning objects (vibrating parts yes). Tracking orientation with them requires integrating the signals in a rotating reference frame. You also need an absolute reference because the integrated signals will drift. Here's something google turned up: http://www.smalltimes.com/document_display.cfm?section_id=76document_id=7451 From what I can see of the various default instruments in FlightGear, the only source of roll angle from an instrument is the attitude indicator or indirectly, the turn coordinator, which the Digitrak does not use. I conclude that to model the Digitrak fully, I would need to create C code to represent this three axis gyro using the gyro.*** code that the attitude indicator depends on. I have a little experience with C, but not much. I nearly understand how the attitude indicator works with the gyro model, but I still have to many questions to comprehend all it is doing. I also assume that using /orientation/roll-angle is the best substitute currently available. I would appreciate any help with this and please correct me if I am wrong in any of this. The only way to really know what the Digitrak is doing is to know what it's really doing ;-) I think the Digitrak would make an interesting contribution to FlightGear. It would, but you may be limited to just a visual representation and some other autopilot code. It would be really hard to know exactly what their software is doing without access to source code. -Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Digitrak and three axis gyro
I don't know how detailed you want to get with the digitrak modeling, but as a first pass, you could just assume that what ever the digitrak is doing, it's keeping a pretty good estimate of reality. If you make that assumption, then you could just use the raw pitch, roll, yaw values from FG and move on to the higher level modeling. As Paul suggests, if you want to really model all the internal sensors, you really have to know exactly what they are, how they are calibrated to some absolute reference, what math is going on behind the scenes, etc. etc. Curt. Paul Kahler wrote: On Wed, 2005-09-14 at 20:35 -0400, Steve Knoblock wrote: The Digitrak is described as employing gyroscopic rate sensors are installed so as to sense motion about each of the major axes (roll, yaw and pitch). I assume they mean there is a spinning gryo around which three sensors are arranged, to sense motion in each axis, pitch, roll and yaw. The sensors report how much the aircraft has moved around the gyro for each axis. Gyroscopic rate sensors measure rotation rate around a single axis with respect to whatever they're mounted on. To measure 3 axis motion requires a minimum of 3 sensors. There are no gimbals or spinning objects (vibrating parts yes). Tracking orientation with them requires integrating the signals in a rotating reference frame. You also need an absolute reference because the integrated signals will drift. Here's something google turned up: http://www.smalltimes.com/document_display.cfm?section_id=76document_id=7451 From what I can see of the various default instruments in FlightGear, the only source of roll angle from an instrument is the attitude indicator or indirectly, the turn coordinator, which the Digitrak does not use. I conclude that to model the Digitrak fully, I would need to create C code to represent this three axis gyro using the gyro.*** code that the attitude indicator depends on. I have a little experience with C, but not much. I nearly understand how the attitude indicator works with the gyro model, but I still have to many questions to comprehend all it is doing. I also assume that using /orientation/roll-angle is the best substitute currently available. I would appreciate any help with this and please correct me if I am wrong in any of this. The only way to really know what the Digitrak is doing is to know what it's really doing ;-) I think the Digitrak would make an interesting contribution to FlightGear. It would, but you may be limited to just a visual representation and some other autopilot code. It would be really hard to know exactly what their software is doing without access to source code. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
On Saturday 17 September 2005 16:43, Paul Kahler wrote: I'm not trying to flame, but why would you be using a moving average filter? That's the most complicated filter I've ever seen - it calls other functions! It calls some of the methods of the deque datatype. I'm sorry! That's the implementation my limited skills came up with. I chose 4 filters from one of my textbooks: Exponential, Double Exponential, Moving Average and Noise Spike. That's what the author of the textbook called them. Both of the exponential filters are IIR filters. I always liked the simplicity of a low pass filter: output += (measurement - output) * gain; Using floats, doubles, or fixed point of course. You are welcome to add this filter (or any other filter that you think might be usefull) to the already existing filters. No need to call a function either, just in-line it where you need it. Want fast convergence on startup? Just sweep the gain from 1.0 down to whatever the steady state value needs to be. I bet this is nothing new - it's probably in the code under else if (filterType == IIRfilter) or something. So why do people use moving average filters? The Scientist and Engineer's Guide to Digital Signal Processing says about the moving average filter that it is the most common filter in DSP, because it's easy to understand and use. It's optimal for reducing random noise, while retaining a sharp step response. http://www.dspguide.com Why does FGFS? The best I can think of is why not? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Determining range?
... how do I get the distance from my current Lat/Long to another Lat/Long? There's a function in SimGear that does this. See SimGear/simgear/math/sg_geodesy.cxx for a function called int geo_inverse_wgs_84() This may be overkill for your application. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
