Trajectory definition issues
| Bugzilla Link | 4293 |
| Created on | Jan 27, 2020 15:14 |
| Version | unspecified |
| Attachments | Image1, Image2 |
Extended Description
Created attachment 146
Image1
I'll paste here the email discussion related to trajectory definition.
======================================================================
From: Pierre R. Mai pmai@pmsfit.de
Sent: 24 January 2020 17:30
To: Stracabosko, Daniel AVL/HR Daniel.Stracabosko@avl.com; openscenario_transfer@asam.net
Cc: benjamin.engel@asam.net; Vukalovic, Jakob AVL/HR Jakob.Vukalovic@avl.com
Subject: AW: Trajectory definition issues
Hi everyone,
probably this discussion would be better handled as a gitlab issue, which would properly archive the results, but for now replying here:
- Trajectory timing information
The time information is stored as part of the Vertex or ControlPoint elements for the Polyline and Nurbs shapes, since they are just a 4th/7th dimension in those cases. Note that the user guide entry, as formulated does not state that the time information is stored in the Trajectory element, it talks about the trajectory as a whole, which comprises the Trajectory element and all of its contents, i.e. the whole trajectory specification. For the Clothoid the time dimension values at the start and end of the clothoid are given.
- Heading information inside trajectories
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.
Regs, Pierre.
--
Pierre R. Mai pmai@pmsf.de
PMSF IT Consulting Pierre R. Mai http://www.pmsf.de/
Blumenstr. 4 / Büro Waldweg 4 Goethestr. 32
85417 Marzling 87724 Ottobeuren
Tel. +49(0)8161/976 96 - 11 +49(0)8332/936 69 13
Fax +49(0)8161/976 96 - 51 +49(0)8332/936 69 03
Germany VAT ID / USt-ID Nr: DE 212838159
Von: Stracabosko, Daniel AVL/HR Daniel.Stracabosko@avl.com
Gesendet: Freitag, 24. Januar 2020 15:11
An: openscenario_transfer@asam.net
Cc: benjamin.engel@asam.net; Vukalovic, Jakob AVL/HR Jakob.Vukalovic@avl.com
Betreff: Trajectory definition issues
Hi,
Colleague Jakob Vukalovic doesn’t have permission to send to openscenario_transfer@asam.net so I’m forwarding you his email.
Ps: @benjamin.engel@asam.net can you please add Jakob Vukalovic to the list of possible senders?
Best regards,
Daniel
====================================================================
From: Vukalovic, Jakob AVL/HR Jakob.Vukalovic@avl.com
Sent: 24 January 2020 15:06
To: openscenario_transfer@asam.net
Cc: Bulaja, Mirko AVL/HR mirko.bulaja@avl.com; n.ochoa@denso-auto.de; zeyn.saigol@ts.catapult.org.uk; bruno.augusto@vti.se; klaus.zaeper@b-plus.com; Jens.Gruenberg@tracetronic.de; rico.auerswald@ivi.fraunhofer.de; Tobias.Weimer@micronova.de; Schneider, Hannes AVL/AT Hannes.Schneider@avl.com; PBouillon@dspace.de; sebastian.rossner@audi.de; emil.knabe@volvocars.com; Stracabosko, Daniel AVL/HR Daniel.Stracabosko@avl.com; mohamed.tlig@irt-systemx.fr; benjamin.engel@asam.net; klaus.estenfeld@asam.net; nicco.dillmann@asam.net; pmai@pmsfit.de
Subject: Trajectory definition issues
Hello!
While going over the user manual, I found some inconsistencies in the current definition of OpenScenario trajectories.
Trajectory timing information
From the user manual:
Additionally, a trajectory can be specified with or without a time dimension, allowing for the combined or separate specification of the entity’s longitudinal domain: A trajectory with the time dimension completely specifies the motion path of the entity, including its speed, whereas a trajectory without the time dimension does not specify the speed along the path, hence allowing separate control of the speed to occur.
Trajectory references can specify whether to make use of the time dimension information in a catalog trajectory.
Furthermore, FollowTrajectoryAction clearly references this timing information provided by the trajectory, and optionally imposes its own offset/scaling. From the UML:
(timeReference attribute) Defines if time information provided within the trajectory should be considered. If so, it may be used as either absolute or relative time along the trajectory in order to define longitudinal velocity of the actor. Moreover, a time offset or time scaling may be applied.
However, neither the latest UML nor the schema contain the description of the timing information attribute within the Trajectory object. Per schema and UML a trajectory definition only contains name, closed, shape and parameterDeclarations.
Clothoid Shape does have attributes pertaining to timing - startTime and stopTime (which, too, have not been clarified BTW), but this is not a Trajectory object, it's a Shape object. Moreover, other Shapes, NURBS and polyline, don't have these attributes.
Heading inside the trajectory
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ć
MSc Jakob VUKALOVIĆ
Development Engineer Software
CDC Computer Science
T: +385 1 7775 165
AVL-AST d.o.o. Croatia
Strojarska 22, 10000 Zagreb
Croatia