Merge pull request #401 from OpenSimulationInterface/WP-10-traffic-update-proposal

Add future trajectory to MovingObject

Author: pmai

osi_common.proto

@@ -461,3 +461,33 @@ message BaseMoving
     //
     repeated Vector2d base_polygon = 7;
 }
+
+//
+// \brief The StatePoint definition
+//
+// A reference to a time and pose.  Typically used in a repeated field to define
+// a trajectory.
+//
+// \note The StatePoint definition does not define mandatory fields.
+// The context defines how and what fields are used.  For example, in some cases
+// only the pose variables are relevant and the timestamp is ignored.
+//
+message StatePoint
+{
+    // The timestamp of a StatePoint.
+    //
+    // \note Zero time does not need to coincide with the UNIX epoch.
+    //
+    optional Timestamp timestamp = 1;
+
+    // Position in the global coordinate system.
+    //
+    // \note Remark: The definition of the reference point follows the
+    // specification of the \c BaseMoving message.
+    //
+    optional Vector3d position = 2;
+
+    // Orientation in the global coordinate system.
+    //
+    optional Orientation3d orientation = 3;
+}

osi_object.proto

@@ -338,6 +338,18 @@ message MovingObject
     //
     optional string model_reference = 7;
 
+    // The trajectory that this moving object expects to follow in the future.
+    //
+    // This is not externally perceivable information, rather this is to aid
+    // realistic simulation of traffic participants that are not under test.  
+    // This information should not be made available to the stack under test.
+    //
+    // \note Moving objects are not required to stick to this trajectory, it is
+    // indicative, and equivalent to the output of a perception + prediction
+    // system.
+    //
+    repeated StatePoint future_trajectory = 8;
+
     // Definition of object types.
     //
     enum Type

osi_trafficcommand.proto

@@ -119,36 +119,6 @@ message TrafficAction
     optional TeleportAction teleport_action = 12; 
 }
 
-//
-// \brief The StatePoint definition
-//
-// \note The StatePoint definition does not define mandatory fields.
-// The context defines how and what fields are used.
-// For example: FollowPathAction does not use timestamp in contrast to
-// FollowTrajectoryAction. 
-//
-message StatePoint
-{
-    // The timestamp of a StatePoint
-    //
-    // \note Zero time point does not need to coincide with the UNIX epoch.
-    //
-    optional Timestamp timestamp = 1;
-
-    // Position in the global coordinate system.
-    //
-    // The position refers to the center (x,y,z) of the bounding box.
-    //
-    // \note Remark: The definition of the reference point follows the
-    // specification of the \c BaseMoving message.
-    //
-    optional Vector3d position = 2;
-
-    // Orientation in the global coordinate system.
-    //
-    optional Orientation3d orientation = 3;
-}
-
 //
 // \brief The action header
 //

osi_trafficupdate.proto

@@ -10,8 +10,8 @@ package osi3;
 
 //
 // \brief The traffic update message is provided by traffic
-// participant models to provide updates to their position and
-// state back to the simulation environment.
+// participant models to provide updates to their position, state
+// and future trajectory back to the simulation environment.
 //
 // \note For reasons of convenience and consistency, the
 // updated information is provided as a MovingObject.  Certain fields
@@ -38,13 +38,12 @@ message TrafficUpdate
     //
     optional Timestamp timestamp = 2;
 
-    // Updated moving object
+    // Updated traffic participant data
     //
-    // \note Only the following members are considered in updates: id, base member 
-    // without dimension and base_polygon and the vehicle_classification.light_state.
-    // All other members can be left undefined and will be
-    // ignored by the receiver of this message.
+    // \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.
     //
-    optional MovingObject update = 3;
-
+    repeated MovingObject update = 3;
 }