Hệ thống điều khiển phương tiện có người lái hoặc một phần có người lái
Xe hơi, tàu ngầm, phương tiện vũ trụ,…
Xây dựng phần mềm để điều khiển robot
Cảm biến bên ngoài và thiết bị truyền động
Thời gian thực
Đầu vào do cảm biến cung cấp
Điều khiển chuyển động
Lập kế hoạch con đường tương lai
Robot di động tiếp tục
Các yếu tố phức tạp
Các chướng ngại vật có thể chặn đường đi
Đầu vào cảm biến không hoàn hảo
Robot có thể hết điện
Độ chính xác khi di chuyển
Thao tác với vật liệu nguy hiểm
Các sự kiện không lường trước có thể dẫn đến cần phản ứng nhanh
Robot di động tiếp tục
Xem xét bốn (4) thiết kế kiến trúc
Vòng điều khiển
Thiết kế phân lớp
Hệ thống sự kiện
Bảng đen
Robot di động tiếp tục
Cân nhắc thiết kế
Yêu cầu 1: hành vi có chủ đích và phản ứng
Phối hợp các hành động của robot với phản ứng của môi trường
Yêu cầu 2: không chắc chắn
Robot cần phải hành động ngay cả khi nó có thông tin không đầy đủ và không đáng tin cậy
Yêu cầu 3: tính đến nguy hiểm
Khả năng chịu lỗi, an toàn, hiệu suất
Yêu cầu 4: tính linh hoạt
Phát triển ứng dụng yêu cầu thử nghiệm và cấu hình lại
Robot di động tiếp tục
Yêu cầu các loại khác nhau
Ứng dụng của chúng phụ thuộc vào độ phức tạp của công việc và khả năng dự đoán của môi trường
Ví dụ: robot đang hoạt động ở hành tinh khác => khả năng chịu lỗi tối quan trọng
Ít quan trọng hơn (FT) khi robot ở cơ sở bảo trì gần đó
Bốn yêu cầu hướng dẫn đánh giá bốn phương án kiến trúc
Giải pháp 1: vòng điều khiển
Một robot di động sử dụng mô hình vòng kín
Bộ điều khiển khởi tạo các hành động của robot và theo dõi hậu quả của chúng, điều chỉnh kế hoạch
Giải pháp 1 tiếp
Bốn yêu cầu?
Yêu cầu 1: hành vi có chủ ý và phản ứng
+ tính đơn giản của mô hình
– sự đơn giản của một vấn đề trong môi trường không thể đoán trước
Giả định ngầm: những thay đổi liên tục trong môi trường đòi hỏi phản ứng liên tục
Robot phải đối mặt với các sự kiện rời rạc
Chuyển đổi giữa các chế độ hành vi – làm thế nào để thay đổi giữa các chế độ?
Làm thế nào để phân tách phần mềm thành các thành phần hợp tác?
Giải pháp 1 tiếp
Bốn yêu cầu?
Yêu cầu 2: sự không chắc chắn
– Quy trình thử-và-sai
Yêu cầu 3: tính đến những nguy hiểm
+ sự đơn giản giúp dễ dàng sao chép
Yêu cầu 4: tính linh hoạt
+ các thành phần chính (bộ giám sát, cảm biến, động cơ) tách biệt, độc lập, có thể thay thế
Giải pháp 1 tiếp tục
Tóm tắt:
Mô hình thích hợp cho người máy đơn giản
Chỉ có thể xử lý một số lượng nhỏ các sự kiện bên ngoài
Không thực sự dành cho việc phân rã các nhiệm vụ phức tạp
Giải pháp 2: Kiến trúc phân lớp
Tám cấp độ:
Cấp độ 1: Quy trình điều khiển robot (động cơ, khớp,…)
Cấp độ 2 & 3: đầu vào từ môi trường
Giải thích và tích hợp cảm biến (một so với một số cảm biến)
Cấp độ 4: mô hình của robot trong thế giới thực
Cấp độ 5 : điều hướng của rô bốt
Cấp độ 6 & 7: lập lịch và lập kế hoạch cho các hành động của rô bốt
Xử lý các vấn đề và lập kế hoạch lại: ở cấp độ 7
Cấp độ 8: giao diện người dùng và chức năng giám sát
Giải pháp 2 tiếp
Bốn yêu cầu?
Yêu cầu 1: hành vi có chủ ý và phản ứng
+ Nhiều thành phần hơn để ủy quyền nhiệm vụ cho
+ Chỉ ra các mối quan tâm cần được giải quyết
Tích hợp cảm biến
+ Xác định mức độ trừu tượng để hướng dẫn thiết kế
Điều khiển rô bốt so với điều hướng rô bốt
– Không phù hợp với dữ liệu thực tế và các mẫu luồng điều khiển
Không tuân theo kiến trúc lớp: để phản ứng nhanh, dữ liệu từ cảm biến trực tiếp đến xử lý sự cố ở mức 7, tương tự phản ứng lại
– Không tách biệt phân cấp dữ liệu (1-4) khỏi phân cấp điều khiển (1,5-8)
Giải pháp 2 tiếp
Bốn yêu cầu?
Yêu cầu 2: sự không chắc chắn
+ các lớp trừu tượng quản lý điều này
Yêu cầu 3: tính đến nguy hiểm
+ được quản lý bởi cơ chế trừu tượng: dữ liệu và lệnh được phân tích từ các góc độ khác nhau
Khả năng chịu lỗi và an toàn bị động ok; an toàn hoạt động không ổn
Yêu cầu 4: tính linh hoạt
– sự phụ thuộc giữa các lớp là một trở ngại
– các mối quan hệ phức tạp giữa các lớp có thể trở nên khó quản lý
Giải pháp 2 tiếp tục
Tóm tắt:
Cung cấp khuôn khổ để tổ chức các thành phần
Chính xác về vai trò của các lớp
Các vấn đề khi thêm chi tiết ở cấp độ hiện thực
Mẫu giao tiếp trong rô bốt sẽ không tuân theo sơ đồ của kiến trúc
Giải pháp 3: hệ thống sự kiện
Kiến trúc điều khiển tác vụ
Dựa trên phân cấp nhiệm vụ
Cây tác vụ
Tác vụ mẹ khởi tạo tác vụ con
Nhà thiết kế phần mềm có thể xác định phụ thuộc thời gian giữa các tác vụ (ví dụ: A phải hoàn thành trước B)
Cấu hình lại động của cây nhiệm vụ tại thời gian chạy
Sử dụng lệnh gọi ngầm để phối hợp tương tác giữa các tác vụ
Các tác vụ giao tiếp bằng các thông báo đa hướng thông qua một máy chủ tin nhắn (chuyển hướng các tin nhắn đến các tác vụ đã đăng ký để xử lý chúng)
Giải pháp 3 tiếp tục
Lệnh gọi ngầm của TCA hỗ trợ:
Ngoại lệ: xử lý ngoại lệ ghi đè các tác vụ
Thay đổi chế độ xử lý
Có thể hủy bỏ hoặc thử lại các tác vụ
Phù hợp hơn để quản lý các sự kiện tự phát (ví dụ như lỗi)
Nghe lén: chặn tin nhắn bằng các tác vụ chồng lên trên
Kiểm tra độ an toàn của các lệnh gửi đi
Điều khiển: đọc thông tin và thực hiện các hành động
Các vấn đề về khả năng chịu lỗi khi sử dụng các tác nhân để giám sát hệ thống
Giải pháp 3 tiếp
Bốn yêu cầu?
Yêu cầu 1: hành vi có chủ ý và phản ứng
+ Tách hành động và phản ứng qua cây nhiệm vụ và ngoại lệ, nghe lén và giám sát
+ đồng thời rõ ràng: nhiều hành động có thể tiến hành cùng một lúc và độc lập
– mặc dù trên thực tế bị giới hạn bởi máy chủ tin nhắn trung tâm
⇒ – dựa vào một điểm kiểm soát trung tâm
Giải pháp 3 tiếp
Bốn yêu cầu?
Yêu cầu 2: không chắc chắn
– không rõ ràng trong mô hình
Có thể thông qua cây nhiệm vụ và ngoại lệ
Yêu cầu 3: nguy hiểm
+ ngoại lệ, nghe lén, giám sát
+ khả năng chịu lỗi do dự phòng
Nhiều trình xử lý được đăng ký cho cùng một tín hiệu, cái này bị lỗi thì cái khác tiếp quản
Nhiều lần xuất hiện cùng một yêu cầu: đồng thời
Yêu cầu 4: tính linh hoạt
+ lệnh gọi ngầm cho phép phát triển và thay thế gia tăng các thành phần
Thường đủ để đăng ký trình xử lý mới trong máy chủ trung tâm
Giải pháp 3 tiếp tục
Tóm tắt:
TCA cung cấp một bộ tính năng toàn diện để điều phối các nhiệm vụ
Thích hợp cho các dự án rô bốt phức tạp
Giải pháp 4: bảng đen
Dựa trên các thành phần sau:
Thuyền trưởng (Captain): người giám sát tổng thể
Người điều hướng bản đồ (Map navigator): người lập kế hoạch đường đi cấp cao
Người canh gác (Lookout): giám sát môi trường
Phi công (Pilot): người lập kế hoạch đường đi cấp thấp và bộ điều khiển chuyển động
Hệ thống con nhận thức (Perception subsystem): đầu vào thô từ cảm biến và sự tích hợp của nó với một cách diễn giải
Giải pháp 4 tiếp
Bốn yêu cầu?
Yêu cầu 1: hành vi có chủ ý và phản ứng
+ các thành phần tương tác thông qua kho lưu trữ được chia sẻ
– luồng điều khiển phải được cưỡng chế để phù hợp với cơ chế cơ sở dữ liệu
Các thành phần không giao tiếp trực tiếp
Yêu cầu 2: sự không chắc chắn
+ bảng đen cũng là phương tiện để giải quyết xung đột và không chắc chắn
Tất cả dữ liệu có sẵn trong cơ sở dữ liệu
Giải pháp 4 tiếp
Bốn yêu cầu?
Yêu cầu 3: tính đến các mối nguy hiểm
+ giao tiếp qua dịch vụ trung tâm, cơ sở dữ liệu
Xử lý ngoại lệ, nghe lén, giám sát có thể được thực hiện bằng cách thêm các mô-đun theo dõi cơ sở dữ liệu để tìm các dấu hiệu nhất định của các tình huống có vấn đề
Yêu cầu 4: tính linh hoạt
+ Hỗ trợ đồng thời
+ Tách người gửi khỏi người nhận
Tạo điều kiện bảo trì
Giải pháp 4 tiếp tục
Tóm tắt:
Kiến trúc có khả năng mô hình hóa sự hợp tác của các nhiệm vụ
Phối hợp
Giải quyết sự không chắc chắn
Ít mạnh hơn TCA một chút
Không phải là khả năng duy nhất cho người máy…
Ngoài ra tồn tại kiến trúc lai
Comparison
Control loop
Layers
Impl. invocation
Blackboard
Task coordination
+ –
–
++
+
Dealing with uncertainty
–
+ –
+ –
+
Fault tolerance
+ –
+ –
++
+
Safety
+ –
+ –
++
+
Performance
+ –
+ –
++
+
Flexibility
+ –
–
+
+
Điểm quan trọng của ngày hôm nay
Cần có một bộ sưu tập các kiểu kiến trúc cơ bản
Các nghiên cứu điển hình nhỏ hữu ích cho mục đích minh họa
Các ý tưởng tương tự (khá cơ bản) sẽ quay trở lại trong lĩnh vực của chúng ta
