Re: [Flightgear-devel] Fix for compilation error in panel.cxx: `truncf' undeclared
Bernie Bright wrote: Compiles okay on Mandrake 9.2/10.0 (glibc-2.3.3 and gcc-3.3.2). However this should really be tested for by the configure script - AC_CHECK_FUNCS(truncf) and panel.cxx should then contain: I'll add a test for it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot
Hi All As one of only a few people who have built an autopilot for FG.I would ask what the perseved problems are with the current system. While I admit there are improvements to be made What is there is pretty good. At the risk also of seeming rude I would ask what experence the people who are proposing changes to the autopilot/autothrottle systems have in this area. If someone is keen to code up a system then may I suggest a Flight Management System.FG could realey use one of these.Failing that maybe a weather radar Jon Berndt writes ../roll-rate -++---+ /controls/elevator ../yaw-rate -+-- | Autopilot | -- /controls/ailerons ../heading -++---+ /controls/... My 707 course notes indicate 14 inputs and 6 outputs What's inside the black box? That's what I want to configure. Why???.Thats why they are called a black box. And unless you work for Bendix/King or one of the other black box manufactures you will never know.After all what is in the black box is there bread and butter. Yes. Me too. That's why JSBSim does things the way it does! :-) My recommendation is to take this design very slowly, chew on it a while, think about it. You want to do this right the first time. And, again, make it optional. Jon Cheers Innis _ E-mail just got a whole lot better. New ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalization of Live-CD
On Mon 26. January 2004 09:06, you wrote: Hi, I am in the process of i18n of the Live-CD. I need your assistance here. I only speek German and my own version of English. I need the sentence For starting in insert your language here please type: in all the languages you speak. (Please correct my English version too, if necessary.) In czech. Pro sputn v etin napite: MaDr ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot
Roy wrote: What's inside the black box? That's what I want to configure. Innis replied: Why???.Thats why they are called a black box. And unless you work for Bendix/King or one of the other black box manufactures you will never know.After all what is in the black box is there bread and butter. First, For some aircraft the autopilot block diagrams can be found. For those it would be nice to be able to model the autopilot mechanization as closely as possible. Second, for some other aircraft the mechanization of the autopilot might be proprietary (or even classified), but the designers might want to use FlightGear to test the implementation (even though the general public would never see the result). Third - and this happens for JSBSim periodically - a student or researcher might want to use building blocks to design a special purpose autopilot or flight control system (or a portion of one) for a thesis or other paper in an academic setting. Most people probably won't care to what level of detail the autopilot functionality is mechanized in FlightGear. However, once a general purpose heading A/P is crafted, or a wing leveler, etc., then those items as specified in a configuration file could be reused. They could also be easily tweaked. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
I agree with Jon. JSBSim (and possibly others) seems to be a notable flightdynamics model even in research. It will be better not to restrict posibilities in the area of modelling planes with their flightcontrol systems including the autopilots behavour. Greetings Mathias Roy wrote: What's inside the black box? That's what I want to configure. Innis replied: Why???.Thats why they are called a black box. And unless you work for Bendix/King or one of the other black box manufactures you will never know.After all what is in the black box is there bread and butter. First, For some aircraft the autopilot block diagrams can be found. For those it would be nice to be able to model the autopilot mechanization as closely as possible. Second, for some other aircraft the mechanization of the autopilot might be proprietary (or even classified), but the designers might want to use FlightGear to test the implementation (even though the general public would never see the result). Third - and this happens for JSBSim periodically - a student or researcher might want to use building blocks to design a special purpose autopilot or flight control system (or a portion of one) for a thesis or other paper in an academic setting. Most people probably won't care to what level of detail the autopilot functionality is mechanized in FlightGear. However, once a general purpose heading A/P is crafted, or a wing leveler, etc., then those items as specified in a configuration file could be reused. They could also be easily tweaked. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Mathias Fröhlich, e-mail: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Flight Gear - Brasil
I am installing Flight Gear and I would like to know if there is someone from Brasil that is currently working on the Flight Gear Project. Yes, there is. Not exactly working, but using it a lot! I'm creating airport models for brazilian airports now, Congonhas and Cumbica, feel free to contact me (in portuguese, maybe). I not a experienced airport developer, but I'm gladto helpyou. PS: Pode escrever em português diretamente para mim.. :) Marcio Shimoda -- ___Get your free email from http://www.iname.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot
Hi Jon Jon Berndt writes Most people probably won't care to what level of detail the autopilot functionality is mechanized in FlightGear. However, once a general purpose heading A/P is crafted, or a wing leveler, etc., then those items as specified in a configuration file could be reused. They could also be easily tweaked. This is what I dont understand what is wrong with the current system which can do heading,V/S,wing leveler,vor/loc(nav),approach,and autothrottle are these not accurate enough?. Also how much more computing power will be required for what ever extra detail may be involved.A 3D modeller would not even think of modeling the insides of the engine or every rivit in the aircraft for the obvious reason that the model would bring the computer to a halt.I am just wondering if this in its own way is not doing the same thing. Anyway the one question I would realy like answered is what is wrong with the current system.If the answer is nothing then why change. Famous Saying if it an't broke don't fix it Jon Cheers Innis _ Protect your inbox from harmful viruses with new ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot
On 1/27/04 at 10:30 PM Innis Cunningham wrote: Also how much more computing power will be required for what ever extra detail may be involved.A 3D modeller would not even think of modeling the insides of the engine or every rivit in the aircraft for the obvious Almost certainly neglible compared to the rendering. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Innis Cunningham wrote: This is what I dont understand what is wrong with the current system which can do heading,V/S,wing leveler,vor/loc(nav),approach,and autothrottle are these not accurate enough?. Also how much more computing power will be required for what ever extra detail may be involved.A 3D modeller would not even think of modeling the insides of the engine or every rivit in the aircraft for the obvious reason that the model would bring the computer to a halt.I am just wondering if this in its own way is not doing the same thing. Anyway the one question I would realy like answered is what is wrong with the current system.If the answer is nothing then why change. Famous Saying if it an't broke don't fix it Functionally the current autopilot is ok, but the underlying algorithm is very basic. Also, if you look through the code, it is a big hairy mess. And this was after a rewrite of the original C version. The problem is that we need to do more with the autopilot than what it's doing right now. For instance I want to be able to hold a specific pitch, or hold a specific speed with pitch. I might also want to hold a target roll rate (like 1 degree/sec) for 20 seconds. It would be possible to paste this onto the current system, but it's already a big mess of code in there and this will make just make the problem worse. I understand that if it aint broke, don't fix it but if I have to mess with a mess, I like to clean it up. :-) That's not to say anything negative about the current autopilot contributors. Just that I think the required functionality had long ago outgrown the infrastructure we had setup and so as people have added things, it's become quite a jumble. Also, we have several people here knowledgable in the field of control theory and people that understand how autopilots are supposed to work. Add that in with someone who (thinks he) understands the internals of FG and I think we have an opportunity to really improve the entire auto pilot infrastructure. That's where I'm coming from anyway ... Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Roy Vegard Ovesen wrote: On Mon, 26 Jan 2004 13:13:44 -, Richard Bytheway [EMAIL PROTECTED] wrote: That would be the responsibility of the autopilot designer. If he/she designed a control structure that used two separate controllers that acted on the ailerons, that would be his/her problem. In fact it might turn out to be a good thing. ;-) Does this imply that we also need a summer class/unit/module which can take the outputs from various controllers and sum them to feed to the actuator? Yes, a summer class/unit/module would be a handy tool. A gain class/unit/module would also be usefull. This would be for control mixing, right? Elevons, ailerators, thrudders, and, flailerons, and that sort of stuff? This should be a fairly straightforward extension to the current system I am working on. Now I have a question for the expert. I see two issues, and I'm curious about the best way to solve them. Right now we have limits built into the altitude hold modules. For instance, for the C172, I don't want to command a climb if the speed is less that 70 kts. So I take the target climb rate and tail that off to zero as the speed goes down to 70. It's a hack I know, but it seems to help. Is there a better way to do that anyway given a generic pid algorithm? Would we want to build in hooks to the generic pid algorithm so we can set up these sorts of limits? As I understand it, the autothrottle predicts the airspeed 10 seconds ahead of time, and uses that as the input. Would the differential component of the PID algorithm be able to account for this? Would we want some code someplace that puts the predicted speed into the property tree for the generic pid algorithm to use, or would we want to build in some sort of property prediction ability into the pid algorithm (in case the 'd' component doesn't quite do what we want?) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fix for compilation error in panel.cxx: `truncf' undeclared
Bernie Bright wrote:
this should really be tested for by the configure script -
AC_CHECK_FUNCS(truncf) and panel.cxx should then contain:
#ifndef HAVE_TRUNCF
inline float truncf (float d) { ...
#endif
Um, or you could just use floor() instead, which does the same thing
and works everywhere. Autoconf hackery should always be the choice of
last resort.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fix for compilation error in panel.cxx: `truncf' undeclared
Um, or you could just use floor() instead, which does the same thing and works everywhere. Unless you fly into someplace below sea level, where the floor of -0.01 is -1. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot
This is what I dont understand what is wrong with the current system which can do heading,V/S,wing leveler,vor/loc(nav),approach,and autothrottle are these not accurate enough?. Also how much more computing power will be required for what ever extra detail may be involved.A 3D modeller would not even think of modeling the insides of the engine or every rivit in the aircraft for the obvious reason that the model would bring the computer to a halt.I am just wondering if this in its own way is not doing the same thing. Anyway the one question I would realy like answered is what is wrong with the current system.If the answer is nothing then why change. Famous Saying if it an't broke don't fix it Disclaimer: I don't fully understand the current autopilot system, but I think I get the gist of the new proposal. As I understand it, the proposal is to rework the autopilot so that it is configurable within the XML for each aircraft, rather than being buried in the C++ code. To do this, there is a need for a controller that is XML configurable, which can have inputs, outputs and magic numbers associated either with entries in the property tree, or fixed in the XML. It makes sense to implement as few types of controller as possible, and make them as flexible as possible. A PID controller does everything we need for simple controllers (wing leveller by aileron, or speed by throttle for instance), and can be stacked (or cascaded) for more complex situations. It can also have the I and/or D components set to 0 if you want a P, PI or PD only controller. We might also need some simple auxiliary units, such as a summer and a limiter, although these could probably be combined into a summer which has the ability to clip the output. There is nothing in the proposal that would make use of this system compulsory. The current system isn't broken, it just isn't as easy to set up, or as flexible as a system could be. Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Fix for compilation error in panel.cxx: `truncf' undeclared
[truncf] * Andy Ross -- Tuesday 27 January 2004 17:09: Um, or you could just use floor() instead, which does the same thing [...] That's what I thought at first as well, but then I tried it ... m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fix for compilation error in panel.cxx: `truncf' undeclared
Unless you fly into someplace below sea level, where the floor of -0.01 is -1. And that's wrong? Why? Mild flame time: truncate-toward-zero is one of those things like acos/asin/atan that you want to avoid like the plague. It has almost no mathematical meaning (its output space is non-linear -- zero is overrepresented) and gets you into trouble more often than not. What are we using it for? And why won't floor or ceil work instead? The only legitimate use I can think of for trunc() on a negative number is to emulate a FPU float to int conversion without going through an integer register. The only use for it, so far, is to extract the thousands value from the altitude for use in an altimeter digital thousands display. Trunc() will work fine for both positive and negative altitudes, but floor() won't. Mild flame time: It's an engineering solution, not a math problem. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Can we ban outlook users from the list?
Just a thought :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Can we ban outlook users from the list?
Jim Wilson wrote: Just a thought :-) I got lectured once in a job interview (that obviously did not go well for me.) The interviewer didn't like my answer on the future of computer security. He asserted that in 6 months (this was 10 years ago) that all security problems would be solved because business simply can't tolerate this sort of nonsense. Market pressures would force vendors to fix all their bugs. Fortunately (for MS) market*ing* pressure wins out over market pressure. And users are all too forgiving and tolerant of bugs and problems and security holes. Being an effective monopoly definitely has it's upside. Just my opinion of course. I'm not speaking on behalf of the flightgear project here. :-) I guess what amazes me is the incredible tolerance of the computing public. I wonder what would happen if we gave our politicians the same amount of latitude that we give our computer software. Or for that matter, gave each other the same amount of margin for error as we give our computer software. :-) Of course, being a linux user means I don't tolerate this sort of crap in my software or in my politicians. I expect nothing less than complete perfection. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Can we ban outlook users from the list?
Cameron Moore wrote: Yes, we can actually. Just filter out this in Mailman: ^X-Mailer:.*Outlook Problem solved. ;-P gritting teeth Must fight ... the ... urge ... to ... /gritting teeth Disclaimer. We love our outlook users, just not the virus and security problems that seem to plague this particular piece of software. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Can we ban outlook users from the list?
* [EMAIL PROTECTED] (Jim Wilson) [2004.01.27 13:09]: Just a thought :-) Best, Jim Yes, we can actually. Just filter out this in Mailman: ^X-Mailer:.*Outlook Problem solved. ;-P -- Cameron Moore [ Why are there 5 syllables in the word monosyllabic? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Can we ban outlook users from the list?
Curtis L. Olson [EMAIL PROTECTED] said: Jim Wilson wrote: Just a thought :-) I guess what amazes me is the incredible tolerance of the computing public. I wonder what would happen if we gave our politicians the same amount of latitude that we give our computer software. Or for that matter, gave each other the same amount of margin for error as we give our computer software. :-) Maybe that's the solution to bring world peace. Or maybe people are suffering from repressed anger toward Microsoft...and taking it out on each other. I think I ran across some whaky web site once that claimed that Bill Gates was behind the 9/11 attacks. Perhaps (indirectly) it is true! I think that a lot of folks fall into the category of the user that just barely manages to use the software, never mind critiquing it. By the way, if anyone reading this thread is a Bank One customer, you've got a worm on your computer. I know because they just told me. :-D Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Tue, 27 Jan 2004 18:18:36 +0800, Innis Cunningham [EMAIL PROTECTED] wrote: Why???.Thats why they are called a black box. And unless you work for Bendix/King or one of the other black box manufactures you will never know.After all what is in the black box is there bread and butter. If nobody knows what's inside the autopilot, how can we make one? I want do design the black box, that is the kind of flexibility I'm looking for. Besides, I don't think it makes sense to have black boxes in an open source project. ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Tue, 27 Jan 2004 22:30:17 +0800, Innis Cunningham [EMAIL PROTECTED] wrote: This is what I dont understand what is wrong with the current system which can do heading,V/S,wing leveler,vor/loc(nav),approach,and autothrottle are these not accurate enough?. I'm sure the performance of the current autopliot system is very good. But I think that it's not very flexible. Also how much more computing power will be required for what ever extra detail may be involved.A 3D modeller would not even think of modeling the insides of the engine or every rivit in the aircraft for the obvious reason that the model would bring the computer to a halt.I am just wondering if this in its own way is not doing the same thing. Anyway the one question I would realy like answered is what is wrong with the current system.If the answer is nothing then why change. Here is my list of things that I think are wrong or should I say bad: * All aircraft have the same autopilot * Some functions are missing, like pitch-hold, and my favourite: aoa-hold ;-] * You can't tune the controllers By tuning I mean the manipulation of the proportional-, integral- and derivate-gains to achieve stability and smoothness. * Recognizing that there are a number of different strategies to implement a wing-leveler, or any other function, you are tied to the one that is hardcoded in C++. * The controller algorithm don't have integrator anti-windup (wich I consider essential) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Lighting Idea
On Monday 26 January 2004 13:00, Ilja Moderau wrote: Hi, I painted the windows of 747 and a320 transparent, then I put a simple rectangle behind the windows. This object got an emissive white color. http://home.arcor.de/iljamod/747.jpg http://home.arcor.de/iljamod/a320.jpg Just imagine, when you add the select animation depending on time or sun, you´ll see lights in the cabin when it is dark. Normally you´ll see the windows that are animated by select too. We can even add such lights to buildings etc. All the best Ilja Sounds like a neat trick, with quite a bit of potential. Nice one:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] panel action set (feature request)
David Culp wrote: For Innis' new 737 panel we could use a set action, that will set a property to the value of another property. Use a nasal script. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] panel action set (feature request)
On Tue, 27 Jan 2004 18:17:53 -0600, David Culp [EMAIL PROTECTED] wrote: Panel actions presently come in three types: 1. toggle 2. adjust 3. swap For Innis' new 737 panel we could use a set action, that will set a property to the value of another property. For instance, when the V/S switch is pushed the property /autopilot/settings/vertical-speed-fpm should be set to the airplane's current vertical speed. I used this action to achive this effect: binding commandproperty-assign/command property/autopilot/settings/altitude-ft/property property/instrumentation/altimeter/indicated-altitude-ft/property /binding .../altitude-ft is assigned the value of .../indicated-altitude-ft -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Just a bit more grist for the mill - as if it were needed:) One of the type of up-coming generations of a/c are likely to be controlled by thrust alone. No moving control surfaces and probably tailess. What I haven't figured out yet is if the concept's relying upon a very simple aerodynamic model, with lots of excess thrust, in which case simulating it might be possible(?), or it might rely upon clever aerodynamics, which I would have thought would be pretty difficult to simulate. But bearing that in mind, the AP design and structure will need to be flexible enough to work with these sorts of a/c control systems. I guess it also touches on the area of missile control systems too. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] panel action set (feature request)
Thanks Andy and Roy. The binding worked, but unfortunately the property I need doesn't exist :( Looks like I finally have to learn nasal. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] panel action set (feature request)
David Culp wrote: Thanks Andy and Roy. The binding worked, but unfortunately the property I need doesn't exist :( Looks like I finally have to learn nasal. Without having done any testing, testing, this would seem to do what you want. Basically, it's just a property-assign with a units conversion. There is a fancier property used by the VSI which computes vertical speed from the static pressure, too. binding commandnasal/command script setprop(/autopilot/settings/vertical-speed-fpm, 60 * getprop(/velocities/vertical-speed-fps)) /script /binding Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] panel action set (feature request)
binding commandnasal/command script setprop(/autopilot/settings/vertical-speed-fpm, 60 * getprop(/velocities/vertical-speed-fps)) /script /binding Perfect. I came up with the same thing in a couple minutes. Not much of a learning curve with nasal! Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot: Propulsion only FCS
My understanding is that they will be doing a lot of thrust vectoring ... lots of research is/has been done in that area. Curt. No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion only: http://www.dfrc.nasa.gov/DTRS/1999/PDF/H-2331.pdf Differential thrust (per side) induces a sideslip - induces roll. Changes in thrust (thrust line offset from CG in Z) induces pitch changes as well as accel/decel. Etc. Again, this is something that the JSBSim FCS components could handle - you need building blocks. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot: Propulsion only FCS
No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion only: I meant No thrust vectoring is necessary, nor used in the examples in the referenced paper. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot: Propulsion only FCS
Jon Berndt wrote: My understanding is that they will be doing a lot of thrust vectoring ... lots of research is/has been done in that area. Curt. No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion only: http://www.dfrc.nasa.gov/DTRS/1999/PDF/H-2331.pdf Differential thrust (per side) induces a sideslip - induces roll. Changes in thrust (thrust line offset from CG in Z) induces pitch changes as well as accel/decel. Etc. Again, this is something that the JSBSim FCS components could handle - you need building blocks. I thought some were discussing this in the context of fighters of the future. Just ignore me. :-) Curt. -- Curtis Olson Intelligent Vehicles Lab 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] New autopilot: Propulsion only FCS
I thought some were discussing this in the context of fighters of the future. Just ignore me. :-) Curt. Oops. Yes, that has been done, most recently on an F-15 I believe. I must have misinterpreted the context of the discussion. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot: Propulsion only FCS
On Wednesday 28 January 2004 02:26, Jon Berndt wrote: My understanding is that they will be doing a lot of thrust vectoring ... lots of research is/has been done in that area. Curt. No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion only: http://www.dfrc.nasa.gov/DTRS/1999/PDF/H-2331.pdf Differential thrust (per side) induces a sideslip - induces roll. Changes in thrust (thrust line offset from CG in Z) induces pitch changes as well as accel/decel. Etc. Again, this is something that the JSBSim FCS components could handle - you need building blocks. Jon I think I've heard of some of the stuff Curt's referring to - the next gen US fighters are planned to be thrust vectoring only. Taking the control surface stuff out of the wing removes channeling, making it more simple but also stronger and more resiliant to damage - you don't have to worry about the control surfaces getting damaged. Infact, the entire wing could sustain a lot of damage but as long as there's something there, it'd probably be flyable with such a control system. The planiforms I've seen have been trapizoidal, with an area cut out of the middle, along the fuselage! No tail surfaces, just vectoring thrust. Landing must be a laugh - difficult to imagine landing without flaps - very high AoA perhaps. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Fix for compilation error in panel.cxx: `truncf' undeclared
Erik Hoffman wrote: Bernie Bright wrote: / Compiles okay on Mandrake 9.2/10.0 (glibc-2.3.3 and gcc-3.3.2). However this // should really be tested for by the configure script - AC_CHECK_FUNCS(truncf) // and panel.cxx should then contain: / I'll add a test for it. Erik Erik, Unfortunately, FlightGear still doesn't compile on RedHat 7.3, even with the above configure script check for truncf (I haven't checked it out on RedHat 9 yet). I did figure out how to get it to work though (see below). The problem is that although truncf is present in Red Hat 7.3's glibc libraries, a declaration for truncf is not provided in math.h, unless _ISOC99_SOURCE is defined (maybe this is a Red Hat peculiarity, since Bernie said that he had no problems compiling on Mandrake -- can any other Red Hat users confirm this compilation problem?). The configure script effectively only tests for the presence of the truncf function in the library, so the check succeeds. When I run 'make' to compile FlightGear however, compilation fails with the error that truncf is undeclared (even though the configure script check passed!). I can get around this problem by using the preprocessor option -D_GNU_SOURCE, which in turn defines _ISOC99_SOURCE (you can't simply define _ISOC99_SOURCE, since that will cause some other macros to be un-defined, which causes the configure script check for plib to fail. Maddening!). With _GNU_SOURCE defined, truncf gets declared and compilation proceeds without error. So, my question to the autoconf gurus is this: Is there a way to test in the configure script to see if truncf is declared in math.h, and if not, to add -D_GNU_SOURCE to the preprocessor options (if the compiler is gcc) and check for a declaration of truncf again? I'm willing to drop the subject and just add -D_GNU_SOURCE to the CPPFLAGS environment variable in my personal FlightGear build script, but if a test is available that will automagically sort out all these issues for all platforms, that would be a better solution. Thanks, -Eric Hathaway ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot: Propulsion only FCS
Lee wrote: I think I've heard of some of the stuff Curt's referring to - the next gen US fighters are planned to be thrust vectoring only. Taking the control surface stuff out of the wing removes channeling, making it more simple but also stronger and more resiliant to damage - you don't have to worry about the control surfaces getting damaged. Infact, the entire wing could sustain a lot of damage but as long as there's something there, it'd probably be flyable with such a control system. The planiforms I've seen have been trapizoidal, with an area cut out of the middle, along the fuselage! No tail surfaces, just vectoring thrust. Landing must be a laugh - difficult to imagine landing without flaps - very high AoA perhaps. LeeE http://www.nawcad.navy.mil/strike/projects/x31.cfm http://www.nawcad.navy.mil/strike/projects/fall2001/x31_fall2001.cfm (4 MB, X-31 landing) http://www.dfrc.nasa.gov/Gallery/Movie/X-31/Medium/EM-0036-04.mpg (800 KB, X-31 post-loop stall; this one will blow you away) http://www.dfrc.nasa.gov/Gallery/Movie/X-31/Medium/EM-0036-08.mov (350 KB, Mongoose manuever; this one will blow you away more) http://www.dfrc.nasa.gov/Gallery/Movie/X-31/Medium/EM-0036-05.mov ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Fix for compilation error in panel.cxx: `truncf' undeclared
Eric L Hathaway [EMAIL PROTECTED] said: Unfortunately, FlightGear still doesn't compile on RedHat 7.3, even with the above configure script check for truncf (I haven't checked it out on RedHat 9 yet). I did figure out how to get it to work though (see below). It does build on 7.3. Maybe you need to have glibc-devel installed? Sorry I can't give you a better answer right now. If you're still stumped tomorrow I'll get on the 7.3 machine and track it down. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Using Nasal for view calcs in preferences.xml
Is it possible to use nasal scripting in preferences.xml? I'm specifically interested in using it in a view definition. -- Cameron Moore [ You're mind can only absorb what you seek out and endure. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Hi Curt Curtis L. Olson writes Also, we have several people here knowledgable in the field of control theory and people that understand how autopilots are supposed to work. Add that in with someone who (thinks he) understands the internals of FG and I think we have an opportunity to really improve the entire auto pilot infrastructure. That's where I'm coming from anyway ... Ok in that case I hope we end up with a great autopilot. Although I am wondering if a basic autopilot for a light plane, a commercial jet,a fighter and other types would be the same. or would you need a separate one for each class. The things I found I can't do with the current setting is hold pitch angle,hold angle of attack,hold roll rate,But as all these things are in the property tree I would have thought it would be easy enough to add them to the autopilot locks property. Maybe not. It is my understanding that most commercial aviation autopilots have a set roll rate,yaw rate and pitch rate. Is this not the case Regards, Curt. Cheers Innis _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Fix for compilation error in panel.cxx: `truncf' undeclared
On Tue, 27 Jan 2004 23:50:56 -0500 Eric L Hathaway [EMAIL PROTECTED] wrote: Erik Hoffman wrote: Bernie Bright wrote: / Compiles okay on Mandrake 9.2/10.0 (glibc-2.3.3 and gcc-3.3.2). However this// should really be tested for by the configure script - AC_CHECK_FUNCS(truncf)// and panel.cxx should then contain: / I'll add a test for it. Erik Erik, Unfortunately, FlightGear still doesn't compile on RedHat 7.3, even with the above configure script check for truncf (I haven't checked it out on RedHat 9 yet). I did figure out how to get it to work though (see below). Perhaps we need to reconsider this whole truncf() thing. FlightGear is supposed to be written in C++ not C99. Maybe we could add an equivalent function to SimGear. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
