watonomous.github.io

  1. Software Division
  2. Software Division Home

[ Software Division : Path Planning Code Flow May 2020 ]

Created by [ Charles Zhang] on May 13, 2020

Main local_planning ROS Node: 

https://git.uwaterloo.ca/WATonomous/decision/blob/develop/local_planning/ros_main.cpp

Inputs:

Main Loop: https://git.uwaterloo.ca/WATonomous/decision/blob/develop/local_planning/ros_main.cpp#L210

  1. Plan Lane level route (Global Interface)
  2. Evaluate behavioural planner (Behavioural Planner)
  3. Update dynamic object state (Occupiable Objects)
  4. Plan with Frenet
  5. Publish path to Controller (MPC/PID) (out of the scope of this document)

**Global Interface
**

  1. Takes` /path_planning/global_command`, which is a high level path traversing roads, and converts it to a low level path traversing lanes 
  2. Uses the HDM Interface defined in the localization node (https://git.uwaterloo.ca/WATonomous/localization/tree/develop/hdmap_processing/srv), Documentation: HDM Service
  3. Key API:
    1. GlobalInterface::planLaneRoute()
      Based on the list of link_ids in the global command (stored as a queue), update the current route so that it reaches to the next link id in the global command queue. If updating the current path is impossible, it will try to replan. If that again is impossible, it will throw and we publish a global reroute instruction
      Returns: The current LANE we are on, and the next lane we want to be on. If a lane change is required, the two lanes will be different. Otherwise, they will be the same.
    2. GlobalInterface::NearIntersection()
      Returns BOOL based on our distance to the next global command.
    3. LaneTopology& getTopology()Returns the Lane Topology (unordered_map of lane_id to Lane struct) as populated by the global interface during planning. Should be used in the behavioural planner to get lane information. Note RoadLines are physical lines on the ground. Lanes are the hypothetical grouping of two adjacent RoadLines that form a lane that we drive down the center of. Note the Lane class is an instance of std::vector, and contains the points denoting the center of that lane.
    4. Other generic API that i'm sure you can figure out
  4. Pseudocode for the main planning algorithm: https://git.uwaterloo.ca/WATonomous/decision/merge_requests/245 
  5.  PR for the global interface https://git.uwaterloo.ca/WATonomous/decision/merge_requests/253/diffs

Behavioural Planner

  1. Currently barely used and barely functional. Behavioural planner has a reference to the global interface and can thus access any of the global interface's APIs.
  2. Only functional and used bit of code is the code to decide which blinker to turn on (thanks ray)
  3. Useful Util: findClosestPolylineIndex(https://git.uwaterloo.ca/WATonomous/decision/blob/develop/behavioral/behavioral_planner.cpp#L31 )
    1. Does what the name and it's comment says. Broken since I modified the LaneTopology structure. Instead of taking a Vector<T>, it should take a Lane Topology
  4. State machine that Oswaldo wrote last year. Works, not being compiled right now. https://git.uwaterloo.ca/WATonomous/decision/blob/develop/behavioral/StateMachine.h 
  5. Documentation and ideas for the lane changing Behavioural planner from W20: Behavioral. Corresponding merge request: https://git.uwaterloo.ca/WATonomous/decision/merge_requests/243 
    1. Baseline idea is to modify the lane level path from Global Interface so that it avoid construction/blocked lanes and only makes the lane change when it's most reasonable and safe to do. READ THE DOCUMENTATION: Behavioral
    2. TODO: Integrate NearIntersection, Fix findClosestPolyline, Fix picking out the left/right

The HPP file could use some cleaning up. I've already commended out all the code in behavioural_planner.cpp

BehaviouralState, BehavioralPlannerStateManager, the constants,  and anything else related to the old behavioural planner should be deleted

Occupiable Objects

Unchanged since summer of 2020. We finally have the opportunity to test traffic lights in CARLA. Turns out, they don't work! Fix it (big grin) . There are also some dirty hacks since Processing tracking doesn't work at all. We're currently ignoring object IDs and assuming there's one of each object. This should be removed (Charles Zhang{.confluence-userlink .user-mention}) since we have reliable IDs in CARLA, and hopefully processing will get on their shit

Wiki: Occupiable Objects

Plan with Frenet

<TODO_BEN>

\

Document generated by Confluence on Dec 10, 2021 04:01

Atlassian