From 318591998be388ad1dadac375fda88fca4937095 Mon Sep 17 00:00:00 2001 From: Mark Allyn Date: Mon, 15 Jun 2026 21:16:26 -0700 Subject: [PATCH] Add more information about traffic_cop and add .md suffix to the classes file --- 01_classes | 52 ---------------- 01_classes.md | 168 ++++++++++++++++++++++++++++++++++++++++++++++++++ CLAUDE.md | 7 +++ 3 files changed, 175 insertions(+), 52 deletions(-) delete mode 100644 01_classes create mode 100644 01_classes.md diff --git a/01_classes b/01_classes deleted file mode 100644 index 9df9c97..0000000 --- a/01_classes +++ /dev/null @@ -1,52 +0,0 @@ -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. - -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. - -5. Run. This should be handled by only as a base class. It is triggered every 30th of a - second to tell the shaders to execute. diff --git a/01_classes.md b/01_classes.md new file mode 100644 index 0000000..e5d6e57 --- /dev/null +++ b/01_classes.md @@ -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 +}; + diff --git a/CLAUDE.md b/CLAUDE.md index a43d350..9cc31fe 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -384,6 +384,13 @@ Thread 5 = Raspberry pi data recever = this receives the data from the raspberry not be developed for the current version of the project. The Raspberry PI receiver will need to set mutex-raspberry-pi in order to transfer target data to the traffic cop. +Thread 6 = Physical control panel (to be defined later) + This will handle control operations from the physical control panel. It will need + to make appropriate changes to the CPU globals and the uniforms in the shades, + similar to the Keyboard controls. However, since this thread 6, it will need + to assert the mutex-to-pass-controls-to-thread-1 mutex before sending + values to thread 1. + ================================================================================