Split tolerance used within xodr parsing and RoadGeometry construction process.

[agalbachicar]

Just what the title says.

The expected behavior is that we are can decouple those two tolerances and improve our building process and coverage.

Comes from https://github.com/ToyotaResearchInstitute/malidrive/issues/517#issuecomment-684035799

[francocipollone]

In order to achieve this goal, we should get all the possible information about the XODR.

• On one hand, we are providing a method to get the minimum and maximum geometry's length of the XODR:https://github.com/ToyotaResearchInstitute/malidrive/issues/569

• On the other hand, we should check the start-end coordinates between geometries within planView. Having in mind that we are going to need to know the gap between geometries(if any). This will help to obtain proper tolerance. For example:

  <planView>
  <geometry s="0.0000000000000000e+0" x="5.4000000000000000e+1" y="0.0000000000000000e+0" hdg="3.1415926535897931e+0" length="6.8629150101521930e-2">
      <line/>
  </geometry>
  <geometry s="6.8629153072834015e-2" x="5.3931370849898478e+1" y="0.0000000000000000e+0" hdg="3.1415926535897931e+0" length="3.0876914451445292e+0">
      <arc curvature="2.5436419971059765e-1"/>
  </geometry>
  <geometry s="3.1563205718994141e+0" x="5.1151471862576145e+1" y="-1.1514718625761429e+0" hdg="3.9269908169872410e+0" length="3.0876914451445305e+0">
      <arc curvature="2.5436419971059815e-1"/>
  </geometry>
  <geometry s="6.2440118789672852e+0" x="5.0000000000000000e+1" y="-3.9313708498984772e+0" hdg="-1.5707963267948966e+0" length="6.8474312421988870e-2">
      <line/>
  </geometry>
  </planView>

Knowing the (Xs,Ys) start point, the heading and the length we could estimate the final (Xf,Yf) point for each geometry. Finally, we could calculate the difference between the endpoint of a geometry and the start point of the next geometry.

The DBManager could provide a method to get the worst case from the XODR.

[agalbachicar]

Agreed. Note that again, it'd be good to have both the shortest and largest gaps.

[francocipollone]

A small technical doubt. Early we chatted about that this analysis shouldn't be done during parsing time, but at demand when the method is called. However, I think that the builder will always want to know this information, so I think that makes sense to perform this analysis when the parser is executed and just return the outcome when the api's method is called.

[agalbachicar]

There is a world where this processing is not needed because we know in advance values that will work with the map (e.g. a test) so we should run this code just when it is needed. I expect it to last a considerable amount of time with respect to other tasks in parse time. Hence, the request is still valid I think.

What do you think?

[francocipollone]

Ah okok, If we allow passing those values then it definitely makes sense to perform this analysis on demand. I agree then. Thanks.

[agalbachicar]

In ToyotaResearchInstitute/malidrive#590, I started to draft a solution to derive a good enough value of tolerance that is derived from the geometry issues.

[agalbachicar]

I believe the tolerance automatic adjustment will work under certain circumstances but for most of real world maps the malidrive's Builder will need to be smart and solve some of the geometry descriptions. The following list describes some the cases that are problematic and we might do something to solve them:

• Gaps within a XODR Road:
  • adding small lines / splines to join the non- contiguous roads.
  • extending the geometries (when possible) to match the endpoints with the correct orientation.
• Tiny adjacent geometries within a XODR Road:
  • we can filter them with a line / piecewise spline that uses the endpoints as control points.

The suggested approach for this is to:

• Create the APIs in the DBManager that would allow the library to inspect the map and determine where the filtering can be done with certain criteria.
• Modify the Builder with a secondary policy that is not strict and performs a filtering process on the map to remove those edge cases.

[agalbachicar]

After running ToyotaResearchInstitute/malidrive#603 in a local branch to test maps, I could identify that roads that are already part of the malidrive integration tests are loaded. The following list shows the problematic xodr Road IDs in each map:

• Town01: 73 --> @francocipollone
• Town02: 284 --> @francocipollone
• Town03: 797
• Town04: 399 --> @agalbachicar
• Town05: 1275
• Town06: 610
• Town07: 788
• RRLongRoad: 5
• Figure8: 21

