Repository navigation
Conversation
…om feat/v0.64/e2e Import the following packages as-is from feat/v0.64/e2e (7719eb4): - planning/autoware_trajectory_modifier (unified modifier/optimizer node) - common/autoware_traffic_light_compliance_checker - common/autoware_obstacle_proximity_checker
…sient_local QoS Re-apply the trajectory_modifier part of #3628 on top of the e2e import so that the latched max_vel from external_velocity_limit_selector is received.
The hotfix version does not build against the imported trajectory_modifier utils (obstacle_stop API changes), so import it as-is from feat/v0.64/e2e (7719eb4).
|
|
||
| /// @brief type of traffic light violation | ||
| enum class ViolationType { RED_LIGHT, AMBER_LIGHT, V2I }; | ||
| enum class ViolationType { RED_LIGHT, AMBER_LIGHT }; |
There was a problem hiding this comment.
Changes related to V2I must remain in v4.4.0.1
V2I logic is not added in latest e2e branch, and is only implemented for v4.4.0.1 at the moment, so this cherry-pick PR should keep the logic.
Please refer to #3499
There was a problem hiding this comment.
Thank you for checking! I restored the V2I logic of #3499 (including signal_timeout) on top of the imported e2e code.
- universe (5cc5156): V2I logic in
traffic_light_compliance_checker/src/v2i_handling.cpp, with tests - autoware_launch.x2 (1ad83904b):
v2i_handling/signal_timeoutparams, same values as v4.4.0.1-hotfix
|
@kyo0221 Thanks for the folder import — I compared this PR ( Scope confirmationThis set is the unified Import SHA
Live launch chain (
|
| Plugin | vs hotfix | In launch plugin_names |
use_* after PR |
|---|---|---|---|
| Map / External vel, Surround, Obstacle, TL, VelocityModifier | already on hotfix | yes | ON |
| StopPointFixer | listed, was OFF | yes | OFF |
| Former optimizer plugins (TemporalMPT, PointFixer, KFE, QP, VelOpt, EB, Spline, MPT, Extender) | moved into this node | yes | all OFF |
TrajectoryTimeSequenceRawOptimizer |
new (not in old optimizer yaml) | yes | OFF (same as e2e) |
ModelPlanningFactorID |
new | yes | ON |
DetectionAreaStop |
new in plugins.xml |
not listed (e2e launch yaml also omits it) | — |
TrajectoryMppiOptimizer |
e2e has it ON | commented out | — |
Flag change vs old hotfix optimizer: use_trajectory_point_fixer was true on the separate optimizer node; unified launch yaml sets it false (matches e2e, not old hotfix). Point-fixer will stop running unless the flag is restored.
Hotfix autoware_mppi_optimizer is still a standalone node and has no trajectory_modifier_plugins.xml, so commenting MPPI is consistent.
Still un-cherry-picked along this pipeline
Working downstream from ML (not this PR’s job, but the remaining gap):
autoware_ml_planner— still hotfix (17 files vs e2e).#3145only adapted candidate-trajectory types. Launch still remaps MLoutput_turn_indicators→/planning/turn_indicators_cmd; e2e moved that to selector.- MPPI as a modifier plugin + e2e
mppi_optimizertree /mppi_optimizer.param.yaml. DetectionAreaStop— code in tree, not in launchplugin_names.- TSO / MPT / QP / … — code is in the unified node, all
use_*false (same as e2e). - MRBP — imported; launch default still off.
autoware_safety_planner— e2e-only backup generator.- Selector / validator / ranker / adapter — still the old 3-node chain. e2e inlined ranker, added validator diagnostics / crosswalk / feasibility / pointcloud collision, dropped
vehicle_constraint_filter. autoware_trajectory_validator+boundary_departure_checker— intentionally left on hotfix (as you noted).- Leftover
planning/autoware_trajectory_optimizerpackage on universe (deleted on e2e). Launch no longer starts it after feat(perception): apply new perception pipeline (#3008) #3034; consider deleting in a follow-up.
Please confirm before marking ready
- Point-fixer OFF vs old hotfix is intentional.
- Imported modifier does not need post-
#3145ranker/adapter/diffusion APIs at runtime (those packages are still far from e2e). - Keep
#3628QoS + remap to/planning/scenario_planning/max_velocity(do not drop with the e2e folder import). - Whether to delete leftover
autoware_trajectory_optimizerin this PR or a follow-up.
Core #143 / launch.x2 #3034 look aligned with this universe change. All three are still drafts; core and launch had no checks on the head branch when I looked.
Re-apply the V2I handling of #3499 on top of the trajectory_modifier imported from feat/v0.64/e2e. V2I is not on e2e, but it is enabled on v4.4.0.1 (use_v2i_remaining_time: true in the launcher), so keep it. - traffic_light_compliance_checker: add ViolationType::V2I, Parameters::v2i_handling and a use_v2i_remaining_time argument to check() (default false). The V2I logic lives in v2i_handling.cpp so that the rest of the checker stays identical to e2e. - traffic_light_stop: pass the V2I parameters to the checker and skip the check when the signals are older than signal_timeout. - Add signal_timeout and v2i_handling.* to param, struct and schema (V2I disabled by default). - Add V2I tests to the checker and a stale signal test to the plugin. Unlike #3499, allow_if_cannot_stop uses the distance from the ego front, as the e2e red and amber checks do (#3380).
|
@Owen-Liuyuxuan
Also, V2I (#3499) is now restored, as requested in another comment. |
|



変更内容
コンフリクトの解消
注意