ROS: Thực hành tốt nhất?


14

Tôi sẽ xây dựng một hệ thống robot nhỏ và có vẻ như ROS phục vụ một khung công tác tốt để kiểm soát và lập trình hệ thống.

Tuy nhiên, tôi tự hỏi đâu là cách thực hành tốt nhất để quản lý các thành phần của robot của tôi.

  • Liệu nó có ý nghĩa để đặt tất cả các cảm biến trong một nút?

  • Tôi chỉ nên đặt các cảm biến cùng loại trong một nút hay tốt hơn là có một nút cho một cảm biến?

  • Đây có phải là một cách thực hành tốt để có một số loại nút xử lý, lấy đầu vào từ các cảm biến và điều khiển các bộ truyền động tương ứng hoặc các nút chấp hành và các nút cảm biến giao tiếp trực tiếp?


  1. Các nút cảm biến hợp nhất và các nút chấp hành với trình xử lý 1. Các nút cảm biến hợp nhất và các nút chấp hành với trình xử lý

  2. Các nút cảm biến và cơ cấu chấp hành đơn với trình xử lý nhập mô tả hình ảnh ở đây

  3. Giao tiếp trực tiếp nhập mô tả hình ảnh ở đây

Đối với tôi, tôi đoán tốt nhất là có một số trình xử lý, xử lý giao tiếp giữa các cảm biến và cơ cấu chấp hành và có một nút cho mỗi phần tử của robot (như trong hình 2), bởi vì hệ thống này theo cách này được ghép lỏng lẻo và có thể được mở rộng dễ dàng, nhưng tôi muốn biết ý kiến ​​của bạn là gì.

Câu trả lời:


15

Câu trả lời rất ngắn: 2


Cảm biến

Về việc đọc từ tất cả các cảm biến trong một nút hoặc mỗi nút riêng biệt, bạn nên tự hỏi mình câu hỏi này:

Là các cảm biến vô nghĩa mà không có khác?

Câu hỏi này hỏi liệu các cảm biến được liên kết chặt chẽ hay không. Ví dụ: giả sử bạn có một cảm biến nhạy cảm với nhiệt độ (và bạn cần phải bù cho nó). Bạn thêm một cảm biến nhiệt độ chủ yếu để sửa giá trị của cảm biến khác. Trong kịch bản này, sẽ hợp lý khi đọc cả hai giá trị cùng một lúc, vì chúng được kết hợp chặt chẽ. Trong thực tế, không có các bài đọc từ cảm biến nhiệt độ, các bài đọc từ cảm biến ban đầu là vô ích.

Mặt khác, nếu các cảm biến là hữu ích riêng lẻ, bằng mọi cách giữ chúng trong các nút riêng biệt. Điều này có nhiều lợi ích:

  • Các nút có thể được chạy trên các bộ xử lý riêng biệt
  • Các nút có thể được tái sử dụng trong các robot trong tương lai
  • Lỗi trong giao tiếp với một nút không làm giảm toàn bộ hệ thống
  • Khởi động lại việc mua lại từ bảng cảm biến bị lỗi có thể được thực hiện tách biệt với các bảng khác

Trong thực tế, nếu bạn cần bất kỳ lợi ích nào ở trên, bạn sẽ phải sử dụng các nút riêng biệt, ngay cả khi các cảm biến được liên kết chặt chẽ, nhưng điều đó thường không xảy ra.

Thiết bị truyền động

Điều này là tương tự.

Là các thiết bị truyền động vô nghĩa mà không có khác?

Ví dụ: nếu bạn đang thiết kế một cổ tay có các gân robot , trong đó đối với mỗi gân (vì bất kỳ lý do gì), hai động cơ có trách nhiệm đồng thời làm việc để di chuyển khớp theo một hoặc một hướng khác, sau đó chúng được phục vụ trong cùng một nút sẽ tạo ra nhiều hơn ý nghĩa hơn riêng biệt.

Mặt khác, trong đó các bộ truyền động là độc lập (trường hợp phổ biến), sẽ có một nút cho mỗi bộ chấp hành. Trong trường hợp đó, mỗi có thể được đặt trong một nút khác nhau. Bên cạnh những lợi ích chính xác như với các cảm biến, còn có thêm lợi ích này:

  • Nếu một bộ truyền động bị đình trệ (vì bất kỳ lý do gì), các bộ truyền động khác vẫn hoạt động. Nếu có mức độ tự do dư thừa, họ thậm chí có thể bù đắp hoàn toàn cho nó.

Điều này có một hàm ý. Nếu bạn cần các bộ truyền động để làm việc hài hòa, sau đó đặt chúng vào cùng một nút. Điều này không chỉ vì thất bại trong giao tiếp, mà bởi vì các nút khác nhau có nghĩa là sự chậm trễ khác nhau; trên một hệ thống phân tán, mỗi nút nằm trên một phần khác nhau của mạng và do đó sự khác biệt về độ trễ, trên hệ thống tập trung, sự chậm trễ khác nhau xảy ra đối với tải CPU cao do mỗi quá trình may mắn trong lịch.

Có nên xử lý?

Mặc dù câu trả lời là "nó phụ thuộc", có một cách tiếp cận phổ biến với nhiều ưu điểm. Hãy thay đổi tên và gọi nó là "bộ điều khiển". Cách tiếp cận là "có, nên có một bộ điều khiển".

