Error introduced because of RBounds calculation

[francocipollone]

Summary

Context

When calculating the RBounds at a given p, it is required to obtain the equivalent p in the left and right boundary in order to obtain the boundaries of the lane correctly. For doing so, we'd decided to follow a simple scaling approximation, as the situation escalates quickly when trying to get something more accurate:

https://github.com/maliput/maliput_sparse/blob/0d6611bf5a26588010b238b3b9f3a9c397d94be4/src/geometry/lane_geometry.cc#L122-L145

This works correctly in some simple geometries:

• straights
• arcs

However, this causes some undesired values when having geometries that from the start to the end don't maintain a linear proportion between the length between the left and right linestring (if that makes sense): For example

• A lane with an S-shaped geometry.
  • Both left and right linestrings have the same length however scaling the centerline's p in order to get the equivalent p for the laterals isn't accurate.

Because of this situation, the final lane that is loaded (for example using maliput_osm backend) shows a wider lane as reaching the middle of the road.

For the record this is the flat-s-shape road used: lanelet2_s_shape_road.zip

[francocipollone]

Related to https://github.com/maliput/maliput_osm/issues/2#issuecomment-1276305852

[agalbachicar]

I am happy to have this sample road to evaluate it. I'll think of this and get back with a proposal.

[agalbachicar]

I have another proposal that deserves exploration.

We can compute the lane bounds and segment bounds by using the orientation at p of the centerline. That should give us the roll, pitch, yaw angles required to go from the centerline at p to both extents. We could compute the r_hat vector and intersect it to the left and right LineStrings of the lane or the segment.

PROs:

• Easy to compute: intersection of a polyline with a line.
• Easy to clamp: when p goes beyond the LineString extenstion ( [0, length]) we clamp it.
• Should deal with the changes of convexity of the road (e.g. S-shape road here).

CONs:

• The error amplifies with the lateral distance as it is not able to capture the variations in path due to curvature. We require more sampling.
• Orientation at a waypoint presents discontinuities by design, so we could easily fall on an abrupt change of orientation that maps on a lateral the wrong side or even no intersection. See this picture below.

[agalbachicar]

• At p1, the proposal works.
• At p2, the proposal ends up intersecting twice the same linestring instead of the other one.
• At p3, the proposal has just one lateral intersection to the right, but not to the left.

[agalbachicar]

I think we should push down a bit the information and do a mapping between the sections of each line that have certain reciprocity.

For example, in the S shape road, we could apply the scaling fro the C and inverted C, with different scaling functions. Thoughts @francocipollone ?

[francocipollone]

I like the general idea and I think that it is an improvement to what we have nowadays. However:

We can compute the lane bounds and segment bounds by using the orientation at p of the centerline. That should give us the roll, pitch, yaw angles required to go from the centerline at p to both extents.

Nowadays the orientation's rolling value is being computed using a scaling factor.(superelevation). We would need to tackled that first then. Actually the base of the issue is the same.

https://github.com/maliput/maliput_sparse/blob/c4663c98604f54d478e2b390ad72f4089240340a/src/geometry/lane_geometry.cc#L98 Check also https://github.com/maliput/maliput_sparse/issues/15#issuecomment-1250683237

We could compute the r_hat vector and intersect it to the left and right LineStrings of the lane or the segment.

We are in R3 and the centerline may not be in the same plane as the left and rigthstring so the intersection could not happen. Maybe intersecting a plane formed by a point in the centerline and the normal with the left/right string could work.

---

So the issue, besides the lane bounds or orientation, gets reduced to how we could obtain correctly the equivalent p for the left and right strings. Does it make sense to try to calculate this in the XY plane in order to get the equivalent p? We could obtain the 2dtagent at the centerline and from there calculate the r_hat(2d) to intersect with the boundaries. It has its flaws indeed but it is still an improvement.

[agalbachicar]

Sorry for the long delay here.

I took a look at the code and I think we can define "lane sections" when building the centerline from the left and right linestrings. Each new point that would build the centerline linestrings is made out of two points in the left and right linestrings as well. Some points in the left and in the right linestrings might be omitted when selecting the best candidate, thus we could define the extent at which each point will map to the left and to the right.

There are some extreme cases in which one of the side iterators does not advance to the next point. This case is not an exception, but it will degenerate to a side with length zero.

The picture belows how we should map to each side the p mapping. These lane sections would consolidate the path length up to the lane section under the mapping and then do a linear scaling to the sides. We would make sure to advance the necessary path length on each side this way and get the right mapping. Note that this method reduces the impact on the r_hat direction as it does not leave behind the path length distance on each side (or each linestring).

From a code point of view, everything could be handed by the LaneGeometry class. When computing the centerline, we could also make sure to create another structure that keeps track of the points in the left and right linestring that define the quadrilateral of the lane section under that yields two consecutive points in the centerline. Then, every time we are required to compute the lane boundaries, we could do so by implementing the method described above. The key change will be in the prototype and implementation of LineString3d ComputeCenterline3d(const LineString3d& left, const LineString3d& right). We would be required to return some compound object with a LineString3d and the reference waypoints for each other side. We could opt to return a vector of iterators for each other LineString, a copy of the points or a LineString itself.

[francocipollone]

As discussed F2F:

Some issues:

• When computing the centerline(current algorithm) the left and right points used for each centerline point may be quite displaced in space. And it will add considerable errors as the samples in the left and right string are distant.
• The left and right linestring may not be uniformly sampled and the distance between points will be different. In this situation the lane sections that are obtained could represent not usable cases:

Perhaps we could do some post processing after computing the centerline for finding the lane sections:

1. Project left right and centerline on the xy plane
2. For each centerline's point intersect each bisector with the left and right linestring finding the interpolated point that would define the lane section:
3. Traduce the p values to the third dimension by considering the elevation.