Update Sensor Configuration File

[paulbourelly999]

PR Details

Description

The changes recommended in this PR are to modify the Sensor Configuration file to be able to provide either a cartesian offset or a WGS84 location based on a type enumeration. The new format of the sensor configuration file is described below

Note

Sensor reference or "ref" can either be defined as a "CARTESIAN" offset from a provided lanelet2 osm map (first example) or a "WGS84" location (second example). The "CARTESIAN" offset is only recommended for simulation testing as it adds a dependency on a lanelet2 map. For real-world deployments it is recommended that the "WGS84" location is provided.

CARTESIAN(SIMULATION):

[
  {
    "sensorId": "sensor_1",
    "type": "SemanticLidar",
    "ref": {
      "type": "CARTESIAN",
      "location": {
        "x": 1.0, /* in meters */
        "y": 2.0, /* in meters */
        "z": -3.2 /* in meters */
      },
       "orientation": { 
        "yaw": 0.0,
        "pitch": 0.0,
        "roll": 0.0
        }
    }
  } 
]

The orientation information provided here is not used by the Sensor Data Sharing Service, but it used by other parts for the CARMA Streets system (V2X-Hub/CDASimAdapterPlugin) in simulation to provide orientation information for spawning a requested sensor.

or

WGS84(REAL-WORLD):

[
  {
    "sensorId": "sensor_1",
    "type": "SemanticLidar",
    "ref": {
      "type": "WGS84",
      "location": {
        "latitude": 38.9549716548523, /* in degrees */
        "longitude": -77.14935313519123, /* in degrees */
        "altitude": 5.5 /* in meters */
      }
    }
  } 
]

I opted to use WGS84 coordinates since we do not need the orientation or offsets included in a geo refence projection string in real world deployment. The detection data has a assumed ENU coordinate frame so all we need is the reference sensor location from which this detection data is measured.

Warning

The changes to the Sensor Configuration file format do break some of the existing CARMA-Streets/Simulation integration. An additional PR will be introduced into CDASim to account for the format difference in the Sensor Configuration information

Related GitHub Issue

Related Jira Key

FCP-37

Motivation and Context

Currently the Sensor Data Sharing Services reads geo-reference information from lanelet2 osm map and then reads cartesian position for a sensor from the sensor configuration file to generate an SDSM WSG84 reference location.
Example Geo reference string included in lanelet2 osm map

+proj=tmerc +lat_0=0 +lon_0=0 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +geoidgrids=egm96_15.gtx +vunits=m +no_defs 

Example Sensor Config

[
  {
    "sensorId": "sensor_1",
    "type": "SemanticLidar",
    "location": {
      "x": 1.0,
      "y": 2.0,
      "z": -3.2
     },
     "orientation": {
       "yaw": 0.0,
       "pitch": 0.0,
       "roll": 0.0
      }
  } 
]

Geo reference + sensor config cartesian offset = sdsm reference location

This is a problem because it unnecessarily introduces a dependency on an lanlet2 OSM map for SDSM functionality. It is also not practical to attempt to configure a real-world sensor based on a cartesian offset in a lanelet2 map. This implementation was created because conversely it is not practical to generate a sensor in simulation with WGS 84 coordinate location since many simulation environments do not have real world counter parts.
As a result we offer two different ways to configure sensor's in simulation and for real world outlined above. This removes unnecessary dependency on a lanelet2 osm map for real world sensors, while still allowing easy configuration of sensor in simulation.

How Has This Been Tested?

Current testing is limited to unit testing. It is recommended that this change set is integration tested #426 PR is closed.

Types of changes

• Defect fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that cause existing functionality to change)

Checklist:

• I have added any new packages to the sonar-scanner.properties file
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[sonarcloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
60.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud