Why PDM planner is providing trajectories which the first state doesn't match with the ego current state?

[cfcv]

Hi,

I noticed that inside the planner (get_closed_loop_trajectory) we have two types one trajectory:

1. proposals_array which don't start at ego current state and are later extended from 4s to 8s (41 poses -> 81 poses as 10Hz is used as frequency) https://github.com/autonomousvision/tuplan_garage/blob/5dd9206e056c86ca857843830b8fc793a76f815a/tuplan_garage/planning/simulation/planner/pdm_planner/abstract_pdm_closed_planner.py#L160 https://github.com/autonomousvision/tuplan_garage/blob/5dd9206e056c86ca857843830b8fc793a76f815a/tuplan_garage/planning/simulation/planner/pdm_planner/abstract_pdm_closed_planner.py#L187

2. simulated_proposals_array which are the same trajectories as proposals_array but starting at current ego pose and simulated using Bicycle model and LQRtracker, which are used for scoring. (and also have 81 poses) https://github.com/autonomousvision/tuplan_garage/blob/5dd9206e056c86ca857843830b8fc793a76f815a/tuplan_garage/planning/simulation/planner/pdm_planner/abstract_pdm_closed_planner.py#L165

What I am wondering is why return a trajectory that is not starting at ego current pose as starting point (extension of the best trajectory inside proposals_array) instead of using one trajectory that starts at ego position as in simulated_proposals? Is that done on purpose as part of a trick for the simulation?

Thanks in advance :)

[kashyap7x]

Since the LQR controller in the nuplan simulator is imperfect, returning the trajectory that starts at the ego position (as in simulated_proposals) leads to the planner executing a slightly different trajectory, which may contain errors that were not considered during scoring. This would be the preferred option only when using a highly accurate (or perfect) controller.

Since the trajectory in the proposals_array is already simulated with an LQR controller before scoring, we know that returning this trajectory to the nuplan simulator will result in driving behavior similar to what was observed in the simulated_proposal, which means our scoring becomes more reliable.

The high-level idea behind this design choice is to enable lateral control via a path (i.e., centerline) instead of a trajectory (which is highly dependent on the ego pose). Using path-based lateral control was also successful for the winning entries of the recent CARLA challenge, both on the sensor track and map track.

[DanielDauner]

Quick follow-up on Kashyap’s response. Also, the output trajectory of the original IDM implementation projects the initial ego state on the centerline (see here). We maintained this (for proposals_array and the final trajectory) because lateral controller errors from the lane center aren’t accumulated, resulting in closed-loop stability. We still score each proposal based on the expected closed-loop simulation outcome. The closed-loop movement starts at the ego position, as does simulated_proposals_array. Thanks for pointing this out. I hope you found our responses helpful 🙂

[cfcv]

Thank you @kashyap7x @DanielDauner for the answers! Now it is clearer :)