Hi Stuart, I'm actually trying to implement failures onto a fork of the Lionceau.
http://seb.marque.free.fr/fichiers/flightgear/apm20.tgz (--aircraft=apm20, the official Lionceau needs to be installed) For now it doesn't "create" random or calculated failures, but manage manual failures (the intention is to create failures via an external application or distant instructor). As you've mentionned it looks through .+/serviceable props to know if an instrument fails. I'm sure I'm not clever enough to invent powder, but I've tried a way to manage failures in a transparent way for the pilots using alias/unalias Nasal capacities. Indeed every instrument in the panel is the reflect of a property aliased to the real data as given by the fdm. When a instrument fails, I unalias the property and manage the output calculation with some Nasal code, if necessary (i.e. when the output needs to vary even if the instrument fails, or gives a wrong information even if the system works fine: levels/temps/pressures). This part is still to be done... indeed it is in an early devel stage. I'm also going to try the system too with the rudder, elevator and ailerons properties, it means that the fdm config files need to be modified to use the aliased prop rather than the usual /controls/flight/* ones. This should allow to unalias the props and even if the pilot try to make the controls act, it doesn't have the pilot's expected effect on fdm. BTW in the same fork I've implemented an engine failure when it is used in a non-proper way (more than 5 min full throttle, engine damages calculation above 90% throttle, soon will come oil temp and cht temp, following engine and flight manuals descriptions, see limitations.nas). In order to stop the engine in a more "realistic" manner I use the /engines/engine/out-of-fuel prop allowing engine coughs for a certain amount of time before being complety off without using magnetos (I find ugly to see the magneto switch moving alone in a cokpit :p). For brakes I also use my own implementation of controls.applyBrakes (see actions.nas) which is a kind of failure system to avoid the aircraft to slow down too quickly and is intented to be improved in order to manage wet surfaces and brakes failures. That said, I don't know the cpu cost of using many aliases. I've got a question about your script: what do mean MTBF and MCBF, and what is the purpose of JAM failure? Last point: I think I've found a possible mistake in static system failure with airspeed indicator: indeed I though that with blocked statics (dirty or forgotten flames) and pitot working fine, the indicated airspeed is higher than real airspeed, but actually it seems not to be the case. Indeed the ASI gives some relatively high speed near the ground but falls down to zero quite quickly when climbing, then goes back to a high value at 0ft/mn climbing... I'm maybe complety wrong and the simulated behaviour is correct. best regards seb PS: I found very nice to have a closer look in failures management because this is one of the few "dangers" we have and can simulate, keeping the fun-side of FG and improving pilot-skills entertainment. Stuart Buchanan a ecrit : > Hi All, > > Those of you with long memories may remember some random failure work that > John Denker and I worked on a while ago. For various reasons, this never made > it into CVS. > > Recently, on the FG forum, "erobo" raised interest in this again, and came up > with failure manager with some nice functions. > > I've spent some time reconciling the two approaches, using the MTBF and MCBF > features of John's work, and erobo's idea of an overall "manager". > > The result is available here: > > http://www.nanjika.co.uk/flightgear/failures.tar.gz > > I've done a fair bit of testing on JSBSim aircraft, and a little testing on > YASim. > > Obviously, the instrument failure modes depend on the appropriate instrument > respecting the "serviceable" flag. Note also that "failing" the > ailerons/elevators/rudder currently marks them as read-only, resulting in > various warning messages to the console. I think that Melchior is still > looking at an appropriate solution to this. > > I have identified the following further areas for development, if anyone is > interested: > 1) The engine failure model is very basic - effectively failing the engine > off by switching off the magnetos and setting the cutoff. It might be > interesting to model a stuck throttle/mixture/prop in the same way that the > ailerons/elevators/rudder are currently modeled. > 2) Additional, aircraft-specific failures can be added at runtime to > failures.breakHash. However, I don't currently have a way that these can be > automagically added to the dialogs. > 3) Currently, the correct number of engines is determined in a somewhat > haphazard manner. We should probably do the same for features such as landing > gear and speedbrakes. > > I believe the current patch is ready for review and inclusion in CVS. > Feedback is obviously very welcome :) > > My thanks to John and erobo for their work on this. > > -Stuart > > > > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
