RE: [Flightgear-devel] control surface normalization
> Would you mind repeating your original intention, Jon? > > Ampere I started out with the question: "Can anyone recommend a good digital camcorder?" and it went downhill from there. ;-) Here was my original question: "I'd like to remove the code that normalizes angular measurement, but I am told that FlightGear requires normalized angular measurement, which seems, on the surface, ridiculous. At the very least, I'd like to move the normalization code out of our flight controls code (JSBSim) and into the flightgear interface code, since it appears to be a requirement of FlightGear only." There is some normalization code in our flight controls code that exists really only for the benefit of FlightGear modelers. As such, I wanted to remove it from JSBSim, and into the FGInterface (FGJSBSim) class. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Would you mind repeating your original intention, Jon? Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Would you mind repeating your original intention? Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 22:59:35 - "Vivian Meazza" <[EMAIL PROTECTED]> wrote: Lee Elliott wrote > > [snip...] > > How do FDMs handle Fowler flaps? i.e. the first part of the > action extends the flap rearwards without any rotation, acting > only to increase wing area, then for the rest of the action > rotate downwards? > > Easy enough to 3d model with a normalized input: translation > then rotation. > > Just curious > > Vivian That's exactly one of the problems I'm trying to work out wioth the B-52. The flaps have only two settings - fully extended or fully retracted, and it took 60 sec for full traversal. IIRC, the first 60%, or so, just increases the wing area, with the remainder changing the downwash. I've no idea what YASim is doing, as far as numbers go, but it seems to be behaving close according to anecdotal evidence. Probably what we'd do for JSBSim if we were going to model this is to figure out the aero coefficient increments due to flap extension to specified points (perhaps pseudo "degrees" or in a range from 0 to 1). We might do this using DATCOM+, or using standard equations. Then we'd use a kinematic component to introduce the effects at runtime. For the next version of JSBSim we might even introduce the effects using equations, specified in the config file. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Lee Elliott wrote > > > [snip...] > > > > How do FDMs handle Fowler flaps? i.e. the first part of the > > action extends the flap rearwards without any rotation, acting > > only to increase wing area, then for the rest of the action > > rotate downwards? > > > > Easy enough to 3d model with a normalized input: translation > > then rotation. > > > > Just curious > > > > Vivian > > That's exactly one of the problems I'm trying to work out wioth > the B-52. The flaps have only two settings - fully extended or > fully retracted, and it took 60 sec for full traversal. IIRC, > the first 60%, or so, just increases the wing area, with the > remainder changing the downwash. I've no idea what YASim is > doing, as far as numbers go, but it seems to be behaving close > according to anecdotal evidence. > > Perhaps flight control surfaces should be defined in terms of the > change to chord and incidence but then how do you get the data? > Andy Ross will be able to explain in detail, but as I understand it YASim handles all kinds of flaps the same. The lift and drag increase is specified in the config file, then YASIM applies a proportion of both according to how far the flap is extended. I haven't investigated the function which is applied. It might be linear, or some other. I'm not sure if lift and drag are treated equally. Given how little we know about the real numbers for the likes of the B52, I guess that's good enough. I suppose that, in fdm terms, you could regard Fowler flaps as 2 separate flaps. In principle, some function, or functions could be applied which would cater for the first part of the movement, and then the second. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Friday 17 December 2004 21:51, Vivian Meazza wrote: > Lee Elliott wrote: > > On Thursday 16 December 2004 21:17, Jon S Berndt wrote: > > [snip...] > > > > > Also, ask yourself the question, does the normalized value > > > of, say, 0.5 really correspond to 30 degrees of flaps when > > > the total range is 0 to 60? > > > > Are you not assuming a linear transition here? It doesn't > > have to be. > > How do FDMs handle Fowler flaps? i.e. the first part of the > action extends the flap rearwards without any rotation, acting > only to increase wing area, then for the rest of the action > rotate downwards? > > Easy enough to 3d model with a normalized input: translation > then rotation. > > Just curious > > Vivian That's exactly one of the problems I'm trying to work out wioth the B-52. The flaps have only two settings - fully extended or fully retracted, and it took 60 sec for full traversal. IIRC, the first 60%, or so, just increases the wing area, with the remainder changing the downwash. I've no idea what YASim is doing, as far as numbers go, but it seems to be behaving close according to anecdotal evidence. Perhaps flight control surfaces should be defined in terms of the change to chord and incidence but then how do you get the data? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 21:51:56 - "Vivian Meazza" <[EMAIL PROTECTED]> wrote: How do FDMs handle Fowler flaps? i.e. the first part of the action extends the flap rearwards without any rotation, acting only to increase wing area, then for the rest of the action rotate downwards? Easy enough to 3d model with a normalized input: translation then rotation. Now that's a good example. I'd have to think about it a bit. I don't have an answer on that one. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Lee Elliott wrote: > > On Thursday 16 December 2004 21:17, Jon S Berndt wrote: > [snip...] > > > > Also, ask yourself the question, does the normalized value of, > > say, 0.5 really correspond to 30 degrees of flaps when the > > total range is 0 to 60? > > > > Are you not assuming a linear transition here? It doesn't have > to be. > How do FDMs handle Fowler flaps? i.e. the first part of the action extends the flap rearwards without any rotation, acting only to increase wing area, then for the rest of the action rotate downwards? Easy enough to 3d model with a normalized input: translation then rotation. Just curious Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thursday 16 December 2004 22:08, Gordan Sikic wrote: [snip...] > > (about F16) > AFAIK, it has nonmoving joystick, and force transducers, and > it is "normal" for that plane to ise output from the > transduced as a input. > The original HOTAS non-moving sticks in the development a/c were changed to have a very small amount of movement in the early production a/c. I don't know if they then started using non-moving sticks again in later versions though. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thursday 16 December 2004 21:17, Jon S Berndt wrote: [snip...] > > Also, ask yourself the question, does the normalized value of, > say, 0.5 really correspond to 30 degrees of flaps when the > total range is 0 to 60? > Are you not assuming a linear transition here? It doesn't have to be. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
I disagree. It is easy to say what is natural, but hard to show it. After someone has been flying for a while it sure feels natural. But when I have a new student I find that very often they "over control" the aircraft. I can get them to quite down by convincing them to "just use pressure". Maybe we are just arguing semantics, but I think that it is learned, not "natural." -- Adam > From: Gordan Sikic <[EMAIL PROTECTED]> > Reply-To: FlightGear developers discussions <[EMAIL PROTECTED]> > Date: Fri, 17 Dec 2004 09:22:17 +0100 > To: FlightGear developers discussions <[EMAIL PROTECTED]> > Subject: Re: [Flightgear-devel] control surface normalization > > Hi, > >> Pilots are taught to think in terms of pressure on stick not displacement. >> That is part of the reason that the F-16 is built the way it is. >> > > Thats OK, I agree, with one small change: > pilots are not *taught* to think in terms in terms of pressure on stick. > It is the natural way of "sensing the aircraft". > > cheers, > Gordan > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 10:05:04 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: The FDM may choose to carry along with that abstraction (which makes sense) because you are concerned with getting the right performance when the lever is in the 30 degree position. It all works out in the end, but saying the flaps are at 30 degrees is an extreme over simplification. Yes, this is true. You're right, too, that we don't care about the _visual_ position of the flaps, but what the flaps have been commanded to and what aerodynamic properties result from that setting. But at least we have that. Saying we are at 30 degrees flaps in a range from 0 to 60 may not be concrete, but it beats simply saying that the flap setting is 0.5. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 10:07:47 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: Jon, the problem is: how does the interface know how to normalize the control surface positions? Where does it read the maximum limits from? The FDM is really the only piece that is going to know this information. This is **exactly** one of the big concerns I have. But, it cuts both ways. Using normalized position, NIETHER the FDM NOR the animation system knows where to place the elevator, for instance, unless two pieces of information are present. This is what I've been trying to illustrate for some time. For aerosurfaces, an absolute measurement makes sense (such as degrees or radians) for most aerosurfaces because it uniquely determines orientation. It is true that the FDM usually knows what the phyisical limits are for an aerosurface, but if we normalize the elevator or rudder setting we cannot simply pass the normalized value, we have to pass the limit as well. And I'm not prepared to continue to do this in the FDM proper. The presence of all the special purpose normalization routines is really confusing. Whatever is done will have to be done in the interface. Additionally, what on earth are the animators using to turn normalized values into degrees, now? JSBSim is certainly not now passing in limit information. I suppose JSBSim defines one set of limits and - hopefully - the 3D modelers are using the same value. But, what if the limits are changed in the flight model? One thing we could do is to simply define a NORMAL_FACTOR that corresponds to a constant, say 30 degrees. Then always normalize in the interface w.r.t. that. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon Berndt wrote: Boy, do I enjoy a vigorous debate, especially when I am right. Unfortunately, in this case, I appears that I did not consider all the needs of the animation system. Neither one should have to be designed to make up for something the other doesn't do. So I think the best thing to do, as we've hit on before, is to have the interface do the translation. That's where the discussion should probably head. Jon, the problem is: how does the interface know how to normalize the control surface positions? Where does it read the maximum limits from? The FDM is really the only piece that is going to know this information. I propose that you continue to output normalized values, but in addition, output degrees. Your FCS can choose to work with the degree numbers, and the animators can choose to use which ever number/units are most appropriate and convenient for their purposes. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon Berndt wrote: No, the FDM doesn't care about anything but commanded flap position - which will be taken to actual position through the FCS, but with JSBSim actuator dynamics are not required to be modeled. Commanded and actual positions are in degrees. As I said before, does 30 degrees flaps (when the maximum travel is 60) corespond to an actuator extension of 0.5? Probably not. Does it matter for animation purposes? Probably not, I guess. Jon, The question I have is when the pilot selects "30 degrees flap" in the cockpit, for an aircraft with a complex multi-part flap mechansim ... are they really getting 30 degrees? Where is this measured, relative to what? How does this relate to how much the pieces extend as they rotate? For many aircraft, "flap degrees" is an abstraction already, and doesn't really correspond directly or linearly to actual measurable degrees. The FDM may choose to carry along with that abstraction (which makes sense) because you are concerned with getting the right performance when the lever is in the 30 degree position. It all works out in the end, but saying the flaps are at 30 degrees is an extreme over simplification. I do think you are trying to make some valid points here in this thread, but I don't think that using flaps as an example advances your argument. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 15:26:26 +0100 Gordan Sikic <[EMAIL PROTECTED]> wrote: Hi Jon, Once more, do not make general statements, based on a few examples. Jon wrote: One hundred percent of the control law diagrams ... I have seen that include pilot inputs use force. There are _many_ FCS's out there, not using input you just described. Fore examples, take a look at the "Flight control and simulation", the book with examples that are completely based on F16 dynamics. Steven's and Lewis? F-16? I don't know what Steven's and Lewis are saying (I'll take a look later today), but I *am* referring to the F-16 as _one_ example, and I was referring to the manufacturer's (General Dynamics) FCS diagrams, not a textbook interpretation. The manufacturer's diagrams show stick force as input. I don't mean to say that this is necessarily a standard, or that it is always this way, or even usually this way, but it makes sense and is easy to work with. Can you give an example of an alternative approach? I am curious. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Hi Jon, output laterally, on the pedals, and front/back on the stick. I think that's why the control law diagrams I have seen use pilot stick force as the input unit. One hundred percent of the control law diagrams I have seen that include pilot inputs use force. Once more, do not make general statements, based on a few examples. There are _many_ FCS's out there, not using input you just described. Fore examples, take a look at the "Flight control and simulation", the book with examples that are completely based on F16 dynamics. cheers, Gordan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Jon Berndt writes: > > Boy, do I enjoy a vigorous debate, especially when I am right. Unfortunately, > in this > case, I appears that I did not consider all the needs of the animation > system. Neither one > should have to be designed to make up for something the other doesn't do. So > I think the > best thing to do, as we've hit on before, is to have the interface do the > translation. > That's where the discussion should probably head. As was suggested *very* early on in this thread :-) being-right-like-beauty-is-in-the-eyes-of-the-beholder'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 07:32:04 -0600, Jon wrote in message <[EMAIL PROTECTED]>: > On Behalf Of Arnt Karlsen > > > On Fri, 17 Dec 2004 09:22:17 +0100, Gordan wrote in message > > <[EMAIL PROTECTED]>: > > > > > Hi, > > > > > > > Pilots are taught to think in terms of pressure on stick not > > > > displacement. That is part of the reason that the F-16 is built > > > > the way it is. > > > > ..this used to be the doctrine in at least the 1980'ies in the > > RNoAF. > > > > > Thats OK, I agree, with one small change: > > > pilots are not *taught* to think in terms in terms of pressure on > > > stick. It is the natural way of "sensing the aircraft". > > > > ..this is the saner approach. ;-) > > When it comes down to it, there is only a voltage, or a resistance, in > a fly-by-wire system, at least. The FCS computer doesn't really care > what it gets. But it has to know the relationship between what the > pilot is saying and the voltage it is seeing. In some cases the stick > doesn't simply control elevator motion (for example), it commands a > pitch rate, or a normal force, or whatever. The one thing the pilot > can output to the stick - the single thing - is a force on it. There > are standards that state what a pilot can output laterally, on the > pedals, and front/back on the stick. I think that's why the control > law diagrams I have seen use pilot stick force as the input unit. One > hundred percent of the control law diagrams I have seen that include > pilot inputs use force. ..true, in *AF environments you also train people to deal with it, even after combat damage, and there you need these people to _act_ and _act_right_, rather than die figuring out control laws, hence the "sane shortcuts". ;-) -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Boy, do I enjoy a vigorous debate, especially when I am right. Unfortunately, in this case, I appears that I did not consider all the needs of the animation system. Neither one should have to be designed to make up for something the other doesn't do. So I think the best thing to do, as we've hit on before, is to have the interface do the translation. That's where the discussion should probably head. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
> Jon Berndt wrote: > good chance > > that you're not going to get exactly 30 degrees flaps. The actuator > > mechnism probably > > won't linearly extend the flaps due to the compound nature of the flap > > mechanisms. > > If that is the case the FDM should know about it more than anything else > IMHO. > > Erik No, the FDM doesn't care about anything but commanded flap position - which will be taken to actual position through the FCS, but with JSBSim actuator dynamics are not required to be modeled. Commanded and actual positions are in degrees. As I said before, does 30 degrees flaps (when the maximum travel is 60) corespond to an actuator extension of 0.5? Probably not. Does it matter for animation purposes? Probably not, I guess. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon Berndt wrote: Also, ask yourself the question, does the normalized value of, say, 0.5 really correspond to 30 degrees of flaps when the total range is 0 to 60? It should be, if the FDM does it's thing right. Erik Not so fast. Aero tables might be indexed for flaps based on angle. If the flaps are commanded to 30 degrees the aero force and moment will be calculated based on that. What I was getting at is this: if the flap actuator extends fifty percent, there's a good chance that you're not going to get exactly 30 degrees flaps. The actuator mechnism probably won't linearly extend the flaps due to the compound nature of the flap mechanisms. If that is the case the FDM should know about it more than anything else IMHO. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
> Curtis L. Olson wrote: > > It doesn't probably matter too much for 3d animation if your conversion > > factor get's you close. > > There is another thing, all doors, struts and support bars are animated > based on the gear extension. While the main gear extension might be > perfectly valid in degrees, converting supports struts/bars will be a > whole lot more complicated. Like I mentioned before, landing gear extension is fine as a "0 to 1" parameter. Elevator, rudder, speedbrake, spoilers, etc. in angular measurements. Now, *IF* we are to normalize these angular parameters in the FGInterface class, WHAT is the non-dimensionalizing procedure? How do we non-dimensionalize with any degree of accuracy and compatibility? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
> > Also, ask yourself the question, does the normalized value of, say, 0.5 > > really correspond to 30 degrees of flaps when the total range is 0 to 60? > > It should be, if the FDM does it's thing right. > > Erik Not so fast. Aero tables might be indexed for flaps based on angle. If the flaps are commanded to 30 degrees the aero force and moment will be calculated based on that. What I was getting at is this: if the flap actuator extends fifty percent, there's a good chance that you're not going to get exactly 30 degrees flaps. The actuator mechnism probably won't linearly extend the flaps due to the compound nature of the flap mechanisms. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon Berndt wrote: (And If you don't believe me, start to work on the gear animations of the Fokker-50 in degrees (0 - 90 degrees). If you manage to get that working we could start talking again). I think this illustrates the futility of trying to use a one-size-fits-all animation strategy. It tries to be everything to everyone and ends up completely pleasing no one. Oh, I like the normalized values. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
On Behalf Of Arnt Karlsen > On Fri, 17 Dec 2004 09:22:17 +0100, Gordan wrote in message > <[EMAIL PROTECTED]>: > > > Hi, > > > > > Pilots are taught to think in terms of pressure on stick not > > > displacement. That is part of the reason that the F-16 is built the > > > way it is. > > ..this used to be the doctrine in at least the 1980'ies in the RNoAF. > > > Thats OK, I agree, with one small change: > > pilots are not *taught* to think in terms in terms of pressure on > > stick. It is the natural way of "sensing the aircraft". > > ..this is the saner approach. ;-) When it comes down to it, there is only a voltage, or a resistance, in a fly-by-wire system, at least. The FCS computer doesn't really care what it gets. But it has to know the relationship between what the pilot is saying and the voltage it is seeing. In some cases the stick doesn't simply control elevator motion (for example), it commands a pitch rate, or a normal force, or whatever. The one thing the pilot can output to the stick - the single thing - is a force on it. There are standards that state what a pilot can output laterally, on the pedals, and front/back on the stick. I think that's why the control law diagrams I have seen use pilot stick force as the input unit. One hundred percent of the control law diagrams I have seen that include pilot inputs use force. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
> Curtis L. Olson wrote: > > Erik Hofman wrote: > > > >>> Personally, I would be in favor of using angles to describe the > >>> positions of left/right aileron, elevator, rudder and nose/tail wheel. > >> > >> Please, not for the wheels. Really. > > > > It doesn't probably matter too much for 3d animation if your conversion > > factor get's you close. > > There is another thing, all doors, struts and support bars are animated > based on the gear extension. While the main gear extension might be > perfectly valid in degrees, converting supports struts/bars will be a > whole lot more complicated. > > (And If you don't believe me, start to work on the gear animations of > the Fokker-50 in degrees (0 - 90 degrees). If you manage to get that > working we could start talking again). > > Erik I think this illustrates the futility of trying to use a one-size-fits-all animation strategy. It tries to be everything to everyone and ends up completely pleasing no one. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 09:22:17 +0100, Gordan wrote in message <[EMAIL PROTECTED]>: > Hi, > > > Pilots are taught to think in terms of pressure on stick not > > displacement. That is part of the reason that the F-16 is built the > > way it is. ..this used to be the doctrine in at least the 1980'ies in the RNoAF. > Thats OK, I agree, with one small change: > pilots are not *taught* to think in terms in terms of pressure on > stick. It is the natural way of "sensing the aircraft". ..this is the saner approach. ;-) -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon S Berndt wrote: On Thu, 16 Dec 2004 20:47:03 - "Jim Wilson" wrote: It might be useful for someone to work through the values as that would be report for the various stages of deployment on a 747 flap system. As Richard message suggests here the detail required by the 3D modeler is sometimes quite a bit more than what is required by the FDM. Also, ask yourself the question, does the normalized value of, say, 0.5 really correspond to 30 degrees of flaps when the total range is 0 to 60? It should be, if the FDM does it's thing right. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jim Wilson wrote: This is just what was going through my mind when reading this discussion. Jon's concern is quite valid, but there are problems. As I work through these concepts in my mind, I can see that although the current method sounds more complicated for the 3D animator, having to deal with the real values could be a lot worse (at least with the current architecture). It might be useful for someone to work through the values as that would be report for the various stages of deployment on a 747 flap system. As Richard message suggests here the detail required by the 3D modeler is sometimes quite a bit more than what is required by the FDM. Also, to have some objects reported normalized and other objects reported actual would be too confusing...even if the distinctions and reasons were logically sensible. In the long run we'll benefit the most from consistency even if it means more work at the FDM interface. I second this. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Curtis L. Olson wrote: Erik Hofman wrote: Personally, I would be in favor of using angles to describe the positions of left/right aileron, elevator, rudder and nose/tail wheel. Please, not for the wheels. Really. It doesn't probably matter too much for 3d animation if your conversion factor get's you close. There is another thing, all doors, struts and support bars are animated based on the gear extension. While the main gear extension might be perfectly valid in degrees, converting supports struts/bars will be a whole lot more complicated. (And If you don't believe me, start to work on the gear animations of the Fokker-50 in degrees (0 - 90 degrees). If you manage to get that working we could start talking again). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Hi, Pilots are taught to think in terms of pressure on stick not displacement. That is part of the reason that the F-16 is built the way it is. Thats OK, I agree, with one small change: pilots are not *taught* to think in terms in terms of pressure on stick. It is the natural way of "sensing the aircraft". cheers, Gordan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Pilots are taught to think in terms of pressure on stick not displacement. That is part of the reason that the F-16 is built the way it is. -- Adam Dershowitz, Ph.D., CFI, MEI > From: Gordan Sikic <[EMAIL PROTECTED]> > Reply-To: FlightGear developers discussions <[EMAIL PROTECTED]> > Date: Thu, 16 Dec 2004 23:08:30 +0100 > To: FlightGear developers discussions <[EMAIL PROTECTED]> > Subject: Re: [Flightgear-devel] control surface normalization > > Hi Jon, > > I see you are really mad :) >> Look here at the X-15 data and FCS diagram: >> http://jsbsim.sourceforge.net/X-15Aero.html >> >> The USAF F-16 (Block 40) FCS diagram is the same way: stick force is the >> input. Same with Space Shuttle control Law diagrams. >> >> The JSBSim X-15 model simulates the X-15 control laws as shown in the >> link above. We take the -1 to +1 joystick input from FlightGear and turn >> it into a stick force, mapping to the force range described in Etkin's >> book as a sort of standard. >> > > These are 3 particular examples only. > > (about F16) > AFAIK, it has nonmoving joystick, and force transducers, and it is > "normal" for that plane to ise output from the transduced as a input. > > (about X15) > AFAIK, it had 2 completely different (unconnected?) sticks, one for > "lower speeds" (usual stick), and the other one (joystick actually) used > for control in "higer speeds regimes". Does it apply for both sticks? > > > As I mentioned, these are 3 particular examples only, not a general rule . > > cheers, :) > Gordan > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Hi Jon, I see you are really mad :) Look here at the X-15 data and FCS diagram: http://jsbsim.sourceforge.net/X-15Aero.html The USAF F-16 (Block 40) FCS diagram is the same way: stick force is the input. Same with Space Shuttle control Law diagrams. The JSBSim X-15 model simulates the X-15 control laws as shown in the link above. We take the -1 to +1 joystick input from FlightGear and turn it into a stick force, mapping to the force range described in Etkin's book as a sort of standard. These are 3 particular examples only. (about F16) AFAIK, it has nonmoving joystick, and force transducers, and it is "normal" for that plane to ise output from the transduced as a input. (about X15) AFAIK, it had 2 completely different (unconnected?) sticks, one for "lower speeds" (usual stick), and the other one (joystick actually) used for control in "higer speeds regimes". Does it apply for both sticks? As I mentioned, these are 3 particular examples only, not a general rule . cheers, :) Gordan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon S Berndt said: > Also, ask yourself the question, does the normalized value of, say, > 0.5 really correspond to 30 degrees of flaps when the total range is 0 > to 60? No telling. How many angles can you discern at 50 meters on a 1600 pixel screen (not to mention 800)? :-) > > Also, to have some objects reported normalized and other objects > >reported > > actual would be too confusing...even if the distinctions and reasons > >were > > logically sensible. In the long run we'll benefit the most from > >consistency > > even if it means more work at the FDM interface. > > Not sure I agree here. It should not be a big deal to have two > subclasses, one to handle normalized and one to handle not normalized. The 3D modeler would need to know which class object X belonged to. Well...I suppose...as usual I'm just too easily confused :-) > It's not such a big deal to me except in that I don't want the FDM to > be dealing with things it does not need to be dealing with - I want to > work towards reducing "excess baggage" from JSBSim proper. I'd be > content with moving normalization into the interface class. That's an option. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thu, 16 Dec 2004 20:47:03 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: Jon's concern is quite valid, but there are problems. As I work through these concepts in my mind, I can see that although the current method sounds more complicated for the 3D animator, having to deal with the real values could be a lot worse (at least with the current architecture). For simple aerosurface movements I fail to see how it could be anything but easier. For more difficult cases, whether you are scaling an angle or a normalized value, it should be similar. It might be useful for someone to work through the values as that would be report for the various stages of deployment on a 747 flap system. As Richard message suggests here the detail required by the 3D modeler is sometimes quite a bit more than what is required by the FDM. Also, ask yourself the question, does the normalized value of, say, 0.5 really correspond to 30 degrees of flaps when the total range is 0 to 60? Also, to have some objects reported normalized and other objects reported actual would be too confusing...even if the distinctions and reasons were logically sensible. In the long run we'll benefit the most from consistency even if it means more work at the FDM interface. Not sure I agree here. It should not be a big deal to have two subclasses, one to handle normalized and one to handle not normalized. It's not such a big deal to me except in that I don't want the FDM to be dealing with things it does not need to be dealing with - I want to work towards reducing "excess baggage" from JSBSim proper. I'd be content with moving normalization into the interface class. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Richard Harke said: > A rotation whether in degrees or radians only makes sense if the axis > of rotation is specified. This would have to be on a per aircraft basis. Also > I'm sure that many if not most control surfaces do not simply rotate about > a single axis but involve sliding motion and rotation of multiple parts > and often, rotation while sliding. This is just what was going through my mind when reading this discussion. Jon's concern is quite valid, but there are problems. As I work through these concepts in my mind, I can see that although the current method sounds more complicated for the 3D animator, having to deal with the real values could be a lot worse (at least with the current architecture). It might be useful for someone to work through the values as that would be report for the various stages of deployment on a 747 flap system. As Richard message suggests here the detail required by the 3D modeler is sometimes quite a bit more than what is required by the FDM. Also, to have some objects reported normalized and other objects reported actual would be too confusing...even if the distinctions and reasons were logically sensible. In the long run we'll benefit the most from consistency even if it means more work at the FDM interface. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thu, 16 Dec 2004 18:21:24 +0100 Gordan Sikic <[EMAIL PROTECTED]> wrote: I have seen (and I've seen more than few) control law diagrams taking some generalized input (0-1 range), taking target speed, or attitude, or something,... but havent seen any, taking as a input force that pilot has to produce. Could you pls give some pointers? I'd like to take a look; it's never to late to learn something new :) As far as the force in the stick is of concern, I've seen exactly oposite situation: one has position of the stick, speed of the stick, dynamic properties of the linkage, and all data from FDM. Using those as input, force to be produced on the stick is calculated, and generated. Look here at the X-15 data and FCS diagram: http://jsbsim.sourceforge.net/X-15Aero.html The USAF F-16 (Block 40) FCS diagram is the same way: stick force is the input. Same with Space Shuttle control Law diagrams. The JSBSim X-15 model simulates the X-15 control laws as shown in the link above. We take the -1 to +1 joystick input from FlightGear and turn it into a stick force, mapping to the force range described in Etkin's book as a sort of standard. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thu, 16 Dec 2004 11:15:52 -0800 Richard Harke <[EMAIL PROTECTED]> wrote: A rotation whether in degrees or radians only makes sense if the axis of rotation is specified. This would have to be on a per aircraft basis. Also I'm sure that many if not most control surfaces do not simply rotate about a single axis but involve sliding motion and rotation of multiple parts and often, rotation while sliding. No, this is only really relevant for the 3D model. But even complicated multi-segment flaps are indexed by degrees with respect to aero coefficients. Further, the flight control system still outputs degrees - not normalized units. Once you get to a certain level of detail of course the signal to an actuator might be in volts. How do you normalize that? For any normalized aerosurface command, you still need two pieces of data to make an absolute: the normalized value and the travel range. Plus, as I've mentioned before, if you output in degrees (or radians) you are outputting an absolute, which is also eeffectively what is require for the rendering system directly. When I did IRIX GL programming ten years ago the API call used degrees to rotate. Converting to a normalized value, then back again is a waste. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Hi, Control law block diagrams I have seen take stick input in pounds force (pilot inputs) and output in degrees to actuators. I've never seen one that output control commands to an aerosurface actuator in a range from 0 to 1. Have you? I have seen (and I've seen more than few) control law diagrams taking some generalized input (0-1 range), taking target speed, or attitude, or something,... but havent seen any, taking as a input force that pilot has to produce. Could you pls give some pointers? I'd like to take a look; it's never to late to learn something new :) As far as the force in the stick is of concern, I've seen exactly oposite situation: one has position of the stick, speed of the stick, dynamic properties of the linkage, and all data from FDM. Using those as input, force to be produced on the stick is calculated, and generated. By "natural" I mean that it's: the most commonly seen angular command unit for aerosurfaces, that it's what is used by the rendering routines to rotate 3D objects, that it completely specifies the commanded angular position without the need for a range (a range of 0 to 1 by itself specifies nothing without the definition of what the maximum is - there is no standard here for that), and much aero data is non-dimensionalised using degrees (or radians, see below). So, sorry, but based on the above description, for this application, yes, degrees are "natural". Ok, I see your point as: natural --> most common. But IMO, degrees are wrong choice; in that case I would use radians. After all, isn't the standard that RAD-ians are used deep in CPU math unit, meaning "the need for yet another conversion"? best regards, Gordan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thursday 16 December 2004 04:06, Jon Berndt wrote: > True, I've seen both. JSBSim has used both, and we accept both, but > "normalized" units are anything but normal - you have to provide a range > for it to mean anything, and as far as I can tell, there is no standard > here. It's defined on a per-aircraft basis. And, as I have pointed out > above, for aerosurfaces it requires an intermediate conversion twice. A rotation whether in degrees or radians only makes sense if the axis of rotation is specified. This would have to be on a per aircraft basis. Also I'm sure that many if not most control surfaces do not simply rotate about a single axis but involve sliding motion and rotation of multiple parts and often, rotation while sliding. I think a normalized value makes good sense. For complicated cases, on the FDM side, it can be converted into an index into a table of effective force while on the GUI side, it could index into a table of drawing routines. Just my 2 cents. Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Erik Hofman wrote: Personally, I would be in favor of using angles to describe the positions of left/right aileron, elevator, rudder and nose/tail wheel. Please, not for the wheels. Really. It doesn't probably matter too much for 3d animation if your conversion factor get's you close. However, the FAA tests actually do care about nose wheel deflection angle, so that's a good thing to get out of the FDM in degrees, not normalized values. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
> Hi, > > I agree with Norman. As long as control system is of concern, it is much > better to use normalized units. Control law block diagrams I have seen take stick input in pounds force (pilot inputs) and output in degrees to actuators. I've never seen one that output control commands to an aerosurface actuator in a range from 0 to 1. Have you? > > surface deflections in degrees, and for good reason: it's natural, it's > > physical. From the point of view of JSBSim, "normalized" aerosurface > > Degrees are not natural, nor physical. We may argude that *radians* > might be natural, but *not* degrees. By "natural" I mean that it's: the most commonly seen angular command unit for aerosurfaces, that it's what is used by the rendering routines to rotate 3D objects, that it completely specifies the commanded angular position without the need for a range (a range of 0 to 1 by itself specifies nothing without the definition of what the maximum is - there is no standard here for that), and much aero data is non-dimensionalised using degrees (or radians, see below). So, sorry, but based on the above description, for this application, yes, degrees are "natural". > This would lead us to another class of problems, what system of > measurements is used? (I'm used to SI system) or > what about input (I mean stick, pedals positions...)? > Should the input be expressed in "natural" or normalized units? I've said several times that we expect INPUTS in a range from zero to 1. We can process the inputs to arrive at a force unit to match the FCS block diagram. Note that for JSBSim we are also changing the config file format. When the next major version of JSBSim is released (early next year) supporting the new configuration file format, many items will now take a UNIT="" attribute, allowing aircraft to be defined in different unit systems. > And about FDM itself, aerodata to be used are not unified... I have seen > some using degrees as a control surface deflections units, and others > using radians. What would you choose as a "natural"? True, I've seen both. JSBSim has used both, and we accept both, but "normalized" units are anything but normal - you have to provide a range for it to mean anything, and as far as I can tell, there is no standard here. It's defined on a per-aircraft basis. And, as I have pointed out above, for aerosurfaces it requires an intermediate conversion twice. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Curtis L. Olson wrote: I think we are limiting the discussion here to only flying control surface positions, i.e. - left aileron deflection - right aileron deflection - elevator deflection - rudder deflection - nose/tail wheel deflection. I wouldn't like this one to end up in degrees. Not because it isn't possible, but because it is very hard to match the 3d model with the real number. You will always need to cheat with the deflection angles to get it properly inside the fuselage. - various flap deflections - various spoiler deflections. However, what about slats which often deploy linearly rather than via a rotation. What about speed brakes that deploy linearly rather than via rotation. Even flaps themselves can be a complex combination of pieces that move together and don't necessarily have one particular angle you can assign to them. Yep, getting slotted flaps to animate properly using animations is quite a bit harder using degrees. Personally, I would be in favor of using angles to describe the positions of left/right aileron, elevator, rudder and nose/tail wheel. Please, not for the wheels. Really. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Hi, I agree with Norman. As long as control system is of concern, it is much better to use normalized units. > surface deflections in degrees, and for good reason: it's natural, it's > physical. From the point of view of JSBSim, "normalized" aerosurface Degrees are not natural, nor physical. We may argude that *radians* might be natural, but *not* degrees. This would lead us to another class of problems, what system of measurements is used? (I'm used to SI system) or what about input (I mean stick, pedals positions...)? Should the input be expressed in "natural" or normalized units? And about FDM itself, aerodata to be used are not unified... I have seen some using degrees as a control surface deflections units, and others using radians. What would you choose as a "natural"? I think normalized deflections *are* the best solution. just my 2$ :) cheers, Gordan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Hi, Since flightgears animation engine can now use interpolation tables where you can map any range linearly to any other range I think that normalization is not that important anymore. Anyway, my F-18 uses degrees for every *internally* used surface deflection. The values used for animations are later scaled by a gain component to normalize them. That is, once you implememented a gain component, you do not need to care for that anymore ... :) Greetings Mathias On Mittwoch 15 Dezember 2004 14:08, Jon Berndt wrote: > Do 3D models use a "normalized" range to model aerosurface rotation, or > actual degree magnitude? I've been looking at the JSBSim flight control > code and the addition of the code that "normalizes" aerosurface (elevator, > aileron, etc.) rotation positions confuses the code, and appears to only be > relevant to 3D modeling. > > It was my opinion that rotations are done using actual degree measurement - > that is, you can't specify an angular rotation in a range of 0 to 1 and > have it mean anything at all. A rotation needs to be done over an angular > range that is known, such as degrees or radians. > > I'd like to remove the code that normalizes angular measurement, but I am > told that FlightGear requires normalized angular measurement, which seems, > on teh surface, ridiculous. At the very least, I'd like to move the > normalization code out of our flight controls code and into the flightgear > interface code, since it appears to be a requirement of FlightGear only. > > Jon > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Vivian Meazza writes: > > Perhaps some of our longer standing developers can shed some light on the > background to this important decision. This was the easiest way to implement the system at the time insuring that only 'sane' values were ever passed. ie 'clamped' An alternative method would be to have all the extreme values default to some safe value and to have these actually set in the individual aircraft files. The controls themselves would probably be best implemented as pure 'property objects'. This would be a much more flexible system but would require a fair bit of work to implement. This would also add to the complexity of the aircraft definition files. Neither of these are show stoppers. The current method obviously works so so this requires someone with a strong incentive to make the change to step up and take on the job FWIW I suggest that the new property tree be fully fleshed out ahead of time before any code was actually changed. Note The FGFS code would then become nothing more but but a means for the FDMs to access the property tree values Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Vivian Meazza > > > 3. For consistency, and remember that some 3d models are used with > > > both YASim and other FDMs, we need normalized values. > > > > This is just plain wrong. If an aircraft can deflect the elevator +/- > > 30 degrees that's the way it is. Regardless of FDM. We are talking > > about absolutes, here, not some arbitrary limit decided upon by the > > FDM. Even if the FDMs use different values for elevator deflection > > limits, the aircraft would fly based on the deflection actually made, > > and the 3D model will show what the FDM says it is flying to. Item #3 > > here is a non-issue. > > I don't think so. YASim can only output a normalized value, since we don't > tell it what the input angle is, although I'm not clear if we _can_. I > don't > think we want different interpretations for different FDMs, otherwise we > will have to have different animations for different FDMs. My instinct > tells > me that YASim has it right here, because it is intended for aircraft > I meant to add: 'about which we have limited data.' Getting late here :-) Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Curt wrote: But Jon, this statement seems to run counter to your overall argument. Slats at least on many of the aircraft I've seen deploy linearly. In other words they are on some sort of rail mechanism and slide out away from the leading edge of the wing in a linear motion. They aren't attached with a hinge, there's no rotation at all. So in this case representing linear motion with some arbitrary angle seems a lot worse than representing angles with normalized values. You're right - I had in my mind that we were discussing spoilers - not slats. Slats could be similar to landing gear, working in a 0 to 1 range. In the case of YAsim, you may need to dig in and get a better understanding of it, but essentially, the way it works, it does not need to know deflection angles. Yes, I'm sure it's a pretty good approximation, but IMHO this is sloppy. In flight simulation you want to know deflection angles for any of a number of reasons. And, again, in some flight control systems you might have hardware or software limits placed on the aerosurface excursions. Does YASim arbitrarily choose the limits? Which limits? Where does the rendering system get the limits so it knows what the maximum travel means? The point is: if you take angular deflections from the FDM, you have all you need right there; angular measurements are used to do the drawing. If YASim specifies some range of travel that represents full deflection, then it can also easily pass you degrees deflection for an elevator, for instance. As you pointed out earlier, elevator, rudder, aileron, flaps - those items are always or almost entirely always referenced in angular units - exactly the units needed for drawing, and native units that the FDM outputs. It seems to me that it would be polluting the property tree to provide these in normalized coordinates. I think what I'd like to do for now is to put the normalization for these parameters outside of JSBSim and into the FGJSBSim interface code. But, I'll look at that some more before doing so. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Jon S Berndt wrote: > On Wed, 15 Dec 2004 18:22:30 - > "Vivian Meazza" <[EMAIL PROTECTED]> wrote: > > > There are several points here. > > > > 1. The fact is that most 3d (I think all, but I haven't checked) > > rightly or wrongly already use normalized values. It would be a > > significant task to change. > > Agreed. This is a consideration. If the FDMs can divest themselves of > the need to provide normalized values, I don't care what is done on > the other side of FGInterface. > > > 2. I don't think we tell YASim the correct angles to use. Therefore > > the normalized output, factored to produce the correct visual angles, > > is the way to do it right now. > > How does YASim know how far an aileron can deflect? How does > FlightGear know how far to deflect the aileron? The FDM needs to know > and use control surface deflection in degrees (or radians) - > normalized values won't cut it for flight modeling. Since the FDM > knows "truth", it can be the one-stop supplier for this angle - rather > than normalizing it (based on what?) and shipping that to > FlightGear/SimGear where it must be told how to de-normalize the > normalized value for display. Andy Ross will be able to explain this better than I, but my understanding is that YASim applies a proportion of the appropriate force. > > 3. For consistency, and remember that some 3d models are used with > > both YASim and other FDMs, we need normalized values. > > This is just plain wrong. If an aircraft can deflect the elevator +/- > 30 degrees that's the way it is. Regardless of FDM. We are talking > about absolutes, here, not some arbitrary limit decided upon by the > FDM. Even if the FDMs use different values for elevator deflection > limits, the aircraft would fly based on the deflection actually made, > and the 3D model will show what the FDM says it is flying to. Item #3 > here is a non-issue. I don't think so. YASim can only output a normalized value, since we don't tell it what the input angle is, although I'm not clear if we _can_. I don't think we want different interpretations for different FDMs, otherwise we will have to have different animations for different FDMs. My instinct tells me that YASim has it right here, because it is intended for aircraft > > 4. It doesn't matter where the conversion is done. If FG is the only > > user of normalized values, it makes sense to do it there. > > Yes, and that's my point. But there is a little more to it than that - > it's about accuracy. If the FDMs abandon the provision of normalized > values, what will FlightGear do with what is provided? If JSBSim sends > FlightGear a 20 degree elevator deflection, what does it normalize > that value based on? FlightGear will need to be provided with the > maximum travel for aerosurfaces. Since teh FDM will also work with > these maximums, this could introduce another "point of failure". If you don't want to do the conversion in the FDM, then you will need to pass max deflection to FG, otherwise leave it where it is. What about landing gear, arrester hooks etc. etc? It makes sense to me to use a single standard for all moving items which can be animated, but we can work around it. > > I have no doubt that this point was vigorously debated at some point > > in the past, and for good reasons we are where we are. We need to > > revisit those discussions and revalidate the decisions before making > > any change. > > I would think we would have discussed this in the past, but I don't > remember having done so. Normalized values were introduced in JSBSim > about 2 years and 9 months ago, according to our CVS logs. Perhaps some of our longer standing developers can shed some light on the background to this important decision. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Wed, 15 Dec 2004 14:51:07 -0500 "Norman Vine" <[EMAIL PROTECTED]> wrote: Jon S Berndt writes: This is irrelevant, also - at least for JSBSim. That is an excellent observation FGFS is more then JSBSim though :-) Norman Absolutely. And JSBSim is used by more than FlightGear - which leads to part of the concern I have. FlightGear should not require the FDM to massage values that it should be massaging itself. Object-oriented design has been referred to as the "the elimination of the irrelevant and the amplification of the essential". All FDMs I have worked with or am aware of (except, perhaps YASim) output control surface deflections in degrees, and for good reason: it's natural, it's physical. From the point of view of JSBSim, "normalized" aerosurface deflections are unnatural and irrelevant. The overhead and baggage code causes confusion and obfuscates the operation of flight control code. It clutters the code. I have no problem with FlightGear doing whatever it wants to with the values we send, but I remain skeptical about using "normalized" values as a "common transport device" for the actual physical value. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
John Wojnaroski wrote: Not quite, these slats are air-loaded; i.e, there is no mechanical, hydraulic, or electrical actuation of the slats. There is no command or logic in the FCS, air data computer, or crew activation to extend the slats. Part of the walk-around is to physically push the slats up and see that they drop freely. I don't think there are any aircraft currently modeled that have this sort of slat system, so the point may be mute. The Helio Courier (which I'd love to see modeled some day) uses this same leading edge slat arrangement. The slats are divided in half on each wing so there are actually 4 independent pieces. These are aero-loaded and drop down at different times depending on small differences in friction, and differences in slip and air currents. It's a bit disconcerting if you aren't expecting it though ... they bang down rather loudly when they go. These same aircraft also have a small spoiler near the end of each wing that deploys in low speed configurations to help maintain roll attitude. These things can do steep (controlled) 45 degree banked "S" turns at 35kts. The spoiler is a small piece of metal that extends vertically out of the wing ... their's no rotational or hinge aspect to it, yet it's tied to the "wheel" or aileron control. The Helio is really a nifty little airplane for what it's worth. Here's a couple pictures: Leading edge slat deployed: http://www.chamoismoon.com/Resources/Helio/Cameramount_Sony-HDC500.jpg ttp://www.chamoismoon.com/Resources/Helio/64V_Mariposa.jpg Taking off: http://forums.alphaetarho.org/?q=node/view/49 Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Jon S Berndt writes: > > Absolutely. And JSBSim is used by more than FlightGear - which leads > to part of the concern I have. FlightGear should not require the FDM > to massage values that it should be massaging itself. Just need a translation layer IIRC 'Normalized Control Units' have been in FGFS for at least 5 years probably more like 7 or 8. not to say that this can't be changed but ... Anyway I will go back to lurk status Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Wed, 15 Dec 2004 14:51:07 -0500 "Norman Vine" <[EMAIL PROTECTED]> wrote: Jon S Berndt writes: This is irrelevant, also - at least for JSBSim. That is an excellent observation FGFS is more then JSBSim though :-) Norman Absolutely. And JSBSim is used by more than FlightGear - which leads to part of the concern I have. FlightGear should not require the FDM to massage values that it should be massaging itself. Object-oriented design has been referred to as the "the elimination of the irrelevant and the amplification of the essential". All FDMs I have worked with or am aware of (except, perhaps YASim) output control surface deflections in degrees, and for good reason: it's natural, it's physical. From the point of view of JSBSim, "normalized" aerosurface deflections are unnatural and irrelevant. The overhead and baggage code causes confusion and obfuscates the operation of flight control code. It clutters the code. I have no problem with FlightGear doing whatever it wants to with the values we send, but I remain skeptical about using "normalized" values as a "common transport device" for the actual physical value. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Wed, 15 Dec 2004 14:51:07 -0500 "Norman Vine" <[EMAIL PROTECTED]> wrote: Jon S Berndt writes: This is irrelevant, also - at least for JSBSim. That is an excellent observation FGFS is more then JSBSim though :-) Norman Absolutely. And JSBSim is used by more than FlightGear - which leads to part of the concern I have. FlightGear should not require the FDM to massage values that it should be massaging itself. Object-oriented design has been referred to as the "the elimination of the irrelevant and the amplification of the essential". All FDMs I have worked with or am aware of (except, perhaps YASim) output control surface deflections in degrees, and for good reason: it's natural, it's physical. From the point of view of JSBSim, "normalized" aerosurface deflections are unnatural and irrelevant. The overhead and baggage code causes confusion and obfuscates the operation of flight control code. It clutters the code. I have no problem with FlightGear doing whatever it wants to with the values we send, but I remain skeptical about using "normalized" values as a "common transport device" for the actual physical value. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon S Berndt wrote: On Wed, 15 Dec 2004 11:16:32 -0800 "John Wojnaroski" <[EMAIL PROTECTED]> wrote: And then there are slats that deploy as a function of airspeed/AOA; e.g; Sabreliners This is irrelevant, also - at least for JSBSim. In this case, the slats would be automatically deployed as directed by the flight control system control laws, and the actual position would be referenced by degrees. But Jon, this statement seems to run counter to your overall argument. Slats at least on many of the aircraft I've seen deploy linearly. In other words they are on some sort of rail mechanism and slide out away from the leading edge of the wing in a linear motion. They aren't attached with a hinge, there's no rotation at all. So in this case representing linear motion with some arbitrary angle seems a lot worse than representing angles with normalized values. In the case of YAsim, you may need to dig in and get a better understanding of it, but essentially, the way it works, it does not need to know deflection angles. You provide a lift and drag multiplier at full surface deflection and that is all. Internally YAsim keep the control inputs and surface positions normalized. This is a simplification of reality of course, but it actually works quite well. YAsim is a different approach to modeling flight, but it is quite ingenious, and does a really nice job for what it does. There's a limit to how far you can take it, but until you hit that limit, it's really a slick little piece of code. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
- Original Message - From: "Jon S Berndt" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" <[EMAIL PROTECTED]> Sent: Wednesday, December 15, 2004 11:30 AM Subject: Re: [Flightgear-devel] control surface normalization > On Wed, 15 Dec 2004 11:16:32 -0800 > "John Wojnaroski" <[EMAIL PROTECTED]> wrote: > >> > > And then there are slats that deploy as a function of airspeed/AOA; > > e.g; Sabreliners > > This is irrelevant, also - at least for JSBSim. In this case, the > slats would be automatically deployed as directed by the flight > control system control laws, and the actual position would be > referenced by degrees. > Not quite, these slats are air-loaded; i.e, there is no mechanical, hydraulic, or electrical actuation of the slats. There is no command or logic in the FCS, air data computer, or crew activation to extend the slats. Part of the walk-around is to physically push the slats up and see that they drop freely. I don't think there are any aircraft currently modeled that have this sort of slat system, so the point may be mute. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Jon S Berndt writes: > > > This is irrelevant, also - at least for JSBSim. That is an excellent observation FGFS is more then JSBSim though :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Wed, 15 Dec 2004 11:16:32 -0800 "John Wojnaroski" <[EMAIL PROTECTED]> wrote: And then there are slats that deploy as a function of airspeed/AOA; e.g; Sabreliners This is irrelevant, also - at least for JSBSim. In this case, the slats would be automatically deployed as directed by the flight control system control laws, and the actual position would be referenced by degrees. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Wednesday 15 December 2004 18:22, Vivian Meazza wrote: > Jon S Berndt wrote: > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:flightgear-devel- [EMAIL PROTECTED] On Behalf > > Of > > Sent: 15 December 2004 17:34 > > To: FlightGear developers discussions > > Subject: Re: [Flightgear-devel] control surface > > normalization > > > > On Wed, 15 Dec 2004 17:21:13 - > > > > "Vivian Meazza" <[EMAIL PROTECTED]> wrote: > > > A quick search revealed that most, if not all, the 3d > > > models in the current inventory use normalized values for > > > animating the control surfaces. > > > > See, this further raises a red flag for me. How does the 3D > > model know how far to move the aerosurface? What does the > > "normalized value" represent? This requires (like the VRP) > > more communication between the flight modeler and the 3D > > modeler. Are they both using the same values for the maximum > > angular range for an aerosruface - that is, the value that > > "1" represents? There are software limits. There are > > hardware limits. Which one is being used by the 3D modeler? > > It seems to me that the sensible thing to do is to simply > > use the angular value provided by the FDM - the one that is > > being used to determine the forces and moments. To do > > otherwise invites errors and confusion, IMHO. > > There are several points here. > > 1. The fact is that most 3d (I think all, but I haven't > checked) rightly or wrongly already use normalized values. It > would be a significant task to change. > > 2. I don't think we tell YASim the correct angles to use. > Therefore the normalized output, factored to produce the > correct visual angles, is the way to do it right now. > > 3. For consistency, and remember that some 3d models are used > with both YASim and other FDMs, we need normalized values. > > 4. It doesn't matter where the conversion is done. If FG is > the only user of normalized values, it makes sense to do it > there. > > I have no doubt that this point was vigorously debated at some > point in the past, and for good reasons we are where we are. > We need to revisit those discussions and revalidate the > decisions before making any change. > > Regards, > > Vivian I think that normalised values for flight-surface values might be vital for YASim - we'd probably have to check with Andy Ross. It seems to me that because YASim generates an aircraft with characteristics to match the config, the actual number of degrees that a flap, for example, is rotated is irrelevant - all it needs to know is the degree of effect to produce for settings between nil and full deflection. Actually getting the animation right is easy if the real deflection angles/distances are known. For example, if full flap deflection on an a/c is 35 degrees then a factor of 35 should be used in the animation. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
> > But when it comes to flaps, slats, and speed brakes it's not nearly so > simple. There, normalized values make a lot of sense. But then to > follow along with the logic, do we want to output our control surface > positions in one consistent way, or do we want to mix and match units, > and if we do, what if we come across some oddball aircraft where the > control surface angle is a completely non-sensical concept? > And then there are slats that deploy as a function of airspeed/AOA; e.g; Sabreliners Regards John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Wed, 15 Dec 2004 18:22:30 - "Vivian Meazza" <[EMAIL PROTECTED]> wrote: There are several points here. 1. The fact is that most 3d (I think all, but I haven't checked) rightly or wrongly already use normalized values. It would be a significant task to change. Agreed. This is a consideration. If the FDMs can divest themselves of the need to provide normalized values, I don't care what is done on the other side of FGInterface. 2. I don't think we tell YASim the correct angles to use. Therefore the normalized output, factored to produce the correct visual angles, is the way to do it right now. How does YASim know how far an aileron can deflect? How does FlightGear know how far to deflect the aileron? The FDM needs to know and use control surface deflection in degrees (or radians) - normalized values won't cut it for flight modeling. Since the FDM knows "truth", it can be the one-stop supplier for this angle - rather than normalizing it (based on what?) and shipping that to FlightGear/SimGear where it must be told how to de-normalize the normalized value for display. 3. For consistency, and remember that some 3d models are used with both YASim and other FDMs, we need normalized values. This is just plain wrong. If an aircraft can deflect the elevator +/- 30 degrees that's the way it is. Regardless of FDM. We are talking about absolutes, here, not some arbitrary limit decided upon by the FDM. Even if the FDMs use different values for elevator deflection limits, the aircraft would fly based on the deflection actually made, and the 3D model will show what the FDM says it is flying to. Item #3 here is a non-issue. 4. It doesn't matter where the conversion is done. If FG is the only user of normalized values, it makes sense to do it there. Yes, and that's my point. But there is a little more to it than that - it's about accuracy. If the FDMs abandon the provision of normalized values, what will FlightGear do with what is provided? If JSBSim sends FlightGear a 20 degree elevator deflection, what does it normalize that value based on? FlightGear will need to be provided with the maximum travel for aerosurfaces. Since teh FDM will also work with these maximums, this could introduce another "point of failure". I have no doubt that this point was vigorously debated at some point in the past, and for good reasons we are where we are. We need to revisit those discussions and revalidate the decisions before making any change. I would think we would have discussed this in the past, but I don't remember having done so. Normalized values were introduced in JSBSim about 2 years and 9 months ago, according to our CVS logs. Best regards, Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Jon S Berndt wrote: > -Original Message- > From: [EMAIL PROTECTED] [mailto:flightgear-devel- > [EMAIL PROTECTED] On Behalf Of > Sent: 15 December 2004 17:34 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] control surface normalization > > On Wed, 15 Dec 2004 17:21:13 - > "Vivian Meazza" <[EMAIL PROTECTED]> wrote: > > > A quick search revealed that most, if not all, the 3d models in the > > current inventory use normalized values for animating the control > > surfaces. > > See, this further raises a red flag for me. How does the 3D model know > how far to move the aerosurface? What does the "normalized value" > represent? This requires (like the VRP) more communication between the > flight modeler and the 3D modeler. Are they both using the same values > for the maximum angular range for an aerosruface - that is, the value > that "1" represents? There are software limits. There are hardware > limits. Which one is being used by the 3D modeler? It seems to me that > the sensible thing to do is to simply use the angular value provided > by the FDM - the one that is being used to determine the forces and > moments. To do otherwise invites errors and confusion, IMHO. There are several points here. 1. The fact is that most 3d (I think all, but I haven't checked) rightly or wrongly already use normalized values. It would be a significant task to change. 2. I don't think we tell YASim the correct angles to use. Therefore the normalized output, factored to produce the correct visual angles, is the way to do it right now. 3. For consistency, and remember that some 3d models are used with both YASim and other FDMs, we need normalized values. 4. It doesn't matter where the conversion is done. If FG is the only user of normalized values, it makes sense to do it there. I have no doubt that this point was vigorously debated at some point in the past, and for good reasons we are where we are. We need to revisit those discussions and revalidate the decisions before making any change. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Wed, 15 Dec 2004 12:30:25 -0500 "Norman Vine" <[EMAIL PROTECTED]> wrote: Curtis L. Olson writes: I think we are limiting the discussion here to only flying control surface positions, i.e. As you point out those are only a small subset of the Control class abstaction. So specialize these if esired but IMO the 'slippery slope principal' is in play here It's a matter of not trying to fit a square peg into a round hole. Consideration of a subclass here is warranted. BTW It is peculiar how one of the argument for using degrees "because it cuts down on 'conversion code'" in SimGear is not applied to using for Geocentric Coordinates internally as SimGear and the FDMs go to great pains to pass everything as lat lons which requires duplicate conversions on both ends of the pipe :-) ?? Not sure I can parse this sentence. Can you rephrase? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Wed, 15 Dec 2004 17:21:13 - "Vivian Meazza" <[EMAIL PROTECTED]> wrote: A quick search revealed that most, if not all, the 3d models in the current inventory use normalized values for animating the control surfaces. See, this further raises a red flag for me. How does the 3D model know how far to move the aerosurface? What does the "normalized value" represent? This requires (like the VRP) more communication between the flight modeler and the 3D modeler. Are they both using the same values for the maximum angular range for an aerosruface - that is, the value that "1" represents? There are software limits. There are hardware limits. Which one is being used by the 3D modeler? It seems to me that the sensible thing to do is to simply use the angular value provided by the FDM - the one that is being used to determine the forces and moments. To do otherwise invites errors and confusion, IMHO. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Wed, 15 Dec 2004 12:01:23 -0500 "Norman Vine" <[EMAIL PROTECTED]> wrote: It is realy quite simple you either have 1) an abstract class with 'Normalized units' class Control or 2) a bunch of specalized classes class Angle_Controller class Toggle_Controller class Percentage_Controller etc . Both schemes have advantages Quick question Do valves take 1 or 2 full rotations of the handle to fully open ? Yes, I agree that there are output (from the FDM perspective) parameters that operate on a 0 to 1 basis. Even in our aero coefficient specification, landing gear effects, for example, are based on a 0 to 1 range. Aerosurfaces are different, though. Plain flap deployment is referenced via angle. Even complex flap arrangements are referenced by angular measurement in degrees - I have not personally seen nor heard of flaps being referenced via a 0 to 1 normalized range. Spoilers also are referenced in degrees, from what I have seen (maybe Dave Culp can chime in here, and Tony). I think there is a use for both types of actuators, both linear and angular. I'd much rather see them referenced via native (or "more native") variables. Also, again your (valve) example is for an input control, not an output control that is fully defined by a subsystem (FDM). We (FDM) take normalized joystick inputs (0 to 1) because there are many joystick types and it makes sense to accept a zero or 1 and turn that into the value we need. We have control over that. We don't need to add special code for that. But our output for aerosurfaces is (like I said before) in the lowest common denominator value when we can ship it out - in degrees. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Curtis L. Olson writes: > > I think we are limiting the discussion here to only flying control > surface positions, i.e. As you point out those are only a small subset of the Control class abstaction. So specialize these if esired but IMO the 'slippery slope principal' is in play here BTW It is peculiar how one of the argument for using degrees "because it cuts down on 'conversion code'" in SimGear is not applied to using for Geocentric Coordinates internally as SimGear and the FDMs go to great pains to pass everything as lat lons which requires duplicate conversions on both ends of the pipe :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Jon Berndt > Do 3D models use a "normalized" range to model aerosurface rotation, or > actual degree > magnitude? I've been looking at the JSBSim flight control code and the > addition of the > code that "normalizes" aerosurface (elevator, aileron, etc.) rotation > positions confuses > the code, and appears to only be relevant to 3D modeling. A quick search revealed that most, if not all, the 3d models in the current inventory use normalized values for animating the control surfaces. > It was my opinion that rotations are done using actual degree measurement > - that is, you > can't specify an angular rotation in a range of 0 to 1 and have it mean > anything at all. A > rotation needs to be done over an angular range that is known, such as > degrees or radians. > > I'd like to remove the code that normalizes angular measurement, but I am > told that > FlightGear requires normalized angular measurement, which seems, on teh > surface, > ridiculous. At the very least, I'd like to move the normalization code out > of our flight > controls code and into the flightgear interface code, since it appears to > be a requirement > of FlightGear only. To avoid a sizeable conversion task, all we need is a property containing the normalized value, so this seems like a sensible suggestion to me. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Norman Vine wrote: Curtis L. Olson writes: Jon S Berndt wrote: Your example is irrelevant. Fluid pressure cannot be seen. Amps cannot be seen. Neither Amps nor fluid pressure are reported on a zero to one scale. Aerosurfaces can be drawn and seen, and that's not done on a zero to one basis either. Like I said, there are some things that can be done on a zero to one basis, such as landing gear deployment. But, aerosurfaces are reported in degrees, regardless of whatever aircraft it is, it's already "generalized" to its lowest common denominator. Why it should be further "reduced" and then reassembled to the exact same value (one hopes) later on when rendered via SimGear - that's defies description, IMHO. It is true that we can pollute our code (a.k.a. "implement wrappers") to satisfy FlightGear, but why? We know what the control surface limits are. So, what do we do? Pass a normalized value AND the aerosurface limits so they can be reconstructed later? Why not just pass the raw value and be done with it? Code that massages physical parameters to make up for shortcomings in the rendering/animation system doesn't belong in the FDM. If it doesn't belong in SimGear or on the FlightGear side, it belongs in the FGInterface class - but I don't think it even belongs there. I know this sounds "forceful", and I don't mean to step on any toes here, I just feel strongly about this. For what it's worth, I recall there being some sort of substantial discussion at the time this was implemented, I just don't recall what that discussion consisted of. I tend to support your position John, however, let's not act too hastily because a lot of code and animation depends on this behavior. It is realy quite simple you either have 1) an abstract class with 'Normalized units' class Control or 2) a bunch of specalized classes class Angle_Controller class Toggle_Controller class Percentage_Controller etc . Both schemes have advantages Quick question Do valves take 1 or 2 full rotations of the handle to fully open ? I think we are limiting the discussion here to only flying control surface positions, i.e. - left aileron deflection - right aileron deflection - elevator deflection - rudder deflection - nose/tail wheel deflection. - various flap deflections - various spoiler deflections. However, what about slats which often deploy linearly rather than via a rotation. What about speed brakes that deploy linearly rather than via rotation. Even flaps themselves can be a complex combination of pieces that move together and don't necessarily have one particular angle you can assign to them. Personally, I would be in favor of using angles to describe the positions of left/right aileron, elevator, rudder and nose/tail wheel. But when it comes to flaps, slats, and speed brakes it's not nearly so simple. There, normalized values make a lot of sense. But then to follow along with the logic, do we want to output our control surface positions in one consistent way, or do we want to mix and match units, and if we do, what if we come across some oddball aircraft where the control surface angle is a completely non-sensical concept? Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Curtis L. Olson writes: > > Jon S Berndt wrote: > > > Your example is irrelevant. Fluid pressure cannot be seen. Amps cannot > > be seen. Neither Amps nor fluid pressure are reported on a zero to one > > scale. Aerosurfaces can be drawn and seen, and that's not done on a > > zero to one basis either. Like I said, there are some things that can > > be done on a zero to one basis, such as landing gear deployment. But, > > aerosurfaces are reported in degrees, regardless of whatever aircraft > > it is, it's already "generalized" to its lowest common denominator. > > Why it should be further "reduced" and then reassembled to the exact > > same value (one hopes) later on when rendered via SimGear - that's > > defies description, IMHO. > > > > It is true that we can pollute our code (a.k.a. "implement wrappers") > > to satisfy FlightGear, but why? We know what the control surface > > limits are. So, what do we do? Pass a normalized value AND the > > aerosurface limits so they can be reconstructed later? Why not just > > pass the raw value and be done with it? > > > > Code that massages physical parameters to make up for shortcomings in > > the rendering/animation system doesn't belong in the FDM. If it > > doesn't belong in SimGear or on the FlightGear side, it belongs in the > > FGInterface class - but I don't think it even belongs there. > > > > I know this sounds "forceful", and I don't mean to step on any toes > > here, I just feel strongly about this. > > > For what it's worth, I recall there being some sort of substantial > discussion at the time this was implemented, I just don't recall what > that discussion consisted of. I tend to support your position John, > however, let's not act too hastily because a lot of code and animation > depends on this behavior. It is realy quite simple you either have 1) an abstract class with 'Normalized units' class Control or 2) a bunch of specalized classes class Angle_Controller class Toggle_Controller class Percentage_Controller etc . Both schemes have advantages Quick question Do valves take 1 or 2 full rotations of the handle to fully open ? Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon S Berndt wrote: Your example is irrelevant. Fluid pressure cannot be seen. Amps cannot be seen. Neither Amps nor fluid pressure are reported on a zero to one scale. Aerosurfaces can be drawn and seen, and that's not done on a zero to one basis either. Like I said, there are some things that can be done on a zero to one basis, such as landing gear deployment. But, aerosurfaces are reported in degrees, regardless of whatever aircraft it is, it's already "generalized" to its lowest common denominator. Why it should be further "reduced" and then reassembled to the exact same value (one hopes) later on when rendered via SimGear - that's defies description, IMHO. It is true that we can pollute our code (a.k.a. "implement wrappers") to satisfy FlightGear, but why? We know what the control surface limits are. So, what do we do? Pass a normalized value AND the aerosurface limits so they can be reconstructed later? Why not just pass the raw value and be done with it? Code that massages physical parameters to make up for shortcomings in the rendering/animation system doesn't belong in the FDM. If it doesn't belong in SimGear or on the FlightGear side, it belongs in the FGInterface class - but I don't think it even belongs there. I know this sounds "forceful", and I don't mean to step on any toes here, I just feel strongly about this. For what it's worth, I recall there being some sort of substantial discussion at the time this was implemented, I just don't recall what that discussion consisted of. I tend to support your position John, however, let's not act too hastily because a lot of code and animation depends on this behavior. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Wed, 15 Dec 2004 10:41:27 -0500 "Norman Vine" <[EMAIL PROTECTED]> wrote: Jim Wilson writes: And the Simgear 3D animation code is all about taking those normalized values and translating them to a representation of degrees movement. On the surface, this doesn't make sense to me either. I can think of no other generalized expression of a 'control's state' whether it be rotation, fluid pressure, amps what ever :-) Once you start specializing there is no end and IMO using the Normalized Values makes perfect sense for the abstract Control Module. Simple translators from Normallized to Actual value are all that is needed and are already instantiated on the FGFS side. Client applications such a JSBSim can easily implement wrappers when talking to FGFS Your example is irrelevant. Fluid pressure cannot be seen. Amps cannot be seen. Neither Amps nor fluid pressure are reported on a zero to one scale. Aerosurfaces can be drawn and seen, and that's not done on a zero to one basis either. Like I said, there are some things that can be done on a zero to one basis, such as landing gear deployment. But, aerosurfaces are reported in degrees, regardless of whatever aircraft it is, it's already "generalized" to its lowest common denominator. Why it should be further "reduced" and then reassembled to the exact same value (one hopes) later on when rendered via SimGear - that's defies description, IMHO. It is true that we can pollute our code (a.k.a. "implement wrappers") to satisfy FlightGear, but why? We know what the control surface limits are. So, what do we do? Pass a normalized value AND the aerosurface limits so they can be reconstructed later? Why not just pass the raw value and be done with it? Code that massages physical parameters to make up for shortcomings in the rendering/animation system doesn't belong in the FDM. If it doesn't belong in SimGear or on the FlightGear side, it belongs in the FGInterface class - but I don't think it even belongs there. I know this sounds "forceful", and I don't mean to step on any toes here, I just feel strongly about this. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Jim Wilson writes: > > Jon Berndt said: > > > Do 3D models use a "normalized" range to model aerosurface rotation, or > actual degree > > magnitude? I've been looking at the JSBSim flight control code and the > addition of the > > code that "normalizes" aerosurface (elevator, aileron, etc.) rotation > positions confuses > > the code, and appears to only be relevant to 3D modeling. > > And the Simgear 3D animation code is all about taking those normalized values > and translating them to a representation of degrees movement. On the surface, > this doesn't make sense to me either. I can think of no other generalized expression of a 'control's state' whether it be rotation, fluid pressure, amps what ever :-) Once you start specializing there is no end and IMO using the Normalized Values makes perfect sense for the abstract Control Module. Simple translators from Normallized to Actual value are all that is needed and are already instantiated on the FGFS side. Client applications such a JSBSim can easily implement wrappers when talking to FGFS my-two-cents'ly-yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
> And the Simgear 3D animation code is all about taking those normalized values > and translating them to a representation of degrees movement. On the surface, > this doesn't make sense to me either. > > Changing this on the FlightGear end and making the other FDMs compatible is > quite a task though. The biggest part...I think...would be fixing the ac > animations after all the FDMs were in sync. There ought to be a way to provide "raw" values that SimGear would not need to massage - simple degree measurements. Providing that parallel capability might be a start? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon Berndt said: > Do 3D models use a "normalized" range to model aerosurface rotation, or actual degree > magnitude? I've been looking at the JSBSim flight control code and the addition of the > code that "normalizes" aerosurface (elevator, aileron, etc.) rotation positions confuses > the code, and appears to only be relevant to 3D modeling. And the Simgear 3D animation code is all about taking those normalized values and translating them to a representation of degrees movement. On the surface, this doesn't make sense to me either. Changing this on the FlightGear end and making the other FDMs compatible is quite a task though. The biggest part...I think...would be fixing the ac animations after all the FDMs were in sync. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
