osi3::TrafficUpdate Struct Reference

The traffic update message is provided by traffic participant models to provide updates to their position, state and future trajectory back to the simulation environment. More...

Collaboration diagram for osi3::TrafficUpdate:

Public Attributes

optional InterfaceVersion version = 1
 The interface version used by the sender (traffic participant model). More...
 
optional Timestamp timestamp = 2
 The data timestamp of the simulation environment. More...
 
repeated MovingObject update = 3
 Updated traffic participant data. More...
 
repeated HostVehicleData internal_state = 4
 Internal state for each vehicle. More...
 

Detailed Description

The traffic update message is provided by traffic participant models to provide updates to their position, state and future trajectory back to the simulation environment.

The message is designed to update data of exactly one traffic participant, optionally with an attached trailer.

Note
For reasons of convenience and consistency, the updated information is provided as a MovingObject. Certain fields of this sub-message are not required to be set and will be ignored by the simulation environment, because they are static information. Instead of creating a separate message type for only the non-static information, re-use existing message.

Member Data Documentation

◆ version

optional InterfaceVersion osi3::TrafficUpdate::version = 1

The interface version used by the sender (traffic participant model).

Rules
is_set

◆ timestamp

optional Timestamp osi3::TrafficUpdate::timestamp = 2

The data timestamp of the simulation environment.

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
For moving object update data the timestamp coincides both with the notional simulation time the data applies to and the time it was sent. There is no inherent latency for moving object update data, as opposed to sensor data.
Rules
is_set

◆ update

repeated MovingObject osi3::TrafficUpdate::update = 3

Updated traffic participant data.

Note
It is not expected that static fields are populated. If they are, they may be ignored by the receiver of this message, for example, dimensions, or vehicle category. All dynamic fields should be populated where known, for example, velocity, light states, or future trajectory.
The field is repeated because it is possible to have a trailer attached to a vehicle, see MovingObject::VehicleClassification::has_trailer and MovingObject::VehicleClassification::trailer_id.

◆ internal_state

repeated HostVehicleData osi3::TrafficUpdate::internal_state = 4

Internal state for each vehicle.

This is an optional field as internal state may not be known or relevant, for example, a trailer might not have any internal state. It is also allowed to only specify internal_state for a subset of the objects referenced in the update.

Note
This covers any information which cannot be externally perceived and therefore cannot be included in messages available in ground truth.
The id field from this should match the id in the update field above where the same vehicle is being referenced.

  • osi_trafficupdate.proto