Có phải ROS (Hệ điều hành Robot) là bắt buộc?

Chúng ta có phải xây dựng ROS cho nghiên cứu / ứng dụng robot không? Lợi thế chính là gì? Khi nào hoặc trong tình huống nào thì ROS là bắt buộc?

Tôi trở lại máy tính!

Giống như tôi đã nói trong bình luận này , ROS thường không bắt buộc. ROS là một trong số nhiều nền tảng, nổi tiếng chủ yếu là do Willow Garage tặng robot miễn phí tại một số thời điểm cho bất cứ ai viết nhiều mô-đun ROS nhất. Điều đó nói rằng, nó không phải là nền tảng tốt nhất có thể, và chắc chắn không có gì quá đặc biệt. Đặc biệt, cuộc thi nói trên đã dẫn đến rất nhiều mô-đun chất lượng thấp chỉ để có được số lượng cao hơn.

Theo thời gian, chất lượng của các mô-đun ROS đã tốt hơn và có rất nhiều trong số chúng. Do đó, sử dụng ROS, bạn có lợi ích khi sử dụng lại rất nhiều việc đã làm. Bạn có thể đọc ở đây một số lý do tại sao bạn có thể muốn sử dụng ROS.

Với ý nghĩ đó, bạn cũng nên xem xét các tác dụng phụ.

Kiểm soát phân tán

Với ROS, bạn có nhiều nút nói chuyện với nhau thông qua mạng. Điều này đôi khi tốt và dễ dàng, nhưng nói chung dẫn đến một sự chậm trễ khác nhau trong việc tiếp nhận tin nhắn. Do đó, bạn sẽ phải có độ trễ điều khiển lớn để đảm bảo tất cả các tin nhắn đến, điều đó có nghĩa là bạn không thể phản ứng nhanh với các sự kiện, điều này có nghĩa là bạn phải di chuyển robot của mình ở tốc độ chậm hơn để không bỏ lỡ các sự kiện đó.

Dù bạn có tin hay không, mọi người thực sự điều khiển robot thông qua ROS ( MoveIt! Là tên của bộ linh kiện có liên quan). Chậm. Không an toàn. Nhưng dễ!

Không thời gian thực

Ngay cả khi không được phân phối, ROS không phải là một nền tảng thời gian thực. Điều đó có nghĩa là bạn hoàn toàn tùy ý sử dụng nhân Linux để lên lịch cho các tác vụ của mình bất cứ lúc nào nó thấy phù hợp. Điều này là tốt cho một số ứng dụng, nhưng không tốt cho những người khác. Vì vậy, bạn cần phải xem xét các yêu cầu của riêng bạn. Bạn có cần phải đảm bảo rằng nhiệm vụ của bạn sẽ hoàn thành trong một khung thời gian đã biết không? Nếu vậy, bạn cần một hệ thống thời gian thực.

Lưu trữ môi trường thời gian chạy

Một điểm khác cần xem xét là, trong khi ROS là một giao thức giao tiếp chung, về cơ bản nó chỉ được hỗ trợ cho các môi trường được lưu trữ. Được lưu trữ có nghĩa là mã chạy trên hạt nhân, trái ngược với sự tự do có nghĩa là mã trực tiếp điều khiển phần cứng (ví dụ: trên vi điều khiển).

Nếu ứng dụng robot của bạn chạy gần với phần cứng và do đó bạn sẽ cần một chương trình chạy trên vi điều khiển, thì ROS không giúp ích gì cho bạn.

Khóa nền tảng

Cuối cùng nhưng không kém phần quan trọng, phát triển cho kết quả ROS trong một khóa nền tảng. Điều này có nghĩa là nếu trong tương lai, vì lý do này hay lý do khác, bạn quyết định dựa trên công việc của mình trên một nền tảng robot khác, chẳng hạn như OROCOS, YARP, v.v., sẽ rất tuyệt vời.

Bạn cũng sẽ bị khóa với Linux. Linux là tốt nhất, không còn nghi ngờ gì nữa, nhưng một ngày nào đó bạn có thể sẽ phải hỗ trợ một hệ thống khác, chẳng hạn như QNX, VxWorks, v.v. và bạn cũng sẽ gặp vấn đề ở đó.

Nếu bạn đang viết cho vi điều khiển, thì hãy quên ROS. Nếu bạn đang viết các mô-đun cấp cao, tôi khuyên bạn nên viết mã di động. Ví dụ: giả sử bạn đã phát triển một cảm biến mới và bạn muốn viết một mô-đun lấy dữ liệu từ cảm biến này, được kết nối với máy tính của bạn thông qua bus CAN.

Những gì bạn có thể làm trong tình huống này là viết một thư viện độc lập, với các chức năng có thể làm việc với cảm biến của bạn và thu thập dữ liệu. Bạn thậm chí có thể nghĩ đến việc sinh ra một chủ đề trong thư viện thu thập và xử lý dữ liệu định kỳ.

Khi bạn có thư viện trợ giúp này, bạn có thể tự do viết một mô-đun CLI, GUI, ROS, mô-đun OROCOS, mô-đun YARP, kết nối với Matlab hoặc bất cứ điều gì bạn muốn sử dụng để tương tác với cảm biến của bạn.

Lưu ý cuối cùng: những gì tôi đã nói ở đây thường áp dụng cho tất cả các nền tảng robot và không chỉ ROS.

