Action Client

Action Client is for ROS 2 actions: goals with feedback, progress, and a cancel path. Use it for Nav2 navigation, MoveIt planning, or any mission step lasting seconds to minutes. A fire-and-forget tap is simpler as Custom Button in Tap mode; a request/response call like clearing a costmap fits Custom Button in Service mode.

Point Action Topic at /navigate_to_pose. Selecting it from the field's own autocomplete (any topic ending in /_action/send_goal) derives the sub-topics in one step: the send_goal and cancel_goal services, and the feedback and status topics. You only see those five fields if you turn on Override Sub-Topics, which is for servers that don't follow the standard naming.

Action Type is a picker, not just a text box. Choose nav2_msgs/action/NavigateToPose from the known-action list and it fills a matching Goalfor you; type your own if the action isn't in the list. Where the bridge reports the type, it also auto-fills on connect.

The shipped Goal template already includes a frame_id and an identity orientation, both required for a valid PoseStamped: edit only the position block, for example x: 1.0, y: 0.5, and leave the rest alone. Rename Send Button Labelto something readable, like "Go to Kitchen".

Inside Goal, tick a field to promote it to the widget's face. Those fields then sit on the dashboard with the send button, so a new destination is two taps rather than a trip back into the config screen. Tick position.x and position.yon a NavigateToPose widget and you have a go-to-coordinate pad; leave the frame and orientation untouched underneath. Everything you don't tick still ships with the goal exactly as the template defines it.

For an action in the built-in table, progress and the value line are worked out for you: leave Customize Feedback Displayoff and it just works. Turn it on when your action isn't in the table and you need to point those two readouts at your own feedback fields.

That panel has two traps. Progress Field needs a path that is a completion fraction, and almost no standard action publishes one: Nav2 reports distance remaining, which is the opposite direction, so leaving this empty and letting the table do the work is usually right. Progress Scale then has to be stated rather than guessed, because a reading of exactly 1 is a finished goal on the 0-to-1 scale and barely started on the 0-to-100 one. Fill from action seeds the value field and its unit from the table so you edit from a starting point instead of from empty, and it needs no robot connected.

The end states are not interchangeable, and the difference is who made the call. Abortedis the server's own verdict: the robot ran your goal and gave up on it. Failed covers every outcome the server never ruled on, including a rejected goal, a dispatch timeout, a transport error, and a connection lost mid-goal. A dropped link is therefore Failed, not Aborted: nothing on the robot ever reached a verdict.

Stopped is the one you caused: backgrounding the app or disconnecting on purpose cancels the goal and reports it that way, distinct from a link that failed on its own.

Unknown is the fourth end state. If a goal the app watched the server accept simply leaves the status array without a terminal state ever arriving, the widget will not claim it succeeded or failed. It tells you the robot is no longer reporting the goal, that it may still be running, and to use a hardware E-stop if you need one.

• Lose the connection mid-goal and the widget warns you the robot may still be executing the goal, and to use a hardware E-stop if needed. Take it literally: the link died, not the robot.
• The app's E-Stop sends a blind cancel across every configured action rather than a cancel naming one goal, so it can take down goals this widget never dispatched, including a goal sent by another client entirely. That reach is deliberate. It also acts only on the app's side of the link: it cancels, publishes a zero velocity, and disconnects, which is why a hardware E-stop stays the authority for stopping the robot.
• Action Type must match the server exactly, package included: nav2_msgs/action/NavigateToPose is real, nav_msgs/action/NavigateToPose is not.
• Cancel asks politely: some servers preempt immediately, some finish the current motion first. The widget only confirms cancel was sent, not that the robot stopped.