Re: [Flightgear-devel] Seneca II tutorials - Torsten
- Get the latest update from CVS - Via the Menu call Help-Start Tutorial Or - Read this http://wiki.flightgear.org/flightgear_wiki/index.php?title=Piper_PA34-200T_Seneca_II http://wiki.flightgear.org/flightgear_wiki/index.php?title=Seneca_II_Checklist http://wiki.flightgear.org/flightgear_wiki/index.php?title=Seneca_II_HOWTO http://wiki.flightgear.org/flightgear_wiki/index.php?title=Seneca_II_Panel_Reference Enjoy Torsten Am Samstag, 1. Dezember 2007 17:08 schrieb Fabian Grodek: Where can I find the tutorial? Fabian - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Prerelease 0.9.11 some testresults
On Thursday 29 November 2007 16:34, Torsten Dreyer wrote: Am Donnerstag, 29. November 2007 14:44 schrieb Hans Fugal: Is there not a way to sanity check the cloud cache size in the plib version before going ahead and segfaulting? Like notice that it's 0 and set it to the lowest valid value. It seems that this would be a simple fix, and that there's really no excuse not to do it. Unless, of course, there is a real excuse... This should do the trick: Instead of doing nothing when setting a new value to zero, the resolution and cacheSize is set to it's default value when trying to set it to zero. It works on my copy, but maybe one of the screnegraph experts should comment this. Torsten I decided to go ahead and commit this, even though I haven't seen any further comment from a scenegraph expert. The patch seems simple enough, and preventing program crashes would make it worthwhile. If there is breakage, it seems easy enough to revert. :-) Cheers, Durk - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RFC: Control surface position damping
When prssing the 5 key on the numeric keypad to reset the controls to zero, the control surfaces instantly move to their origin. Similar effects can also happen when an autopilot controller is activated, and when a noisy joystick is interfering with an autopilot controller. I think moving a control surface, like for example the rudder, from full left deflection to rull right deflection in an instant is unrealistic. To make this more realistic I think we should put in a low pass filter somewhere in the chain from crontrol device to FDM. My first thought would be to do the filtering just befir handing the value over to the FDM. Does anyone on the list have comments on this? -- Roy Vegard Ovesen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On Sunday 02 December 2007, John Denker wrote: That's not a good solution. That's highly unrealistic. In real life, in a small airplane, if I decide to stomp on the rudder pedal, the rudder is going to move real fast. The realistic time scale is not long compared to 1/30th of a second i.e. the inverse frame rate. That is to say, any filter with a realistic timescale wouldn't solve the problem. OK, thats one end of the scale. How about the other end, a big aircraft with huge control surfaces? The filtering would have to be configurable on at least a per aircraft basis. Possibly on a per control surface basis. The problem (as usual) lies with the nut behind the steering wheel. If you don't want the rudder to move real fast, don't command the rudder to move real fast. -- Specifically, if the problem is a noisy joystick, fix the joystick somehow; don't mess up the FDM. -- If 5 is doing the wrong thing, make 5 do the right thing. The problem that I am addressing is the fact that an object can not move from one position to another in an instant. That would of course require an unlimited amount of force. -- Roy Vegard Ovesen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On Sunday 02 December 2007, David Megginson wrote: That's true for control surface movement in general, but I had (mis)understood that Roy was proposing this specifically for the '5' key -- that's a simulator-specific key that has no real-life equivalent, so binding it to a new command that has a low-pass filter would probably be a good idea. We don't have to worry about realism for this key, just controllability. I mentioned the 5 key only as an example. I am not proposing to put a filter on that command. -- Roy Vegard Ovesen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On Sun, 2 Dec 2007, Curtis Olson wrote: This touches on an earlier design flaw in FlightGear. We have control inputs feed directly into surface positions, and that is it. There is some horsing around you can do with Nasal, but it's not ideal. What we really should have [I think] is pilot control inputs - [flight control black box] - desired surface positions - actual surface positions. This is certainly possible to do in JSBSim and I'd be very surprised if YASim can't do the same. Cheers, Anders -- --- Anders Gidenstam mail: anders(at)gidenstam.org WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Yasim and taileron; JSBsim and thrust-reverser
Hi, maybe this fit more to the flightmodel-list, but I'm not sure about if this list is really be read;-) Trying to do a fdm with yasim for a Panavia Tornado GR4 IDS I noticed that it seems to me not possible to model a taileron (elevator and aileron in one control surface at the tail)- I always get the error message: Insufficient elevator to trim for approach I tried this also on the Lightning-yasim but the same error... It is really not possible? On JSBsim I noticed that the thrust reverser are not working ( as an example Fokker 70/100), but I remember that it was working with 0.9.9 and 0.9.10 - something changed or I'm too stupid? thanks Regards HHS __ Ihr erstes Baby? Holen Sie sich Tipps von anderen Eltern. www.yahoo.de/clever - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On 02/12/2007, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: I mentioned the 5 key only as an example. I am not proposing to put a filter on that command. In general, then, as others have mentioned, this belongs in the flight models rather than the input layer. The input layer *requests* a position -- it's up to the flight model to decide if or how fast to provide it. Putting the joystick to full right ailerons is just asking full right ailerons, please. I do like the idea of a filter on '5', though. All the best, David - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On Sunday 02 December 2007, Roy Vegard Ovesen wrote: I think moving a control surface, like for example the rudder, from full left deflection to rull right deflection in an instant is unrealistic. To make this more realistic I think we should put in a low pass filter somewhere in the chain from crontrol device to FDM. My first thought would be to do the filtering just befir handing the value over to the FDM. Turns out that JSBSim and YASim already has what I'm looking for. My question then is reduced to: why doesn't more FDM modellers use these features of JSBSim and YASim to create cotrol surfaces that seem to have mass -- Roy Vegard Ovesen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Informal version number poll
On Saturday 01 December 2007 02:38:13 pm alexis bory wrote: Heiko Schulz wrote: But we havn't found a number yet- so how should we find the right name? Alexis Identifying the versions as stable testing and unstable might not be a bad idea. It tells people that active development is going on and there are new releases planned. eg... Flightgear Current Stable Version 0.9.10 Wright Testing 1.0 Lindenburg Unstable v1.5-osg Simstick I have not thought much about the names but I have thought about some easy to understand scheme to show that future versions are being worked on. It would be easier than writing a current news letter (hmmm.) - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Informal version number poll
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Robert Black schrieb: On Saturday 01 December 2007 02:38:13 pm alexis bory wrote: Heiko Schulz wrote: But we havn't found a number yet- so how should we find the right name? Alexis Identifying the versions as stable testing and unstable might not be a bad idea. It tells people that active development is going on and there are new releases planned. eg... Flightgear Current Stable Version 0.9.10 Wright Testing 1.0 Lindenburg Unstable v1.5-osg Simstick As I wrote before I doubt that that will work for FGFS. Currently we've got a stable branch (even numbers at the second position) and a development branch (odd numbers at the sechon position). But all we do happens in the development brach and nothing gets backported to the stable branch. I'm for dropping this scheme and only release current versions. BTW, even the linux kernel developing process dropped that scheme - and *they* are realy depending on showing the customers (aka users) if they are working with stable or unstable code... A crashing FGFS is annoying, a crashing kernel can be desasterous... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHUtqmoWM1JLkHou0RCCM8AJ9zr/e8RSUV2hlwChn88/zHHiBvvQCfceWw 26zRmzlAFEZIW3qMcmrsc2w= =sMcf -END PGP SIGNATURE- - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On 12/02/2007 10:18 AM, Roy Vegard Ovesen wrote: My question then is reduced to: why doesn't more FDM modellers use these features of JSBSim and YASim to create cotrol surfaces that seem to have mass Probably because in most cases, it would a very unrealistic way to deal with the reported problems. The problem that I am addressing is the fact that an object can not move from one position to another in an instant. Nobody is arguing that they should move in an instant. They can, however, move rather fast. The timescale is not long compared to the inverse framerate of the sim. Any filter that would be noticeable on this timescale would be unrealistic. The problem that I am addressing is the fact that an object can not move from one position to another in an instant. Why? Because it looks bad? If the pilot rapidly moves the control surfaces, it not only looks bad; it *is* bad. However, that doesn't mean it can't happen. http://www.ntsb.gov/publictn/2004/AAR0404.htm That would of course require an unlimited amount of force. Before we can discuss the laws of physics, you need to figure out what *you* are talking about. a) damping [from the subject line] ??? That's a stick force proportional to X dot. b) mass [above] ??? That's a stick force proportional to X dot dot. c) big aircraft with huge control surfaces [previous msg] ??? That can give rise to a stick force proportional to X. d) slew rate limiting in the hydraulic system ??? That's something yet again, not mentioned until now. e) programmed slew rate limiting in the autopilot ??? Since very few of our users have force-feedback joysticks, there is no realistic way to model (a), (b), or (c) ... and attempting to model any of those with the suggested low-pass filter is a bad idea ... worse than no filter at all. Item (d) makes more sense; it should be modeled by the FDM on the few aircraft that actually exhibit a significant amount of this behavior. Item (e) should be modeled within the autopilot. Real autopilots are sure-as-shootin slew rate limited. I mentioned the 5 key only as an example. I am not proposing to put a filter on that command. Too bad; that would have been a sensible proposal. The 5 key is essentially in the autopilot category; it should feed a smooth signal to the control system. This is *not* considered a limitation on how the control system responds to inputs; it is a limitation on the output from the autopilot and autopilot-like systems. = To repeat: 1) In the overwhelming majority of aircraft, Asking the FDM to low-pass filter the controls (to any significant degree) is unrealistic. 2) In the few aircraft where there is a significant limitation in the fly-by-wire system, sure, go ahead and model it. This will require a lot more than a low-pass filter. 3) As the proverb says, pilots are judged on their smoothness, not on their quickness. Smoothness is built into the pilots; it is not usually built into the hardware. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] local key bindings ... Meta Super
Here's my Crazy Idea Of The Day:
The question was asked a few times, whether there are keys
reserved for local customization purposes. There are none.
But we have some completely unused shift levels. The X window
system supports 8 modifiers (usually called shift, ctrl, alt,
capslock, meta, super, hyper, and-another-one). All of them
can be combined. You can have Super-Meta-Ctrl-Shift-Alt-q.
But this isn't only hard to type in for those with only
10 fingers, it's also not supported everywhere (MS Windows?).
What we could do, though, is to invent a new modifier level
for local use. One that works everywhere. By just redefining
a key that is bigger than the others and easy to hit, just
like the other modifiers ... umm ... except alt, altgr)
Tadaaa: The TAB modifier! :-)
With the attached simple script the TAB key becomes a modifier
that shifts all key codes up by adding 1000 to them. So, if you
press TAB-a, you get the key n=1098 definition triggered.
This works also in combination with regular modifiers Shift-Tab-a,
etc. (Except that Shit-Tab-a only triggers the mod-shift part
of A, not A itself. Could easily be changed, but that's left
as an exercise to the student.)
m.
var local = 0;
var active = {};
_setlistener(/devices/status/keyboard/event, func {
var event = cmdarg();
event.getNode(key).setValue(handle_key_event(event));
});
var handle_key_event = func(e) {
var key = e.getNode(key).getValue();
var pressed = e.getNode(pressed).getValue();
if (key == `\t`) {
local = pressed;
return 0;
} elsif (local) {
active[key] = e.getNode(modifier).getValue();
return key + 1000;
} elsif (!pressed and contains(active, key)) {
e.getNode(modifier).setValue(active[key]);
key += 1000;
}
delete(active, key);
return key;
}
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] local key bindings ... Meta Super
--- Melchior FRANZ wrote: Here's my Crazy Idea Of The Day: snip What we could do, though, is to invent a new modifier level for local use. One that works everywhere. By just redefining a key that is bigger than the others and easy to hit, just like the other modifiers ... umm ... except alt, altgr) Tadaaa: The TAB modifier! :-) That is an excellent idea, and gives users plenty of choice. However, I expect that a lot of people won't have the skills required to include such Nasal code themselves. Would it be possible to integrate the function more thoroughly into the codebase, so that it is Just There for new users and they can simply add new key bindings to keyboard.xml? One or two aircraft also currently use Tab (including the Vulcan) for other purposes, but I'm more than happy to swap the Vulcan to use another key (though it would be nice to define the reserved aircraft keys first ;) ). -Stuart ___ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Informal version number poll
n Sat, 1 Dec 2007 21:24:06 +0100 (CET), Heiko wrote in message [EMAIL PROTECTED]: --- alexis bory [EMAIL PROTECTED] schrieb: Heiko Schulz wrote: And as first name we should take Wright- the first pilot an an aircraft OK, but let's call 0.9.11pre2 == Clement Ader ! Alexis Gustav Weisskopf! ..I raise you Hans Andreas Navrestad's 1825 400 meter glide across the Navrestad Lake in Lund, Norway, then we have Muslims, Chinese, and possibly pre-Columbian Americans and Egyptians flying gliders, some even rocket powered, and likely hot air balloons too, before the French woke up. ;o) To be serious - nice idea, but not very practicable. Mabye as add-on to the number like Ubuntu does. But we havn't found a number yet- so how should we find the right name? ..we have 0.9.11 which should add sea floor data in the scenery, so we can do proper sea level rise and carbon sink simulations too. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] local key bindings ... Meta Super
* Melchior FRANZ -- Sunday 02 December 2007:
Tadaaa: The TAB modifier! :-)
D'oh! I had tried it with +500, and just to make it prettier I
changed it to 1000 before posting. And that crashes, because
input.cxx sets MAX_KEYS = 1024. So we are back at 500, which
is good enough.
New version attached, even shorter, even cooler. ;-)
m.
var local = 0;
var active = {};
_setlistener(/devices/status/keyboard/event, func {
var e = cmdarg();
var keyN = e.getNode(key);
var key = keyN.getValue();
var pressed = e.getNode(pressed).getValue();
if (key == `\t`) {
local = pressed;
key = 0;
} elsif (local) {
active[key] = e.getNode(modifier).getValue();
return keyN.setValue(key + 500);
} elsif (!pressed and contains(active, key)) {
e.getNode(modifier).setValue(active[key]);
key += 500;
}
delete(active, key);
keyN.setValue(key);
});
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On Sunday 02 December 2007 15:18, Roy Vegard Ovesen wrote: On Sunday 02 December 2007, Roy Vegard Ovesen wrote: I think moving a control surface, like for example the rudder, from full left deflection to rull right deflection in an instant is unrealistic. To make this more realistic I think we should put in a low pass filter somewhere in the chain from crontrol device to FDM. My first thought would be to do the filtering just befir handing the value over to the FDM. Turns out that JSBSim and YASim already has what I'm looking for. My question then is reduced to: why doesn't more FDM modellers use these features of JSBSim and YASim to create cotrol surfaces that seem to have mass -- Roy Vegard Ovesen There are several aspects to this problem and I've not found a single solution to all of them. However, it's usually possible to get there using a combination of techniques. I agree that instant deflections are un-realistic and using the FDM features to set the speed at which control surfaces respond is the first step. To be sure, on some aircraft the deflection rates can be very high e.g. recent fbw fighter aircraft like the F-16 etc, but even with these the response is not instant so a suitable rate should be set in the FDM config. However, setting the deflection rate isn't sufficient in all cases because the the forces required to make a deflection can vary with speed and if we assume constant force control inputs then the effective maximum deflection rate will vary according to speed. Setting too low a deflection rate can also upset A/P PID controllers that work ok with higher deflection rates - I experienced this recently while working on the B-52F. I wanted to reduce the elevator deflection rate to simulate the very heavy stick and pedal forces that act as a natural pitch-damper but I found that setting it too low upset one of the controllers that worked ok with higher rates but I couldn't manage to re-tune it satisfactorily to get the same response with the lower rate. I think this problem is more to do with the rates, and therefore resolution, at which the controllers run in FG, typically less than 100Hz rather than in kHz ranges. Another aspect of this problem, as you mentioned earlier, is when an A/P controller is first switched in. At this point, if the controller sees no natural convergence between the current state and the required state it'll command a maximum output. For example, you're in level flight below the target altitude-hold setting and you switch on altitude-hold - the controller first sees zero climb-rate and therefore zero convergence and so swings to max output. Once the aircraft has responded to this initial max output the controller will then see convergence and back-off on it's output to achieve convergence in accordance with it's settings. It's possible to reduce the initial 'kick' from the controller but only by setting very low gain rates Kp and long periods Ti but these may not be compatible with the required performance i.e. it can take too long to start a climb and stabilise at the required rate. One way help with this is to use a noise-spike filter to limit the max rate of change on the output from the controller, the filter being tuned to the controller. This problem can also manifest itself when switching between different controller cascades, with different gains and periods, that operate on the same control surface. To get around this I've started using a common control surface driver that is used by all higher-level controllers/controller hierarchies. The lowest level controller is a common pitch-hold driver for the elevator - it takes a target pitch and tries to achieve it by deflecting the elevator. For vertical climb-rate hold you add a controller that outputs a target pitch to achieve a target rate of climb and for altitude hold you add a controller that outputs a target climb-rate. The end result is a two stage cascade for vertical climb-rate hold and a three stage cascade for altitude hold but because there is no switching between controllers at the control surface level, which has constantly been engaged, there is less likelyhood of sudden max output commands. Seems to work ok in practice too - I've used this method on several of the more recent aircraft I've done. Unfortunately though, this method can't be used with aircraft where elevons are used for both pitch and roll (e.g. SU-37) and the best bet there is to use more filters to limit the rates. There are a couple of things relating to this area that would be very helpful. One would be to be able to change some of the filter parameters while they are running or switch filters on and off. With this feature it would be possible to use different filter rates depending on circumstances and/or conditions but as it is, once a filter is running it is always running and with invariable settings. The other thing
Re: [Flightgear-devel] Yasim and taileron; JSBsim and thrust-reverser
Thanks, Markus Zojier hepled me too. We have to much aircrafts, I was completely lost- so I couldn't see, that tere are some with tailerons! O.k. So I should solve my problem! Regards HHS --- LeeE [EMAIL PROTECTED] schrieb: On Sunday 02 December 2007 14:48, Heiko Schulz wrote: Hi, maybe this fit more to the flightmodel-list, but I'm not sure about if this list is really be read;-) Trying to do a fdm with yasim for a Panavia Tornado GR4 IDS I noticed that it seems to me not possible to model a taileron (elevator and aileron in one control surface at the tail)- I always get the error message: Insufficient elevator to trim for approach I tried this also on the Lightning-yasim but the same error... It is really not possible? On JSBsim I noticed that the thrust reverser are not working ( as an example Fokker 70/100), but I remember that it was working with 0.9.9 and 0.9.10 - something changed or I'm too stupid? thanks Regards HHS First of all, you _need_ to include an elevator-trim binding to the hstab for YASim to solve. Have a look at the BAC-TSR2 (combined elevator aileron), YF-23 (combined elevator rudder) or SU-37 (combined FCS pitch roll). The SU-37 has a lot of additional control inputs that might be confusing but the BAC-TSR2 and YF-23 are fairly simple. YASim assumes a fixed elevator and determining it's incidence is fundamental to the way it works but it is possible to make a passable job of simulating elevons. Basically, you'll need four control inputs for the hstab element:- elevator, elevator-trim, aileron and aileron trim (remember to set the aileron and aileron-trim to split=true) YASim will then simply sum the inputs. The only thing to watch out for is that it can then output deflections of up to +-2.0 instead of limiting it to +-1.0 (it would be handy if such a limiter could be implemented). Another tip, one Andy R gave me a long time ago but one I've only recently understood the significance of, is to set the idrag for the elevators to a low value. With fixed tailplanes the drag will increase with AoA but with all-moving 'slab' tailplanes this isn't the case, so setting a low idrag value should help simulate this. So far I've only tried low idrag in the SU-37 (and I've just added it to the BAC-TSR2 that I'm currently revising) but it seems to work ok. LeeE - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim and taileron; JSBsim and thrust-reverser
On Sunday 02 December 2007 14:48, Heiko Schulz wrote: Hi, maybe this fit more to the flightmodel-list, but I'm not sure about if this list is really be read;-) Trying to do a fdm with yasim for a Panavia Tornado GR4 IDS I noticed that it seems to me not possible to model a taileron (elevator and aileron in one control surface at the tail)- I always get the error message: Insufficient elevator to trim for approach I tried this also on the Lightning-yasim but the same error... It is really not possible? On JSBsim I noticed that the thrust reverser are not working ( as an example Fokker 70/100), but I remember that it was working with 0.9.9 and 0.9.10 - something changed or I'm too stupid? thanks Regards HHS First of all, you _need_ to include an elevator-trim binding to the hstab for YASim to solve. Have a look at the BAC-TSR2 (combined elevator aileron), YF-23 (combined elevator rudder) or SU-37 (combined FCS pitch roll). The SU-37 has a lot of additional control inputs that might be confusing but the BAC-TSR2 and YF-23 are fairly simple. YASim assumes a fixed elevator and determining it's incidence is fundamental to the way it works but it is possible to make a passable job of simulating elevons. Basically, you'll need four control inputs for the hstab element:- elevator, elevator-trim, aileron and aileron trim (remember to set the aileron and aileron-trim to split=true) YASim will then simply sum the inputs. The only thing to watch out for is that it can then output deflections of up to +-2.0 instead of limiting it to +-1.0 (it would be handy if such a limiter could be implemented). Another tip, one Andy R gave me a long time ago but one I've only recently understood the significance of, is to set the idrag for the elevators to a low value. With fixed tailplanes the drag will increase with AoA but with all-moving 'slab' tailplanes this isn't the case, so setting a low idrag value should help simulate this. So far I've only tried low idrag in the SU-37 (and I've just added it to the BAC-TSR2 that I'm currently revising) but it seems to work ok. LeeE - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Removing warp delta and speed up key assignments
Hi All,
Now that we have an updated time-of-day dialog that allows you to control
the warp delta and simulation rate from the GUI, I think we should remove
the key assignments that were previously used for these functions, namely
t/T and a/A.
Two reasons:
1) They currently cause confusion for new (and not so new) users (who
turned off the lights, Woah, my plane is suddenly going very fast...
splat).
2) We can use the freed up keys for something more useful as part of the
keyboard re-org.
The patch below removes the bindings.
David M - your coordinating the keyboard re-org. Assuming there is no
objection, would you commit it please?
-Stuart
Index: keyboard.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/keyboard.xml,v
retrieving revision 1.103
diff -u -r1.103 keyboard.xml
--- keyboard.xml26 Nov 2007 17:55:28 - 1.103
+++ keyboard.xml2 Dec 2007 17:09:00 -
@@ -584,17 +584,6 @@
/binding
/key
- key n=65
- nameA/name
- descDecrease speed-up./desc
- binding
- commandproperty-adjust/command
- property/sim/speed-up/property
- min1/min
- step type=double-1/step
- /binding
- /key
-
key n=66
nameB/name
descToggle parking brake on or off/desc
@@ -695,16 +684,6 @@
/binding
/key
- key n=84
- nameT/name
- descDecrease warp delta./desc
- binding
- commandproperty-adjust/command
- property/sim/time/warp-delta/property
- step type=int-30/step
- /binding
- /key
-
key n=86
nameV/name
descScroll in reverse through views./desc
@@ -773,17 +752,6 @@
/mod-up
/key
- key n=97
- namea/name
- descIncrease speed-up./desc
- binding
- commandproperty-adjust/command
- property/sim/speed-up/property
- min1/min
- step type=double1/step
- /binding
- /key
-
key n=98
nameb/name
descApply all brakes./desc
@@ -951,34 +919,6 @@
/script
/nasal
- key n=116
- namet/name
- descIncrease warp delta./desc
- binding
- commandproperty-adjust/command
- property/sim/time/warp-delta/property
- step type=int30/step
- /binding
- binding
- commandnasal/command
- script
-(func(x) {
-settimer(func {
-x == t_id or return;
-gui.popupTip(resetting warp);
-setprop(/sim/time/warp-delta, 0);
-}, 1, 1)
-})(t_id += 1)
- /script
- /binding
- mod-up
- binding
-commandnasal/command
-scriptt_id += 1/script
- /binding
- /mod-up
- /key
-
key n=118
namev/name
descScroll through views./desc
__
Sent from Yahoo! - the World's favourite mail http://uk.mail.yahoo.com
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] local key bindings ... Meta Super
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Melchior FRANZ wrote: Here's my Crazy Idea Of The Day: The question was asked a few times, whether there are keys reserved for local customization purposes. There are none. But we have some completely unused shift levels. The X window system supports 8 modifiers (usually called shift, ctrl, alt, capslock, meta, super, hyper, and-another-one). All of them can be combined. You can have Super-Meta-Ctrl-Shift-Alt-q. But this isn't only hard to type in for those with only 10 fingers, it's also not supported everywhere (MS Windows?). What we could do, though, is to invent a new modifier level for local use. One that works everywhere. By just redefining a key that is bigger than the others and easy to hit, just like the other modifiers ... umm ... except alt, altgr) Tadaaa: The TAB modifier! :-) With the attached simple script the TAB key becomes a modifier that shifts all key codes up by adding 1000 to them. So, if you press TAB-a, you get the key n=1098 definition triggered. This works also in combination with regular modifiers Shift-Tab-a, etc. (Except that Shit-Tab-a only triggers the mod-shift part of A, not A itself. Could easily be changed, but that's left as an exercise to the student.) A lot of keyboards have problems registering more than x keys (however Alt, shift and such normally work anyway). For example left arrow key, space and ctrl doesn't work together on my keyboard. I got no idea of if tab got any problems but it is worth thinking about if you add modifier keys that are not normally modifiers. Another thing, a few aircrafts use tab iirc. They will need to be updated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHUvJPWmK6ng/aMNkRCo1NAJ9EdNXybxoVrx24Yw/SjcC+AfP7qgCeNsap UKzr9v+vs7EP8nvx8imKjC4= =E3Qt -END PGP SIGNATURE- - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
Turns out that JSBSim and YASim already has what I'm looking for. My question then is reduced to: why doesn't more FDM modellers use these features of JSBSim and YASim to create cotrol surfaces that seem to have mass? Roy Vegard Ovesen Roy: Possibly, it is because many of the aircraft flight models were written before the specific capabilities became available. There are two flight control components provided by JSBSim which could be added into the control path for a JSBSim aircraft to affect movement of an aerosurface: a kinematic control and an actuator control. The kinematic control is more for flaps. The more recent actuator control provides rate and position limiting, hysteresis, and deadband, among other things. My suspicion is that an actuator would be a very good thing to have in there and the right thing to do. Also, a filter could be added. It is generally not a good idea to alter the inputs to the FDM (joystick and/or keyboard inputs) prior to the FDM getting ahold of the signal. From my point of view, when the simulation creates an artificial condition (such as a reset of some kind, or a skew, or trimming) which is driven by the simulator, then signals to the FDM (i.e. control inputs) can be processed, perhaps to prevent undesirable dynamics. But, for natural and actual inputs, the FDM control system should handle that. I'm unclear as to whether the situation you are referring to is natural or simulation-induced. For more information about the JSBSim actuator and kinematic control components, see: http://jsbsim.sourceforge.net/wiki/index.php/User%27s_Manual#Flight_Control_ Section You will have to scroll down a ways. Jon - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim and taileron; JSBsim and thrust-reverser
FlightGear CVS from 11/24/2007 win32-built plib --- Jon S. Berndt [EMAIL PROTECTED] schrieb: On JSBsim I noticed that the thrust reverser are not working ( as an example Fokker 70/100), but I remember that it was working with 0.9.9 and 0.9.10 - something changed or I'm too stupid? thanks Regards HHS I thought we fixed that. Maybe you have an old configuration or software? Jon - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ Ihr erstes Baby? Holen Sie sich Tipps von anderen Eltern. www.yahoo.de/clever - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
Maik Sent: 02 December 2007 13:49 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] RFC: Control surface position damping Hi Roy, Roy Vegard Ovesen schrieb am 02.12.2007 14:13: When prssing the 5 key on the numeric keypad to reset the controls to zero, the control surfaces instantly move to their origin. Similar effects can also happen when an autopilot controller is activated, and when a noisy joystick is interfering with an autopilot controller. I think moving a control surface, like for example the rudder, from full left deflection to rull right deflection in an instant is unrealistic. To make this more realistic I think we should put in a low pass filter somewhere in the chain from crontrol device to FDM. My first thought would be to do the filtering just befir handing the value over to the FDM. Does anyone on the list have comments on this? With YASim you can limit the speed of any control surface, mostly used for flaps. I use it for all control surfaces where appropriate to simulate servo response time. I would not like key 5 to muck about with this in some pre-cooked and inappropriate way. Key 5 should be just centre the controls - that and no more. If individual aircraft designers want to modulate it in some way, that's down to them. This is a bad idea. Vivian - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim and taileron; JSBsim and thrust-reverser
On JSBsim I noticed that the thrust reverser are not working ( as an example Fokker 70/100), but I remember that it was working with 0.9.9 and 0.9.10 - something changed or I'm too stupid? thanks Regards HHS I thought we fixed that. Maybe you have an old configuration or software? Jon - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On Sun, 2 Dec 2007 14:13:49 +0100 Roy Vegard Ovesen [EMAIL PROTECTED] wrote: When prssing the 5 key on the numeric keypad to reset the controls to zero, the control surfaces instantly move to their origin. Similar effects can also happen when an autopilot controller is activated, and when a noisy joystick is interfering with an autopilot controller. I think moving a control surface, like for example the rudder, from full left deflection to rull right deflection in an instant is unrealistic. To make this more realistic I think we should put in a low pass filter somewhere in the chain from crontrol device to FDM. My first thought would be to do the filtering just befir handing the value over to the FDM. Does anyone on the list have comments on this? This would really mess up helicopter tuning ... the Robinson (in real life ) is very sensitive to minute control inputs ... Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On 12/02/2007 01:14 PM, Jon S. Berndt wrote: In a C-172, for instance, ...there is a direct connection between the stick and rudder. Yup. And that's not limited to little Cessnas, either. Additional examples to illustrate the same point include: DC-9 pilots say that DC stands for Direct Cable from stick to control surfaces ... no hydraulic boost. Similarly MD-80 stands for Mechanically Driven control surfaces. Virtually all aircraft from WWII and before (including transports and bombers) had unboosted controls. The B-24 in particular was notorious for its heavy control forces. B-24 plots trained for athletic strength and endurance. The mass of the control system is not relevant to the pilot in these cases. There is no relevant damping in the control linkage, either. On 12/02/2007 01:42 PM, SydSandy wrote: the Robinson (in real life ) is very sensitive to minute control inputs Yes, that's another whole category of examples illustrating the same point. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On Sunday 02 December 2007, John Denker wrote: The problem that I am addressing is the fact that an object can not move from one position to another in an instant. Why? Simply because it's impossible, but if it can move faster than our simulator rate, then it does not matter. Or was this a rhetorical question. :-) d) slew rate limiting in the hydraulic system ??? That's something yet again, not mentioned until now. e) programmed slew rate limiting in the autopilot ??? Since very few of our users have force-feedback joysticks, there is no realistic way to model (a), (b), or (c) ... and attempting to model any of those with the suggested low-pass filter is a bad idea ... worse than no filter at all. Item (d) makes more sense; it should be modeled by the FDM on the few aircraft that actually exhibit a significant amount of this behavior. This is readily possible in JSBSim. I was not aware of this when I posted my initial RFC. Item (e) should be modeled within the autopilot. Real autopilots are sure-as-shootin slew rate limited. ... and this is readily possible in the autopilot configuration using the noise spike filter, where you can set the max rate of change. To repeat: 1) In the overwhelming majority of aircraft, Asking the FDM to low-pass filter the controls (to any significant degree) is unrealistic. 2) In the few aircraft where there is a significant limitation in the fly-by-wire system, sure, go ahead and model it. This will require a lot more than a low-pass filter. 3) As the proverb says, pilots are judged on their smoothness, not on their quickness. Smoothness is built into the pilots; it is not usually built into the hardware. -- Roy Vegard Ovesen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Positioning data from the multiplayer server
I'm wanting to access the multiplayer positioning data in a third party software. Currently, I've modified the FlightGear code to forward position messages received from the multiplayer server to my external application. It appears I'm receiving these messages fine because I can read information in the message header (like the callsign of the plane in question and the type of message being sent). However, when I try to read the position and orientation portions of the message, I can't seem to convert these numbers to something accurate. I'm emulating (verbatim) the FlightGear code that reads these messages. I suppose my question is, is there anything special I need to know about these numbers? Any special conversions I need to make or code I need to look at? Any help would be appreciated. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying/Contributing with a wheeled vehicle simulator
Ok, thanks. I've thinked a bit more about this whole idea and, since i was planning to code Motorsport as a library instead of as a standalon executable, maybe Motorsport can be used from FlightGear, instead of being coded inside it. It looks like FG already uses several different physics engines depending on the planes (am i right?), so it would be a matter of adding another one for land vehicles. How does that sound? On 12/1/07, Detlef Faber [EMAIL PROTECTED] wrote: Am Samstag, den 01.12.2007, 18:39 +0100 schrieb STenyaK (Bruno Gonzalez): I'm unable to find the Jeep or any other car that were mentioned.. haven't searched much though. Try this: http://sol2500.net/flightgear/jeep.zip It should work with 0.9.10, but you will not have different ground properties like the FlightGear CVS version has. Quick question: by ground reactions you mean collision detection and response? Are there no plane-to-plane collisions currently, only basic plane-to-ground? And is the ground a generic trimesh or a heightmap? On 12/1/07, Jon S. Berndt [EMAIL PROTECTED] wrote: GWMobile wrote: Just to help you. X-plane simulates springs and tires and has an open interface. People have built cars for x-plane. The roads suck though. I think it would be great if fgear did this too. Ground reactions have been a hot topic for a while. It sounds like Andy has got something really nice for YASim, and I hope to get time to look at that code at some point very soon. Obviously, people look at simulations differently, and there are a lot of sims out there that serve different purposes. To the dismay of some here, we haven't paid so much attention to ground reactions with JSBSim. First and foremost is because I don't have the time I once did. Second, it's because my own focus is more on the GNC aspects, and overall sim architecture, as well as other things. At some point, I hope to revisit the ground reactions code. Jon - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Saludos, Bruno González ___ Msn/Jabber: stenyak AT gmail.com ICQ: 153709484 http://www.stenyak.com - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: Re: [Flightgear-users] Seneca II - couple of user comments]
I am forwarding an exchange from today's users list to the developers list because it raises a significant difference between jsbsim and yasim. These fdms treat turbulence very differently and jsbsim has a very exaggerated adverse-aileron yaw that makes this difference fatal for autopilot ILS approaches even in light turbulence. Original Message Subject:Re: [Flightgear-users] Seneca II - couple of user comments Date: Sun, 02 Dec 2007 19:10:05 -0700 From: dave perry [EMAIL PROTECTED] Reply-To: FlightGear user discussions [EMAIL PROTECTED] To: FlightGear user discussions [EMAIL PROTECTED] References: [EMAIL PROTECTED] Laurence Vanek wrote: For my money, the Seneca is one of the best done aircraft in FG. Have been flying it a good deal of late. Agreed! snip [2] On localizer during an ILS approach the A/P seems unstable (increasing roll oscillations) when within ~1 mile of approach end of runway. Perhaps this requires tweak of A/P controller constants. On a CAT II or III approach one would still not be able to see the runway at that distance. I usually disable the A/P at DH point. I have commented before about the difference between yasim and jsbsim when it comes to two autopilot issues. 1. jsbsim becomes almost uncontrolable with turbulence. Even at 0.1 or certainly at 0.2 turbulence, the c172p will not complete an approach with the kap140. So, make sure you have turbulence at 0. 2. I spent many many hours tweaking the SenecaII autopilot config file. Since jsbsim (in my opinion) has a very exagerated adverse aileron yaw response and most autopilots have aileron but not rudder roll outputs, this creates the oscillations. That is why I put in the menu options for the SenecaII a yaw-damper that may help some. It is a controller that applies rudder to try and keep the ball centered. To see the fdm difference, fly the Senecal II and then the pa24-250 (which has the same autopilot nasal file and very similar autopilot config file) down the same ILS. The pa24-250 with the Century III autopilot will be rock solid all the way to the runway center line even with light to moderate turbulence. The pa24 uses yasim. You can see the same comparison between the jsbsim c172p and the yasim pa28-161 which both have the kap140. snip Does anyone know of a jsbsim model with autopilot that will fly an ILS with no oscillation with even very light turbulence? -Dave Perry - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flightgear-users - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: Re: [Flightgear-users] Seneca II - couple of user comments]
I can't answer this at length at the moment, but a couple of months ago I turned off JSBSim turbulence completely because I had some questions about it myself. If you get the FGAtmosphere.cpp file from JSBSim CVS, that should include the newly turned off turbulence. I hope to revisit that in the near future. I have assembled some reference documents to review as time permits. Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dave perry Sent: Sunday, December 02, 2007 9:45 PM To: FlightGear developers discussions Subject: [Flightgear-devel] [Fwd: Re: [Flightgear-users] Seneca II - couple of user comments] I am forwarding an exchange from today's users list to the developers list because it raises a significant difference between jsbsim and yasim. These fdms treat turbulence very differently and jsbsim has a very exaggerated adverse-aileron yaw that makes this difference fatal for autopilot ILS approaches even in light turbulence. Original Message Subject: Re: [Flightgear-users] Seneca II - couple of user comments Date: Sun, 02 Dec 2007 19:10:05 -0700 From: dave perry [EMAIL PROTECTED] Reply-To: FlightGear user discussions [EMAIL PROTECTED] To: FlightGear user discussions flightgear- [EMAIL PROTECTED] References: [EMAIL PROTECTED] Laurence Vanek wrote: For my money, the Seneca is one of the best done aircraft in FG. Have been flying it a good deal of late. Agreed! snip [2] On localizer during an ILS approach the A/P seems unstable (increasing roll oscillations) when within ~1 mile of approach end of runway. Perhaps this requires tweak of A/P controller constants. On a CAT II or III approach one would still not be able to see the runway at that distance. I usually disable the A/P at DH point. I have commented before about the difference between yasim and jsbsim when it comes to two autopilot issues. 1. jsbsim becomes almost uncontrolable with turbulence. Even at 0.1 or certainly at 0.2 turbulence, the c172p will not complete an approach with the kap140. So, make sure you have turbulence at 0. 2. I spent many many hours tweaking the SenecaII autopilot config file. Since jsbsim (in my opinion) has a very exagerated adverse aileron yaw response and most autopilots have aileron but not rudder roll outputs, this creates the oscillations. That is why I put in the menu options for the SenecaII a yaw-damper that may help some. It is a controller that applies rudder to try and keep the ball centered. To see the fdm difference, fly the Senecal II and then the pa24-250 (which has the same autopilot nasal file and very similar autopilot config file) down the same ILS. The pa24-250 with the Century III autopilot will be rock solid all the way to the runway center line even with light to moderate turbulence. The pa24 uses yasim. You can see the same comparison between the jsbsim c172p and the yasim pa28-161 which both have the kap140. snip Does anyone know of a jsbsim model with autopilot that will fly an ILS with no oscillation with even very light turbulence? -Dave Perry --- -- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flightgear-users --- -- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
