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 10000m/s
and you are running at 20fps the effective resolution of the pulses
(if the aircraft is stationary) will be 10000/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, and using the elevation markers to show the
high-elevation points, it usually manages to find ridge-lines and
buildings/bridges etc with a high degree of accuracy) On top of
that, the frame-rate varies so the resolution becomes
indeterminate. Using a slower pulse speed increases the resolution
but also increases the submodel overhead because they need a longer
lifetime to reach the same scanning distance whilst simultaneously
increasing the time before you get a 'return' and thus reducing the
time available to react:(
It _is_ an attractive approach but I think the cons outweigh the
pros.
LeeE
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/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/vse0120000070mrt/direct/01/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
