Heading information inside trajectories

Created from #141

The ability to specify orientation as additional three dimensions for trajectories is intended exactly to cover cases where a naïve derivation from movement is not enough: Either because the vehicle/pedestrian under consideration can obviously move in ways where orientation and movement are decoupled, or because the motion effects of a proper vehicle dynamics model are to be approximated (cars do not in general move in ways where the vehicle orientation is the movement tangent around the center of the rear axle, even when not taking sliding cars on ice into account, which one obviously has to).

The calculation of orientation mirrors directly the calculation of position for the shapes: I.e. for a polyline that specifies all 6/7 dimensions, the orientation values between vertices is calculated using linear interpolation, just as is done for the position. The same for NURBS, i.e. the control points specify a curve in 6/7 dimensional space, which is then sampled for position and orientation along its path.

Since not every use case will require exact specification of orientation, the option to specify only 3 dimensions is given, which then will have to rely on implementation-dependend derivation of orientation based on whatever motion model the implementation is using for a particular vehicle or other traffic participant.

For the special case of the (grandfathered in) Clothoids, we should indeed clarify that for them evolution of orientation cannot be specified, and that in this case orientation is indeed not optional for the start point.

Regards, Pierre

Again, from the user manual:

Trajectories can be specified using just the three positional dimensions (along the X, Y, and Z axes, see section 3.1.7 of this document for coordinate system definitions), or it can be specified using the three positional dimensions and the three rotational dimensions (heading, pitch and roll) for six total dimensions. In the second case, the path not only specifies the movement of the entity along the path, but also the orientation of the entity during that movement.

Even though it doesn't say how exactly this additional information should be used to calculate vehicle heading, I do not see how it could possibly be used to calculate any useful heading information. Together with the shape, X, Y, and Z coordinates already provide enough information for calculating the heading of the vehicle at any given point of the trajectory.

Example - polyline shape with vertices (1, 2, 3, 4):

[Image 1]

Between points 1 and 2, vehicle heading that makes most sense is h1,2 (the blue box representing the vehicle in that case). Per user manual, points 1 and 2 could define additional heading info, h1 and h2, with left and right green boxes representing the vehicle in these cases, respectively. That means:

• the vehicle is basically sliding sideways along the trajectory,

• again there is no clear definition of whether the vehicle should use heading h1 or h2 (or something else) between points 1 and 2.

Same goes for other points.

Example - clothoid shape:

[Image 2]

Definition of clothoid Shape contains the following attributes:

• length - total length of the trajectory,

• curvature - curvature at start (at point 1 in the picture),

• curvatureDot - rate of curvature change,

• position - position of the starting point (point 1) of the clothoid.

Note that here, orientation of the position point is not (or should not be) optional. Not because of some vehicle heading, but because this information is required to determine exact position of the trajectory around the position point. The heading of the vehicle inside the trajectory should again not be determined by some other, "custom" orientation value (green box and arrow), but by its position along the trajectory - ie it should be the tangent at each point (blue arrows at points 1, 2, 3, 4). Otherwise we would again end up with a sideways slide.

Comment - NURBS shape:

NURBS shape differs from polyline and clothoid in that the trajectory doesn't even pass through its control points (except for the endpoints). Furthermore, position of each point on the trajectory is influenced by multiple control points, so again it wouldn't be clear which one to use to calculate the heading.

Again, when control points are only defined by X, Y, and Z coordinate, the heading is simply tangent at current vehicle position, as it should always be.

To sum up, I think that:

• polyline and NURBS shapes do not need any additional orientation info,

• clothoid always needs orientation info in its position attribute,

• the paragraph that talks about additional heading information for a vehicle inside the trajectory should be removed from the user manual,

• vehicle heading should always be tangent to the trajectory at its current position along the trajectory.

Best regards!

Jakob Vukalović