@armgits please take a look at the failing linting / precommit jobs. The copyright would be yours / your company's (if done for a company) if its code you wrote. If you copy+pasted it with minimum modifications from another file in Nav2, keep that original copyright.

LGTM! I think the new Action API field is the only missing element (+ the BT node to parse it to put in an output port; 3 lines)

Do you think we shuold add a new field to the action definition that indicates if the output path is partial or not?

I was thinking if adding a new error code could do the same thing... Otherwise adding a new field to the result works too, I'm fine with either way to indicate a partial path in result.

(+ the BT node to parse it to put in an output port; 3 lines)

So is the job of this BT node just to evaluate whether the result from planner server is partial?
I'm guessing there's already a BT Node that just needs to be modified.

If the setting is 'true' that it is value to return a partial one, then I think that's not an error code-situation (i.e. a failure). I think we should add a field if a partial one was used and/or maybe even include the index of the goals that the final output represents?

I'm guessing there's already a BT Node that just needs to be modified.

Yeah, just use the outputPort method in the terminal conditions to parse the value (or reset in case of error) -- you'll see in the ComputePathThroughPoses BT node, its no biggie

I think we should add a field if a partial one was used and/or maybe even include the index of the goals that the final output represents?

So this would be a boolean field to indicate partial plan + a list of indices in the order of poses given in goal request? Would the final index just before obstacle work instead?

@armgits, 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).

So this would be a boolean field to indicate partial plan + a list of indices in the order of poses given in goal request? Would the final index just before obstacle work instead?

I think just the final index would work. Optionally: you could have this in a single field for the index of the goal -- whereas its set to -1 when it includes all goals. It could be an enum in the message definition like these https://github.com/ros-navigation/navigation2/blob/main/nav2_msgs/action/ComputePathThroughPoses.action#L11 (obviously needs to be signed) which can be set by default and overrided only when the failure condition happens.

Then any use case of this can just check if whatever-final-goal-variable != ComputePathThroughPoses::Result::ALL_GOALS to see if its not inclusive of all, rather than storing duplicate information in the Result message

you could have this in a single field for the index of the goal -- whereas its set to -1 when it includes all goals. It could be an enum in the message definition

This sounds perfect, I'll add this field to the action API.

@armgits, 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).

@armgits, 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).

@armgits, 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).

@armgits check out the docs PR, I asked for a small change there and otherwise once CI passes we can merge!

Codecov Report

❌ Patch coverage is 88.46154% with 3 lines in your changes missing coverage. Please review.

... and 8 files with indirect coverage changes

Just waiting on doc updates! CI's happy