Centralize path handler logic in controller server #5446

mini-1235 · 2025-08-12T14:03:32Z

This PR continues the work in #4789
Fixes #4757
Fixes #4304

This is a continuation of work started by @ottojo in draft PR #4593

I'll quote their introduction and, expand a bit afterwards, and update any fields that have changed.

The controller server uses a configurable goal checker to determine if the robot has completed its current path as defined by the global plan. Current goal checkers compare the goal (end of path) pose and twist to the current robot state, but that is not sufficient in all cases.
In some use cases, the path will visit the goal multiple times, and the goal might coincide with the starting position. It is still desired that the robot follows the entire path, instead of immediately ending navigation once the goal pose is reached.
This PR adds a parameter to the GoalChecker interface to inform the goal checker of the current path, which enables building more sophisticated goal checkers that (for example) take progress along the path into account.
We already use such a goal checker internally, which just subscribes to the global plan via the appropriate ROS topic, but i think this here is the cleaner solution (and also avoids race conditions of checking against an old path in the goal checker...)
I don't have a nice testing setup and a goal checker using this interface yet (other than our own robot and the mentioned goal checker), which is why I mark this as draft for now.

I've cherry-picked @ottojo 's commit on top of the latest main branch, then added a new basic goal checker PathCompleteGoalChecker, which is a subclass of SimpleGoalChecker, but has an additional parameter (path_length_tolerance, default=1), and checks that the current path has <= path_length_tolerance waypoints before allowing the normal SimpleGoalChecker completion logic to take its course.

The result is a trivial extension of SimpleGoalChecker that should be immune to the current_pose = goal_pose short-circuit problem/bug. Rather than try to create an elaborate unit test that navigates a course, I stuck to first principles to ensure that the new plugin behaves the same as SimpleGoalChecker with <= path_length_tolerance waypoints, and that it does not complete with > path_length_tolerance waypoints.

Basic Info

Info Please fill out this column
Ticket(s) this addresses #4304
Primary OS tested on Ubuntu
Robotic platform tested on (WIP)
Does this PR contain AI generated software? No

Description of contribution in a few bullet points

Extend GoalChecker::isGoalReached interface with argument for current path

Add this argument to the in-tree goal checker implementations

Add a goal checker which checks for path-completion

[] Define a test-scenario with global plan that returns to start pose

Description of documentation updates required from your changes

Migration guide for out-of-tree goal checkers

Future work that may be required in bullet points

Implementing more sophisticated goal checkers

For Maintainers:

Check that any new parameters added are updated in docs.nav2.org

Check that any significant change is added to the migration guide

Check that any new features OR changes to existing behaviors are reflected in the tuning guide

Check that any new functions have Doxygen added

Check that any new features have test coverage

Check that any new plugins is added to the plugins page

If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists

mini-1235 · 2025-08-12T14:05:10Z

@SteveMacenski before I go too far, can you take a quick look to make sure I am on the right track? I have only pushed the changes in nav2_controller, graceful_controller and RPP

mergify · 2025-08-12T14:06:07Z

@mini-1235, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mini-1235 · 2025-08-12T18:38:05Z

I have spent some time reading into MPPI's path handler, I can see there are some improvements like #3659, #3443. Also, there is a related PR for RPP in #4763, maybe we need to check if these changes are applicable to all controllers? If yes, I guess it will be easier to move them in Controller Server

I also noticed that the DWB/MPPI need the path from planner to find its goal, should we pass this plan via the setplan api or a new argument in computevelocitycommands?

mamariomiamo · 2025-08-13T01:46:13Z

Hi, sorry to jump in here but just sharing my two cents:
Alternatively, is it possible to modify the end_pose_ to be the end of the pruned and transformed global path from the path_handler_? This way we do not need to add the additional PathCompleteGoalChecker since we will no longer be using the end of the global path for isGoalReached check. As the robot progresses along the global path, the pruned and transformed global path will eventually cover until the end of the global path and thus we will still be using the actual navigation goal as the final isGoalReached check.

