Làm cách nào tôi có thể điều khiển hệ thống thời gian thực nhanh (200Hz) với hệ thống chậm (30Hz)?

Chúng tôi hiện đang thiết kế một robot di động + cánh tay gắn kết với nhiều mức độ tự do và cảm biến được kiểm soát.

Tôi đang xem xét một kiến ​​trúc trong hai phần:

1. Một bộ các bộ điều khiển thời gian thực (Raspeberry Pis chạy RTOS như Xenomai hoặc vi điều khiển kim loại trần) để điều khiển động cơ cánh tay và bộ mã hóa. Hãy để chúng tôi gọi các máy này là RTx, với x = 1,2,3, tùy thuộc vào số lượng vi điều khiển. Vòng điều khiển này sẽ chạy ở 200Hz.

2. Một cỗ máy linux vanilla mạnh mẽ chạy ROS để tính toán SLAM, mocap và thực hiện logic mức cao (quyết định nhiệm vụ của robot và tính toán vị trí và tốc độ mong muốn của động cơ). Vòng điều khiển này sẽ chạy ở 30Hz.

Tôi biết khuôn khổ của tôi cần có khả năng mở rộng để chiếm nhiều động cơ hơn, nhiều cảm biến hơn, nhiều PC hơn (ví dụ: đối với mocap bên ngoài).

Vấn đề chính của tôi là quyết định làm thế nào để RTx khác nhau giao tiếp với PC1. Tôi đã xem xét các bài báo liên quan đến kiến ​​trúc robot (ví dụ HRP2 ), hầu hết họ thường mô tả kiến ​​trúc điều khiển cấp cao nhưng tôi vẫn chưa tìm thấy thông tin về cách để giao tiếp cấp thấp với cấp cao và theo cách có thể mở rộng. Tôi đã bỏ lỡ một cái gì đó?

Để kết nối các máy RT nhanh đảm bảo điều khiển động cơ với PC1, tôi đã xem xét TCP / IP, CAN và UART:

• TCP / IP: không xác định nhưng dễ đặt. Là không xác định là một vấn đề thực sự (vì nó sẽ chỉ được sử dụng ở tốc độ chậm 30Hz dù sao)?
• CAN: chậm, rất đáng tin cậy, nhắm vào ô tô (đã thấy có một số ví dụ sử dụng CAN với robot nhưng trông có vẻ kỳ lạ)
• UART: nếu tôi chỉ có một máy RT để điều khiển động cơ thì tôi đã xem xét UART nhưng tôi đoán cổng này không hoạt động tốt với nhiều RTx Có phải TCP / IP thực sự không hoạt động vì các đặc điểm không xác định của nó? Nó rất dễ sử dụng

Hiện tại không có giải pháp nào thực sự rõ ràng đối với tôi. Và vì tôi không thể tìm thấy ví dụ robot nghiêm túc nào bằng cách sử dụng một giải pháp đáng tin cậy và có thể mở rộng cụ thể, tôi không cảm thấy tự tin để đưa ra lựa chọn.

Có ai có một cái nhìn rõ ràng về điểm này hoặc văn học để chỉ đến? Có giải pháp truyền thông điển hình hoặc chính thống được sử dụng trên robot?

Tôi nghĩ rằng bạn đã thực hiện bước đầu tiên tốt; bạn đã phân chia vấn đề thành một nền tảng di động (không chắc chắn về vị trí và phải điều hướng) và cánh tay (có sự chắc chắn về vị trí trong thời gian thực, thông qua các bộ mã hóa).

Tôi đã xem xét các bài báo liên quan đến kiến ​​trúc robot [...] nhưng tôi vẫn chưa tìm thấy thông tin về cách để có mức độ thấp giao tiếp với cấp độ cao và theo cách có thể mở rộng. Tôi đã bỏ lỡ một cái gì đó?

Từ mô tả của bạn, có vẻ như bạn đang cố gắng liên kết trực tiếp từng bộ điều khiển RTx với PC1 đang chạy ROS. Điều bạn đã bỏ lỡ là ROS được thiết kế để xử lý một nhóm các ứng dụng có thể tạo và tiêu thụ dữ liệu ở các mức giá khác nhau.

Những gì ứng dụng của bạn cần là một cầu nối truyền thông - một giao diện duy nhất giữa vòng lặp 200Hz và môi trường ROS của bạn. Nói cách khác, thay vì buộc từng bộ điều khiển RTx vào PC1, hãy buộc tất cả các bộ điều khiển RTx lại với nhau và kết nối nó với PC1.

Ví dụ: sử dụng I2C Bus để liên kết các hệ thống RTx với nhau và thêm một bộ điều khiển RTx khác làm "Arm Master" (AM). Công việc của AM sẽ là chấp nhận các lệnh đến trong một số định dạng và giao thức thân thiện với PC1 và chuyển đổi các lệnh đó thành các thông điệp I2C. Sau đó, bạn sẽ viết một ứng dụng ROS để gửi lệnh đến AM.

Một cách khác để làm điều đó với I2C là đặt bộ điều khiển I2C trực tiếp lên PC1 và viết tất cả logic điều khiển cánh tay trong ứng dụng ROS. Điều này có vẻ như là một cách hợp lý hơn để thực hiện mục tiêu của bạn, nhưng nó có thể khiến việc gỡ lỗi trở nên khó khăn hơn khi bạn loại bỏ tính mô-đun của hệ thống - bạn sẽ phải khắc phục sự cố như một hệ thống phức tạp lớn thay vì hai thành phần dễ kiểm tra.

