RE: [Flightgear-devel] Proposed change to Terrain Following control
snip So that's what I've come up with so far. Am I completely nuts? Any suggestions? I have no formal education in control theory, so what I know has been gleaned from here and there so I probably don't know much of the correct terminology and there are certainly tricks and things that I'm not aware of. I'm hoping to do a good job of roughing in the flexible xml structure and interfacing to flightgear, then get some help on the control theory side from the experts. I am also not a control theory expert, but I have sat in meetings with some :-) That all looks good so far, and looks to be much easier to configure than the current scheme. FWIW, the two (or more) stage controller is knwon as a cascade controller. In light of recent discussions on the list about integrator wind up, can you bear this in mind when you do the I functions? Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
Hi Guys Curtis L. Olson writes This is my general plan. Right now I have the autopilot config in a separate .xml file * The autopilot should get input from other instruments (airspeed indicator, altimeter, attitude indicator, etc.), and not from /position/altitude-ft, /velocities/..., etc. That way the wing-leveler would be unuseable if the attitude indicator was broken. Failures in the underlying instruments and systems would affect the autopilot. Yup, each autopilot component will be able to take input from any property, and output to any other property. As long as we have the instrument values modeled and placed in the property tree, we can use them. The trick will be for someone who knows a little about autopilots to be able to tell us what inputs drive what functions. As far as I am aware on any autopilot I ever worked on the autopilot/autothrottle took no information from the instruments.It provides information to the instruments so the pilot can see what the autopilot is doing.But to fly the A/C the autopilot could not careless what the instruments are doing. The autopilot takes its information from CADS Corrected Air Data System INS or U Inertial Navigation System or Unit or GPS Radio Navigation Unit Radio Altimeter Auto Pilot Control panel Compass Controler All these units except for the control panel are blackbox's down in the bowels.Also the autopilot unit is down there to. So to simulate the Autopilot you would need to simulate all these box's outputs. Alternativly you could just add there outputs to the property tree,quite a few already are,and make the autopilot/autothrottle that way. This is all I used to do the 737 autopilot.And while there are a few things that need to be done the property tree I found to be very good. Hope this helps Cheers Innis _ E-mail just got a whole lot better. New ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Terragear-devel] Wittman Airport, Oshkosh, WI
Bohnert Paul [EMAIL PROTECTED] wrote: Consider it done. Robin said he will add them as soon as he can. The meanings of these two sentences are 'diametrically opposed' ;-) No, I don't want to accuse Robin, I fully understand that there are times where the first priority is not occupated by his airport database, 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] Proposed change to Terrain Following control
On Thu, 22 Jan 2004 17:28:51 +0800, Innis Cunningham [EMAIL PROTECTED] wrote: As far as I am aware on any autopilot I ever worked on the autopilot/autothrottle took no information from the instruments.It provides information to the instruments so the pilot can see what the autopilot is doing.But to fly the A/C the autopilot could not careless what the instruments are doing. After studying the Bendix KFC 225 Pilot's Guide (available on the Bendix/King website), I am under the impression that this particular autopilot reads information from the instruments: Attitude Gyro Altimeter Compass System Optionally a GPS and Optionally a Radar Altimeter This was the autopilot that I had in mind. The autopilot takes its information from CADS Corrected Air Data System INS or U Inertial Navigation System or Unit or GPS Radio Navigation Unit Radio Altimeter Auto Pilot Control panel Compass Controler I don't think all theese units are available in a light aircraft like the C172 ;-) All these units except for the control panel are blackbox's down in the bowels.Also the autopilot unit is down there to. So to simulate the Autopilot you would need to simulate all these box's outputs. Yes! Alternativly you could just add there outputs to the property tree,quite a few already are,and make the autopilot/autothrottle that way. This is all I used to do the 737 autopilot.And while there are a few things that need to be done the property tree I found to be very good. Hope this helps Cheers Innis _ E-mail just got a whole lot better. New ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
On Wed, 21 Jan 2004 22:28:22 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: Roy Vegard Ovesen wrote: Let me share my thoughts about the autopilot: * I would like to see the autopilot move from c++ code into the instrument configuration xml-files. This is my general plan. Right now I have the autopilot config in a separate .xml file * The autopilot should get input from other instruments (airspeed indicator, altimeter, attitude indicator, etc.), and not from /position/altitude-ft, /velocities/..., etc. That way the wing-leveler would be unuseable if the attitude indicator was broken. Failures in the underlying instruments and systems would affect the autopilot. Yup, each autopilot component will be able to take input from any property, and output to any other property. As long as we have the instrument values modeled and placed in the property tree, we can use them. And I firmly believe that we _should_ use the instrument values because in my mind using /position/... and /velocities/... would be cheating, theese perfect values are _not_ available in the real world. The trick will be for someone who knows a little about autopilots to be able to tell us what inputs drive what functions. I have a masters-degree in control theory, and I think that an autopilot is just like any other plant that has to be controlled. The most important thing is to have a good knowledge about the process that is to be controlled. So maybe the best consultant for an autopilot would be a good pilot. He/She _is_ the autopilot (think about it!). I've been hacking things out here a bit this evening and here's what I've come up with for a simple proportional wing leveler. All of this is in a state of flux, is subject to change, and only exists on my local HD. I'll intersperse some explanatory comments ... autopilot.xml: proportional nameWing Leveler (Turn Coordinator based)/name I implemented (in jsbsim) a wing leveler or I should say a roll-angle holder that was roll-angle based. It's all a matter of preference, I think (turn coordinator based or roll-angle based or ...) enable !-- enable this component when the defined property equals the specified value -- prop/autopilot/locks/heading/prop valuewing-leveler/value /enable input !-- the input source -- prop/instrumentation/turn-indicator/indicated-turn-rate/prop /input target !-- what we want to drive the input value to, this can also be a property name -- value0.0/value /target output !-- the output property name -- prop/controls/flight/aileron/prop /output config !-- output = (target - input) * factor + offset -- factor0.5/factor !-- I don't know if it makes sense to offer an offset here, but it's easy to add and I've seen similar things other places in the code so I stuck it in. -- offset0.0/offset In PID controllers an offset is often to set the working-point. The point where: offset = output = target - input = 0. The aileron deflection that results in zero turn rate. This aileron deflection doesn't have to be zero, as we all have experienced :-) Another application for the offset is to attatch it to the manual actuator, in our case the stick. This means that the pilot can still control the airplane when the autopilot is engaged ;-) , and when the autopilot is disengaged, the output = offset = stick = pilot is flying. post !-- I might be better off moving this to the output section, but this lets us clamp the output result -- clamp min-1.0/min max1.0/max /clamp /post /config /proportional So if you set /autopilot/locks/heading = wing-leveler, this component will become active and start driving the turn rate to zero using the ailerons. A proportional only controller will _not_ be able to drive the turn rate to zero. If the working-point were zero aileron deflection, then this controller would work but, as stated earlier, the working point is moving around. In general you need at least proportional and intgral components, in a controller, to avoid this static-error. Here's a more complicated two stage heading bug follower (still using simple proportional control): This is called cascade control. !-- this first stage calculates a target roll degree based on the difference between our current heading and the heading bug heading. It writes the result to a temporary property name. This temp property is the input to the second stage. Both stages use the same enable property and value. -- proportional nameHeading Bug Hold (DG based) Calc Target Roll/name enable prop/autopilot/locks/heading/prop valuedg-heading-hold/value /enable input
[Flightgear-devel] getting and setting properties
After reading through "fg_props.hxx", I found that the most efficient was to get a property value is to use fgGetNode instead of the "fgGet" functions. Is there a more efficient way to set properties, or is that best way to use the "fgSet" functions Thanks. Adam ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Some sound problems under Alsa
Hi, I was formerly using flightgear-devel but someone suggested to adress technical problems here. ;-) Since Slackware will use Alsa sound from version 9.1 and onwards I would like to mention a sound problem with some planes. Running --aircraft=c310-yasim I'll get no plane sound, just the OM and MM tweets. I've tried the very same data partition with Slackware 9.0 which uses OSS sound. All the planes have sound working there. Then I move the Slackware 9.0 binary to Slackware 9.1 and the mentioned sound stops working, but it flies nonetheless. So how does Flightgear transmit sound? It would be nice to learn how to sort (with all respect...) the 'working' planes from the planes which misses sound. The 747-yasim jet sounds work in Slackware too, for example. But if I pause and restart FG I have no sound at all. From the top of my head I'm looking at the sound header, as I've learned how to cope/avoid the 'sox' utility. That one almost threw me off using Linux. Sorry. :-) I have a Soundblaster Live! Player and OSS is hard to get get working in the current Slackware. I start 'rexima' (the console mixer program) and all I get is Line1, Line2 and Line3. As I redo Alsa it works just fine. Regards, Roger Andreassen. _ MSN Messenger http://www.msn.no/messenger Den korteste veien mellom deg og dine venner ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] A Logitech joystick on the loose!
Hello, I have a Logitech joystick on the loose. It's a silvery/black, four-legged USB wired Logitech. js_demo says: Joystick 0: Logitech Logitech Extreme 3D Pro and I think the wireless 'brother' says the same. USB don't know what's outside the transmitter... The buttons are a bit funny. 1 5 O 6 3 4 --- \2 '1' is at the index finger and '2' would be the thumb one. 'O' is the viewfinder. See why I had to map the trim 5/3 and the flaps 6/4? That's my standard. ;-) I can see that driver in the CVS from January the 14th, but 'Logitech' is just mentioned once: Logitech Extreme 3D Pro. Is that the correct way? Here's my attempt: ?xml version=1.0? !-- * Bindings for Logitech WingMan Digital Extreme 3D joystick. * * This joystick is dual-mode: it can connect either through the * gameport or through a USB port. Bindings are as follow: * * Axis 0: ailerons * Axis 1: elevator * Axis 2 (twist): rudder * Axis 3 (slider): throttle * Axes 5 and 6 (hat): view direction * * Button 0 (trigger): all brakes * Button 1 (02): * Button 2 (03): elevator trim up * Button 3 (04): flaps down * Button 4 (05): elevator trim down * Button 5 (06): flaps up * Button 6 (07): decrease propeller pitch * Button 7 (08): increase propeller pitch * Button 8 (09): mixture leaner * Button 9 (10): mixture richer * Button 10 (11): left brake only * Button 11 (12): right brake only I didn't dump all the load as I will look if the CVS works. Regards, Roger Andreassen. _ MSN Messenger http://www.msn.no/messenger Den korteste veien mellom deg og dine venner ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
Roy Vegard Ovesen wrote: And I firmly believe that we _should_ use the instrument values because in my mind using /position/... and /velocities/... would be cheating, theese perfect values are _not_ available in the real world. I definitely agree. We should have instrument values well modeled for the sorts of intruments typically found in smaller aircraft. I have a masters-degree in control theory, Ok, then I will depend on you to keep me from doing anything too stupid. :-) I implemented (in jsbsim) a wing leveler or I should say a roll-angle holder that was roll-angle based. It's all a matter of preference, I think (turn coordinator based or roll-angle based or ...) I believe that some real life wing levelers are based on the turn coordinator gyro which is why I did it that way. I guess it boils down to how it's done in real life on which ever particular real aircraft we are modeling. In PID controllers an offset is often to set the working-point. The point where: offset = output = target - input = 0. The aileron deflection that results in zero turn rate. This aileron deflection doesn't have to be zero, as we all have experienced :-) Yes ... Another application for the offset is to attatch it to the manual actuator, in our case the stick. This means that the pilot can still control the airplane when the autopilot is engaged ;-) , and when the autopilot is disengaged, the output = offset = stick = pilot is flying. That's an interesting idea ... and shouldn't be all that difficult to impliment. A proportional only controller will _not_ be able to drive the turn rate to zero. If the working-point were zero aileron deflection, then this controller would work but, as stated earlier, the working point is moving around. In general you need at least proportional and intgral components, in a controller, to avoid this static-error. That is true, although for a typical C172 with it's laggy and inaccurate sensors, a proportional controller might just get you close enough. It's easy to spot small errors in a sim, but in real life there are usually much bigger errors that hide that last 0.2% that the I compensates for. :-) But hopefully in the end, this will all be handled in the autopilot config file which leaves the choice up to the person building the autopilot. This is called cascade control. I assume that it is a reasonable approach if there's an official name for it. :-) In stead of (or in addition to) having proportional, integral and derivate components, I would like to see a pid-controller that incorporates all three and in addition features like anti-windup, reduced set point weighing, etc. Here's my suggestion: (I'm not sure about the propert names) pid-controller nameRoll Angle Controller/name enable prop/autopilot/roll-angle-hold/prop valuetrue/value /enable input prop/instrumentation/attitude-indicator/roll-angle/prop /input setpoint prop/autopilot/roll-angle-setpoint/prop /setpoint output prop/controls/flight/aileron/prop /output config proportional prop/autopilot/roll-angle-controller/proportional/prop /proportional integral prop/autopilot/roll-angle-controller/integral/prop /integral derivate prop/autopilot/roll-angle-controller/derivate/prop /derivate !-- clamping is required for the anti-integrator-windup -- clamp min-15/min !-- minimum aileron deflection -- max20/max !-- maximum aileron deflection -- /clamp beta !-- set-point weighing -- prop/autopilot/roll-angle-controller/beta/prop /beta /config /pid-controller The one-eighty hack should be moved outside of the controller. Do you have any suggestions for better ways to handle this? For heading control, -370 degrees is a lot different than -10 degrees. At some point in the pipeline, we need to be able to remap results. Either we could build a ton of tiny building blocks (at which point we might be better off just writing the autopilot entirely in nasal) or we need to have a way to tell the controller to remap the results at various stanges in the pipeline. A PID controller is very versitale, it can be a P, PI, PD or a PID controller by setting the proportional, integral and derivate gains, and in many applications a PI controller is good enough. I have a PID controller algorithm from one of my textbooks, I could send it to you with lots of comments. If it's not too much typing for you, it would be worth taking a look at. With a PID controlle we should have the tools to build good autopilots. Then comes the art-of-tuning :-) Yes. I'm worried that I might end up breaking a lot of the existing tuning. I will try not too, but it's something I'm nervous about. I'm half tempted to commit what I have to CVS. But that leaves a lot of autopilot stuff temporarily broken. So, I'm leaning towards hacking on this until I've recovered 99% of the existing functionality before
Re: [Flightgear-devel] getting and setting properties
Snyder Adam D Civ AFRL/VACD wrote: After reading through fg_props.hxx, I found that the most efficient was to get a property value is to use fgGetNode instead of the fgGet functions. Is there a more efficient way to set properties, or is that best way to use the fgSet functions You could also use getter/setter functions to synchronize the property and a local variable, or even tie a variable directly to a property. This uses some C++ voodoo though. You can see an example of that in FlightGear/src/AIModel/AIBase.cxx in the AIBAse::bind function. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Proposed change to Terrain Following control
* Curtis L. Olson -- Thursday 22 January 2004 18:46: I'm half tempted to commit what I have to CVS. But that leaves a lot of autopilot stuff temporarily broken. You could make a cvs branch for that, and later merge it into head, if it's done and tested. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] getting and setting properties
Adam D. Snyder wrote: After reading through fg_props.hxx, I found that the most efficient was to get a property value is to use fgGetNode instead of the fgGet functions. Is there a more efficient way to set properties, or is that best way to use the fgSet functions The node objects you get back from fgGetNode() (members of the SGPropertyNode class in SimGear) have set methods, so yes. But I think you've misunderstood a bit. Simply replacing fgGetFloat(/what/ever) with fgGetNode(/what/ever).getFloatValue() gets you no speedup whatsoever (in fact, this is basically how fgGetFloat is implemented internally). The speedup comes from repeated operations on that property node. If you are going to be doing lots of operations on a property (once per frame, for example), it pays to save the Node object somewhere. This avoids the overhead of parsing the string and walking the property tree every time. Whether the extra work is worth it or not is context dependent. For example, YASim does almost all of its work with the string functions, because the property import/export overhead is tiny compared to the work the FDM has to do to compute the values in the first place. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
And I firmly believe that we _should_ use the instrument values because in my mind using /position/... and /velocities/... would be cheating, theese perfect values are _not_ available in the real world. I definitely agree. We should have instrument values well modeled for the sorts of intruments typically found in smaller aircraft. This thread is scaring me. I hope we aren't deciding to hard-wire the autoflight inputs from panel instrument output? The input choice will be strictly optional, right? Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
This thread is scaring me. I hope we aren't deciding to hard-wire the autoflight inputs from panel instrument output? Why hardwire anything? Why not write it to take property nodes as the input and output entities, and let the glue layers (XML, Nasal, etc...) handle the configuration. Exactly. The XML code snippet looks like it supports any input, however the chat was about what the input _should_ be. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
David Culp wrote: This thread is scaring me. I hope we aren't deciding to hard-wire the autoflight inputs from panel instrument output? Why hardwire anything? Why not write it to take property nodes as the input and output entities, and let the glue layers (XML, Nasal, etc...) handle the configuration. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
David Culp wrote: This thread is scaring me. I hope we aren't deciding to hard-wire the autoflight inputs from panel instrument output? The input choice will be strictly optional, right? Figures, I just finished screwing the cowl back on ... The whole point of defining the autopilot via xml is so that we can a) set up wildly different configurations for different aircraft (like in real life.) And also so we have the flexibility to connect in just about any type of input. We would not connect directly from the panel instruments, that doesn't make much sense structurally. However, in many cases, the autopilot should be driven by the same values the instruments are reporting (in other words, both the instrument and autopilot could be driven by the same underlying instrumenation model.) Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Incorrect fog rendering
Hello everybody, After doing a complete build of the flightgear-0.9.3 source under Cygwin, the simulation runs near perfect. However on two machines (one AMD XP, one P4 XP) with a Radeon 9700 card, fog is incorrectly rendered. Only cloud and ground polygons change gradualy to a white color when visibilty is decreased. The fogwall is not there however. The same build on an ATI mobility graphics chip does render fog correctly. Running OpenGL tests on all machines didnt reveal anything out of the ordinary, so my guess is, it might be the way FlightGear uses the OpenGL extensions? Did this occur to anyone else? Does it have anything to do with pixel vs. polygon based fog? I'm new to this group, and would like to add that if there is any information needed on MD11 and B767 flight characteristics or systems, feel free to ask through this mailing list, I have a lot of flying hours on these types. Avi The Netherlands ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect fog rendering
Avi Levy wrote: Hello everybody, After doing a complete build of the flightgear-0.9.3 source under Cygwin, the simulation runs near perfect. However on two machines (one AMD XP, one P4 XP) with a Radeon 9700 card, fog is incorrectly rendered. Only cloud and ground polygons change gradualy to a white color when visibilty is decreased. The fogwall is not there however. The same build on an ATI mobility graphics chip does render fog correctly. We've had similar reports on NVidia hardware and got around it with a hack. But I recently discovered what might go wrong. In the sky callback (postdraw and predraw functions) the fog is set and unset without pushing and popping it sometimes. I guess that might result in problems like this. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect fog rendering
I'm new to this group, and would like to add that if there is any information needed on MD11 and B767 flight characteristics or systems, feel free to ask through this mailing list, I have a lot of flying hours on these types. Are you planning on making models of these yourself? It doesn't cost anything ;) Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
-- Original Message -- From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Proposed change to Terrain Following control Date: Thu, 22 Jan 2004 14:09:30 -0600 Reply-To: FlightGear developers discussions [EMAIL PROTECTED] This thread is scaring me. I hope we aren't deciding to hard-wire the autoflight inputs from panel instrument output? The input choice will be strictly optional, right? Yes! I think they should be optional, but I think that one should aspire to use outputs from instruments. -- Roy Vegard Ovesen -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] getting and setting properties
Snyder Adam D Civ AFRL/VACD wrote: After reading through fg_props.hxx, I found that the most efficient was to get a property value is to use fgGetNode instead of the fgGet functions. Is there a more efficient way to set properties, or is that best way to use the fgSet functions Yes, fgGetNode is the most efficient way -- it saves any string lookups, and operates almost directly on the value. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Notice: property use for animations
Hi, This is a heads up for all 3d model designers. In order to be able the use your model as an AIModel (and later on ATC controlled model) it is important that the properties used in the animation configuration file are *not* absolute, but instead are defined relative. This is done quite easily by removing the first '/' character of the property definition: wrong: property/controls/lighting/nav-lights/property right: propertycontrols/lighting/nav-lights/property Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
Curtis L. Olson wrote: And I firmly believe that we _should_ use the instrument values because in my mind using /position/... and /velocities/... would be cheating, theese perfect values are _not_ available in the real world. I definitely agree. We should have instrument values well modeled for the sorts of intruments typically found in smaller aircraft. I agree as well. An autopilot driven by the gyro compass should reflect all of the compass's error's, such as drift; ditto for an AP driven by a VOR receiver. If we want to model an AP driven by a GPS, INS, and/or FMS, we should model those as well. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
Any chanceof doing a look-ahead on the scenery polygons to get an altitude eg 2mi in front (for TSR2?) - Original Message - From: Andy Ross [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, January 22, 2004 8:12 PM Subject: Re: [Flightgear-devel] Proposed change to Terrain Following control David Culp wrote: This thread is scaring me. I hope we aren't deciding to hard-wire the autoflight inputs from panel instrument output? Why hardwire anything? Why not write it to take property nodes as the input and output entities, and let the glue layers (XML, Nasal, etc...) handle the configuration. Andy ___ 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] Proposed change to Terrain Following control
Richard Hornby wrote: Any chanceof doing a look-ahead on the scenery polygons to get an altitude eg 2mi in front (for TSR2?) Yes, so long as the tile is loaded. But that's not the way that real autopilots work. The real world doesn't have a scenery elevation API. :) Doing this right would presumably require terrain radar modelling, which hard, and most probably classified anyway. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
On Thu, 22 Jan 2004 16:15:41 -0500 David Megginson [EMAIL PROTECTED] wrote: I agree as well. An autopilot driven by the gyro compass should reflect all of the compass's error's, such as drift; ditto for an AP driven by a VOR receiver. If we want to model an AP driven by a GPS, INS, and/or FMS, we should model those as well. David I think more care should be taken with the terminology. This was scaring me for a while, too. What is being done really is providing sensed state to the A/P and FCS. In my work, these are called sensors - NOT instruments. Instruments (in my experience) refer to devices that display sensed state to the pilot. In an aircraft (or spacecraft) plant, it goes like this: sensors - FCS - effectors To close the loop, there would be an arrow from effectors to Environment/Aircraft State, and subsequently back to sensors. For instance, the F-16 FCS receives rates and accelerations from sensors, as well as taking command input from the pilot. The gyros and accelerometers are the sensors. You could certainly think of them as sensing instruments, but reading this thread might confuse some that we wanted to take the attitude as displayed by the HSI (for instance) and use that as input to the A/P, which is not correct. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
-- Original Message -- Date: Thu, 22 Jan 2004 11:46:00 -0600 From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Proposed change to Terrain Following control Reply-To: FlightGear developers discussions [EMAIL PROTECTED] Do you have any suggestions for better ways to handle this? For heading control, -370 degrees is a lot different than -10 degrees. At some point in the pipeline, we need to be able to remap results. Either we could bui d a ton of tiny building blocks (at which point we might be better off just writing the autopilot entirely in nasal) or we need to have a way to tell the controller to remap the results at various stanges in the pipeline. I think the add/subtract 360 until in the -180 -- +180 region is an excellent solution. If one does this first to the error (desired heading - current heading) one would get the degrees that the plane should turn. Now one simply uses this value as input to the controller and zero as setpoint to the controller. -- Roy Vegard Ovesen -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
-- Original Message -- From: Jon S Berndt [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Proposed change to Terrain Following control To: FlightGear developers discussions [EMAIL PROTECTED] Date: Thu, 22 Jan 2004 15:40:55 -0600 Reply-To: FlightGear developers discussions [EMAIL PROTECTED] I think more care should be taken with the terminology. This was scaring me for a while, too. What is being done really is providing sensed state to the A/P and FCS. In my work, these are called sensors - NOT instruments. Instruments (in my experience) refer to devices that display sensed state to the pilot. I'm sorry! When I was talking about instruments, I was meaning sensors. Hope this post from Jon removes the confusion I made. -- Roy Vegard Ovesen -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
Any chanceof doing a look-ahead on the scenery polygons to get an altitude eg 2mi in front (for TSR2?) Yes, so long as the tile is loaded. But that's not the way that real autopilots work. The real world doesn't have a scenery elevation API. :) Doing this right would presumably require terrain radar modelling, which hard, and most probably classified anyway. I'm sure Richard means a terrain-following autopilot, which follows terrain. I don't think it would be necessary to model the actual radar. It would be useful to just calculate the lat/long of a point 2mi in front of the airplane, and determine what ground elevation corresponds to that lat/lon. The elevation can be exposed to the property tree so that anyone wishing to terrain-follow can do so. To be more flexible the look-ahead could be based on time, say 5 seconds ahead. As for the scenery elevation API, I have one in the airplane I fly, although it isn't yet certified for navigation. Cruise missles have one and use it for navigation. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
On Thursday 22 January 2004 22:12, David Culp wrote: Any chanceof doing a look-ahead on the scenery polygons to get an altitude eg 2mi in front (for TSR2?) Yes, so long as the tile is loaded. But that's not the way that real autopilots work. The real world doesn't have a scenery elevation API. :) Doing this right would presumably require terrain radar modelling, which hard, and most probably classified anyway. I'm sure Richard means a terrain-following autopilot, which follows terrain. I don't think it would be necessary to model the actual radar. It would be useful to just calculate the lat/long of a point 2mi in front of the airplane, and determine what ground elevation corresponds to that lat/lon. The elevation can be exposed to the property tree so that anyone wishing to terrain-follow can do so. To be more flexible the look-ahead could be based on time, say 5 seconds ahead. As for the scenery elevation API, I have one in the airplane I fly, although it isn't yet certified for navigation. Cruise missles have one and use it for navigation. Dave I've been giving quite a bit of thought to look-ahead algorithms for terrain following. The most straight forward way would be to take a number of look-ahead samples each frame, and simply take the highest point as the target alt. Taking a lot of samples each frame can't be a good idea though so I've been thinking more about single look-ahead sample alogorithms. These don't seem to be too tricky but they're pretty much limited to straight-line flight. It's possible that using several single-sample tracks might work for turns though. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
Lee Elliott wrote: I've been giving quite a bit of thought to look-ahead algorithms for terrain following. The most straight forward way would be to take a number of look-ahead samples each frame, and simply take the highest point as the target alt. Taking a lot of samples each frame can't be a good idea though so I've been thinking more about single look-ahead sample alogorithms. These don't seem to be too tricky but they're pretty much limited to straight-line flight. It's possible that using several single-sample tracks might work for turns though. Let's say you were flying 240 meters/sec and generally in a straight line. Let's also assume we are drawing 60 frames/sec. That means we travel about 4 meters every frame. Let's say we want to look ahead 10 seconds. That is 10 * 240m/s = 2400 meters we would have to look ahead. Figuring a flat ground and the aircraft's pitch angle, figure the appropriate angle to point your radar or laser scaner. Now if you do one terrain intersection lookup each frame and do it 2400 meters ahead of you. But, also keep the last 10 sec * 60 fps lookups in a buffer, then assuming you are flying in a straight line, once your buffer fills up, that gives you a set of elevation points in your path at 4 meter increments looking 2400m ahead. If you turn, this blows the whole scheme so just don't turn. :-) Perhaps after sensing a turn, you could wipe the buffer and start filing it in with one extra terrain intersection lookup per frame, and scan in a binary partitioning pattern ... This would minimize computation cost and *might* work ... Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
Now if you do one terrain intersection lookup each frame and do it 2400 meters ahead of you. But, also keep the last 10 sec * 60 fps lookups in a buffer, then assuming you are flying in a straight line, once your buffer fills up, that gives you a set of elevation points in your path at 4 meter increments looking 2400m ahead. Maybe you could just keep the highest elevation between present position and the look-ahead position. Then have the autopilot seek that elevation + something. Crude, but I think it would work as a first cut. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
On Thursday 22 January 2004 22:54, Curtis L. Olson wrote: Lee Elliott wrote: I've been giving quite a bit of thought to look-ahead algorithms for terrain following. The most straight forward way would be to take a number of look-ahead samples each frame, and simply take the highest point as the target alt. Taking a lot of samples each frame can't be a good idea though so I've been thinking more about single look-ahead sample alogorithms. These don't seem to be too tricky but they're pretty much limited to straight-line flight. It's possible that using several single-sample tracks might work for turns though. Let's say you were flying 240 meters/sec and generally in a straight line. Let's also assume we are drawing 60 frames/sec. That means we travel about 4 meters every frame. Let's say we want to look ahead 10 seconds. That is 10 * 240m/s = 2400 meters we would have to look ahead. Figuring a flat ground and the aircraft's pitch angle, figure the appropriate angle to point your radar or laser scaner. Now if you do one terrain intersection lookup each frame and do it 2400 meters ahead of you. But, also keep the last 10 sec * 60 fps lookups in a buffer, then assuming you are flying in a straight line, once your buffer fills up, that gives you a set of elevation points in your path at 4 meter increments looking 2400m ahead. If you turn, this blows the whole scheme so just don't turn. :-) Perhaps after sensing a turn, you could wipe the buffer and start filing it in with one extra terrain intersection lookup per frame, and scan in a binary partitioning pattern ... This would minimize computation cost and *might* work ... Curt. I don't think you'd need to maintain the full 10 sec * 60fps buffer of samples - just holding the sequence of high points should be ok, and you fly from each one to the next. I don't think you really need to know about any lower elevations within the look-ahead distance. You may not even need to maintain the full series of high-points either - it might be possible to do it with just two or three high point values. Making sure you clear high ground is easy enough - just maintain a high value and compare each new sample with it - if the new sample is higher then that becomes the target and the new high value. Store the distance to the high point each frame and then on the next frame re-calc it to see if it's closer or further away - when the distance increases it's behind you. It's coming back down after a high point that's a bit trickier if you're trying to do it without a full series of high point data. Even so, I'm pretty sure it can be done with just two or three high point values. Dealing with turns is an interesting problem:) I think some degree of turn capability is achievable but trying to come up with something economical that'll stop you from pulling a hard turn into a cliff is probably not feasible - that would need a full 3d awareness system capable of handling tremendous amounts of data. Atm, I've been thinking in terms of a 'supplimental' off-axis scan that starts when a bank/change of direction is detected, and this would need a different scanning scheme to the simple line-ahead method used for straight level fight. Heh! - I've always wanted a good excuse to try a 'Drunkards Walk' scanning algorithm :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Proposed change to Terrain Following control
Lee Elliott writes: On Thursday 22 January 2004 22:54, Curtis L. Olson wrote: Lee Elliott wrote: I've been giving quite a bit of thought to look-ahead algorithms for terrain following. The most straight forward way would be to take a number of look-ahead samples each frame, and simply take the highest point as the target alt. I don't think you'd need to maintain the full 10 sec * 60fps buffer of samples - just holding the sequence of high points should be ok, and you fly from each one to the next. I don't think you really need to know about any lower elevations within the look-ahead distance. You may not even need to maintain the full series of high-points either - it might be possible to do it with just two or three high point values. Making sure you clear high ground is easy enough - just maintain a high value and compare each new sample with it - if the new sample is higher then that becomes the target and the new high value. Store the distance to the high point each frame and then on the next frame re-calc it to see if it's closer or further away - when the distance increases it's behind you. I thnk the fastest way todo this will be to use the Graphics hardware. i.e. render only that part of the terrain that is within your lookahead distance with a *very* narrow field of view into a tall but skinny pbuffer with the eye point at the desired 'agl' distance beneath the current position with the view vector pointing in the direction of travel. Now you can read the position of the obstacles ahead directly from the pbuffer rendered into Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect fog rendering
On Thu, Jan 22, 2004 at 09:35:23PM +0100, Avi Levy wrote: I'm new to this group, and would like to add that if there is any information needed on MD11 and B767 flight characteristics or systems, feel free to ask through this mailing list, I have a lot of flying hours on these types. A MD11 jsbsim model would be nice :-) AFAIR, the MD11 glass cockpit is very similar to the one used on the B717-200. Do you have detailed infos about that ? even screenshots of different situations, closups from cockpit photos... Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] speaking of MD-11's
Here's an interesting MD-11 that NASA has modified: http://www.nasatech.com/Briefs/May02/DRC9655.html Controling the airplane with engines only is interesting, but controling it with engines on one side only is amazing. This could probably be modeled in JSBSim, and perhaps with Curt's new configurable autopilot for FlightGear. Interestingly, I read elsewhere that no owners of MD-11's are interested in the PCA system. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
