Board index FlightGear Development Nasal

On board Radar

Nasal is the scripting language of FlightGear.

On board Radar

Postby 5H1N0B1 » Thu Jan 30, 2014 4:30 pm

Hi everyone,

I would like to work on the onbard radar.
On the mirage 2000, I use modified radar2.nas for this. This is, for my humble point of view the most appropriate for that purpose.
It simulate the sweep, azimuth angle, radar range, perhaps attenuation, lightning, nearest target, use the "target" class and feed the rwr.
But their things missing or not enough dynamic that we can't add without changing the code and make it very specific, which is not an ideal at all for me.
So I'm going to re code it, and add these things :
1) OOP : Using object should help us to have something more dynamic, or more drivable.
2) Add choosable azimuth angle, for normal mode, and lightning mode.
3) Add choosable : sweep or not. to simulate modern AESA radar
4) Add the hability to not detect an aircraft, when there is a mountain between them and us.
5) Add heat detection and RCS management (-> to "not" detect an B2 -> perhaps with input in radar-dist)
6) 5-> we could push the vice until define a band of frequency for the radar and for the RCS...(not for now, but the code should be able to receive it without big changes)
7) Add target management -> not just the nearest, but modern aircraft can select their target.
8) Modify the "target" object : To make it compatible with missile.nas( Not with the radar but : Make the possibility to create a Target object with just coordinate : long/lat/alt, in order to simulate laser targeting)
9) Terrain ? (Don't know how to do that...)
10) IFF management ( I think it work with the transponder...)
11) Canvas compatibility ? (don't know enough about canvas but I can try)
12) Loop management -> to have a better framerate
13) Other generic things ? (Do not hesitate to add your Christmas list...)

This is a first step before making the missile.nas really generic.
My question before going into 2-3 month (perhpas more) of work, is, in order to avoid reinventing the wheel :
Is there something like that in flightgear ?

Thanks for your anwser

5H1N0B1
5H1N0B1
"Each day, with every person you meet, there is something to learn"
5H1N0B1
 
Posts: 222
Joined: Thu Aug 30, 2012 10:36 am
Location: France
Callsign: 5H1N0B1
IRC name: _5H1N0B1
Version: GIT
OS: Ubuntu

Re: On board Radar

Postby Hooray » Thu Jan 30, 2014 4:36 pm

you really SHOULD be using MapStructure for this, we have quite a few existing layers that could be directly useful here, or that could be adapted.
This will require some added support for styling, LOD-handling and probably caching. But we are working on that anyway, so please see the wiki (MapStructure) and get in touch via the canvas subforum, so that we can learn what's missing.
You can basically put together a radar with a handful of MapStructure layers - each layer will typically involve 10-20 lines of custom code, but can be copied and adapted from existing layers.

http://wiki.flightgear.org/MapStructure

Using MapStructure for this, will save you a ton of work, and will automatically be much faster than a custom-coded implementation - also, it means that your Radar code can be used in other aircraft easily, but also in other dialogs - such as ATC-FS or for other ATC purposes, such as an AWACS aircraft.

Given that you already know Nasal, this will save you a ton of work, and things will be much better maintainable that way. So please let's coordinate things a bit. I promise you'll have my full attention and support regarding missing features.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: On board Radar

Postby Johan G » Thu Jan 30, 2014 5:49 pm

5H1N0B1 wrote in Thu Jan 30, 2014 4:30 pm:9) Terrain ? (Don't know how to do that...)

Search the forum for "terrain sampler", "terrain sampling" or something similar to that and also "vertical situation display". I know there has been work related both to rendering elevation and an elevation profile in the past. Also see the wiki article Howto:Terrain sampling in Nasal.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: On board Radar

Postby Hooray » Thu Jan 30, 2014 5:53 pm

You are right, I have already updated the MapStructure article (wiki) to provide the corresponding pointers.
The main issue here being that we should probably NOT use geodinfo() directly, but instead use TorstenD's terrain presampler, which was custom-coded and implemented in C++ to speed up terrain-presampling for ThorstenR's LW/AW system - so this should be a good foundation for creating heightmaps and styling them based on elevation information.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: On board Radar

Postby 5H1N0B1 » Thu Jan 30, 2014 8:01 pm

This is great news :)