mamariomiamo · 2025-08-13T03:42:48Z

I have spent some time reading into MPPI's path handler, I can see there are some improvements like #3659, #3443. Also, there is a related PR for RPP in #4763, maybe we need to check if these changes are applicable to all controllers? If yes, I guess it will be easier to move them in Controller Server

I also noticed that the DWB/MPPI need the path from planner to find its goal, should we pass this plan via the setplan api or a new argument in computevelocitycommands?

I think path_handler implementation from MPPI is more comprehensive as it also considers path up to inversion point. This would also be helpful when user uses Hybrid A* with reeds-shepp as the global planner.

mini-1235 · 2025-08-13T15:13:39Z

Hi, sorry to jump in here but just sharing my two cents: Alternatively, is it possible to modify the end_pose_ to be the end of the pruned and transformed global path from the path_handler_? This way we do not need to add the additional PathCompleteGoalChecker since we will no longer be using the end of the global path for isGoalReached check. As the robot progresses along the global path, the pruned and transformed global path will eventually cover until the end of the global path and thus we will still be using the actual navigation goal as the final isGoalReached check.

Thanks for sharing, I will try to implement this and compare with my current method

mergify · 2025-08-16T19:26:42Z

@mini-1235, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

SteveMacenski

Sorry it took so long!

nav2_controller/include/nav2_controller/controller_server.hpp

nav2_controller/plugins/path_complete_goal_checker.cpp

SteveMacenski · 2025-08-28T23:18:09Z

nav2_controller/src/controller_server.cpp

  goal_checker_loader_("nav2_core", "nav2_core::GoalChecker"),
  default_goal_checker_ids_{"goal_checker"},
-  default_goal_checker_types_{"nav2_controller::SimpleGoalChecker"},
+  default_goal_checker_types_{"nav2_controller::PathCompleteGoalChecker"},


I think by 'default' I mean that this should just be built into the simple goal checker so that this just given to everyone 'for free'

So I should remove this new plugin and add the path_length_tolerance to simple goal checker, do I understand this correctly?

nav2_controller/src/controller_server.cpp

SteveMacenski · 2025-08-28T23:27:09Z

I think path_handler implementation from MPPI is more comprehensive as it also considers path up to inversion point.

I agree with this general sentiment. I think it would be nice to review all the path handlers and make sure the key features of all are being respected in the server's implementation.

There's a number of CI failures that should also be looked at, but I'm sure you know :-)

mini-1235 · 2025-08-29T17:28:47Z

There's a number of CI failures that should also be looked at, but I'm sure you know :-)

Yes, I will continue this PR once #5496 and other future PRs targeting path handler are done

mergify · 2025-09-24T07:09:23Z

@mini-1235, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

mini-1235 · 2025-09-25T14:35:45Z

@SteveMacenski I think you can start reviewing this when you have time, in the following days I plan to:

Finish DWB (Some logics are not handled yet)
Test Graceful/MPPI/RPP/DWB on different platform (Ackermann, Differential) with different params
Handle dynamic params in controller server
Fix & Add unit tests

Things to debate:

Alternatively, is it possible to modify the end_pose_ to be the end of the pruned and transformed global path from the path_handler_? This way we do not need to add the additional PathCompleteGoalChecker since we will no longer be using the end of the global path for isGoalReached check

I think this becomes problematic when enforce_path_inversion is set to true. In that case, the local goal ends up being the cusping point, and the robot may stop there once it satisfies the XY and yaw tolerances. Because of this, I believe we still need the global goal for the goal checker. But as @SteveMacenski suggested, we could add this directly into the simple goal checker, so by default the simple goal checker is checking both the global goal and local path length. Do you agree with this approach? @mamariomiamo

This PR has moved the following parameters from the plugin level to controller level:

