Làm thế nào trưởng thành là lập trình thời gian thực trong robotics? [đóng cửa]

Chỉnh sửa: Tôi không biết tại sao, nhưng câu hỏi này dường như gây nhầm lẫn cho nhiều người. Tôi nhận thức được khi nào / ở đâu / tại sao / làm thế nào để sử dụng thời gian thực. Tôi quan tâm đến việc liệu những người có nhiệm vụ thời gian thực có thực sự quan tâm đủ để thực hiện nó trong thời gian thực hay không.

Không cần phải đề cập tại sao hoạt động trong thời gian thực lại quan trọng đối với robot. Câu hỏi của tôi là tuy nhiên, nó thực sự được sử dụng bao nhiêu trong robot?

Lấy câu hỏi này làm ví dụ. Chỉ có một câu trả lời đề cập đến bất kỳ nền tảng nào có khả năng thời gian thực và nó cũng nằm xa trên cùng. ROS rõ ràng, là một nền tảng rất phổ biến mà không phải là thời gian thực.

Tuy nhiên, trong thế giới thời gian thực, RTAI ¹ dường như là nền tảng sử dụng thời gian thực miễn phí duy nhất khả thi . Tuy nhiên, nó bị giới hạn ở Linux (không có vấn đề gì), được ghi chép lại và phát triển chậm.

Vì vậy, bao nhiêu hành vi thời gian thực được tìm kiếm giữa các nhà phát triển robot?Câu hỏi là, các nhà phát triển có xu hướng viết các ứng dụng thời gian thực bao nhiêu khi hành vi thời gian thực là thực sự cần thiết? Nếu không nhiều thì sao?

Ví dụ, hành vi phản xạ dựa trên dữ liệu xúc giác, không thể thông qua ROS vì nó sẽ mất tài sản thời gian thực. Nhưng mọi người có thực sự nghĩ ra một giải pháp thời gian thực hay sử dụng ROS nào không, bỏ qua tài sản thời gian thực?

¹ hoặc tương tự Xenomai

Hãy nhớ rằng có Thời gian thực và Thời gian thực .

Hard Real time rất khó đạt được nếu không có hỗ trợ phần cứng hoặc hỗ trợ phần mềm cấp thấp, nhưng bạn thường không cần mọi thứ để có khả năng Hard Real Time . Soft & Firm Đáp ứng thời gian thực dễ dàng hơn nhiều để đạt được và thường là quá đủ cho nhiều ứng dụng.

Ngoài ra, các phần khác nhau của một hệ thống có thể có các yêu cầu thời gian thực rất khác nhau . Nếu bạn đang chạy các vòng lặp phần mềm PID, họ thực sự cần phải có phản ứng thời gian thực cứng (bạn thực sự không muốn phải chọn giữa điều chỉnh mềm PID hoặc điều chỉnh chúng cứng và đôi khi chúng không ổn định). Một hệ thống tầm nhìn có thể có các yêu cầu đáp ứng thời gian thực vững chắc , hiệu suất sẽ giảm nếu bạn không thể xử lý hình ảnh kịp thời cho quyết định tiếp theo nhưng nó không ngăn hệ thống chạy, trong trường hợp này nếu bạn không thể xử lý kịp thời tốt hơn hết là vứt bỏ kết quả một phần và không mất thời gian bắt đầu phân tích trên khung tiếp theo. Cuối cùng là lập kế hoạch và phối hợp tổng thể của bạn (có lẽ là phức tạp nhấtmột phần của hệ thống robot của bạn) thường có thể duy trì vững chắc trong miền thời gian thực mềm .

