Skip to content

Refactor how lane_select publishes /base_waypoints

Ian Colwell requested to merge astuff/autoware.ai/core_planning:upstream/lane_select_cleanup into master

Base on our waypoint following demo using gnss localizer, we noticed /base_waypoints is published at a unnecessary rate of 100 Hz considering our planning is running at 10 Hz. Specifically, every update from current_pose and current_velocity will trigger the current /base_waypoints to be published. If both topics are published at a high rate (~50 Hz or even higher at ~100 Hz for a responsive control loop), the /base_waypoints will be published at the same rate. By using linux utility tool top, we also noticed the process consumes about 7% of one core cpu time on our Spectra PC. In summary, the topic /base_waypoints should only be updated when one of following conditions is satisfied:

  1. The subscribing /traffic_waypoints_array is updated (lane_array_id_ is changing).
  2. The current_lane_idx_ is changing as ego-vehicle is moving or decision_maker/state is changing (CHANGE_LANE)

See astuff/autoware.ai/core_planning!22 (merged) and astuff/autoware.ai/core_planning!33 (merged) for more details.

Merge request reports