"ROS" là một thuật ngữ tương đối, APM chạy mã tùy chỉnh đầy đủ được thiết kế riêng cho điều khiển quadrocopter, trong đó một ROS tùy chỉnh có thể được mong muốn để không bị sập, mặt khác, Navio + chạy trên nhân Linux và chạy mã khác ngoài tự động, và vẫn cố gắng để tránh bị rơi. Hầu hết các ROS thực sự là một tập hợp các chức năng trên hệ điều hành hiện có, trái ngược với việc viết một hệ điều hành từ đầu. Như với bất cứ điều gì, nó phụ thuộc.

Tuyên bố miễn trừ trách nhiệm: Câu trả lời này bằng cách nào đó là một phản ứng đối với bài đăng của Shahbaz, vì vậy nó có khuynh hướng ủng hộ ROS.

Tôi không nghĩ rằng ROS là bắt buộc, nhưng đó là điểm khởi đầu tuyệt vời và đáng để dành thời gian đầu tư. Nó bắt đầu trong Willow Garage, nhưng công ty này đã biến mất và ROS vẫn còn sống, được sử dụng và phát triển. Hầu hết ROS là nguồn mở hoàn toàn và cũng có thể sử dụng được về mặt thương mại, vì vậy không có cách nào mà ROS sẽ biến mất nếu một công ty không còn quan tâm đến nó nữa. Chất lượng mã của khóa học khác nhau giữa các mô-đun cốt lõi và triển khai các thuật toán tiên tiến mà một số sinh viên phd đã xuất bản cùng với bài báo của mình.

ROS đang tăng tốc ngày càng nhiều hơn trong các thiết lập công nghiệp (Tôi sẽ ngạc nhiên nếu có một phần đáng kể khởi động robot trên toàn thế giới không sử dụng ROS). Một số thuật toán sẽ được tiếp tục duy trì và phát triển bởi tập đoàn công nghiệp hồng và nếu bạn có một cái nhìn về các thành viên, thì thật đáng mừng khi ROS sẽ trở thành một tiêu chuẩn trong ngành:

http://rosindustrial.org/ric/civerse-members/

Cách phân phối sử dụng ROS giúp rất nhiều để tạo và duy trì các gói mới, đặc biệt là trong các nhóm. Các định nghĩa thông điệp và hành động giúp ích rất nhiều trong việc xác định giao diện để phần cứng và thuật toán có thể được trao đổi nhanh chóng. Nó cũng giúp tích hợp các thành viên nhóm mới vì một nút mới sẽ làm giảm các nút khác nếu nó gặp sự cố (miễn là nó không ăn hết RAM ..) vì vậy việc tích hợp các nút làm việc một phần vào hệ thống đang chạy là an toàn hiệu quả bị hạn chế. Giao tiếp sử dụng TCP đáng tin cậy và nhanh chóng (trên máy cục bộ), do đó việc truyền tin nhắn rất nhanh (vài trăm Hz cho một vòng điều khiển là có thể).

Không theo thời gian thực

ROS hiện không phải là thời gian thực vì đại đa số các thuật toán không có nhu cầu về thời gian thực. Cảm biến hoặc lập kế hoạch không có ràng buộc thời gian thực trong hầu hết các trường hợp (có bao nhiêu người đang chế tạo xe tự lái tốc độ cao?). Sẽ đủ nếu vòng điều khiển cuối cùng chạy trong thời gian thực và trong nhiều trường hợp điều này có thể được thực hiện trực tiếp trên động cơ (mà vị trí cuối cùng được gửi, ví dụ như qua CAN). Tuy nhiên, Real Time là một trong những mục tiêu cốt lõi của ROS2 ( https://github.com/ros2/ros2/wiki/Real-Time-Programming ) vì vậy ngay cả khi bạn cần điều này trong tương lai cho toàn hệ thống, ROS vẫn đảm bảo .

Nếu bạn thực sự muốn chạy các công cụ được nhúng, tất nhiên có một kết nối với arduino, để bạn có thể viết tin nhắn ROS trực tiếp trên arduino sau đó được gửi qua kết nối nối tiếp.

Chạy ROS trên Windows hiện tại khá khó khăn, nhưng vì Windows đang tiến gần hơn đến Linux (thậm chí bắt đầu có thứ gì đó giống như bash), nên chỉ còn là vấn đề thời gian cho đến khi có thể. (Nhưng ai muốn chạy một robot có cửa sổ nào?)

Các giao diện phần cứng và thuật toán:

Tôi nghĩ rằng đây thực sự là một điểm mạnh cho ROS. Rất nhiều robot có sẵn trên thị trường đã có giao diện ROS hoặc ai đó đã đầu tư một số thời gian để thực hiện giao diện. Hầu hết các vũ khí thương mại có thể được sử dụng trong MoveIt, rất nhiều công việc để có được một ứng dụng chạy với một nhánh cụ thể có thể được sử dụng lại với phần cứng khác.

Cộng đồng:

Một điểm mạnh khác của ROS. Các thuật toán mới có được giao diện ROS rất nhanh và rất nhiều người gặp vấn đề tương tự như bạn, vì vậy bạn sẽ tìm được ai đó giúp bạn.

http://doad.ros.org/doads/metrics/metrics-report-2016-07.pdf