Raghumanimehta/807-partial:Timeout implementation + cleanup of update_if_needed, LocalPath and NodeNavigate#839
Conversation
| prev_lp_wp_index += 1 | ||
|
|
||
| if prev_lp_wp_index > len(path.waypoints): | ||
| raise ValueError("waypoint idx > len(path.waypoints). Must generate new path") |
There was a problem hiding this comment.
So when could this happen? As it stands, this scenario is not recoverable right? because update_if_needed does not catch this.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I have updated a TODO for now to remember to handle this in the future.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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)) |
There was a problem hiding this comment.
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?
| current_wp_latlon = waypoints[target_wp_index - 1] | ||
| next_wp_latlon = waypoints[target_wp_index] | ||
|
|
||
| def mid_point(start_latlon: HelperLatLon, end_latlon: HelperLatLon): |
There was a problem hiding this comment.
Although this is for testing, it isn't immediately clear what this function does. Add a short docstring explaining what this function does.
|
|
||
| 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(): |
There was a problem hiding this comment.
Isn't this case already covered in must_change_path() called above?
| return ( | ||
| True, | ||
| f"Target waypoint index out of bounds: {self._target_lp_wp_index} >= {len(self.path.waypoints)}", # noqa | ||
| ) |
There was a problem hiding this comment.
Should is_significant_wind_change() be added here?
There was a problem hiding this comment.
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.
Description
path_generation_timetoLocalPathStateto keep a track of when the path was generated.is_path_expiredinLocalPaththat checks if a path is expired or not using the field mentioned in the previous point.LocalPath'supdate_if_neededto have a cleaner flow. It still largely follows the old algorithm.node_navigate.pyandlocal_path.pyto 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.Verification
Resources