Canvas Radar

From FlightGear wiki
Revision as of 10:55, 24 February 2014 by 5H1N0B1 (talk | contribs) (→‎Objective)
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.
This article describes content/features that may not yet be available in the latest stable version of FlightGear (2020.3).
You may need to install some extra components, use the latest development (Git) version or even rebuild FlightGear from source, possibly from a custom topic branch using special build settings: .

This feature is scheduled for FlightGear (unknown). 10}% completed

If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear.

Canvas Radar Framework
MapStructure-TFC-Troubleshooting.png
Started in 02/2014
Description Radar Framework
Maintainer(s) 5H1N0B1, Hooray
Contributor(s) 5H1N0B1 (since 02/2014),
Status Under active development as of 02/2014
Topic branches:
fgdata canvas-hackers team clone (topics/canvas-radar)
Subforum http://forum.flightgear.org/viewforum.php?f=71


Canvas Radar is a MapStructure-based Nasal-space Canvas-Framework for creating Radar displays in FlightGear, as of 02/2014 it is being actively developed by 5H1N0B1 with a focus on the Mirage 2000-5 fighter jet. The Radar implementation is heavily based on xiii's original code and will be further generalized and adapted to be usable in the MVC-centric design of Philosopher's MapStructure framework.

The Radar framework is being closely developed in conjunction with F-JYL's CanvasMFD framework to ensure that aircraft developers can easily adopt the framework in their own aircraft, without having to modify a ton of Nasal code.

Note  Contributors wanting to check out the topics/canvas-radar fgdata branch, need to follow these 3 steps:
  • git remote add canvas-hackers git@gitorious.org:fg/canvas-hackers-fgdata.git
  • git fetch canvas-hackers
  • git checkout --track -b canvas-radar canvas-hackers/topics/canvas-radar

This will give you a local branch named canvas-radar, so that you can easily pull/push changes. When pulling, it makes sense to pull with --rebase



Objective

Come up with a generic radar framework for MapStructure that is completely aircraft-agnostic, so that it can be easily adopted, integrated and customized by aircraft developers, but also by people doing ATC related projects, like ATC-FS or ATC-aircraft.

Currently, we're in touch with Adrian to see if his Radio Propagation could be rebased against git/next and exposed via Nasal/CppBind to provide a better option for radar modeling. This is something that we should probably discuss with xiii (developer of the original Nasal code) and vivian (agradar developer) at some point, vivian also expressed interest in updating the agradar to support the Radio Propagation code written by Adrian[1].

Also, i4dnf mentioned that we could benefit from making antenna profiles configurable for different aircraft. Adrian mentioned that he has access to the radar manual of the F16 and that he's familiar with the various operating modes.

