Save the goal pose if lanelet maps are not subscribed in mission planner

[TomohitoAndo]

Checklist

• [X] I've read the contribution guidelines.
• [X] I've searched other issues and no duplicate issues were found.
• [X] I've agreed with the maintainers that I can plan this task.

Description

Currently mission planner doesn't plan a path when goal pose was specified but lanelet maps are not subscribed. In situations where scenario simulation is used, the subscription order of goal pose and lanelet map is not fixed.

https://github.com/autowarefoundation/autoware.universe/blob/main/planning/mission_planner/lib/mission_planner_base.cpp#L107-L110

Purpose

Prevent mission planner from aborting if the goal pose was specified before the lanelet maps are subscribed.

Possible approaches

• Save the goal pose and use it when lanelet maps are subscribed.

Definition of done

• Mission planner can plan the path regardless of the subscription order of goal pose and lanelet maps

[mitsudome-r]

Are you sure you want this? I think it is more intuitive to have map first and the goal later. In case of scenario simulation, you can just look at the autoware_state and give goal pose after the state is waiting_for_route.

[TomohitoAndo]

@mitsudome-r Thank you for your comments. I think looking at the autoware_state is more suitable idea.

But since ad_service_state_monitor doesn't check if mission_planner has map, the issue of scenario simulation may sometimes occur. It looks like ad_service_state_monitor checks if map is published here, https://github.com/autowarefoundation/autoware.universe/blob/86101edd278bd572124995866d7fecf534830d21/system/ad_service_state_monitor/src/ad_service_state_monitor_node/state_machine.cpp#L237

and transit to WaitingForRoute state after waiting for one second. (I don't know what "sync error" means, but it may have something to do with the issue I mentioned.) https://github.com/autowarefoundation/autoware.universe/blob/86101edd278bd572124995866d7fecf534830d21/system/ad_service_state_monitor/src/ad_service_state_monitor_node/state_machine.cpp#L244-L251

So, I think increasing the value of wait_time_after_initializing is one way to address the issue I mentioned. Is this right?

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity.

[takayuki5168]

@mitsudome-r kindly ping

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity.