map_based_prediction

Role

map_based_prediction is a module to predict the future paths (and their probabilities) of other vehicles and pedestrians according to the shape of the map and the surrounding environment.

Assumptions

• The following information about the target obstacle is needed
  • Label (type of person, car, etc.)
  • The object position in the current time and predicted position in the future time.
• The following information about the surrounding environment is needed
  • Road network information with Lanelet2 format

Inner-workings / Algorithms

Flow chart

Path prediction for road users

Remove old object history

Store time-series data of objects to determine the vehicle’s route and to detect lane change for several duration. Object Data contains the object’s position, speed, and time information.

Get current lanelet and update Object history

Search one or more lanelets satisfying the following conditions for each target object and store them in the ObjectData.

• The CoG of the object must be inside the lanelet.
• The centerline of the lanelet must have two or more points.
• The angle difference between the lanelet and the direction of the object must be within the threshold given by the parameters.
  • The angle flip is allowed, the condition is diff_yaw < threshold or diff_yaw > pi - threshold.
• The lanelet must be reachable from the lanelet recorded in the past history.

Get predicted reference path

• Get reference path:
  • Create a reference path for the object from the associated lanelet.
• Predict object maneuver:
  • Generate predicted paths for the object.
  • Assign probability to each maneuver of Lane Follow, Left Lane Change, and Right Lane Change based on the object history and the reference path obtained in the first step.
  • Lane change decision is based on two domains:
    • Geometric domain: the lateral distance between the center of gravity of the object and left/right boundaries of the lane.
    • Time domain: estimated time margin for the object to reach the left/right bound.

The conditions for left lane change detection are:

• Check if the distance to the left lane boundary is less than the distance to the right lane boundary.
• Check if the distance to the left lane boundary is less than a dist_threshold_to_bound_.
• Check if the lateral velocity direction is towards the left lane boundary.
• Check if the time to reach the left lane boundary is less than time_threshold_to_bound_.

Lane change logics is illustrated in the figure below.An example of how to tune the parameters is described later.

• Calculate object probability:
  • The path probability obtained above is calculated based on the current position and angle of the object.
• Refine predicted paths for smooth movement:
  • The generated predicted paths are recomputed to take the vehicle dynamics into account.
  • The path is calculated with minimum jerk trajectory implemented by 4th/5th order spline for lateral/longitudinal motion.

Tuning lane change detection logic

Currently we provide three parameters to tune lane change detection:

• dist_threshold_to_bound_: maximum distance from lane boundary allowed for lane changing vehicle
• time_threshold_to_bound_: maximum time allowed for lane change vehicle to reach the boundary
• cutoff_freq_of_velocity_lpf_: cutoff frequency of low pass filter for lateral velocity

You can change these parameters in rosparam in the table below.

param name	default value
dist_threshold_for_lane_change_detection	1.0 [m]
time_threshold_for_lane_change_detection	5.0 [s]
cutoff_freq_of_velocity_for_lane_change_detection	0.1 [Hz]

Tuning threshold parameters

Increasing these two parameters will slow down and stabilize the lane change estimation.

Normally, we recommend tuning only time_threshold_for_lane_change_detection because it is the more important factor for lane change decision.

Tuning lateral velocity calculation

Lateral velocity calculation is also a very important factor for lane change decision because it is used in the time domain decision.

The predicted time to reach the lane boundary is calculated by

\[t_{predicted} = \dfrac{d_{lat}}{v_{lat}}\]

where $d_{lat}$ and $v_{lat}$ represent the lateral distance to the lane boundary and the lateral velocity, respectively.

Lowering the cutoff frequency of the low-pass filter for lateral velocity will make the lane change decision more stable but slower. Our setting is very conservative, so you may increase this parameter if you want to make the lane change decision faster.

For the additional information, here we show how we calculate lateral velocity.

lateral velocity calculation method	equation	description
[applied] time derivative of lateral distance	$\dfrac{\Delta d_{lat}}{\Delta t}$	Currently, we use this method to deal with winding roads. Since this time differentiation easily becomes noisy, we also use a low-pass filter to get smoothed velocity.
[not applied] Object Velocity Projection to Lateral Direction	$v_{obj} \sin(\theta)$	Normally, object velocities are less noisy than the time derivative of lateral distance. But the yaw difference $\theta$ between the lane and object directions sometimes becomes discontinuous, so we did not adopt this method.