Ngay cả trong lĩnh vực máy tính Windows, bạn có thể có được hiệu năng thời gian thực khó khăn , bạn chỉ cần phần mềm phù hợp với các móc nối đúng vào kernel. PLC mềm TwinCat của Beckhoff khá vui vẻ chạy PLC tốc độ quét cao bằng cách cắt một nửa chu kỳ máy của Pentium, đưa nửa còn lại cho Windows NT, và điều này đã hơn một thập kỷ trước. Ngay cả các hệ thống điều khiển hiện đại như một số tùy chọn trong phạm vi A3200 của Aerotech cũng hoạt động tốt trên PC chủ, với nhân cấp thấp mất nhiều thời gian CPU cần thiết cho các yêu cầu thời gian thực cứng và để lại các chu kỳ CPU còn lại cho Windows 7 để sử dụng!

Một hệ thống thời gian thực không thực sự cần thiết cho nhiều hệ thống điều khiển robot (hầu hết?). Miễn là bạn có một vòng điều khiển chạy đủ nhanh, với độ biến động đủ thấp và không bỏ lỡ quá nhiều chu kỳ, thì điều này là khá phù hợp cho điều khiển robot và điều khiển.

Để làm bằng chứng về điều này, hãy để tôi trình bày PR2 và Shadow Robot Hand:

Robot này có khoảng 20 độ tự do, tất cả đều được điều khiển thông qua vòng lặp chính của ROS. Hoặc làm thế nào về Shadow Robot Hand, cũng có 20 DOF, cộng với một loạt các cảm biến xúc giác và các cảm biến khác, và cũng được điều khiển thông qua vòng lặp chính của ROS.

Vòng lặp chính của ROS chịu một chút nhiễu, đôi khi tới 100us và thậm chí đôi khi bỏ lỡ các chu kỳ hoàn toàn. Nhưng nó không thành vấn đề nếu 99,9% chu kỳ được thực hiện thành công.

Việc sử dụng nhiều lõi trong các máy tính chủ có nghĩa là toàn bộ một lõi được dành riêng để chạy vòng lặp chính, và do đó nó rất hiếm khi bị trì hoãn bởi các tác vụ khác.

Lý do chính cho việc sử dụng một hệ điều hành thời gian thực cho hệ thống robot là vì sự an toàn. Nếu robot đang làm việc trong tình huống quan trọng về an toàn, thì bạn có trách nhiệm đảm bảo kiểm soát 100% thời gian hoạt động và một phần của việc này là đảm bảo tính chất thời gian thực của nó.

Cho dù bạn có sử dụng HĐH thời gian thực hay không, các servo của bạn sẽ làm điều gì đó an toàn trong trường hợp vòng điều khiển bị chết hoàn toàn. Hệ thống an toàn này cũng sẽ hữu ích trong trường hợp hiếm hoi hệ điều hành phi thời gian thực của bạn bỏ qua hơn một chu kỳ. Ví dụ, trên Bàn tay bóng tối, các động cơ bị dừng nếu vòng điều khiển bỏ lỡ hơn 20 chu kỳ (20ms). Tôi chưa bao giờ thấy điều này xảy ra mặc dù.

Thêm

Một cách khác để suy nghĩ về nó là: Hệ thống servo của bạn thực sự cần tốc độ cập nhật nào? Nếu đó là một cánh tay to lớn và không cần hiệu suất siêu cao, định vị tốc độ cao, thì 500Hz có thể là đủ. Đối với lái xe xung quanh, 200Hz có lẽ là đủ. Trong cả hai trường hợp này, nếu vòng lặp của bạn thực sự chạy ở 1000Hz, thì chu kỳ trễ hoặc mất tích thực sự không có vấn đề gì, miễn là thuật toán điều khiển của bạn tính đến thời gian trôi qua thực tế giữa các vòng.

Mục đích của phần mềm xác định xem nó có cần phải theo thời gian thực hay không.

Trong đó mục đích là lập kế hoạch đường đi hoặc nội địa hóa, thường thì tần số thấp là không đủ, ví dụ, 10Hz. Trong những trường hợp này, thiết lập trình phát / giai đoạn chạy trên Linux là ổn. Chúng ta có thể thấy rằng có một vài vấn đề nếu bước một lần dài hơn hoặc ngắn hơn một chút.