The Flightgear Next Gen Radar would be able to (not sorted) :

  1. Be a lot faster as actual system (Using Canvas display and some C++ for high consuming function)
  2. Detect Heat/infrared
  3. Manage AESA radar. (Actually it's more complicated to manage non AESA radar -> cause of the sweep. -> No sweep for AESA)
  4. Manage DOPPLER radar DOPPLER (Actually, more complicated to manage "non doppler" radar. The purpose is to erase signature of airplane which are bellow us, and fly at low alt. We could even erase 0 kts aircraft -> The Pougatchev's Cobra should be able to make stall DOPPLER radar)
  5. BONUS : Terrain detection. Make an aircraft disapear if it's behind a mountain
  6. With the terrain detection : Allow to have a fast Terrain Following Mode
  7. Make it working with existing Radio Propagation code.
  8. Manage IFF/Transponder
  9. Display Radar on Nav Mfd
  10. Allow more than one radar on a plane, like AWACS or Russian aircraft which have a rear radar
  11. Manage laser targeting -> with a pod view and clicking (for non AI target like building)
  12. Allow simple re use of the radar on each aircraft military and also civilian
  13. Long term obj : Put a radar object in "each" missile on the missile.nas script
  14. More ?

Status

Currently, we're playing around with a modified version of the MapStructure TFC (traffic) layer, to use this in a standalone XML dialog and customize it as needed. Once that is working as expected, we will investigate adding xiii's radar modeling code and replace the traffic/TCAS functionality accordingly. Afterwards, we will need to integrate this with the Canvas MFD Framework to ensure that aircraft developers can easily use the framework in their cockpits.

At that point, it would then also make sense to check out the Category:Fighter aircraft and Category:Carrier-based aircraft categories to get in touch with the developers and maintainers of aircraft with RADAR, and ask them for adoption/integration feedback.

Subsequently, it would make sense to look at existing hard-coded displays, like the agradar, groundradar and wxradar to support these use-cases, too. Specifically, ATC-FS and ATC-aircraft could greatly benefit from this effort.

5H1N0B1 also mentioned that a properly-designed component would allow other uses, too - such as for example, equipping Scripted AI Missiles with a real RADAR, or adding radar support to Bombable - likewise, it would be possible to add such radar displays to AWACS aircraft, or even to vessels like the Nimitz.

Radar/ATC Requirements

These are primarily requirements for the Mirage2000 that is currently being revamped by 5H1N0B1[2], these changes could also be used to add ATC support to AWACS aircraft[3].

  • Set up a dialog-based test bed Done Done
  • Prototype a simple ATC/RADAR layer 40}% completed
  • Terrain layer (elevation height maps using the terrain presampler) see: [4] and [5] Not done Not done (by 5H1N0B1)
  • Custom Controllers for:
    • azimuth-based filtering Not done Not done (by 5H1N0B1)
    • sweep mode (AESA) Not done Not done (by 5H1N0B1)
    • terrain awareness (filtering) Not done Not done (by 5H1N0B1)
    • heat detection based filtering Not done Not done (by 5H1N0B1)
  • select and animate symbols (targets) Not done Not done (by 5H1N0B1)
  • TCAS/transponder awareness for symbol animation/styling Not done Not done (by 5H1N0B1)
  • explore integrating this with Adrian's Radio propagation system via cppbind (Hooray) Not done Not done


Also see ATC-FS and ATC-aircraft

Development

Creating a custom ATC/RADAR Layer

People already having some Nasal experience (property tree, OOP), should be able to complete this 20-30 minutes, 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

Basically, this should get you going quickly:

  • copy an existing set of files (better TFC* instead of VOR*), but name it "TARGET" instead of TFC: TARGET.symbol, TARGET.lcontroller, TARGET.symbol (RADAR may be a more appropriate name)
  • you need to change the name to TARGET inside the 3 new TARGET* files (see the top of the new files, where 'TFC' can be seen)
    • start by opening TARGET.scontroller and replace TFC with TARGET
    • next, open TARGET.symbol - this contains the draw() and update() callbacks to draw/update a single symbol and animate it accordingly, also replace TFC with TARGET
    • next, open TARGET.lcontroller - this contains the layer management code, a layer manages a vector of symbols, replace TFC with TARGET
  • now, add the new files to MapStructure.nas: 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. This is to tell the framework about your newly created layer files.
  • once that is done, use the new "TARGET" identifier in the foreach vector in the Nasal section of the dialog seen above and its embedded canvas/nasal/load block
  • this should give you a TCAS traffic (TFC) symbol using the TARGET handle when you run the dialog

(5H1N0B1 : I'm here)

  • 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/label, 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, all driven via the TCAS function.
  • 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!
  • 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 the heuristics accordingly - 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:
var myPosition3D = {
 new: func {
  return {parents:[geo.Coord.new() ]};
 },
};

Next, you will want to investigate the positionedSearch class, which provides a powerful means to do range-based filtering of positioned objects, these can in turn be filtered (searched) for other characteristics, i.e. based on range, terrain, radio propagation or heat etc. Take a look at TARGET.lcontroller and its searchCmd() helper.

If you need help doing this, please check out the canvas subforum, and 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.

Custom Filtering

Once the previously outlined steps are working, I would consider customizing the searchCmd in your lcontroller file. At the moment, TFC.lcontoller works like this https://gitorious.org/fg/fgdata/source/c78b2f936891bffad49e27d84d952a0d45540eef:Nasal/canvas/map/TFC.lcontroller#

The line where I added PLACEHOLDER is where you could insert your own logic, i.e. the radar-specific stuff from xiii's code - such as checking distance, azimuth, altitude - radar profile/signature, terrain etc - and only append the aircraft if the whole check evaluates to true.

You will find that the whole lcontroller file uses a wrapper called "TrafficModel" - you can either extend this to use your "Target" class directly, or change your Target class accordingly. The main thing is that your class should be derived from a geo.Coord object, so that it has the lat/lon/alt methods available and can be directly processed by MapStructure without requiring further changes.

You will see that the TrafficModel class is used in a few places - so this would need some changes if you use some different approach, but it's still simple. The external interface is all about having lat/lon/alt (positions) and the .equals() method Overall, TrafficModel is just a dumb helper class that is a wrapper for geo.Coord() objects, so there's no reason why you shouldn't be able to extend your own Target class accordingly, you can use the TrafficModel as a template. I would just suggest to maintain the MVC separation at all times.

Analogous to the in_range() helper, you could add other functions for your own filtering needs (altitude, terrain-obstruction etc) - it's better to use separate functions for each, than inflating a single function unnecessarily. As you can see, the in_range() function is unaware of TrafficModel specifics -it deals directly with lat/lon pairs..

So it's simple to reuse as is. TrafficModel itself is typically directly used via the constructor call: .new()

Design