osi3::SensorData Struct Reference

The interface version used by the sender.

Rules

is_set

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.

Rules

is_set

The sensors estimated location of the host vehicle.

Note

This value is only set by sensors that are able to provide an own estimation of the host vehicle location.

Note that dimension and base_polygon need not be set.

The parent frame of host_vehicle_location is the sensor frame.

The sensors estimated location error of the host vehicle.

Note

This value is only set by sensors that are able to provide an own estimation of the host vehicle location.

Note that dimension and base_polygon need not be set.

The parent frame of host_vehicle_location_rmse is the sensor frame.

The ID of the sensor at host vehicle's mounting_position.

This is the ID of the virtual sensor, to be used in its detected object output; it is distinct from the IDs of its physical detectors, which are used in the detected features.

Rules

is_set

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

Reference:

[1] DIN Deutsches Institut fuer Normung e. V. (2013). DIN ISO 8855 Strassenfahrzeuge - Fahrzeugdynamik und Fahrverhalten - Begriffe. (DIN ISO 8855:2013-11). Berlin, Germany.

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.

Rules

is_set

The root mean squared error of the mounting position.

Sensor view w.r.t.

the sensor coordinate system

This provides a copy of the SensorView data received by the sensor for reference purposes. For complex sensors or logic models this can be multiple copies.

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.

General information about the DetectedStationaryObject .

The list of stationary objects (e.g.

landmarks) detected by the sensor.

General information about the DetectedMovingObject .

The list of moving objects detected by the sensor as perceived by the sensor.

General information about the DetectedTrafficSign .

The list of traffic signs detected by the sensor.

General information about the DetectedTrafficLight .

The list of traffic lights detected by the sensor.

General information about the DetectedRoadMarking .

The list of road markings detected by the sensor.

This excludes lane boundary markings.

General information about the DetectedLaneBoundary .

The list of lane boundary markings detected by the sensor.

General information about the DetectedLane .

The list of lanes detected by the sensor.

General information about the DetectedOccupant .

The list of occupants of the host vehicle.

Low level feature data interface.

Low Level feature data is optionally provided by sensor models that model sensors giving access to this low level data, i.e. data prior to object hypothesis and tracking.

Logical detection data interface.

Logical detection data are provided by a transformation (and optional sensor fusion) performed by a sensor model or a logical model that fuses multiple sensors and/or sensor types into a single reference frame of the so called logical/virtual sensor. Therefore, all information is given with respect to the reference frame of the logical/virtual sensor SensorView::mounting_position (e.g. center of rear axle of the ego car) in cartesian coordinates.

Virtual detection area of the sensor.

The system time of the modeled source of the sensor data, given in UTC (Unix Epoch timestamp).

The system time can be used to transmit the internal time of the simulated component that supplies the sensor data, which might not coincide with the simulation time as transmitted in the timestamp field. Example use cases include recorded data traces or the simulation of time synchronization mechanisms and errors.