Lập trình robot với ROS - Phần 4: Các khái niệm

Trở lại với chuỗi bài viết về ROS, cũng một thời gian khá lâu do mình cần phải tìm hiểu về lĩnh vực này thêm. Trong bài viết này để tiếp tục chặng hành trình chúng ta cùng tìm hiểu về các khái niệm

Trước khi bắt đầu viết code trong ROS, chúng ta sẽ dành một chút thời gian để giới thiệu một số khái niệm chính làm nền tảng cho framework. Hệ thống ROS bao gồm một số lượng lớn các chương trình độc lập liên tục giao tiếp với nhau. Trong chương này, chúng ta sẽ thảo luận về kiến trúc này và xem xét các command-line tools tương tác với nó. Chúng ta cũng sẽ thảo luận chi tiết về naming schemes và namespaces được ROS sử dụng và cách sử dụng những lược đồ này để bạn có thể sử dụng lại code một cách hiệu quả hơn.

The ROS Graph

Một trong những "vấn đề thách thức" ban đầu thúc đẩy thiết kế ROS được gọi một cách trìu mến là vấn đề "fetch an item". Hãy tưởng tượng một robot tương đối lớn và phức tạp với một số máy ảnh và máy quét laser, một cánh tay điều khiển và một đế có bánh xe. Trong bài toán “tìm nạp một mặt hàng”, nhiệm vụ của robot là điều hướng môi trường gia đình hoặc văn phòng điển hình, tìm mặt hàng được yêu cầu và giao nó đến vị trí được yêu cầu. Nhiệm vụ này, giống như nhiều nhiệm vụ khác, dẫn đến một số quan sát về nhiều ứng dụng phần mềm ro-bot, trở thành một số mục tiêu thiết kế của ROS:

• Các tác vụ của ứng dụng có thể được phân tách thành nhiều hệ thống con độc lập, chẳng hạn như điều hướng, thị giác máy tính, cầm nắm, v.v.
• Các hệ thống con này có thể được sử dụng cho các nhiệm vụ khác, chẳng hạn như tuần tra an ninh, dọn dẹp, gửi thư, v.v.
• Với phần cứng và lớp trừu tượng thích hợp, phần lớn phần mềm ứng dụng có thể chạy trên bất kỳ rô bốt nào.

Lưu ý: một nút trong ROS graph đại diện cho một mô-đun phần mềm đang gửi hoặc nhận thông báo và một cạnh trong ROS graph biểu thị một luồng thông báo giữa hai nút. Mặc dù mọi thứ có thể trở nên phức tạp hơn, nhưng các nút thường là các quy trình POSIX và các cạnh là các kết nối TCP. Điều này cung cấp khả năng chịu lỗi bổ sung: một sự cố phần mềm thường chỉ xảy ra quá trình của chính nó. Phần còn lại của biểu đồ sẽ duy trì, chuyển các thông báo và hoạt động như bình thường. Các trường hợp dẫn đến sự cố thường có thể được tạo lại bằng cách ghi nhật ký các thông báo vào một nút và chỉ cần xem lại chúng sau trong quá trình debug.

Tuy nhiên, có lẽ lợi ích lớn nhất của kiến trúc dựa trên đồ thị, được kết hợp lỏng lẻo là khả năng tạo mẫu nhanh các hệ thống phức tạp với ít hoặc không cần “glue” phần mềm để thử nghiệm. Các nút đơn, chẳng hạn như nút object recognition trong hệ thống “fetch an item”, có thể được hoán đổi một cách đáng kể bằng cách khởi chạy một quy trình hoàn toàn khác, chấp nhận hình ảnh và xuất các đối tượng được gắn nhãn. Không chỉ có thể hoán đổi một nút duy nhất, mà toàn bộ các phần của biểu đồ (đồ thị con) có thể được chia nhỏ và thay thế, trong thời gian chạy, bằng các đồ thị con khác. Trình điều khiển phần cứng của robot thực có thể được thay thế bằng trình mô phỏng, hệ thống con điều hướng có thể được hoán đổi, thuật toán có thể được tinh chỉnh và biên dịch lại, v.v.

