Skip to content

Commit 42ba6da

Browse files
Nader ThomasThomasNaderBMW
authored andcommitted
Edited trafficupdate.proto
Signed-off-by: Nader Thomas <a442105@europe.bmw.corp>
1 parent 63ef7a1 commit 42ba6da

File tree

1 file changed

+58
-0
lines changed

1 file changed

+58
-0
lines changed

osi_trafficupdate.proto.orig

Lines changed: 58 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,58 @@
1+
syntax = "proto2";
2+
3+
option optimize_for = SPEED;
4+
5+
import "osi_version.proto";
6+
import "osi_common.proto";
7+
import "osi_object.proto";
8+
9+
package osi3;
10+
11+
//
12+
// \brief The traffic update message is provided by traffic
13+
// participant models to provide updates to their position, state
14+
// and future trajectory back to the simulation environment.
15+
//
16+
// \note For reasons of convenience and consistency, the
17+
// updated information is provided as a MovingObject. Certain fields
18+
// of this sub-message are not required to be set and will be ignored by the
19+
// simulation environment, because they are static information.
20+
// Instead of creating a seperate message type for only the non-static
21+
// information, re-use existing message.
22+
//
23+
message TrafficUpdate
24+
{
25+
// The interface version used by the sender (traffic participant model).
26+
//
27+
optional InterfaceVersion version = 1;
28+
29+
// The data timestamp of the simulation environment. Zero time is arbitrary
30+
// but must be identical for all messages. Zero time does not need to
31+
// coincide with the UNIX epoch. Recommended is the starting time point of
32+
// the simulation.
33+
//
34+
// \note For moving object update data the timestamp coincides both with
35+
// the notional simulation time the data applies to and the time it was sent.
36+
// There is no inherent latency for moving object update data, as opposed
37+
// to sensor data.
38+
//
39+
optional Timestamp timestamp = 2;
40+
41+
// Updated traffic participant data
42+
//
43+
// \note It is not expected that static fields are populated. If they
44+
// are, they may be ignored by the receiver of this message, for example, dimensions,
45+
// or vehicle category. All dynamic fields should be populated where known,
46+
// for example, velocity, light states, or future trajectory.
47+
//
48+
<<<<<<< HEAD
49+
repeated MovingObject update = 3;
50+
=======
51+
optional MovingObject update = 3;
52+
53+
// Updated host vehicle data
54+
//
55+
optional HostVehicleData host_vehicle_data_update = 4;
56+
57+
>>>>>>> Edited trafficupdate.proto
58+
}

0 commit comments

Comments
 (0)