I do understand what the point with MapStructure.
So If I understand well, I feed the MapStructure with an object an it will draw it ?
I just don't really understand yet what can be the object needed to implement this...
The radar could return an array of "target" obect, which contain all the data on each target (heading, bearing, ,lat, long, alt, pitch, dist, speed, RCS, infrared etc...)

Does this kind of array[] can match ?
5H1N0B1
"Each day, with every person you meet, there is something to learn"
5H1N0B1
 
Posts: 222
Joined: Thu Aug 30, 2012 10:36 am
Location: France
Callsign: 5H1N0B1
IRC name: _5H1N0B1
Version: GIT
OS: Ubuntu

Re: On board Radar

Postby Hooray » Thu Jan 30, 2014 8:07 pm

the kind of object that is typically needed by MapStructure is just an geo-referenced position, which is just fancy lingo for anything that has a 3D position (lat,lon,altitude)
MapStructure will internally handle all the details to implement each layer efficiently.

The framework works in terms of "symbols" and "layers" where each layer would have symbols, along with controllers for each symbol (i.e. to animate things, to change the color/style etc) - also, each layer can be controlled using a layer-controller, e.g. to change the range for example.

I suggest to look at some of the simpler examples, e.g. the NDB symbol to see how everything is implemented.
You can basically load a SVG file or draw your own symbols using OpenVG instructions.

Then, the layer controller will determine where symbols are to be drawn, and do any filtering (range, altitude, mountains, azimuth).

So the result will just return a vector (resizable array) to the layer controller with drawables (symbols).

You will probably want to experiment first with a really simple example to see how everything works.

I suggest to try out the demo/example mentioned in the article.

Ultimately, you can them combine many layers to form a single map, and each layer can have "many" different symbols
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: On board Radar

Postby Johan G » Thu Jan 30, 2014 8:29 pm

Hooray wrote in Thu Jan 30, 2014 5:53 pm:we should probably NOT use geodinfo() directly, but instead use TorstenD's terrain presampler, which was custom-coded and implemented in C++ to speed up terrain-presampling for ThorstenR's LW/AW system.

Information on that is extremely sparse on the wiki and the forum. See this Google search (currently 9 hits, most of them referring to it, but not linking to any further information).
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: On board Radar

Postby Hooray » Thu Jan 30, 2014 8:35 pm

Johan G wrote in Thu Jan 30, 2014 8:29 pm:
Hooray wrote in Thu Jan 30, 2014 5:53 pm:we should probably NOT use geodinfo() directly, but instead use TorstenD's terrain presampler, which was custom-coded and implemented in C++ to speed up terrain-presampling for ThorstenR's LW/AW system.

Information on that is extremely sparse on the wiki and the forum. See this Google search (currently 9 hits, most of them referring to it, but not linking to any further information).

right, I guess the problem is that core developers do not usually have to go through the rigid process of having their features/code peer-reviewed by others - which is why we are seeing an increasing number of new (and USEFUL!) features added without any helpful docs - no matter if it's via $FG_ROOT/Docs/README* files or via corresponding wiki articles... This has been brought up by a number of people, and Torsten is currently not as much involved in FG, so it'd be kinda pointless to get in touch with him - for now, I would suggest to look into Thorsten's AW compat_layer module, which encapsulates the presampler module in a back-end agnostic fashion, if there are any open questions, just get in touch, so that we can document the subsystem - I am sure, that Thorsten can also clarify a few things, because it was basically custom-coded for him by TorstenD.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: On board Radar

Postby 5H1N0B1 » Thu Jan 30, 2014 10:45 pm

Ok, it's gonna be touchy...
I'm not that good yet, so it will takes time... :)
First I have to code the Radar object itself without thinking about graphical stuff.

Then, it should be easy to add or update a function in order to feed MapStructure, as long as the target object have his (lat/long/alt)
5H1N0B1
"Each day, with every person you meet, there is something to learn"
5H1N0B1
 
Posts: 222
Joined: Thu Aug 30, 2012 10:36 am
Location: France
Callsign: 5H1N0B1
IRC name: _5H1N0B1
Version: GIT
OS: Ubuntu