transform_tolerance
prune_distance
max_robot_pose_search_dist
enforce_path_inversion
inversion_xy_tolerance
inversion_yaw_tolerance

Previously, the transform tolerance in the controller server was obtained from costmap->getTransformTolerance. I think it makes more sense for the server and its plugins to share the same tolerance, so I moved this to the controller level.

We have different pruned_plan_end for MPPI and RPP,

navigation2/nav2_controller/src/path_handler.cpp

Lines 134 to 146 in 3404f3a

    
           //TODO: For RPP and graceful we don't have prune distance, maybe we need to support two kinds of pruned_plan_end here 
        
           // by parameter? 
        
           if (1){ 
        
             pruned_plan_end = nav2_util::geometry_utils::first_after_integrated_distance( 
        
             closest_point, global_plan_up_to_inversion_.poses.end(), params_->prune_distance); 
        
           } 
        
           else{ 
        
             pruned_plan_end = std::find_if( 
        
             closest_point, global_plan_up_to_inversion_.poses.end(), 
        
             [&](const auto & global_plan_pose) { 
        
               return euclidean_distance(global_plan_pose, robot_pose) > max_costmap_extent; 
        
             }); 
        
           }

I am not sure how do we want to handle this, since only MPPI & DWB has the prune_distance parameter. Maybe adding a new parameter here will work?

Before merging this, I also need to:

Update nav2 tutorial with the new controller server API
Update docs, including migration guide, writing a new controller plugin, configuration guides

mergify · 2025-09-25T15:14:41Z

@mini-1235, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

SteveMacenski · 2025-09-29T20:42:21Z

OK will do! This is admittedly alot so this next round is going to be more high level.

... the local goal ends up being the cusping point, and the robot may stop there once it satisfies the XY and yaw tolerances ... we could add this directly into the simple goal checker, so by default the simple goal checker is checking both the global goal and local path length

Ah ok. That makes sense for the goal checker, though probably not the other elements right? When enforcing inversions is off, its the same either way since we just prune to the prune distance / costmap bounds. When is it enabled, then we prune to that which we want from the control algorithm's perspective, but not the goal checker.

Previously, the transform tolerance in the controller server was obtained from costmap->getTransformTolerance. I think it makes more sense for the server and its plugins to share the same tolerance, so I moved this to the controller level.

Why not have it still acquire it from costmap2D, just stored and used at the controller server level? I suppose I prefer less parameters to more, but I'm OK either way.

We have different pruned_plan_end for MPPI and RPP,

Do both - first after the integrated distance, as long as that distance is within the costmap bounds.

nav2_controller/src/parameter_handler.cpp

nav2_mppi_controller/include/nav2_mppi_controller/critic_data.hpp

SteveMacenski · 2025-09-29T20:49:28Z

nav2_controller/include/nav2_controller/parameter_handler.hpp

+   */
+  ~ParameterHandler();
+
+  std::mutex & getMutex() {return mutex_;}


Is this being properly locked when needed in the main function(s) so that dynamic parameters aren't being updated during execution?

Yes I forgot to add this, will add it in the next update

@mini-1235 is this still open?

I don't think so, I have added in ControllerServer L424

nav2_core/include/nav2_core/controller.hpp

mini-1235 · 2025-10-01T15:10:13Z

Ah ok. That makes sense for the goal checker, though probably not the other elements right? When enforcing inversions is off, its the same either way since we just prune to the prune distance / costmap bounds. When is it enabled, then we prune to that which we want from the control algorithm's perspective, but not the goal checker.

Yes, when it is on, the distance to the local goal can become very small. That's why I think this local goal is not suitable to use in the goal checker

Why not have it still acquire it from costmap2D,

For the controller plugins as well?

Do both - first after the integrated distance, as long as that distance is within the costmap bounds.

Not sure if I understand this, can you elaborate?

SteveMacenski · 2025-10-01T15:56:43Z

For the controller plugins as well?

Isn't that in effect what is done today?

Not sure if I understand this, can you elaborate?

Basically combine the two:

navigation2/nav2_controller/src/path_handler.cpp

Lines 134 to 146 in 3404f3a

    
           //TODO: For RPP and graceful we don't have prune distance, maybe we need to support two kinds of pruned_plan_end here 
        
           // by parameter? 
        
           if (1){ 
        
             pruned_plan_end = nav2_util::geometry_utils::first_after_integrated_distance( 
        
             closest_point, global_plan_up_to_inversion_.poses.end(), params_->prune_distance); 
        
           } 
        
           else{ 
        
             pruned_plan_end = std::find_if( 
        
             closest_point, global_plan_up_to_inversion_.poses.end(), 
        
             [&](const auto & global_plan_pose) { 
        
               return euclidean_distance(global_plan_pose, robot_pose) > max_costmap_extent; 
        
             }); 
        
           }

. Find the first after the integrated distance. If its outside of the costmap bounds, then wind back until its within the costmap bounds. If its off the local costmap, then we cannot consider them for control since they're not validly known

SteveMacenski · 2025-10-01T16:40:18Z

A good suggestion I received today: It would be great to make the path handler itself a plugin so that other users can replace this implementation if they see fit. A nice side effect is it makes us have to think a bit more about the API interfaces for it to make sure its generally good for a broad range of purposes and include all the information for the APIs other implementations may want that we have access to.

Another would be possibly changing the pruning distance to be proportional to time instead, to prune the distance set out by that time by the maximum velocity. That way it wasn't something that needed to be tuned for changing velocity limits.

Finally, maybe it would be good to provide feedback about the current idx of the path we're on to use in the BT Navigator for computing ETA, path length remaining, and so forth. That way we handle the issue of path looping using the wrong index globally

mini-1235 · 2025-10-01T17:18:03Z

I will think about it and reply tomorrow

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

mini-1235 · 2025-10-17T17:49:10Z

Oops, forgot to format files

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

mini-1235 · 2025-10-17T18:32:25Z

I think ament_uncrustify --reformat . automatically inserts newlines and indents 4 spaces whenever a line exceeds 100 characters. It would be great if we could have an uncrustify.cfg that only enforces 2-space indentation instead of 4

SteveMacenski · 2025-10-21T00:18:02Z

It didn't used to do that ... I wonder if the ament_uncrustify format got corrupted in that case. it didn't used to do that and that was the profile in use.

is there anything above you want me to take a look at (except that last comment)? I wasn't sure if I was waiting or you wanted me to take a look again.

mergify · 2025-10-21T00:21:48Z

This pull request is in conflict. Could you fix it @mini-1235?

mini-1235 · 2025-10-21T14:09:30Z

It didn't used to do that ... I wonder if the ament_uncrustify format got corrupted in that case. it didn't used to do that and that was the profile in use.

I am not familiar with uncrustify, will take a look when I have time. For this PR, I will just update it manually.

I wasn't sure if I was waiting or you wanted me to take a look again.

Yes, please take another look when you have time. I have updated things accordingly

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

SteveMacenski

Also check out CI, a number of tests don't have results or have failures

There are a number of open items above (make sure to expand the hidden topics since this is so long) and I commented on all of them with responses (if not closing due to completion).

SteveMacenski · 2025-10-23T21:27:58Z

nav2_system_tests/src/waypoint_follower/test_case_launch.py

    params_file = os.path.join(nav2_bringup_dir, 'params/nav2_params.yaml')
