ros2 action — gửi goal và theo dõi tiến trình từ terminal

Action (như /navigate_to_pose của Nav2) khác service ở chỗ chạy lâu và có feedback dọc đường — ros2 action là cách test một action server mà không cần dựng UI, đặc biệt hữu ích khi debug Nav2 qua SSH, không có màn hình để mở RViz2.

Khái niệm chính

ros2 action list                     # liệt kê action server đang có
ros2 action info /navigate_to_pose   # xem client/server đang kết nối
ros2 action send_goal /navigate_to_pose nav2_msgs/action/NavigateToPose \
  "{pose: {header: {frame_id: 'map'}, pose: {position: {x: 1.0, y: 2.0}}}}"

send_goal gửi một goal thật tới action server, sau đó giữ terminal mở để in feedback liên tục cho tới khi action hoàn tất hoặc bị huỷ (Ctrl+C) — khác service call chỉ đợi đúng một phản hồi rồi kết thúc ngay.

Nguyên lý hoạt động

Đọc feedback trong khi action đang chạy:

$ ros2 action send_goal /navigate_to_pose nav2_msgs/action/NavigateToPose "{...}" --feedback
Goal accepted with ID: 8f3a...

Feedback:
    current_pose: ...
    distance_remaining: 3.42

Feedback:
    current_pose: ...
    distance_remaining: 2.87
...
Result:
    error_code: 0

Cờ --feedback bật in từng gói feedback theo thời gian thực — với NavigateToPose, quan sát distance_remaining giảm dần đều là dấu hiệu robot đang di chuyển đúng hướng; nếu con số đứng yên hoặc tăng, Nav2 đang gặp vấn đề trước cả khi cần mở RViz2 để nhìn trực quan.

Tóm lại: Action = service (có phản hồi cuối) + topic (feedback liên tục dọc đường) + khả năng huỷ giữa chừng — ba đặc điểm mà send_goal --feedback cho phép kiểm chứng cả ba ngay từ terminal, không cần bất kỳ giao diện đồ hoạ nào.

Huỷ goal đang chạy:

ros2 action send_goal ... # Ctrl+C để huỷ goal đang chờ kết quả

Nhấn Ctrl+C trong lúc send_goal đang chờ sẽ gửi yêu cầu huỷ (cancel) goal đó tới server — hành vi tương đương khi Nav2 nhận lệnh dừng khẩn cấp giữa lúc đang điều hướng, đúng luồng cần test khi kiểm tra logic recovery/an toàn của hệ thống.

Kiến thức kỹ thuật

Thông số

Một số cờ bổ sung hữu ích khi làm việc với ros2 action:

Cờ/lệnh	Tác dụng
ros2 action info /navigate_to_pose -t	Hiện kèm kiểu action, không cần gọi lệnh riêng
ros2 action list -t	Liệt kê mọi action kèm kiểu tương ứng
ros2 action send_goal ... --feedback	Bắt buộc phải có nếu muốn thấy feedback — mặc định không bật

Không giống ros2 service call (không có timeout mặc định), send_goal chờ phản hồi chấp nhận/từ chối goal gần như ngay lập tức (server phải trả lời có nhận goal hay không trong thời gian ngắn), nhưng phần result cuối cùng thì có thể chờ rất lâu tuỳ độ dài thực tế của tác vụ (VD: hành trình điều hướng dài) — đây là lý do --feedback quan trọng để biết action có đang thực sự tiến triển hay đã "chết" giữa chừng.

Ứng dụng thực tế

ros2 action send_goal --feedback đặc biệt giá trị khi kỹ sư hiện trường phải chẩn đoán từ xa qua SSH — robot bị "kẹt" trong kho hàng, không tiện mang laptop có màn hình lớn để mở RViz2 tại chỗ, chỉ cần SSH vào máy tính robot và gửi thử 1 goal điều hướng, quan sát distance_remaining có giảm hay không để phân biệt nhanh 2 tình huống khác nhau: Nav2 đang tính toán đường đi bị kẹt thuật toán (feedback không xuất hiện hoặc goal bị REJECTED ngay), hay robot bị kẹt vật lý thực sự (feedback vẫn cập nhật nhưng distance_remaining không đổi) — 2 nguyên nhân này cần hướng xử lý hoàn toàn khác nhau.

Ví dụ thực tế

$ ros2 action info /navigate_to_pose -t

Output:
Action: /navigate_to_pose
Action clients: 0
Action servers: 1
    /bt_navigator [nav2_msgs/action/NavigateToPose]

Action clients: 0 cho biết hiện chưa có client nào (kể cả RViz2) đang gửi goal — nếu vừa click trên RViz2 mà thấy vẫn 0, vấn đề nằm ở kết nối giữa RViz2 và hệ thống, không phải ở phía bt_navigator.

Lỗi thường gặp

• Quên cờ --feedback rồi tưởng action bị treo — mặc định send_goal không in feedback, terminal "im lặng" trong lúc robot thực ra vẫn đang di chuyển bình thường — luôn thêm --feedback khi cần theo dõi tiến độ trực quan.
• Đọc nhầm goal bị REJECTED thành đã chấp nhận — cần đọc kỹ dòng đầu tiên Goal accepted... hay không, không chỉ giả định goal luôn được chấp nhận vì lệnh chạy "không lỗi".
• Kỳ vọng Ctrl+C dừng robot ngay lập tức — yêu cầu huỷ (cancel) cần thời gian để server xử lý (chuyển qua trạng thái CANCELING trước khi thực sự dừng), không phải lúc nào cũng tức thời tuyệt đối — với robot vật lý đang di chuyển, vẫn cần khoảng thời gian phanh lại an toàn.
• Action server không xử lý cancel đúng cách khiến lệnh huỷ "treo" mãi — nếu server implementation không kiểm tra cờ huỷ định kỳ (đã nói ở bài Action Communication), CLI có thể chờ mãi không thấy goal chuyển sang CANCELED — đây là dấu hiệu lỗi ở code server, không phải lỗi khi dùng CLI.

Kết luận

ros2 action send_goal --feedback là công cụ mạnh nhất để test action server từ terminal, đặc biệt giá trị khi debug từ xa qua SSH không có giao diện đồ hoạ. Luôn nhớ thêm --feedback và đọc kỹ trạng thái goal (accepted/rejected) thay vì chỉ tin lệnh "chạy không lỗi". Bài tiếp theo trong chuyên mục nói về ros2 param — công cụ tương đương để xem và đổi tham số node từ terminal.