Những lợi thế của việc có một bộ điều khiển là (trong số nhiều):

  • Xử lý tách rời: mỗi nút chịu trách nhiệm cho một điều có nghĩa là:
    • Đơn giản: ngụ ý
      • Phát triển dễ dàng hơn
      • Gỡ lỗi dễ dàng hơn
      • Ít lỗi hơn
      • Ít cơ hội thất bại
    • Khả năng sử dụng lại: bởi vì cùng một bộ điều khiển có thể được sử dụng với các nút cảm biến khác nhau nếu chúng có cùng chức năng (nghĩa là định dạng tin nhắn và dịch vụ).
  • Thực thi trên phần cứng riêng biệt: mỗi nút có thể được di chuyển trong mạng. Ví dụ, các nút cảm biến và bộ truyền động có thể được chuyển sang một bộ vi điều khiển chuyên dụng ( ví dụ Arduino (không phải tôi khuyên dùng)) và bộ điều khiển trên PC.
  • Tránh sự xấu xí cực độ: nếu các cảm biến muốn ảnh hưởng trực tiếp đến các cơ cấu chấp hành, kết quả chỉ đơn giản là một mớ hỗn độn. Giả sử không có bộ điều khiển, chúng ta hãy xem xét từng trường hợp:
    • Một nút cảm biến: về cơ bản, điều này có nghĩa là nút cảm biến và bộ điều khiển được đặt cùng một nút. Không quá tệ, nhưng rất không cần thiết.
    • Nhiều nút cảm biến: đây là mớ hỗn độn. Điều này có nghĩa là bộ điều khiển được phân phối giữa các nút cảm biến. Do đó, tất cả các nút cảm biến phải nói chuyện với nhau để biết cách điều khiển (các) bộ truyền động liên quan của nó. Hãy tưởng tượng một sự thất bại trong giao tiếp hoặc các loại chậm trễ khác nhau và bạn sẽ thấy nó trở nên khó khăn như thế nào. Cho rằng điều này là hoàn toàn không cần thiết, không có lý do để làm điều đó!

Những điều này nói, có những bất lợi quá. Có nhiều nút hơn (bất kỳ nút nào, không chỉ bộ điều khiển) có nghĩa là:

  • Truyền thông bị lãng phí nhiều hơn: dữ liệu phải di chuyển xung quanh theo các định dạng tiêu chuẩn (được tuần tự hóa và giải tuần tự hóa) thông qua mạng hoặc bộ nhớ dùng chung, lõi ROS phải xem xét chúng và quyết định giao chúng cho ai, v.v. Tóm lại, một số tài nguyên hệ thống bị lãng phí trong giao tiếp. Nếu tất cả các nút trong một, chi phí đó có thể bằng không.
  • Cơ hội thất bại cao hơn: nếu vì bất kỳ lý do gì khiến liên kết mạng bị hỏng hoặc nút bị chết, hệ thống sẽ bị lỗi. Nếu bạn không chuẩn bị cho nó, nó có thể phá hủy toàn bộ hệ thống. Bây giờ đây thực sự là một điều tốt để có thể mất một phần của hệ thống nhưng không phải tất cả của nó ( sự xuống cấp duyên dáng ), nhưng cũng tồn tại các ứng dụng mà điều này nên tránh càng nhiều càng tốt. Cắt giao tiếp và đặt tất cả mã vào một nút thực sự giúp ổn định hệ thống. Mặt trái là tất nhiên, hệ thống hoặc hoạt động tốt hoặc đột nhiên chết hoàn toàn.
  • Thời gian hỗn loạn: mỗi nút chạy trên chính nó. Thời gian để tin nhắn của nó đến được với người khác là không xác định và thay đổi theo từng bước. Trừ khi các nút của bạn đánh dấu thời gian từng thông báo (như một lưu ý phụ: bạn cần phải có đồng hồ được đồng bộ hóa ở mức độ tốt, mà ROS không có) và trừ khi mỗi nút nhận có thể tính đến độ trễ và kiểm soát phù hợp (đây là một nhiệm vụ rất khó khăn trên chính nó) sau đó có nhiều nút có nghĩa là không chắc chắn cao về tuổi của dữ liệu. Đây thực sự là một trong những lý do (trong số rất nhiều) rằng hầu hết các robot di chuyển rất chậm; vòng điều khiển của chúng phải đủ chậm để đảm bảo tất cả dữ liệu tương ứng với giai đoạn hiện tại. Độ trễ càng lớn, vòng điều khiển càng chậm.

Trong tất cả các nhược điểm trên, giải pháp là giảm số lượng nút, tốt nhất là xuống một nút. Đợi một chút, đó là không sử dụng ROS nữa! Chính xác.

Để tóm tắt:

  • Sử dụng ROS cho các hệ thống phi thời gian thực, nơi sự chậm trễ có thể tăng cao. Trong trường hợp đó, vui lòng có nhiều nút ROS như bạn muốn. Trên thực tế, thực tế rất tốt khi mỗi nút ROS thực hiện một và chỉ một điều. Bằng cách đó, chúng trở nên rất đơn giản, và chúng trở nên có khả năng tái sử dụng cao.
  • Mặt khác, đối với các hệ thống thời gian thực, bằng mọi cách tránh ROS. Cho rằng có orocos và các công nghệ như EtherCAT và thường xuyên hơn không, các giải pháp đặc biệt.

Là một từ cuối cùng, trong thực tế, ROS làm tốt. Không tuyệt vời, nhưng tốt. Rất thường hệ thống không quan trọng và khả năng thất bại là rất nhỏ đến nỗi cứ sau một lần khởi động lại không phải là vấn đề lớn. Đây là thuật toán đà điểu !


1
Wow, câu trả lời rất hay và chi tiết! Cảm ơn bạn rất nhiều vì thời gian của bạn;)
manf
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.