ros2 service — gọi thử service từ terminal

Một service /reset_odometry hay /set_mode chỉ dùng thử vài lần khi debug — viết hẳn một client node cho việc này là phí thời gian. ros2 service cho phép gọi trực tiếp từ terminal, không cần viết dòng code nào.

Khái niệm chính

ros2 service list                    # liệt kê mọi service đang có
ros2 service type /reset_odometry    # xem kiểu service (request/response gì)
ros2 service call /reset_odometry std_srvs/srv/Trigger

Với service có tham số đầu vào phức tạp hơn Trigger (vốn không cần tham số), gõ thêm phần request dạng YAML:

ros2 service call /set_mode my_msgs/srv/SetMode "{mode: 'auto'}"

Nguyên lý hoạt động

Không nhớ format request? Để tab-complete tự điền:

ros2 interface show my_msgs/srv/SetMode

Lệnh này in ra đúng cấu trúc field của service (phần request phía trên dấu ---, response phía dưới) — tra trước khi gọi ros2 service call để biết chính xác cần điền field nào, tránh đoán mò. Terminal ROS2 cũng hỗ trợ nhấn Tab sau khi gõ tên service để tự động điền sẵn khung YAML rỗng đúng kiểu.

Tóm lại: Khác với topic (fire-and-forget, không đảm bảo ai nhận), service luôn có phản hồi ngay trong terminal sau khi gọi — nếu lệnh treo không trả về, gần như chắc chắn server phía node cung cấp service đó chưa chạy hoặc đang bị block ở đâu đó, không phải do cú pháp câu lệnh gọi sai.

Kiến thức kỹ thuật

Thông số

Một số hành vi/cờ cần biết khi dùng ros2 service call trong thực tế:

Thông số	Ghi chú
Timeout mặc định	Không có — lệnh chờ vô thời hạn nếu server không phản hồi, cần Ctrl+C để huỷ
ros2 service list -t	Liệt kê kèm luôn kiểu service, không cần gọi ros2 service type riêng cho từng cái
ros2 service call ... --rate N	Gọi lặp lại liên tục ở N Hz (hữu ích để test server chịu tải gọi liên tục)

Ứng dụng thực tế

ros2 service call trong script shell là cách đơn giản để dựng một bài kiểm tra tự động (self-test) trước khi cho robot vận hành thật — VD: 1 script chạy tuần tự gọi service self_test trên từng node quan trọng (driver động cơ, LiDAR, IMU), kiểm tra tất cả đều trả về success: true trước khi cho phép chuyển robot sang chế độ tự hành — cách này phát hiện sớm node nào đó chưa khởi động đúng, tránh để robot vận hành với 1 thành phần bị lỗi mà không ai biết.

#!/bin/bash
for srv in /motor_driver/self_test /lidar_driver/self_test /imu_driver/self_test; do
  result=$(ros2 service call "$srv" std_srvs/srv/Trigger | grep -o "success=True")
  if [ -z "$result" ]; then
    echo "LỖI: $srv không sẵn sàng — huỷ chuyển chế độ tự hành"
    exit 1
  fi
done
echo "Tất cả node đã sẵn sàng — cho phép chuyển chế độ tự hành"

Script trên gọi lần lượt từng service self_test, chỉ tiếp tục khi mọi node đều báo success=True — thất bại ở bất kỳ node nào sẽ dừng ngay và báo lỗi rõ ràng, thay vì để robot vận hành với 1 thành phần chưa sẵn sàng mà không ai kiểm tra trước. Cách tiếp cận này cũng dễ dàng tích hợp vào quy trình CI hoặc script khởi động tự động của robot, chạy như một bước kiểm tra bắt buộc trước khi hệ thống chuyển sang trạng thái vận hành.

Ví dụ thực tế

$ ros2 service call /reset_odometry std_srvs/srv/Trigger

Output:
waiting for service to become available...
requester: making request: std_srvs.srv.Trigger_Request()

response:
std_srvs.srv.Trigger_Response(success=True, message='Odometry reset thành công')

Đây là cách nhanh nhất để reset odometry giữa các lần chạy thử SLAM mà không cần restart toàn bộ node — miễn là package đã có sẵn service này.

Lỗi thường gặp

• Lệnh treo vô thời hạn khi server không tồn tại/không phản hồi — như đã nói ở mục Thông số, không có timeout mặc định — nếu chờ quá lâu mà không thấy response:, kiểm tra ros2 service list xem service đó có thực sự đang chạy hay không thay vì tiếp tục chờ.
• Lỗi cú pháp YAML với request có nhiều trường lồng nhau — tương tự lỗi ở ros2 topic pub, dùng ros2 interface show trước để biết chính xác cấu trúc cần điền, tránh đoán mò gây lỗi parse.
• Gọi đúng tên service nhưng sai kiểu — ros2 service call sẽ báo lỗi rõ ràng nếu kiểu service không khớp với kiểu server thực tế cung cấp — kiểm tra bằng ros2 service type trước khi gọi nếu không chắc chắn.
• Dùng ros2 service call cho vòng lặp tự động hoá tần suất cao — mỗi lần gọi CLI tốn overhead khởi tạo tiến trình, không phù hợp để gọi liên tục hàng chục Hz trong một quy trình tự động — với nhu cầu đó, viết 1 client node thật sự thay vì dựa vào CLI.

Kết luận

ros2 service call loại bỏ nhu cầu viết client node riêng chỉ để test — gọi trực tiếp từ terminal, xem phản hồi ngay lập tức, đặc biệt hữu ích cho các service tiện ích như reset/self-test. Luôn nhớ không có timeout mặc định khi debug lệnh bị treo. Bài tiếp theo trong chuyên mục nói về ros2 action — công cụ tương đương cho tác vụ dài có tiến độ và khả năng huỷ.