[Flightgear-devel] PATCH: various fixes and cleanups
Attached are two patches: one for simgear, and one for flightgear.
The changes are mostly minor except for a few fixes to uninitialized
variables found by valgrind. Here's the list of changes:
== Changes in simgear-cleanups.diff:
simgear/misc/props.cxx
* Rearranged member initializers to shut gcc -Wall up
simgear/sky/sky.cxx
* Fixed (un)signed comparison
== Changes in flightgear-cleanups.diff:
src/Autopilot/newauto.cxx
* Fixed uninitialized MaxAileron value (set to 0.5)
src/Cockpit/kr_87.cxx
* Fixed uninitialized values
src/Cockpit/steam.cxx
* Rearranged member initializers to shut gcc -Wall up
src/Input/input.cxx
* Fixed (un)signed comparisons
* Rearranged member initializers
src/Main/viewer.cxx
* Rearranged member initializers
src/Model/model.cxx
* Fixed (un)signed comparisons
src/Sound/fg_sound.cxx
* Rearranged member initializers
Thanks
--
Cameron Moore
[ Where do forest rangers go to "get away from it all?" ]
diff -urN ../FlightGear/src/Autopilot/newauto.cxx ./src/Autopilot/newauto.cxx
--- ../FlightGear/src/Autopilot/newauto.cxx Mon Jul 8 22:59:43 2002
+++ ./src/Autopilot/newauto.cxx Tue Jul 9 01:20:05 2002
@@ -305,6 +305,9 @@
// 25% max control variablilty 0.5 / 2.0
disengage_threshold = 1.0;
+// set default aileron max deflection
+MaxAileron = 0.5;
+
#if !defined( USING_SLIDER_CLASS )
MaxRollAdjust = 2 * MaxRoll;
RollOutAdjust = 2 * RollOut;
diff -urN ../FlightGear/src/Cockpit/kr_87.cxx ./src/Cockpit/kr_87.cxx
--- ../FlightGear/src/Cockpit/kr_87.cxx Thu Jul 4 14:37:06 2002
+++ ./src/Cockpit/kr_87.cxx Tue Jul 9 01:28:59 2002
@@ -76,6 +76,8 @@
need_update(true),
valid(false),
inrange(false),
+dist(0.0),
+heading(0.0),
goal_needle_deg(0.0),
et_flash_time(0.0),
ant_mode(0),
diff -urN ../FlightGear/src/Cockpit/steam.cxx ./src/Cockpit/steam.cxx
--- ../FlightGear/src/Cockpit/steam.cxx Mon Jul 8 22:59:44 2002
+++ ./src/Cockpit/steam.cxx Mon Jul 8 23:56:20 2002
@@ -54,21 +54,22 @@
FGSteam::FGSteam ()
- : the_STATIC_inhg(29.92),
+ :
the_ALT_ft(0.0),
the_ALT_datum_mb(1013.0),
-the_VSI_case(29.92),
-the_VSI_fps(0.0),
+the_TC_rad(0.0),
+the_TC_std(0.0),
+the_STATIC_inhg(29.92),
the_VACUUM_inhg(0.0),
-the_MH_err(0.0),
+the_VSI_fps(0.0),
+the_VSI_case(29.92),
the_MH_deg(0.0),
the_MH_degps(0.0),
-the_DG_err(0.0),
+the_MH_err(0.0),
the_DG_deg(0.0),
the_DG_degps(0.0),
the_DG_inhg(0.0),
-the_TC_rad(0.0),
-the_TC_std(0.0),
+the_DG_err(0.0),
_UpdateTimePending(100)
{
}
diff -urN ../FlightGear/src/Input/input.cxx ./src/Input/input.cxx
--- ../FlightGear/src/Input/input.cxx Mon Jul 8 22:59:50 2002
+++ ./src/Input/input.cxx Tue Jul 9 00:09:26 2002
@@ -403,12 +403,12 @@
// so we can play with it.
if (x != m.x) {
int delta = x - m.x;
-for (int i = 0; i < mode.x_bindings[modifiers].size(); i++)
+for (unsigned int i = 0; i < mode.x_bindings[modifiers].size(); i++)
mode.x_bindings[modifiers][i]->fire(double(delta), double(xsize));
}
if (y != m.y) {
int delta = y - m.y;
-for (int i = 0; i < mode.y_bindings[modifiers].size(); i++)
+for (unsigned int i = 0; i < mode.y_bindings[modifiers].size(); i++)
mode.y_bindings[modifiers][i]->fire(double(delta), double(ysize));
}
@@ -487,7 +487,7 @@
std::cout << "Looking for bindings for joystick \""
<< name << '"' << std::endl;
vector nodes = js_nodes->getChildren("js-named");
- for (int i = 0; i < nodes.size(); i++) {
+ for (unsigned int i = 0; i < nodes.size(); i++) {
SGPropertyNode_ptr node = nodes[i];
std::cout << " Trying \"" << node->getStringValue("name") << '"' << std::endl;
if (!strcmp(node->getStringValue("name"), name)) {
@@ -968,10 +968,10 @@
FGInput::mouse::mouse ()
- : nModes(1),
-current_mode(0),
-x(-1),
+ : x(-1),
y(-1),
+nModes(1),
+current_mode(0),
modes(0)
{
}
diff -urN ../FlightGear/src/Main/viewer.cxx ./src/Main/viewer.cxx
--- ../FlightGear/src/Main/viewer.cxx Wed May 29 20:03:38 2002
+++ ./src/Main/viewer.cxx Tue Jul 9 00:22:18 2002
@@ -132,8 +132,6 @@
// Constructor
FGViewer::FGViewer( fgViewType Type, bool from_model, int from_model_index, bool
at_model, int at_model_index, double x_offset_m, double y_offset_m, double z_offset_m,
double near_m ):
-_scaling_type(FG_SCALING_MAX),
-_fov_deg(55.0),
_dirty(true),
_lon_deg(0),
_lat_deg(0),
@@ -144,11 +142,13 @@
_roll_deg(0),
_pitch_deg(0),
_heading_deg(0),
-_heading_offset_deg(0),
-_pitch_offset_deg(0),
_roll_offset_deg(0),
+_pitch_offset_deg(0),
+_heading_offset_deg(0),
+_goal_pitch_offset_deg(0.0),
Re: [Flightgear-devel] x++ The World's First XML-Based Programming Language
On Monday, July 8, 2002, at 11:23 PM, Jon Berndt wrote: > Just because something *can* be done doesn't mean it *should* be! > > ;-) > > Jon > Actually, I was going to say that it was another solution in search of a problem. >> Subject: [Flightgear-devel] x++ The World's First XML-Based Programming >> Language >> >> FYI >> http://xplusplus.sourceforge.net/index.htm > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FlightGear precautionary landing
> Just out of curiosity, what is the shuttle's approach speed, and can > it recover from a stall? > > David I recall reading that initial flights landed at about 205 mph. This page: http://www-pao.ksc.nasa.gov/kscpao/nasafact/count3slf.htm says that the landing speed is typically now 213 to 226 mph. Heavier orbiter payload bay contents compared to initial flights could make that difference. In any case, as the orbiter rolls onto final, the pilot pushes over to steepen the glide and pick up speed. The glideslope is about 20 degrees at that point. Video from inside the cockpit at that point shows quite a view. As for stall characteristics, I really don't want to hypothesize on this because it would be pure conjecture. I've never seen any treatment of the topic. But, I would guess that it would not be a very good situation, with recovery being extremely difficult at best. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] x++ The World's First XML-Based ProgrammingLanguage
On Mon, 2002-07-08 at 20:52, Norman Vine wrote: > FYI > http://xplusplus.sourceforge.net/index.htm Bring on the significant whitespace! > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] x++ The World's First XML-Based Programming Language
Just because something *can* be done doesn't mean it *should* be! ;-) Jon > Subject: [Flightgear-devel] x++ The World's First XML-Based Programming > Language > > FYI > http://xplusplus.sourceforge.net/index.htm smime.p7s Description: application/pkcs7-signature
[Flightgear-devel] x++ The World's First XML-Based Programming Language
FYI http://xplusplus.sourceforge.net/index.htm ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem with clouds?
Does anyone know why cloud.cxx is putting out: Error: base = 0,-0.00112949 Error: base = 0,0 It's been doing it for a while ... -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] dc3-yasim model
Didn't attach the xml. Dave
[Flightgear-devel] dc3-yasim model
Andy, I put the main gear back at x="-6.02" and added a under the cockpit at 700 lbs and it handles very well. I even did some x-wind take offs and landings. Here the locking tail wheel helps in the initial acceleration. For strong x-winds, I think one uses differential power (and even differential brakes) in the initial acceleration phase until the rudder power kicks in. I like the feel of this configuration. Try the attached "dc3.xml" file. Is it possible to get the actual CG location from yasim for a particular xml file? Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FlightGear precautionary landing
Jon Berndt writes: > Actually, I meant the pre-flare, which occurs at about 1800 ft. agl. This > brings the glideslope from about 20 to less than 2 degrees. That's where > he clobbered me. He was toying with me. The operators had some sense of > humour... Just out of curiosity, what is the shuttle's approach speed, and can it recover from a stall? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Jitterbug pinpointed
David Megginson writes: > >Andy Ross writes: > > > Unless I'm still not understanding you, I think you misunderstand the > > issue. Just adding an offset to the camera is what's already being > > done, and it runs into precision problems. The trick is to >make sure > > that the camera is *never* moved to the scenery centroid before > > rendering the model. Once that 1000m transformation is on >the stack, > > it's too late -- you can't recover precision you've already lost. > >Just to summarize, I think that Andy is recommending that the camera >location *always* be 0,0,0, and that scene graphs be transformed >appropriately for rendering. Is Norm suggesting something different? I guess I have to 'spell out' my hints in their entirety but I am saying the same thing PLUS giving 'hints' as to what part of the code also needs to change. BUT IMHO this is still a suboptimal solution in that it is MUCH easier to just use separate scene graphs as I and others have been 'suggesting' ever since the 'rewrite' was first proposed refactoring-a-graph'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FlightGear precautionary landing
> Jon S Berndt writes: > > > Just as I flared during the last landing he gave me a 100 knot > > tailwind. If there would have been a black box, it would have > > gotten from me only a "What the ... !" before I pancaked in. > > If you were flaring, you were probably close enough to the ground to > survive (i.e. less than 10ft), though with some damage to the shuttle. > Otherwise, I doubt any aircrew could survive a sudden 100kt tailwind > during an approach any fixed-wing aircraft -- I don't know of any > plane that approaches at more than 100kt above its stall speed. Actually, I meant the pre-flare, which occurs at about 1800 ft. agl. This brings the glideslope from about 20 to less than 2 degrees. That's where he clobbered me. He was toying with me. The operators had some sense of humour... Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] Jitterbug pinpointed
Andy Ross writes: > > Just adding an offset to the camera is what's already being >done, and it runs into precision problems. The trick is to make sure >that the camera is *never* moved to the scenery centroid before >rendering the model. Right --- So why not leave the camera at 0,0,0 and add an additional offset to the 'tile-offset' Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jitterbug pinpointed
Andy Ross writes: > Unless I'm still not understanding you, I think you misunderstand the > issue. Just adding an offset to the camera is what's already being > done, and it runs into precision problems. The trick is to make sure > that the camera is *never* moved to the scenery centroid before > rendering the model. Once that 1000m transformation is on the stack, > it's too late -- you can't recover precision you've already lost. Just to summarize, I think that Andy is recommending that the camera location *always* be 0,0,0, and that scene graphs be transformed appropriately for rendering. Is Norm suggesting something different? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear precautionary landing
Jon S Berndt writes: > Just as I flared during the last landing he gave me a 100 knot > tailwind. If there would have been a black box, it would have > gotten from me only a "What the ... !" before I pancaked in. If you were flaring, you were probably close enough to the ground to survive (i.e. less than 10ft), though with some damage to the shuttle. Otherwise, I doubt any aircrew could survive a sudden 100kt tailwind during an approach any fixed-wing aircraft -- I don't know of any plane that approaches at more than 100kt above its stall speed. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Failures and Instrumentation
Andy Ross writes: > This could actually be done with minimal C++ code. Picture a "failure > manager" that walks a property tree under "/failures". For each > child, it reads a "mtbf-sec" property and sets the "working" boolean > with a random probability that corresponds to the failure rate. This > is maybe a few tens of lines of C++. I was picturing something a little different. Every component has its own failure flag, and we register the failure properties and MBEF with the failure manager. On that note, I've been thinking about how to rework the instruments, and here's what I have so far. We create a new src/Instrumentation/ directory with subsystems for each instrument or instrument group (such as pitot-static or vacuum-driven gyros), copying most of the code out of the existing steam.cxx where possible. This subdirectory, though, could also hold custom code for GPS's, transponders, weather radar, etc. etc. In the property tree, we set up a root /instrumentation/ branch. Inside this, we have /instrumentation/altimeter/ /instrumentation/airspeed-indicator/ /instrumentation/vor-gauge/ /instrumentation/transponder/ etc., with indexes as appropriate. Inside each branch, we have a collection of properties, some common to many (or all) instruments, and some specific to individual instruments: /instrumentation/altimeter/servicable /instrumentation/altimeter/error-pct /instrumentation/altimeter/reading-ft /instrumentation/altimeter/setting-inhg error-pct would be a percentage error independent of the altimeter setting, static port issues, and so on -- instructors could play with it just to mess with students' minds. servicable would be a flag on every instrument for enabled/disabled. We would also have a /systems/ branch for the various aircraft systems, like the static-pitot system: /systems/static-port/obstruction-pct /systems/pitot-tube/obstruction-pct /systems/air-intake/obstruction-pct /systems/pitot-heat/servicable Obviously, it will take time to implement all of this, but at least we'd have a place to put all of it. Engines are important enough systems that they deserve they own branch, of course. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Jitterbug pinpointed
Andy Ross writes: >Norman Vine wrote: >> I guess I wrongly assumed that everyone would read this as "just add >> the appropriate offset to move the camera to the origin" :-) > >Unless I'm still not understanding you, we do seem to have a communication gap :-) not-all-M$oft-users-use-the-gui'ly yours Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jitterbug pinpointed
Norman Vine wrote: > I guess I wrongly assumed that everyone would read this as "just add > the appropriate offset to move the camera to the origin" :-) Unless I'm still not understanding you, I think you misunderstand the issue. Just adding an offset to the camera is what's already being done, and it runs into precision problems. The trick is to make sure that the camera is *never* moved to the scenery centroid before rendering the model. Once that 1000m transformation is on the stack, it's too late -- you can't recover precision you've already lost. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Jitterbug pinpointed
Andy Ross writes > The right solution (ignoring orientation, which is >fine as-is) is this: > >Move 0m in the camera > Move +1000m >Draw the terrain > Move ~1m to the aircraft origin >Draw the cockpit Indeed ... which is why I pointed out 'where' in the code it was easiest to do this > To experiment I believe all you should have todo is change the > value for 'center' in prep_ssg_node( vis, up, center ); > in tilemngr.cxx to reflect the 'offset' you want. I guess I wrongly assumed that everyone would read this as "just add the appropriate offset to move the camera to the origin" :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear precautionary landing
On Mon, 8 Jul 2002 16:54:12 -0500 (CDT) "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: >However, we would also need to be able to turn off the auto-failure >generation module and allow an instructor (or a script) have complete >control over the failures. This way an instructor could use the sim >to train for specific failure scenarios and have complete control over >when, where, and what happens. For shuttle training, the instructors have scripts, but they still enter the mals by hand. Also, pretty much any sim variable can be accessed and changed by hand. The functionality to change a set of variables and then have them take effect at a particular time is also there. For a complex machine like the space shuttle, malfunctions are often not the product of simply turning on or off a boolean (although many are). Some are so complicated that they cannot really be programmed, but can give the correct "symptoms" if an instructor has the power to do as he can in the shuttle mission simulator and access any variable. The ability to access any variable (perhaps via the property tree) could open up a whole range of surprise training scenarios. This was demonstrated to me (and Curt, you may have seen something similar in your encounters with "real" commercial training sims) on a session where I was testing some changes I had made in the shuttle sim code at Johnson Space Center. I had made a series of nice landings (OK: "survivable" landings) in the shuttle simulator early one morning in testing my code when the operator thought I was getting a bit cocky. Just as I flared during the last landing he gave me a 100 knot tailwind. If there would have been a black box, it would have gotten from me only a "What the ... !" before I pancaked in. When I worked F-16 FCS modeling we had failures like CADC failures (air data computer), stuck switches, etc. Some of the failures we might want to eventually model might involve simulating sensors - i.e. right now we assume we are getting air data, rates, velocities, etc. as-is from the FDM. If we get a bad sensor it might read 0.0, or stick at a value, or something else depending on the associated electronics. I wonder if we might need to model a sensor class someday. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear precautionary landing
Andy Ross writes: > This could actually be done with minimal C++ code. Picture a "failure > manager" that walks a property tree under "/failures". For each > child, it reads a "mtbf-sec" property and sets the "working" boolean > with a random probability that corresponds to the failure rate. This > is maybe a few tens of lines of C++. > > So each failure system then sets something like > "/failures/static-pressure/mtbf" to 10 in an initialization file. > And the relevant system (the ASI and altimeter, in this case) just > checks the value of "/failures/static-pressure/working". Most of this > can be done using the existing property conditions as-is. A few > failure modes (engine failures, maybe) might require FDM intervention, > but most are just of the "turn off the gadget" form. I would agree that it makes sense to just load up the failure status into a subtree in our property system, and then the modules that impliment the various items would need to check the failure status and also impliment failure modes in addition to implimenting correctly working behavior. We could have a separate system that tries to impliment realistic failure rates ... that could be cool for the general default behavior if the failure rates were indeed realistic. However, we would also need to be able to turn off the auto-failure generation module and allow an instructor (or a script) have complete control over the failures. This way an instructor could use the sim to train for specific failure scenarios and have complete control over when, where, and what happens. Here's where scripting could be useful to reduce the interactive load on the instructor ... and would allow the instructor to impliment more insidious and 'ill timed' failures. >From what I've seen, instructors take great pleasure in maximizing the pain of their student (so to speak.) :-) But the flip side of this is that if the student can learn to handle the worst case scenarios, then hopefully they'll be well trained to handle more typical emergencies. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jitterbug pinpointed
Curtis L. Olson wrote: > I haven't been following this thread as closely as I should have been, > but there should be no reason why we'd need to have the camera in the > scene graph. I think we just need to be smarter about how we > structure the transforms. That was my original suggestion: put the camera origin at the viewpoint, and insert one ssgTransform node on top of the terrain that moves it to the tile centroid, and another above the model that moves it to the model origin. The camera business came up because I suggested that this sort of mistake is very easy to make with the camera living outside of the scene graph. The proof: Jim (no slouch as a 3D programmer) didn't realize that the bug still applied in cockpit mode, even though the model was in its own scene graph. The fact that the camera lives separately from the graph is, IMHO, a mistake. But it's tangential to the bug. > There's nothing magical about having multiple scene graphs vs. one > scene graph, in the end you still get basically the same set of > opengl primitives. True, but the more special rules there are (e.g. cameras aren't the same thing as ssgTransform nodes), the less obvious the set of OpenGL primitives that will be generated is. No one would ever think to do the following in OpenGL: Move +1000m Draw the Terrain (>~100m from the viewpoint) Move -1000m Draw the Cockpit (>~0.1m from the viewpoint) But that's exactly what happened to us. It happened because the two "move" lines are not implemented the same way -- the first happens in ssgSetCamera, the second is an ssgTransform node at the top of the model scene graph. The right solution (ignoring orientation, which is fine as-is) is this: Move 0m in the camera Move +1000m Draw the terrain Move ~1m to the aircraft origin Draw the cockpit Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] spacegear.org
For those that might be interested I just wanted to point out the creation of a new open source (space) flight simulation project. http://www.spacegear.org/ At this point there is no direct code relationship with FlightGear, but they are in the very early stages of bringing their project up to speed. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear precautionary landing
Curtis L. Olson wrote: > But to your other point, I agree that we should start looking into > failure modes. This is one big un-addressed issue. I could make up a > list of interesting failure modes if anyone was interested. This could actually be done with minimal C++ code. Picture a "failure manager" that walks a property tree under "/failures". For each child, it reads a "mtbf-sec" property and sets the "working" boolean with a random probability that corresponds to the failure rate. This is maybe a few tens of lines of C++. So each failure system then sets something like "/failures/static-pressure/mtbf" to 10 in an initialization file. And the relevant system (the ASI and altimeter, in this case) just checks the value of "/failures/static-pressure/working". Most of this can be done using the existing property conditions as-is. A few failure modes (engine failures, maybe) might require FDM intervention, but most are just of the "turn off the gadget" form. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear precautionary landing
Curtis L. Olson writes: > I've never, ever seen this problem (and I'm not lying my butt off > about this like some software vendors I currently have to deal with.) > But if you observe this happening again, you might double check that > you didn't inadvertantly activate the wing leveler or heading hold or > waypoint follower ... that would be one non-bug explanation for what > you describe. I'll bet that was it. The autopilot wasn't visible on the screen, so I didn't see anything activated. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear precautionary landing
David Megginson writes: > I was testing some aero changes by flying in mouse mode (which is > easier than pulling out the yoke and clamping it onto my desk) when > something went wrong -- suddenly, the mouse would no longer control > the ailerons, though it still controlled the elevators. I was off > from the runway and heading for some forest, so I added power slowly > (to avoid yaw), overflew a small river, then did a soft-field landing > in some grass on the far side. > > This was a program bug (which I'll try to hunt down later), but it is > also a strong encouragement for us to start adding proper failure > modes to FlightGear. Instruments and radios do stop working, control > surfaces do jam, and engines do fail, though thankfully such events > (except for the first set) are extremely rare in real life. I've never, ever seen this problem (and I'm not lying my butt off about this like some software vendors I currently have to deal with.) But if you observe this happening again, you might double check that you didn't inadvertantly activate the wing leveler or heading hold or waypoint follower ... that would be one non-bug explanation for what you describe. But to your other point, I agree that we should start looking into failure modes. This is one big un-addressed issue. I could make up a list of interesting failure modes if anyone was interested. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jitterbug pinpointed
Andy Ross writes: > Which is a good point in theory. Their basic idea is that the scene > graph specifies data, and you "interpret" that data via a camera. > These are two well-defined and separate areas, and should be kept > separate in code. > > The problem is that this leads naturally to precision problems exactly > like our jitter -- you can't just push transforms onto the matrix > stack willy nilly (in this case, moving ~1.0e+07 cockpit-pixels away > and coming back) and expect things to work nicely. These are finite > computers, and they have finite precision. > > Sure, it's cleaner in principle to have all the scene data separated > from the camera data, but until we have arbitrary-precision GPUs these > two halves need to coordinate so they don't step on each others toes. I haven't been following this thread as closely as I should have been, but there should be no reason why we'd need to have the camera in the scene graph. I think we just need to be smarter about how we structure the transforms. Someone mentioned that currently we have a transform for part of the scene then for the model we have a transform that undoes part of the original transform??? It seems like that could be restructured to avoid those sort of numerical problems. The scene graph is just a convenient way to hold geometry data. There's nothing magical about it, it just gets translated into a big bunch of opengl primitives when we call ssgCullAndDraw(). There's nothing magical about having multiple scene graphs vs. one scene graph, in the end you still get basically the same set of opengl primitives. The advantage to splitting up a scene into separate trees is that it allows you to do things in between rendering sections of your scene. This is mostly an 'optimization' or 'perfomance' issue. We put light points in a separate tree so that we can change fog and other global parameters once before rendering all the lights. Otherwise we'd have to do this via call backs, but since call backs can only be attached to leaf nodes, we'd have to change state before each lighting leaf node, and reset it back after each one which would be much less efficient. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dc3-yasim model
Semi-related ... I was watching a PBS show yesterday called 'chasing the sun.' They had a portion on the development of the dc-3. Apologies if I have the name wrong, but I think it was Pan-Am that drove the specification that the DC-3 was designed to fill. One of the main factors was safety, and coming from a recent ford tri-motor crash that was attributable to a wing full of dry-rot, they wanted an all aluminum design. Going along with the safety theme, they wanted to demonstrate that the aircraft could be operated safely on one engine only. So, they devised a test where they were to take off from Winslow, AZ, cross the rockies mtns, and land someplace further east using only one engine the entire flight. I imagine if you have to be quick on the rudders with both engines, you probably have to be even more focused with only a single engine. They decided to idle the other engine the entire flight for safety reasons so they could kick it in if they started to get into trouble. Anyway, the copilot (who worked for Pan-Am) unexpectedly killed the 2nd engine soon after take off arguing that he worked for the customer and he wanted this to be a 'real' test. After a 'what the hell was that for look' the pilot recovered and continued on. It turned out that the prototype passed this test with flying colors and things proceeded from there. Regards, Curt. Andy Ross writes: > Dave Perry wrote: > > Attched find an xml file "dc3.xml" that includes edits that allow > > accelleration on the main gear and relativly easy wheel landings. > > With these changes, I can leave the tail wheel unlocked for take-off > > and landings. > > Very cool. I'll try it as soon as I get home. > > > 3. I moved the main gear back to 6.9 (from 6.02). This had a very > > big effect and enables getting the tail up and accelerating on the > > mains. Without this, no matter what I did, by the time the tail came > > up, I had already set up the porpoise. Same on wheel landings. > > This is the only one I worry about. While the other tunables > inherently involve some guesswork, the position of the wheels is, er, > Physical Truth. :) > > While it's entirely possible that I mismeasured the location on the > 3-view I was looking at, this is the sort of thing that in principle > can be made exactly correct. It shouldn't require tuning. There's > also the issue of synchronicity with the 3D model -- we want the > position of the wheels in the FDM to match what the user sees on the > screen. > > Instead, what you might try is to move the c.g. forward by the same 88 > cm by adding tags. What these do is to place the specified > amount of the aircraft's empty weight at the location, instead of > allocating it to the wing and fuselage elements. The DC-3 doesn't > have any, but most of the tricycle models do -- they tend to tip over > backwards using the default weighting; tail draggers have a much > larger tripod to sit on. > > Andy > > -- > Andrew J. RossNextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FlightGear precautionary landing
I was testing some aero changes by flying in mouse mode (which is easier than pulling out the yoke and clamping it onto my desk) when something went wrong -- suddenly, the mouse would no longer control the ailerons, though it still controlled the elevators. I was off from the runway and heading for some forest, so I added power slowly (to avoid yaw), overflew a small river, then did a soft-field landing in some grass on the far side. This was a program bug (which I'll try to hunt down later), but it is also a strong encouragement for us to start adding proper failure modes to FlightGear. Instruments and radios do stop working, control surfaces do jam, and engines do fail, though thankfully such events (except for the first set) are extremely rare in real life. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jitterbug pinpointed
Norman Vine wrote: > Following is IMHO a good explanation as to why having the camera a > node in the scene-graph is not 'necessarily' a 'good idea' Which is a good point in theory. Their basic idea is that the scene graph specifies data, and you "interpret" that data via a camera. These are two well-defined and separate areas, and should be kept separate in code. The problem is that this leads naturally to precision problems exactly like our jitter -- you can't just push transforms onto the matrix stack willy nilly (in this case, moving ~1.0e+07 cockpit-pixels away and coming back) and expect things to work nicely. These are finite computers, and they have finite precision. Sure, it's cleaner in principle to have all the scene data separated from the camera data, but until we have arbitrary-precision GPUs these two halves need to coordinate so they don't step on each others toes. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS not working
"Curtis L. Olson" wrote: > > Julian Foad writes: > > The CVS server is not working for me at the moment. It was working > > 10 hours ago when I last tried it. > > > > $ cvs diff > > cvs [diff aborted]: recv() from server cvs.flightgear.org: EOF > > Seems to be working for me at the moment. Yes, it's back again for me too. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Jitterbug pinpointed
Andy Ross writes: > >Jim Wilson wrote: >> I can see what you are saying...but the aircraft (in the cockpit view) >> is actually a different scene graph. > >But it's under the same camera (oddly, ssg puts the global camera >"outside" the graph, when it's logically the top-level node of the >graph), and has the same double-transform problem; it just doesn't >happen to use the terrain frame for anything. Where the camera 'resides' with respect to the scene-graph can be confusing Following is IMHO a good explanation as to why having the camera a node in the scene-graph is not 'necessarily' a 'good idea' Note this discussion was on the Open Scene Graph list and is not about the SSG camera but the principals discussed are exactly the same Norman > My research group has started using OpenSceneGraph recently. One thing > that I don't understand is why the camera is not in the scene graph. Having a camera node as part of the scene graph seems natural to some engineers, alien to others. The former in general come from an Inventor type scene graph background, the later from a Performer type scene graph background. Personally I have no strong opinions, I see both approaches as being useful, but I think requiring a camera as part of the scene graph to use the scene graph would be bad design, as would not be flexible enough for many users. To define your view in the OSG all you need is a projection matrix and modelview matrix. How you generate these is up to the programmer. The osg::Camera exists to encapsualate some of the set up of these matrices, but it purely an optional extra these days. This is a *really* good thing, as it allow users to write their own camera code, or integrate it with pre-existing camera code with minal effort. To have a camera node is a scene graph poses some interesting questions, especially when you can share subgraph such as you can do in the OSG. Consider adding a camera node to the the head of soldier in the turret of a tank, the head can move, the turret can move and the tank can move. This implies a hierachy of transform nodes, the leaf node being the camera node. To render the view from the soldier, first we have to work out the modelview matrix to do this we have to invert this accumulated transform. This should is not difficult, but might not be unique as the OSG allows you to have multiple parents. For example, the tank might be instanced 100 times a battle field, which tank do you choose? To resolve this you need to specifiy a unique path from the root of the scene graph being viewed to the leaf camera node. This path would be naturally tied to the view, rather than the camera node. If you take another step, if you need this unique path in your view then the camera node itself could just be a normal OSG node, as its the accumulated transforms which define the modelview matrix, not the camera node. One might use the camera node to store a local transformation to multiple the modelview matrix by, but for this you might as well just use a standard osg::Transform. One can of course add more data into a camera, such as projection details, but these depend up the viewport dimensions/aspect ratio, so a much more closely tied to the view of the scene, rather than a specific node in the scene graph. Clearly it isn't entirely natural for a camera to be part of scene, although the concept of camera platform, something to position a camera view is useful, but in the end the really important thing is to get the path to the camera platform. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dc3-yasim model
Dave Perry wrote: > Attched find an xml file "dc3.xml" that includes edits that allow > accelleration on the main gear and relativly easy wheel landings. > With these changes, I can leave the tail wheel unlocked for take-off > and landings. Very cool. I'll try it as soon as I get home. > 3. I moved the main gear back to 6.9 (from 6.02). This had a very > big effect and enables getting the tail up and accelerating on the > mains. Without this, no matter what I did, by the time the tail came > up, I had already set up the porpoise. Same on wheel landings. This is the only one I worry about. While the other tunables inherently involve some guesswork, the position of the wheels is, er, Physical Truth. :) While it's entirely possible that I mismeasured the location on the 3-view I was looking at, this is the sort of thing that in principle can be made exactly correct. It shouldn't require tuning. There's also the issue of synchronicity with the 3D model -- we want the position of the wheels in the FDM to match what the user sees on the screen. Instead, what you might try is to move the c.g. forward by the same 88 cm by adding tags. What these do is to place the specified amount of the aircraft's empty weight at the location, instead of allocating it to the wing and fuselage elements. The DC-3 doesn't have any, but most of the tricycle models do -- they tend to tip over backwards using the default weighting; tail draggers have a much larger tripod to sit on. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] dumb suggestion
David Megginson <[EMAIL PROTECTED]> said: > Norman Vine writes: > > >globals->get_model_mgr()->draw(); > >globals->get_aircraft_model()->draw(); > > That's mostly dead code. FGModelMgr::draw is now a no-op and should > be removed (Jim?): > Yes, I noticed that but didn't remove. Was focusing on something else. Actually I'm not sure that it ever did anything, it goes back to when you split the code out in order to support non-ac models. In any case we wavered back and forth on using a separate root for the cockpit. As far as I'm concerned it can go. For the aircraft model, more than likely we should not have a draw there either, but eventually should just update a pointer to a rendering class that contains an array of ssgroots in the order they get drawn or something like that. I think we can also do pre-draw call backs per ssgRoot that would take care of any changes that need to be made between cullanddraw's. Norman, the FGRender() has pretty much remained unchanged, especially in terms of anything that would affect lighting. The aircraft model draw() is an addition and I think a tilemgr update was moved out of it. Pretty much everything else is what has been there for a good many months (since I first looked at it last fall or so). The lighting problem has been there a while as well. It kind of needs to be a addressed with more than just a patch, as we do need to improve the 3d cockpit lighting and night time ground visibility. Also the daylight lighting isn't all that realistic. Maybe it is because the light adjustment does not account for the dilation of the pupils (which would decrease the apparent difference in light between say Noon and 4pm). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