I will add tests to solve those specific cases in order.

[liangfok]

What do the numbers correspond to? Like, in Town01, what does "73" mean? Is it a road number?

[francocipollone]

That's right. It is the Road Id

[agalbachicar]

What do the numbers correspond to? Like, in Town01, what does "73" mean? Is it a road number?

@liangfok I have edited the comment to make it explicit that those are the XODR Road Ids.

[liangfok]

Thanks. Do we have visualizations of the problematic road IDs so we can see the problem?

[agalbachicar]

We don't have visualizations because they fail when building the RoadCurve. Failures are related to constraint violations. I will send a few PRs to easily reproduce the errors.

[agalbachicar]

In the meantime, I'd like to illustrate with a piece of the Road 399 in Town04:

        <planView>
            <geometry s="0.0000000000000000e+0" x="3.1283780569538402e+2" y="1.8031339835661868e+2" hdg="-1.5797139021955537e+0" length="4.3068866785660020e-2">
                <line/>
            </geometry>
            <geometry s="4.3068866785660020e-2" x="3.1283742163060742e+2" y="1.8027033120230766e+2" hdg="-1.5797139021955537e+0" length="7.0006205424934933e+0">
                <line/>
            </geometry>
            <geometry s="7.0436894092791817e+0" x="3.1277499389648438e+2" y="1.7326998901367188e+2" hdg="-1.5797139021955546e+0" length="2.6432891455440028e+0">
                <line/>
            </geometry>
            <geometry s="9.6869785548231846e+0" x="3.1275142247863840e+2" y="1.7062680496877235e+2" hdg="-1.5797139021955546e+0" length="9.3738955918390445e+0">
                <line/>
            </geometry>
            <geometry s="1.9060874146662229e+1" x="3.1266783116581797e+2" y="1.6125328209532074e+2" hdg="-1.5797139021955546e+0" length="4.1237163998090409e-2">
                <line/>
            </geometry>
        </planView>

If you take a look at the headings and lengths of the lines, you will see that the first two share the same heading as well as the last thee do. The first length and the last length is a couple of order of magnitudes less than the other lengths. When putting everything together it throws an error because the tolerance constraint.

On the other hand, the map should not be like this, a line could be created out of several lines but should not have different orientations.

[agalbachicar]

I will send a few PRs to easily reproduce the errors.

Enabling the simplifications in ToyotaResearchInstitute/malidrive#606

[francocipollone]

Comments about Town01.xodr.

Road 73 Using constants::kLinearTolerance (= 5e-2)

The XODR describes two "problematics" :

• A: Last geoemtry is too short

      <planView>
          <geometry s="0.0000000000000000e+0" x="3.3670817676017708e+2" y="-3.1745223897602796e+2" hdg="4.7117849694245422e+0" length="2.8447879720998568e+0">
              <line/>
          </geometry>
          <geometry s="2.8447879720998568e+0" x="3.3670645847716708e+2" y="-3.2029702642919693e+2" hdg="4.7117849694245342e+0" length="6.4426475123177251e+0">
              <arc curvature="-1.1702009361818989e-1"/>
          </geometry>
          <geometry s="9.2874354844175802e+0" x="3.3438718474410859e+2" y="-3.2614505934186957e+2" hdg="3.9578657543841258e+0" length="6.3862805350901564e+0">
              <arc curvature="-1.2781666829529736e-1"/>
          </geometry>
          <geometry s="1.5673716019507737e+1" x="3.2868684692483936e+2" y="-3.2860998535156250e+2" hdg="3.1415926535897931e+0" length="2.9557641729919624e+0">
              <line/>
          </geometry>
          <geometry s="1.8629480192499699e+1" x="3.2573108275017819e+2" y="-3.2860998535156250e+2" hdg="3.1415926535897931e+0" length="7.3076007114991626e-3">
              <line/>
          </geometry>
      </planView>

  (Fails when building the PiecewiseGeometry)

