Skip to content

Global Planner

Jump to bottom
Axel Böll edited this page Mar 30, 2022 · 7 revisions

Global Planner

Read XODR-File

XODR XML

We use the XODR-files for getting all information to plan and enhance our route. A XODR-File is a XML-Like file with inforamtion of all roads, lanes, sings and other usefull things.

Our Implementation

Instead of just using the middle line geometries from xodr-file, we save an geometry for each lanesection as it can be seen in the picture. Then we connect the geometry by setting weights between them and save it in a Matrix (example Road1_Lane1_Geo1 -> Road1_Lane1_Geo2).

After filling the Matrix we calculate with help of the dijkstra-algorithem the shortest path from start to the end position. Beforehead we calculate in witch point the start and end point is to be located. With this path we then calcualte the resulting waypoints and metadata. Afterwards we combine this two inforamtion and send it to the local planner.

Problems and achievements

With our implementation you have more oppertunites and slitly more information in comparison to lanelet2. But a lot of black magic is happening in the global planner and we recommend to use a different global planner or the one from the other group.

Details

Clearly Structured Code (Refactoring)

The XODR file parser uses Python dataclasses for type checking. As a side effect, the data structure is more tangible than before.

Moreover, the route planning was re-written and backed up with test cases to ensure everything works as expected (see following section).

1) Side-of-Road Detection / Bounding Box

  • Issue:
    • the function for computing the orthogonal offset was not rotating the vector by 90 deg
    • this leads to weirdly shaped polygons that behave differently than expected
  • Solution:
    • implement the 2D formula for rotating a vector
    • add some unit tests to back the logic up

2) Start / End Section Determination

  • Issue:
    • for route planning, the start and end point need to be assigned to road sections to run the planning algorithm
    • but: the bounding boxes were detecting more roads than expected (such as lanes of the oncoming traffic)
  • Solution:
    • call the bounding box computation with correct parameters
    • construct some test cases from a XODR map example

3) Insertion of Start / Target Position into Graph

  • Issue:
    • the map graph wasn't constructed correctly
    • for instance, there were incoming edges to the start position and outgoing edges from the target position
    • moreover, the edge weights were buggy as well, leading to weird route planning
  • Solution:
    • re-think the logic and implement it properly
    • test the behavior by planning some route examples

4) Simplified Edge Weights

  • Issue:
    • edge weights were computed by adding up distances of road geometries
    • but: this accuracy might not be needed and bloats the code unnecessarily
  • Solution:
    • just use the distance between the start / end point of the road

5) Putting the Route Together

  • Issue:
    • the logic for putting the route together was really messy (several hundred lines)
  • Solution:
    • re-write the logic in a way that actually makes sense
    • test the outcome by planning some routes

6) Route Point Interpolation

  • Issue:
    • the interpolated route might contain waypoints pointing backwards (which confused the vehicle controller)
  • Solution:
    • forbid overshooting the interpolation interval between 2 points by rounding with floor() instead of ceil()

Outcome

  • the route planner can create routes keeping the lane (don't drive into oncoming traffic)
  • the logic is a lot more robust and backed up by some tests
  • it's possible to make changes to the Global Planner in ongoing sprints by extending the logic

Outlook

  • there might be more accurate graph edge weights reflecting the actual time to drive a road
  • the XODR meta-data (e.g. location of traffic lights / signs) can be parsed and sent to the local planner
  • the route planning might be implemented as ROS service
  • for further detail, see #41, #42

First Draft Global Planner

Details

The global planner consists of the path Provider, Map Manager and a reinforcement learning part.

Path Provider:

Plans the route from the Start position to the destination with the given weighed edges from the Map Manager. After calculation the shortest path it sends the Route Info to the local planner.

Map Manger:

Saves and calculate weighed Edges and Route info and provide the map for Path Provider.

Reinforcement learning

Planned for later sprints

In every step the weight of a lanelet will be updated. Depending on the actual traffic situation and traffic light situation.

Input

  • Opendrive Map
  • Landmarks
  • Start/ Destination Position

Output

  • Route Info: List[Waypoint, actual-lane, possible-lanes, legal-speed, dist_next_Traffic_Light, end_of_Road_section, stop_sign_m]
Clone this wiki locally