Hành vi thời gian thực nghiêm ngặt được yêu cầu nếu động lực học của robot nhanh. Ví dụ, di chuyển một cánh tay robot để theo dõi một vị trí, hoặc để xử lý / kẹp các vật thể và di chuyển chúng. Nếu một bước thời gian bị bỏ lỡ, vị trí có thể vượt quá mức không mong muốn và chúng tôi có thể muốn hành vi dễ dự đoán hơn. Trong trường hợp này, chúng tôi có thể có tần số lên tới 1kHz trở lên. Nếu một hệ điều hành được sử dụng, chúng tôi muốn có một hệ điều hành thời gian thực.

Hành vi thời gian thực có thể được thực hiện trong các ứng dụng nhúng, bằng cách sử dụng bộ định thời và ngắt (mã C được biên dịch trên vi điều khiển). Trong trường hợp này, chúng tôi phải đảm bảo rằng tải xử lý không quá cao để có thể duy trì tần số lấy mẫu thường xuyên.

Robot sử dụng máy tính / bộ vi xử lý (vì cần nhiều sức mạnh xử lý hơn), sẽ cần sử dụng hệ điều hành thời gian thực để đảm bảo tốc độ lấy mẫu cao.

Do đó, việc hành vi trong thời gian thực có bắt buộc hay không phụ thuộc vào việc nhà phát triển dự định sử dụng nó để làm gì.

Công ty chúng tôi xây dựng robot bằng FreeRTOS chạy trên vi điều khiển PIC. Đối với chúng tôi, lý do chính để sử dụng FreeRTOS là dễ dàng sắp xếp lại các ưu tiên cho các tác vụ, xử lý đồng thời nhiều đường truyền và giao tiếp dễ dàng giữa các trình xử lý ngắt và các tác vụ chính. Vi điều khiển rẻ hơn nhiều so với việc đưa một máy linux đầy đủ vào mỗi robot chúng tôi sản xuất.

Nếu bạn thực sự cần thời gian thực, thì bạn sử dụng hệ điều hành thời gian thực. Giám sát an toàn, thu thập dữ liệu và các vòng điều khiển tốc độ mẫu không đổi là các hệ thống con phổ biến sử dụng lập lịch thời gian thực.

Phần thời gian thực của lập trình thường càng nhỏ càng tốt, vì khó gỡ lỗi hơn và ít mã hơn để kiểm tra tính chính xác. Tài liệu về hệ điều hành thời gian thực thường khá tốt (bao gồm RTAI / Xenomai).

Tôi đã sử dụng QNX và RTAI-> Xenomai trong các dự án robot thực tế khác nhau . Tôi thích QNX nhưng Xenomai cũng hiệu quả.

Orocos là một khung phần mềm điều khiển robot thời gian thực trưởng thành. Tôi đã thấy nó được sử dụng để điều khiển thành công các trình điều khiển robot tốc độ cao với các yêu cầu cứng thời gian thực. Nó có nhiều thành phần cấp khung giống như ROS, truyền thông, cấu hình, tuần tự hóa và đóng gói dựa trên thành phần.

Bắt đầu suy nghĩ về robot của bạn về nhiều CPU và thay đổi câu hỏi thời gian thực. Nếu bạn có một thuật toán cần phản hồi đáng tin cậy tốc độ cao như bộ cân bằng hai bánh hoặc bộ ổn định bốn bánh hoặc xung servo, thời gian thực là vô cùng quan trọng, nhưng nhiệm vụ cũng rất hạn chế.

Bạn có thể giảm tải một vòng điều khiển như thế này cho CPU thời gian thực chuyên dụng như AVR 8 bit giá rẻ hoặc ARM 32 bit cấp thấp được tìm thấy trong lớp thiết bị Arduino. Không có gì ngăn cản bạn thêm hàng tá MCU nhỏ này chạy các vòng điều khiển chuyên dụng, việc liệt kê thiết bị USB thậm chí còn giúp việc này trở nên dễ dàng.

