Trong nhiều lĩnh vực, mô hình chậm chỉ gây khó chịu. Trong robot, nó là ràng buộc cứng: quá chậm thì không chỉ phản ứng kém mà cả hệ thống có thể dao động và mất ổn định.
Vì sao độ trễ nguy hiểm với hệ có phản hồi
Vòng điều khiển hoạt động bằng cách đo sai lệch rồi sửa. Nếu phép đo phản ánh trạng thái của một khoảnh khắc đã qua, lệnh sửa sẽ đến muộn.
Với độ trễ đủ lớn, lệnh sửa đến khi hệ đã vượt qua điểm cân bằng, và thay vì kéo về nó lại đẩy đi xa hơn. Kết quả là dao động tự duy trì.
Đây là lý do không thể đơn giản đưa một mô hình lớn vào thay cho bộ điều khiển. Không phải vì mô hình kém, mà vì nhịp của nó không phù hợp với động lực học của cơ khí.
Phân tầng: cách giải quyết tiêu chuẩn
Kiến trúc phổ biến chia thành ba tầng với ba nhịp khác nhau.
- Tầng nhiệm vụ: mô hình lớn, chạy chậm, quyết định làm gì tiếp theo. Nhịp tính bằng giây.
- Tầng thao tác: sinh chuỗi chuyển động cho vài giây tới. Nhịp tính bằng phần mười giây.
- Tầng khớp: bám theo quỹ đạo, phản ứng với lực và sai lệch. Nhịp tính bằng phần nghìn giây.
Mỗi tầng chỉ cần nhanh tương ứng với thứ nó xử lý. Sự kiện cần phản ứng gấp — chạm phải vật cứng, vượt giới hạn lực — được xử lý ở tầng dưới cùng, nơi đủ nhanh.
Cách phân chia này cũng chính là cách bảo đảm an toàn: giới hạn cứng nằm ở tầng nhanh nhất và không phụ thuộc vào mô hình.
Chạy mô hình ở đâu
Ba phương án, mỗi phương án một kiểu đánh đổi.
Trên máy gắn ngay tại robot. Độ trễ thấp và ổn định, không phụ thuộc mạng. Bị giới hạn về kích thước mô hình do điện năng và tản nhiệt.
Trên máy chủ trong cùng nhà xưởng. Chạy được mô hình lớn hơn, nhiều robot dùng chung. Thêm độ trễ mạng, nhưng trong mạng nội bộ thì nhỏ và khá ổn định.
Trên hạ tầng từ xa. Không giới hạn về tài nguyên nhưng độ trễ lớn và không ổn định. Đây là điểm quan trọng: độ trễ dao động còn khó xử lý hơn độ trễ lớn nhưng cố định.
Với phần điều khiển, phương án từ xa hầu như không dùng được. Nó chỉ hợp cho các tác vụ chậm như lập kế hoạch nhiệm vụ.
Các cách giảm độ trễ khi triển khai
- Giảm độ chính xác số học của mô hình, đổi một phần chất lượng lấy tốc độ. Thường là bước tối ưu đầu tiên và cho hiệu quả rõ.
- Chưng cất mô hình lớn thành mô hình nhỏ hơn chuyên cho nhiệm vụ đang dùng.
- Giảm độ phân giải ảnh đầu vào tới mức vẫn đủ nhận biết. Chi phí xử lý ảnh tăng nhanh theo độ phân giải.
- Chồng lấn tính toán với chuyển động: tính chuỗi tiếp theo trong lúc robot đang thực hiện chuỗi hiện tại.
- Bỏ bớt tần suất gọi mô hình ở các giai đoạn không cần quyết định, ví dụ khi đang di chuyển trong không gian trống.
Điểm cuối thường bị bỏ qua nhưng cho hiệu quả lớn: không phải mọi khoảnh khắc đều cần đến mô hình lớn.
Đo cho đúng trước khi tối ưu
Con số cần quan tâm không phải thời gian suy luận trung bình mà là độ trễ toàn chuỗi ở phần trăm xấu nhất.
Chuỗi này gồm: thời gian chụp ảnh, truyền ảnh, tiền xử lý, suy luận, hậu xử lý, truyền lệnh xuống bộ điều khiển. Nhiều nhóm chỉ đo phần suy luận và ngạc nhiên khi hệ thống thật chậm hơn nhiều.
Cũng cần đo độ dao động của độ trễ. Một hệ có độ trễ ổn định dễ bù trừ hơn nhiều so với hệ nhanh hơn nhưng thỉnh thoảng bị chậm đột biến.
Cách đo đơn giản mà hiệu quả: đóng dấu thời gian tại từng chặng và ghi lại trong nhật ký, rồi xem phân bố thay vì chỉ xem giá trị trung bình.
Câu hỏi thường gặp
Mô hình cần chạy bao nhiêu lần mỗi giây là đủ?
Tuỳ tầng. Tầng lập kế hoạch nhiệm vụ có thể chạy vài giây một lần. Tầng sinh chuỗi chuyển động cần nhanh hơn nhiều để phản ứng kịp với thay đổi. Tầng bám quỹ đạo và xử lý lực phải nhanh hơn nữa và thường không do mô hình đảm nhận.
Độ trễ dao động vì sao lại tệ hơn độ trễ lớn?
Vì độ trễ cố định có thể bù trừ bằng cách dự đoán trước, còn độ trễ thay đổi thất thường thì không. Hệ điều khiển được chỉnh cho một mức trễ sẽ hành xử khác khi độ trễ đột ngột tăng, và đó là lúc dao động xuất hiện.
Giảm độ chính xác số học có làm mô hình kém đi nhiều không?
Thường mất rất ít chất lượng so với mức tăng tốc độ, nhưng cần kiểm chứng trên chính nhiệm vụ của bạn chứ không tin vào con số chung. Nên so sánh tỉ lệ thành công trước và sau khi tối ưu, trên cùng tập kiểm thử.
Có nên dùng máy chủ dùng chung cho nhiều robot không?
Hợp lý khi các robot không cùng lúc yêu cầu suy luận ở tần số cao, và khi mạng nội bộ đủ ổn định. Cần tính tới trường hợp xấu nhất khi nhiều robot cùng gọi, vì lúc đó độ trễ tăng đúng vào thời điểm hệ thống bận nhất.
Đọc thêm trong Huấn luyện trong mô phỏng và Nền tảng & bộ công cụ.