Skip to content

Commit b93cd53

Browse files
tblehertbleher
committed
Move ReferenceLine to separate file
This makes it easier to use the ReferenceLine for other purposes. Signed-off-by: Thomas Bleher <thomas.tb.bleher@bmw.de>
1 parent 1a635b8 commit b93cd53

File tree

4 files changed

+143
-133
lines changed

4 files changed

+143
-133
lines changed

‎CMakeLists.txt‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -74,6 +74,7 @@ set(OSI_PROTO_FILES
7474
osi_trafficlight.proto
7575
osi_trafficupdate.proto
7676
osi_trafficcommand.proto
77+
osi_referenceline.proto
7778
osi_roadmarking.proto
7879
osi_lane.proto
7980
osi_logicallane.proto

‎osi_groundtruth.proto‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,7 @@ import "osi_trafficlight.proto";
1010
import "osi_roadmarking.proto";
1111
import "osi_lane.proto";
1212
import "osi_logicallane.proto";
13+
import "osi_referenceline.proto";
1314
import "osi_object.proto";
1415
import "osi_occupant.proto";
1516

‎osi_logicallane.proto‎

Lines changed: 0 additions & 133 deletions
Original file line numberDiff line numberDiff line change
@@ -7,139 +7,6 @@ import "osi_lane.proto";
77

88
package osi3;
99

10-
//
11-
// \brief A reference line for defining a non-euclidean ST coordinate system
12-
//
13-
// A reference line is a 3D polyline, used for generating a non-euclidean
14-
// ST coordinate system.
15-
//
16-
// Notes on design decisions:
17-
// - This is a polyline, and not some more complex curve. The advantage of a
18-
// polyline is that it is very simple to generate from various map formats,
19-
// and it is also easy to handle. The downside is that a polyline has no
20-
// direct curvature, and even the angle is not continuous (only C0 smooth).
21-
// In the author's experience, the benefits of a polyline outweigh the costs.
22-
//
23-
// TODO Test whether the current definition is good enough for wide roads with
24-
// strong curvature (e.g. roundabouts with several lanes).
25-
//
26-
message ReferenceLine
27-
{
28-
// The ID of the logical lane.
29-
//
30-
// \note Note ID is global unique.
31-
//
32-
// \rules
33-
// is_globally_unique
34-
// \endrules
35-
//
36-
optional Identifier id = 1;
37-
38-
// Points comprising the polyline.
39-
//
40-
// At least 2 points must be given.
41-
// The polyline is defined as the lines between consecutive points.
42-
// Each point has an S coordinate. There are a few requirements on the S
43-
// position:
44-
// - Later points in the list must have strictly larger S coordinates than
45-
// earlier points.
46-
// - For consecutive points, the S difference between them must be at
47-
// least as large as the 2D euclidean distance between the points (2D
48-
// distance == euclidean distance between the points taking only X and Y
49-
// into account).
50-
// - The S distance between two points may be larger than the 2D euclidean
51-
// distance, but should be not much larger. It is allowed to be larger if
52-
// the underlying reference line (e.g. in an OpenDRIVE map) is a curve,
53-
// and thus the sampled reference line has a smaller length than the original
54-
// curve.
55-
//
56-
// Together, these rules allow directly putting OpenDRIVE S coordinates
57-
// into an OSI ReferenceLine.
58-
//
59-
// If the reference line approximates a curve (e.g. a clothoid in
60-
// OpenDRIVE), the points must be chosen in a way that the lateral distance
61-
// to the ideal line does not exceed 5cm. As shown in the following image:
62-
//
63-
// \image html line_approximation_error.svg "Approximation error"
64-
// Approximation error green line.
65-
//
66-
// Between two ReferenceLinePoints, both the world coordinate and the S
67-
// coordinate is interpolated linearly. So each S value uniquely describes
68-
// a point on the polyline.
69-
//
70-
// For the purpose of this discussion, let's call the S position of the
71-
// first point sStart, and the S position of the last point sEnd.
72-
//
73-
// For some purposes, S positions outside the normally defined range (i.e.
74-
// outside [sStart,sEnd]) need to be defined. For this purpose, the first
75-
// line of the polyline is infinitely extended in negative S direction.
76-
// Similarly, the last line of the polyline is infinitely extended beyond
77-
// the last point. The S value of points outside [sStart,sEnd] is defined
78-
// by the euclidean 2D distance from the start or end point, respectively.
79-
// So if sStart = 15, and a point is on the line extended from the start
80-
// position, with a 2D euclidean distance of 10 from the first point, then
81-
// it has an S position of 5.
82-
//
83-
// A point is "before" the reference line, if its s coordinate is < sStart.
84-
// A point is "after" the reference line, if its s coordinate is > sEnd.
85-
//
86-
// To describe points that are not directly on the polyline, a T
87-
// coordinate is added. T is the signed 2D distance (i.e. hypot(A.X-B.X,
88-
// A.Y-B.Y), if A and B are the two points) between the point to describe
89-
// and the nearest point on the polyline (this point might either be on a
90-
// line segment or at an edge between two line segments). The distance is
91-
// positive if the point is left of the polyline (in definition direction),
92-
// negative if it is right of it. Note that the "nearest point on the
93-
// polyline" is calculated in 3D, in order to choose the correct point for
94-
// 3D curves (think reference lines for roads in parking decks). If there
95-
// are several "nearest points", the one with the smallest S coordinate on
96-
// the polyline is chosen.
97-
//
98-
// Sometimes an angle to a reference line is needed. This shall be defined
99-
// as follows:
100-
// First the nearest point on the polyline is determined, as described
101-
// above. If this point is on a line segment, then the angle is calculated
102-
// relative to the line segment on which the reference point lays.
103-
// If the nearest point is at the edge between line segments, then the
104-
// angle of the following line shall be chosen.
105-
//
106-
// Notes on OpenDRIVE compatibility:
107-
// Ideally, one would want the polyline to be fully compatible with
108-
// OpenDRIVE, so that calculations done for OpenDRIVE directly match those
109-
// in OSI. There are a few difficulties with this:
110-
// - The T coordinate is nearly the same as for OpenDRIVE, but
111-
// unfortunately not perfectly. In OpenDRIVE, if the road is tilted using
112-
// superElevation, then the t coordinate system is tilted along, so the T
113-
// coordinate is no longer calculated in the XY plane (as proposed for
114-
// OSI). It doesn't seem feasable to implement the same tilting for OSI,
115-
// so simulation tools will have to consider superElevation and convert
116-
// the T coordinate accordingly: t_OSI = t_OpenDRIVE * cos(alpha), where
117-
// alpha is the superelevation angle.
118-
// - The angle will not be perfectly the same, due to the use of line
119-
// segments in OSI, and curves in OpenDRIVE. In the authors opinion, the
120-
// difference will be negligible if the poly_line is suitably sampled.
121-
//
122-
// Notes on design decisions:
123-
// - The S coordinate is included directly, both for OpenDRIVE
124-
// compatibility, and to speed up calculations.
125-
// - The rules on S coordinates (e.g. the calculation in 2D space) are
126-
// there to ensure OpenDRIVE compatibility.
127-
// - The rules on T coordinates are there to ensure OpenDRIVE compatibility
128-
// for lanes without superelevation, and to make it easier to convert
129-
// between OSI and OpenDRIVE in case superelevation is present.
130-
//
131-
repeated ReferenceLinePoint poly_line = 2;
132-
133-
// A point on the reference line
134-
message ReferenceLinePoint {
135-
// A world position
136-
optional Vector3d world_position = 1;
137-
138-
// S position on the reference line
139-
optional double s_position = 2;
140-
}
141-
}
142-
14310
// Similar to a LaneBoundary, but with a reference and ST positions.
14411
//
14512
// A logical lane boundary describes the boundary between two logical lanes. As

‎osi_referenceline.proto‎

Lines changed: 141 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,141 @@
1+
syntax = "proto2";
2+
3+
option optimize_for = SPEED;
4+
5+
import "osi_common.proto";
6+
7+
package osi3;
8+
9+
//
10+
// \brief A reference line for defining a non-euclidean ST coordinate system
11+
//
12+
// A reference line is a 3D polyline, used for generating a non-euclidean
13+
// ST coordinate system.
14+
//
15+
// Notes on design decisions:
16+
// - This is a polyline, and not some more complex curve. The advantage of a
17+
// polyline is that it is very simple to generate from various map formats,
18+
// and it is also easy to handle. The downside is that a polyline has no
19+
// direct curvature, and even the angle is not continuous (only C0 smooth).
20+
// In the author's experience, the benefits of a polyline outweigh the costs.
21+
//
22+
// TODO Test whether the current definition is good enough for wide roads with
23+
// strong curvature (e.g. roundabouts with several lanes).
24+
//
25+
message ReferenceLine
26+
{
27+
// The ID of the logical lane.
28+
//
29+
// \note Note ID is global unique.
30+
//
31+
// \rules
32+
// is_globally_unique
33+
// \endrules
34+
//
35+
optional Identifier id = 1;
36+
37+
// Points comprising the polyline.
38+
//
39+
// At least 2 points must be given.
40+
// The polyline is defined as the lines between consecutive points.
41+
// Each point has an S coordinate. There are a few requirements on the S
42+
// position:
43+
// - Later points in the list must have strictly larger S coordinates than
44+
// earlier points.
45+
// - For consecutive points, the S difference between them must be at
46+
// least as large as the 2D euclidean distance between the points (2D
47+
// distance == euclidean distance between the points taking only X and Y
48+
// into account).
49+
// - The S distance between two points may be larger than the 2D euclidean
50+
// distance, but should be not much larger. It is allowed to be larger if
51+
// the underlying reference line (e.g. in an OpenDRIVE map) is a curve,
52+
// and thus the sampled reference line has a smaller length than the original
53+
// curve.
54+
//
55+
// Together, these rules allow directly putting OpenDRIVE S coordinates
56+
// into an OSI ReferenceLine.
57+
//
58+
// If the reference line approximates a curve (e.g. a clothoid in
59+
// OpenDRIVE), the points must be chosen in a way that the lateral distance
60+
// to the ideal line does not exceed 5cm. As shown in the following image:
61+
//
62+
// \image html line_approximation_error.svg "Approximation error"
63+
// Approximation error green line.
64+
//
65+
// Between two ReferenceLinePoints, both the world coordinate and the S
66+
// coordinate is interpolated linearly. So each S value uniquely describes
67+
// a point on the polyline.
68+
//
69+
// For the purpose of this discussion, let's call the S position of the
70+
// first point sStart, and the S position of the last point sEnd.
71+
//
72+
// For some purposes, S positions outside the normally defined range (i.e.
73+
// outside [sStart,sEnd]) need to be defined. For this purpose, the first
74+
// line of the polyline is infinitely extended in negative S direction.
75+
// Similarly, the last line of the polyline is infinitely extended beyond
76+
// the last point. The S value of points outside [sStart,sEnd] is defined
77+
// by the euclidean 2D distance from the start or end point, respectively.
78+
// So if sStart = 15, and a point is on the line extended from the start
79+
// position, with a 2D euclidean distance of 10 from the first point, then
80+
// it has an S position of 5.
81+
//
82+
// A point is "before" the reference line, if its s coordinate is < sStart.
83+
// A point is "after" the reference line, if its s coordinate is > sEnd.
84+
//
85+
// To describe points that are not directly on the polyline, a T
86+
// coordinate is added. T is the signed 2D distance (i.e. hypot(A.X-B.X,
87+
// A.Y-B.Y), if A and B are the two points) between the point to describe
88+
// and the nearest point on the polyline (this point might either be on a
89+
// line segment or at an edge between two line segments). The distance is
90+
// positive if the point is left of the polyline (in definition direction),
91+
// negative if it is right of it. Note that the "nearest point on the
92+
// polyline" is calculated in 3D, in order to choose the correct point for
93+
// 3D curves (think reference lines for roads in parking decks). If there
94+
// are several "nearest points", the one with the smallest S coordinate on
95+
// the polyline is chosen.
96+
//
97+
// Sometimes an angle to a reference line is needed. This shall be defined
98+
// as follows:
99+
// First the nearest point on the polyline is determined, as described
100+
// above. If this point is on a line segment, then the angle is calculated
101+
// relative to the line segment on which the reference point lays.
102+
// If the nearest point is at the edge between line segments, then the
103+
// angle of the following line shall be chosen.
104+
//
105+
// Notes on OpenDRIVE compatibility:
106+
// Ideally, one would want the polyline to be fully compatible with
107+
// OpenDRIVE, so that calculations done for OpenDRIVE directly match those
108+
// in OSI. There are a few difficulties with this:
109+
// - The T coordinate is nearly the same as for OpenDRIVE, but
110+
// unfortunately not perfectly. In OpenDRIVE, if the road is tilted using
111+
// superElevation, then the t coordinate system is tilted along, so the T
112+
// coordinate is no longer calculated in the XY plane (as proposed for
113+
// OSI). It doesn't seem feasable to implement the same tilting for OSI,
114+
// so simulation tools will have to consider superElevation and convert
115+
// the T coordinate accordingly: t_OSI = t_OpenDRIVE * cos(alpha), where
116+
// alpha is the superelevation angle.
117+
// - The angle will not be perfectly the same, due to the use of line
118+
// segments in OSI, and curves in OpenDRIVE. In the authors opinion, the
119+
// difference will be negligible if the poly_line is suitably sampled.
120+
//
121+
// Notes on design decisions:
122+
// - The S coordinate is included directly, both for OpenDRIVE
123+
// compatibility, and to speed up calculations.
124+
// - The rules on S coordinates (e.g. the calculation in 2D space) are
125+
// there to ensure OpenDRIVE compatibility.
126+
// - The rules on T coordinates are there to ensure OpenDRIVE compatibility
127+
// for lanes without superelevation, and to make it easier to convert
128+
// between OSI and OpenDRIVE in case superelevation is present.
129+
//
130+
repeated ReferenceLinePoint poly_line = 2;
131+
132+
// A point on the reference line
133+
message ReferenceLinePoint {
134+
// A world position
135+
optional Vector3d world_position = 1;
136+
137+
// S position on the reference line
138+
optional double s_position = 2;
139+
}
140+
}
141+

0 commit comments

Comments
 (0)