Currently, we use the upper method with a low-pass filter to calculate lateral velocity.

Path generation

Path generation is generated on the frenet frame. The path is generated by the following steps:

1. Get the frenet frame of the reference path.
2. Generate the frenet frame of the current position of the object and the finite position of the object.
3. Optimize the path in each longitudinal and lateral coordinate of the frenet frame. (Use the quintic polynomial to fit start and end conditions.)
4. Convert the path to the global coordinate.

See paper [2] for more details.

Tuning lateral path shape

lateral_control_time_horizon parameter supports the tuning of the lateral path shape. This parameter is used to calculate the time to reach the reference path. The smaller the value, the more the path will be generated to reach the reference path quickly. (Mostly the center of the lane.)

Pruning predicted paths with lateral acceleration constraint (for vehicle obstacles)

It is possible to apply a maximum lateral acceleration constraint to generated vehicle paths. This check verifies if it is possible for the vehicle to perform the predicted path without surpassing a lateral acceleration threshold max_lateral_accel when taking a curve. If it is not possible, it checks if the vehicle can slow down on time to take the curve with a deceleration of min_acceleration_before_curve and comply with the constraint. If that is also not possible, the path is eliminated.

Currently we provide three parameters to tune the lateral acceleration constraint:

• check_lateral_acceleration_constraints_: to enable the constraint check.
• max_lateral_accel_: max acceptable lateral acceleration for predicted paths (absolute value).
• min_acceleration_before_curve_: the minimum acceleration the vehicle would theoretically use to slow down before a curve is taken (must be negative).

You can change these parameters in rosparam in the table below.

param name	default value
check_lateral_acceleration_constraints	false [bool]
max_lateral_accel	2.0 [m/s^2]
min_acceleration_before_curve	-2.0 [m/s^2]

Using Vehicle Acceleration for Path Prediction (for Vehicle Obstacles)

By default, the map_based_prediction module uses the current obstacle’s velocity to compute its predicted path length. However, it is possible to use the obstacle’s current acceleration to calculate its predicted path’s length.

Decaying Acceleration Model

Since this module tries to predict the vehicle’s path several seconds into the future, it is not practical to consider the current vehicle’s acceleration as constant (it is not assumed the vehicle will be accelerating for prediction_time_horizon seconds after detection). Instead, a decaying acceleration model is used. With the decaying acceleration model, a vehicle’s acceleration is modeled as:

$\ a(t) = a_{t0} \cdot e^{-\lambda \cdot t} $

where $\ a_{t0} $ is the vehicle acceleration at the time of detection $\ t0 $, and $\ \lambda $ is the decay constant $\ \lambda = \ln(2) / hl $ and $\ hl $ is the exponential’s half life.

Furthermore, the integration of $\ a(t) $ over time gives us equations for velocity, $\ v(t) $ and distance $\ x(t) $ as:

$\ v(t) = v{t0} + a{t0} * (1/\lambda) \cdot (1 - e^{-\lambda \cdot t}) $

and

$\ x(t) = x{t0} + (v{t0} + a{t0} * (1/\lambda)) \cdot t + a{t0}(1/λ^2)(e^{-\lambda \cdot t} - 1) $

With this model, the influence of the vehicle’s detected instantaneous acceleration on the predicted path’s length is diminished but still considered. This feature also considers that the obstacle might not accelerate past its road’s speed limit (multiplied by a tunable factor).

Currently, we provide three parameters to tune the use of obstacle acceleration for path prediction:

• use_vehicle_acceleration: to enable the feature.
• acceleration_exponential_half_life: The decaying acceleration model considers that the current vehicle acceleration will be halved after this many seconds.
• speed_limit_multiplier: Set the vehicle type obstacle’s maximum predicted speed as the legal speed limit in that lanelet times this value. This value should be at least equal or greater than 1.0.

You can change these parameters in rosparam in the table below.

Param Name	Default Value
use_vehicle_acceleration	false [bool]
acceleration_exponential_half_life	2.5 [s]
speed_limit_multiplier	1.5 []

Path prediction for crosswalk users

This module treats Pedestrians and Bicycles as objects using the crosswalk, and outputs prediction path based on map and estimated object’s velocity, assuming the object has intention to cross the crosswalk, if the objects satisfies at least one of the following conditions:

• move toward the crosswalk
• stop near the crosswalk