ROS đang tạo ra tất cả các phần mềm phụ trợ cần thiết một cách nhanh chóng, toàn bộ hệ thống tương tác và được thiết kế để khuyến khích thử nghiệm.

Cho đến thời điểm này, chúng ta đã giả định rằng bằng cách nào đó các nút tìm thấy nhau nhưng chưa mô tả cách thức hoạt động của quá trình đó. Trong số tất cả các lưu lượng bay xung quanh một mạng bận rộn, làm thế nào để các nút tìm thấy nhau, để chúng có thể bắt đầu chuyển thông điệp? Câu trả lời nằm trong một chương trình có tên là roscore.

ROSCore

Roscore là một dịch vụ cung cấp thông tin kết nối đến các nút để chúng có thể truyền thông điệp cho nhau. Mỗi nút kết nối với roscore khi khởi động để đăng ký thông tin chi tiết về luồng thông báo mà nó xuất bản và các luồng mà nó muốn đăng ký. Khi một nút mới xuất hiện, roscore cung cấp cho nó thông tin cần thiết để tạo kết nối ngang hàng trực tiếp với các nút khác xuất bản và đăng ký các chủ đề thông báo tương tự. Mọi hệ thống ROS đều cần một roscore, vì không có nó, các nút không thể tìm thấy các nút khác.

Tuy nhiên, một khía cạnh quan trọng của ROS là các thông điệp giữa các nút được truyền ngang hàng. Roscore chỉ được sử dụng bởi các nút để biết nơi tìm các đồng nghiệp của chúng. Điều này hơi tế nhị và có thể dẫn đến một số hiểu lầm, vì các lập trình viên xuất thân từ nền tảng web thường quen thuộc với các hệ thống server / client, chẳng hạn như trình duyệt web nói chuyện với web server, nơi vai trò của client và server được xác định rõ ràng . Kiến trúc ROS là sự kết hợp giữa hệ thống server / client cổ điển và hệ thống phân tán hoàn toàn, do sự hiện diện của một điểm trung tâm cung cấp name service cho các peer-to-peer message.

Khi một nút ROS khởi động, nó mong đợi process của nó có một biến môi trường có tên ROS_MASTER_URI. Biến này sẽ chứa một chuỗi có dạng http://hostname:11311/, trong trường hợp này ngụ ý rằng có một phiên bản roscore đang chạy có thể truy cập trên cổng 11311 ở đâu đó trên máy chủ có tên là hostname có thể được truy cập qua network.

Port 11311 được chọn làm port mặc định cho roscore vì nó là một số nguyên tố palindromic không được sử dụng bởi các ứng dụng phổ biến khác trong những ngày đầu của ROS, khoảng năm 2007. Nó không có ý nghĩa đặc biệt. Bất kỳ số port nào (1025–65535) đều có thể được sử dụng thay thế. Các port khác nhau có thể được chỉ định trong lệnh khởi động roscore và trong biến môi trường ROS_MASTER_URI để cho phép nhiều hệ thống ROS cùng tồn tại trên một mạng duy nhất.

Với kiến thức về vị trí của roscore trên mạng, các nút tự đăng ký khi khởi động với roscore và sau đó truy vấn roscore để tìm các nút và luồng dữ liệu khác theo tên. Mỗi nút ROS cho roscore biết nó cung cấp thông điệp nào và nó muốn đăng ký những thông điệp gì. Sau đó, roscore cung cấp địa chỉ của những producer và consumer tin nhắn có liên quan.

Tạm kết

Trong bài viết này chúng ta đã tìm hiểu hai khái niệm ban đầu về ROS Graph và ROSCore. Chúc bạn đọc vui vẻ