ObstacleCruisePlanner_progress_update-20.08.24

progress.md

• Got review from yuki-takagi-66 autowarefoundation/autoware_universe#8072 (comment)

  • He reported some issues about stop planning. He tried prd_jt scenarios and observed some issues. I run these scenarios again in my local. I couldn't observe the problems.
  • I shared his outputs and my trials below:
    • 1. A stop wall is inserted against the object at the lane change destination.
      • Local Test of DistR_UC-v2-B-03-00001_001_case01_cmn_general:
      • https://youtu.be/mxt0gnIn8Qo
    • 2. A stop decision is made even though the ego can pass the collision point before the pedestrian (the pedestrian will stop).
      • Local Test of DistR_UC-v2-D-01-00004_004_case01_cmn_general:
      • https://youtu.be/1aZEU3FjuUI
    • 3. No stop wall against the in front object
      • Local Test of DistR_UC-v2-D-03-00002_002_case01_cmn_general:
      • https://youtu.be/x0jQfL7P6Pw

• Current implementation of the OCR, it filters all object if they are behind of the Ego. New filter mecanism developed, if the obstacle is behind of the ego, OCR may take into account the obstacle if its tangent velocity is higher than our velocity (It can overtake us, so we can start cruising while it comes from our behind.)

• Focused on not cruising if an obstacle overtakes us. Ismet shared the problem in https://github.com/orgs/autowarefoundation/discussions/5020 (2.1.9 Test - 9: Autonomous Drive on Route B at a Velocity of 30 km/h)

  • The problem is if a vehicle overtakes by using another lane, OCR start cruising very late. Why does not cruising I explained below:
    • OCR only looking for the highest confidence predicted path. The problem is if NPC comes from Lane A to Lane B, the highest confidence predicted path is on the Lane A for a long time. So OCR can not detect any collision points for NPC. I changed the algorithm to look for the first three predicted paths if the obstacle is outside of the trajectory. It worked well in my trials.
    • Another improvement made for filtering process of determining cruise obstacle. Current implementation filters objects if lateral distance is higher than some threshold value. I added another condition: Calculate lateral approaching velocity of object, then find the time_to_trajectory value. If object is approaching laterally to our trajectory, cruise planner take into account it. So, we can react early for these kind of obstacles.
  • Trial video: I couldn't record it some technical problems.