ROS2 Layer trong AMR: bản đồ topic thực tế của một robot hoàn chỉnh
Atlasbot · 22/8/2026 · 11 phút đọc
Chuyên mục ROS2 & phần mềm đã có loạt bài riêng giải thích node, topic, service là gì. Bài này không nhắc lại các khái niệm nền tảng đó — nó đứng đúng vị trí của mình trong mô hình 5 tầng: ROS2 Layer là hạ tầng giao tiếp nối Driver Layer (đã học ở bài trước) với Localization và Navigation (2 bài tiếp theo).
Khái niệm chính
Một AMR hoàn chỉnh thường có tối thiểu 3-4 node chính giao tiếp qua topic:
- driver_node — publish
/odom(từ encoder) và/imu(từ IMU), subscribe/cmd_velđể gửi lệnh xuống firmware - lidar_node — publish
/scan(dữ liệu LaserScan) - robot_localization (package EKF, đã nhắc ở bài IMU trong AMR) — subscribe
/odomvà/imu, publish/odometry/filtered - nav2 stack — subscribe
/scanvà/odometry/filtered, publish/cmd_vel
Không node nào biết trực tiếp về node khác — chúng chỉ biết tên topic và kiểu message cần publish/subscribe. Đây chính là điểm mạnh cốt lõi của kiến trúc middleware: có thể thay lidar_node bằng driver LiDAR khác mà không cần sửa bất kỳ node nào khác, miễn là vẫn publish đúng topic /scan với đúng kiểu message.
Nguyên lý hoạt động
DDS (nền tảng truyền thông bên dưới ROS2) tự động khớp publisher với subscriber theo tên topic — không cần cấu hình thủ công kết nối giữa các node. Nhưng "tự động khớp" không có nghĩa "mọi dữ liệu đều được xử lý như nhau" — mỗi loại dữ liệu trong AMR có yêu cầu khác nhau về độ tin cậy và độ trễ:
/cmd_vel (lệnh điều khiển): cần đến đúng lúc, mất 1 message không quá nghiêm trọng
vì message tiếp theo sẽ tới rất nhanh sau đó
/scan, /odom (dữ liệu cảm biến tần số cao): ưu tiên dữ liệu MỚI NHẤT hơn là
đảm bảo nhận đủ mọi message cũ
/map (bản đồ, publish không thường xuyên): cần đảm bảo node mới join
vẫn nhận được bản đồ hiện tại, dù publish từ trước đó rất lâu
Đây chính xác là bài toán mà QoS (Quality of Service) trong ROS2 giải quyết — đã trình bày chi tiết ở bài QoS tại chuyên mục ROS2 & phần mềm.
Kiến thức kỹ thuật
Công thức
Băng thông topic ước lượng — quan trọng khi nhiều node cùng chạy trên một mạng/máy tính, tránh nghẽn:
Băng_thông_topic ≈ Kích_thước_message × Tần_số_publish
VD: /scan (LiDAR 360°, 360 điểm, mỗi điểm ~4 byte float) ở tần số 10Hz
Kích_thước_message ≈ 360 × 4 = 1440 byte
Băng_thông ≈ 1440 × 10 = 14400 byte/s ≈ 14KB/s (rất nhỏ so với băng thông mạng thông thường)
VD: /camera/image_raw (640×480, RGB) ở tần số 30Hz
Kích_thước_message ≈ 640×480×3 = 921600 byte ≈ 900KB
Băng_thông ≈ 900KB × 30 ≈ 27MB/s (đáng kể, cần cân nhắc nén hoặc giảm tần số/độ phân giải)
Thông số
| Topic | Loại dữ liệu | QoS phù hợp |
|---|---|---|
/cmd_vel | Lệnh điều khiển, tần số cao | Reliable, ưu tiên message mới nhất |
/scan, /odom | Cảm biến tần số cao | Best-effort, chấp nhận mất vài message |
/map | Publish thưa, cần node mới vẫn nhận được | Transient local (giữ lại message cuối) |
Ứng dụng thực tế
Cấu trúc topic như trên cho phép chuyên mục Localization và Navigation tiếp theo hoàn toàn không cần biết /odom tới từ Differential Drive hay Mecanum Drive, không cần biết /scan tới từ LiDAR hãng nào — chúng chỉ subscribe đúng topic, đúng kiểu message chuẩn. Đây là lý do package robot_localization và toàn bộ Nav2 stack có thể tái sử dụng gần như nguyên vẹn giữa các dự án AMR hoàn toàn khác nhau về phần cứng, miễn là Driver Layer publish đúng chuẩn message ROS2 mong đợi.
Ví dụ thực tế
# Liệt kê toàn bộ topic đang chạy trên một AMR thực tế
ros2 topic list
# Output điển hình:
# /cmd_vel
# /odom
# /imu
# /scan
# /odometry/filtered
# /map
# /tf
# Kiểm tra tần số publish thực tế của /odom (nên khớp thiết kế, VD 50Hz)
ros2 topic hz /odom
# Kiểm tra QoS hiện tại của /scan
ros2 topic info /scan --verbose
Việc kiểm tra ros2 topic hz là bước debug đầu tiên khi nghi ngờ dữ liệu tới chậm hoặc thiếu — nếu tần số thực tế thấp hơn nhiều so với thiết kế (VD: 50Hz thiết kế nhưng đo được chỉ 15Hz), vấn đề nằm ở Driver Layer hoặc Hardware Layer bên dưới, không phải ở bản thân ROS2.
Lỗi thường gặp
- Dùng QoS mặc định cho mọi topic mà không cân nhắc đặc tính dữ liệu — như bảng Thông số, dữ liệu cảm biến tần số cao dùng Reliable QoS không cần thiết có thể gây tích luỹ độ trễ khi mạng/CPU tải cao.
- Tên topic không khớp chính xác (kể cả namespace) — publisher và subscriber tưởng đang nói chuyện với nhau nhưng thực chất không kết nối được do lệch tên topic dù chỉ một ký tự, và ROS2 không báo lỗi rõ ràng cho tình huống này.
- Không kiểm tra tần số publish thực tế trước khi nghi ngờ thuật toán — như ví dụ trên,
ros2 topic hznên là bước debug đầu tiên, tránh mất thời gian nghi ngờ sai tầng. - Publish dữ liệu ảnh/point cloud độ phân giải cao không cần thiết — như tính ở mục Công thức, dữ liệu hình ảnh chiếm băng thông lớn hơn nhiều so với dữ liệu số đơn giản, cần cân nhắc giảm tần số/độ phân giải nếu không thực sự cần thiết cho thuật toán đang chạy.
Kết luận
ROS2 Layer không tự sinh ra dữ liệu hay ra quyết định — nó là hạ tầng trung gian cho phép Driver Layer, Localization, và Navigation "nói chuyện" với nhau qua topic mà không cần biết chi tiết triển khai của nhau. Hiểu đúng bản đồ topic và chọn QoS phù hợp với đặc tính từng loại dữ liệu là kỹ năng debug quan trọng hơn nhiều so với việc thuộc lòng cú pháp ROS2. Bài tiếp theo trong chuyên mục đi vào Localization Layer — nơi dữ liệu /odom, /imu, /scan vừa nêu được hợp nhất thành ước lượng vị trí đáng tin cậy.
