Người đã viết phần mềm nhiều năm bước vào robotics thường đi rất nhanh ở tháng đầu rồi khựng lại. Không phải vì thiếu kỹ năng lập trình, mà vì bốn giả định đúng trong thế giới phần mềm lại sai trong thế giới vật lý.
Giả định thứ nhất: dữ liệu là chính xác
Trong phần mềm, khi một hàm trả về số ba, nó là ba. Trong robotics, cảm biến trả về ba nghĩa là giá trị thật nằm đâu đó quanh ba, với một phân bố sai số phụ thuộc nhiệt độ, tuổi thọ và điều kiện môi trường.
Hệ quả về cách viết mã rất cụ thể. So sánh bằng không dùng được, phải so sánh với ngưỡng. Một lần đọc không đủ, phải lọc theo thời gian. Và mọi ngưỡng đều cần vùng trễ, nếu không tín hiệu sẽ nhảy qua lại liên tục quanh ngưỡng.
Đây thường là bài học đầu tiên và đau nhất: chương trình đúng về mặt logic nhưng máy vẫn chạy sai, vì logic đó giả định dữ liệu sạch.
Giả định thứ hai: thao tác là tức thời và luôn thành công
Gọi một hàm trong phần mềm thì nó chạy xong rồi trả về. Ra lệnh cho robot di chuyển thì lệnh chỉ mới bắt đầu, và nó có thể không hoàn thành.
Vì vậy mọi thao tác vật lý phải được viết như một quá trình có trạng thái: đã gửi lệnh, đang thực hiện, đã tới đích, thất bại vì lý do gì. Kèm theo là thời gian chờ tối đa và hành động khi hết thời gian.
Người quen viết mã đồng bộ thường bỏ qua phần này, và chương trình chạy tốt cho tới lần đầu tiên có gì đó kẹt.
Giả định thứ ba: có thể thử lại tuỳ ý
Trong phần mềm, chạy lại một hàm thường vô hại. Trong robotics, mỗi lần chạy lại là một chuyển động thật, có thể làm hỏng phôi, va vào đồ gá hoặc gây nguy hiểm cho người đứng cạnh.
Điều này thay đổi hẳn nhịp làm việc. Bạn phải mô phỏng trước, chạy ở tốc độ chậm trước, kiểm tra từng đoạn trước khi ghép lại. Chu kỳ thử và sửa chậm hơn nhiều so với phần mềm thuần tuý.
Nó cũng thay đổi cách viết mã: trạng thái khởi động phải luôn xác định, và chương trình phải biết đưa máy về vị trí an toàn trước khi làm bất cứ việc gì khác.
Giả định thứ tư: gỡ lỗi bằng cách đọc log
Khi robot làm sai, log thường không đủ. Vấn đề có thể nằm ở một con ốc lỏng, một sợi cáp bị kẹp, ánh sáng đổi khi trời tối, hoặc phôi lô mới có dung sai khác lô cũ.
Kỹ năng cần bổ sung là chẩn đoán hệ thống vật lý: thu hẹp phạm vi bằng cách thay đổi một biến mỗi lần, chạy chậm để quan sát, dùng tay cảm nhận độ rơ, so sánh với một máy khác đang chạy tốt.
Một câu hỏi rất hiệu quả trong robotics mà ít dùng trong phần mềm: lần cuối nó chạy đúng là khi nào, và giữa hai thời điểm đó có gì thay đổi — kể cả những thay đổi tưởng không liên quan như thay ca, thay lô vật tư hay chuyển vị trí máy.
Những gì mang sang được nguyên vẹn
Không phải mọi thứ đều phải học lại. Bốn thói quen sau là lợi thế lớn của người từ phần mềm sang.
- Quản lý phiên bản. Nhiều xưởng vẫn lưu chương trình robot theo kiểu chép tay và đặt tên có ngày tháng. Đưa kỷ luật phiên bản vào là cải thiện thấy được ngay.
- Tách lớp và tái sử dụng. Chương trình robot dễ trở thành một khối dài không sửa được; tư duy module hoá giúp tránh điều đó.
- Ghi log có cấu trúc. Ghi lại thời gian, trạng thái và giá trị cảm biến ở các điểm quan trọng giúp việc chẩn đoán nhanh hơn nhiều.
- Tự động hoá kiểm thử. Chạy một chuỗi kiểm tra chuẩn sau mỗi lần sửa là thói quen rất ít gặp trong xưởng nhưng rất có giá trị.
Nói ngắn gọn: phần cần bổ sung là hiểu biết về thế giới vật lý và sai số; phần mang sang được là kỷ luật kỹ thuật phần mềm, thứ mà nhiều nhóm tự động hoá đang thiếu.
Câu hỏi thường gặp
Lập trình viên web chuyển sang robotics có khó hơn lập trình nhúng không?
Có một khoảng cách lớn hơn, chủ yếu vì thói quen làm việc với hệ thống có tài nguyên dồi dào và không có ràng buộc thời gian chặt. Nhưng nền tảng về cấu trúc dữ liệu, thiết kế phần mềm và gỡ lỗi vẫn chuyển sang được nguyên vẹn.
Có cần học điện tử để làm phần mềm robot không?
Cần ở mức đọc được sơ đồ, hiểu tín hiệu vào ra và biết khi nào vấn đề nằm ở phần cứng. Không cần thiết kế mạch, nhưng nếu không phân biệt được lỗi phần mềm với lỗi dây nối, bạn sẽ mất rất nhiều thời gian tìm sai chỗ.
Ràng buộc thời gian thực nghĩa là gì trong thực tế?
Nghĩa là một số phần của hệ thống phải hoàn thành trong khoảng thời gian xác định, không được trễ. Vòng điều khiển khớp là ví dụ điển hình. Phần lớn lớp trên như lập kế hoạch hay giao diện không cần ràng buộc này, nên không phải toàn bộ mã đều phải viết theo kiểu thời gian thực.
Mất bao lâu để chuyển đổi được?
Với người đã vững lập trình, khoảng sáu tháng làm việc thật là đủ để đóng góp được vào dự án, và một tới hai năm để tự chủ. Yếu tố quyết định là có được tiếp xúc với máy thật hay không, vì phần khó nhất chỉ xuất hiện khi rời khỏi mô phỏng.
Đọc thêm trong Thuật ngữ robotics và Nhập môn robotics.