If there are a reachable crosswalk entry points within the prediction_time_horizon and the objects satisfies above condition, this module outputs additional predicted path to cross the opposite side via the crosswalk entry point.

This module takes into account the corresponding traffic light information. When RED signal is indicated, we assume the target object will not walk across. In addition, if the target object is stopping (not moving) against GREEN signal, we assume the target object will not walk across either. This prediction comes from the assumption that the object should move if the traffic light is green and the object is intended to cross.

If the target object is inside the road or crosswalk, this module outputs one or two additional prediction path(s) to reach exit point of the crosswalk. The number of prediction paths are depend on whether object is moving or not. If the object is moving, this module outputs one prediction path toward an exit point that existed in the direction of object’s movement. One the other hand, if the object has stopped, it is impossible to infer which exit points the object want to go, so this module outputs two prediction paths toward both side exit point.

Inputs / Outputs

Input

Name	Type	Description
~/perception/object_recognition/tracking/objects	autoware_perception_msgs::msg::TrackedObjects	tracking objects without predicted path.
~/vector_map	autoware_map_msgs::msg::LaneletMapBin	binary data of Lanelet2 Map.
~/perception/traffic_light_recognition/traffic_signals	autoware_perception_msgs::msg::TrafficLightGroupArray	rearranged information on the corresponding traffic lights

Output

Name	Type	Description
~/input/objects	autoware_perception_msgs::msg::TrackedObjects	tracking objects. Default is set to /perception/object_recognition/tracking/objects
~/output/objects	autoware_perception_msgs::msg::PredictedObjects	tracking objects with predicted path.
~/objects_path_markers	visualization_msgs::msg::MarkerArray	marker for visualization.
~/debug/processing_time_ms	std_msgs::msg::Float64	processing time of this module.
~/debug/cyclic_time_ms	std_msgs::msg::Float64	cyclic time of this module.

Parameters

Parameter	Unit	Type	Description
prediction_time_horizon	[s]	double	predict time duration for predicted path
lateral_control_time_horizon	[s]	double	time duration for predicted path will reach the reference path (mostly center of the lane)
prediction_sampling_delta_time	[s]	double	sampling time for points in predicted path
min_velocity_for_map_based_prediction	[m/s]	double	apply map-based prediction to the objects with higher velocity than this value
min_crosswalk_user_velocity	[m/s]	double	minimum velocity used when crosswalk user’s velocity is calculated
max_crosswalk_user_delta_yaw_threshold_for_lanelet	[rad]	double	maximum yaw difference between crosswalk user and lanelet to use in path prediction for crosswalk users
dist_threshold_for_searching_lanelet	[m]	double	The threshold of the angle used when searching for the lane to which the object belongs
delta_yaw_threshold_for_searching_lanelet	[rad]	double	The threshold of the angle used when searching for the lane to which the object belongs
sigma_lateral_offset	[m]	double	Standard deviation for lateral position of objects
sigma_yaw_angle_deg	[deg]	double	Standard deviation yaw angle of objects
object_buffer_time_length	[s]	double	Time span of object history to store the information
history_time_length	[s]	double	Time span of object information used for prediction
prediction_time_horizon_rate_for_validate_shoulder_lane_length	[-]	double	prediction path will disabled when the estimated path length exceeds lanelet length. This parameter control the estimated path length

Assumptions / Known limits

• For object types of passenger car, bus, and truck
  • The predicted path of the object follows the road structure.
  • For the object not being on any roads, the predicted path is generated by just a straight line prediction.
  • For the object on a lanelet but moving in a different direction of the road, the predicted path is just straight.
  • Vehicle dynamics may not be properly considered in the predicted path.
• For object types of person and motorcycle
  • The predicted path is generated by just a straight line in all situations except for “around crosswalk”.
• For all obstacles
  • In the prediction, the vehicle motion is assumed to be a constant velocity due to a lack of acceleration information.

Reference

1. M. Werling, J. Ziegler, S. Kammel, and S. Thrun, “Optimal trajectory generation for dynamic street scenario in a frenet frame,” IEEE International Conference on Robotics and Automation, Anchorage, Alaska, USA, May 2010.
2. A. Houenou, P. Bonnifait, V. Cherfaoui, and Wen Yao, “Vehicle trajectory prediction based on motion model and maneuver recognition,” in 2013 IEEE/RSJ International Conference on Intelligent Robots and Systems. IEEE, nov 2013, pp. 4363-4369.

