Re: [Flightgear-devel] Object avoidance
I wrote: Subject: Re: [Flightgear-devel] Object avoidance Lee Subject: Re: [Flightgear-devel] Object avoidance On Sunday 17 February 2008 11:35, Vivian Meazza wrote: Markus Subject: Re: [Flightgear-devel] Object avoidance LeeE wrote: On Friday 15 February 2008 17:08, Melchior FRANZ wrote: * R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? m. Markus Zojer has used this technique for the TFA functions in the B-1B. I had a look at it and experimented with it when I wanted to add TFA to a couple of aircraft I've done - it's a very appealing approach because it's almost like simulating a real radar. I had a play with the technique but hit some problems with it, mainly because the trajectory of the submodels is fixed to the pitch of the aircraft. I found it fine while the aircraft was in level flight but I hit some issues when the aircraft was pitched up or down to any significant degree and in the end I decided to use the Nasal geo functions instead. I am still working on the terrain following function, rewriting it completely for the 3rd time and again used the real radar approach, as you are not dependent in the scanning resolution of the geo properties. The fixed radar beam (submodels) could be refined if we would add the property absolute to the pitch angle of the submodel (so the submodel leaves the plane at always the same pitch angle). Due to the ongoing environment development in OSG, now low level flying is really flashing :) Expect the new version included in the next release (coming hopefully within the next 10 days). Fly on, Markus As I mentioned previously, the geo functions do interact with static buildings and structures, as long as the scanning scheme has a high enough resolution to ensure sampling them - I haven't tried with random objects though - still on OSG 2.2 here and the performance hit when using OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here. I have noticed that pylons are not detected and I would doubt that trees are detected either, presumably because they have no area. The pylons are made with line objects that have no width and the trees, at least in plan, also have no width, so it'll be very unlikely to hit the exact point where they are in any scanning scheme. Adding a transparent horizontal plane poly to the top of these objects probably would make it work, but not only would it increase the render load but also probably introduce more transparency render artifacts and ordering issues. OK I can give you submodels which are stabilised in pitch within a few days, if this is really a good approach - submodels are a big frame rate hit. Would an alternative be to duplicate the code which calculates the ground intersection for submodels, without the cost of flying the submodel? This approach would take more coding, but might be less frame rate intensive. However, the methods which are used are some of the most frame rate heavy around so perhaps in practice not too different. Vivian It is an attractive approach because it is very similar to the way that real radar works and it's fun to add a visible model to the pulses so you can see them:) Some of the problems I found with it though, include the high submodel overhead. Even in level flight I found I needed to 'fire' pulses in a vertical fan, both above and below the line of flight, to ensure detection of higher ground, especially if the aircraft is pitched down to any significant degree. However, if there isn't any higher ground within range, which will be the case unless you only fly in mountainous regions, a high proportion of the pulses will never hit anything and will only expire at the end of their lifetime - this seemed like an unnecessary overhead. I also hit some problems with the resolution of the pulses, this seeming to be tied to the pulse speed, the aircraft speed and the frame-rate, because the location of the pulse can only be checked once per frame. For example, if you use a pulse speed of 1m/s and you are running at 20fps the effective resolution of the pulses
Re: [Flightgear-devel] Object avoidance
LeeE wrote: On Friday 15 February 2008 16:36, ricardo freitasfilho wrote: Hi, I'm doing some simulations of a airship using the aerosim blockset and the flightgear. It is usefull if there is a may to get the information of the scenery buildings so we can avoid these building in the simulation. I was reading one of your answers and I got interested in how can I send these information to the blockset. Can you help me with that? I found, while working on a terrain following/avoidance system for some of the aircraft I've done, that the Nasal geo.elevation(lat, lon) function will return the height of buildings or other structures e.g. bridges located at that lat,lon. There are not any in-built FG scanning schemes/mechanisms though, so you'll have to design and implement one in Nasal to fit your needs. Have a look at the cvs BAC-TSR2 TFA nasal stuff to see the simple look-ahead scanning schemes I've done. Both of the schemes I've used just perform a single track look-ahead scan, compensated for yaw but not for turning flight (yet). LeeE I don't know if it could be useful or just pertinent, but I modeled one of the features of the Intruder's Terrain avoidance radar. It displays the ground elevations relative to the aircraft's datum line. the radar shadow is also computed. Have a look at the A-6E the display is just under the video Attitude Indicator. Any comment welcome. Cheers, Alexis - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
On Tuesday 19 February 2008 20:05, alexis bory wrote: LeeE wrote: On Friday 15 February 2008 16:36, ricardo freitasfilho wrote: Hi, I'm doing some simulations of a airship using the aerosim blockset and the flightgear. It is usefull if there is a may to get the information of the scenery buildings so we can avoid these building in the simulation. I was reading one of your answers and I got interested in how can I send these information to the blockset. Can you help me with that? I found, while working on a terrain following/avoidance system for some of the aircraft I've done, that the Nasal geo.elevation(lat, lon) function will return the height of buildings or other structures e.g. bridges located at that lat,lon. There are not any in-built FG scanning schemes/mechanisms though, so you'll have to design and implement one in Nasal to fit your needs. Have a look at the cvs BAC-TSR2 TFA nasal stuff to see the simple look-ahead scanning schemes I've done. Both of the schemes I've used just perform a single track look-ahead scan, compensated for yaw but not for turning flight (yet). LeeE I don't know if it could be useful or just pertinent, but I modeled one of the features of the Intruder's Terrain avoidance radar. It displays the ground elevations relative to the aircraft's datum line. the radar shadow is also computed. Have a look at the A-6E the display is just under the video Attitude Indicator. Any comment welcome. Cheers, Alexis That looks pretty neat - nice aircraft Alexis. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
Lee Subject: Re: [Flightgear-devel] Object avoidance On Sunday 17 February 2008 11:35, Vivian Meazza wrote: Markus Subject: Re: [Flightgear-devel] Object avoidance LeeE wrote: On Friday 15 February 2008 17:08, Melchior FRANZ wrote: * R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? m. Markus Zojer has used this technique for the TFA functions in the B-1B. I had a look at it and experimented with it when I wanted to add TFA to a couple of aircraft I've done - it's a very appealing approach because it's almost like simulating a real radar. I had a play with the technique but hit some problems with it, mainly because the trajectory of the submodels is fixed to the pitch of the aircraft. I found it fine while the aircraft was in level flight but I hit some issues when the aircraft was pitched up or down to any significant degree and in the end I decided to use the Nasal geo functions instead. I am still working on the terrain following function, rewriting it completely for the 3rd time and again used the real radar approach, as you are not dependent in the scanning resolution of the geo properties. The fixed radar beam (submodels) could be refined if we would add the property absolute to the pitch angle of the submodel (so the submodel leaves the plane at always the same pitch angle). Due to the ongoing environment development in OSG, now low level flying is really flashing :) Expect the new version included in the next release (coming hopefully within the next 10 days). Fly on, Markus As I mentioned previously, the geo functions do interact with static buildings and structures, as long as the scanning scheme has a high enough resolution to ensure sampling them - I haven't tried with random objects though - still on OSG 2.2 here and the performance hit when using OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here. I have noticed that pylons are not detected and I would doubt that trees are detected either, presumably because they have no area. The pylons are made with line objects that have no width and the trees, at least in plan, also have no width, so it'll be very unlikely to hit the exact point where they are in any scanning scheme. Adding a transparent horizontal plane poly to the top of these objects probably would make it work, but not only would it increase the render load but also probably introduce more transparency render artifacts and ordering issues. OK I can give you submodels which are stabilised in pitch within a few days, if this is really a good approach - submodels are a big frame rate hit. Would an alternative be to duplicate the code which calculates the ground intersection for submodels, without the cost of flying the submodel? This approach would take more coding, but might be less frame rate intensive. However, the methods which are used are some of the most frame rate heavy around so perhaps in practice not too different. Vivian It is an attractive approach because it is very similar to the way that real radar works and it's fun to add a visible model to the pulses so you can see them:) Some of the problems I found with it though, include the high submodel overhead. Even in level flight I found I needed to 'fire' pulses in a vertical fan, both above and below the line of flight, to ensure detection of higher ground, especially if the aircraft is pitched down to any significant degree. However, if there isn't any higher ground within range, which will be the case unless you only fly in mountainous regions, a high proportion of the pulses will never hit anything and will only expire at the end of their lifetime - this seemed like an unnecessary overhead. I also hit some problems with the resolution of the pulses, this seeming to be tied to the pulse speed, the aircraft speed and the frame-rate, because the location of the pulse can only be checked once per frame. For example, if you use a pulse speed of 1m/s and you are running at 20fps the effective resolution of the pulses (if the aircraft is stationary) will be 1/20 = 500m. Furthermore, once the aircraft speed is added to the pulse speed, because the pulse speed is relative
Re: [Flightgear-devel] Object avoidance
On Feb 15, 2008 11:59 AM, LeeE [EMAIL PROTECTED] wrote: On Friday 15 February 2008 16:36, ricardo freitasfilho wrote: Hi, I'm doing some simulations of a airship using the aerosim blockset and the flightgear. It is usefull if there is a may to get the information of the scenery buildings so we can avoid these building in the simulation. I was reading one of your answers and I got interested in how can I send these information to the blockset. Can you help me with that? I found, while working on a terrain following/avoidance system for some of the aircraft I've done, that the Nasal geo.elevation(lat, lon) function will return the height of buildings or other structures e.g. bridges located at that lat,lon. There are not any in-built FG scanning schemes/mechanisms though, so you'll have to design and implement one in Nasal to fit your needs. Have a look at the cvs BAC-TSR2 TFA nasal stuff to see the simple look-ahead scanning schemes I've done. Both of the schemes I've used just perform a single track look-ahead scan, compensated for yaw but not for turning flight (yet). LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel The nasal archive wish you are saying in the BAC-TSR2-tfa right? I don't realy know how to do a nasal archive but I'm going to study that. How whould I be able to send that information for Matlab? Can you help me with that? I only have 1 week to get that done. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
On Monday 18 February 2008 16:36, ricardo freitasfilho wrote: On Feb 15, 2008 11:59 AM, LeeE [EMAIL PROTECTED] wrote: On Friday 15 February 2008 16:36, ricardo freitasfilho wrote: Hi, I'm doing some simulations of a airship using the aerosim blockset and the flightgear. It is usefull if there is a may to get the information of the scenery buildings so we can avoid these building in the simulation. I was reading one of your answers and I got interested in how can I send these information to the blockset. Can you help me with that? I found, while working on a terrain following/avoidance system for some of the aircraft I've done, that the Nasal geo.elevation(lat, lon) function will return the height of buildings or other structures e.g. bridges located at that lat,lon. There are not any in-built FG scanning schemes/mechanisms though, so you'll have to design and implement one in Nasal to fit your needs. Have a look at the cvs BAC-TSR2 TFA nasal stuff to see the simple look-ahead scanning schemes I've done. Both of the schemes I've used just perform a single track look-ahead scan, compensated for yaw but not for turning flight (yet). LeeE The nasal archive wish you are saying in the BAC-TSR2-tfa right? I don't realy know how to do a nasal archive but I'm going to study that. How whould I be able to send that information for Matlab? Can you help me with that? I only have 1 week to get that done. Yup - it's in the cvs versions of the B-52F, BAC-TSR2 SU-37. The BAC-TSR2 is the best 'tuned' though - it's pretty accurate down to 100ft and will handle rolling terrain at 50ft. The B-52F SU-37 aren't as highly tuned and are better off at = 100ft. This is down to controller tuning issues though and not the principles. I'm a bit short of time right now but start by grepping through the BAC-TSR2 folder for 'tfa' to get an idea where it's referenced and identify the necessary files. Actually, the SU-37 might be easier to follow as it was a quick addition and I think I merged a couple of the relevant Nasal files. The BAC-TSR2 includes a couple of 2D diagnostic instruments to help TFA monitoring. If you can't figure it out from that, get back to me and I'll pick out the specific bits you need to add. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
LeeE wrote: On Friday 15 February 2008 17:08, Melchior FRANZ wrote: * R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? m. Markus Zojer has used this technique for the TFA functions in the B-1B. I had a look at it and experimented with it when I wanted to add TFA to a couple of aircraft I've done - it's a very appealing approach because it's almost like simulating a real radar. I had a play with the technique but hit some problems with it, mainly because the trajectory of the submodels is fixed to the pitch of the aircraft. I found it fine while the aircraft was in level flight but I hit some issues when the aircraft was pitched up or down to any significant degree and in the end I decided to use the Nasal geo functions instead. I am still working on the terrain following function, rewriting it completely for the 3rd time and again used the real radar approach, as you are not dependent in the scanning resolution of the geo properties. The fixed radar beam (submodels) could be refined if we would add the property absolute to the pitch angle of the submodel (so the submodel leaves the plane at always the same pitch angle). Due to the ongoing environment development in OSG, now low level flying is really flashing :) Expect the new version included in the next release (coming hopefully within the next 10 days). Fly on, Markus As I mentioned previously, the geo functions do interact with static buildings and structures, as long as the scanning scheme has a high enough resolution to ensure sampling them - I haven't tried with random objects though - still on OSG 2.2 here and the performance hit when using OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here. I have noticed that pylons are not detected and I would doubt that trees are detected either, presumably because they have no area. The pylons are made with line objects that have no width and the trees, at least in plan, also have no width, so it'll be very unlikely to hit the exact point where they are in any scanning scheme. Adding a transparent horizontal plane poly to the top of these objects probably would make it work, but not only would it increase the render load but also probably introduce more transparency render artifacts and ordering issues. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
Markus Subject: Re: [Flightgear-devel] Object avoidance LeeE wrote: On Friday 15 February 2008 17:08, Melchior FRANZ wrote: * R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? m. Markus Zojer has used this technique for the TFA functions in the B-1B. I had a look at it and experimented with it when I wanted to add TFA to a couple of aircraft I've done - it's a very appealing approach because it's almost like simulating a real radar. I had a play with the technique but hit some problems with it, mainly because the trajectory of the submodels is fixed to the pitch of the aircraft. I found it fine while the aircraft was in level flight but I hit some issues when the aircraft was pitched up or down to any significant degree and in the end I decided to use the Nasal geo functions instead. I am still working on the terrain following function, rewriting it completely for the 3rd time and again used the real radar approach, as you are not dependent in the scanning resolution of the geo properties. The fixed radar beam (submodels) could be refined if we would add the property absolute to the pitch angle of the submodel (so the submodel leaves the plane at always the same pitch angle). Due to the ongoing environment development in OSG, now low level flying is really flashing :) Expect the new version included in the next release (coming hopefully within the next 10 days). Fly on, Markus As I mentioned previously, the geo functions do interact with static buildings and structures, as long as the scanning scheme has a high enough resolution to ensure sampling them - I haven't tried with random objects though - still on OSG 2.2 here and the performance hit when using OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here. I have noticed that pylons are not detected and I would doubt that trees are detected either, presumably because they have no area. The pylons are made with line objects that have no width and the trees, at least in plan, also have no width, so it'll be very unlikely to hit the exact point where they are in any scanning scheme. Adding a transparent horizontal plane poly to the top of these objects probably would make it work, but not only would it increase the render load but also probably introduce more transparency render artifacts and ordering issues. OK I can give you submodels which are stabilised in pitch within a few days, if this is really a good approach - submodels are a big frame rate hit. Would an alternative be to duplicate the code which calculates the ground intersection for submodels, without the cost of flying the submodel? This approach would take more coding, but might be less frame rate intensive. However, the methods which are used are some of the most frame rate heavy around so perhaps in practice not too different. Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
On Sunday 17 February 2008 11:35, Vivian Meazza wrote: Markus Subject: Re: [Flightgear-devel] Object avoidance LeeE wrote: On Friday 15 February 2008 17:08, Melchior FRANZ wrote: * R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? m. Markus Zojer has used this technique for the TFA functions in the B-1B. I had a look at it and experimented with it when I wanted to add TFA to a couple of aircraft I've done - it's a very appealing approach because it's almost like simulating a real radar. I had a play with the technique but hit some problems with it, mainly because the trajectory of the submodels is fixed to the pitch of the aircraft. I found it fine while the aircraft was in level flight but I hit some issues when the aircraft was pitched up or down to any significant degree and in the end I decided to use the Nasal geo functions instead. I am still working on the terrain following function, rewriting it completely for the 3rd time and again used the real radar approach, as you are not dependent in the scanning resolution of the geo properties. The fixed radar beam (submodels) could be refined if we would add the property absolute to the pitch angle of the submodel (so the submodel leaves the plane at always the same pitch angle). Due to the ongoing environment development in OSG, now low level flying is really flashing :) Expect the new version included in the next release (coming hopefully within the next 10 days). Fly on, Markus As I mentioned previously, the geo functions do interact with static buildings and structures, as long as the scanning scheme has a high enough resolution to ensure sampling them - I haven't tried with random objects though - still on OSG 2.2 here and the performance hit when using OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here. I have noticed that pylons are not detected and I would doubt that trees are detected either, presumably because they have no area. The pylons are made with line objects that have no width and the trees, at least in plan, also have no width, so it'll be very unlikely to hit the exact point where they are in any scanning scheme. Adding a transparent horizontal plane poly to the top of these objects probably would make it work, but not only would it increase the render load but also probably introduce more transparency render artifacts and ordering issues. OK I can give you submodels which are stabilised in pitch within a few days, if this is really a good approach - submodels are a big frame rate hit. Would an alternative be to duplicate the code which calculates the ground intersection for submodels, without the cost of flying the submodel? This approach would take more coding, but might be less frame rate intensive. However, the methods which are used are some of the most frame rate heavy around so perhaps in practice not too different. Vivian It is an attractive approach because it is very similar to the way that real radar works and it's fun to add a visible model to the pulses so you can see them:) Some of the problems I found with it though, include the high submodel overhead. Even in level flight I found I needed to 'fire' pulses in a vertical fan, both above and below the line of flight, to ensure detection of higher ground, especially if the aircraft is pitched down to any significant degree. However, if there isn't any higher ground within range, which will be the case unless you only fly in mountainous regions, a high proportion of the pulses will never hit anything and will only expire at the end of their lifetime - this seemed like an unnecessary overhead. I also hit some problems with the resolution of the pulses, this seeming to be tied to the pulse speed, the aircraft speed and the frame-rate, because the location of the pulse can only be checked once per frame. For example, if you use a pulse speed of 1m/s and you are running at 20fps the effective resolution of the pulses (if the aircraft is stationary) will be 1/20 = 500m. Furthermore, once the aircraft speed is added to the pulse speed, because the pulse speed is relative to the aircraft speed, the resolution reduces as airspeed increases (this is also a factor in the Nasal geo solution I've done but in 'continuous' mode it is ameliorated to a large degree by multiple scans of the same area and in practice
Re: [Flightgear-devel] Object avoidance
Has anyone tried integrating this radar with standard terrain models such as those from the DMA? Also, it seems that integrating a realistic radar simulation feature into FlightGear is valuable even if it runs a little slow, because having such a model would provide developers an open source, low-cost platform for testing TF/TA systems. I can certainly imagine many uses for such a feature with the emergence of UAS for so many applications. Lee LeeE wrote: On Sunday 17 February 2008 11:35, Vivian Meazza wrote: Markus Subject: Re: [Flightgear-devel] Object avoidance LeeE wrote: On Friday 15 February 2008 17:08, Melchior FRANZ wrote: * R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? m. Markus Zojer has used this technique for the TFA functions in the B-1B. I had a look at it and experimented with it when I wanted to add TFA to a couple of aircraft I've done - it's a very appealing approach because it's almost like simulating a real radar. I had a play with the technique but hit some problems with it, mainly because the trajectory of the submodels is fixed to the pitch of the aircraft. I found it fine while the aircraft was in level flight but I hit some issues when the aircraft was pitched up or down to any significant degree and in the end I decided to use the Nasal geo functions instead. I am still working on the terrain following function, rewriting it completely for the 3rd time and again used the real radar approach, as you are not dependent in the scanning resolution of the geo properties. The fixed radar beam (submodels) could be refined if we would add the property absolute to the pitch angle of the submodel (so the submodel leaves the plane at always the same pitch angle). Due to the ongoing environment development in OSG, now low level flying is really flashing :) Expect the new version included in the next release (coming hopefully within the next 10 days). Fly on, Markus As I mentioned previously, the geo functions do interact with static buildings and structures, as long as the scanning scheme has a high enough resolution to ensure sampling them - I haven't tried with random objects though - still on OSG 2.2 here and the performance hit when using OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here. I have noticed that pylons are not detected and I would doubt that trees are detected either, presumably because they have no area. The pylons are made with line objects that have no width and the trees, at least in plan, also have no width, so it'll be very unlikely to hit the exact point where they are in any scanning scheme. Adding a transparent horizontal plane poly to the top of these objects probably would make it work, but not only would it increase the render load but also probably introduce more transparency render artifacts and ordering issues. OK I can give you submodels which are stabilised in pitch within a few days, if this is really a good approach - submodels are a big frame rate hit. Would an alternative be to duplicate the code which calculates the ground intersection for submodels, without the cost of flying the submodel? This approach would take more coding, but might be less frame rate intensive. However, the methods which are used are some of the most frame rate heavy around so perhaps in practice not too different. Vivian It is an attractive approach because it is very similar to the way that real radar works and it's fun to add a visible model to the pulses so you can see them:) Some of the problems I found with it though, include the high submodel overhead. Even in level flight I found I needed to 'fire' pulses in a vertical fan, both above and below the line of flight, to ensure detection of higher ground, especially if the aircraft is pitched down to any significant degree. However, if there isn't any higher ground within range, which will be the case unless you only fly in mountainous regions, a high proportion of the pulses will never hit anything and will only expire at the end of their lifetime - this seemed like an unnecessary overhead. I also hit some problems with the resolution of the pulses, this seeming to be tied to the pulse speed, the aircraft speed and the frame-rate, because the location of the pulse can only be checked once per frame. For example, if you use a pulse speed of 1m/s and you are running at 20fps
Re: [Flightgear-devel] Object avoidance
Thanks for stabilized submodels, makes them more versatile. Using 2 beams of each 5 submodels per second (max 10 submodels at a time together, norm 4 -8) I could not monitor a frame rate drop (ok, maybe in the 1-3fps scale, but that is hardly monitorable as you never know where it is coming from), maybe because no visible model is attached. Fly on, Markus Vivian Meazza wrote: Markus Subject: Re: [Flightgear-devel] Object avoidance LeeE wrote: On Friday 15 February 2008 17:08, Melchior FRANZ wrote: * R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? m. Markus Zojer has used this technique for the TFA functions in the B-1B. I had a look at it and experimented with it when I wanted to add TFA to a couple of aircraft I've done - it's a very appealing approach because it's almost like simulating a real radar. I had a play with the technique but hit some problems with it, mainly because the trajectory of the submodels is fixed to the pitch of the aircraft. I found it fine while the aircraft was in level flight but I hit some issues when the aircraft was pitched up or down to any significant degree and in the end I decided to use the Nasal geo functions instead. I am still working on the terrain following function, rewriting it completely for the 3rd time and again used the real radar approach, as you are not dependent in the scanning resolution of the geo properties. The fixed radar beam (submodels) could be refined if we would add the property absolute to the pitch angle of the submodel (so the submodel leaves the plane at always the same pitch angle). Due to the ongoing environment development in OSG, now low level flying is really flashing :) Expect the new version included in the next release (coming hopefully within the next 10 days). Fly on, Markus As I mentioned previously, the geo functions do interact with static buildings and structures, as long as the scanning scheme has a high enough resolution to ensure sampling them - I haven't tried with random objects though - still on OSG 2.2 here and the performance hit when using OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here. I have noticed that pylons are not detected and I would doubt that trees are detected either, presumably because they have no area. The pylons are made with line objects that have no width and the trees, at least in plan, also have no width, so it'll be very unlikely to hit the exact point where they are in any scanning scheme. Adding a transparent horizontal plane poly to the top of these objects probably would make it work, but not only would it increase the render load but also probably introduce more transparency render artifacts and ordering issues. OK I can give you submodels which are stabilised in pitch within a few days, if this is really a good approach - submodels are a big frame rate hit. Would an alternative be to duplicate the code which calculates the ground intersection for submodels, without the cost of flying the submodel? This approach would take more coding, but might be less frame rate intensive. However, the methods which are used are some of the most frame rate heavy around so perhaps in practice not too different. Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
On Friday 15 February 2008 16:36, ricardo freitasfilho wrote: Hi, I'm doing some simulations of a airship using the aerosim blockset and the flightgear. It is usefull if there is a may to get the information of the scenery buildings so we can avoid these building in the simulation. I was reading one of your answers and I got interested in how can I send these information to the blockset. Can you help me with that? I found, while working on a terrain following/avoidance system for some of the aircraft I've done, that the Nasal geo.elevation(lat, lon) function will return the height of buildings or other structures e.g. bridges located at that lat,lon. There are not any in-built FG scanning schemes/mechanisms though, so you'll have to design and implement one in Nasal to fit your needs. Have a look at the cvs BAC-TSR2 TFA nasal stuff to see the simple look-ahead scanning schemes I've done. Both of the schemes I've used just perform a single track look-ahead scan, compensated for yaw but not for turning flight (yet). LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
* ricardo freitasfilho -- Friday 15 February 2008: It is usefull if there is a may to get the information of the scenery buildings so we can avoid these building in the simulation. There's no way to query the location of buildings (like in real life :-). But you can check for the terrain elevation at some given coordinate (Nasal's geodinfo(), or the geo.elevation() wrapper), and you can get the elevation of an impact point (see $FG_ROOT/Docs/README.submodels). The latter might report impacts on buildings (fg/osg?), so you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. m. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
* R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
On Friday 15 February 2008 17:08, Melchior FRANZ wrote: * R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? m. Markus Zojer has used this technique for the TFA functions in the B-1B. I had a look at it and experimented with it when I wanted to add TFA to a couple of aircraft I've done - it's a very appealing approach because it's almost like simulating a real radar. I had a play with the technique but hit some problems with it, mainly because the trajectory of the submodels is fixed to the pitch of the aircraft. I found it fine while the aircraft was in level flight but I hit some issues when the aircraft was pitched up or down to any significant degree and in the end I decided to use the Nasal geo functions instead. As I mentioned previously, the geo functions do interact with static buildings and structures, as long as the scanning scheme has a high enough resolution to ensure sampling them - I haven't tried with random objects though - still on OSG 2.2 here and the performance hit when using OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here. I have noticed that pylons are not detected and I would doubt that trees are detected either, presumably because they have no area. The pylons are made with line objects that have no width and the trees, at least in plan, also have no width, so it'll be very unlikely to hit the exact point where they are in any scanning scheme. Adding a transparent horizontal plane poly to the top of these objects probably would make it work, but not only would it increase the render load but also probably introduce more transparency render artifacts and ordering issues. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
--- Melchior FRANZ wrote: * R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? Photons colliding with cows - isn't that a microwave oven? TING! Burger anyone? ;) -Stuart ___ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