-
-    # Replace the `use_astar` setting on the params file
-    param_substitutions = {


Why this change?

This substitutes the parameter prune_distance and forward_prune_distance in DWB. Since we are centralizing it in controller server, I don't think we have these two parameters anymore in DWB

SteveMacenski · 2025-10-23T21:28:18Z

nav2_system_tests/src/system/nav2_system_params.yaml

      xy_goal_tolerance: 0.25
      yaw_goal_tolerance: 0.25
+    path_handler:
+      plugin: "nav2_controller::SimplePathHandler"


Add some params to this to be fully described? (here, other similar files in nav2 tests + Nav2 bringup)

Will add in next update

SteveMacenski · 2025-10-23T21:31:07Z

nav2_rviz_plugins/src/selector.cpp

  row_3_label_layout_->addWidget(new QLabel("Progress Checker"));
  row_3_layout_->addWidget(progress_checker_);
+  row_3_label_layout_->addWidget(new QLabel("Path Handler"));
+  row_3_layout_->addWidget(path_handler_);


Does the layout need to adapt due to the additional field (i.e. larger size?)

I don't think so, this looks fine for me

SteveMacenski · 2025-10-23T21:32:22Z

nav2_regulated_pure_pursuit_controller/test/test_regulated_pp.cpp

    results4);
 }

-class TransformGlobalPlanTest : public ::testing::Test


Were all the relevant tests for full coverage of the new plugin transferred?

Will add in next update

SteveMacenski · 2025-10-23T21:37:53Z

nav2_controller/plugins/simple_path_handler.cpp