Tôi muốn nói rằng bất kỳ ứng dụng nào yêu cầu số lượng lớn các nút truyền thông (cảm biến hoặc bộ truyền động) sẽ được hưởng lợi khi được triển khai như một bus hệ thống (ngược lại với các liên kết điểm tới điểm như UART hoặc Ethernet), do độ phức tạp của hệ thống dây điện, tính xác định và tính mô đun.

Bất kỳ hệ thống điều khiển nào cũng đòi hỏi mức độ xác định cao, mà các kênh băng thông cao (như Ethernet) thường kém (đặc biệt là khi được sử dụng với HĐH có mục đích chung giới thiệu một lượng lớn jitter lập lịch, hãy xem liên kết sau để thảo luận về tính xác định lập lịch ). Các bộ xử lý ứng dụng (như ARM11 của Raspberry Pi) cũng có thể không phù hợp với các hệ thống thời gian thực (do các hiệu ứng như độ trễ ngắt và lớp lót ống dẫn). Xem phần thảo luận sau đây so sánh hành vi thời gian thực của lõi ứng dụng ARM với vi điều khiển .

Thật đáng tiếc khi tính khả dụng của CAN tích hợp không phổ biến như UART (RS-485) hoặc I2C (chưa), vì tôi nghĩ rằng nó thực sự đơn giản hóa vấn đề cảm biến phân tán và truyền động. Và mặc dù 1 Mbps thông thường có vẻ chậm, nhưng nó thường là quá đủ sau khi tính toán tốc độ làm mới của tất cả các thành viên xe buýt (và tốc độ truyền luôn có thể tăng lên, tùy thuộc vào độ dài xe buýt, trở kháng và liệu bộ thu phát của bạn có cho phép không). Ngoài ra còn có phần mềm mô phỏng tuyệt vời, về cơ bản đảm bảo thời gian phản hồi trong trường hợp xấu nhất (ví dụ RealTime-at-work có bộ phân tích bus CAN miễn phí có tên RTaW-Sim). Và cuối cùng, có vẻ như sự sẵn có của các cảm biến MEMS với CAN tích hợp là khá kém.

Một ví dụ khác trong đó các bộ truyền động được cấu hình là một bus (hoặc vòng), là sê-ri Dynamixels AX và MX, trong đó mỗi động cơ được nối với nhau thông qua liên kết UART. Điều này giúp đơn giản hóa rất nhiều thiết kế hệ thống nếu bạn có một lượng lớn bộ truyền động.

Nhưng, để quay lại câu hỏi thực tế, tôi nghĩ rằng nếu bạn mô tả hệ thống của bạn là các điểm đặt thời gian thực, thay vì các lệnh (ví dụ: liên tục phát một góc động cơ hơn là chỉ dẫn một lệnh như góc goto), nó sẽ đơn giản hóa việc ghép giữa vòng lặp 200 Hz và 30 Hz.

Bạn dường như có 2 vấn đề riêng biệt (nhưng có liên quan) mà bạn đang cố gắng giải quyết cùng một lúc. Hãy chia nhỏ câu hỏi hóc búa của bạn thành các phần nhỏ hơn:

1. Làm cách nào để giao tiếp các lệnh từ hệ thống chậm (30Hz) đến bộ điều khiển nhanh (200Hz) và làm cách nào để giao tiếp dữ liệu được nhận ở 200Hz trở lại với thinktank 30Hz của tôi?
2. Làm cách nào để kiểm soát những gì đang xảy ra ở 200Hz, khi tôi chỉ có thể nói cho robot biết phải làm gì ở 30Hz?

Mục 1 có thể được giải quyết bằng phần cứng vì câu hỏi ban đầu của bạn dường như chỉ ra - bạn có thể xếp hàng dữ liệu ở 200Hz và gửi gói tin ở tần số 30Hz đến hệ thống cấp cao hơn của bạn. Bạn có thể làm điều này với TCP / IP hoặc có thể CÓ THỂ tùy thuộc vào lượng dữ liệu bạn muốn gửi. Phần cứng khác nhau có tốc độ dữ liệu tối đa khác nhau. Thêm một cấp độ kiến ​​trúc như ROS để đóng vai trò là cầu nối / trọng tài truyền thông như được đề xuất trong các bài đăng khác cũng có thể giúp ích.

Mục 2 là một vấn đề lý thuyết điều khiển không thể được giải quyết chỉ với phần cứng. SLAM, xác định vị trí và tốc độ và xác định nhiệm vụ mà bạn muốn sẽ cần phải thông minh hơn vì chúng gửi và nhận thông tin ít thường xuyên hơn. Bạn có thể sẽ muốn 2 vòng điều khiển : 1 ở 200Hz và 1 ở 30Hz.

Có rất nhiều câu hỏi khác bao gồm các vòng lặp điều khiển phản hồi, phản hồi và phản hồi PID, nhưng bạn đã hỏi cụ thể về khả năng mở rộng - cách mà hầu hết các hệ thống khổng lồ quy mô là bằng cách xếp lớp các vòng điều khiển và logic sao cho thông tin cần thiết tối thiểu đi qua bất kỳ phần cứng nào bạn kết thúc với Ví dụ: bộ điều khiển cấp cao nhất của bạn chỉ có thể cung cấp điểm vị trí mục tiêu và tốc độ mục tiêu trung bình cho cấp thấp hơn, không thay đổi tốc độ 30 lần một giây.