feature(waypoint_follower): provide a simpler method to record, store, and reuse driving waypoints without depending solely on lanelet maps

[JiaWeiLee-turing]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I'm convinced that this is not my fault but a bug.

Current Behavior

None

Expected Behavior

A simpler method to record, store, and reuse driving waypoints without depending solely on lanelet maps provides a lightweight alternative for managing routes. By directly capturing and reusing waypoints from driving sessions, it avoids the complexity of maintaining detailed maps while still enabling reliable navigation, quick testing, and flexible route validation.

Actual Behavior

Waypoint follower

The waypoint following architecture is designed as a dedicated scenario alongside lane driving and parking. A waypoint maker records odometry as waypoints at fixed intervals into CSV files, which can later be loaded to generate forward or reverse paths for execution. This scenario includes its own launch files and a motion velocity planner to handle obstacle cruise and stop functions. Waypoint following is triggered once the vehicle enters or aligns with the defined waypoint zone.

Scenario Gate

• The mission_planner dispatches to LaneDriving (behavior_path_planner, behavior_velocity_planner, motion_velocity_planner), Parking (freespace_planner), and optionally Extra Scenarios, each publishing /planning/scenario_planning//trajectory.
• All these trajectories are sent to scenario_gate. In this change, the original scenario selection logic is not modified. It is only wrapped as a default selector plugin, keeping the same behavior and interface.
• scenario_gate can load the selector as a plugin. By default, it uses the default selector, so the system works exactly as before. If needed, other selectors can also be loaded without changing existing code or topics.
• The final selected trajectory is published to /planning/scenario_planning/trajectory together with /planning/current_scenario, and then processed by velocity_smoother.

GUI

Waypoint Saver

• The GUI provides intuitive control with SAVE and FINISH buttons, making it simple for users to record waypoints.
• Users can configure the recording interval (default: 0.5 m), ensuring flexibility in waypoint density.
• Once recording starts with SAVE, the system shows the active file name and enables the FINISH button to conclude recording.
• The latest recorded file is automatically copied as waypoint_default.csv, so the Waypoint Loader can immediately reuse it without manual selection.
• This design reduces user operations, ensures consistency across sessions, and simplifies testing by always providing an up-to-date default waypoint file.

Waypoint Loader

• The GUI allows users to browse and select waypoint files from a designated folder, then load them with a single LOAD button.
• Once a file is loaded, it automatically becomes the new waypoint_default.csv, ensuring the system always uses the latest selected waypoints without extra user action.
• To enhance safety, the LOAD button is disabled while the vehicle is in motion, preventing accidental path switching during driving.
• This design simplifies waypoint management, reduces redundant operations, and ensures consistency between sessions.

Workflow

• It should setup a goal pose directly, and the system will generate a path to make the vehicle stop alongside waypoint zone.​
• When the vehicle is alongside or within waypoint zone, it will switch to waypoint following.​
• Once the waypoint following is completed, the system will switch back to lane driving or parking.​
• If a goal is set in waypoint zone, it is not supported. The waypoint zone is designed to follow a recorded path to path-through the area.

Versions

• OS: Ubuntu 22.04
• ROS2: Humble
• Autoware: Autoware.universe:main

[emmeyteja]

LGTM

[Owen-Liuyuxuan]

@JiaWeiLee-turing
I think this scheme of directly using waypoints is a good strategy and worth some refactoring. I would like to ask why we build it as an output from motion velocity smoother?

I think there are other options:

1. Waypoint maker output use shared motion velocity smoother or the behavior velocity planner.
2. Formulate the waypoint maker as a module in the behavior path planner.
3. Formulate the waypoint maker into the mission planner.

Personally I am quite interested in the third option. Could you elaborate more on your architecture design choices?

[JiaWeiLee-turing]

@NickYang-Turing
Could you please help answer this question?