Uses the closest point to calculate the equivalent p in a boundary.

[francocipollone]

🦟 Bug fix

Related to #39

Summary

39 Describes an issue that is evidenced when calculating the RBounds.

Intrinsically, this issue comes from the calculation of the equivalent p: this is the p in the left or right linestring that matches with the p in the centerline.

At the moment the equivalent p has been calculated by scaling the centerline p by the ratio of centerline length and boundary length. (Causing the issue in #39)

In this PR a new approach is given: For a given point in the centerline, the equivalent p in the boundaries will be given by the closest point(boundary to centerline)

Using this approach the issue of the RBounds calculation is solved, being consistent no matter the shape of the lane:

(Compare it with the case in #39 )

Pros:

• This approach doesn't accumulate error as the prior does given that the closest point is calculated for each centerline p.
• Solves the issue for the RBound calculation for any shape for roads.

Cons:

• The time for creating the meshes for the s_shape_road was doubled. From 36sec to 70sec(we should improve overall performance tho)
• when equivalent p is wanted to be calculated on a change of direction, an error might be added: this is minimized by sampling the road correctly and avoiding big discrete jumps in direction. For example:

Checklist

• [x] Signed all commits for DCO
• [ ] Added tests
• [ ] Updated documentation (as needed)
• [ ] Updated migration guide (as needed)
• [ ] Consider updating Python bindings (if it affects the public API)

[francocipollone]

This is a draft and the tests will be updated once this approach has been debated.

[agalbachicar]

I think it is worth the pros against the cons because:

• The time for creating the meshes for the s_shape_road was doubled. From 36sec to 70sec(we should improve overall performance tho)

This is a one time thing, and the problem should be reduced if we expose or use when computing meshes some kind of API that allows to pass in hints of where the previous value was computed, then the search is done in much smaller space. Also, sampling distance should reduce the computational cost here.

when equivalent p is wanted to be calculated on a change of direction: this is minimized by sampling the road correctly and avoiding big discrete jumps in direction.

There is no formal solution to this problem, I think. It is heuristic based and we should define one way to do it. This one seems reasonable based on the results you showed.

[francocipollone]

While the issue is solved for the SShapeRoad (which is flat), an anomaly can be seen when there is a variable superelevation, like in the SShapeSuperelevatedRoad. It is not as smooth as maliput_malidrive.

While in the part of the road where no superelevation is present.

[agalbachicar]

It is OK to not be smooth by definition. I think it is the combined effect between the curvature and the superelevation what makes that effect rather than superelevation alone.