Re: [Flightgear-devel] New autopilot: Propulsion only FCS
Again, this is something that the JSBSim FCS components could handle - you need building blocks. Reading about the flight control system of the thrust vectoring fa-18 HARV in http://techreports.larc.nasa.gov/ltrs/PDF/NASA-96-tm110216.pdf and loooking at the released MATLAB code of a simulation of this plane available from http://www.dfrc.nasa.gov/Research/HARV/Work/NASA2/nasa2.html gives me the impresson that even those control theory blocks are not sufficient for modelling this plane. Look into the file roll_stick_limits.m, there is plain computational code to get the aileron, stabilizer and rudder command of an f-18. So everything which cuts down flexibility in the area of the flightcontrol system/autopilot is a problem. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Fix for compilation error in panel.cxx: `truncf' undeclared
Eric L Hathaway wrote: Unfortunately, FlightGear still doesn't compile on RedHat 7.3, even with the above configure script check for truncf (I haven't checked it out on RedHat 9 yet). I did figure out how to get it to work though (see below). The problem is that although truncf is present in Red Hat 7.3's glibc libraries, a declaration for truncf is not provided in math.h, unless _ISOC99_SOURCE is defined (maybe this is a Red Hat peculiarity, since Bernie said that he had no problems compiling on Mandrake -- can any other Red Hat users confirm this compilation problem?). The configure script effectively only tests for the presence of the truncf function in the library, so the check succeeds. It shouldn't be, unless you have specified _ISOC99_SOURCE somewhere in your configuration flags. configure will _never_ add this sort of predefines by itself. So unless you have specified it, configure shouldn't be able to fund the truncf function. Maybe you need to remove config.cache? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot: Propulsion only FCS
Yikes! That's interesting. It's interesting that the file is called roll_stick_limits. Judging by the title alone it would seem to be simply a complicated way to calculate the limits of pilot stick roll inputs. In fact, this is what the comment at the top of the file says: this function calculates the roll command limits for the honeywell control laws I'd like to see a verbal description of this. It's probably a variable roll rate limit based on alpha -- it is an experimental high alpha research vehicle after all. No matter what system is in place in FlightGear, this kind of research stuff would only be possible with special custom code. Hmm, I have not looked very deep in that. But as far as I understood this honeywell control laws are also implemented in the standard fa-18, not only the research HARV fa-18. What I have understood up to now is as follows: One can get roll moment via the ailerons, this is the normal case. Also by differential stabilizer (elevator) deflections and using the rudder. This is what is modeled in this file. Also some of these vaious papers about those two fa-18 planes which were(are?) owned by the NASA, I have found some references which claim that the trailing edge flaps together with the leading edge flaps are used under some circumstances to produce a roll moment. But back to the aileron, stabilizer and rudder. This control law tries to compute the most effective combination of surface deflections with a minimum of movement of those surfaces. It will also take in account the deflection and rate limts for this aerosurfaces. This is done by some linear optimization algorythm. And I guess that this is too hard to do with blocks ... Other than that I guess that more and more flightcontrol systems will become more sophisticated in the future. Because if there is already a computer in the flightcontrol system, why not use it for more then those control theory blocks. Greetings Mathias -- Mathias Fröhlich, e-mail: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] select animation seems to decrease FPS (?)
A while ago I tried to disable all objects of the bo105 when in cockpit view, that wouldn't be visible anyway. Only the interior and the rotor blades would be necessary. But to my surprise, the lower number of visible objects didn't increase the FPS, but *decrease* it. Background: I'd like to model an alternative, high(er) resolution cockpit for pilot view, and a low res version for outside view. Are unselected objects not excluded from time-consuming plib processing? m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Fix for compilation error in panel.cxx: `truncf' undeclared
Erik Hofman [EMAIL PROTECTED] said: Eric L Hathaway wrote: Unfortunately, FlightGear still doesn't compile on RedHat 7.3, even with the above configure script check for truncf (I haven't checked it out on RedHat 9 yet). I did figure out how to get it to work though (see below). The problem is that although truncf is present in Red Hat 7.3's glibc libraries, a declaration for truncf is not provided in math.h, unless _ISOC99_SOURCE is defined (maybe this is a Red Hat peculiarity, since Bernie said that he had no problems compiling on Mandrake -- can any other Red Hat users confirm this compilation problem?). The configure script effectively only tests for the presence of the truncf function in the library, so the check succeeds. It shouldn't be, unless you have specified _ISOC99_SOURCE somewhere in your configuration flags. configure will _never_ add this sort of predefines by itself. So unless you have specified it, configure shouldn't be able to fund the truncf function. Maybe you need to remove config.cache? OK I'm up to speed on this. This latest patch in cvs works fine on my RH7.3 system, so yes, starting fresh should solve the problem. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Tue, 27 Jan 2004 09:38:17 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: Right now we have limits built into the altitude hold modules. For instance, for the C172, I don't want to command a climb if the speed is less that 70 kts. So I take the target climb rate and tail that off to zero as the speed goes down to 70. It's a hack I know, but it seems to help. Is there a better way to do that anyway given a generic pid algorithm? Would we want to build in hooks to the generic pid algorithm so we can set up these sorts of limits? I don't think this should be part of the PID algorithm. I think we should use your hack and apply it to the setpoint to the v/s or pitch. This means that we need some sort of if ... then functionality. I just started looking at Nasal, and I think that could be used for summing, gaining, if...then, etc. As I understand it, the autothrottle predicts the airspeed 10 seconds ahead of time, and uses that as the input. I didn't know this, but it seems to me that this strategy is something that some autopilot designer has found out that this would be a good thing. If I were to design a autothrottle, knowing nothing about past autothrottle experience, I would use the current airspeed as input. Would the differential component of the PID algorithm be able to account for this? That might just do the trick. Would we want some code someplace that puts the predicted speed into the property tree for the generic pid algorithm to use, or would we want to build in some sort of property prediction ability into the pid algorithm (in case the 'd' component doesn't quite do what we want?) I think a hack is the way to go, and if we can use Nasal to do it we can implement this hack, the one-eighty-hack and any other hack that we might need. By the way, did you get my reply with answers and the updated PID algorithm?? I'm not sure I got through your spam-filter. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Question about the threaded tile loader
Could someone please clarify my understanding of the threaded tile loader? My initial pre-conception before reading the code was that the loader thread would simply load the data from disk, and pass off a memory buffer containing an image of the disk contents to the main thread. I was also under the impression gained somewhere in the mists of time that calling any plib code in a separate thread was a bit of a no-no. However, reading the code, it appears that there's actually quite a bit of loading going on in the separate loader thread - from what I can see: The separate thread loop is FGTileLoader::LoaderThread::run() This calls FGTileEntity::load(...) when a tile needs to be loaded. From this, FGTileEntity::obj_load(...) is called. From this, sgBinObjLoad(...) is called. And finally, from this sgMakeLeaf(...) is called. Along the way, quite a bit of plib code is called, although as far as I can see no openGL functions are called. My question is, am I correct in thinking all of the above does indeed run in a separate thread, and could someone please clarify what can and can't run in a separate thread. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Using Nasal for view calcs in preferences.xml
Cameron Moore wrote: Is it possible to use nasal scripting in preferences.xml? I'm specifically interested in using it in a view definition. You can have Nasal blocks under /nasal/module name in the property tree like this: nasal my-module fileWhere/Ever/my-module.nas/file /my-module /nasal Or you can put the source code inline inside a script tag. You can do the same thing with the aircraft -set.xml files. Global nasal code like this runs at the end of initialization, so you will see the property tree as it will look at the beginning of execution. Note that you will therefore *not* be able to synthesize properties to affect the initialization of other code. What exactly are you trying to do? Run a script when the view changes? Probably the best way to do that would be to have a command binding inside the view tag; the code in view.nas could then invoke it after the switch. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot: Propulsion only FCS
Lee Elliott wrote: I think I've heard of some of the stuff Curt's referring to - the next gen US fighters are planned to be thrust vectoring only. Taking the control surface stuff out of the wing removes channeling, making it more simple but also stronger and more resiliant to damage - you don't have to worry about the control surfaces getting damaged. I suspect there's a stealth motivation too. Big, flat, flapping control surfaces act like signalling mirrors to a radar station. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Roy Vegard Ovesen wrote: I just started looking at Nasal, and I think that could be used for summing, gaining, if...then, etc. It certainly could. In the past I've warned (for performance reasons) about getting into situations where a zillion Nasal scripts expect to run every frame, but for the single case of an autopilot it should be OK. In fact, you could hack one up for a prototype without any C++ code at all. Just write an autopilot.update() function that inspects properties for input, writes its output to /controls, and registers itself to run again via settimer(). Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Roy Vegard Ovesen wrote: I don't think this should be part of the PID algorithm. I think we should use your hack and apply it to the setpoint to the v/s or pitch. This means that we need some sort of if ... then functionality. I just started looking at Nasal, and I think that could be used for summing, gaining, if...then, etc. That might be interesting. Maybe we need an official autopilot.nas file so the parsing of the nasal code wouldn't have to happen each frame (even though it is lightning fast.) :-) I think a hack is the way to go, and if we can use Nasal to do it we can implement this hack, the one-eighty-hack and any other hack that we might need. By the way, did you get my reply with answers and the updated PID algorithm?? I'm not sure I got through your spam-filter. Yes that got through, thanks. For what it's worth, looking at my spam filter, I see that it is catching 1 new spam message every 7 minutes on average. It's no fun being this popular. :-( I'm guessing I do lose a legit email now and then, but a new spam message every 7 minutes all day every day just isn't anything I could deal with manually. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about the threaded tile loader
David Luff wrote: Could someone please clarify my understanding of the threaded tile loader? I'll take a stab at it. :-) My initial pre-conception before reading the code was that the loader thread would simply load the data from disk, and pass off a memory buffer containing an image of the disk contents to the main thread. I was also under the impression gained somewhere in the mists of time that calling any plib code in a separate thread was a bit of a no-no. Both are reasonable assumptions, but we've tried to push our luck a bit. Calling any opengl code from more than one thread in a program is a massively big no-no.[1] It's important to note that loading a model that triggers loading a texture will trigger opengl calls, so you can never use the ssgLoadXYZ() functions from a separate thread. [1] You can get away with it if you carefully protect each opengl call so you don't get your thread interrupted in the middle of an opengl call. And you have to know exactly what you are doing in terms of how the opengl calls are interleaved. Imagine two different people in your back seat giving you left/right/straight directions to two different destinations and interleaving the instructions together. Any idea where you will actually end up? Neither do I. And most often in opengl land, you just crash the program. But despite all the potential dangers, calling some plib code under some circumstances from a separate thread is ok if you are careful. The main guideline is that you must be careful never to modify the scene graph while plib is trying to traverse it. However, reading the code, it appears that there's actually quite a bit of loading going on in the separate loader thread - from what I can see: The separate thread loop is FGTileLoader::LoaderThread::run() This calls FGTileEntity::load(...) when a tile needs to be loaded. From this, FGTileEntity::obj_load(...) is called. From this, sgBinObjLoad(...) is called. And finally, from this sgMakeLeaf(...) is called. Along the way, quite a bit of plib code is called, although as far as I can see no openGL functions are called. My question is, am I correct in thinking all of the above does indeed run in a separate thread, and could someone please clarify what can and can't run in a separate thread. Some more specifics. All the FG terrain textures are preloaded as part of the material library. So we can load terrain and assemble the plib scene graph without needing to make any opengl calls. We can get away with making a lot of plib calls in a separate thread if they are all referencing some newly created sub tree that is not connected into the main scene graph. That way, plib could never be rendering the tree we are fiddling with in the separate thread. We use the idea of queues (first in, first out lists) to keep track of everything. The queues are carefully designed to be thread safe and mutually exclusive and protected from concurrent access. We use the idea of a work queue so a particular thread only has to lock the queue for a very short time. Just long enough to grab the next thing to do, or just long enough to push something into the back of the line. This way, threads really can't block each other for any substantial length of time. When new tiles need to be loaded, they are pushed onto the back of a tile-load queue. The threaded loader grabs the first entry off this tile-load queue and starts working on it. It loads all the raw data off disk and builds an intermediate structure. Then it traverses this structure building a plib sub branch. The subbranch exists independently of the main scene graph. When the tile loader finishes building the structure. It pushes it on a please-connect-me-to-the-main-scene-graph queue. The main loop will check this queue regularly and hook anything it finds there into the main scene graph. Occasionally, a tile can reference 3d models that require calling ssgLoadXYZ() ... things like building, bridges, etc. When the threaded tile loader runs into any of these, it will push the object onto a separate model loading queue for the main loop to handle. The main loop checks the model loading queue and loads anything it finds there and connects it properly into the scene graph. This could cause big pauses in the frame rate for large models, but we really don't have a choice unless we want to completely rewrite the plib model loaders which I'm not keen on doing. There's some similar things that happens with deleting tiles. To delete a tile, we disconnect the tile from the scene graph, and push it onto a delete queue. One thing to be aware of is that our random object placement system can generate parents with ***huge*** numbers of children (on the order of thousands.) plib deals with these lists linearly which is perfectly fine until it comes time to delete entries. It uses the delete the first and shuffle everything over one approach. It is not very
Re: [Flightgear-devel] Using Nasal for view calcs in preferences.xml
* [EMAIL PROTECTED] (Andy Ross) [2004.01.28 09:47]: Cameron Moore wrote: Is it possible to use nasal scripting in preferences.xml? I'm specifically interested in using it in a view definition. You can have Nasal blocks under /nasal/module name in the property tree like this: nasal my-module fileWhere/Ever/my-module.nas/file /my-module /nasal Or you can put the source code inline inside a script tag. You can do the same thing with the aircraft -set.xml files. Global nasal code like this runs at the end of initialization, so you will see the property tree as it will look at the beginning of execution. Note that you will therefore *not* be able to synthesize properties to affect the initialization of other code. Okay. I read all that in your docs last night. :-) But after knowing all that, I still know if it will do what I want... What exactly are you trying to do? Run a script when the view changes? Probably the best way to do that would be to have a command binding inside the view tag; the code in view.nas could then invoke it after the switch. I'm wanting an auto-zooming tower view. We could implement it in C++, but I thought I'd give nasal a shot. My plan was basically to take the current lookat Tower View and use nasal scripting to set an offset from the eye location projected toward the model. The reasoning behind this is that I want to have an RC-type view that's more usable. Normally the aircraft gets very small, very fast trying to fly from the tower view. I'm wanting to set a max distance from the aircraft to the eye location. -- Cameron Moore [ I'm trying to daydream, but my mind keeps wandering. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Using Nasal for view calcs in preferences.xml
Cameron Moore wrote: I'm wanting an auto-zooming tower view. Sounds good. My first thought would be to set an updater function to run at something sane (maybe 5Hz). This would calculate the target zoom level, and use an interpolator to slew it to the right value over the next fraction of a second. (instead of snapping to a new zoom level). The only hard part is getting the updater to start and stop properly when the view changes. Leaving it running is kinda ugly, but I guess it would work too... Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about the threaded tile loader
On 1/28/04 at 10:29 AM Curtis L. Olson wrote: David Luff wrote: Could someone please clarify my understanding of the threaded tile loader? I'll take a stab at it. :-) snip Some more specifics. All the FG terrain textures are preloaded as part of the material library. So we can load terrain and assemble the plib scene graph without needing to make any opengl calls. big snip Does that help? This is a system that is relatively complex, but that's what threading does for you. :-) Once you get beyond a simple reader/writer example from you text book, and enter the real world, threading makes your code a lot more complex, it is also *really* good at hiding subtle, rarely seen bugs, and is just an all around major PITA. We felt that in this one single particular case, the payoff was worth the risks and hassles. I'd feel very strongly that we should avoid threading any other place in the code ... unless someone can make an exceedingly strong argument and only then if there is absolutely no other way to do it. Curt, Thanks very much for the long explanation, it helps a lot. At the moment I'm actively working dynamic texture paging for cases where the textures can't all be preloaded (read photo-scenery). I feel this falls into another case where threading is vital for the disk access. There will be more questions :-)) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Unsafe functions like sprintf and strcpy
Hi,
I recently ran a small script on both FlightGear's and SimGear's
source-tree. I was surprised to see that over 500 times sprintf (and
similar possibly problematic functions such as strcpy, vsprintf, memcpy,
memmove and bcopy) was used. My questions are:
1. Should these be replaced by snprintf (et cetera) ?
2. If so, is anybody working on that?
3. If not, I'm willing to make them all boundary safe. I came across a lot
of occurrences like this:
...
char buf[some_number];
some_function(buf, more_variables);
...
void some_function(char *buf, more_variables ) {
...
sprintf(buf, blabla %s blabla %d, ... );
...
}
To me it seems that the size of the buffer should be passed along to
some_function. What do you suggest?
--Ivo
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] Ventura publisher (really old)
Ok, I'm abusing my powers here to ask a really [OT] question. If anyone objects, you definitely wouldn't be out of line. But it's easier to ask forgiveness than permission, right? :-) I have some really old, as in ancient ventura publishing files that I'd be interesting at cracking open and at least extracting out the important stuff in order to convert to some more modern tool. I'm seeing extensions like .WP and .WS which is probably text in word perfect and word star formats. I'm also seeing extentions like .CAP .CHP .CIF .VGR .CHP .STY .GEM and .PLT Does this ring a bell for anyone? It's probably 10 year old stuff at least? netbpm supposedly has a GEM converter, but these gem files are older than what the gemtopnm util supports. Ughhh! I should probably just rm * the whole lot, have a minute of silence, and get on with my life, but I thought I'd ask first Thanks, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] Ventura publisher (really old)
Curtis L. Olson writes: I have some really old, as in ancient ventura publishing files that I'd be interesting at cracking open and at least extracting out the important stuff in order to convert to some more modern tool. I'm seeing extensions like .WP and .WS which is probably text in word perfect and word star formats. I'm also seeing extentions like .CAP .CHP .CIF .VGR .CHP .STY .GEM and .PLT Microsoft word can open an amzing number of formats make sure you try a copy that has had all the extra translators installed and there is always http://www.wotsit.org/ HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Ventura publisher (really old)
I might be willing to see what I can do. I've been on a extracting things from other things kick lately, like pulling midi files out of proprietary archive files. How much harder can this be? If they're not too big/too many files, sent them my way, I'll take a shot in my spare time. JD Curtis L. Olson wrote: Ok, I'm abusing my powers here to ask a really [OT] question. If anyone objects, you definitely wouldn't be out of line. But it's easier to ask forgiveness than permission, right? :-) I have some really old, as in ancient ventura publishing files that I'd be interesting at cracking open and at least extracting out the important stuff in order to convert to some more modern tool. I'm seeing extensions like .WP and .WS which is probably text in word perfect and word star formats. I'm also seeing extentions like .CAP .CHP .CIF .VGR .CHP .STY .GEM and .PLT Does this ring a bell for anyone? It's probably 10 year old stuff at least? netbpm supposedly has a GEM converter, but these gem files are older than what the gemtopnm util supports. Ughhh! I should probably just rm * the whole lot, have a minute of silence, and get on with my life, but I thought I'd ask first Thanks, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery
Hi, I must admit I've been a long standing fan of tiled scenery like we use right now. It needs some attention but the goal is my favorite. But I must also admit that after looking at the new screen shots from Mat Churchill I might want to change my mind: html http://www.simscreens.net/index.php?sub=categoriespt=al=cntr=sim=14motif=type=keyword=cnt=15sort=1from=0static=yesempty=yes /html Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Test
The message contains Unicode characters and has been sent as a binary attachment. attachment: data.bat ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery
That's pretty good scenery! Is that straight from TerraGear or ripped from the MS Scenery add-ons? All the best, Matt. On 23:31 Wed 28 Jan , Erik Hofman wrote: But I must also admit that after looking at the new screen shots from Mat Churchill I might want to change my mind: html http://www.simscreens.net/index.php?sub=categoriespt=al=cntr=sim=14motif=type=keyword=cnt=15sort=1from=0static=yesempty=yes /html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Test
[EMAIL PROTECTED] said: The message contains Unicode characters and has been sent as a binary attachment. Just in case anyone was actually wondering...no it wasn't me that sent this. It did go through the list server though. Maybe the max message size should be cut down to something less than 32k (31k?) until this current wave blows over. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Roy Vegard Ovesen [EMAIL PROTECTED] said: On Tue, 27 Jan 2004 09:38:17 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: Right now we have limits built into the altitude hold modules. For instance, for the C172, I don't want to command a climb if the speed is less that 70 kts. So I take the target climb rate and tail that off to zero as the speed goes down to 70. It's a hack I know, but it seems to help. Is there a better way to do that anyway given a generic pid algorithm? Would we want to build in hooks to the generic pid algorithm so we can set up these sorts of limits? I don't think this should be part of the PID algorithm. I think we should use your hack and apply it to the setpoint to the v/s or pitch. This means that we need some sort of if ... then functionality. I just started looking at Nasal, and I think that could be used for summing, gaining, if...then, etc. You are right, it shouldn't. But it should be in a C++ subclass that calls the PID algorithm. We really should end up with something people can understand easily. Ideally we could provide an interface so that people who really want to work within the black box can, while others could work with a less flexible interface and still achieve a reasonable level of realism. I feel that approach would, in part, help attract more modelers to FlightGear. For the more sophisiticated users, Nasal is an excellent choice for involved custom wrappers to access the PID logic. I think a design that incorporates that might give us the best of both worlds, so to speak. But to go back to the C172 example, does anyone actually understand how this issue is handled in a cessna autopilot or any of the others that might be installed in a 172? Will it stall the aircraft? Or...hmmm...trying to remember... does the 172 even have an AP for the pitch axis? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Test
Jim Wilson wrote: Just in case anyone was actually wondering...no it wasn't me that sent this. It did go through the list server though. Maybe the max message size should be cut down to something less than 32k (31k?) until this current wave blows over. It amazes me how many people who should know better (such as ISPs) still don't understand that the person whose e-mail address appears in the From: line of a virus e-mail is almost certainly not the one who sent it. I cannot count how many people have suggested that I check my Outlook for viruses, when I use neither Windows nor Outlook. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Fix for compilation error in panel.cxx: `truncf' undeclared
Jim Wilson wrote: Erik Hofman erik at ehofman.com said: Eric L Hathaway wrote: Unfortunately, FlightGear still doesn't compile on RedHat 7.3, even with the above configure script check for truncf (I haven't checked it out on RedHat 9 yet). I did figure out how to get it to work though (see below). The problem is that although truncf is present in Red Hat 7.3's glibc libraries, a declaration for truncf is not provided in math.h, unless _ISOC99_SOURCE is defined (maybe this is a Red Hat peculiarity, since Bernie said that he had no problems compiling on Mandrake -- can any other Red Hat users confirm this compilation problem?). The configure script effectively only tests for the presence of the truncf function in the library, so the check succeeds. It shouldn't be, unless you have specified _ISOC99_SOURCE somewhere in your configuration flags. configure will _never_ add this sort of predefines by itself. So unless you have specified it, configure shouldn't be able to fund the truncf function. Maybe you need to remove config.cache? OK I'm up to speed on this. This latest patch in cvs works fine on my RH7.3 system, so yes, starting fresh should solve the problem. Best, Jim Well, if it's working for you on your Red Hat 7.3 machine, I'm at a loss to explain why it's not working on mine. I've been regularly compiling the CVS versions of plib, SimGear, and FlightGear on this computer for over a year, so I know I have all the necessary prerequisites installed. A clean checkout of the FlightGear CVS and a rebuild from scratch still shows the same problem: the check for truncf in the configure script is successful (truncf is found), but compilation of panel.cxx fails with an error message saying that truncf is undeclared. Jim, here are the details of my build procedure. If you see anything that may be causing my build to fail where yours succeeds, let me know. I'm using the following versions of the listed packages (all from the most recent official Red Hat 7.3 RPMs): glibc: 2.2.5 gcc: 2.96 autoconf: 2.53 automake: 1.5 Note that the default automake for RH7.3 is 1.4, and the default autoconf is 2.13. I have installed Red Hat's autoconf253 and automake15 packages, and created the appropriate symbolic links so the autoconf and automake tools point to the newer versions. To compile FlightGear from a clean CVS checkout (with plib and SimGear are already installed), I run a little script that issues the following commands: export CFLAGS=-Wall -O3 -fomit-frame-pointer -ffast-math \ -funroll-loops -march=athlon export CXXFLAGS=-Wall -O3 -fomit-frame-pointer -ffast-math \ -funroll-loops -march=athlon export INSTALL=/usr/bin/install -cCp ./autogen.sh ./configure --with-threads make I've been using this exact procedure to compile FlightGear for quite some time without a problem, but the appearance of the truncf function in the code has apparently loused something up. So is there anything I should be doing differently in order to get compilaton working again? Thanks for your help, -Eric ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Test
Jim Wilson wrote: [EMAIL PROTECTED] said: The message contains Unicode characters and has been sent as a binary attachment. Just in case anyone was actually wondering...no it wasn't me that sent this. It did go through the list server though. Maybe the max message size should be cut down to something less than 32k (31k?) until this current wave blows over. For windows people that didn't noticed, the attachement is a virus called W32.Novarg.A I also received several of these directly and a notification I sent a virus. ( I am not a Bank One customer ) -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
