[Flightgear-devel] moving hotspots?
Is it possible to have hotspots on moving objects like the stick throttle? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maik Justus Sent: Monday, July 31, 2006 4:06 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] heli simulation update ready for cvs? Hi, there was a bug in the diff file (I have deleted some debug code directly in the diff file...). Please use this file instead of the diff file enclosed in the archive. Maik Maik Justus schrieb: Hello, for my part the update of the yasim heli simulation is ready for cvs. Andy: therefore I want to ask you for a review of the patch and your agreement to add this to cvs or a list of necessary modifications or (hopefully not) a clear no. The heli add on is not fully finished now, but the missings will have only very small impact to the flight dynamic. The only upcoming modification with impact to the xml configuration files of the helicopters will be the connection to the yasim engines. Probably I will do this by a rotorgear tag, which will be a modified propeller tag acting as an interface between one engine and all the rotors. But I need further modifications, because now there is no governor for the engines. For constant rpm propeller the incidence is varied to get the constant rpm, for a rotor the power must be modified to get constant rpm. And simulation of multi engine helicopters should be done by more than one engine... I have decided to include the patch directly to this mail due to the quite small size. I have to say thank you to Melchior for his assistance testing and improving this patch. Maik - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] heli simulation update ready for cvs?
Hi Andy, thank you for reviewing the patch. Andy Ross wrote: Maik Justus wrote: for my part the update of the yasim heli simulation is ready for cvs. Andy: therefore I want to ask you for a review of the patch and your agreement to add this to cvs or a list of necessary modifications or (hopefully not) a clear no. OK, here's a quick review of the stuff I don't like. There are no comments here on the Rotor* files. Those are 100% yours and really not my business to complain about. :) Explain why the changes to Surface.cpp are needed? The comments about stall lift are incorrect -- YASim does not attenuate lift at stall to zero. my impression was, that a stab is not producing forces perpendicular to its surface, when the wind is blowing perpendicular to its surface, as it is for the hstab for a helicopter in hover (valid only for helictopters with the hstab beneath the rotor). I think that this is to the fact, that stallMul becomes one for this case and therefore stallLift = (stallMul - 1) * _cz * out[2] becomes zero. This conditions will not occur in a plane and therefore this had no visible impact to planes. And why do you need incidence values to be non-small angles? If that's the requirement, then it would be better to have an implementation that can rotate the surface orientation instead. Doing it here loks like a hack. Do you actually need these changes for the helicopter code? Why? The fuselage is simulated as a open tube and in the bo the resulting drag was to small I think. Therefore I added a vertical stab to close the tube at the beginning. This vertical slab I realized by an stab with 90 deg. incidence. There should be many other ways to do this without a vertical stab, but this way was self-evident for me. The boundary changes in Wing.cpp don't make any sense to me. You are adding two entries, but don't map them to anything. How is this change not a complete (and hard to understand) no-op? The outer definition of the wing in Yasim is given by the innermost and outermost bound[]. But the bound[] are only defined at flapx start, flapx end, spoiler... and slat... .Therefore for an wing without flap, spoiler and slat the bound[] array is empty and no surface element is generated. E. g. for the bo105 hstab (without flap, spoiler and slat) this stab is not simulated in YASim. E. g. for the j3, with only one control subelement at the wing (flap0 start=.31 end=0.85 lift=1.5 drag=1.4/), there is no surface generated for the outer 15% of the wing (the same for the inner 31%). The changes to Model::calcForces() are just not acceptable. This routine should be a short, top-level wrapper for the force calculation (i.e. for each surface, set up parameters and calculate forces, then do the same for each engine, etc...). You have dumped a *TON* of quite clearly helicopter-specific logic right into the middle of this function. (Amusingly, you also broke my comment that reads end of engine stuff -- it now comes something like 100+ lines after the end of the engines). Can't this go into one of the Rotor* files? At the very least, get it out of calcForces(). Yes, I will change this. The lines between the two comments // check,if the engine... and // End of engine stuff will be replaced by one function call. The few remaining lines I will reduce (one of the for-loops can be included to the other for-loop) ...by the way, I think the comment that reads end of engine stuff is by me. Also, I notice that I had a nit-picky comment at the top of Model::initRotorIteration(). I know you read this comment, because you modified the function. But you don't seem to have addressed the concern. Either remove the comment if it is incorrect, explain to me why it's not a problem, or fix the code. :) Of course I didn't want to change your comment. Yes, there is some integration done in the void Rotorpart::inititeration(float dt,float *rot) called from this function. One is the integration of the rotor orientation by omega*dt for the 3D-visualization of the heli only. The other is the compensation of the rotation of the fuselage. The rotor does not follow the rotation of the fuselage. Therefore its rotation must be subtracted from the orientation of the rotor. I think, one could call this unstiff problems. The changes to RigidBody.cpp are just plain wrong. You appear to be trying to handle a divide-by-zero condition by testing the denominator. Which is sort of OK, if clumsy (AFAICT, neither of these situations can occur in practice -- please explain why you needed to fix these; I suspect you had some other bug). Unfotrunately, your fallback cases treat the infinity that gets produced as being EQUAL TO ONE! For debugging the rotor code I had switched the floating point exceptions on. But I got floating point exceptions exactly in the modified functions directly after starting the program, probably due to
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
I think this is resulting from a combination of factors. The YASim YF-23, as currently defined, probably doesn't weigh enough and the engines are a bit too powerful, both due to a dearth of good info on the YF-23 when I originally did it. I suspect that this means that it can get to 74000ft at which point, IIRC, YASim stops calculating altitude effects with the result that once you're above 74000ft you can carry on climbing. Again, IIRC, the real (Y)F-23 could (was intended) get to 65000ft so with the YASim YF-23 under weight and too powerful it's able to climb just a bit too high:) I do want update the YF-23 some time soon but I'm already pretty busy with two updates and a new aircraft so it'll have to wait a bit. LeeE On Monday 31 July 2006 05:44, JD Fenech wrote: Is this some sort of bug in the model? It strikes me as something that would either be a tightly held performance spec on the part of the US Gov't, or a glaring flaw somewhere... Stefan Seifert wrote: Melchior FRANZ wrote: $ fgfs --aircraft=YF-23 --airport=knuq --disable-real-weather-fetch - full throttle - climb to 8000 ft - 90 degree bank - pull stick fully back amazingly: you don't bleed off speed, but *accelerate* - at ~1630 kt (after that the speed decreases) 0 degree bank and 90 degree pitch up - climb to 163000 ft in no time If you really want to travel to other planets I suggest just pulling the throttle to zero when you reach the speed limit, while still rotating. This gives you the extra boost you need for interplanetary travel. Nine - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
* Lee Elliott -- Tuesday 01 August 2006 23:40: Again, IIRC, the real (Y)F-23 could (was intended) get to 65000ft so with the YASim YF-23 under weight and too powerful it's able to climb just a bit too high:) That's a minor problem. The bigger problem is that it *accelerates* in very narrow turns, and even with no throttle at all. And you can fly straight down with 1000 kt, and shortly before touch-down pitch up and fly straight up again. Doesn't seem to have enough mass/inertia. (Yes, the g-load would kill me anyway, so I shouldn't bother. :-) m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
On Tuesday 01 August 2006 22:50, Melchior FRANZ wrote: * Lee Elliott -- Tuesday 01 August 2006 23:40: Again, IIRC, the real (Y)F-23 could (was intended) get to 65000ft so with the YASim YF-23 under weight and too powerful it's able to climb just a bit too high:) That's a minor problem. The bigger problem is that it *accelerates* in very narrow turns, and even with no throttle at all. And you can fly straight down with 1000 kt, and shortly before touch-down pitch up and fly straight up again. Doesn't seem to have enough mass/inertia. (Yes, the g-load would kill me anyway, so I shouldn't bother. :-) m. Hmm... I don't remember it ever behaving like that but I haven't flown it for ages. I'll have to take a look at it. LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] heli simulation update ready for cvs?
Hi, Maik Justus wrote: The outer definition of the wing in Yasim is given by the innermost and outermost bound[]. But the bound[] are only defined at flapx start, flapx end, spoiler... and slat... .Therefore for an wing without flap, spoiler and slat the bound[] array is empty and no surface element is generated. E. g. for the bo105 hstab (without flap, spoiler and slat) this stab is not simulated in YASim. E. g. for the j3, with only one control subelement at the wing (flap0 start=.31 end=0.85 lift=1.5 drag=1.4/), there is no surface generated for the outer 15% of the wing (the same for the inner 31%). I have to correct this a little bit. For the J3 a surface is generated for the inner 31% due to the fact, that all control subelements, which are not defined, yield to a bound[x]=0. The innermost part is only missing for wings with 2 flaps, spoiler and slat. Maik - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] heli simulation update ready for cvs?
Maik Justus wrote: my impression was, that a stab is not producing forces perpendicular to its surface, when the wind is blowing perpendicular to its surface You have misinterpreted the code, I think. The stallLift value is only one contribution to the transverse force from the surface. Regular drag forces still apply, and I assure you they work. If they did not, YASim aircraft would not be stable when placed in zero-velocity situations like a hammerhead stall or similar situation where AoA goes through 90. The fuselage is simulated as a open tube and in the bo the resulting drag was to small I think. Therefore I added a vertical stab to close the tube at the beginning. This vertical slab I realized by an stab with 90 deg. incidence. There should be many other ways to do this without a vertical stab, but this way was self-evident for me. OK, I understand. But this is a hack. Your problem has nothing to do with surface incidence: your problem is that the fuselage drag is too low. Since the solver isn't run for helicopters, that isn't surprising. Why not investigate solutions that address the actual problem* and don't involve putting trig operations into the inner loop of the simulator? If you *really* need this feature and don't want to use one of the IMHO more general features above, can you provide it to me as a separate patch with change comments? It really isn't related to helicopters. The performance cost here is rather high, this code gets hit at 400 Hz for every surface in the aircraft (and there can be hundreds on a big plane). The small angle trick was being used for a reason, basically. * Suggestion A: an effectiveness parameter for fuselage tags that works like it does for wings, so you can tune it per-aircraft. Suggestion B: a new spheroid type that creates surfaces distributed in 3D around a center point instead of the 1D distribution you get from a fuselage tag. This would probably still need an effectiveness tunable, but will be much easier for authors of helicopters and airships to use than vstab objects. Andy Ross wrote: The boundary changes in Wing.cpp don't make any sense to me. Therefore for an wing without flap, spoiler and slat [...] no surface element is generated. Ah, OK. Yes, this was indeed a bug; I'm kinda shocked that we never noticed this before, it's been there since the code was written. And unfortunately it affects *all* wings with segments that like between a control position and an edge. Which means that we're going to need to retest the solution results for basically every YASim aircraft once this goes in. Ick. :( As always, it's nicer to hear about bugs as bug reports, and not as anonymous changes in a 120k patch file. :) Can you (1) split this out into a separate patch as above, (2) add a comment explaining the two new entries in the table, and (3) write 10 instead of 8+2 (or BOUND_COUNT or sizeof(bounds)/sizeof(bounds[0]), etc...). Yes, I will change this. The lines [...] will be replaced by one function call. OK. But why must this be in Model.cpp? That class is a top-level wrapper that contains a bunch of sub-objects to do the real simulation; it doesn't have any aircraft-specific logic. Shouldn't this be part of a Rotor? If not, maybe you need another abstraction? (RotorShaft, maybe, by analogy to PropEngine?) The immediate complaint was that this was a lot of very special-purpose code inside my a small, general function. But the proximate issue remains: this seems like a lot of special-purpose code without an obvious home in the design. Abstraction is nice: it lets your changes go into files that you own (like Rotor*.?pp) without being torn apart by viscious folk like me. :) Of course I didn't want to change your comment. Yes, there is some integration done [...] the compensation of the rotation of the fuselage. The rotor does not follow the rotation of the fuselage. Therefore its rotation must be subtracted from the orientation of the rotor. I think, one could call this unstiff problems. Leaving a comment in place above your code that you disagree with seems kinda silly; I don't care if I wrote it or not. Pull it out and replace it with the above explanation of why this code is OK inside of initIteration() and does not need to be in calcForces(). A more general suggestion: isn't this a design bug with your choice of coordinates? The body is an accelerated reference frame. Wouldn't it be better to store the rotor orientation as a matrix in the global frame instead, the same way aircraft orientations are stored? Not only would you be able to skip this step, you would be immune to physics bugs caused by rapid rotations of the helicopter body. For debugging the rotor code I had switched the floating point exceptions on. But I got floating point exceptions exactly in the modified functions directly after starting the program, probably due to uninitialized variables somewhere else.
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
Lee Elliott wrote: dearth of good info on the YF-23 when I originally did it. I Should you find a moment, I feel that I should point this out: http://www.flight-manuals-on-cd.com/YFN.html Josh - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
