The sensor information derived from GroundTruth and processed by sensor-models. More...

Detailed Description

The sensor information derived from GroundTruth and processed by sensor-models.

The sensor information is supposed to imitate the output of real sensors. All information regarding the environment is given with respect to the virtual sensor coordinate system specified in SensorData::mounting_position, except for feature data, which is given with respect to the physical sensor coordinate system specified in the corresponding physical sensor's coordinate system.

When simulating multiple distinct sensors, each sensor can produce an individual copy of the SensorData interface. This allows an independent treatment of the sensors.

Sensor fusion models can consolidate multiple SensorData interfaces into one consolidated SensorData interface. This can happen either in seperate logical models, consuming and producing SensorData interfaces, or it can happen as part of a combined sensor/logical model, that consumes SensorView interfaces and directly produces one consolidated SensorData output.

Requirements

Field	Type	Repeated	Requirements
version	`InterfaceVersion`	No	Must be set and valid
timestamp	`Timestamp`	No	Must be set and valid
host_vehicle_location	`BaseMoving`	No	Must be set and valid
host_vehicle_location_rmse	`BaseMoving`	No	Must be set and valid
sensor_id	`Identifier`	No	Must correspond to the id of a virtual sensor
mounting_position	`MountingPosition`	No	Must be set and valid
mounting_position_rmse	`MountingPosition`	No	Must be set and valid
sensor_view	`SensorView`	Yes	Must be set and valid
last_measurement_time	`Timestamp`	No	Must be set and valid
stationary_object_header	`DetectedEntityHeader`	No	Must be set and valid
stationary_object	`DetectedStationaryObject`	Yes	Must be set and valid
moving_object_header	`DetectedEntityHeader`	No	Must be set and valid
moving_object	`DetectedMovingObject`	Yes	Must be set and valid
traffic_sign_header	`DetectedEntityHeader`	No	Must be set and valid
traffic_sign	`DetectedTrafficSign`	Yes	Must be set and valid
traffic_light_header	`DetectedEntityHeader`	No	Must be set and valid
traffic_light	`DetectedTrafficLight`	Yes	Must be set and valid
road_marking_header	`DetectedEntityHeader`	No	Must be set and valid
road_marking	`DetectedRoadMarking`	Yes	Must be set and valid
lane_boundary_header	`DetectedEntityHeader`	No	Must be set and valid
lane_boundary	`DetectedLaneBoundary`	Yes	Must be set and valid
lane_header	`DetectedEntityHeader`	No	Must be set and valid
lane	`DetectedLane`	Yes	Must be set and valid
occupant_header	`DetectedEntityHeader`	No	Must be set and valid
occupant	`DetectedOccupant`	Yes	Must be set and valid
feature_data	`FeatureData`	No	Must be set and valid

Details on timestamp

The timestamp of the sensor data. Zero time is arbitrary but must be identical for all messages. Zero time does not need to coincide with the unix epoch. Recommended is the starting time point of the simulation.

Note: This is the point in time that the sensor data message becomes available to the rest of the system (i.e. the driving functions), so it corresponds with the sending time and thus takes the latency of internal processing of the sensor into account. Latencies of bus communications, etc., that occur after the sensor output have to be applied on top of this, if needed.

The time that the actual measurement was performed (which will usually correspond with the timestamp of the GroundTruth the sensor model processed to arrive at these results) can be found in the additional field SensorData::last_measurement_time.

For an ideal zero latency sensor the two timestamps would be the same and would correspond with the timestamp from the current GroundTruth message.

For a sensor model that does not know its own internal latencies (e.g. a dumb sensor with no internal time concept), the two timestamps might also be identical, but delayed from the GroundTruth timestamp.

Details on mounting_position

The virtual mounting position of the sensor (origin and orientation of the sensor coordinate system) given in vehicle coordinates [1]. The virtual position pertains to the sensor as a whole, regardless of the actual position of individual physical detectors, and governs the sensor-relative coordinates in detected objects of the sensor as a whole. Individual features detected by individual physical detectors are governed by the actual physical mounting positions of the detectors, as indicated in the technology-specific sub-views and sub-view configurations.

x-direction of sensor coordinate system: sensor viewing direction
z-direction of sensor coordinate system: sensor (up)
y-direction of sensor coordinate system: perpendicular to x and z right hand system

References:

[1] DIN ISO 8855:2013-11

Note: This field is usually static during the simulation.; The origin of vehicle's coordinate system in world frame is ( MovingObject::base . BaseMoving::position + Inverse_Rotation_yaw_pitch_roll( MovingObject::base . BaseMoving::orientation) * MovingObject::VehicleAttributes::bbcenter_to_rear) . The orientation of the vehicle's coordinate system is equal to the orientation of the vehicle's bounding box MovingObject::base . BaseMoving::orientation.

Details on last_measurement_time

The timestamp of the last real-world measurement (e.g. GT input) that this set of sensor data takes into account. This in effect is the last time instance of reality the measurements correspond to. See field SensorData::timestamp for a detailed discussion. This value is also the upper bound to the DetectedEntityHeader::measurement_time and the feature data SensorDetectionHeader::measurement_time fields.