Máy tính cá nhân điều khiển đội robot lau sàn thế nào?

• Robot lau
• Wi-Fi và bộ phát
• Broker hoặc agent trung gian
• Máy tính chạy chương trình điều khiển
• Điện thoại nhận cảnh báo

Bạn sẽ học được gì

• Vẽ chuỗi robot, Wi-Fi, broker hoặc agent và chương trình trên máy tính, rồi chia việc cho từng khối.
• So sánh MQTT với micro-ROS khi dùng làm đường nối robot với máy tính, và chọn kiểu giao nhận cho từng loại bản tin.
• Chỉ ra ba điểm lỗi của chuỗi, gồm máy tính ngủ, đổi điểm truy cập Wi-Fi và quá tải, cùng tín hiệu báo từng lỗi.

Cần biết trước

Nên đọc bài so sánh điều khiển tập trung và tự hành và bài về MQTT để nắm mô hình đăng ký và phát bản tin.

Việc nào chạy trên máy tính, việc nào ở robot?

Máy tính giữ những việc cần nhìn cả căn nhà, robot giữ những việc không được chậm. Cách chia này theo kiểu lai đã chọn ở bài so sánh nói trên. Bảng dưới là thiết kế minh họa, chưa phải kết quả thử.

Bản tin giữa hai bên rơi vào ba nhóm. Trạng thái nhỏ và đều đặn, nên chỉ mẫu mới nhất có ích. Lệnh cần được báo nhận trước khi trung tâm coi là robot đã tiếp nhận. Ảnh nặng, nên robot chỉ gửi khi trung tâm yêu cầu thay vì phát liên tục. Đây là lập luận thiết kế; kích thước và tần số cụ thể phải đo trên hệ thật. Có thể ước lượng tải bằng kích thước bản tin nhân tần số gửi của từng robot rồi cộng cả đội, cộng thêm ảnh và chi phí giao thức. Đo tốc độ nhận thực tế, tuổi mẫu và thời gian từ gửi lệnh đến báo nhận khi tăng tải; giảm ảnh trước khi làm chậm phản hồi điều khiển. Không suy ra số robot tối đa chỉ từ cấu hình máy tính.

• Robot lau
• Vòng phản xạ ngắn trong thân robot
• Tia cảm biến xuống mép bậc
• Laptop có bản đồ và đường phủ
• Nhận diện vật thể
• Nhật ký
• Lệnh đi xuống robot
• Trạng thái đi lên máy tính

MQTT hay micro-ROS nối robot với máy tính?

MQTT hợp khi cần một đường nối đơn giản; micro-ROS hợp khi phía máy tính đã chạy các nút ROS 2. Cả hai đều có một bên trung gian giữa robot và máy tính, nhưng bên đó làm việc khác nhau.

Theo tài liệu micro-ROS về MQTT, MQTT là giao thức bản tin nhẹ dùng trên TCP. Giao diện của nó là đăng ký và phát bản tin đơn giản. Máy khách nối với một broker MQTT, và broker điều phối việc trao đổi dữ liệu. Máy khách phải biết địa chỉ broker trước lần kết nối đầu tiên. Chuẩn MQTT không quy định cách gắn kiểu dữ liệu với chủ đề, nên việc hiểu bản tin thuộc về phía người dùng. Robot có thể dùng ESP-MQTT của Espressif, một cài đặt máy khách MQTT.

Với micro-ROS, tài liệu Micro XRCE-DDS mô tả XRCE Client là thiết bị ít tài nguyên. Nó nối với một XRCE Agent, agent hành động thay mặt client trong không gian dữ liệu toàn cục DDS. micro-ROS dùng Micro XRCE-DDS làm lớp trung gian mặc định. Khác broker MQTT, XRCE Agent không quản lý việc đăng ký và phát chủ đề. Trạng thái đại diện giao tiếp DDS có thể nằm ở agent; điều này không có nghĩa robot bỏ trạng thái nhiệm vụ hoặc dữ liệu cần cho về trạm.

Về giao nhận, đặc tả MQTT nêu rằng QoS 0 cho bản tin tới bên nhận đúng một lần hoặc không tới, còn QoS 1 bảo đảm tới ít nhất một lần. ROS 2 cũng cho chọn mức tin cậy, nhưng đây không phải ánh xạ hoàn toàn giữa hai giao thức: best effort cố gắng giao nhưng có thể làm mất, reliable bảo đảm giao và có thể thử lại. Thiết kế minh họa chọn như sau:

• Trạng thái dùng QoS 0 hoặc best effort, vì mẫu mới thay mẫu cũ.
• Lệnh dùng QoS 1 hoặc reliable. Vì có thể tới hai lần, mỗi lệnh mang một mã riêng để robot bỏ bản trùng.
• Khu vực đang giao dùng bản tin giữ lại (retained message). Khi máy khách gửi PUBLISH có cờ RETAIN, broker thay bản tin giữ lại cũ của chủ đề bằng bản mới. Nhờ vậy robot đăng ký sau có thể nhận lại khu đã lưu. Trong thiết kế minh họa, đây chỉ là dữ liệu phân vùng, không tự kích hoạt chuyển động: sau khi nối lại, robot phải kiểm phiên điều khiển, thời hạn và chờ trung tâm xác nhận lại.

• Robot
• Broker MQTT với bản tin
• Chương trình trên máy tính
• XRCE Agent
• Bản sao robot do agent giữ
• Vòng dữ liệu DDS có máy tính
• Ranh giới giữa hai cách

Làm sao biết từng khâu còn sống và giờ có khớp?

Trong mô hình minh họa, nhịp tim ứng dụng cho biết vòng xử lý vừa chạy, còn giờ chung giúp đối chiếu sự kiện. Còn kết nối tới broker chưa chứng minh chương trình điều khiển vẫn xử lý được lệnh. Mỗi cơ chế có tín hiệu riêng.

Với MQTT, Keep Alive là khoảng tối đa cho phép trôi qua giữa các gói điều khiển do máy khách gửi. Nếu Keep Alive khác không và broker không nhận được gói nào trong một lần rưỡi khoảng đó, broker phải đóng kết nối. Khi không có gói nào khác để gửi, máy khách phải gửi PINGREQ. Nếu không nhận được PINGRESP trong khoảng hợp lý, máy khách nên đóng kết nối mạng. Khi kết nối đóng bất thường, broker còn hoạt động có thể phát bản tin di chúc (Will Message) theo cấu hình, báo kết nối bị mất; nó không xác định vị trí hay tình trạng vật lý của robot. Nếu broker cũng ngủ hoặc hỏng, không thể trông chờ nó phát cảnh báo.

Với ROS 2, thời hạn lease (lease duration) là thời gian tối đa một bên đăng có để báo còn sống. Quá hạn đó, hệ thống coi nó đã mất liveliness. Nút cũng định kỳ thông báo sự hiện diện và báo khi ngừng hoạt động. Hai nút chỉ nối được khi thiết lập chất lượng dịch vụ tương thích. Cặp cấu hình lệch có thể không nối được dù cả hai nút đang chạy.

Chiều ngược lại cũng cần: robot theo dõi một bản tin nhịp tim do trung tâm phát. Mất bản tin đó có thể do máy tính ngủ, chương trình treo hoặc liên kết hỏng, và robot chuyển sang phản xạ an toàn.

Về giờ, NTP được dùng rộng rãi để đồng bộ đồng hồ máy tính. Offset là độ lệch giờ ước lượng của đồng hồ máy chủ so với đồng hồ hệ thống; delay là độ trễ khứ hồi giữa máy khách và máy chủ. SNTP dành cho máy khách có một máy chủ thượng nguồn duy nhất. Vì vậy mỗi robot có thể trỏ về một nguồn giờ, ví dụ máy tính điều khiển. Trên robot, thư viện SNTP của lwIP trong ESP-IDF đặt giờ khi nhận phản hồi từ máy chủ NTP. Giờ chung giúp trung tâm đối chiếu sự kiện của nhiều robot; sự kiện gần nhau vẫn có thể khó xếp thứ tự vì còn sai số đồng bộ. Trong thiết kế minh họa, thời hạn dừng được đo bằng đồng hồ đếm thời gian cục bộ không lùi, để việc chỉnh giờ không kéo dài lệnh cũ.

Hai thiết lập ROS 2 giúp giới hạn dữ liệu cũ nhưng không tự chẩn đoán được quá tải: keep last chỉ giữ tối đa một số mẫu theo độ sâu hàng đợi, và bản tin quá lifespan bị bỏ lặng lẽ.

• Hai đồng hồ cùng giờ
• Nhịp tim robot gửi
• Nhịp tim không còn
• Nhịp tim tới trung tâm
• Khoảng chờ tính từ nhịp cuối
• Điểm hết hạn
• Bản tin di chúc

Vì sao nên bắt đầu bằng laptop rồi chuyển sang máy chuyên dụng?

Laptop có sẵn và cho phép viết, chạy, mô phỏng trên cùng một máy. Nhưng nó dễ ngủ, đổi mạng và rời nhà, nên chỉ hợp giai đoạn thử. Bảng dưới liệt kê các điểm lỗi và tín hiệu báo chúng.