+double SimplePathHandler::getCostmapMaxExtent() const
+{
+  const double max_costmap_dim_meters = std::max(
+    costmap_ros_->getCostmap()->getSizeInCellsX(),


I don't think that semantic difference is really being used here -- I think you can simply use the Meters API

SteveMacenski · 2025-10-23T21:42:45Z

nav2_controller/include/nav2_controller/parameter_handler.hpp

+   */
+  ~ParameterHandler();
+
+  std::mutex & getMutex() {return mutex_;}


@mini-1235 is this still open?

SteveMacenski · 2025-10-23T21:44:18Z

nav2_controller/src/controller_server.cpp

  goal_checker_loader_("nav2_core", "nav2_core::GoalChecker"),
  default_goal_checker_ids_{"goal_checker"},
-  default_goal_checker_types_{"nav2_controller::SimpleGoalChecker"},
+  default_goal_checker_types_{"nav2_controller::PathCompleteGoalChecker"},


SteveMacenski · 2025-10-23T21:46:13Z

nav2_rotation_shim_controller/src/nav2_rotation_shim_controller.cpp

-  current_path_ = path;
-  primary_controller_->setPlan(path);
+  path_updated_ = rotate_to_heading_once_ ? isGoalChanged(raw_global_path) : true;
+  current_path_ = raw_global_path;


Should we use the new computeVelocityCommands for this instead for setting the current path?

I think this is a special case where the controller needs the full global plan, no?

navigation2/nav2_rotation_shim_controller/src/nav2_rotation_shim_controller.cpp

Lines 273 to 281 in 8dbc929

// Find the first point at least sampling distance away

for (unsigned int i = 1; i != current_path_.poses.size(); i++) {

dx = current_path_.poses[i].pose.position.x - start.position.x;

dy = current_path_.poses[i].pose.position.y - start.position.y;

if (hypot(dx, dy) >= forward_sampling_distance_) {

current_path_.poses[i].header.frame_id = current_path_.header.frame_id;

current_path_.poses[i].header.stamp = clock_->now(); // Get current time transformation

return current_path_.poses[i];

}

SteveMacenski · 2025-10-23T21:49:12Z

nav2_regulated_pure_pursuit_controller/src/regulated_pure_pursuit_controller.cpp

-  auto transformed_plan = path_handler_->transformGlobalPlan(
-    pose, params_->max_robot_pose_search_dist, params_->interpolate_curvature_after_goal);
-  global_path_pub_->publish(transformed_plan);
+  // Transform the plan from costmap's global frame to robot base frame


This process seems like it might be a nice utility to have in the path handler plugin itself. Given a path, convert it to another frame (i.e. the base frame) at a timestamp. If not in the path handler class, then maybe as a path utils for nav2_utils

SteveMacenski · 2025-10-23T21:50:56Z

nav2_graceful_controller/src/graceful_controller.cpp

    goal_dist_tolerance_ = pose_tolerance.position.x;
  }

+  // Transform the plan from costmap's global frame to robot base frame


That util / path handler API could then be used here too!

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

codecov · 2025-10-25T19:56:48Z

Codecov Report

❌ Patch coverage is 88.83827% with 49 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
nav2_controller/plugins/simple_path_handler.cpp	84.54%	17 Missing ⚠️
nav2_controller/src/controller_server.cpp	81.48%	15 Missing ⚠️
nav2_controller/src/parameter_handler.cpp	90.00%	12 Missing ⚠️
...m_controller/src/nav2_rotation_shim_controller.cpp	66.66%	2 Missing ⚠️
...ehavior_tree/plugins/action/follow_path_action.cpp	75.00%	1 Missing ⚠️
...v2_graceful_controller/src/graceful_controller.cpp	75.00%	1 Missing ⚠️
...ntroller/src/regulated_pure_pursuit_controller.cpp	75.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
...ehavior_tree/plugins/action/follow_path_action.hpp	`100.00% <100.00%> (ø)`
...tree/plugins/action/path_handler_selector_node.hpp	`100.00% <100.00%> (ø)`
...tree/plugins/action/path_handler_selector_node.cpp	`100.00% <100.00%> (ø)`
...ller/include/nav2_controller/controller_server.hpp	`100.00% <100.00%> (ø)`
...ller/include/nav2_controller/parameter_handler.hpp	`100.00% <100.00%> (ø)`
.../nav2_controller/plugins/position_goal_checker.hpp	`100.00% <ø> (ø)`
...de/nav2_controller/plugins/simple_path_handler.hpp	`100.00% <100.00%> (ø)`
nav2_controller/plugins/position_goal_checker.cpp	`100.00% <100.00%> (+40.00%)`	⬆️
nav2_controller/plugins/simple_goal_checker.cpp	`100.00% <100.00%> (ø)`
nav2_controller/plugins/stopped_goal_checker.cpp	`100.00% <100.00%> (ø)`
... and 28 more

... and 17 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

SteveMacenski mentioned this pull request Aug 12, 2025

Goalchecker path argument and plugin #4789

Closed

11 tasks

mini-1235 mentioned this pull request Aug 15, 2025

Better management of RPP path pruning when cusp points are detected #4763

Closed

7 tasks

SteveMacenski requested changes Aug 28, 2025

View reviewed changes

This was referenced Sep 4, 2025

MPPI feedback for progress on global path #5498

Closed

Add exact path following in rpp for feasible plans #5496

Closed

SteveMacenski mentioned this pull request Sep 17, 2025

Path distance feature #5387

Merged

8 tasks

mini-1235 mentioned this pull request Sep 22, 2025

DWBLocalPlanner: NavToPose fails if prune_plan is disabled #3375

Closed

mini-1235 force-pushed the feat/goal_checker branch from 145b2d9 to ea45821 Compare September 22, 2025 17:22

mini-1235 mentioned this pull request Sep 24, 2025

Refactor common functions in smoother and planner #5537

Merged

8 tasks

mini-1235 changed the title ~~Add path goal checker plugin~~ Centralize path handler logic in controller server Sep 25, 2025

mini-1235 mentioned this pull request Sep 26, 2025

[Graceful Controller] Fix Incorrect Motion Target Heading output by controller #5530

Merged

8 tasks

SteveMacenski reviewed Sep 29, 2025

View reviewed changes

mini-1235 mentioned this pull request Oct 1, 2025

Update declares and gets to use new declare_or_get_param API #5299

Open

mini-1235 added 2 commits October 17, 2025 17:32

Add path length tolerance in dwb critic

0e107ea

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

Linting

6892041

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

mini-1235 requested a review from SteveMacenski October 17, 2025 17:33

Format

dd76468

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

mini-1235 added 6 commits October 22, 2025 15:26

Activate dynamic parameters callback in Avtivate stage

3d1e857

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

Merge remote-tracking branch 'origin/main' into feat/goal_checker

a29c0ce

Fix tests for dynamic parameters

84d3497

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

Lint

8ad9f8f

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

Merge remote-tracking branch 'origin/main' into feat/goal_checker

820e55a

Skip

f1f0539

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

SteveMacenski reviewed Oct 23, 2025

View reviewed changes

mini-1235 added 4 commits October 25, 2025 13:09

Fix as suggested

fb9e294

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

Fix tests

70f55cd

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

Fix tests

15f48a4

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

Update CI key for codecov

4b7deb2

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

mini-1235 added 5 commits October 26, 2025 10:30

Increase code coverage

a8f5ad7

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

Linting

487f1ed

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

Increase code coverage

ae8b599

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

Move from controller_utils to path_utils

9431ee4

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

Update params and rviz

c669b68

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

mini-1235 mentioned this pull request Oct 28, 2025

MPPI: Clip path up to in-place rotation #5648

Open

9 tasks

mini-1235 added 2 commits October 28, 2025 14:30

Update costmap update timeout

25cd699

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

Lint

4529858

Signed-off-by: mini-1235 <mauricepurnawan@gmail.com>

mini-1235 mentioned this pull request Oct 31, 2025

Refactor parameter handler #5667

Open

8 tasks

	// Find the first point at least sampling distance away
	for (unsigned int i = 1; i != current_path_.poses.size(); i++) {
	dx = current_path_.poses[i].pose.position.x - start.position.x;
	dy = current_path_.poses[i].pose.position.y - start.position.y;
	if (hypot(dx, dy) >= forward_sampling_distance_) {
	current_path_.poses[i].header.frame_id = current_path_.header.frame_id;
	current_path_.poses[i].header.stamp = clock_->now(); // Get current time transformation
	return current_path_.poses[i];
	}

Centralize path handler logic in controller server #5446

Are you sure you want to change the base?

Centralize path handler logic in controller server #5446

Uh oh!

Conversation

mini-1235 commented Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Basic Info

Description of contribution in a few bullet points

Description of documentation updates required from your changes

Future work that may be required in bullet points

For Maintainers:

Uh oh!

mini-1235 commented Aug 12, 2025

Uh oh!

mergify bot commented Aug 12, 2025

Uh oh!

mini-1235 commented Aug 12, 2025

Uh oh!

mamariomiamo commented Aug 13, 2025

Uh oh!

mamariomiamo commented Aug 13, 2025

Uh oh!

mini-1235 commented Aug 13, 2025

Uh oh!

mergify bot commented Aug 16, 2025

Uh oh!

SteveMacenski left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

SteveMacenski commented Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mini-1235 commented Aug 29, 2025

Uh oh!

mergify bot commented Sep 24, 2025

Uh oh!

mini-1235 commented Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mergify bot commented Sep 25, 2025

Uh oh!

SteveMacenski commented Sep 29, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mini-1235 commented Oct 1, 2025

Uh oh!

SteveMacenski commented Oct 1, 2025

Uh oh!

SteveMacenski commented Oct 1, 2025

Uh oh!

mini-1235 commented Oct 1, 2025

Uh oh!

mini-1235 commented Oct 17, 2025

Uh oh!

mini-1235 commented Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

mini-1235 commented Aug 12, 2025 •

edited

Loading

SteveMacenski commented Aug 28, 2025 •

edited

Loading

mini-1235 commented Sep 25, 2025 •

edited

Loading

mini-1235 commented Oct 17, 2025 •

edited

Loading

SteveMacenski commented Oct 21, 2025 •

edited

Loading