• B: The length of the second laneSection is too short.

  <laneSection s="1.8629480192499699e+1">

  Road's Length: Length = 1.8636787793211198e1 laneSection[1] starts at S = 1.8629480192499699e1 --> LaneSection's length = 0.0073076007 (Fails in the OpenRangeValidator because the length of the lane is larger than the tolerance)

Solution I was able to sort out these issues in two ways:

One option: enable geometry simplification to solve A and then adjust tolerance to solve B.

• Using Tolerance = 5e-2 | geometry simplification = false --> error A.
• Using: Tolerance = 5e-2 | geometry simplification = true --> error B.
• Using: Tolerance = 1e-2 | geometry simplification = true --> Correctly built.

Another option: decrease tolerance to avoid A. (B is implicitly covered too)

• Using: Tolerance = 5e-2 | geometry simplification = false --> error A.
• Using: Tolerance = 1e-2 | geometry simplification = false --> error A.
• Using: Tolerance = 7e-3 | geometry simplification = false --> Correctly built

[francocipollone]

Comments about Town02.xodr.

Similar issues to Town01

• Using Tolerance = 5e-2 | geometry simplification = false Road 255 Throws when generating the PiecewiseGroundCurve because of the small length of the geometries.

• Using Tolerance = 5e-2 | geometry simplification = true Solves the previous issue in Road 255 Road 274 Throws when building the MalidriveLane because of the small length of the Lane (= Length of the 7th laneSection).

Decreasing tolerance < 2.8e-4 solves that issue in Road 274 however it causes another error in Road 255

• Using Tolerance = 2.7e-4 | geometry simplification = true Throws when generating the PiecewiseGroundCurve. Fails during the contiguity checking, because lowering down the tolerance higher the requirement of contiguity(Endpoint of one geometry vs startpoint of the next geometry)

  EndPoint:   lhs->G(lhs->p1()): {2.94852, -189.554}
  StartPoint:  rhs->G(rhs->p0()): {2.94876, -189.554}

  
  Failure at /home/franco/Worskpace/RoadNetwork/tri_ws/src/malidrive/src/malidrive/road_curve/piecewise_ground_curve.cc:61 in PiecewiseGroundCurve(): condition 'contiguity_checker(previous_ground_curve, ground_curve.get())' failed.

