Re: [Flightgear-devel] New keyboard bindings
Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: * control b... toggle speedbrake (emh) Shouldn't that be defined at the aircraft level? Ctrl+b is booster on the p51d. And it doesn't have speedbrakes. I made sure the p51d booster functions still works. IMHO it won't harm to have a default assigned to Ctrl+B which can be overruled by aircraft specific bindings. I expect there will be more models with speedbrakes than models with engine boost for instance. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
Norman Vine wrote: Norman Vine wrote: Ummm. 533 math $ c++ -O3 -o test test.cxx fastmath.cxx Ooops pardon the line noise Pfew, you scared me :-D I didn't reinitialize the clock in my test program Here are the updated test results *NICE* win on the log() call And quite accurate also, error around 0.01% 537 math $ ./test log3014 fast_log 120 exp3996 fast_exp 2634 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: how to fix joystick config files
Julian Foad [EMAIL PROTECTED] said: I think what you are proposing is better than the way it is now. However, it should be easy to make it perfect. In your proposal, each binding specifies an amount of change per step, and you fix the number of steps per second (which previously was varying, being faster on faster machines). The objections are that the smoothness of control operation is limited by this fixed step rate. Instead of that, have the binding specify the amount of change PER SECOND (i.e. the rate of change), and allow the number of steps per second to vary with machine power and load. At each step, the new value is calculated so that the control is moving at the specified rate: value += rate * delta_t. That would make the rate of change well defined, but the smoothness would be better on faster machines. I f Jim wants to control the update frequency he can then do so very easily. But the important thing to do first is to define the rate of change rather than the amount per undefined time step. This is a sounds good. But it is possible that some controls might be better off sacrificing speed for higher resolution step sizes on certain systems (e.g. trim controls). Then again we could pick and chose which controls use the per second method and which use the fixed steps (in other words, support both). As I mentioned earlier...controlling the update frequency doesn't seem necessary to me right now. Best, Jim To get both fine step and constant rate modes, could it be implemented something like the standard PC keyboard interface? That is you get a single click if you press the button for less than 0.2 second or so, and only after that does it go into bananas per second mode. Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: how to fix joystick config files
* Richard Bytheway -- Monday 30 June 2003 10:20: To get both fine step and constant rate modes, could it be implemented something like the standard PC keyboard interface? That is you get a single click if you press the button for less than 0.2 second or so, and only after that does it go into bananas per second mode. IMHO not necessary. Let me explain: The ominous patch does - not affect the analog axes =at all= - not affect ordinary buttons =at all= - only throttle repeatable buttons to a constant trigger rate, so as to make the step sizes CPU independent; This trigger rate could well be 50 or 100 Hz if deemed necessary. What are repeatable buttons used for? - to let a digital input device (regular button, or digital hat switch) emulate an analog device I looked through all joystick config files and here is what repeatable buttons are used for: - set the view direction elevation via hat switch - set rudder elevator aileron trim - set engine boost mixture propeller pitch - set rudder (only in my own joystick file :-) Emulating an analog axis with two buttons is only a workaround for a missing real analog device. It can in any case only be used for things that don't require smoother operation than can be guaranteed by constant 50 or 100 Hz trigger rate, given that the time from starting to push the button until the contacts are closed is arbitrary, and that you never know the current position and state. (I have to use a third button to center the rudder. How smooth can the rudder operation be made even on a 20 GHz computer, if it relies on three buttons and a human? ;-) But again: all this won't be a problem for =me=. I know how to fix it for my computer, and it'll be a while until I can afford a faster one, anyway. So, in fact, I don't really care. (Maybe the thousand users are what matters ...) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: how to fix joystick config files
* Melchior FRANZ -- Monday 30 June 2003 10:57: I looked through all joystick config files and here is what repeatable buttons are used for: - set the view direction elevation via hat switch - set rudder elevator aileron trim - set engine boost mixture propeller pitch - set rudder (only in my own joystick file :-) - set brakes Sorry for this omission. It didn't mean to manipulate the result. ;-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New keyboard bindings
Erik Hofman [EMAIL PROTECTED] said: Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: * control b... toggle speedbrake (emh) Shouldn't that be defined at the aircraft level? Ctrl+b is booster on the p51d. And it doesn't have speedbrakes. I made sure the p51d booster functions still works. IMHO it won't harm to have a default assigned to Ctrl+B which can be overruled by aircraft specific bindings. I expect there will be more models with speedbrakes than models with engine boost for instance. Should we set aside CTRL keys for aircraft specific use? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Melchior FRANZ [EMAIL PROTECTED] said: But again: all this won't be a problem for =me=. I know how to fix it for my computer, and it'll be a while until I can afford a faster one, anyway. So, in fact, I don't really care. (Maybe the thousand users are what matters ...) Ummm...then that means it would be ok with you to adopt Julian's idea? ::: duck ::: :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: how to fix joystick config files
* Jim Wilson -- Monday 30 June 2003 13:36: But again: all this won't be a problem for =me=. I know how to fix it for my computer, and it'll be a while until I can afford a faster one, anyway. So, in fact, I don't really care. (Maybe the thousand users are what matters ...) Ummm...then that means it would be ok with you to adopt Julian's idea? For me personally, yes, of course. I was just in an idealistic mood and thought that bugs should be fixed. And that an existing patch that only adds 11 lines and fixes the problem is worth more than hot air that has yet to materialize. But then again, the next release isn't exactly due next week and I'm probably the only one who even noticed this design flaw. :- ::: duck ::: :-) I won't duck. Hit me, if you can. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New keyboard bindings
Jim Wilson wrote: Should we set aside CTRL keys for aircraft specific use? That might not be a bad idea! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] serial interface
Nick Wright writes: I would like to use flightgear as a testbed for controller software for an R/C model aircraft. I have a small R/C plane and am using a Sharp Zaurus (linux palmtop PC) to interface with the aircraft hardware via a serial cable. The aircraft has digital compas and GPS sensors onboard. What is the best way to set up flightgear to interface with an external application? Usually the best way depends on your specific circumstances. Will the two applications be running on the same machine? If not, do the two machines have a high speed network connection or some slow radio modem type connection? How much data are you sending and at what rate? Do you need really tight timing or can you get by with some delays and sloppiness in the communication? Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Re: how to fix joystick config files
Jim Wilson writes: Actually after thinking about it, it seems to me that we don't need to have an update frequency setting for joytsicks (fixed or adjustable). Users can adjust the step sizes on individual buttons or axes in the xml file for the joystick. Adjusting step sizes without locking in an update frequency (even if adjustable) gives the most flexibility. Currently, the actual update frequency depends on the framerate. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Jim Wilson wrote: Julian Foad [EMAIL PROTECTED] said: have the binding specify the amount of change PER SECOND (i.e. the rate of change), and allow the number of steps per second to vary with machine power and load. At each step, the new value is calculated so that the control is moving at the specified rate: value += rate * delta_t. That would make the rate of change well defined, but the smoothness would be better on faster machines. I f Jim wants to control the update frequency he can then do so very easily. But the important thing to do first is to define the rate of change rather than the amount per undefined time step. This is a sounds good. But it is possible that some controls might be better off sacrificing speed for higher resolution step sizes on certain systems (e.g. trim controls). It is possible, but I can't think of any examples. I wouldn't want the trim wheel to run slowly when my computer is heavily loaded. That would just be a nuisance. After all, any computer since the 1980s has enough power to operate these controls with plenty of speed AND smoothness if the software is written appropriately. One way to increase resolution without sacrificing speed is to use acceleration: when you press the key, the control moves slowly to begin with and then speeds up. This is very appropriate for knobs on the instrument panel, because a real-life knob can be turned both slowly-and-accurately and fast. Then again we could pick and chose which controls use the per second method and which use the fixed steps (in other words, support both). We could, but do you really want to use fixed steps at a variable rate for your trim control or for anything else, given alternatives? As I mentioned earlier...controlling the update frequency doesn't seem necessary to me right now. I agree. So the proposals are: 1. Specified step size; undetermined step time. This is what we have now and isn't good enough. 2. Specified step size; fixed step time (e.g. 0.01 second). This actually means that the step size implies the rate of change. 3. Specified rate of change. As far as the binding is concerned, the specified rate in bananas per second is equivalent to the step value in (2) but a factor of 100 bigger; or it could be specified in bananas per centisecond so that the specified value is exactly the same as the step value in (2). As far as the implementation is concerned, we have the freedom to implement it as a fixed-frequency update, or a variable-frequency update. The only differences between (2) and (3) as far as the user is concerned are a possible factor of 100 difference in the value specified in the binding (no big deal) and the fact that step always guarantees that the control moves in whole multiples of the specified step. Is this latter point important? I think it might be relied upon by the radio tuning controls, for example. Therefore (2) is a safer method. Other enhancements like acceleration are independent of this choice and can be added later. Choice of update frequency: A. Fast enough to capture the duration of the button press fairly accurately. About 20 to 40 Hz corresponds to human accuracy in my opinion. B. Smooth enough for control purposes. If a flight control position is updated less frequently than the FDM calculations at running, then the aircraft will shake. Should update at the FDM rate or a multiple of it. C. Smooth enough for visual feedback (where the control being moved is directly visible). Should update at the frame rate or a multiple of it. In order to match the update rate to the FDM rate and/or frame rate, if those can vary, then proposal (3) would be required. For the time being, I am in favour of Melchior's patch, with a fixed update frequency of (say) 100 Hz, or perhaps 120 Hz if the FDMs are fixed at that frequency. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Melchior FRANZ wrote: What are repeatable buttons used for? - to let a digital input device (regular button, or digital hat switch) emulate an analog device What about keyboard buttons (keys)? Are they not going to work in the same way? Or are they already handled properly (FGFS implementing a fixed repeat rate while a key is held down)? I looked through all joystick config files and here is what repeatable buttons are used for: - set the view direction elevation via hat switch - set rudder elevator aileron trim - set engine boost mixture propeller pitch - set rudder (only in my own joystick file :-) (and brakes, you added) That's a useful list to look at. For instance, none of those things require to move in exact multiples of a specified step size, unlike the radio tuning which might. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Wiki
On Sat, Jun 28, 2003 at 06:24:19PM -0700, WillyB wrote: I have made a list of common acronyms for myself a while ago. Some definitions are adapted from the flightsim navigation tutorial at http://www.navfltsm.addr.com/ My list can be found at: http://cockpit.varxec.de/acronyms/ There are 74 entries right now. Would you mind if I posted that list on the Wiki? No, go ahead :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New keyboard bindings
Erik Hofman [EMAIL PROTECTED] wrote: Jim Wilson wrote: Should we set aside CTRL keys for aircraft specific use? That might not be a bad idea! Yesterday the conductor of out orchestra told us _not_ to use the word 'bad' for describing positive events or facts. This, he said, would be a bad habit among users of the German language :-) 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
[Flightgear-devel] Re: how to fix joystick config files
* Julian Foad -- Monday 30 June 2003 15:08: What about keyboard buttons (keys)? Are they not going to work in the same way? Or are they already handled properly (FGFS implementing a fixed repeat rate while a key is held down)? The changes are only in _update_joystick(). The keyboard's behaviour is not affected. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: how to fix joystick config files
* Julian Foad -- Monday 30 June 2003 15:08: For the time being, I am in favour of Melchior's patch, [...] It's Erik's patch, only slightly hacked by me. ;-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Compass Problem
Innis Cunningham writes: I am just wondering if anyone is looking at the problem with the compass readout.It reads from -12 to 348. Hmm... I don't see this, but I compile with // newauto.hxx #define DEFAULT_AP_HEADING_LOCK FGAutopilot::FG_TRUE_HEADING_LOCK instead of //#define DEFAULT_AP_HEADING_LOCK FGAutopilot::FG_DG_HEADING_LOCK Not sure if this has any 'bearing' on the issue though Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Julian Foad [EMAIL PROTECTED] said: It is possible, but I can't think of any examples. I wouldn't want the trim wheel to run slowly when my computer is heavily loaded. You would if you were unable to trim because the step sizes were to big and you wanted to trim from the joystick. 1. Specified step size; undetermined step time. This is what we have now and isn't good enough. Only not good enough if you insist that the joystick configs work the same and on all systems without adjustment. For the time being, I am in favour of Melchior's patch, with a fixed update frequency of (say) 100 Hz, or perhaps 120 Hz if the FDMs are fixed at that frequency. That was Erik's patch. What I'd like to do, if this is what everyone wants, is to add a property to the joystick binding structure called interval-sec (to be used on the bindings that have low/high defined--axis emulation). If it is defined then use it (or default it to zero). That way only the bindings that require such timing (e.g. rudder controls) will be affected. If this is acceptable then I'll work on adding this to the patch. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] New keyboard bindings
Curtis L. Olson [EMAIL PROTECTED] said: Martin Spott writes: Yesterday the conductor of out orchestra told us _not_ to use the word 'bad' for describing positive events or facts. This, he said, would be a bad habit among users of the German language :-) In my culture if someone asks you how you are doing, the most positive thing you should ever say is not too bad. Because, you never know, even if things are going really well, they could get worse at any time, and you wouldn't want to overstate your state of wellness. Besides, everyone else says not too bad and if someone said something different, it would make them stand out, which again is something to be avoided. :-) Here in Minnesota, we forked the scandanavian culture, switched to english, mixed in a bunch of other random stuff like MTV, Mexican food, and Polka dancing. But all in all, it's not too bad; could be worse. Then there is the case where just bad means good :-) See the paragraph headed Our Living Language at: http://www.bartleby.com/61/7/B0020700.html Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: how to fix joystick config files
* Jim Wilson -- Monday 30 June 2003 15:45: [...] Only not good enough if you insist that the joystick configs work the same and on all systems without adjustment. Whereby everybody knows that fgfs should behave differently on every system ... ;-) What I'd like to do, if this is what everyone wants, is to add a property to the joystick binding structure called interval-sec (to be used on the bindings that have low/high defined--axis emulation). If it is defined then use it (or default it to zero). That way only the bindings that require such timing (e.g. rudder controls) will be affected. That would be =all= repeatable bindings then. The change of view direction/elevation simulates head movement. Braking simulates feet movement on pedals. Mixture ... you get the point. Every set of repeatable buttons emulates (analog) human-machine interaction. I cannot imagine why head movement should be ten times as fast on a faster machine. It's still the same pilot. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Melchior FRANZ [EMAIL PROTECTED] said: That would be =all= repeatable bindings then. The change of view direction/elevation simulates head movement. Braking simulates feet movement on pedals. Mixture ... you get the point. Every set of repeatable buttons emulates (analog) human-machine interaction. I cannot imagine why head movement should be ten times as fast on a faster machine. It's still the same pilot. Not all pilots are the same. Some heads are faster than others. And even though some like to use the mouse for trim wheels, I like the joystick hat. And I like it speedy and high resolution for accurate trimming. Lets just do it with the bindings that are presenting real problems, and stop worrying about slowing down the fast machines so they match the slower machines. I've completed the patch (took less time than writing these last two emails on the subject). All you need to do is specify: interval-sec0.05/interval-sec for the binding in question and you will get a 20 per second repeat rate. It works. If this makes sense to anyone besides myself, I'll submit the patch. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aero-Matic
David Culp writes: Thanks Ryan, I'll be AFK for a couple days, but if anyone would care to try Aero-Matic out I'd like to hear comments. I know the pitch damping in the fighters is a bit weak. I haven't tested the piston engines because I can never remember how to start them. Also, the transport planes are really jet transports, so will have a higher wing loading than, say, a DC-6. I might need to add a prop-transport category (and maybe UAV, RC-model, ultralight, etc). Dave Culp This should now also be available at: http://www.flightgear.org/aeromatic/ Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] [PATCH] Compass Problem fixed
The /orientation/heading-magnetic-deg value goes negative by the variation when close to 360 degrees. Here's a fix: http://www.spiderbark.com/fgfs/fg_props_maghdg.diff Best, Jim Norman Vine [EMAIL PROTECTED] said: Innis Cunningham writes: I am just wondering if anyone is looking at the problem with the compass readout.It reads from -12 to 348. Hmm... I don't see this, but I compile with // newauto.hxx #define DEFAULT_AP_HEADING_LOCK FGAutopilot::FG_TRUE_HEADING_LOCK instead of //#define DEFAULT_AP_HEADING_LOCK FGAutopilot::FG_DG_HEADING_LOCK Not sure if this has any 'bearing' on the issue though Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] plib patch for Solaris
The following patch enables building plib on Solaris. Would anyone with appropriate connections pushing this to the plib people ? Probably this enables us building FlightGear binaries for Solaris: --- src/util/ul.h.original Mon Jun 30 19:16:02 2003 +++ src/util/ul.h Mon Jun 30 19:13:22 2003 @@ -80,7 +80,7 @@ #define UL_IRIX 1 -#elif defined(SOLARIS) +#elif defined(SOLARIS) || defined(sun) #define UL_SOLARIS 1 @@ -121,7 +121,7 @@ #include unistd.h #endif -#if defined(UL_LINUX) || defined(UL_BSD) || defined(UL_IRIX) +#if defined(UL_LINUX) || defined(UL_BSD) || defined(UL_IRIX) || defined(UL_SOLARIS) #include unistd.h #include dlfcn.h #include fcntl.h 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
[Flightgear-devel] Autothrottle
I'd like to project (simplisticly) airspeed in 10 seconds, primarily for autothrottle accuracy with jet engines, but also for display purposes. The idea would be something like this: airspeed_in_10secs = airspeed_kt + (airspeed_kt - last_airspeed_kt) * (10/dt); Anyone have any thoughts on which class we should add this? It could go into the autopilot code...but...maybe it belongs elsewhere. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Autothrottle
Jim Wilson writes: I'd like to project (simplisticly) airspeed in 10 seconds, primarily for autothrottle accuracy with jet engines, but also for display purposes. The idea would be something like this: airspeed_in_10secs = airspeed_kt + (airspeed_kt - last_airspeed_kt) * (10/dt); You might want to increase your sample rate a bit: for example, you could sample every second and do a rolling weighted average of the acceleration (delta airspeed) over the past ten seconds. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autothrottle
David Megginson writes: Jim Wilson writes: I'd like to project (simplisticly) airspeed in 10 seconds, primarily for autothrottle accuracy with jet engines, but also for display purposes. The idea would be something like this: airspeed_in_10secs = airspeed_kt + (airspeed_kt - last_airspeed_kt) * (10/dt); You might want to increase your sample rate a bit: for example, you could sample every second and do a rolling weighted average of the acceleration (delta airspeed) over the past ten seconds. Sounds like a classic begging for a Kalman Filter Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Autothrottle
David Megginson [EMAIL PROTECTED] said: Jim Wilson writes: I'd like to project (simplisticly) airspeed in 10 seconds, primarily for autothrottle accuracy with jet engines, but also for display purposes. The idea would be something like this: airspeed_in_10secs = airspeed_kt + (airspeed_kt - last_airspeed_kt) * (10/dt); You might want to increase your sample rate a bit: for example, you could sample every second and do a rolling weighted average of the acceleration (delta airspeed) over the past ten seconds. That was my original thought, but I was afraid that it would extend the upper/lower limits (make larger predictions) and my readings would come up short. So it seemed to be safer, and of course easier, to base the data on what was happening at that instant, rather than over time. Using this method I've been able to really zero in the selected speed for the autothrottle on the 747. The cessna does just as well, so both extremes if you will seem to respond well to the simplistic 10 second projection. The thing I'm concerned with now is locking in an update frequency for the autopilot. Any suggestions on which method I should use? Currently the autopilot updates just before the fdm_states in the main loop...and doesn't do that until after the FDM inits. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autothrottle
Norman Vine [EMAIL PROTECTED] said: Sounds like a classic begging for a Kalman Filter Hmmm...I looked that up. Is this as complex as it looks? (see http://www.cs.unc.edu/~welch/kalman/kalman_filter/kalman-1.html#pgfId-11839) If not it might be worth checking out when the boeing stuff gets sophisicated enough to start thinking about flight directors and land mode. Trivia question: is Rudolph Kalman related to Paul Newman? http://www.ece.ufl.edu/COE/pages/images/profiles/kalrud.jpg http://i.imdb.com/Photos/Ss/0084855/024543042532_z_verdiccu.jpg Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autothrottle
Jim Wilson writes: David Megginson [EMAIL PROTECTED] said: Jim Wilson writes: I'd like to project (simplisticly) airspeed in 10 seconds, primarily for autothrottle accuracy with jet engines, but also for display purposes. The idea would be something like this: airspeed_in_10secs = airspeed_kt + (airspeed_kt - last_airspeed_kt) * (10/dt); You might want to increase your sample rate a bit: for example, you could sample every second and do a rolling weighted average of the acceleration (delta airspeed) over the past ten seconds. That was my original thought, but I was afraid that it would extend the upper/lower limits (make larger predictions) and my readings would come up short. So it seemed to be safer, and of course easier, to base the data on what was happening at that instant, rather than over time. Jim If you aren't familiar with a Kalman Filter you *really* should read this http://www.cs.unc.edu/~welch/media/pdf/maybeck_ch1.pdf Coding one of these is actually quite straight forward http://cvs.sf.net/cgi-bin/viewcvs.cgi/autopilot/onboard/rev2/ahrs.c?rev=HEADcontent-type=text/vnd.viewcvs-markup Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
