Remaining Distance and Time Calculator

Role

This package aims to provide mission remaining distance and remaining time calculations.

Activation and Timing

• The calculations are activated once we have a route planned for a mission in Autoware.
• The calculations are triggered timely based on the update_rate parameter.
• The calculations are skipped if the scenario is PARKING, and the remaining time and distance values are set to 0.0.

Module Parameters

Inner-workings

Remaining Distance Calculation

• The remaining distance calculation is based on getting the remaining shortest path between the current vehicle pose and goal pose using lanelet2 routing APIs.
• The remaining distance is calculated by summing the 2D length of remaining shortest path, with exception to current lanelet and goal lanelet.
  • For the current lanelet, the distance is calculated from the current vehicle position to the end of that lanelet.
  • For the goal lanelet, the distance is calculated from the start of the lanelet to the goal pose in this lanelet.
• When there is only one lanelet remaining, the distance is calculated by getting the 2D distance between the current vehicle pose and goal pose.
• Checks are added to handle cases when current lanelet, goal lanelet, or routing graph are not valid to prevent node process die.
  • In such cases when, last valid remaining distance and time are maintained.

Remaining Time Calculation

• The remaining time currently depends on a simple equation of motion by getting the maximum velocity limit.
• The remaining distance is calculated by dividing the remaining distance by the maximum velocity limit.
• A check is added to the remaining time calculation to make sure that maximum velocity limit is greater than zero. This prevents division by zero or getting negative time value.

Future Work

• Find a more efficient way for remaining distance calculation instead of regularly searching the graph for finding the remaining shortest path.
• Engage more sophisticated motion models for more accurate remaining time calculations.

Changelog for package autoware_remaining_distance_time_calculator

0.53.0 (2026-09-29)

• Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog

• fix(design): align the planning node designs with the packages they describe (#13342)

  * fix(design): align the planning node designs with the packages they describe HazardLightsSelector registers as HazardLightsSelector, and its second input maps to input/system/hazard_lights_command and carries the MRM command, so the port is named system_hazard_lights_cmd. SurroundObstacleChecker publishes the migrated autoware_internal_planning_msgs velocity limit types, and creates neither stop_reasons nor no_start_reason. RemainingDistanceTimeCalculator takes its velocity limit input through the design graph; global: keeps a port out of it, since link_manager skips any connection whose target is a global input port and the exporter emits no remap. ExternalVelocityLimitSelector's api_limit is the reverse case: it is published only by AD API adaptors outside the design graph, so it keeps global: alongside its remap_target. #13165 unified the Modifier and Optimizer nodes into TrajectoryProcessor but left both old designs in place, naming plugins, executables and param files that no longer exist, and put the new design in common/autoware_universe_designs, a bare directory that is not a ROS package. The design moves into autoware_trajectory_processor per the convention set by #13102, and its processing_time_detail publisher carries ProcessingTimeTree.

  * feat(autoware_path_sampler): add the packaged path sampler parameter file The package had no config/ directory and its INSTALL_TO_SHARE was commented out, so the parameter file the node design points at lived only in autoware_launch. The file is copied into the package and installed, and the design declares the three shared param files the launcher also passes, which is where ego_nearest_dist_threshold and ego_nearest_yaw_threshold come from.

  * feat(design): add the planning factor publishers to the BehaviorPathPlanner node design The node publishes nine planning factor arrays under /planning/planning_factors that the design did not declare, so nothing could connect them to the evaluator. ---------

• refactor(planning): move node design files into each package (#13102) Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>

• Contributors: Ryohsuke Mitsudome, Taekjin LEE

0.52.0 (2026-06-30)

• Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base

• feat: add area support for route planning and fix DCO signoff (#12572)

  • feat: add support for area for route planning
  • feat(mission_planner): publish lane+area route segments and goal height
  • fix(manual_lane_change_handler): guard lane-only APIs when route has areas
  • feat(mission_planner): visualize route area segments as LINE_STRIP in RViz
  • fix (remaining_distance_calculator): derive lane list from route msg when areas present in the route

  * fix(mission_planner): drop redundant goal_height init in refine_goal_height Removes cppcheck redundantInitialization warning; goal_height is always set in the area vs lane branches before use.

  • style(pre-commit): autofix
  • fix: resolve merge conflicts

  * style(pre-commit): autofix ---------Co-authored-by: Ryohsuke Mitsudome <<ryohsuke.mitsudome@tier4.jp>> Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>

• Contributors: emmeyteja, github-actions

0.51.0 (2026-05-01)

• Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base

• feat(autoware_lanelet2_extension): replace remaining lanelet2_extension utilities functions - planning component (#12083)

  • replace getArcCoordinates in planning component
  • replace getCenterlineWithOffset in planning component
  • replace getRight/LeftBoundWithOffset in planning component

File truncated at 100 lines see the full file