Changelog for package autoware_map_based_prediction

0.43.0 (2025-03-21)

• Merge remote-tracking branch 'origin/main' into chore/bump-version-0.43
• chore: rename from [autoware.universe]{.title-ref} to [autoware_universe]{.title-ref} (#10306)
• Contributors: Hayato Mizushima, Yutaka Kondo

0.42.0 (2025-03-03)

• Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
• feat(autoware_utils): replace autoware_universe_utils with autoware_utils (#10191)
• chore(autoware_map_based_prediction): delete unused function and parameter (#10090)
• Contributors: Fumiya Watanabe, Tomoya Kimura, 心刚

0.41.2 (2025-02-19)

• chore: bump version to 0.41.1 (#10088)
• Contributors: Ryohsuke Mitsudome

0.41.1 (2025-02-10)

0.41.0 (2025-01-29)

• Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
• fix(map_based_prediction): fix unintentional accumulation of lanelets (#9950) add clear before insert
• feat: tier4_debug_msgs changed to autoware_internal_debug_msgs in fil… (#9875) feat: tier4_debug_msgs changed to autoware_internal_debug_msgs in files perception/autoware_map_based_prediction
• Contributors: Fumiya Watanabe, Masaki Baba, Vishal Chauhan

0.40.0 (2024-12-12)

• Merge branch 'main' into release-0.40.0
• Revert "chore(package.xml): bump version to 0.39.0 (#9587)" This reverts commit c9f0f2688c57b0f657f5c1f28f036a970682e7f5.
• fix: fix ticket links in CHANGELOG.rst (#9588)
• chore(package.xml): bump version to 0.39.0 (#9587)
  • chore(package.xml): bump version to 0.39.0
  • fix: fix ticket links in CHANGELOG.rst

  * fix: remove unnecessary diff ---------Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>

• fix: fix ticket links in CHANGELOG.rst (#9588)
• fix(cpplint): include what you use - perception (#9569)
• fix(autoware_map_based_prediction): msg namespace (#9553)
• 0.39.0
• update changelog
• Merge commit '6a1ddbd08bd' into release-0.39.0
• fix: fix ticket links to point to https://github.com/autowarefoundation/autoware_universe (#9304)
• fix: fix ticket links to point to https://github.com/autowarefoundation/autoware_universe (#9304)
• chore(package.xml): bump version to 0.38.0 (#9266) (#9284)
  • unify package.xml version to 0.37.0
  • remove system_monitor/CHANGELOG.rst
  • add changelog

  * 0.38.0

• refactor(map_based_prediction): move member functions to utils (#9225)
• refactor(map_based_prediction): divide objectsCallback (#9219)
• refactor(autoware_map_based_prediction): split pedestrian and bicycle predictor (#9201)
  • refactor: grouping functions
  • refactor: grouping parameters
  • refactor: rename member road_users_history to road_users_history_
  • refactor: separate util functions
  • refactor: Add predictor_vru.cpp and utils.cpp to map_based_prediction_node
  • refactor: Add explicit template instantiation for removeOldObjectsHistory function
  • refactor: Add tf2_geometry_msgs to data_structure
  • refactor: Remove unused variables and functions in map_based_prediction_node.cpp
  • Update perception/autoware_map_based_prediction/include/map_based_prediction/predictor_vru.hpp
  • Apply suggestions from code review

  * style(pre-commit): autofix ---------Co-authored-by: Mamoru Sobue <<hilo.soblin@gmail.com>> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]\@users.noreply.github.com>

• Contributors: Amadeusz Szymko, Esteve Fernandez, Fumiya Watanabe, M. Fatih Cırıt, Mamoru Sobue, Ryohsuke Mitsudome, Taekjin LEE, Yutaka Kondo

0.39.0 (2024-11-25)

• Merge commit '6a1ddbd08bd' into release-0.39.0
• fix: fix ticket links to point to https://github.com/autowarefoundation/autoware_universe (#9304)
• fix: fix ticket links to point to https://github.com/autowarefoundation/autoware_universe (#9304)
• chore(package.xml): bump version to 0.38.0 (#9266) (#9284)
  • unify package.xml version to 0.37.0
  • remove system_monitor/CHANGELOG.rst
  • add changelog

  * 0.38.0

• refactor(map_based_prediction): move member functions to utils (#9225)
• refactor(map_based_prediction): divide objectsCallback (#9219)
• refactor(autoware_map_based_prediction): split pedestrian and bicycle predictor (#9201)
  • refactor: grouping functions
  • refactor: grouping parameters
  • refactor: rename member road_users_history to road_users_history_
  • refactor: separate util functions
  • refactor: Add predictor_vru.cpp and utils.cpp to map_based_prediction_node
  • refactor: Add explicit template instantiation for removeOldObjectsHistory function
  • refactor: Add tf2_geometry_msgs to data_structure
  • refactor: Remove unused variables and functions in map_based_prediction_node.cpp
  • Update perception/autoware_map_based_prediction/include/map_based_prediction/predictor_vru.hpp
  • Apply suggestions from code review

  * style(pre-commit): autofix ---------Co-authored-by: Mamoru Sobue <<hilo.soblin@gmail.com>> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]\@users.noreply.github.com>

• Contributors: Esteve Fernandez, Mamoru Sobue, Taekjin LEE, Yutaka Kondo

0.38.0 (2024-11-08)

• unify package.xml version to 0.37.0
• refactor(autoware_map_based_prediction): refactoring lanelet path prediction and pose path conversion (#9104)
  • refactor: update predictObjectManeuver function parameters
  • refactor: update hash function for LaneletPath in map_based_prediction_node.hpp
  • refactor: path list rename
  • refactor: take the path conversion out of the lanelet prediction
  • refactor: lanelet possible paths
  • refactor: separate converter of lanelet path to pose path
  • refactor: block each path lanelet process
  • refactor: fix time keeper

  * Update perception/autoware_map_based_prediction/src/map_based_prediction_node.cpp ---------Co-authored-by: Mamoru Sobue <<hilo.soblin@gmail.com>>

• chore(autoware_map_based_prediction): add maintainers to package.xml (#9125) chore: add maintainers to package.xml The package.xml file was updated to include additional maintainers' email addresses.
• fix(autoware_map_based_prediction): adjust lateral duration when object is behind reference path (#8973) fix: adjust lateral duration when object is behind reference path
• refactor(autoware_interpolation): prefix package and namespace with autoware (#8088) Co-authored-by: kosuke55 <<kosuke.tnp@gmail.com>>
• feat(autoware_map_based_prediction): improve frenet path generation (#8811)
  • feat: calculate terminal d position based on playable width in path_generator.cpp

  * feat: Add width parameter path generations refactor(path_generator): improve backlash width calculation refactor(path_generator): improve backlash width calculation * fix: set initial point of Frenet Path to Cartesian Path conversion refactor: limit the d value to the radius for curved reference paths refactor: limit d value to curve limit for curved reference paths refactor: extend base_path_s with extrapolated base_path_x, base_path_y, base_path_z if min_s is negative refactor: linear path when object is moving backward feat: Update getFrenetPoint function to include target_path parameter The getFrenetPoint function in path_generator.hpp and path_generator.cpp has been updated to include a new parameter called target_path. This parameter is used to trim the reference path based on the starting segment index, allowing for more accurate calculations.

  • feat: Add interpolationLerp function for linear interpolation

  * Update starting_segment_idx type in getFrenetPoint function refactor: Update starting_segment_idx type in getFrenetPoint function refactor: Update getFrenetPoint function to include target_path parameter refactor: exclude target path determination logic from getFrenetPoint refactor: Add interpolationLerp function for quaternion linear interpolation refactor: remove redundant yaw height update refactor: Update path_generator.cpp to include object height in predicted_pose fix: comment out optimum target searcher * feat: implement a new optimization of target ref path search refactor: Update path_generator.cpp to include object height in predicted_pose refactor: measure performance refactor: remove comment-outs, measure times style(pre-commit): autofix refactor: move starting point search function to getPredictedReferencePath refactor: target segment index search parameter adjust * fix: replace nearest search to custom one for efficiency feat: Update CLOSE_LANELET_THRESHOLD and CLOSE_PATH_THRESHOLD values

  • refactor: getFrenetPoint blocks
  • chore: add comments

  * feat: Trim reference paths if optimum position is not found style(pre-commit): autofix chore: remove comment

  • fix: shadowVariable of time keeper pointers
  • refactor: improve backlash width calculation, parameter adjustment
  • fix: cylinder type object do not have y dimension, use x dimension
  • chore: add comment to explain an internal parameter 'margin'
  • chore: add comment of backlash calculation shortcut
  • chore: Improve readability of backlash to target shift model
  • feat: set the return width by the path width
  • refactor: separate a logic to searchProperStartingRefPathIndex function
  • refactor: search starting ref path using optional for return type
  • fix: object orientation calculation is added to the predicted path generation

  * chore: fix spell-check ---------

• revert(autoware_map_based_prediction): revert improve frenet path gen (#8808) Revert "feat(autoware_map_based_prediction): improve frenet path generation (#8602)" This reverts commit 67265bbd60c85282c1c3cf65e603098e0c30c477.
• feat(autoware_map_based_prediction): improve frenet path generation (#8602)
  • feat: calculate terminal d position based on playable width in path_generator.cpp

  * feat: Add width parameter path generations refactor(path_generator): improve backlash width calculation refactor(path_generator): improve backlash width calculation * fix: set initial point of Frenet Path to Cartesian Path conversion refactor: limit the d value to the radius for curved reference paths refactor: limit d value to curve limit for curved reference paths refactor: extend base_path_s with extrapolated base_path_x, base_path_y, base_path_z if min_s is negative refactor: linear path when object is moving backward feat: Update getFrenetPoint function to include target_path parameter The getFrenetPoint function in path_generator.hpp and path_generator.cpp has been updated to include a new parameter called target_path. This parameter is used to trim the reference path based on the starting segment index, allowing for more accurate calculations.

  • feat: Add interpolationLerp function for linear interpolation

  * Update starting_segment_idx type in getFrenetPoint function refactor: Update starting_segment_idx type in getFrenetPoint function refactor: Update getFrenetPoint function to include target_path parameter refactor: exclude target path determination logic from getFrenetPoint refactor: Add interpolationLerp function for quaternion linear interpolation refactor: remove redundant yaw height update refactor: Update path_generator.cpp to include object height in predicted_pose fix: comment out optimum target searcher * feat: implement a new optimization of target ref path search refactor: Update path_generator.cpp to include object height in predicted_pose refactor: measure performance refactor: remove comment-outs, measure times style(pre-commit): autofix refactor: move starting point search function to getPredictedReferencePath refactor: target segment index search parameter adjust * fix: replace nearest search to custom one for efficiency feat: Update CLOSE_LANELET_THRESHOLD and CLOSE_PATH_THRESHOLD values

  • refactor: getFrenetPoint blocks
  • chore: add comments

  * feat: Trim reference paths if optimum position is not found style(pre-commit): autofix chore: remove comment

  • fix: shadowVariable of time keeper pointers
  • refactor: improve backlash width calculation, parameter adjustment
  • fix: cylinder type object do not have y dimension, use x dimension
  • chore: add comment to explain an internal parameter 'margin'
  • chore: add comment of backlash calculation shortcut
  • chore: Improve readability of backlash to target shift model
  • feat: set the return width by the path width
  • refactor: separate a logic to searchProperStartingRefPathIndex function

  * refactor: search starting ref path using optional for return type ---------

• perf(autoware_map_based_prediction): replace pow (#8751)
• fix(autoware_map_based_prediction): output from screen to both (#8408)
• perf(autoware_map_based_prediction): removed duplicate findNearest calculations (#8490)
• perf(autoware_map_based_prediction): enhance speed by removing unnecessary calculation (#8471)
  • fix(autoware_map_based_prediction): use surrounding_crosswalks instead of external_surrounding_crosswalks

  * perf(autoware_map_based_prediction): enhance speed by removing unnecessary calculation ---------

• refactor(autoware_map_based_prediction): map based pred time keeper ptr (#8462)
  • refactor(map_based_prediction): implement time keeper by pointer
  • feat(map_based_prediction): set time keeper in path generator
  • feat: use scoped time track only when the timekeeper ptr is not null
  • refactor: define publish function to measure time
  • chore: add debug parameters for map-based prediction
  • chore: remove unnecessary ScopedTimeTrack instances

  * feat: replace member to pointer ---------

• fix(autoware_map_based_prediction): use surrounding_crosswalks instead of external_surrounding_crosswalks (#8467)
• perf(autoware_map_based_prediction): speed up map based prediction by using lru cache in convertPathType (#8461) feat(autoware_map_based_prediction): speed up map based prediction by using lru cache in convertPathType
• perf(map_based_prediction): improve world to map transform calculation (#8413) * perf(map_based_prediction): improve world to map transform calculation
  1. remove unused transforms

  2. make transform loading late as possible * perf(map_based_prediction): get transform only when it is necessary ---------

• perf(autoware_map_based_prediction): improve orientation calculation and resample converted path (#8427) * refactor: improve orientation calculation and resample converted path with linear interpolation Simplify the calculation of the orientation for each pose in the convertPathType function by directly calculating the sine and cosine of half the yaw angle. This improves efficiency and readability. Also, improve the resampling of the converted path by using linear interpolation for better performance. * Update perception/autoware_map_based_prediction/src/map_based_prediction_node.cpp Co-authored-by: Kotaro Uetake <<60615504+ktro2828@users.noreply.github.com>> * Update perception/autoware_map_based_prediction/src/map_based_prediction_node.cpp Co-authored-by: Kotaro Uetake <<60615504+ktro2828@users.noreply.github.com>> ---------Co-authored-by: Shumpei Wakabayashi <<42209144+shmpwk@users.noreply.github.com>> Co-authored-by: Kotaro Uetake <<60615504+ktro2828@users.noreply.github.com>>

• perf(map_based_prediction): apply lerp instead of spline (#8416) perf: apply lerp interpolation instead of spline
• revert (map_based_prediction): use linear interpolation for path conversion (#8400)" (#8417) Revert "perf(map_based_prediction): use linear interpolation for path conversion (#8400)" This reverts commit 147403f1765346be9c5a3273552d86133298a899.

• perf(map_based_prediction): use linear interpolation for path conversion (#8400) * refactor: improve orientation calculation in MapBasedPredictionNode Simplify the calculation of the orientation for each pose in the convertPathType function. Instead of using the atan2 function, calculate the sine and cosine of half the yaw angle directly. This improves the efficiency and readability of the code. * refactor: resample converted path with linear interpolation Improve the resampling of the converted path in the convertPathType function. Using linear interpolation for performance improvement. the mark indicates true, but the function resamplePoseVector implementation is opposite. chore: write comment about use_akima_slpine_for_xy ---------

• perf(map_based_prediction): create a fence LineString layer and use rtree query (#8406) use fence layer
• perf(map_based_prediction): remove unncessary withinRoadLanelet() (#8403)
• feat(map_based_prediction): filter surrounding crosswalks for pedestrians beforehand (#8388) fix withinAnyCroswalk
• fix(autoware_map_based_prediction): fix argument order (#8031) fix(autoware_map_based_prediction): fix argument order in call [getFrenetPoint()]{.title-ref} Co-authored-by: Shintaro Tomie <<58775300+Shin-kyoto@users.noreply.github.com>> Co-authored-by: Kotaro Uetake <<60615504+ktro2828@users.noreply.github.com>>
• feat(map_based_prediction): add time_keeper (#8176)
• fix(autoware_map_based_prediction): fix shadowVariable (#7934) fix:shadowVariable
• perf(map_based_prediction): remove query on all fences linestrings (#7237)
• fix(autoware_map_based_prediction): fix syntaxError (#7813)
  • fix(autoware_map_based_prediction): fix syntaxError
  • style(pre-commit): autofix
  • fix spellcheck
  • fix new cppcheck warnings

  * style(pre-commit): autofix ---------Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]\@users.noreply.github.com>

• feat: add [autoware_]{.title-ref} prefix to [lanelet2_extension]{.title-ref} (#7640)
• refactor(universe_utils/motion_utils)!: add autoware namespace (#7594)
• refactor(motion_utils)!: add autoware prefix and include dir (#7539) refactor(motion_utils): add autoware prefix and include dir
• feat(autoware_universe_utils)!: rename from tier4_autoware_utils (#7538) Co-authored-by: kosuke55 <<kosuke.tnp@gmail.com>>
• feat(map based prediction): use polling subscriber (#7397) feat(map_based_prediction): use polling subscriber
• refactor(map_based_prediction): prefix map based prediction (#7391)
• Contributors: Esteve Fernandez, Kosuke Takeuchi, Kotaro Uetake, Mamoru Sobue, Maxime CLEMENT, Onur Can Yücedağ, Ryuta Kambe, Taekjin LEE, Takamasa Horibe, Takayuki Murooka, Yukinari Hisaki, Yutaka Kondo, kminoda, kobayu858

0.26.0 (2024-04-03)