fixed traffic cop steps and reflective calculations
This commit is contained in:
73
CLAUDE.md
73
CLAUDE.md
@@ -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
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user