Skip to content

fix(nav2_integration): add sequence-numbered costmap handshake and diect goal preemption - #73

Open
arjo129 wants to merge 1 commit into
arjoc/feat/plan_executor_subdivision_and_clearancefrom
arjoc/fix/costmap_handshake
Open

arjo129 wants to merge 1 commit into
arjoc/feat/plan_executor_subdivision_and_clearancefrom
arjoc/fix/costmap_handshake

Conversation

@arjo129

@arjo129 arjo129 commented Oct 22, 2026 •

Copy link
Copy Markdown
Member

Fixed bug

This PR fixes a synchronization rmf_nav2_traffic, the spatio temporal costmap layer and nav2. Previously it was possible for the costmap to arrive after the nav2 goal. This would lead to frequent replanning.

Fix applied

The current fix is far from ideal, but it essentially involves publishing a new std_msgs/Header acknowledging receipt of the costmap before sending the next goal.

GenAI Use

We follow OSRA's policy on GenAI tools

  • I used a GenAI tool in this PR.
  • I did not use GenAI

Generated-by: Gemini 4 Argon

@arjo129
arjo129 added this pull request to stack #55 October 22, 2026 07:36
@mxgrey mxgrey added this to PMC Board Oct 22, 2026
@github-project-automation github-project-automation Bot moved this to Inbox in PMC Board Oct 22, 2026
…rect goal preemption

Signed-off-by: Arjo Chakravarty <arjoc@intrinsic.ai>
@arjo129
arjo129 force-pushed the arjoc/fix/costmap_handshake branch from 703f5a5 to 817674c Compare October 22, 2026 10:21
Comment on lines +167 to +169
let Some(amcl_pose_msg) = amcl_pose_sub.subscriber.take_data() else {
continue;
}
};

@SamuelFoo SamuelFoo Oct 26, 2026 •

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 think skipping the status update here when there is no new AMCL pose may leave a stationary robot waiting indefinitely.

take_data() consumes the latest pose, so this path stops publishing status until another pose arrives. AMCL may not publish a new pose while the robot is stationary.

For example, A stops at a crossing to wait for B. B clears it and sends its status, but the executor recomputes A's release on A's own status callback. Without a new pose, A may keep waiting even though the crossing is clear.

Could we keep publishing status from the cached pose while preserving its timestamp? Alternatively, the executor could recompute A’s release when B’s progress changes. The continuous ground-truth pose stream in #74 may hide this, so it would be worth checking with AMCL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Inbox

Development

Successfully merging this pull request may close these issues.

2 participants