Skip to content

Raghumanimehta/807-partial:Timeout implementation + cleanup of update_if_needed, LocalPath and NodeNavigate#839

Merged
raghumanimehta merged 29 commits intomainfrom
raghumanimehta/807_conditions_to_switch_paths_rework
Mar 23, 2026
Merged

Raghumanimehta/807-partial:Timeout implementation + cleanup of update_if_needed, LocalPath and NodeNavigate#839
raghumanimehta merged 29 commits intomainfrom
raghumanimehta/807_conditions_to_switch_paths_rework

Conversation

@raghumanimehta
Copy link
Copy Markdown
Contributor

@raghumanimehta raghumanimehta commented Mar 2, 2026

Description

  • Resolves a part of the conditions to switch path issue, not mentioning it here otherwise github would close it.
  • I had intended the whole conditions to switch paths be one PR but it seems making small incremental changes will allow more people to asynchronously work on this eg. @MilcToast worked on the wind thresholding.
  • This PR adds a field path_generation_time to LocalPathState to keep a track of when the path was generated.
  • I also added a function is_path_expired in LocalPath that checks if a path is expired or not using the field mentioned in the previous point.
  • The funciton has been tested
  • I also updated the LocalPath's update_if_needed to have a cleaner flow. It still largely follows the old algorithm.
  • I have updated the documentation in node_navigate.py and local_path.py to reflect that waypoint index is not the targetted waypoint but the waypoint we have already passed. Think of the situation of what happens when OMPL is called. The first item (0 index) is the waypoint at which OMPL was called and the boat is moving away from this waypoint. Following this intuition, the waypoint index is the waypoint that has already been visited. The variable name has been updated to reflect this behaviour.
  • I also added some error checking to ensure that we never access out of bound access in the waypoints array stored (localPath array from OMPL).

Verification

  • Unit tests

Resources

@raghumanimehta raghumanimehta added the path Pathfinding team label Mar 2, 2026
@raghumanimehta raghumanimehta changed the title Raghumanimehta/807 conditions to switch paths rework Raghumanimehta/807-partial:Timeout implementation + cleanup of update_if_needed, LocalPath and NodeNavigate Mar 2, 2026
@SPDonaghy SPDonaghy added path Pathfinding team and removed path Pathfinding team labels Mar 2, 2026
@github-project-automation github-project-automation bot moved this to Backlog in SOFT Project Mar 2, 2026
prev_lp_wp_index += 1

if prev_lp_wp_index > len(path.waypoints):
raise ValueError("waypoint idx > len(path.waypoints). Must generate new path")
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So when could this happen? As it stands, this scenario is not recoverable right? because update_if_needed does not catch this.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, update_if_needed doesn't catch it yet. It will in a separate PR.

When could this happen?
I have noticed it happen when you let PATH run for sometime and you are at the end of local path. There was a mismatch in what docstring and code thought waypoint index was. Read the PR description to learn more. Please let me know if it doesn't make sense.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have updated a TODO for now to remember to handle this in the future.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read the PR description, but am still fuzzy on when exactly this can happen and if its expected to be a transient issue that should be caught and handled or if its a sign something is very wrong and we cannot recover/should try rebooting.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is definitely something that warrants some added tests to verify that this scenario doesn't occur or if it does, that it's handled the right way. I'm wary of this because it doesn't convincingly solve the underlying problem of how this could occur and instead passes the problem to update_if_needed.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean by that?
I believe the tests you are talking about will come only after we have a finalized update_if_needed. In the meanwhile, we can have unit tests to test that these errors are thrown.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this issue is a sign that something is gone very wrong. I still believe it was an off by one error.

Please let me know if you have any good ideas on how we can test this (without doing what I suggested in the previous comment).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more thing, I still believe we should be handling this how I suggested in this PR. I don't feel good about indexing an array without checks (which was the case earlier).

or (self.path is None)
or (self.in_collision_zone())
or (self.is_path_expired())
or (self._prev_lp_wp_index > len(self.path.waypoints))
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This last case requires the boat to traverse the waypoint that comes after the last waypoint in self.path.waypoints. Do you think this should be >= instead? That way it reruns ompl when we finish the current local path, or is this handled well enough by received_new_global_waypoint in update_if_needed?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed.

current_wp_latlon = waypoints[target_wp_index - 1]
next_wp_latlon = waypoints[target_wp_index]

def mid_point(start_latlon: HelperLatLon, end_latlon: HelperLatLon):
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although this is for testing, it isn't immediately clear what this function does. Add a short docstring explaining what this function does.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed.


heading_diff_old_path = cs.calculate_heading_diff(self.state.heading, heading_old_path)
heading_diff_new_path = cs.calculate_heading_diff(self.state.heading, heading_new_path)
if self.is_path_expired():
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this case already covered in must_change_path() called above?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. fixed.

return (
True,
f"Target waypoint index out of bounds: {self._target_lp_wp_index} >= {len(self.path.waypoints)}", # noqa
)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should is_significant_wind_change() be added here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eventually, yes. This work was done before Jeremy had made the PR for that function. We will add it here in a separate PR.
Think of this PR as a fix of a bug with the waypoint latlon and implementation of a part of the reworked conditions to switch paths.

@raghumanimehta raghumanimehta requested a review from a team as a code owner March 17, 2026 21:43
@raghumanimehta raghumanimehta merged commit a5cb3cc into main Mar 23, 2026
6 checks passed
@raghumanimehta raghumanimehta deleted the raghumanimehta/807_conditions_to_switch_paths_rework branch March 23, 2026 21:55
@github-project-automation github-project-automation bot moved this from Backlog to Done in SOFT Project Mar 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

path Pathfinding team

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants