[Flightgear-devel] YASim solution solution?
OK, I *think* I have nailed the platform-dependant YASim solution failures. What I found was that the solution heuristics hid a bunch of pseudo-chaotic instabilities that were introduced when the approach elevator trim feature went in a few weeks back. This was deterministic, but weird -- increasing the value of a parameter by a tiny amount could throw the solution into an oscillation. Since tiny differences in calculation results ncould (I suppose...) be due to compiler differences, I'm willing to believe this was the culprit; the older gcc had a rounding mode bug or somesuch that caused the solver to pick up on a different oscillation mode. I validated with a command line YASim compiler that the results generated by 2.95.2 were identical to those from 2.96. Unfortunately, my FlightGear 2.95.2 build has begun crashing while loading tiles, so I can't test that until tomorrow. Anyway, try the new code and see if that works for you. You'll also want new planes, as some of the old ones went pretty wacky once the fix went in: http://www.plausible.org/andy/yasim-aircraft-052902.tar Hopefully we can bury this one. 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] Recent observations
I finally had some time to play around with FG the other day (first time in a few weeks), so let me preface all of this with the fact that I'm not running the latest CVS. Mine is from May 18th. I don't have time to update and rebuild everything right now, so sorry. Now, on with the bugs... When in the tower view and the aircraft goes through a cloud layer, the tower view gets "clouded." It looks like we are using the FDM altitude to draw the cloud fog but should be using the current view altitude. Another problem I ran in to was that when starting at KHAF and cycling to the tower view, all hell breaks loose. The first time I got a fatal error trying to load a bogus tile. Subsequent tries just made the aircraft (default c172) bounce about 50 ft into the air. So, I repeated this in different FDMs and got this: - JSBSim weird bouncing around - YASim freezes - LaRCSim weird bouncing and hovering around - UIUC doesn't seem to be working in my build (falls through ground) - UFO works fine And finally, while testing the above, I always got segfaults trying to Restart. I think someone already mentioned this, so it may be fixed already. Thanks -- Cameron Moore $\="Hacker";$,="another ";print"Just ","Perl "; ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim and 2.95.2 math (was: Rudder invertedagain in yasim)
On Tue, 2002-05-28 at 19:30, Jim Wilson wrote: > Tony Peden <[EMAIL PROTECTED]> said: > > > Just something to file away ... big jets should have a climb mode in > > which the power is regulated to max climb by the autothrottles and speed > > is held with the pitch control. > > Filed it away. But not sure of the purpose of this mode. It'd seem that > pitch control should just hold the selected pitch angle, with the exception of > leveling off gradually when a preset altitude is reached. FlightGear's > current autopilot (that uses pitch to maintain max climb) would be very > uncomfortable to ride in...even if it was smoothed. I suppose one advantage > of a mode like you describe would be to prevent stalls even if the crew falls > asleep. It's just speculation on my part, but I figure several things play into that. Best climb is usually published in the form of a speed, not an angle. Also, that speed is usually above 250 knots for a jet, so you dial in 250 until you get to 10k (at least here in the US) then dial it up to best climb. Also, the same mode will work for descent as well as climb. On top of all that, speed is just more convenient since ATC instructions are given in terms of speed. > > Best, > > Jim > > ___ > 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] Yasim and 2.95.2 math (was: Rudder inverted againin yasim)
> > Just something to file away ... big jets should have a climb mode in > > which the power is regulated to max climb by the autothrottles and speed > > is held with the pitch control. > > Filed it away. But not sure of the purpose of this mode. It's more efficient as follows ... The autothrottle does its very best to get as much power as possible (given operational limits) from the engine. This will vary from flight to flight, as well as between engines. Maximum rate of climb is achieved when excess thrust beyond that needed to overcome drag is maximized. Since thrust is mostly speed invariant for the climb regime (so I gather), this really means minimizing drag. For a given aircraft configuration, there is a specific airspeed that minimizes drag, and is the _basis_ for Vy. Thus, we adjust pitch to whatever value is needed to maintain that optimal airspeed. ... it's no different from what pilots do manually ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim and 2.95.2 math (was: Rudder inverted again in yasim)
Tony Peden <[EMAIL PROTECTED]> said: > Just something to file away ... big jets should have a climb mode in > which the power is regulated to max climb by the autothrottles and speed > is held with the pitch control. Filed it away. But not sure of the purpose of this mode. It'd seem that pitch control should just hold the selected pitch angle, with the exception of leveling off gradually when a preset altitude is reached. FlightGear's current autopilot (that uses pitch to maintain max climb) would be very uncomfortable to ride in...even if it was smoothed. I suppose one advantage of a mode like you describe would be to prevent stalls even if the crew falls asleep. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: ..why C++ and not C?
On Monday, May 27, 2002, at 04:43 PM, joe mangan wrote: Standards for application to general aviation aircraft have been revised as to reduce the burden for certification of specific classes of avionics equipment. AC 29-1309 An alternative would be to consider an effort to certify FlightGear as a Flight Training Device under AC 120-45A Jonathan, what is your day job ? Software engineer developing Avionics software for both military and commercial applications. Primarily, I lead the work on our host-based simulation environment, but I have also worked on our level A certified LAN. Joe Mangan
RE: [Flightgear-devel] Re: channel_options_list - starting FGFS with HTTPd-Server
I'm currently working on a web-based TreeViewer for the Property-Tree which loads nodes and values dynamically. Hope that anybody (except me) has use for it ... georg -Original Message- From: Melchior FRANZ [mailto:[EMAIL PROTECTED]] Sent: Dienstag, 28. Mai 2002 23:42 To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Re: channel_options_list - starting FGFS with HTTPd-Server * Curtis L. Olson -- Tuesday 28 May 2002 23:35: > Melchior FRANZ writes: > > * Curtis L. Olson -- Tuesday 28 May 2002 23:22: > > > Melchior FRANZ writes: > > > > $ w3m http://localhost:5500/ > > > fgfs --jpg-httpd=5501 > I don't believe a default is specified or defined, you can use which > ever ports you prefer. Ahh, sorry, of course. I missed the "jpeg" and meant you wanted to correct the 5500 for the httpd. I used to use the port numbers that were mentioned in some documentation long ago, and accepted these as a kind of standard, although they are in fact meaningless. sorry m. :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: channel_options_list - starting FGFS with HTTPd-Server
* Curtis L. Olson -- Tuesday 28 May 2002 23:35: > Melchior FRANZ writes: > > * Curtis L. Olson -- Tuesday 28 May 2002 23:22: > > > Melchior FRANZ writes: > > > > $ w3m http://localhost:5500/ > > > fgfs --jpg-httpd=5501 > I don't believe a default is specified or defined, you can use which > ever ports you prefer. Ahh, sorry, of course. I missed the "jpeg" and meant you wanted to correct the 5500 for the httpd. I used to use the port numbers that were mentioned in some documentation long ago, and accepted these as a kind of standard, although they are in fact meaningless. sorry m. :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: ..why C++ and not C?
On Tue, 28 May 2002 09:06:35 -0700 (PDT), Alex Perry <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > > On Sat, 27 Apr 2002 01:57:09 -0500 Jonathan Polley wrote > > >When you state your concerns about the FAA, I assume that you are > > >talking about avionics software, probably DO-178B level C or > > >higher. > > FlightGear is a combination of an aircraft FDM, a GIS database and a > 3D GUI. When placed into an aircraft, I don't see any benefit in using > our FDM since we would be accepting a data feed from the aircraft in > --fdm=external. ..reasons could be to help _predict_ flight dynamics _situations_, to optimize cruise performance, and for new experimental aircraft, help record flight data. Comparing fdm data against the actual aircraft, also provides early warnings of failures. ..FDM data can also help provide accident data, and using radiolinks or some such, communication of these between aircraft can prevent accidents. ..in traffic, this can help _route_ traffic and advice pilot of traffic conflicts, possibly advicing of an evasion route or manouver. ..midairs and near misses happen for one reason, mens failure. > Given that scenario, the remaining GIS and GUI components are only > providing a way to interpret the data feed and, in themselves, cannot > affect the acft. Providing the FGFS GUI is advisory and not a primary > instrument, most of the requirements go away and we're in the same > situation as all those moving map displays that are essentially a tiny > Windows NT computer with LCD screen. > > > An alternative would be to consider an effort to certify FlightGear > > as a Flight Training Device under > > AC 120-45A > > What do you seek to gain from that ? FTDs are required to have a > physical instrument panel and cockpit and a separate instructor > console. The visual display, which we're so proud of, is optional and > the FDM can be minimal. ..picture a semi-transplarant "tunnell tube", "to fly out of throuble thru". -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Virus with humor
On Dienstag, 28. Mai 2002 19:22 Christian Mayer wrote: > Just got that Virus. Look at the "From:" and it's text... It's the good ole klez worm. Gode save Linux ;) Martin -- [EMAIL PROTECTED] http://www.martinhenne.de ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim and 2.95.2 math (was: Rudder invertedagain in yasim)
On Tue, 2002-05-28 at 09:21, Jim Wilson wrote: > Alex Perry <[EMAIL PROTECTED]> said: > > > Andy: > > One thing to consider is whether the autopilot is optimizing for > > the correct solution to the equations. > > Basically the autopilot just targets the max climb/descent rate until desired > altitude is reached. It needs work. The current autopilot doesn't hold a > pitch or a throttle/power/speed setting...so you can see it is quite easy to > create a stall situation. Just something to file away ... big jets should have a climb mode in which the power is regulated to max climb by the autothrottles and speed is held with the pitch control. > > The problem I'm seeing is actually observable without the autopilot. The > autopilot was just being used as a reference point to describe the bug so it > can be reproduced (as opposed to manual flight where I could have just had the > trim screwed up). > > Best, > > Jim > > ___ > 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
[Flightgear-devel] [SITE] The Base of Aircraft Data (BADA)
[Curt: this deserves a link on the FlightGear site.] [Jon: ditto for the JSBSim site.] I think that this could be a treasure trove of aero data from the European Organization for the Safety of Air Navigation. Here's the abstract from the BADA manual for version 2.6: The Base of Aircraft Data (BADA) provides a set of ASCII files containing performance and operating procedure coefficients for 166 different aircraft types. The coefficients include those used to calculate thrust, drag and fuel flow and those used to specify nominal cruise, climb and descent speeds. User Manual for Revision 2.6 of BADA provides definitions of each of the coefficients and then explains the file formats. Instructions for remotely accessing the files via Internet are also given. These seem to be designed for ATC use, hence the limited selection of aero coefficients, but still, it's something. Here's the link to the complete version of the 2.6 manual: http://www.eurocontrol.fr/public/reports/eecnotes/1997/not23-97.pdf And here's the location of the actual data files (current version seems to be 3.3): ftp://bada.eurocontrol.fr/bada/ For each aircraft, there are three files: 1. The Airline Procedures File (*.APF). 2. The Aircraft Performance Operational Files (*.OPF). 3. The Performance File (*.PTF). As an example, here are the files for the Dash-8: ftp://bada.eurocontrol.fr/bada/3.3/DH8C__.APF ftp://bada.eurocontrol.fr/bada/3.3/DH8C__.OPF ftp://bada.eurocontrol.fr/bada/3.3/DH8C__.PTF Unfortunately, the DC-3 doesn't seem to be included. With 166 different models, you'd think they might have slipped it in... 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] Yasim and 2.95.2 math (was: Rudder inverted again in yasim)
Jim Wilson writes: > The pitch angle seems to be way too high when at altitude (not > climbing), which of course would cause a decrease of airspeed and > power. The altitude starts to decrease smoothly as IAS passes > below 300knots...not in a "stall" fashion. This is running with > the default half full tanks. Just wondering if you're seeing this > as well on your 2.95.2 build. Roskam's sample data for a 747-200 in cruise at 40,000ft gives these conditions: angle of attack: 2.4deg mach number: 0.9 TAS: 871fps (=516kt) weight: 636,636lb 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] Rudder inverted again in yasim
Jon Berndt writes: > OK. But I am not sure I agree with FlightGear's convention. That's certainly up for discussion, but it's been there for many years. The current FlightGear convention might make more sense to pilots than to engineers: a negative input to rudder or ailerons will (usually) decrease your compass heading, while a positive input will increase it. On the other hand, a negative elevator input will increase your angle of attack, and that doesn't seem to bother anyone. 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] Rudder inverted again in yasim
On Tue, 28 May 2002 10:04:12 -0700 Andy Ross <[EMAIL PROTECTED]> wrote: >Hopefully I got the conventions right. The point being not that >YASim's coordinate system is inherently better**, but that making the >joystick inputs match the coordinate sense is possible with a right >handed coordinate system. I don't know how the rudder pedals return a value. IIRC, the joystick returns a value based on a timer and ranges from 0 to some power of 2, depending on how far the joystick is yanked over. I assume the rudder pedals are similar. So, yes, it would not surprise me if the FlightGear (or plib) control "conventions" are linked to that. I suppose it's no big deal, really, just that we all agree. As far as aerosurface conventions go, however, yours is backwards from every one I have ever seen (but if it works for you it doesn't really matter). Both structural and body frames have the Y axis out the right wing. Aero conventions always (to my knowledge) place the coordinate system for each aero surface on that surface's hinge line and the frame is parallel (more or less) to the body frame (X out the nose positive, Y out the right side, z positive downward). Then, the elevator, flaps, rudder, etc. all obey the right hand rule when the surface is rotated about its hinge line. The exception is aileron command, for obvious reasons. A positive rudder deflection should result in a left yaw. I think if you stomp on the left rudder, this should be a positive rudder command, and you should get a left yaw, with the rudder rotating in a positive sense about its own Z axis. To the best of my knowledge, that's the way it works. Tony may comment on this if I'm off base. I've got so much going on now that I may be overlooking something. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] Virus with humor
Just got that Virus. Look at the "From:" and it's text... CU, Christian Message-ID: Return-Path: <[EMAIL PROTECTED]> Received: from dartagnan.telusquebec.com ([142.169.1.123]) by mailin01.sul.t-online.de with esmtp id 17CkSA-1xuRJgC; Tue, 28 May 2002 19:08:10 +0200 Received: from Qjvyda (alexis3-41-174.globetrotter.net [142.169.41.174]) by smtp.globetrotter.net (iPlanet Messaging Server 5.1 HotFix 0.6 (built Apr 26 2002)) with SMTP id <0GWT00AZZZF3RX@"TELUS Quebec"> for [EMAIL PROTECTED]; Tue, 28 May 2002 13:04:18 -0400 (EDT) Date: Tue, 28 May 2002 13:04:16 -0400 (EDT) Date-warning: Date header was inserted by smtp.globetrotter.net From: fgfs-devel <[EMAIL PROTECTED]> Subject: A excite game To: [EMAIL PROTECTED] MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_7O4JUesrc3ObuhWxlHjpJQ)" X-Mozilla-Status: 8001 X-Mozilla-Status2: X-UIDL: bae318bef17e7894 --Boundary_(ID_7O4JUesrc3ObuhWxlHjpJQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hello,This is a excite game This game is my first work. You're the first player. I hope you would enjoy it. --Boundary_(ID_7O4JUesrc3ObuhWxlHjpJQ) Content-id: Content-type: application/octet-stream; name=snoopy.exe Content-transfer-encoding: base64 Content-disposition: attachment; filename=snoopy.exe TVqQAAME//8AALgAQAAA 2A4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g ... -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rudder inverted again in yasim
Jon S. Berndt wrote: > OK. But I am not sure I agree with FlightGear's convention. It less a FlightGear thing than a PC joystick convention, I believe. Stomping on the left pedal makes the rudder axis value returned from the joystick driver positive. > The rudder Z axis is downward. [...] Personally, I would have > thought that a positive aileron deflection should result in a > positive roll rate, but it is opposite. That's coordinate system dependent. YASim (internally) has X forward, Y left and Z up. So a positive elevator (joystick up) produces a positive torque about Y, positive aileron* (joystick left) produces a positive torque about X, and positive rudder produces a positive torque about Z. Hopefully I got the conventions right. The point being not that YASim's coordinate system is inherently better**, but that making the joystick inputs match the coordinate sense is possible with a right handed coordinate system. Andy * On the left wing, which is the one YASim defines as the master. A vertical stabilizer is just an unmirrored left wing with a dihedral of 90. ** The real reason it's better is that I can model it on my right hand without pain while typing at the keyboard. -- 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] Yasim and 2.95.2 math (was: Rudder invertedagain in yasim)
Jim Wilson wrote: > The pitch angle seems to be way too high when at altitude (not > climbing) [...] But now I'm thinking that the real issue has to do > with the lift calculation. [...] The altitude starts to decrease > smoothly as IAS passes below 300knots...not in a "stall" fashion. > This is running with the default half full tanks. Just wondering if > you're seeing this as well on your 2.95.2 build. My 2.95.2 build doesn't work. :) Yours does only because you played with the thresholds. I'd be really suspicious of any "solution" obtained under such circumstances. Let me find and fix the compiler dependant solution failure first, then we can worry about simulation issues. The lack of a clear "stall", however, is probably not a bug. Big planes don't experience the same kind of giant attitude change inside the stall that the little ones do, they just drop faster. The fact that it happens at 300 KIAS is a problem, but I'll put that to the solution failure until proven otherwise. 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] Yasim and 2.95.2 math (was: Rudder inverted again in yasim)
Alex Perry <[EMAIL PROTECTED]> said: > Andy: > One thing to consider is whether the autopilot is optimizing for > the correct solution to the equations. Basically the autopilot just targets the max climb/descent rate until desired altitude is reached. It needs work. The current autopilot doesn't hold a pitch or a throttle/power/speed setting...so you can see it is quite easy to create a stall situation. The problem I'm seeing is actually observable without the autopilot. The autopilot was just being used as a reference point to describe the bug so it can be reproduced (as opposed to manual flight where I could have just had the trim screwed up). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: ..why C++ and not C?
> On Sat, 27 Apr 2002 01:57:09 -0500 Jonathan Polley wrote > >When you state your concerns about the FAA, I assume that you are talking > >about avionics software, probably DO-178B level C or higher. FlightGear is a combination of an aircraft FDM, a GIS database and a 3D GUI. When placed into an aircraft, I don't see any benefit in using our FDM since we would be accepting a data feed from the aircraft in --fdm=external. Given that scenario, the remaining GIS and GUI components are only providing a way to interpret the data feed and, in themselves, cannot affect the acft. Providing the FGFS GUI is advisory and not a primary instrument, most of the requirements go away and we're in the same situation as all those moving map displays that are essentially a tiny Windows NT computer with LCD screen. > An alternative would be to consider an effort to certify FlightGear > as a Flight Training Device under > AC 120-45A What do you seek to gain from that ? FTDs are required to have a physical instrument panel and cockpit and a separate instructor console. The visual display, which we're so proud of, is optional and the FDM can be minimal. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: ..why C++ and not C?
On Sat, 27 Apr 2002 01:57:09 -0500 Jonathan Polley wrote >When you state your concerns about the FAA, I assume that you are talking >about avionics software, probably DO-178B level C or higher.>The vast majority of modern (1987+) avionics software that I have seen is >in Ada, largely due to the structure that is built into the language. >With Ada's strong typing and package structure, you really need to work to >do something bad. The little bit of C software that we let wind up in our >final software is *very* process driven. This includes design reviews, >code reviews, test plans at design time, and test procedures that are >traceable back to top-level requirements. While our Ada software goes >through these same steps, extra care is taken with C (we restrict what can >be used), largely due to the lack of safeguards built into the language.>The biggest problem I see with C++ and the FAA is that it is VERY hard to >guarantee that C++ will not do any dynamic memory allocation. If you step >through the STL code with a debugger you will be amazed at how much is >going on there (strings are nasty). Since avionics are embedded systems, >the freeing of dynamic memory is a Very Bad Thing.>If you are developing software that will be used to test avionics software,> then the rules change. The same is true for level D or lower software. >With test applications, you need to go through a verification process, >which my team will be doing very shortly. While the process demands are >not as strict as it is for the flight software, I tend to require the same >level of process as our flight code. We tend to share people across >programs, and you never quite know where your software will be used next. >I think I can safely say that FlightGear will never be airworthy (unless >it is level E, which, in this case, means it will not be used for >flight). There are no documented requirements, design, evidence of peer >reviews, interface documentation, test procedures (especially ones mapped >to the requirements), etc. While you could, in theory, spend enough money >to certify almost any code, it is best if you think about airworthiness >from the onset. The structural coverage alone would be prohibitive (i.e., >prove that every branch of every line of code maps to some requirement and >that you have a test that exercises them). Standards for application to general aviation aircraft have been revised as to reduce the burden for certification of specific classes of avionics equipment. AC 29-1309 An alternative would be to consider an effort to certify FlightGear as a Flight Training Device under AC 120-45A Jonathan, what is your day job ? Joe Mangan
Re: [Flightgear-devel] Yasim and 2.95.2 math (was: Rudder inverted againin yasim)
Andy: One thing to consider is whether the autopilot is optimizing for the correct solution to the equations. There are always two solutions, one slower with higher drag and the other faster with lower drag. Depending on altitude and power, one of these can be below stall speed. Near the service ceiling, the two solutions may be only a couple of knots apart and difficult to distinguish by airspeed (have to use pitch). A popular mistake that both auto- and human- pilots make is to accidentally select the wrong one, which forces the aircraft into a trim oscillation. For humans, this is a problem in cruise, where the frequency is slow enough that the human doesn't figure out what's going on. For autos, it is a problem at slow speeds, where the frequency is high enough for the circuit never to notice the second solution and jump over to it. > Andy Ross <[EMAIL PROTECTED]> said: > > > In other news, I think I've got a 2.95.2 build that fails the same way > > yours does. I'm still at the "yup, it don't work" stage, though. No > > analysis yet. > > > Interesting. Also a few months ago we discussed a power problem at altitude > with the 747. Around 25000 feet or so the airspeed starts to fall when the > autopilot is engaged. > > But now I'm thinking that the real issue has to do with the lift calculation. > The pitch angle seems to be way too high when at altitude (not climbing), > which of course would cause a decrease of airspeed and power. The altitude > starts to decrease smoothly as IAS passes below 300knots...not in a "stall" > fashion. This is running with the default half full tanks. Just wondering if > you're seeing this as well on your 2.95.2 build. > > Best, > > Jim > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim and 2.95.2 math (was: Rudder inverted again in yasim)
Andy Ross <[EMAIL PROTECTED]> said: > In other news, I think I've got a 2.95.2 build that fails the same way > yours does. I'm still at the "yup, it don't work" stage, though. No > analysis yet. > Interesting. Also a few months ago we discussed a power problem at altitude with the 747. Around 25000 feet or so the airspeed starts to fall when the autopilot is engaged. But now I'm thinking that the real issue has to do with the lift calculation. The pitch angle seems to be way too high when at altitude (not climbing), which of course would cause a decrease of airspeed and power. The altitude starts to decrease smoothly as IAS passes below 300knots...not in a "stall" fashion. This is running with the default half full tanks. Just wondering if you're seeing this as well on your 2.95.2 build. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Rudder inverted again in yasim
OK. But I am not sure I agree with FlightGear's convention. The rudder Z axis is downward. A positive deflection (by the right hand rule) rotates (should rotate) the trailing edge left. The elevator deflection follows the same convention, right hand rule about the Y axis hinge line. Aileron is different, though. Personally, I would have thought that a positive aileron deflection should result in a positive roll rate, but it is opposite. Aileron is a rate control, unlike the other controls. Right aileron down is positive, resulting in a left roll. Jon > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David > Megginson > Sent: Tuesday, May 28, 2002 7:14 AM > To: [EMAIL PROTECTED] > Subject: RE: [Flightgear-devel] Rudder inverted again in yasim > > > Jon Berndt writes: > > > > I agree -- JSBSim is reporting a positive normalized position for > > > a negative input (and vice-versa). Obviously, we've made > > > allowances for that in the model animations, but it's > > > inconsistent with the behaviour elsewhere. I'll look into fixing > > > it. > > > > Before making changes, can you elaborate on this "problem"? > > 1. FlightGear uses a negative value for left rudder input. > > 2. JSBSim internally uses a positive value for left rudder deflection. > > 3. JSBSim publishes the rudder surface position back to FlightGear >with positive for left rudder. > > No change to the JSBSim core was required -- I just multiplied > FCS->GetDrPos(ofNorm) by -1 before passing the value to the FlightGear > property. > > > 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 > smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] Rudder inverted again in yasim
Jon Berndt writes: > > I agree -- JSBSim is reporting a positive normalized position for > > a negative input (and vice-versa). Obviously, we've made > > allowances for that in the model animations, but it's > > inconsistent with the behaviour elsewhere. I'll look into fixing > > it. > > Before making changes, can you elaborate on this "problem"? 1. FlightGear uses a negative value for left rudder input. 2. JSBSim internally uses a positive value for left rudder deflection. 3. JSBSim publishes the rudder surface position back to FlightGear with positive for left rudder. No change to the JSBSim core was required -- I just multiplied FCS->GetDrPos(ofNorm) by -1 before passing the value to the FlightGear property. 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] Rudder inverted again in yasim
No elaboration needed. Thanks David. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jon Berndt > Sent: Tuesday, May 28, 2002 6:38 AM > To: [EMAIL PROTECTED] > Subject: RE: [Flightgear-devel] Rudder inverted again in yasim > > > > I agree -- JSBSim is reporting a positive normalized position for a > > negative input (and vice-versa). Obviously, we've made allowances for > > that in the model animations, but it's inconsistent with the behaviour > > elsewhere. I'll look into fixing it. > > Before making changes, can you elaborate on this "problem"? > > Jon > smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Rudder inverted again in yasim
David Megginson <[EMAIL PROTECTED]> said: > I agree -- JSBSim is reporting a positive normalized position for a > negative input (and vice-versa). Obviously, we've made allowances for > that in the model animations, but it's inconsistent with the behaviour > elsewhere. I'll look into fixing it. > Ah, should have looked before assuming that JSBSim was right :-) I'll correct the 747. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Rudder inverted again in yasim
> I agree -- JSBSim is reporting a positive normalized position for a > negative input (and vice-versa). Obviously, we've made allowances for > that in the model animations, but it's inconsistent with the behaviour > elsewhere. I'll look into fixing it. Before making changes, can you elaborate on this "problem"? Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Rudder inverted again in yasim
Andy Ross writes: > I'm pretty sure that under the current YASim configurations, a > positive /controls/rudder input from the joystick will produce a > /surface-positions/rudder-norm of the same sign. That seems > rational to me, so I hereby hand the bug off to the JSB folks to > fix or further deflect. :) I agree -- JSBSim is reporting a positive normalized position for a negative input (and vice-versa). Obviously, we've made allowances for that in the model animations, but it's inconsistent with the behaviour elsewhere. I'll look into fixing it. 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] Report on my Scenery Investigation
Sounds interesting, which photo scenery do you work on? (I haven't read the postings for a while) thanks georg > -Original Message- > From: Colin Rose [mailto:[EMAIL PROTECTED]] > Sent: Dienstag, 28. Mai 2002 02:52 > To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] Report on my Scenery Investigation > > > > Well I am happy to report that I got the Photo scenery to > work perfectly. > Unfortunately it is with the latest windows binaries under > XP. Although the > photo scenery works fine none of the other scenery seems to > be installable > as it doesnt seem to be uncompressable under windows. > But thats OK if you have a dual boot system because you can > load all of the > scenery under linux except for the photo scenery of course > (at least on my > linux system the world scenery files gunzip) but the photo > scenery gove the > vertical lines stuff. > > Does anyone think the developers are aware of this? > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
