maliput / maliput_malidrive

Open-source ready OpenDrive backend for Maliput
BSD 3-Clause "New" or "Revised" License
1 stars 2 forks source link

Connectivity map verification in real XODR maps. #11

Open francocipollone opened 4 years ago

francocipollone commented 4 years ago

Context

Sometimes in the connectivity map of a Junction, the information is not complete, some possible connections are missing. (Although the OpenDrive standard says: "Junction record contains the information about all possible connections between roads meeting at a physical junction.")

And that is ok in almost all the maps because the information provided is enough to create a road map. The connections that must be described are those where the path is ambiguous.

To put an example I will use Town03 map:

This is the Road 847 that belongs to the junction 831:

    <road name="Road 847" length="2.7137343386939342e+1" id="847" junction="831">
        <link>
            <predecessor elementType="road" elementId="40" contactPoint="end"/>
            <successor elementType="road" elementId="27" contactPoint="start"/>
        </link>
        ...

So one would expect that in the connectivity map of the junction 831, the connections to the road 40(predecessor) and road 27(successor) to be described.

However, there is no reference to Road 27:

    <junction id="831" name="junction831">
        <connection id="0" incomingRoad="26" connectingRoad="833" contactPoint="start">
            <laneLink from="-2" to="-2"/>
            <laneLink from="-3" to="-3"/>
        </connection>
        <connection id="1" incomingRoad="26" connectingRoad="837" contactPoint="start">
            <laneLink from="-3" to="-3"/>
        </connection>
        <connection id="2" incomingRoad="40" connectingRoad="843" contactPoint="end">
            <laneLink from="-5" to="5"/>
            <laneLink from="-4" to="4"/>
        </connection>
        <connection id="3" incomingRoad="40" connectingRoad="846" contactPoint="start">
            <laneLink from="-4" to="-1"/>
        </connection>
        <connection id="4" incomingRoad="40" connectingRoad="847" contactPoint="start">
            <laneLink from="-5" to="-5"/>
        </connection>
    </junction>

When traversing Road 40 at the moment you hit the junction you have multiples paths. (So it is ambiguous, you need to know the possible paths.) But with Road 27, you only have one possible path and that is why that connection is not described. The connection that is missing could be added if it is needed, this would be:

        <connection id="4" incomingRoad="27" connectingRoad="847" contactPoint="end">
            <laneLink from="-2" to="-2"/>
        </connection>

But in practical terms, it is not needed, and many of the XODRs we have, don't provide this "obvious" connections.

Victory condition

Complement current RoadLinks verification in order to verify semantics and coherence between Junctions description and Road description.

agalbachicar commented 3 years ago

@francocipollone aren't we doing this already via the Validate functions in xodr?

francocipollone commented 3 years ago

@francocipollone aren't we doing this already via the Validate functions in xodr?

We are verifying the road linkage, yes. And we also are verifying that the described connections in the junction xodr node if the road belongs to a junction.

However when there are missing connections (https://github.com/ToyotaResearchInstitute/maliput_malidrive/issues/57) we are just logging it. We are not evaluating whether those missing connections are omitted because it is redundant(and there is no missing information to build the roads) or because there are actual errors when creating the xodr description.

agalbachicar commented 3 years ago

However when there are missing connections (#57) we are just logging it. We are not evaluating whether those missing connections are omitted because it is redundant(and there is no missing information to build the roads) or because there are actual errors when creating the xodr description

Right. This is done by the Solve* functions in builder_tools, right?

Alright, if that's the case there is still work to do for this task.