osi3::TrafficUpdate Struct Reference
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