RE: [Flightgear-devel] status of aircraft carrier
I wrote: > > > Yesterday I put together some code which outputs the Lat/Lon/Alt of > the > > > hook tip when extended. Norman Vine kindly pointed me at the SG > > conversion > > > function, so I now have output in X,Y,Z. I'm using great chunks of > > submodel > > > code, much of which is redundant in this context, so I need to tighten > > this > > > up. However, I've added the function to the Seafire as a demonstrator. > > All done: code outputs X,Y,Z of the hook tip, last iteration and current > iteration. It's transformed for roll, pitch, heading and yaw, and > compensated for compression when in contact with the ground. > > I'll send you an update for the Spitfire/Seafire code which Erik has just > put into cvs, together with the necessary source files. > > Looking forward to your scenery stuff, and also the hook-wire interaction > logic. > Mathias, I've sent you all the necessary files. Let me know if there are any problems. Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote: > Sent: 22 October 2004 06:37 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > On Donnerstag 21 Oktober 2004 09:11, Vivian Meazza wrote: > > Yesterday I put together some code which outputs the Lat/Lon/Alt of the > > hook tip when extended. Norman Vine kindly pointed me at the SG > conversion > > function, so I now have output in X,Y,Z. I'm using great chunks of > submodel > > code, much of which is redundant in this context, so I need to tighten > this > > up. However, I've added the function to the Seafire as a demonstrator. All done: code outputs X,Y,Z of the hook tip, last iteration and current iteration. It's transformed for roll, pitch, heading and yaw, and compensated for compression when in contact with the ground. I'll send you an update for the Spitfire/Seafire code which Erik has just put into cvs, together with the necessary source files. Looking forward to your scenery stuff, and also the hook-wire interaction logic. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
> -Original Message- > From: [EMAIL PROTECTED] [mailto:flightgear-devel- > [EMAIL PROTECTED] On Behalf Of Mathias Fröhlich > Sent: 22 October 2004 06:37 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > On Donnerstag 21 Oktober 2004 09:11, Vivian Meazza wrote: > > Yesterday I put together some code which outputs the Lat/Lon/Alt of the > > hook tip when extended. Norman Vine kindly pointed me at the SG > conversion > > function, so I now have output in X,Y,Z. I'm using great chunks of > submodel > > code, much of which is redundant in this context, so I need to tighten > this > > up. However, I've added the function to the Seafire as a demonstrator. > > > > I still have to adjust the hook tip for compression when it's in contact > > with the ground. I'll have a first cut of all this code ready after the > > weekend, I hope. > You, do YASim for the hunter? Yes > For the *first* *proof* *of* *concept*, you can also let the hook hang > below > ground. > That is what I actually try to do at the moment with JSBSim. > I want to have something where I can test if I can see the wires I have > now > injected in my scene. > The Aircraft I use for that is a private one with a 4-th gear at its tail. > This 4th gear has a tiny spring constant and a well defined name. A gear > named 'HOOK' interacts with a line called 'Wire'. > This is the preliminary test to find all that stuff ;) That's what is done for the hook-equipped aircraft (Hunter/Seahawk) already in the inventory > I hope to send you a version of that stuff today evening ... > I'll probably finish later today - I broke the code last night, and I can't explain either what went wrong, or how I fixed it ... The main issue now is a small explanatory text. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] status of aircraft carrier
On Donnerstag 21 Oktober 2004 09:11, Vivian Meazza wrote: > Yesterday I put together some code which outputs the Lat/Lon/Alt of the > hook tip when extended. Norman Vine kindly pointed me at the SG conversion > function, so I now have output in X,Y,Z. I'm using great chunks of submodel > code, much of which is redundant in this context, so I need to tighten this > up. However, I've added the function to the Seafire as a demonstrator. > > I still have to adjust the hook tip for compression when it's in contact > with the ground. I'll have a first cut of all this code ready after the > weekend, I hope. You, do YASim for the hunter? For the *first* *proof* *of* *concept*, you can also let the hook hang below ground. That is what I actually try to do at the moment with JSBSim. I want to have something where I can test if I can see the wires I have now injected in my scene. The Aircraft I use for that is a private one with a 4-th gear at its tail. This 4th gear has a tiny spring constant and a well defined name. A gear named 'HOOK' interacts with a line called 'Wire'. This is the preliminary test to find all that stuff ;) I hope to send you a version of that stuff today evening ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich writes: > > I cannot see a way to model the earths surface with different properties like > runnway/grass/water with load factor. Moving and rotating triangles for the > ac carriers deck, and special elements like the wires/catapults. Easiest way is to add surface property is to use the ssgBase user_data field in the leafs and then use the a modified FGHitList::get_entity() method to return the touched leaf user_data. This could just be the pointer to the ssgTexture. Probably easiest to derive a fgTexture object from ssgTexture and add a surface property field This would require adding a field to the HitList that was set to the fgHitRec used note: I believe that this will always be the same as last_hit() but I haven't tested this and adding and maintaining an extra field won't hurt performance The actual call to do this would then be something like ((fgTexture *)(myHitList->get_entity(myHitList->get_active_entity())->get_user_data()->get_surface_property(); Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote: > Sent: 21 October 2004 07:31 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > On Mittwoch 20 Oktober 2004 09:49, Vivian Meazza wrote: > > We calculated the output in geodetic terms (lat/long/alt) for submodels > so > > that they could be displayed, and it's no problem to output in x,y,z > > aircraft terms. It didn't seem to be expensive computationally. Further, > > lat/long/alt was the easiest to get at for the aircraft location. I > think > > that I'll need some help here with the necessary conversion factors. > I'll > > look into it further. > The problem is that those values are in geodetic lat/lon. The underlying > transform to an elliptical coordinate space is done in sgCartToGeod in > SimGear/simgear/math/sg_geodesy.cxx. There is also a paper about this > stuff > floating around. > But it is sufficient to know that this transform is significantly more > expensive than doing a scalar times vector. Unless I can find a way to get at the XYZ positions we're stuck with it. However, my initial impression, admittedly on a pretty powerful machine is that the computation effort is not significant. > > > Do we need ground reactions as an intrinsic part of this code? Although > I > > can see that it might represent an opportunity to improve the current > > situation. > I think so. > I cannot see a way to model the earths surface with different properties > like > runnway/grass/water with load factor. In principle you need to tell the fdm what static and dynamic coefficients of friction to apply for each type of surface - I think I've seen suitable figures around on the net. Did you mean water lying on runway/grass or the sea? Thats just another coefficient of friction. I think the hydrodynamics of floats are a whole new ballpark. We shouldn't tackle that, but we need to recognize that we now have a float plane in the inventory, so someone might like to do it some time. > Moving and rotating triangles for > the > ac carriers deck, and special elements like the wires/catapults. This is a similar problem to the position of the hook tip relative to the origin of the aircraft. We should be able to adapt the (soon to be) existing code. > Ok, this can be put into the property tree as we have a structure broken > out > into scalar values. But I guess that this provides a huge overhead for > that > stuff. If you do serious computatiions with those values you will need to > transform them back into structs/classes/whatever. > > > Good, let's go for it. > Ok, yesterday evening I did that hierarchical boundingbox stuff. It looks > very > hackish at the moment and I first need to seperate out some stuff also in > that experimental tree before I can send you what I have. I hope to get > that > done today evening ... > > I can taxi on slopes and get all surfaces/lines in an ball aroung the > aircraft. > > So If you can think about, how we can inject our preliminary wire area > into > the scenegraph, we will be some step ahead. > :) > I thought about using normal ssgLeafs for such a thing with some special > information that this is a wire area stored in the UserData field of > ssgBase. I was thinking on similar lines. Let's start with that and see how we evolve. > Really, modelling individual wires with lines is also not a big deal. > So If we could inject individual wires every 5 meters on the whole KSFO > runway > (I am not a good pilot for testing ... :) we can start with that. > > A word for testing if a wire is caught: > The hook (think of it as a line) has a position before the integration > step. > Past integration, it has a new position. The rectangle spanned by those > two > lines is the area where the hook was during that integration step. > If a wire line intersects this rectangle, we have cought that wire (when > we > assume for now and testing, that we catch every wire we touch). Yes, good, I hadn't thought that far. This should work > > I'll get on with seeing if I can provide hook position - we would be > well > > under way with that. I think this would be a worthwhile activity since > we > > seem to have most of the bits almost in place. > Yep this hook position is also something we will need. > As I told, best in (double valued) cartesian coordinates relative to the > earth's center. The only common output from the fdms that I can get hold of right now seems to be LLZ. Not to worry for now, my code will only need a small change to cope with XYZ. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote: > Sent: 21 October 2004 07:36 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > On Mittwoch 20 Oktober 2004 18:11, Vivian Meazza wrote: > > It would be easy to convert to X,Y,Z coordinates, if I knew the > equations > > (I have suitable equations for ft to degrees lat/long) or, better, I > could > > start in X,Y,Z. > Start with X/Y/Z ... > Yesterday I put together some code which outputs the Lat/Lon/Alt of the hook tip when extended. Norman Vine kindly pointed me at the SG conversion function, so I now have output in X,Y,Z. I'm using great chunks of submodel code, much of which is redundant in this context, so I need to tighten this up. However, I've added the function to the Seafire as a demonstrator. I still have to adjust the hook tip for compression when it's in contact with the ground. I'll have a first cut of all this code ready after the weekend, I hope. So far so good V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] status of aircraft carrier
On Mittwoch 20 Oktober 2004 18:11, Vivian Meazza wrote: > It would be easy to convert to X,Y,Z coordinates, if I knew the equations > (I have suitable equations for ft to degrees lat/long) or, better, I could > start in X,Y,Z. Start with X/Y/Z ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] status of aircraft carrier
On Mittwoch 20 Oktober 2004 09:49, Vivian Meazza wrote: > We calculated the output in geodetic terms (lat/long/alt) for submodels so > that they could be displayed, and it's no problem to output in x,y,z > aircraft terms. It didn't seem to be expensive computationally. Further, > lat/long/alt was the easiest to get at for the aircraft location. I think > that I'll need some help here with the necessary conversion factors. I'll > look into it further. The problem is that those values are in geodetic lat/lon. The underlying transform to an elliptical coordinate space is done in sgCartToGeod in SimGear/simgear/math/sg_geodesy.cxx. There is also a paper about this stuff floating around. But it is sufficient to know that this transform is significantly more expensive than doing a scalar times vector. > Do we need ground reactions as an intrinsic part of this code? Although I > can see that it might represent an opportunity to improve the current > situation. I think so. I cannot see a way to model the earths surface with different properties like runnway/grass/water with load factor. Moving and rotating triangles for the ac carriers deck, and special elements like the wires/catapults. Ok, this can be put into the property tree as we have a structure broken out into scalar values. But I guess that this provides a huge overhead for that stuff. If you do serious computatiions with those values you will need to transform them back into structs/classes/whatever. > Good, let's go for it. Ok, yesterday evening I did that hierarchical boundingbox stuff. It looks very hackish at the moment and I first need to seperate out some stuff also in that experimental tree before I can send you what I have. I hope to get that done today evening ... I can taxi on slopes and get all surfaces/lines in an ball aroung the aircraft. So If you can think about, how we can inject our preliminary wire area into the scenegraph, we will be some step ahead. :) I thought about using normal ssgLeafs for such a thing with some special information that this is a wire area stored in the UserData field of ssgBase. Really, modelling individual wires with lines is also not a big deal. So If we could inject individual wires every 5 meters on the whole KSFO runway (I am not a good pilot for testing ... :) we can start with that. A word for testing if a wire is caught: The hook (think of it as a line) has a position before the integration step. Past integration, it has a new position. The rectangle spanned by those two lines is the area where the hook was during that integration step. If a wire line intersects this rectangle, we have cought that wire (when we assume for now and testing, that we catch every wire we touch). > I'll get on with seeing if I can provide hook position - we would be well > under way with that. I think this would be a worthwhile activity since we > seem to have most of the bits almost in place. Yep this hook position is also something we will need. As I told, best in (double valued) cartesian coordinates relative to the earth's center. greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Norman Vine wrote: > Sent: 20 October 2004 21:36 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] status of aircraft carrier > > Vivian Meazza writes: > > > > Norman Vine > > > > > > see SimGear / simgear / math / sg_geodesy > > > void sgGeodToCart(double lat, double lon, double alt, double* xyz); > > > > > > > Not brilliant though. In the > > property tree Lat/Lon is in degrees, and altitude in ft, so that's a 2 > step > > conversion. > > Well the Property Tree is designed for users whereas > the 'C' code is primarily for developers. > > But isn't this what NASAL is for :-) > I'm doing it in C++ because I can reuse chunks of code that I wrote for submodels (not keen on re-inventing wheels), but, yes I think Nasal would be just as good for this task. I used that for quite a bit of the animation of the Seafire/Spitfire. I don't know if one would be preferred over the other: I'm happy to write code in either. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Vivian Meazza writes: > > Norman Vine > > > > see SimGear / simgear / math / sg_geodesy > > void sgGeodToCart(double lat, double lon, double alt, double* xyz); > > > > Not brilliant though. In the > property tree Lat/Lon is in degrees, and altitude in ft, so that's a 2 step > conversion. Well the Property Tree is designed for users whereas the 'C' code is primarily for developers. But isn't this what NASAL is for :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
> -Original Message- > From: [EMAIL PROTECTED] [mailto:flightgear-devel- > [EMAIL PROTECTED] On Behalf Of Norman Vine > Sent: 20 October 2004 09:32 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] status of aircraft carrier > > > > > I would like to have those positions of the arrester wires not in > lat/lon/alt > > but rather than in earth centered coordinates (cartesian coordinates: x > > towards lat/lon=0, z towards northpole). Just because we already have > all > > scenery values stored in this format. We have a scenery reference point > and > > relative to that, we have rotated vertices. > > < soapbox > > Arrestor wires and all other Model 'features' should be an XYZ offset from > the center point of the parent Model's Frame of reference > > FWIW using LLZ for anything except using user input / output is a step > back to the 'dark ages' of the pre satelite era and the advances in > Geodysey of the post Sputnik world. > > IMHO the FDMs should report in XYZ too, interestingly they all use it > instead of LLZ internally, and this XYZ is what all FGFS location code > should be based on :-) > > The list has heard me harp on this issue before and has rejected this > revolutionary idea but this archaic way of representing position > internally > in FGFS is IMO a *major* PITA in an otherwise reasonably modern > 'Round Earth' simulator. > < /soapbox > > > > With those values we can cheap compute (double valued) positions of > these > > vertices. And then transform them, just by translation and rotation, to > some > > coordinate frame required for modelling the hook, gear ... > > This holds true for any othe properly 'located' object. > That reminds me of the 2 men in a hot air balloon. Flying early one morning they got lost in the dawn mist, so the pilot turned down the burner and descended until he could see a chap on the ground. "Where are we?" he asked. "You're in a balloon", the chap replied. On hearing this, the pilot turned up the burner and ascended, saying: "good, that's sorted: we're just passing the Royal Military College of Science". The second man in the balloon was very impressed but asked: "how do you know that?" "Easy" said the pilot "it's the only place in the area where the information you get is totally accurate and totally bloody useless". Unless that is, someone can tell me how to access the X,Y,Z co-ordinates of a model, otherwise I'm going to have to do it in lat/long/alt. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Norman Vine > Sent: 20 October 2004 18:08 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] status of aircraft carrier > > Vivian Meazza writes: > > > > It would be easy to convert to X,Y,Z coordinates, if I knew the > equations > > see SimGear / simgear / math / sg_geodesy > > /** > * Convert a geodetic lat/lon/altitude to a cartesian point. > * > * @param lat (in) Latitude, in radians > * @param lon (in) Longitude, in radians > * @param alt (in) Altitude, in meters above the WGS84 ellipsoid > * @param xyz (out) Pointer to cartesian point. > */ > void sgGeodToCart(double lat, double lon, double alt, double* xyz); > Ta ever so, that's saved me hours of research. Not brilliant though. In the property tree Lat/Lon is in degrees, and altitude in ft, so that's a 2 step conversion. > > or, better, I could start in X,Y,Z. I think this is a step too far right now. Conversion will do at this stage of development. Thanks again Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Vivian Meazza writes: > > It would be easy to convert to X,Y,Z coordinates, if I knew the equations see SimGear / simgear / math / sg_geodesy /** * Convert a geodetic lat/lon/altitude to a cartesian point. * * @param lat (in) Latitude, in radians * @param lon (in) Longitude, in radians * @param alt (in) Altitude, in meters above the WGS84 ellipsoid * @param xyz (out) Pointer to cartesian point. */ void sgGeodToCart(double lat, double lon, double alt, double* xyz); > or, better, I could start in X,Y,Z. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Norman Vine wrote: > Sent: 20 October 2004 16:41 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] status of aircraft carrier > > Vivian Meazza writes: > > > > Norman Vine wrote: > > > > > > > > < soapbox > > > > > > > FWIW using LLZ for anything except using user input / output is a step > > > back to the 'dark ages' of the pre satelite era and the advances in > > > Geodysey of the post Sputnik world. > > > > > > < /soapbox > > > > > Unless that is, someone can tell me how to access the X,Y,Z co-ordinates > of > > a model, otherwise I'm going to have to do it in lat/long/alt. > > You are talking about user input / output right ? > Which can all go thru a translation unit. At the moment it goes like this, (and it's working). I take the LLZ coordinates of the aircraft, (because that's all I can get right now), and the offset (feet) of the hook bill in its lowered position. I take the roll, pitch, and azimuth of the aircraft and use them to transform the offsets. I convert the output to degrees lat and long which, together with altitude is added to the original LLZ data to find the current position of the hook in LLZ terms. It would be easy to convert to X,Y,Z coordinates, if I knew the equations (I have suitable equations for ft to degrees lat/long) or, better, I could start in X,Y,Z. > I realize that Columbus came centuries after Hipparchus and > that Sputnik was only several decades ago :-) > Hmm ... Colombus ... well us Royal Navy chaps are a mite conservative. If it was good enough for Nelson ... no point in hurrying things :-) Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Vivian Meazza writes: > > Norman Vine wrote: > > > > > < soapbox > > > > > FWIW using LLZ for anything except using user input / output is a step > > back to the 'dark ages' of the pre satelite era and the advances in > > Geodysey of the post Sputnik world. > > > > < /soapbox > > > Unless that is, someone can tell me how to access the X,Y,Z co-ordinates of > a model, otherwise I'm going to have to do it in lat/long/alt. You are talking about user input / output right ? Which can all go thru a translation unit. I realize that Columbus came centuries after Hipparchus and that Sputnik was only several decades ago :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Norman Vine wrote: > Sent: 20 October 2004 09:32 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] status of aircraft carrier > > > > > I would like to have those positions of the arrester wires not in > lat/lon/alt > > but rather than in earth centered coordinates (cartesian coordinates: x > > towards lat/lon=0, z towards northpole). Just because we already have > all > > scenery values stored in this format. We have a scenery reference point > and > > relative to that, we have rotated vertices. > > < soapbox > > Arrestor wires and all other Model 'features' should be an XYZ offset from > the center point of the parent Model's Frame of reference > > FWIW using LLZ for anything except using user input / output is a step > back to the 'dark ages' of the pre satelite era and the advances in > Geodysey of the post Sputnik world. > > IMHO the FDMs should report in XYZ too, interestingly they all use it > instead of LLZ internally, and this XYZ is what all FGFS location code > should be based on :-) > > The list has heard me harp on this issue before and has rejected this > revolutionary idea but this archaic way of representing position > internally > in FGFS is IMO a *major* PITA in an otherwise reasonably modern > 'Round Earth' simulator. > < /soapbox > > > > With those values we can cheap compute (double valued) positions of > these > > vertices. And then transform them, just by translation and rotation, to > some > > coordinate frame required for modelling the hook, gear ... > > This holds true for any othe properly 'located' object. That reminds me of the 2 men in a hot air balloon. Flying early one morning they got lost in the dawn mist, so the pilot turned down the burner and descended until he could see a chap on the ground. "Where are we?" he asked. "You're in a balloon", the chap replied. On hearing this, the pilot turned up the burner and ascended, saying: "good, that's sorted: we're just passing the Royal Military College of Science". The second man in the balloon was very impressed but asked: "how do you know that?" "Easy" said the pilot "it's the only place in the area where the information you get is totally accurate and totally bloody useless". Unless that is, someone can tell me how to access the X,Y,Z co-ordinates of a model, otherwise I'm going to have to do it in lat/long/alt. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
> > I would like to have those positions of the arrester wires not in lat/lon/alt > but rather than in earth centered coordinates (cartesian coordinates: x > towards lat/lon=0, z towards northpole). Just because we already have all > scenery values stored in this format. We have a scenery reference point and > relative to that, we have rotated vertices. < soapbox > Arrestor wires and all other Model 'features' should be an XYZ offset from the center point of the parent Model's Frame of reference FWIW using LLZ for anything except using user input / output is a step back to the 'dark ages' of the pre satelite era and the advances in Geodysey of the post Sputnik world. IMHO the FDMs should report in XYZ too, interestingly they all use it instead of LLZ internally, and this XYZ is what all FGFS location code should be based on :-) The list has heard me harp on this issue before and has rejected this revolutionary idea but this archaic way of representing position internally in FGFS is IMO a *major* PITA in an otherwise reasonably modern 'Round Earth' simulator. < /soapbox > > With those values we can cheap compute (double valued) positions of these > vertices. And then transform them, just by translation and rotation, to some > coordinate frame required for modelling the hook, gear ... This holds true for any othe properly 'located' object. Norman "Give me a place to stand and I can draw the World" ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote: > Sent: 20 October 2004 07:41 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > On Dienstag 19 Oktober 2004 21:23, Vivian Meazza wrote: > > > Hmm, > > > I am not satisfied with anything which is only working on a per frame > > > basis. > > > Just because, if so, we will have different bevour of our physical > models > > > dependent of the frammerate. > > > > I think I put this bit badly. The geodetic output would be dependent on > the > > speed of an iteration loop. If we are only modeling an arrester wire > > _surface_ it should suffice. I can generate some proof-of-principle code > > for this quite readily, I think. I'll see what I can do. > Ok, let's start now :) > I would like to have those positions of the arrester wires not in > lat/lon/alt > but rather than in earth centered coordinates (cartesian coordinates: x > towards lat/lon=0, z towards northpole). Just because we already have all > scenery values stored in this format. We have a scenery reference point > and > relative to that, we have rotated vertices. > With those values we can cheap compute (double valued) positions of these > vertices. And then transform them, just by translation and rotation, to > some > coordinate frame required for modelling the hook, gear ... We calculated the output in geodetic terms (lat/long/alt) for submodels so that they could be displayed, and it's no problem to output in x,y,z aircraft terms. It didn't seem to be expensive computationally. Further, lat/long/alt was the easiest to get at for the aircraft location. I think that I'll need some help here with the necessary conversion factors. I'll look into it further. > > If you use geodetic lat/lon, you need to transform the values to geodetic > lat/lon/alt values which is expensive as such since this requires the use > of > an iteration method. And then transform those values back to that same > flat > coordinate space suitable for comuting ground reactions. > For that backtransform, I can't think of anything not using those earth > centered corrdinates. Do we need ground reactions as an intrinsic part of this code? Although I can see that it might represent an opportunity to improve the current situation. > So all together: if lat/lon/alt is omitted in those computations, we can > get > the same effect with less computations. Yes, agreed. > What I have here in my private tree, is code to have a small, per FDM > instance, cache of ground tiles around the aircraft. With this one it is > easy > to taxi on slopes. Also if such arrester wires are stored there, it would > be > easy to compute the interactions with them. > Intersections with those few triangles can then be done often per > timestep, > since there are only few triangles in that cache. The cache itself is at > the > moment filled on demand, whenever the FDM cannot find a triangle below the > contact point, the scenegraph is queried for a new triangle. > That works for our scenery, but for that simple plane modelling the > arrester > wires, this does not work, since we find a triangle from the scenery, we > do > never query the triangles modelling the wires. > > What I plan to do here, is to build up a cache of all triangles in the > area of > an aircraft. This is easy to do with the hierarchical boundingbox > intersection routines from ssg*. > Having that cache, then implement wires as geometry nodes in the scene > graph, > which will then show up in the cache if we are near them. Intersection > with > geometry nodes in that cache can be implemented using ssg routines. > Coupling the results into a FDM is straight forward. Good > This approach with that cache would also allow to implement this stuff > together with FDM's in child processes or even different machines, like > Curt > was talking about some time ago. > > > My main conceptual difficulty is the compass alignment of the arrester > wire > > surface. If we test the hook position in geodetic terms, i.e. lat a < > hook > > pos < lat b etc. how do we account for the odd triangles at the corners? > See above ... > Use cartesian coordinates for that and then use ssg* for that. > My head includes the solutions here :) > Seriously, I have much of a concept here. So if we can work together, we > might > be faster :) Good, let's go for it. > > Good point. The probability of catching a wire given that the hook > > intersects the wire surface is ... ? Some function of hook design, > number > > of wires, aircraft velocities, ship velocities ... some pure chance ... > ? > Y
Re: [Flightgear-devel] status of aircraft carrier
On Dienstag 19 Oktober 2004 21:23, Vivian Meazza wrote: > > Hmm, > > I am not satisfied with anything which is only working on a per frame > > basis. > > Just because, if so, we will have different bevour of our physical models > > dependent of the frammerate. > > I think I put this bit badly. The geodetic output would be dependent on the > speed of an iteration loop. If we are only modeling an arrester wire > _surface_ it should suffice. I can generate some proof-of-principle code > for this quite readily, I think. I'll see what I can do. Ok, let's start now :) I would like to have those positions of the arrester wires not in lat/lon/alt but rather than in earth centered coordinates (cartesian coordinates: x towards lat/lon=0, z towards northpole). Just because we already have all scenery values stored in this format. We have a scenery reference point and relative to that, we have rotated vertices. With those values we can cheap compute (double valued) positions of these vertices. And then transform them, just by translation and rotation, to some coordinate frame required for modelling the hook, gear ... If you use geodetic lat/lon, you need to transform the values to geodetic lat/lon/alt values which is expensive as such since this requires the use of an iteration method. And then transform those values back to that same flat coordinate space suitable for comuting ground reactions. For that backtransform, I can't think of anything not using those earth centered corrdinates. So all together: if lat/lon/alt is omitted in those computations, we can get the same effect with less computations. What I have here in my private tree, is code to have a small, per FDM instance, cache of ground tiles around the aircraft. With this one it is easy to taxi on slopes. Also if such arrester wires are stored there, it would be easy to compute the interactions with them. Intersections with those few triangles can then be done often per timestep, since there are only few triangles in that cache. The cache itself is at the moment filled on demand, whenever the FDM cannot find a triangle below the contact point, the scenegraph is queried for a new triangle. That works for our scenery, but for that simple plane modelling the arrester wires, this does not work, since we find a triangle from the scenery, we do never query the triangles modelling the wires. What I plan to do here, is to build up a cache of all triangles in the area of an aircraft. This is easy to do with the hierarchical boundingbox intersection routines from ssg*. Having that cache, then implement wires as geometry nodes in the scene graph, which will then show up in the cache if we are near them. Intersection with geometry nodes in that cache can be implemented using ssg routines. Coupling the results into a FDM is straight forward. This approach with that cache would also allow to implement this stuff together with FDM's in child processes or even different machines, like Curt was talking about some time ago. > My main conceptual difficulty is the compass alignment of the arrester wire > surface. If we test the hook position in geodetic terms, i.e. lat a < hook > pos < lat b etc. how do we account for the odd triangles at the corners? See above ... Use cartesian coordinates for that and then use ssg* for that. My head includes the solutions here :) Seriously, I have much of a concept here. So if we can work together, we might be faster :) > Good point. The probability of catching a wire given that the hook > intersects the wire surface is ... ? Some function of hook design, number > of wires, aircraft velocities, ship velocities ... some pure chance ... ? Yep, this kind of stuff. But not relevant at this stage of development... With that cache it would also be easy to model individual wires. If we have them deterministically modelled, multiply with some catch propability. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote: > Sent: 18 October 2004 19:38 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > > Hi, > > On Donnerstag 14 Oktober 2004 17:59, Vivian Meazza wrote: > > Mathias Fröhlich wrote a long time ago: > ... sadly yes. > > > In the next couple of days or so I will have completed a model of a > Seafire > > IIIc. It has a functioning hook, so I was set to wondering if there was > any > > progress on the arrester wire project??? > not yet. > I have thought about many things in this area. But no code yet. > > > In the course of the work on Submodels, I realized that it should be > > possible to re-use some of that code to provide the location of the hook > on > > a near frame-by-frame basis in geodetic terms. Intersection with a 'wire > > surface' should be possible to calculate. But then we need to apply a > > suitable force to the fdm. I wonder if a mega-brake would do the > trick??? > > At least as a first try. > Hmm, > I am not satisfied with anything which is only working on a per frame > basis. > Just because, if so, we will have different bevour of our physical models > dependent of the frammerate. I think I put this bit badly. The geodetic output would be dependent on the speed of an iteration loop. If we are only modeling an arrester wire _surface_ it should suffice. I can generate some proof-of-principle code for this quite readily, I think. I'll see what I can do. My main conceptual difficulty is the compass alignment of the arrester wire surface. If we test the hook position in geodetic terms, i.e. lat a < hook pos < lat b etc. how do we account for the odd triangles at the corners? > We can just tell that this will model the randomness of catching the wire. > But > IMO I would like to be able to infulence this randomness by myself. Good point. The probability of catching a wire given that the hook intersects the wire surface is ... ? Some function of hook design, number of wires, aircraft velocities, ship velocities ... some pure chance ... ? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] status of aircraft carrier
Hi, On Donnerstag 14 Oktober 2004 17:59, Vivian Meazza wrote: > Mathias Fröhlich wrote a long time ago: ... sadly yes. > In the next couple of days or so I will have completed a model of a Seafire > IIIc. It has a functioning hook, so I was set to wondering if there was any > progress on the arrester wire project??? not yet. I have thought about many things in this area. But no code yet. > In the course of the work on Submodels, I realized that it should be > possible to re-use some of that code to provide the location of the hook on > a near frame-by-frame basis in geodetic terms. Intersection with a 'wire > surface' should be possible to calculate. But then we need to apply a > suitable force to the fdm. I wonder if a mega-brake would do the trick??? > At least as a first try. Hmm, I am not satisfied with anything which is only working on a per frame basis. Just because, if so, we will have different bevour of our physical models dependent of the frammerate. We can just tell that this will model the randomness of catching the wire. But IMO I would like to be able to infulence this randomness by myself. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote a long time ago: > Sent: 08 July 2004 10:38 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > On Mittwoch, 7. Juli 2004 21:32, Vivian Meazza wrote: > > It would be a shame if we can't model individual wires, then we could > > experience hook-skip whereby the hook can miss all the wires. A chum of > > mine went around 14 times trying to catch a wire in a Gannet aboard HMS > > Hermes. But I think the 'wire-surface' would do quite well. > Hmm, let me explain a bit. > I for myself will be happy to model the relality in detail. > That wire-surface has grown from an experience I have made during the past > half year when I wanted to push changes into JSBSim. For example, I often > proposed a mechanical system which much better models gears. This is not > hard > to do from my point of view. But Jon always told me that this stuff is > tooo > complicated and it is better to keep things as simple as possible. > So that 'wire surface' has really grown from a extrapolation of my > couterpart > in JSBSim to the flightgear community ... > > ... I am happy with individual wires. It is a bit harder since we do only > have > the position of the hook at discrete times. But I have also thought about > that: > Does the surface spaned from the hook in the prevous timestep and the hook > in > this timestep intersect a wire? > If yes we can have a propability where we catch. And if so apply two > forces > from the ends of the wire. > > So the API between the FDM and Flightgear will look something like a > function > taking a geometry of a rectangle and returning a bool which tells if a > wire > is caught and where the two points are where the wire leaves the deck. And > as > usual, how these two points move. > > > It's very difficult to manoeuvre an aircraft onto a cat. You should > > consider modelling the self-aligning rollers and chocks which bodily > shift > > the aircraft into the correct position. This need be no more than a > area > > on the deck on which, if the main wheels are resting on it, a press of a > > key will automatically correctly position the aircraft. > So with a little jump to the right :) > > Sounds sensible! > > > A key press should signify when the pilot is ready for launch, then the > cat > > should fire after a random interval after. > > > > The Jet Blast Deflectors (JBDs) could also be modelled. > Hehe :) > > And a cat officer showing you where to taxi :) > And all these guys with yellow and green and whatever jackets :) > > One by one. But yes ... > > I think I will put several hundred wires onto KSFO's runway to do the > first > tests :) > > > I can provide more details if you are interested. > Yes, whatever you fell that could be useful. > References ... > > Thanks in advance! In the next couple of days or so I will have completed a model of a Seafire IIIc. It has a functioning hook, so I was set to wondering if there was any progress on the arrester wire project??? In the course of the work on Submodels, I realized that it should be possible to re-use some of that code to provide the location of the hook on a near frame-by-frame basis in geodetic terms. Intersection with a 'wire surface' should be possible to calculate. But then we need to apply a suitable force to the fdm. I wonder if a mega-brake would do the trick??? At least as a first try. A couple of pictures are at: http://myweb.tiscali.co.uk/vmeazza/FlightGear/seafire-001.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/seafire-002.jpg Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Jon S Berndt wrote > Sent: 08 July 2004 15:09 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > > On Thu, 8 Jul 2004 14:03:14 +0100 > "Vivian Meazza" <[EMAIL PROTECTED]> wrote: > > > > > >Jon Berndt wrote > > > >> Sent: 08 July 2004 13:29 > >> To: FlightGear developers discussions > >> Subject: RE: [Flightgear-devel] status of aircraft carrier > >> > >> > >> > In my day they consisted of a pulley system forcing hydraulic > >>fluid > >> > through orifices. These orifices were adjusted to provide the > >>right > >> > decelerating force for each aircraft type. > >> > > >> > I seem to recall that a disk brake system was proposed. I > >> don't think > >> > that this was implemented in Royal Navy carriers, but may have > >>been > >> > for modern US carriers. > >> > >> An aircraft, upon landing on a carrier, does not appear to > >> slip backwards at all under the force of the arresting wire. > >> It seems like a one-way spring. > > > >A one way spring - a new concept in physics :-). Perhaps more like a > >one way damper on a car suspension. > > > >Seriously - did you mean a linear spring where the force > that stretches > >the spring is in direct proportion to the amount of stretch? > That would > >not be quite correct - the arresting force was constant in the first > >part of the > >pull-out, and I think, but can't quite remember, that the orifices > >closed > >towards the end of the pull-out to provide a soft stop. > > I thought about using a damper, too, but qualitatively that didn't > seem right, either. A spring/damper could probably be made to feel > "close enough". > Yes, close enough. In real life in mechanical terms it was more damper than spring. In mathematical terms, a spring/damper would be the way to go. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
On Thu, 8 Jul 2004 14:03:14 +0100 "Vivian Meazza" <[EMAIL PROTECTED]> wrote: Jon Berndt wrote Sent: 08 July 2004 13:29 To: FlightGear developers discussions Subject: RE: [Flightgear-devel] status of aircraft carrier > In my day they consisted of a pulley system forcing hydraulic fluid > through orifices. These orifices were adjusted to provide the right > decelerating force for each aircraft type. > > I seem to recall that a disk brake system was proposed. I don't think > that this was implemented in Royal Navy carriers, but may have been > for modern US carriers. An aircraft, upon landing on a carrier, does not appear to slip backwards at all under the force of the arresting wire. It seems like a one-way spring. A one way spring - a new concept in physics :-). Perhaps more like a one way damper on a car suspension. Seriously - did you mean a linear spring where the force that stretches the spring is in direct proportion to the amount of stretch? That would not be quite correct - the arresting force was constant in the first part of the pull-out, and I think, but can't quite remember, that the orifices closed towards the end of the pull-out to provide a soft stop. I thought about using a damper, too, but qualitatively that didn't seem right, either. A spring/damper could probably be made to feel "close enough". Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] status of aircraft carrier
There is a fairly simple, but possibly useful discussion of aircraft carrier take-offs and landings at How Stuff Works: http://people.howstuffworks.com/aircraft-carrier4.htm There are even some numbers which might be good for getting a semi-working system. It looks like each arrestor wire is attached to a pair of hydraulic damping cylinders, so both ends of the wire move, and thus the wire does not move relative to the hook (once caught). I guess that hydraulics allow the damping force to be easily varied for different aircraft. Richard. This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] status of aircraft carrier
Jon Berndt wrote > Sent: 08 July 2004 13:29 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] status of aircraft carrier > > > > In my day they consisted of a pulley system forcing hydraulic fluid > > through orifices. These orifices were adjusted to provide the right > > decelerating force for each aircraft type. > > > > I seem to recall that a disk brake system was proposed. I > don't think > > that this was implemented in Royal Navy carriers, but may have been > > for modern US carriers. > > An aircraft, upon landing on a carrier, does not appear to > slip backwards at all under the force of the arresting wire. > It seems like a one-way spring. A one way spring - a new concept in physics :-). Perhaps more like a one way damper on a car suspension. Seriously - did you mean a linear spring where the force that stretches the spring is in direct proportion to the amount of stretch? That would not be quite correct - the arresting force was constant in the first part of the pull-out, and I think, but can't quite remember, that the orifices closed towards the end of the pull-out to provide a soft stop. There was enough tension in the system just to impart a little rearward motion to the aircraft. Thus was enough to disengage the wire from the hook, which was then raised, and the aircraft was free to taxi clear. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote > Sent: 08 July 2004 10:38 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > > On Mittwoch, 7. Juli 2004 21:32, Vivian Meazza wrote: > > It would be a shame if we can't model individual wires, > then we could > > experience hook-skip whereby the hook can miss all the > wires. A chum > > of mine went around 14 times trying to catch a wire in a > Gannet aboard > > HMS Hermes. But I think the 'wire-surface' would do quite well. > Hmm, let me explain a bit. > I for myself will be happy to model the relality in detail. > That wire-surface has grown from an experience I have made > during the past > half year when I wanted to push changes into JSBSim. For > example, I often > proposed a mechanical system which much better models gears. > This is not hard > to do from my point of view. But Jon always told me that this > stuff is tooo > complicated and it is better to keep things as simple as > possible. So that 'wire surface' has really grown from a > extrapolation of my counterpart > in JSBSim to the flightgear community ... As I said, I think the 'wire surface' will do fine. KISS, at least at first. > ... I am happy with individual wires. It is a bit harder > since we do only have > the position of the hook at discrete times. But I have also > thought about > that: > Does the surface spanned from the hook in the previous time step > and the hook in > this time step intersect a wire? > If yes we can have a probability where we catch. And if so > apply two forces > from the ends of the wire. > > So the API between the FDM and Flightgear will look something > like a function > taking a geometry of a rectangle and returning a bool which > tells if a wire > is caught and where the two points are where the wire leaves > the deck. And as > usual, how these two points move. The wire slips through the hook, so I think that the action of the wire con be regarded as a decelerating force acting at the hook attachment point, along the aircraft centreline. Good enough I think. > > It's very difficult to manoeuvre an aircraft onto a cat. You should > > consider modelling the self-aligning rollers and chocks > which bodily > > shift the aircraft into the correct position. This need be no more > > than a area on the deck on which, if the main wheels are resting on > > it, a press of a key will automatically correctly position the > > aircraft. > So with a little jump to the right :) > Sounds sensible! Just like real life. > > A key press should signify when the pilot is ready for launch, then > > the cat should fire after a random interval after. > > > > The Jet Blast Deflectors (JBDs) could also be modelled. > Hehe :) > > And a cat officer showing you where to taxi :) > And all these guys with yellow and green and whatever jackets :) > > One by one. But yes ... I've seen it done in another flightsim. Back to bones? > I think I will put several hundred wires onto KSFO's runway > to do the first > tests :) Nothing like making it hard :-) > > I can provide more details if you are interested. > Yes, whatever you fell that could be useful. > References .. I'm looking in my library for some nice photos. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] status of aircraft carrier
> -Original Message- Mathias Fröhlich asked > Sent: 08 July 2004 10:12 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > > On Donnerstag, 8. Juli 2004 09:50, Vivian Meazza wrote: > > The volume of the steam reservoirs are large in comparison with the > > volume of the cat cylinder, so there is only a slight drop in steam > > pressure over the stroke. As far as simulation is > concerned, the cat > > force could be considered to remain constant over the whole of the > > stroke. > Neglecting fluid mechanical effects. > But that is most likely sufficient ... > > I am not sure, but I believe that I have read that newer cats > are driven by > magnetic fields. Something like magnetic monorail trains or > eddy current > brakes work. > Is this true? Yes, electro-magnetic cats are under development, but I'm not sure of their development status right now. > > But even this ones will produce a constant force. So this is > really the same. > > > > So for the cat we apply a suitable force at the cat > attachment point, > > and for the arrester wires at the hook attachment point, > remembering > > that there are vertical as well as horizontal components. > > > > Is that enough detail for some initial design? I can dig > around in my > > memory some more, or do some more research if you need it. > > If you have some interesting references I would be interested too! > > I have a picture in my head that at least the F14 and F18 > have a launch bar in > front of the strut and a wire behind the strut. Both together > are able to > pull the nose gear down to maximum compression, providing a > negative angle of > attack while the aircraft is pushed by the cat. Then when the cat is > decoupled the now heavy compressed nose gear spring will help > the aircraft to > fast increase the angle of attack and produce enough lift to > stay in air. I think the wire to which you refer is the holdback. Don't worry to much about the nose oleo compression - it just happens. > Are there different cats for different aircraft on the same carrier? On some carriers the cats are of different lengths: the longer ones are used for the heavier aircraft. In any case the steam pressure is adjusted to provide the appropriate acceleration for the aircraft launch weight. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] status of aircraft carrier
> In my day they consisted of a pulley system forcing hydraulic fluid through > orifices. These orifices were adjusted to provide the right decelerating > force for each aircraft type. > > I seem to recall that a disk brake system was proposed. I don't think that > this was implemented in Royal Navy carriers, but may have been for modern US > carriers. An aircraft, upon landing on a carrier, does not appear to slip backwards at all under the force of the arresting wire. It seems like a one-way spring. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote > Sent: 08 July 2004 09:58 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > > On Donnerstag, 8. Juli 2004 00:23, Andy Ross wrote: > > Unfortunately, the same trick won't work for the arrestor wires > > because their "track" isn't fixed, but based on the landing > velocity > > of the aircraft. > > How do they work on a real carrier? > > Is this a velocity dependent friction force applied to the wires? > > Is this also changed for each aircraft coming in? > > Greetings > > Mathias > In my day they consisted of a pulley system forcing hydraulic fluid through orifices. These orifices were adjusted to provide the right decelerating force for each aircraft type. I seem to recall that a disk brake system was proposed. I don't think that this was implemented in Royal Navy carriers, but may have been for modern US carriers. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] status of aircraft carrier
> It's important to remember that the FDM doesn't know a ship from Shinola. Very good. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote > > On Mittwoch, 7. Juli 2004 21:12, David Megginson wrote: > > Jon S Berndt wrote: > > > Off the top of my head (and I'm in a real hurry at this > second), I > > > think it would be nice to make it possible to supply the > FDMs with a > > > force vector and point of application - perhaps even a moment > > > vector. Is that what you are proposing? > > > > Once we support ground reactions with a moving surface > (like the deck > > of a ship), why not just model the catapult as a faster moving > > surface? > Hmm, I also think that this will provide more problems than it solves. > > I am also for a force/acceleration vector applied to the nose > gear. This is > how it works in reality. Also it is easier to just add an > additional force > then to have a surface which is used to compute a force that is then > added ... > Don't forget that we only have 2 carrier capable models right now: A4 Skyhawk and Seahawk. Both these predate the nose wheel launch system, and use strops. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
On Mittwoch, 7. Juli 2004 21:32, Vivian Meazza wrote: > It would be a shame if we can't model individual wires, then we could > experience hook-skip whereby the hook can miss all the wires. A chum of > mine went around 14 times trying to catch a wire in a Gannet aboard HMS > Hermes. But I think the 'wire-surface' would do quite well. Hmm, let me explain a bit. I for myself will be happy to model the relality in detail. That wire-surface has grown from an experience I have made during the past half year when I wanted to push changes into JSBSim. For example, I often proposed a mechanical system which much better models gears. This is not hard to do from my point of view. But Jon always told me that this stuff is tooo complicated and it is better to keep things as simple as possible. So that 'wire surface' has really grown from a extrapolation of my couterpart in JSBSim to the flightgear community ... ... I am happy with individual wires. It is a bit harder since we do only have the position of the hook at discrete times. But I have also thought about that: Does the surface spaned from the hook in the prevous timestep and the hook in this timestep intersect a wire? If yes we can have a propability where we catch. And if so apply two forces from the ends of the wire. So the API between the FDM and Flightgear will look something like a function taking a geometry of a rectangle and returning a bool which tells if a wire is caught and where the two points are where the wire leaves the deck. And as usual, how these two points move. > It's very difficult to manoeuvre an aircraft onto a cat. You should > consider modelling the self-aligning rollers and chocks which bodily shift > the aircraft into the correct position. This need be no more than a area > on the deck on which, if the main wheels are resting on it, a press of a > key will automatically correctly position the aircraft. So with a little jump to the right :) Sounds sensible! > A key press should signify when the pilot is ready for launch, then the cat > should fire after a random interval after. > > The Jet Blast Deflectors (JBDs) could also be modelled. Hehe :) And a cat officer showing you where to taxi :) And all these guys with yellow and green and whatever jackets :) One by one. But yes ... I think I will put several hundred wires onto KSFO's runway to do the first tests :) > I can provide more details if you are interested. Yes, whatever you fell that could be useful. References ... Thanks in advance! 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] status of aircraft carrier
On Donnerstag, 8. Juli 2004 09:50, Vivian Meazza wrote: > The volume of the steam reservoirs are large in comparison with the volume > of the cat cylinder, so there is only a slight drop in steam pressure over > the stroke. As far as simulation is concerned, the cat force could be > considered to remain constant over the whole of the stroke. Neglecting fluid mechanical effects. But that is most likely sufficient ... I am not sure, but I believe that I have read that newer cats are driven by magnetic fields. Something like magnetic monorail trains or eddy current brakes work. Is this true? But even this ones will produce a constant force. So this is really the same. > So for the cat we apply a suitable force at the cat attachment point, and > for the arrester wires at the hook attachment point, remembering that there > are vertical as well as horizontal components. > > Is that enough detail for some initial design? I can dig around in my > memory some more, or do some more research if you need it. If you have some interresting references I would be interrested too! I have a picture in my head that at least the F14 and F18 have a launch bar in front of the strut and a wire behind the strut. Both together are able to pull the nose gear down to maximum compression, providing a negative angle of attack while the aircraft is pushed by the cat. Then when the cat is decoupled the now heavy compressed nose gear spring will help the aircraft to fast increase the angle of attack and produce enough lift to stay in air. Are there different cats for different aircraft on the same carrier? 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] status of aircraft carrier
On Donnerstag, 8. Juli 2004 00:23, Andy Ross wrote: > Unfortunately, the same trick won't work for the arrestor wires > because their "track" isn't fixed, but based on the landing velocity > of the aircraft. How do they work on a real carrier? Is this a velocity dependent friction force applied to the wires? Is this also changed for each aircraft comming in? 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] status of aircraft carrier
On Mittwoch, 7. Juli 2004 21:12, David Megginson wrote: > Jon S Berndt wrote: > > Off the top of my head (and I'm in a real hurry at this second), I think > > it would be nice to make it possible to supply the FDMs with a force > > vector and point of application - perhaps even a moment vector. Is that > > what you are proposing? > > Once we support ground reactions with a moving surface (like the deck of a > ship), why not just model the catapult as a faster moving surface? Hmm, I also think that this will provide more problems than it solves. I am also for a force/acceleration vector applied to the nose gear. This is how it works in reality. Also it is easier to just add an additional force then to have a surface which is used to compute a force that is then added ... 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] status of aircraft carrier
Jon S Berndt wrote > On Wed, 7 Jul 2004 22:50:40 +0100 > "Vivian Meazza" <[EMAIL PROTECTED]> wrote: > > >Hmm, bolted? Don't forget that the cat force is adjusted for the > >aircraft type and launch weight. > > > >It would have to be modelled as a spring > >> force acting on the nose gear to be correct. Even that's not > >> quite good enough, since on real cat shots the gear is > >> artificially compressed to keep the nose from tipping > >> backwards during the shot. > > I thought initially that a spring was not the way to go, but I think > you are picturing a spring that (figuratively) goes from the bow of > the ship to the nose gear, no? This sounds plausible, but it depends > on how the catapult works. Does it maintain pressure along the entire > throw length of the catapult? In this case, a spring is wrong. The force applied by a steam cat is more or less constant over the cat stroke. Put simply steam pressure is applied to the back of the cat shuttle from steam reservoirs. This initial pressure is resisted by a 'holdback' attached to the back of the aircraft. When there is sufficient pressure a component in the holdback breaks, and the shuttle (and the aircraft) accelerate down the track. Near the end of the cat stroke, ports in the cat cylinder are uncovered, releasing the steam pressure. A probe on the front of the shuttle engages in a water brake and is rapidly decelerated to a stop. The aircraft overtakes the shuttle, and the cat strop falls away or the nose wheel towing arm disengages. Nothing can go wrong ... The volume of the steam reservoirs are large in comparison with the volume of the cat cylinder, so there is only a slight drop in steam pressure over the stroke. As far as simulation is concerned, the cat force could be considered to remain constant over the whole of the stroke. > >> And arrestor wires have their own complexities. They need to > >> be "tuned" to the landing aircraft weight to produce the > >> right amount of deceleration. This is a manual process on a > >> real carrier, but we'd have to fake it somehow. > >> > > > >Do we need to model that? We know the mass of the aircraft, > just apply > >a suitable decelerating force at the hook attachment point > if the hook > >engages a wire. > > Yep. > Yep, we do need to model that, or yep, we just apply a suitable decelerating force at the hook attachment point if the hook engages a wire? So for the cat we apply a suitable force at the cat attachment point, and for the arrester wires at the hook attachment point, remembering that there are vertical as well as horizontal components. Is that enough detail for some initial design? I can dig around in my memory some more, or do some more research if you need it. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
> Off the top of my head (and I'm in a real hurry at this second), I > think it would be nice to make it possible to supply the FDMs with a > force vector and point of application - perhaps even a moment vector. > Is that what you are proposing? The last time this topic came up it started out about glider towing, and then spread out into related things like: barriers, tow cables, arresting cables, drag chutes, tow bars, spin 'chutes, etc. From the FDM's point of view each of these is a force vector applied to some point on the airplane. Maybe we need a descendant of FGForce called ExternalForce, and a list of these things for each airplane (just like engines). For a catapult the ExternalForce would have an origin at the nose wheel (or thereabouts, it's up to the config writer) and would be pointed say, straight ahead. At the activation of a catapult key the force will have a certain magnitude for a certain time (much easier than for a certain distance). It's important to remember that the FDM doesn't know a ship from Shinola. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
On Wed, 7 Jul 2004 22:50:40 +0100 "Vivian Meazza" <[EMAIL PROTECTED]> wrote: Hmm, bolted? Don't forget that the cat force is adjusted for the aircraft type and launch weight. It would have to be modelled as a spring force acting on the nose gear to be correct. Even that's not quite good enough, since on real cat shots the gear is artificially compressed to keep the nose from tipping backwards during the shot. I thought initially that a spring was not the way to go, but I think you are picturing a spring that (figuratively) goes from the bow of the ship to the nose gear, no? This sounds plausible, but it depends on how the catapult works. Does it maintain pressure along the entire throw length of the catapult? In this case, a spring is wrong. And arrestor wires have their own complexities. They need to be "tuned" to the landing aircraft weight to produce the right amount of deceleration. This is a manual process on a real carrier, but we'd have to fake it somehow. Do we need to model that? We know the mass of the aircraft, just apply a suitable decelerating force at the hook attachment point if the hook engages a wire. Yep. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
Jon S. Berndt wrote: > I thought initially that a spring was not the way to go, but I think > you are picturing a spring that (figuratively) goes from the bow of > the ship to the nose gear, no? Actually, I was thinking about a spring centered on the point where the cat harness "would be" based on a known acceleration curve. This gets you around the problem of "tuning" the force appropriately for the aircraft, and you can just set a target launch speed instead. Unfortunately, the same trick won't work for the arrestor wires because their "track" isn't fixed, but based on the landing velocity of the aircraft. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] status of aircraft carrier
Andy Ross wrote > David Megginson wrote: > > Once we support ground reactions with a moving surface > (like the deck > > of a ship), why not just model the catapult as a faster moving > > surface? > > Because the gear don't simply rest on the catapult to be > pulled along via friction, they're actually bolted to it > during the launch. Hmm, bolted? Don't forget that the cat force is adjusted for the aircraft type and launch weight. It would have to be modelled as a spring > force acting on the nose gear to be correct. Even that's not > quite good enough, since on real cat shots the gear is > artificially compressed to keep the nose from tipping > backwards during the shot. Not exactly, and not in all cases. The F4K had an extending front leg which raised the nose into a take-off angle. When the cat was tensioned for a Buccaneer the nose wheel came off the deck, and a retractable tail bumper came into play. With a nose wheel tow, when the cat is tensioned a downward force is applied to the nose, since the attachment point is above the oleo. When the cat is fired more downward force is applied, as well as forward. > All of this would have to be > modelled; none of it shares any meaningful behaviour with > ground friction. Quite, but I believe that this should all be reasonably straightforward to simulate. > And arrestor wires have their own complexities. They need to > be "tuned" to the landing aircraft weight to produce the > right amount of deceleration. This is a manual process on a > real carrier, but we'd have to fake it somehow. > Do we need to model that? We know the mass of the aircraft, just apply a suitable decelerating force at the hook attachment point if the hook engages a wire. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
David Megginson wrote: > Once we support ground reactions with a moving surface (like the > deck of a ship), why not just model the catapult as a faster moving > surface? Because the gear don't simply rest on the catapult to be pulled along via friction, they're actually bolted to it during the launch. It would have to be modelled as a spring force acting on the nose gear to be correct. Even that's not quite good enough, since on real cat shots the gear is artificially compressed to keep the nose from tipping backwards during the shot. All of this would have to be modelled; none of it shares any meaningful behavior with ground friction. And arrestor wires have their own complexities. They need to be "tuned" to the landing aircraft weight to produce the right amount of deceleration. This is a manual process on a real carrier, but we'd have to fake it somehow. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
On Wed, 07 Jul 2004 15:12:05 -0400 David Megginson <[EMAIL PROTECTED]> wrote: Once we support ground reactions with a moving surface (like the deck of a ship), why not just model the catapult as a faster moving surface? That would supply only a sliding friction force to the tires, which would be way too low, if the surface was horizontal. If you are referring to a vertical surface, that would then be dependent on some kind of spring damper associated with the gear. That's no good, either. In reality, the catapult imparts a force on the aircraft, and that's how it should be modeled. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] status of aircraft carrier
on 07 July 2004 18:12 Mathias Fröhlich wrote > > On Mittwoch, 7. Juli 2004 18:59, Andy Ross wrote: > > The only "special" hardware on the carrier are the > arresting wires and > > catapults. It would be easier to just model these and let generic > > intersection code handle the deck intersection stuff. > Yes, this is what I meant. > > What I thought of is a kind of 'wire surface' which covers > the area between > the first and the last wire. If the hook intersects this > surface we caught a > wire. > That is not the whole truth, but may be a sufficient approximation. It would be a shame if we can't model individual wires, then we could experience hook-skip whereby the hook can miss all the wires. A chum of mine went around 14 times trying to catch a wire in a Gannet aboard HMS Hermes. But I think the 'wire-surface' would do quite well. > For the catapult I am not sure how this can be done. May be > with a surface > where the gear can be mounted onto the catapult and a line > providing the > direction where the force vector will point to. > If the nose gear intersects this surface, the aircraft can be > mounted onto the > catapult. It's very difficult to manoeuvre an aircraft onto a cat. You should consider modelling the self-aligning rollers and chocks which bodily shift the aircraft into the correct position. This need be no more than a area on the deck on which, if the main wheels are resting on it, a press of a key will automatically correctly position the aircraft. A key press should signify when the pilot is ready for launch, then the cat should fire after a random interval after. The Jet Blast Deflectors (JBDs) could also be modelled. A nose wheel tow system was used from about the F4 Phantom onwards, but prior to that a launching strop was attached to 2 hooks on the fuselage. I can provide more details if you are interested. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
Jon S Berndt wrote: Off the top of my head (and I'm in a real hurry at this second), I think it would be nice to make it possible to supply the FDMs with a force vector and point of application - perhaps even a moment vector. Is that what you are proposing? Once we support ground reactions with a moving surface (like the deck of a ship), why not just model the catapult as a faster moving surface? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
On Wed, 7 Jul 2004 19:12:11 +0200 Mathias Fröhlich <[EMAIL PROTECTED]> wrote: On Mittwoch, 7. Juli 2004 18:59, Andy Ross wrote: The only "special" hardware on the carrier are the arresting wires and catapults. It would be easier to just model these and let generic intersection code handle the deck intersection stuff. Yes, this is what I meant. What I thought of is a kind of 'wire surface' which covers the area bewteen the first and the last wire. If the hook intersects this surface we cought a wire. That is not the whole trueth, but may be a sufficient approximation. Off the top of my head (and I'm in a real hurry at this second), I think it would be nice to make it possible to supply the FDMs with a force vector and point of application - perhaps even a moment vector. Is that what you are proposing? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
On Mittwoch, 7. Juli 2004 18:59, Andy Ross wrote: > The only "special" hardware on the carrier are the arresting wires and > catapults. It would be easier to just model these and let generic > intersection code handle the deck intersection stuff. Yes, this is what I meant. What I thought of is a kind of 'wire surface' which covers the area bewteen the first and the last wire. If the hook intersects this surface we cought a wire. That is not the whole trueth, but may be a sufficient approximation. For the catapult I am not shure how this can be done. May be with a surface where the gear can be mounted onto the catapult and a line providing the direction where the force vector will point to. If the nose gear intersects this surface, the aircraft can be mounted onto the catapult. ssg has a class ssgInvisible which could be used for that stuff and which can be handled with the generic intersection routines. But I don't know how such leafs can be placed into the scene graph in an easy way. 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] status of aircraft carrier
Mathias Fröhlich wrote: > Which ssgBranch contains objects like an aircraft carrier? Special-casing "aircraft carrier" is almost certainly the wrong way to do this. There is no reason we can't do correct 3D intersection against the whole scene graph, and the code will be cleaner and simpler. The only "special" hardware on the carrier are the arresting wires and catapults. It would be easier to just model these and let generic intersection code handle the deck intersection stuff. The only bit of information we need that isn't present in the scene graph is the velocity of each surface. Since the AI subsystem is responsible for all of the moving objects in the sim, it ought to be easy enough to write an API to get it from there. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
On Dienstag, 6. Juli 2004 13:48, Norman Vine wrote: > Norman Vine write: [pseudocode] Thanks, that helped very much! I have hacked together a little proof of concept code of what I described earlier. It implements a little triangle cache which consists of a ssgBranch with at most 10 ssgLeafs each containing one triangle. I do a FGHitList::Intersect(...) with that private ssgBranch to get the required information. If the cache does not contain the triangle below the gear, I intersect with globals->get_scenery()->get_terrain_branch() and put that new triangle into the cache. That happens about every few seconds. So alltogether this is not performance critical: Intersection with the cache is cheap and intersection with the scene happens seldom. But I observe strange coredumps. How are threads organized in Flightgear? Does an other thread change the scenegraph below my a**? And if so, is there a lock which guards the scenegraph from changes? A second question: Which ssgBranch contains objects like an aircraft carrier? 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] status of aircraft carrier
Mathias Fröhlich wrote > Sent: 06 July 2004 09:59 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > > On Montag, 5. Juli 2004 22:47, David Culp wrote: > > > ... but it didn't move or have effects > > > for relative wind, deck motion or the burble around tail and > > > superstructure. > > > > Some more info on the AI carrier. I'm not too familiar with the > > hitlist, but I believe this is where objects get their solidity. A > > moving object would have to interact with the hitlist on > every frame, > > which might be too expensive. Again, I'm not really sure. > > > > As far as the wind/turbulence effects go, these are > possible. As an > > example see the FGAIThermal class which models a thermal. > It modifies > > the value of wind-from-down when the "user" aircraft is within the > > thermal's radius, creating a "rising column" of air. > > > > Similar things can be done to the AI tanker, causing > downwash behind > > it. A burble of air behind the ship can also be done like this. > > > > Causing a ship to bob up and down can be modeled by adding > a periodic > > altitude adjustment to the ship's location. That's the easy part. > > For the FDM part I have often thought about this. > > What will be needed is a method where we can query for the > position of a > surface element (triangle/whatever) and its speeds > (longitudinal/rotational) > dependent on a given position (usually the contact patch > position). Also for the cat and the wires we will need to > query for those objects and > their exact locations and speeds in an area of the aircraft. > > To implement that efficient, I think that a FGInterface or > some class in that > area should cache this information and should provide an > interface that could > easily used to query some properties of the ground in the area of the > aircraft. > > I wanted to start with code which can better follow the > ground level in the > area of the aircraft. Also I think it is interresting to distinguish > different load capacities of solid ground. Or/and different > ground types like > asphalt, grass or water. > > ... this way you will need to hit the runway with your 747 > ... also rolling jesus like on the water surface will not work > :) > > Having that, the carrier stuff is an extension which is not > too hard to do. > The most notable difference would be that such surface > triangles will have > velocities. And I think that it is save to assume that these > triangles will > not accelerate within one timestep or even within one frame. > They will just > get an other velocitiy in the next step. > We'll need to improve the handling of the arrester/tail hook as well (at least in YASim, not sure about JBSim). Both the Hunter and Seahawk have them. I've implemented them as a form of gear, but they need to be able to interact with the ground independently of the rest of the gear. At the moment, the compression doesn't appear to be right in that when retracted the compression remains non-zero. In the '60 and '70s some Royal Naval Air Stations used to have arrester wires at the approach end of runways to allow carrier landings to be practised. It might be an idea to start there. We'll need to simulate the projector landing sight as well. Looking forward to this step Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] status of aircraft carrier
Norman Vine write:
>
> This should be doable using the current hitlist mechanism
> and the current PLib code --untested but something like--
oops typo
> if (entity_hit && entity_hit -> isAKindOf ( ssgLeaf () ) )
this pseudo code should be
ssgEntity *entity_hit = hitlist -> get_entity( active_hit_idx );
if (entity_hit && entity_hit -> isAKindOf ( ssgTypeLeaf () ) )
{
ssgState *st = ((ssgLeaf *)entity_hit) -> state;
if ( st != NULL && st -> isAKindOf ( ssgTypeSimpleState () ) )
{
ssgSimpleState *ss = (ssgSimpleState *) st ;
char *tfname = ss -> getTextureFilename () ;
/// !!! do something based on texture filename
}
}
HTH
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich writes:
>
> To implement that efficient, I think that a FGInterface or some class in that
> area should cache this information and should provide an interface that could
> easily used to query some properties of the ground in the area of the
> aircraft.
>
> I wanted to start with code which can better follow the ground level in the
> area of the aircraft. Also I think it is interresting to distinguish
> different load capacities of solid ground. Or/and different ground types like
> asphalt, grass or water.
This should be doable using the current hitlist mechanism
and the current PLib code --untested but something like--
ssgEntity *entity_hit = hitlist -> get_entity( active_hit_idx );
if (entity_hit && entity_hit -> isAKindOf ( ssgLeaf () ) )
{
ssgState *st = ((ssgLeaf *)entity_hit) -> state;
if ( st != NULL && st -> isAKindOf ( ssgTypeSimpleState () ) )
{
ssgSimpleState *ss = (ssgSimpleState *) st ;
char *tfname = ss -> getTextureFilename () ;
/// !!! do something based on texture filename
}
}
HTH
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
On Montag, 5. Juli 2004 22:47, David Culp wrote: > > ... but it didn't move or have effects > > for relative wind, deck motion or the burble around tail and > > superstructure. > > Some more info on the AI carrier. I'm not too familiar with the hitlist, > but I believe this is where objects get their solidity. A moving object > would have to interact with the hitlist on every frame, which might be too > expensive. Again, I'm not really sure. > > As far as the wind/turbulence effects go, these are possible. As an > example see the FGAIThermal class which models a thermal. It modifies the > value of wind-from-down when the "user" aircraft is within the thermal's > radius, creating a "rising column" of air. > > Similar things can be done to the AI tanker, causing downwash behind it. A > burble of air behind the ship can also be done like this. > > Causing a ship to bob up and down can be modeled by adding a periodic > altitude adjustment to the ship's location. That's the easy part. For the FDM part I have often thought about this. What will be needed is a method where we can query for the position of a surface element (triangle/whatever) and its speeds (longitudinal/rotational) dependent on a given position (usually the contact patch position). Also for the cat and the wires we will need to query for those objects and their exact locations and speeds in an area of the aircraft. To implement that efficient, I think that a FGInterface or some class in that area should cache this information and should provide an interface that could easily used to query some properties of the ground in the area of the aircraft. I wanted to start with code which can better follow the ground level in the area of the aircraft. Also I think it is interresting to distinguish different load capacities of solid ground. Or/and different ground types like asphalt, grass or water. ... this way you will need to hit the runway with your 747 ... also rolling jesus like on the water surface will not work :) Having that, the carrier stuff is an extension which is not too hard to do. The most notable difference would be that such surface triangles will have velocities. And I think that it is save to assume that these triangles will not accelerate within one timestep or even within one frame. They will just get an other velocitiy in the next step. 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] status of aircraft carrier
> ... but it didn't move or have effects > for relative wind, deck motion or the burble around tail and > superstructure. Some more info on the AI carrier. I'm not too familiar with the hitlist, but I believe this is where objects get their solidity. A moving object would have to interact with the hitlist on every frame, which might be too expensive. Again, I'm not really sure. As far as the wind/turbulence effects go, these are possible. As an example see the FGAIThermal class which models a thermal. It modifies the value of wind-from-down when the "user" aircraft is within the thermal's radius, creating a "rising column" of air. Similar things can be done to the AI tanker, causing downwash behind it. A burble of air behind the ship can also be done like this. Causing a ship to bob up and down can be modeled by adding a periodic altitude adjustment to the ship's location. That's the easy part. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] status of aircraft carrier
> ... Is there a summary of its status and maybe recent > screenshots somewhere ? AFAIK we have two kinds of carrier available, a static, solid one that you can land on, and a moving one that isn't solid. Here's a screenshot of the latter type: http://home.comcast.net/~davidculp2/saratoga_SFO_bay.jpg The static one is part of the scenery. The moving one is an instance of FGAIShip, one of the AI object types. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