Re: On board Radar

Postby Hooray » Thu Jan 30, 2014 10:46 pm

I would prototype the whole thing as a simple XML dialog, without even looking at the aircraft in the beginning.
You can use the example at: http://wiki.flightgear.org/MapStructure#Hello_World
And then you can directly add your code there to come up the heuristics - always use separate classes (or at least functions), to reduce unnecessary coupling.
That way, you can easily integrate things later on.
By using a dialog, you can even avoid slow startups - but also reload your code directly by closing the dialog and reloading all GUI stuff via the debug menu.
Much faster prototyping that way!
If your aircraft-specific code is implemented properly, you can simply include it via io.load_nasal()
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: On board Radar

Postby 5H1N0B1 » Thu Jan 30, 2014 10:57 pm

Ok. Lets try that way.
I'll begin this week end.(I hope)
Thanks for all dude.
5H1N0B1
"Each day, with every person you meet, there is something to learn"
5H1N0B1
 
Posts: 222
Joined: Thu Aug 30, 2012 10:36 am
Location: France
Callsign: 5H1N0B1
IRC name: _5H1N0B1
Version: GIT
OS: Ubuntu

Re: On board Radar

Postby Hooray » Thu Jan 30, 2014 11:11 pm

It should be pretty straightforward - I used the same method when I ported Gijs' NavDisplay code: I generalized everything, until it was no longer aircraft-specific, at that point, it didn't matter which aircraft I loaded - afterwards, I generalized things further, to ensure that I could load the same code inside a GUI dialog - at that point, any missing dependencies (classes/objects) could be included via io.load_nasal (or the new include directive added by galvedro). This may seem complicated and difficult at first, but it's actually pretty simple in a dynamic language like Nasal, because there's no real typing involved, and every namespace is just a hash.
And at that point, I could really edit/run/test the code easily, without having to quit/restart FG.

Once you prototype such things via a GUI dialog and an embedded Canvas/Nasal section, you can easily reload things from disk, while keeping FG running, and editing your code in TextPad or whatever IDE you use.

Basically, you'll want fixed boundaries and well-defined responsibilities for your modules - once that is working, you will have the added advantage, that your code can be more easily adopted by others doing similar things, or even on different aircraft - but also for scripted AI missiles: http://wiki.flightgear.org/Scripted_AI_Missiles
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: On board Radar

Postby 5H1N0B1 » Sat Feb 01, 2014 8:06 pm

Hi again :)
I started to make the job.
(Where the begining, just for info :http://pastebin.com/QRcgejVZ
The object being coded, and each task is separated in different function.
Using your tips allows me to reload nasal, without reloading fg so +1 for you :)...

Anyways, for now, the result of my code just give me a print in the console...
My question is the next :
In the code I took, this is :
Code: Select all
        foreach(var type; var layer_types = ['VOR',] )
                TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type);

So I still have the VOR displayed. How, with an arrray[] can I feed this Canvas to display (with same picture for begining) the plot spotted by the radar ?
For info this array will be an array of "Target" object.
Because I can continue to developp the radar thing, (no big deal -> the non object code is nearly done by XIII, just have to transorm it into an object) but I still can't see how make the link with the CANVAS...

Thanks in advance
5H1N0B1
"Each day, with every person you meet, there is something to learn"
5H1N0B1
 
Posts: 222
Joined: Thu Aug 30, 2012 10:36 am
Location: France
Callsign: 5H1N0B1
IRC name: _5H1N0B1
Version: GIT
OS: Ubuntu

Re: On board Radar

Postby Hooray » Sun Feb 02, 2014 12:44 am

5H1N0B1 wrote in Sat Feb 01, 2014 8:06 pm:The object being coded, and each task is separated in different function.
Using your tips allows me to reload nasal, without reloading fg so +1 for you :)...

Very good job!
BTW: Check out the menubar.xml flie to see how the GUI can be reloaded - you can copy the binding and add it a button inside the dialog, so that the GUI dialog will be automatically reloaded from disk - I used that to prototype the wizard dialog, without having to quit FG at all - you only need to take a "close/exit" button (XML markup), copy it to your new dialog, and add the binding to reload the GUI stuff from disk - that way, you can edit files on the fly