**The following just provides information about the issue:**
The latter 4 geometries of this Road are the following:
```xml
            ....
            ....
            <geometry s="1.1199366424583692e+1" x="8.9943258779271185e-1" y="-1.8955265216961777e+2" hdg="-4.5836984543057291e-4" length="2.0490863633288026e+0">
                <line/>
            </geometry>
            <geometry s="1.3248452787912495e+1" x="2.9487558380403724e+0" y="-1.8955359151766498e+2" hdg="-4.5836984543168313e-4" length="7.5101660250603608e-2">
                <line/>
            </geometry>
            <geometry s="1.3323554448163097e+1" x="3.0238574904014373e+0" y="-1.8955362594200020e+2" hdg="-4.5836984543168313e-4" length="1.1257591711339821e-1">
                <line/>
            </geometry>
            <geometry s="1.3436130365276496e+1" x="3.1364333956885719e+0" y="-1.8955367754340409e+2" hdg="-4.5836984543168313e-4" length="2.6366579807310586e-1">
                <line/>
            </geometry>

The aforementioned issue about contiguity checking happens between the first and second geometry, when simplification is disabled. If we enable the simplification feature then from the second to the fourth geometry are packed together, therefore the issue is still happening between the first geometry and second geometry, which was simplified.

[francocipollone]

LaneSection's length plays a role too when choosing the correct tolerance.

I used xodr_query with the last improvement(#609) in the above maps. EDIT: I've added information about the largest gap and shortest geometry too.

• Town01 Shortest LaneSection in the XODR: 7.3076e-03 -- Located at RoadHaderId: 73, LaneSection Index: 1 Shortest Geometry in the XODR: 7.3076e-03 -- Located at RoadHaderId: 73, Geometry Index: 4 Largest Gap between Geometries in the XODR: 3.46976e-04 -- Located at RoadHaderId: 170, Geometry Indexes: [3,4]

• Town02 Shortest LaneSection in the XODR: 1.70901e-05 -- Located at RoadHaderId: 127, LaneSection Index: 2 Shortest Geometry in the XODR: 1.70901e-05 -- Located at RoadHaderId: 127, Geometry Index: 5 Largest Gap between Geometries in the XODR: 3.11456e-04 -- Located at RoadHaderId: 127, Geometry Indexes: [0,1]

• Town03 Shortest LaneSection in the XODR: 1.93096e-07 -- Located at RoadHaderId: 160, LaneSection Index: 5 Shortest Geometry in the XODR: 1.93096e-07 -- Located at RoadHaderId: 160, Geometry Index: 5 Largest Gap between Geometries in the XODR: 1.10894e-03 -- Located at RoadHaderId: 183, Geometry Indexes: [3,4]

• Town04 Shortest LaneSection in the XODR: 9.41397e-08 -- Located at RoadHaderId: 580, LaneSection Index: 3 Shortest Geometry in the XODR: 9.41397e-08 -- Located at RoadHaderId: 580, Geometry Index: 3 Largest Gap between Geometries in the XODR: 1.45974e-03 -- Located at RoadHaderId: 566, Geometry Indexes: [1,2]

• Town05 Shortest LaneSection in the XODR: 3.49146e-08 -- Located at RoadHaderId: 363, LaneSection Index: 5 Shortest Geometry in the XODR: 3.49146e-08 -- Located at RoadHaderId: 363, Geometry Index: 5 Largest Gap between Geometries in the XODR: 1.79624e-03 -- Located at RoadHaderId: 610, Geometry Indexes: [2,3]

• Town06 Shortest LaneSection in the XODR: 6.84539e-07 -- Located at RoadHaderId: 682, LaneSection Index: 1 Shortest Geometry in the XODR: 6.84539e-07 -- Located at RoadHaderId: 682, Geometry Index: 1 Largest Gap between Geometries in the XODR: 1.09957e-03 -- Located at RoadHaderId: 193, Geometry Indexes: [3,4]

• Town07 Shortest LaneSection in the XODR: 3.51292e-11 -- Located at RoadHaderId: 641, LaneSection Index: 6 Shortest Geometry in the XODR: 3.51292e-11 -- Located at RoadHaderId: 641, Geometry Index: 6 Largest Gap between Geometries in the XODR: 1.01301e-03 -- Located at RoadHaderId: 346, Geometry Indexes: [1,2]

• RRLongRoad Shortest LaneSection in the XODR: 1.77963e-02 -- Located at RoadHaderId: 5, LaneSection Index: 0 Shortest Geometry in the XODR: 7.20007e-03 -- Located at RoadHaderId: 3, Geometry Index: 13 Largest Gap between Geometries in the XODR: 1.27106e-13 -- Located at RoadHaderId: 6, Geometry Indexes: [84,85]

• Figure8 Shortest LaneSection in the XODR: 4.59566e-02 -- Located at RoadHaderId: 12, LaneSection Index: 0 Shortest Geometry in the XODR: 4.59566e-02 -- Located at RoadHaderId: 12, Geometry Index: 0 Largest Gap between Geometries in the XODR: 2.68062e-04 -- Located at RoadHaderId: 17, Geometry Indexes: [4,5]

---

• Cloverleaf Shortest LaneSection in the XODR: 2.05 -- Located at RoadHaderId: 1227, LaneSection Index: 0 Shortest Geometry in the XODR: 1.58946e-07 -- Located at RoadHaderId: 120, Geometry Index: 0 Largest Gap between Geometries in the XODR: 7.46795.e-04 -- Located at RoadHaderId: 533, Geometry Indexes: [0,1]

• Leghorn 2.0 Shortest LaneSection in the XODR: 3.19252e-03 -- Located at RoadHaderId: 330, LaneSection Index: 0 Shortest Geometry in the XODR: 2.22045e-16 -- Located at RoadHaderId: 4675, Geometry Index: 5 Largest Gap between Geometries in the XODR: 1.60242e-02 -- Located at RoadHaderId: 4973, Geometry Indexes: [0,1]

[francocipollone]

Question is. Does Road Runner also create small LaneSections as CARLA's xodr generator(apparently) does?

I tried Cloverleaf, which is a large map created by RR and:

• Shortest LaneSection in the XODR: 2.05 Located at RoadHaderId: 1227, LaneSection Index: 0**

[liangfok]

I've asked the question internally within TRI and will report back. Meanwhile, is "RRLongRoad" generated by RoadRunner?

[francocipollone]

I've asked the question internally within TRI and will report back. Meanwhile, is "RRLongRoad" generated by RoadRunner?

Thanks! Yes, RRLongRoad was generated by RoadRunner.

And also Leghorn. I've just tried the last Leghorn map that was shared with us.

Leghorn2.0

Shortest LaneSection in the XODR: 0.00319252  -- Located at RoadHaderId: 330, LaneSection Index: 0

[liangfok]

Alright, based on the above, I believe we can safely conclude that RoadRunner also generates short LaneSections, and that Malidrive 2.0 needs to be able to elegantly handle them.

[agalbachicar]

I will write here a F2F chat with @francocipollone for posterity and visibility. New additions will be added in favor of improving the build process and trying to handle malformed maps:

• MalidriveLanes whose parameter range (from the XODR LaneSection extent (p1 - p0)) is less than linear tolerance have the problem of requiring extra computation from the integrators to compute the arc length s parameter for each p value. That is unnecessary and we might be able to obtain similar results with a first order polynomial approximation between p and s, i.e. s = p - p0. For the record, this is analogous to TrivialRoadCurve, which is up and running in malidrive + OpenDRIVE SDK.
• MalidriveLanes whose parameter range (from the XODR LaneSection extent (p1 - p0)) is less than linear tolerance might be so tiny that our s checks might fail (see OpenRangeValidator.cc:38) at construct time. In those cases, we might not care to take multiple samples in the Lane, but to just get a valid coordinate in any frame, orientation, etc. For that reason, it might be worth return for any query the value of a single coordinate (at the beginning of the Lane for example) because the error in any other place of the Lane surface will be bound to the range [p0, p1] which is less than linear tolerance as explained before.

These two changes are expected to:

• Respect the API contract.
• Still have control over tolerance.
• Vary the math model introducing approximations where the requirement of precision is arguable because they are considered as garbage in (but we don't want to provide garbage out).

[francocipollone]

Regarding the new error that you discovered @agalbachicar when loading Town0X maps (but 01 and 05) which is :

terminate called after throwing an instance of 'maliput::common::assertion_error'
  what():  Failure at /home/franco/Worskpace/RoadNetwork/tri_ws/src/malidrive/src/malidrive/road_curve/road_curve_offset.cc:235 in PFromS(): condition 'dense_output->end_time() >= full_length' failed.

That condition fails because full_length is bigger than dense_output->end_time() (obviously) but for about ~1e-17 So clearly here the problem is related to the comparison between double types. In every case, the difference is about that order.

Just doing:

MALIDRIVE_THROW_UNLESS(dense_output->end_time() >= full_length - std::numeric_limits<double>::epsilon());
solves the issue.

We should decide which is the best tolerance to perform the comparison here. Once that is solved Town02, 03, 06 and 07 could be loaded (Town04 fails in another part.)

---

---

Town04 has a particularity

Road 735 has the following elevation profile:

        <elevationProfile>
            <elevation s="0.0000000000000000e+0" a="9.8075278075713044e+0" b="-1.6967480128781007e-2" c="3.8310299155731173e-6" d="0.0000000000000000e+0"/>
            <elevation s="1.0165258117922349e-5" a="9.8075276350924891e+0" b="-1.6967480050894192e-2" c="3.8310299155731173e-6" d="0.0000000000000000e+0"/>
            <elevation s="3.8398544263657186e-1" a="9.8527823517460060e+0" b="-1.6964537995022289e-2" c="0.0000000000000000e+0" d="0.0000000000000000e+0"/>
            <elevation s="1.0061806568593283e+0" a="9.7904578527171413e+0" b="-1.4212740423763861e-2" c="0.0000000000000000e+0" d="0.0000000000000000e+0"/>
            <elevation s="1.9819063267692783e+1" a="9.5230752355466244e+0" b="-1.4212740423763883e-2" c="2.7198619032002585e-4" d="0.0000000000000000e+0"/>
        </elevationProfile>

When the Piecewise Function is being created then G1contiguity is verified between individual functions. Between the second and the third elevation function, there is a considerable(6e-2) difference when is being evaluated.

lhs->f(lhs->p1()): 9.80101310706914
rhs->f(rhs->p0()): 9.85278235174601

I've checked the math and effectively the XODR is not accurate enough.

However, moving the linear tolerance to 6e-2 relaxes the checking and in consequence, it wouldn't fail.

Note: This is the first XODR map where the elevation description is a constraint in the tolerance selection.

[francocipollone]

Failing when running integration tests in delphyne

Adding maps to the integration tests in delphyne-gui

Some errors were found when running delphyne-mali2 with some maps. Although they are errors that happen in delphyne/delphyne-gui's namespace, I share it here because certainly could be related to malidrive's new implementation.

• Town03:

  • Tolerance: 5e-2
  • Map is loaded (MalidriveLoad) correctly. Fails:

    Traceback (most recent call last):
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne-demos/bin/delphyne-mali2", line 9, in <module>
    delphyne_demos.demos.mali2.main()
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne-demos/lib/python3.6/site-packages/delphyne_demos/demos/mali2.py", line 294, in main
    time_step=sim_runner_time_step
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne/lib/python3.6/site-packages/delphyne/trees.py", line 37, in setup
    simulation=builder.build(),
    IndexError: vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)

• Town04 (SOLVED: Agent was being spawned on a non-driveable lane)

  • Tolerance: 7e-2
  • Map is loaded (MalidriveLoad) correctly. Fails:

    Traceback (most recent call last):
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne-demos/bin/delphyne-mali2", line 9, in <module>
    delphyne_demos.demos.mali2.main()
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne-demos/lib/python3.6/site-packages/delphyne_demos/demos/mali2.py", line 294, in main
    time_step=sim_runner_time_step
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne/lib/python3.6/site-packages/delphyne/trees.py", line 34, in setup
    super().setup(builder=builder, **kwargs)
    File "/opt/ros/dashing/lib/python3.6/site-packages/py_trees/trees.py", line 300, in setup
    **kwargs
    File "/opt/ros/dashing/lib/python3.6/site-packages/py_trees/trees.py", line 87, in setup
    visited_setup()
    File "/opt/ros/dashing/lib/python3.6/site-packages/py_trees/trees.py", line 82, in visited_setup
    node.setup(**kwargs)
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne/lib/python3.6/site-packages/delphyne/behaviours/agents.py", line 132, in setup
    nominal_speed=self.nominal_speed                  # nominal_speed (m/s)
    TypeError: __init__(): incompatible constructor arguments. The following argument types are supported:
    1. delphyne.agents.RailCarBlueprint(name: str, lane: maliput.api.Lane, direction_of_travel: bool, longitudinal_position: float, lateral_offset: float, speed: float, nominal_speed: float)
    Invoked with: kwargs: name='car', lane=None, direction_of_travel=True, longitudinal_position=0.0, lateral_offset=0.0, speed=15.0, nominal_speed=20.0

• Town06: (SOLVED: Agent was being spawned on a non-driveable lane) (EDITED)

  • Tolerance: 5e-2
  • Map is loaded (MalidriveLoad) correctly. Fails:

    EDITED

• Town07:

  • Tolerance: 5e-2
  • Map is loaded (MalidriveLoad) correctly. Fails:

Traceback (most recent call last):
  File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne-demos/bin/delphyne-mali2", line 9, in <module>
    delphyne_demos.demos.mali2.main()
  File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne-demos/lib/python3.6/site-packages/delphyne_demos/demos/mali2.py", line 294, in main
    time_step=sim_runner_time_step
  File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne/lib/python3.6/site-packages/delphyne/trees.py", line 37, in setup
    simulation=builder.build(),
IndexError: vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)

• RRLongRoad:
  • Tolerance: 1e-3
  • Map is loaded correctly.
  • Agent's spawned at 00-4 () Fails:

    
    Traceback (most recent call last):
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne-demos/bin/delphyne-mali2", line 9, in <module>
    delphyne_demos.demos.mali2.main()
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne-demos/lib/python3.6/site-packages/delphyne_demos/demos/mali2.py", line 294, in main
    time_step=sim_runner_time_step
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne/lib/python3.6/site-packages/delphyne/trees.py", line 42, in setup
    simulation=builder.build(),
    RuntimeError: Failure at /home/franco/Worskpace/RoadNetwork/tri_ws/src/malidrive/src/malidrive/road_curve/malidrive_road_curve.cc:120 in Orientation(): condition 'prh.x() >= ground_curve_->p0() && prh.x() <= ground_curve_->p1()' failed.

 - **Highway**: (**SOLVED: Agent was being spawned on a non-driveable lane**) (EDITED)
    - Tolerance: 1e-3
    - Map is loaded (MalidriveLoad) correctly.
Fails:

EDITED

[francocipollone]

Town03's error

• Town03:
  • Tolerance: 5e-2
  • Map is loaded (MalidriveLoad) correctly. Fails:

    Traceback (most recent call last):
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne-demos/bin/delphyne-mali2", line 9, in <module>
    delphyne_demos.demos.mali2.main()
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne-demos/lib/python3.6/site-packages/delphyne_demos/demos/mali2.py", line 294, in main
    time_step=sim_runner_time_step
    File "/home/franco/Worskpace/RoadNetwork/tri_ws/install/delphyne/lib/python3.6/site-packages/delphyne/trees.py", line 37, in setup
    simulation=builder.build(),
    IndexError: vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)

I narrowed down the error and it led me to mesh creation:

It fails within the method RenderSegment in the maliput/utilities/generate_obj.cc file when building meshes for Segment Id: 62_0.

<road name="Road 62" length="1.0030283729747680e-2" id="62" junction="-1">

I see two interesting things:

• Road62'lengths is smaller than linear tolerance.
• The Road doesn't have driveable lanes. I am not sure if it could lead to a problem and mesh creation level. I have to check it

[agalbachicar]

Have you tried it with the simplification?

[francocipollone]

Have you tried it with the simplification?

Yes! Same error.

[francocipollone]

Town03 - Continue

I've found why it fails. Given that there are no driveable lanes within Segment Id: 62_0 an out-of-range occurs when calling segment->lane(0) in RenderSegment method in: maliput/utilites/generate_obj.cc

~I guess~ It is confirmed that Town07 fails because of the same thing.

[francocipollone]

RRLongRoad - continue RRLongRoad: Tolerance: 1e-3 Map is loaded correctly. Error when creating meshes. Agent's spawned at 00-4 ()

RuntimeError: Failure at /home/franco/Worskpace/RoadNetwork/tri_ws/src/malidrive/src/malidrive/road_curve/malidrive_road_curve.cc:120 in Orientation(): condition 'prh.x() >= ground_curve_->p0() && prh.x() <= ground_curve_->p1()' failed.

Relaxing the tolerance to 5e-2 this error is avoided. However, I will dig deeper here in order to avoid this throw even when the tolerance is smaller.

[francocipollone]

RRLongRoad - continue RRLongRoad: Tolerance: 1e-3 Map is loaded correctly. Error when creating meshes.

Error in line: https://github.com/ToyotaResearchInstitute/malidrive/blob/183948c640fe5dcf0d1e0051f71b4965b3e62cb6/src/malidrive/road_curve/malidrive_road_curve.cc#L120

Values of p0, p, and p1.

MalidriveLane id: 6_0_-4
p0: 0  p: 483.354320243623   p1: 483.353981561629

I couldn't reveal the origin of this numerical issue yet.

---

Appendix This Road has a particularity. It is composed of 94 geometries. https://github.com/ToyotaResearchInstitute/malidrive/blob/183948c640fe5dcf0d1e0051f71b4965b3e62cb6/resources/RRLongRoad.xodr#L969-L1258

Simplification doesn't sort out the problem.

Note: Relaxing the tolerance to 5e-2 this error is avoided.

[francocipollone]

Based on this comment: https://github.com/ToyotaResearchInstitute/malidrive/issues/618#issuecomment-704278288 (Issue with cloverleaf map)

The elevation and superelevation functions described in the XODR description will also play an important role when selecting an appropriate tolerance. Given that we are demanding contiguity when elevation or superelevation is piecewise-defined.

[francocipollone]

As we are supporting maps with a lateral shift of the road reference line ( laneOffset records of the XODR different than zero) another variable enters the equation when selecting an appropriate tolerance for the loading. Contiguity of the offset description.

I raise this because I found an interesting discontinuity in the offset description of Town03 in the RoadId 847.

<laneOffset s="0.0000000000000000e+0" a="6.6349999999999998e+0" b="0.0000000000000000e+0" c="0.0000000000000000e+0" d="0.0000000000000000e+0"/>
<laneOffset s="1.1837467941303236e+1" a="6.6349999999999998e+0" b="0.0000000000000000e+0" c="0.0000000000000000e+0" d="0.0000000000000000e+0"/>
<laneOffset s="1.4335927289340910e+1" a="6.3500000000000001e-1" b="0.0000000000000000e+0" c="0.0000000000000000e+0" d="0.0000000000000000e+0"/>

There is no need to do math here given that the three descriptions are constant (only a coefficient). One visible issue is happening between the second and the third offset description:

• the second function ends with a value of 6.6349999999999998e+0
• the third function starts with a value of 6.3500000000000001e-1

A major difference of about 6 units.

---

In cloverleaf it is also possible to find this issue: https://github.com/ToyotaResearchInstitute/malidrive/issues/618#issuecomment-705833586

---

Same thing happens in Town04 in the RoadId 859:

            <laneOffset s="0.0000000000000000e+0" a="0.0000000000000000e+0" b="0.0000000000000000e+0" c="0.0000000000000000e+0" d="0.0000000000000000e+0"/>
            <laneOffset s="3.8276944838791621e+1" a="1.4000000000000043e+1" b="0.0000000000000000e+0" c="0.0000000000000000e+0" d="0.0000000000000000e+0"/>
            <laneOffset s="3.8729657523174353e+1" a="1.4000000000000043e+1" b="0.0000000000000000e+0" c="0.0000000000000000e+0" d="0.0000000000000000e+0"/>

There is no continuity between the first and second polynomial.

---

Same thing happens int Town05 in the RoadId 1230:

            <laneOffset s="0.0000000000000000e+0" a="-3.4999999999999689e+0" b="0.0000000000000000e+0" c="0.0000000000000000e+0" d="0.0000000000000000e+0"/>
            <laneOffset s="4.8592277044036791e-2" a="-3.4999999999999689e+0" b="0.0000000000000000e+0" c="0.0000000000000000e+0" d="0.0000000000000000e+0"/>
            <laneOffset s="9.7192089618474142e-2" a="-3.4999999999999689e+0" b="0.0000000000000000e+0" c="0.0000000000000000e+0" d="0.0000000000000000e+0"/>
            <laneOffset s="1.4578435912737575e-1" a="0.0000000000000000e+0" b="0.0000000000000000e+0" c="0.0000000000000000e+0" d="0.0000000000000000e+0"/>

There is no continuity between the third and fourth polynomial.

[francocipollone]

At the moment, in order to summarize, the following shows the problems that the loader/builder needs to elegantly solve (if it is possible):

• Gaps within a XODR Road.
• Tiny adjacent geometries within a XODR Road.
• Contiguity failure in the elevation description.
• Contiguity failure in the superelevation description.
• Contiguity failure in the laneOffset description.

All these issues were obtained from testing real maps.

[francocipollone]

• Continuity failure because of a mismatch in the derivative value of the piecewise-defined function of the elevation profile.

It triggers the necessity to also query the derivative of the elevation(and superelevation?). --> Related to https://github.com/ToyotaResearchInstitute/malidrive/issues/649

[agalbachicar]

This feature request is no longer needed. #77 was merged and we don't need to split tolerances anymore