Máy chuyên dụng cần được cấu hình không ngủ, giám sát tiến trình và nguồn điện; chỉ đổi máy không tự tránh được lỗi này. Nối cáp tới bộ phát Wi-Fi bỏ liên kết không dây của chính máy tính, còn lỗi robot đổi điểm truy cập vẫn còn. Địa chỉ cố định còn quan trọng hơn: máy khách MQTT phải biết địa chỉ broker, nên đổi địa chỉ làm cả đội mất đường về. Chuỗi giữ nguyên (robot, Wi-Fi, broker hoặc agent, chương trình), nên việc chuyển chỉ đổi nơi chạy chứ không đổi giao thức.

• Laptop đang ngủ
• Wi-Fi yếu hoặc đứt
• Chuyển nơi chạy
• Máy chuyên dụng chạy liên tục
• Cáp tới bộ phát Wi-Fi
• Địa chỉ cố định

Ví dụ trong đời sống

Một văn phòng nhỏ có ba robot; broker và chương trình điều khiển chạy trên một laptop. Đây là kịch bản thiết kế, chưa phải kết quả thử. Chương trình chọn khu hành lang cho robot thứ ba. Nó phát lệnh giao khu trên chủ đề lệnh của robot đó, mang mã riêng và dùng QoS 1.

Broker chuyển lệnh tới robot. Robot ghi nhận mã, phát trạng thái "đã nhận khu" rồi bắt đầu lau. Trung tâm thấy trạng thái đó nên thôi gửi lại. Nếu hết thời gian chờ mà chưa thấy báo nhận, trung tâm gửi lại cùng mã, và robot bỏ bản trùng.

Giờ nghỉ trưa, laptop gập nắp. Broker dừng, kết nối của cả ba robot đứt, và không còn nhịp tim của máy tính. Robot ngắt bơm rồi chỉ về trạm khi còn định vị được, có đường về đã lưu và đủ pin; nếu không thì dừng và ghi lỗi. Khi laptop thức, robot kết nối lại tới địa chỉ broker đã biết. Trung tâm hỏi trạng thái và vị trí mới, đối chiếu mã nhiệm vụ rồi mới quyết định tiếp tục hay giao lại; thiếu báo nhận không chứng minh lệnh trước chưa chạy.

Chiều đó robot thứ hai rời vùng phủ của một điểm truy cập và nối sang điểm khác. Kết nối cũ rớt, broker đóng nó sau một lần rưỡi Keep Alive rồi phát bản tin di chúc. Trung tâm đánh dấu robot đã mất, chờ một khoảng định trước, nhưng chưa giao chồng khu đó cho robot khác khi chưa biết vị trí robot mất liên lạc. Trong ví dụ này, trung tâm chỉ giao lại sau khi xác nhận robot cũ đã dừng hoặc được tách khỏi vùng làm việc.

Hiểu lầm thường gặp

QoS 1 bảo đảm lệnh chạy đúng một lần. QoS 1 chỉ bảo đảm tới ít nhất một lần, nên một lệnh có thể tới hai lần. Mỗi lệnh cần mã riêng để robot bỏ bản trùng.

Còn nhịp tim nghĩa là robot đang lau đúng. Nhịp tim cho biết máy khách và liên kết còn sống. Bản tin trạng thái phải mang thêm việc robot đang làm.

Máy tính mạnh thì không phải lo Wi-Fi. Wi-Fi nhà có thể mất gói, nên mỗi loại bản tin cần chọn giữa best effort và reliable. Sức mạnh của máy tính không thay được lựa chọn đó.

Câu hỏi thường gặp

Có cần ROS 2 để điều khiển nhiều robot từ máy tính không?

Không bắt buộc. MQTT với một máy khách ESP-MQTT trên robot đã đủ cho trạng thái, lệnh và nhịp tim. micro-ROS có lợi khi phía máy tính đã dùng các nút ROS 2.

Nên đặt broker MQTT ở đâu?

Đặt trên máy chạy liên tục và có địa chỉ cố định. Đặt cùng máy với chương trình điều khiển thì đơn giản, nhưng khi máy đó ngủ, cả hai dừng cùng lúc.

Wi-Fi yếu thì nên dùng chế độ giao nhận nào?

Còn tùy loại bản tin. Trạng thái chịu được mất mẫu nên dùng QoS 0 hoặc best effort; lệnh không được mất nên dùng QoS 1 hoặc reliable, kèm mã để bỏ bản trùng.

Tóm tắt

• Máy tính giữ kế hoạch, bản đồ, nhận diện và cảnh báo; robot giữ phản xạ và nhịp tim, nối nhau qua broker MQTT hoặc XRCE Agent.
• MQTT với QoS 0, QoS 1, bản tin giữ lại, Keep Alive và bản tin di chúc đủ cho một đội nhỏ; micro-ROS hợp khi phía máy tính dùng ROS 2.
• Máy ngủ, đổi điểm truy cập và quá tải mỗi loại có một tín hiệu riêng; bắt đầu bằng laptop rồi chuyển sang máy chuyên dụng có địa chỉ cố định.