You only need to make sure to free your resources (listeners, timers and loops) in the UNLOAD block of the embedded Nasal section

5H1N0B1 wrote in Sat Feb 01, 2014 8:06 pm:In the code I took, this is :
Code: Select all
        foreach(var type; var layer_types = ['VOR',] )
                TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type);

So I still have the VOR displayed.

Is it working already ? If so, good job again! :-)

5H1N0B1 wrote in Sat Feb 01, 2014 8:06 pm:How, with an arrray[] can I feed this Canvas to display (with same picture for begining) the plot spotted by the radar ?
For info this array will be an array of "Target" object

See: http://wiki.flightgear.org/MapStructure ... new_Layers

It makes sense to use existing layers as templates, i.e. copy a set of files that is close to what you want to implement - e.g. a RADAR or ATC layer will typically involve processing AI/MP traffic - which is what the TCAS (TFC) layer is already doing - so it's a good idea to use that as a template for your new layer.
Using other layers like VOR, NDB or DME would also be possible - but think about what these represent: navaids, with fixed geographic coordinates, while an ATC/RADAR layer would be all about showing live traffic, so it would be less work to reuse and customize a similar layer.
Then again, using a complex layer to represent a simple thing would also be more work than necessary obviously.
Basically, this should get you going:
  • copy an existing set of files (better TFC instead of VOR), name it "TARGET" instead: TARGET.symbol, TARGET.lcontroller, TARGET.symbol
  • you need to change the name to TARGET inside the 3 new TARGET* files (see the top of the new files)
  • once that is done, use the new "TARGET" identifier in the vector above
  • this should give you a TCAS traffic (TFC) symbol using the TARGET handle when you run the dialog
  • once that is working, you can customize the symbol by opening the TARGET.symbol file which contains the draw routine - for example by changing the color or using some custom font, or just using a SVG file via parsesevg() - see the NDB.draw file for an example on how to display a custom SVG file
  • at this stage you should have a custom symbol rendered in all the places where MP/AI traffic is located
  • so the next step is to make the code a bit smarter, especially look at the TFC.lcontroller and TFC.scontroller files
  • it may even be a good idea to directly start with those, instead of the VOR files ...
  • once that is working, i.e. 1) you have a custom symbol shown and see all the surrounding MP/AI traffic, you have already successfully created a simple ATC/radar screen :D
  • next, you would replace the data source (which is AI/MP traffic) with your own data source - for that, refer to the TARGET (TFC) files to see how the AI/MP traffic is added
  • once you have added your own data source, you can change heuristics - to handle terrain, radar range etc.
  • your own objects should ideally be geo.nas Coord objects - that way, the system can directly support your traffic, you only need to derive from geo.Coord to make this happen:
    Code: Select all
    var myPosition3D = {
     new: func {
      return {parents:[geo.Coord................ ]};
     },
    };


Please also post some screen shots, so that we can better help you
It would be a good idea to also start a fgdata topic branch so that we can better track your work and look at the code.

.
Because I can continue to developp the radar thing, (no big deal -> the non object code is nearly done by XIII, just have to transorm it into an object) but I still can't see how make the link with the CANVAS...


This should get you going quickly, given all your Nasal experience, this should take you less than 20-30 minutes to work through, and you would end up with an ATC display and a custom symbol - next, you will want to "filter" traffic based on surrrounding features like terrain, altitude, radar settings and radio propagation etc.

If you find yourself getting stuck somewhere, look at some of the other .symbol/.lcontroller and .scontroller files - especially the shorter/simpler ones - and then read the wiki section about adding new layers a few times, and everything will start making sense
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: On board Radar

Postby Philosopher » Sun Feb 02, 2014 1:19 am

And I forgot to mention in the wiki that near the end of MapStructure.nas, in the loading code, there's a vector that contains the names to load, e.g. "VOR", "DME", and "TFC", and so you will need to add "TARGET" there as well.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Next

Return to Nasal

Who is online

Users browsing this forum: No registered users and 2 guests