Giờ đây, khi bạn có các vòng điều khiển nhạy cảm thời gian được xử lý bởi CPU chuyên dụng, bạn có thể thư giãn nhu cầu thời gian thực của 'bộ não' của robot có thể chạy logic cao cấp hơn bằng cách sử dụng các thành phần như ROS trên Linux hoặc Kinect cho Windows.

Để đáp ứng với hệ thống thời gian thực "khi / trong trường hợp nào" được sử dụng:

Theo kinh nghiệm của tôi, điều khiển chuyển động là ứng dụng chính cho các hệ thống thời gian thực. Để điều khiển động cơ, tần số cao (100hz, 1000hz trở lên) và jitter thấp (biến thiên thời gian) rất quan trọng. An toàn là một điểm lớn ở đây. Xem xét một robot giữa con người: Ví dụ: bạn muốn / cần đảm bảo rằng robot (cánh tay) dừng lại trong một khung thời gian / khoảng cách cụ thể.

Đối với các nhiệm vụ khác như lập kế hoạch đường đi, xử lý tầm nhìn và hệ thống thời gian thực lý luận không quan trọng và thường bị tránh do chi phí phát triển và chi phí phần cứng.

Ngày nay, các robot lớn như PR2 kết hợp cả hai thế giới. Trong bối cảnh thời gian thực của hệ điều hành RT (ví dụ Linux + Xenomai) đang diễn ra và trong phần không thời gian thực (đất người dùng), xử lý và lập kế hoạch tầm nhìn được nhúng trong các hệ thống như ROS. Cả hai có thể chạy trên cùng một máy tính.

Tôi rất vui khi chỉnh sửa câu trả lời này, một khi câu hỏi đã được làm rõ. :-)

Có, giả sử tài nguyên phần cứng có thể đáp ứng các yêu cầu về thời gian (đủ công suất xử lý, độ trễ đủ thấp), khi bộ lập lịch không thể sắp xếp các quy trình và luồng một cách thích hợp, sau đó người ta sử dụng bộ lập lịch thời gian thực, thường được gắn vào hạt nhân được tối ưu hóa đặc biệt cho những thách thức này. Trình điều khiển phần cứng cũng có thể được tối ưu hóa cho các điều kiện thời gian thực.

Có, nếu phần mềm không thể được đảm bảo để thực hiện công việc trong các ràng buộc về thời gian cần thiết, thì người ta sẽ sử dụng các phương pháp tiếp cận thời gian thực.

Một giải pháp tốt là làm cả hai. Một thiết kế tôi sử dụng các chức năng thời gian thực "cứng" trên một bộ điều khiển vi mô nhỏ, các vòng điều khiển servo chặt chẽ và như vậy. Sau đó, có một CPU khác lớn hơn, chạy Linux và ROS. Tôi để ROS xử lý các nhiệm vụ cấp cao hơn và uP xử lý những việc như điều khiển động cơ bước hoặc chạy vòng lặp PID.

Như những người khác đã nói ở trên, bạn CÓ THỂ cho phép một hệ điều hành không thời gian thực chạy các vòng điều khiển 1KHz nhưng để nó hoạt động, bạn cần một máy tính có kích thước quá lớn, dành phần lớn thời gian trong một vòng lặp nhàn rỗi. Nếu bạn chạy máy tính Linux / ROS với mức sử dụng CPU gần 100% thì hiệu suất thời gian thực rất kém. Sử dụng thiết kế hai lớp cho phép bạn luôn có hiệu suất RT rất tốt và cũng sử dụng máy tính nhỏ hơn, ít tốn điện hơn (có thể là nhiệm vụ cấp cao hơn Pi2.) Hiện tại uP của tôi không chạy bất kỳ HĐH nào nhưng tôi đang chuyển sang FreeRTOS