fixed traffic cop steps and reflective calculations

This commit is contained in:
2026-05-31 21:26:27 -07:00
parent 353303c5c1
commit 56605547cc

View File

@@ -147,10 +147,11 @@ struct target_data_to_shader_structure {
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 reflectivity; // derivied from vessel_type (see table below)
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)
};
@@ -995,17 +996,16 @@ Here is the data items for the table in the Postgres database:
1. float length
2. float beam
3. int32_t material - 1 for metal, 2 for wood, 3 for fiberglass
4. int32_t may_need_update (this if a randome value is applied to any part of the target
3. int32_t may_need_update (this if a randome value is applied to any part of the target
and that the user may want to update the database. This
will not force the user to do the update, a later
database editing program will use this.
5. int vessel_type (AIS type code or aircraft type)
6. uint32_t mmsi (unique identification for boat or ICAL for aircraft
7. float reflectivity (derived from target type)
8. float height_estimate (derived from target type)
9. float noiseglint (derived from target type_
10. int32_t police_boat (this indicates that this is for the police boat - 1 is true)
4. int vessel_type (AIS type code or aircraft type)
5. uint32_t mmsi (unique identification for boat or ICAL for aircraft
6. float reflectivity (derived from target type)
7. float height_estimate (derived from target type)
8. float noiseglint (derived from target type_
9. int32_t police_boat (this indicates that this is for the police boat - 1 is true)
Please note that this database is only for the physical characteristics. Dynamic
information which is created by the simulator (or raspberry pis) as that data changes.
@@ -1037,13 +1037,13 @@ Thread 1 = Operation of setting up the system; ie; initializeing Opengl,
compiling, building, and loading all of the shaders. It also handles
the keyboard operation of the radar controls as those are callbacks from
the OpenGL. Accepting target traffic from the Traffic Cop will be performed,
however, the Traffic Cop will need to assert a mutex in order to write any
however, the Traffic Cop will need to assert mutex-target-data in order to write any
target data to this Thread 1.
Thread 2 = Traffic Cop. The Traffic Cop will accept Target Data from the Simulator (which
will be discussed here) ; and the AIS and ADS(b) data from the raspberry pis. At
this time, we need to provide only a stub withing the traffic cop to access the Raspberry pis.
The traffic cop will need to set a mutex before handing radar traffic to the Thread 1 software
The traffic cop will need to set a mutex-target-data before handing radar traffic to the Thread 1 software
which will send the radar data on to the shaders. Note that the traffic cop needs to do
the following processing with target data:
@@ -1053,16 +1053,17 @@ Thread 2 = Traffic Cop. The Traffic Cop will accept Target Data from the Simulat
3. Discard targets whose timestamp is older than 1 hour
Thread 3 = Simulator. The simulator creates and manages the simulated targets. It needs to
assert a mutex to transfer target information to the Traffic cop
assert mutex-simulator-to-traffic-cop to transfer target information to the Traffic cop
Thread 4 = Physical controls, knobs and switches. This has not been developed and will not
be developed with the current version of the project. It will be developed later. It
does need to set a mutex in order to send control information to Thread 1 so that thread
does need to set a mutex-control-data-to-shaders in order to send control
information to Thread 1 so that thread
can set the state variables and the uniforms for the controls in the shaders.
Thread 5 = Raspberry pi data recever = this receives the data from the raspberry pis. It will
not be developed for the current version of the project. The Raspberry PI receiver will
need to set a mutex in order to transfer target data to the traffic cop.
need to set mutex-raspberry-pi in order to transfer target data to the traffic cop.
================================================================================
@@ -1103,38 +1104,46 @@ struct target_data_to_shader_structure {
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 reflectivity; // derivied from vessel_type (see table below)
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)
time_t timestamp; // time of last fix; used to age out stale targets
uint32_t mmsi; // AIS unique identifier; ICAO hex address for aircraft
};
Target Processing suggestion:
1. Determing which radar is in operation
2. Receive target information from simulator or raspberry pi.
1. Determing which geographic area is in operation; bellingham bay, or Vetnor Isle of Wight
2. Receive target information from simulator or raspberry pi. Both these used the target_data_structure
3. Is target already in the memory table for the current radar in use
(memory-bellingham-bay for marine a-scope, marine traffic control ppi, and marine police boat)
(memory-ventnor for chain home)
3a: Yes, replace location, course, altitude, timestamp, police_boat into the memory table;
leave all other data alone
calculate current_reflectivity using the sample code below; leave all other data alone
3b: No, initialize new entry for memory data. Bring over location, course, altitude,
timestamp, police_boat
timestamp, police_boat; note that if we alredy have 300 entries; determine which
entry is the least used and replace that entry with the new one
3c: Is this target in the postgres data base?
3c1: no - Create database entry. Perform calculation for reflectivity as noted below
3b1: Is this target in the postgres data base?
3b1a: no - Create database entry. Perform calculation for reflectivity as noted below
based on vessel_type, length, type, and beam from the target data structure
from the simulator data or raspberry pi data; and then bring over lengh, beam,
altitude, police_boat from the target data structure
3c2: yes - bring over, from database, followng: location, length, beam, course, altitude,
timestamp, reflectivity, height_estimate, noiseglint, timestamea to the memory
table.
3. After all incoming targets processed, wait for next update cycle,
assert mutex, and pass the table to cpu thread 1 to pass onto the shaders.
altitude, police_boat from the target data structure, and bring over the heigh_estimate,
and noiseglind from the getMaterialProfile calculation above.
3b1b: yes - bring over, from database, followng: length, beam,
reflectivity, height_estimate, noiseglint, to the memory
table. This is for the new table created by step 3b.
3b1c: recalculate the current_reflectivity and insert into table; this is dynamic
4. After all incoming targets processed, wait for next update cycle,
assert mutex-target-data, and pass the table to cpu thread 1 to pass onto the shaders.
4. Update cycles shall be 1/25 seconds for chain home and 30 microseconds for the ppi
5. As we are updating, check for the target that is the police boat, if so, check to
see if the radar in use is for the police boat, then fill in unforms for heading and location
but don't send targets as active data tot he shader.
6. Update cycles shall be 1/25 seconds for chain home and 50 milleseconds for the ppi
scopes.
Suggested code for deriving target height, reflectivity, and noiseGlint when target is not
@@ -1193,9 +1202,9 @@ float dynamicReflectivity = baseReflectivity + (randomNoise * glintFactor);
// Clamp it so it doesn't drop below 0 or overshoot 1.0
dynamicReflectivity = std::max(0.0f, std::min(1.0f, dynamicReflectivity));
// Pass 'dynamicReflectivity' to your GLSL shader uniform array
glUniform1f(glGetUniformLocation(shaderProgram, "targetReflectivity[i]"), dynamicReflectivity);
but is not written to the database. It is to be passed to the shaders as a uniform.
// Enter the baseReflectivity into the database entry for the target as reflectivity
// Enter the dynamicReflectivity int the target memory table as current_reflectivity
note that this is to be calculated for each update. It is dynamic unlike reflectivity