maallyn/modular-radar
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add more information about traffic_cop and add .md suffix to the classes file

Browse Source
This commit is contained in:
Mark Allyn
2026-06-15 21:16:26 -07:00
parent d0616ac523
commit 318591998b
3 changed files with 175 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files

168
01_classes.md Normal file
View File

@@ -0,0 +1,168 @@
This components discusses the c++ classes suggested for this project.
======================================================================
The radar class
This pertains to the radars, including controls, shaders, target data, text description,
and status text.
This class shall consist of both a base class and subordinate classes for each radar.
The functions in this class shall be performed in thread 1 as they will directly
interact with the shaders and the keyboard, which are all in thread 1.
Examples of data and functions for this class and it subordinates:
1. Shaders - functions that can be called by the initialization function that will compile,
link, and load the shaders for each radar. The subordinates for each radar would have
the specific shaders that are used for that radar. If a shader is to be used by more than
one radar, that shader should be compiled, linked, and loaded by the base class before the
shader loading functions for each of the subordinate classes' shader loading functions.
Initially, I will have separate shaders for each radar to facilitate debugging and then
(maybe) later, work on combining them.
2. Left hand panel text. Functions that display the description for each radar on the left hand
panel. In addition, the control names and Keyboard Keys shall be displayed at the bottom
of the left hand panel. Please note that in the future, this left hand panel may be moved
to a second physical monitor.
3. Text status panel to be located below the radar scope panel. This will display the current
control settings for the controls and the range and bearing and description of
targets that are on or near the bearing and range cursor. The text status panel shall manage
the hit-test. The hit test shall determine which (if any) targets are either directly the same
rand and the same bearing as the cursor or close to it. The closeness shall be determined
by a configuration variable. Since the cursor information as well as the target information
is already in thread 1, this operatoin shall be performed by the CPU as the CPU will have
all information on the target, including the name and description.
Please note that any text (such as the vessel name and registration will not be part
of the SSBO target information. It will need to be formed in text blocks that can
be submitted as textures to be inserted into the status text panel below the scope
panel.
4. Target data. This will handle the target data that is presented by both the simulator
and the raspberry pi data. All that data will be in the format of the
struct target_data_to_thread_1_structure. The expectation is that the target's local
cartesian offsets in meters relative to the radar. Note that this will be different
for each radar and will dynamically change based on the police boat's radar position.
I am expecting that the target data input functions may be common for all target data
will all be the same for all radars and could be handled by the base class.
Note that there will be a difference in handling the target data that is exclusive
for the police boat will be the police boat's location and heading. This affects the
radar display for the police boat. Perhaps I can suggest that the these three values
should be furnished as uniforms to the shaders for the police boat: 1. int police_boat;
1 is police boat and 0 is not, 2. flost police_location; in local coordinate space,
and 3. float police_boat heading.
Please note that this is running in thread 1. The data input to this is being
provided by the traffic_cop, which is running on thread 2. The traffic_cop needs
to assert the mutex-target-data before writing any target data to here.
Please note that the target data that is used by the shaders does not include
the target name nor target registration (text fields). The followoing
data structure is to be used:
ssbo_target_information { // This is what is sent to the shaders as SSBO
float target_x; // Pre-converted local Cartesian offset X (meters relative to radar)
float target_y; // Pre-converted local Cartesian offset Y (meters relative to radar)
float length; // Vessel length bounds (meters)
float beam; // Vessel beam bounds (meters)
float course; // Course over ground vector (radians relative to True North)
float altitude; // Target altitude profile (meters = 0 for boats)
time_t timestamp; // Data aging tracking identifier
float current_reflectivity; // derivied from vessel_type (see table below)
float height_estimate; // derived from vessel_type (see table below)
float noiseglint; // derived from vessel_type (see table below)
int32_t police_boat; // this indicates that the target is for the roaming
// police boat. 1 = police boat
uint32_t mmsi; // AIS unique identifier; ICAO hex address for aircraft
int type; // target type (0 for boat 1 for aircraft)
};
5. Graticule. This is the same for both chain home and marine-ascope. It
is also the same for marine_traffic and police boat.
6. North indicator for the police boat. Not used anywhere else. It is a second
graticule that rotates when the police boat changes direction.
7. Range Rings and Distance Calibration. For a-scope, small 'ticks' are inserted
by a crystal oscillator to indicate distances. For a ppi scope, they are rings
generated by the sweep to indicated ranges. I suggest two base class members
that are used by either the chain hoome/marine ascope which use range ticks or the
marine traffic/police boat radar which use range rings.
8. Update. This is run once every 30th of a second. I will call everything on this list
to perform an update with the shaders. The order would be, Target data, graticle,
range rings/range ticks (depending on what radar is being used), police boat north
indicator, left hand panel, and text status penel. Perhaps some of these that
have not changed such as the left panel text may not need to be updated.
===============================================================================
The Keyboard controls class
The keyboard controls class (which runs in thread 1) is activated whenever anyone
presses a key on the keyboard. It's functon is to recognize the keystrokes used
for controls and then set the global CPU variables and the uniforms within the
shaders. It will affect only those variables pertaining to the radar that is currently
being used. Any other keystrokes will be ignored except for key 1, which will return
the system to the radar selection stage
The physical control panel class.
The physical control panel class will be constructed later after hardware selection.
It will run on Thread 6 and needs to assert the mutex-to-pass-controls-to-thread-1
mutex before changing any global variables for controls.
===============================================================================
The Traffic Cop class
This class is for the traffic_cop which accepts data from the simulator or the
raspberry pis. It will change the GPS coordinates to the coordinates for whichever
radar is being used before it sends the radar information to Thread 1. It will need
to assert the mutex-target-data mutext before sending data to thread 1.
The data structure that will be received by the traffic_cop is the following
structure:
struct target_data_structure {
double target_longitude;
double target_latitude;
std::string vessel_name; // will be null for no available name
std::string registration; // will be null for no registration
float length; // in meters
float beam; // in meters
int vessel_type; // AIS type code or aircraft type
uint32_t mmsi; // AIS unique identifier; ICAO hex address for aircraft
float course; // course over ground, degrees, based on true north
float speed; // speed over ground, knots
float altitude; // meters, but 0 for boats
int type; // type of target; vessel or aircraft; 0 = vessel
int police_boat // 1 is police boat; 0 is not
time_t timestamp;
};
The data structure that is sent by the traffic cop to thread one (the target data in
the radar class):
struct target_data_to_thread_1_structure {
float target_x; // Pre-converted local Cartesian offset X (meters relative to radar)
float target_y; // Pre-converted local Cartesian offset Y (meters relative to radar)
std::string vessel_name; // will be null for no available name
std::string registration; // will be null for no registration
float length; // Vessel length bounds (meters)
float beam; // Vessel beam bounds (meters)
float course; // Course over ground vector (radians relative to True North)
float altitude; // Target altitude profile (meters = 0 for boats)
time_t timestamp; // Data aging tracking identifier
float current_reflectivity; // derived from calculation based on material - is dynamic
float height_estimate; // derived from vessel_type (see table below)
float noiseglint; // derived from vessel_type (see table below)
int32_t police_boat; // this indicates that the target is for the roaming police boat. 1 = police boat
int type; // target type (0 for boat 1 for aircraft)
uint32_t mmsi; // AIS unique identifier; ICAO hex address for aircraft
};