Re: [Flightgear-devel] Electrical system work..
The starter motor(s) and APU should also be included in the electrical system. In real life the battery can't keep turning that engine over indefinately. In the light aircraft it might not be such an issue but when you get to the commercial jets you have to be very careful about your startup procedures otherwise you can get yourself into a situation where you have to call for some help from an external power source. Also on most multi engine aircraft you can't start all the engines at once because the battery(s) won't handle the current draw. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Electrical system work..
Paul Surgeon wrote: The starter motor(s) and APU should also be included in the electrical system. In real life the battery can't keep turning that engine over indefinately. In the light aircraft it might not be such an issue but when you get to the commercial jets you have to be very careful about your startup procedures otherwise you can get yourself into a situation where you have to call for some help from an external power source. Also on most multi engine aircraft you can't start all the engines at once because the battery(s) won't handle the current draw. Which raises another issue. To get it one more step more realistic I think it is important to know bot nominal and maximum draw and we should define whether a consumer device is either capacitive or inductive. This is often quite easy to guess (a CRT or everything using motors is inductive) and adds the possibility of popping circuit breakers when too many inductive devices are turned on at once. Not to mention we get more accurate current flows (actually battery lifetime) simulated. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Electrical system work..
Hi Gene Gene Buckle writes If you're so stuck on random event generators, go use MSFS. It's full of 'em, including the flight model. I am not stuck on randon event generators it is just that in the real world thats the way things seem to happen.Otherwise they would be planded events.And I can just see someone taking a cessna up knowing that 30 mins into the flight the engine is going to catch fire. How do you determine when the instrument is working normally and when it is not.My guess is the the program is going to say so. The idea here is to be able to create an accurate representation of an aircraft electrical system. Have you ever seen or worked on anything bigger that a light twin electrical system. Lets look at the 747(only because I am most familiar with that) 4 engine driven generators 2 APU driven generators 2 external power connections Then these are spilt up into 115v 3 phase AC 115v single phase AC 28v AC 28v DC ciruits.And then hundreds of CB's.You are not trying to tell me you are going to try and simulate that.The wiring diagrams alone if stacked would be 4 feet high. Every commercial simulator I've worked with has had some kind of electrical system simulation running I have had the fortune of actually opperating 707, 767, 747 and DC10 simulators and yes they have fully functioning electrical systems. But they also have a randon event renerator called a HUMAN and he or she sits at a control panel and selects the system failures. does this not happen in other simulators. The only thing I would ask is if you make these plans to be aware that there a lot of A/C that dont use battery start in fact hardly use a battery at all. And if as I understand FG is a full spectrum simulator then we must consider all types of A/C Cheers Innis The Mad Aussi _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Models Question
Hi Guys I guess this is directed to the model makers. I am making a model with AC3D and I have five surfaces that stay white in FG even though I apply a material to them. I have tried fliping normals or rearranging the vertex order but still they show white. The strange thing is that sometimes when I start FG it only runs at 1fps at this time the surfaces appear with there correct material color. Also if I apply a texture to the surfaces they are OK and display the texture. Does anyone know how to overcome this problem as I had intended to only cover the surfaces with a material.But if it can't be fixed I will have to make textures for them Thanks in advance Cheers Innis The Mad Aussi _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport vehicle (driving) sim
Hmmm, Tricky. David culp sent me the relevant source code. I'll take a look at it and see what I can do. Nickolas HeinMorgantown WV - Original Message - From: Jon Berndt To: FlightGear developers discussions Sent: Saturday, November 15, 2003 3:48 PM Subject: RE: [Flightgear-devel] Airport vehicle (driving) sim -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of NickSent: Saturday, November 15, 2003 2:39 PMTo: FlightGear developers discussionsSubject: Re: [Flightgear-devel] Airport vehicle (driving) sim Good afternoon again. I just remembered another trick about zero-speed rolling models. Below a threshold speed (say 1 m/s) you make the force proportional to the velocity. That way you'll get zero force at zero speed. The other thing that can happen if you don't is that you'll oscillate about the zero speed point. This will stop that oscillation. Hope it helps What if you have wind? Then, your aircraft is experiencing forces and moments, yet the vehicle is not able to oppose the forces and moments if it is stationary. You get an equilibrium drift. Been there, tried it. Didn't work. The way I am leaning is to model it similar to the way the Langley C++ sim does it. At low speeds, the XY plane gear forces are *made* to cause the aircraft to follow a specified path and rate determined by the gear characteristics and known turning radius. This means though that even a tornadic wind would not move the aircraft sideways. ___Flightgear-devel mailing list[EMAIL PROTECTED]http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Models Question
On Sunday 16 November 2003 12:30, Innis Cunningham wrote: Hi Guys I guess this is directed to the model makers. I am making a model with AC3D and I have five surfaces that stay white in FG even though I apply a material to them. I have tried fliping normals or rearranging the vertex order but still they show white. The strange thing is that sometimes when I start FG it only runs at 1fps at this time the surfaces appear with there correct material color. Also if I apply a texture to the surfaces they are OK and display the texture. Does anyone know how to overcome this problem as I had intended to only cover the surfaces with a material.But if it can't be fixed I will have to make textures for them Thanks in advance Cheers Innis The Mad Aussi Strange... Could you put a copy of the model up somewhere so we could have a look at it. That it seems to work ok with s/w rendering must be significant, although what that significance means I don't know. Sort of indicates that the problem might not be with the model/texturing though, because it works under some circumstances. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport vehicle (driving) sim
Andy Ross [EMAIL PROTECTED] wrote: David Megginson wrote: Paul Surgeon writes: I don't know about everyone else's experience but I haven't found one aircraft in FG that wants to sit still on the ground even with the engine off. An ideal mechanism would keep track of how much force each wheel could apply in the ground plane, and then calculate the right amount to apply to keep the aircraft from moving. This basically comes down to solving a bunch of simultaneous equations for each FDM iteration. It's a big mess; I'd be really scared of making this work. I'm not shure if it would be really that difficult - although I don't know precisely what's already there. As mentioned previously some sort of ground FDM would be a really nice thing. If it was plugged into SimGear then people designing racing card simulations (once discussed on this list) could profit from it. Simulating friction on the ground should be quite easy as long as you know some parameters: You have to know about position as well as horizontal and vertical forces of _each_ wheel. Probably this is already there for a C172 (as mentioned above, I don't know), the rest is sort of practical mechanical numeric almost every student in engineering should learn in the first or second year. Look, it's quite easy to calculate how a tyre will move when you put a force onto it. I suppose it would be useful if you have a tyre object that you hand a force vector over. Because of the tyre being elastic it will move a bit to the side as long as the vector contains a component that crosses the longitudinal axis of the aircraft. The tyre object contains an easy calculation which results in a sideway position shift (and a counterforce). When you know this position shift you don't have to deal with forces any more as long as the aircraft sits on the ground. When the vertical forces onto the tyre decrease then the sideway shift will increase because the tyre slips over the ground. If the tyre gets into snow slush then the force vector returned by the tyre object will not only contain a sideway component but also a longitudinal one. O.k., I'n not the one to tell Andy, Dave, Jon, Curt and all the others to be too stupid to understand the simplicity ;-) So please would someone explain to me the missing parts in my idea ? Did I overlook something, do I miss some relevant information ? Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Airport vehicle (driving) sim
Did I overlook something, do I miss some relevant information ? Thanks, Martin. Hi, Martin: I'm pretty busy at the moment doing some rewriting of the JSBSim propulsion systems, but I will refer you at the moment to a set of notes I wrote for our gear model. I have not revisited the topic for a while, but this will give you some insight into our approach, and to the problems we faced. Go to the JSBSim web site, click on the Documentation link at left, then select the Landing Gear Technical Note link. Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AI aircraft carrier
David Culp wrote: Ok, I got the Saratoga moving across San Fransisco bay at 30 knots. http://home.comcast.net/~davidculp2/saratoga_SFO_bay.jpg It can't be landed on because the deck is not solid (however you can fly inside and grab lunch). Is there a way to solidify the deck? Dave Wowww, nice! Hornet 12, inbound for landing. - Hornet 12, Saratoga tower, contact in 2 miles out. Roger that - Good morning Hornet 12, you are number 1 to land, deck is clear for landing Gears down, hook down, flaps set - Left, left... you're low... faster steady you're low slower steady higher... steady... call the ball... steady... CONTACT! [afterburners to full, trying to pull up] [the hook has grabbed] - Hornet 12, nice landing! Roger that, thanks Saratoga tower. :) - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport vehicle (driving) sim
Martin Spott wrote: Simulating friction on the ground should be quite easy as long as you know some parameters: You have to know about position as well as horizontal and vertical forces of _each_ wheel. Probably this is already there for a C172 (as mentioned above, I don't know), the rest is sort of practical mechanical numeric almost every student in engineering should learn in the first or second year. It doesn't work like that. Put a book on the table in front of you. What is the friction force? Zero. (If it wasn't, of course, the book would be accelerating.) Push on it a little, but not enough to move it. What is the friction force? Equal to your push force, and in the opposite direction. Somehow, the book *knows* how much force to apply based on external conditions. You don't just calculate the friction force and apply it. You need to know what is happening to the system. For a single book and a single external force, the solution is trivial. For N gear objects applying force in 2 dimensions, this becomes a giant simultaneous equation problem. Even worse, there might not even be a solution! Big problem, right? Nope. It just means that the vehicle can't be held in place and will start to slide. Which gear are slipping? How do you tell? And those are just the complexities I understand right now. The stuff that really worries me are the bits I can't figure out: if there is a solution, is it unique? What do you do if the terrain is 3D, and the gear aren't on a single ground plane? (The friction force is 2D only, the compression force doesn't work the same way at all.) Basically, this just won't work. Sorry. The idea of switching from a sliding friction model to a static spring at low speeds is probably as good as we're going to get. But quite honestly, it's been my experience that almost all of the YASim aircraft I have worked on can be made to sit still with a little gear tuning. I'm not convinced that this is a critical feature. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-users] Re: multiplay problem: Linux - win xp
[redirected to flightgear-devel]
Frederic Bouvier wrote:
Melchior FRANZ wrote:
* Frederic Bouvier -- Sunday 16 November 2003 15:32:
Are you using the binary distribution or do you compile FG
yourself ?
The xp version is the binary distribution as offered on the
fgfs site. My Linux version is selfcompiled (CVS/HEAD).
I finally tried the multiplayer options between a WinXP box and
a Linux box.
With the ( A320, p51d ) pair, no problem : I can see both from
either systems. I configured on to start on runway 28L while
the other is at runway 28R.
When a c172 is on one machine, I only got segfault on an animation
not found. This animation is named ControlsGroup and I guess
that one object name referenced in this null animation no
longer exist in the .ac model. I say that because the
preceding one is analogous and works.
So I would say the multiplayer works, except when there is a c172.
It seems that this animation refers to 'PanelInstruments' that is
a panel outside the model, so, when loaded with SGModelLib::load_model
the object is not found in the model and there is a non tested
read access through a null pointer in sgMakeAnimation.
This path makes things go better :
D:\FlightGear\cvs\SimGear\simgear\scene\modelcvs diff -u model.cxx
Index: model.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/model/model.cxx,v
retrieving revision 1.11
diff -u -r1.11 model.cxx
--- model.cxx 28 Sep 2003 08:38:48 - 1.11
+++ model.cxx 16 Nov 2003 23:36:49 -
@@ -150,6 +150,9 @@
} else {
object = model;
}
+
+ if ( animation == 0 )
+ return;
ssgBranch * branch = animation-getBranch();
splice_branch(branch, object);
BTW: it is funny ( but not inexplicable ) that the other model is
animated but with the input of the current aircraft : push the
throttle and you will see the propeller of the foreign model
accelerate.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AI aircraft carrier
Wowww, nice! ... Roger that, thanks Saratoga tower. I'll send you the code if you like. I've written a bare-bones AI system based on David Luff's. The AI manager just instantiates an AI object (airplane or ship) wherever you want it and tells it when to update. The AI objects are AIAircraft (yes, even the ship) which have a simple FDM that moves it along at any assigned speed, altitude, heading and bank angle. What I would like to see in FlightGear is: 1) A simple AI base class, like my FGAIBase, which is based on and very similar to the present FGAIEntity. 2) A simple AI object class, like my AIAircraft, that would provide dumb AI, which are minimalist AI objects that move along scripted flight plans. This would be for dumb aircraft and ships. 3) A semi-smart AI class for autos, which must be smart enough to know where the ground is at all times. Seamus is working on these now. 4) A smart class, which is the present AILocalTraffic. These know where the ground is, and have the ability to communicate. In the future they may become interactive. 5) An AI manager that instantiates new AI objects from the above three types for every occurance of entry ... /entry within the ai section of preferences.xml (just like the way environment layers are currently defined). You could create any number of AI objects at any place and time this way. 6) A scripting standard for the AI objects. The script will serve as the object's flight plan, specify when the object should be terminated, and contain communications instructions (for the smart AI). Is there any interest in uniting dumb and smart AI this way? I brought some KSFO arrival charts home from work, and am planning to have a dumb AI airplane appear at the beginning of each arrival every 2 minutes. The Big Sur arrival will feed runway 28L, and the Modesto arrival 28R. After landing the airplanes would turn off disappear. I'm curious what the frame rate hit will be. These might need to be very low-poly models. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport vehicle (driving) sim
Andy Ross [EMAIL PROTECTED] said: Basically, this just won't work. Sorry. The idea of switching from a sliding friction model to a static spring at low speeds is probably as good as we're going to get. But quite honestly, it's been my experience that almost all of the YASim aircraft I have worked on can be made to sit still with a little gear tuning. I'm not convinced that this is a critical feature. Just to explain this a little further...if the balance of the aircraft and/or the position of the gear is incorrect, the aircraft will slide around. Last I knew the helicopter used some very large ballasts. An extremely small movement of this weight would affect the balance and gear tuning. IIRC the skids on the bo105 are modeled as four wheel points, but it should i think be possible to set the fricition high enough on the gear to be similar to a skid. Might it be useful to have some arbitrary mulitplier that affects the way in which forces or friction are scaled as zero velocity is approached? This still should be added _after_ the aircraft pretty much just sits there on it's own. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Airport vehicle (driving) sim
If there were no winds at all, that might help. Otherwise, it doesn't work at all. Jon Let me expand on that. If you do come to a stop, and there are no winds at the moment, then the winds come up after you have stopped, then having reduced the forces as your velocity goes to zero, you won't have any resistance to the wind, and you'll start sliding again. Another area where I have run into trouble is when standing still and trying to calculate the angle that the tires make with the velocity vector. If you are landing, are crabbed, and/or have any rotational rate, the tire isn't going to touch down without providing a sideward force component. But, if you are standing still, the velocity vector is zero, and your steering angle is not. The algorithm that computes steering angle goes berserk, causing massively rabid changes in angle, and the resulting oscillation of force/moment. I think I have recently gotten around that problem by allowing the steering angle to change by a certain set amount per frame. However, now since the steering angle is not allowed to change rapidly, the aircraft slides - albeit much, much more smoothly, and without rotational oscillations. You squeeze the balloon a little here, and it bulges out a little there. I do have a fix in mind for that, and then the gear should be much better in JSBSim. However, as I said earlier, I'm working some propulsion system improvements at the moment. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport vehicle (driving) sim
If there were no winds at all, that might help. Otherwise, it doesn't work at all. Oh. Why is that? I tried limiting the ground reactions and found that if you lower them enough to stop the jitter, the airplane will get blown around by the wind. I believe this is the relevant bit of code from FGAircraft.cpp::Run() vForces.InitMatrix(); vForces += Aerodynamics-GetForces(); vForces += Inertial-GetForces(); vForces += Propulsion-GetForces(); vForces += GroundReactions-GetForces(); vMoments.InitMatrix(); vMoments += Aerodynamics-GetMoments(); vMoments += Propulsion-GetMoments(); vMoments += GroundReactions-GetMoments(); vBodyAccel = vForces/MassBalance-GetMass(); I think the trick is to zero-out the speeds, forces and moments when the airplane's forward speed approaches zero. But you then have to allow the airplane to accelerate out of this frozen state to move again. I didn't find an answer. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Electrical system work..
Curtis L. Olson [EMAIL PROTECTED] said: I know this is probably comparing apples to oranges, but back when I was young and daring, I drove my car about 150 miles with no alternator belt. I survived by making sure every possible electrical item was turned off. If I even hit the turn signal or hit the brakes (brake lights) the engine would sputter and nearly die. Hehe. I did that...at night...once. It was a much shorter distance, in rural Maine, very late at night. I didn't encountered a single other vehicle on the road, which is a good thing in a way, but at the same time it reinforced the likelyhood that my best option was to keep going. Went _very_ slow after the headlights had to be turned off :-). Fortunately, it was a clear night with a bright moon. Pretty cold without the heater fan though. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport vehicle (driving) sim
Andy Ross writes: JSBSim and YASim do things pretty much the same way, using a coefficient of friction for gear as they slide over the ground. This integration works fine for a moving aircraft, Unfortunately, not -- when the JSBSim and YASim aircraft are rolling, they are still far too much affected by the wind. In real life, even with 30 kt gusts, you can usually taxi a 172 or Cherokee around as if it were a car. Personally, I do set the controls appropriately just in case (I'd hate for that one gust to get under the wing and flip me), but I have not seen it make a noticeable difference. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Landing Gear discussion
David M. wrote: Unfortunately, not -- when the JSBSim and YASim aircraft are rolling, they are still far too much affected by the wind. In real life, even with 30 kt gusts, you can usually taxi a 172 or Cherokee around as if it were a car. Personally, I do set the controls appropriately just in case (I'd hate for that one gust to get under the wing and flip me), but I have not seen it make a noticeable difference. Thanks for the input. When I get a chance, maybe I'll try increasing the steering gain. In the end, it could turn out that a physics-based approach is not worth the effort, and we should simply make the aircraft do what experience tells us a real aircraft would do. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
