Chạy thử firmware robot khi chưa có phần cứng ra sao?

• Thử logic trên máy tính
• Vi điều khiển giả lập
• Bo thật với đầu vào mô phỏng

Bạn sẽ học được gì

• Gọi tên ba cách chạy firmware khi chưa có robot hoàn chỉnh và nói mỗi cách cho thấy được gì.
• Tổ chức firmware để thử được các quyết định bằng cảm biến giả, đồng hồ giả và một lần mất liên kết được chèn vào.
• Viết kịch bản như mất nhịp tim, đặt các điều kiện kiểm tra và chạy nó sau mỗi thay đổi.

Cần biết trước

Nên đọc bài về các tầng mô phỏng của robot lau sàn và bài về bo ESP32 chạy chương trình ra sao. Hành vi được đem ra thử có trong bài robot mất kết nối thì tự về trạm. Các thuật ngữ khác được giải thích ngay lần đầu xuất hiện.

Có những mức thử firmware nào khi chưa có robot?

Có ba mức: thử trên máy chủ, giả lập vi điều khiển, và bo thật với đầu vào mô phỏng. Mức đầu rẻ nhất, mức cuối gần robot nhất.

Kiểm thử đơn vị (unit test) kiểm tra riêng một phần của mã. Tài liệu PlatformIO nói phần kiểm thử đơn vị cho phép tách từng phần của firmware ra và kiểm tra từng phần hoạt động đúng. Thử trên máy chủ không cần robot: chạy trên máy chủ không cần phần cứng riêng nào ngoài chính máy đó.

Bộ giả lập (emulator) chạy chính firmware đã biên dịch. Bản QEMU của Espressif mô phỏng CPU, bộ nhớ và một số ngoại vi của ESP32, tức là cách thử ứng dụng mà không cần nạp vào phần cứng thật. Phần cứng trong vòng lặp (hardware-in-the-loop, HIL) nghĩa là bo thật chạy firmware thật trong khi giàn thử cấp giá trị cảm biến và sự kiện liên kết mô phỏng.

• Thử trên máy chủ
• Vi điều khiển giả lập
• Phần cứng trong vòng lặp
• Cột trái, từ trên xuống: logic quyết định, thời gian, ngoại vi, vô tuyến
• Vòng tô đầy: thể hiện được
• Vòng rỗng: không thể hiện được
• Vòng nửa tô: chỉ một phần

Làm thế nào để firmware thử được?

Giữ phần quyết định trong mã không đụng tới chip, và đi tới phần cứng qua một lớp mỏng mà bài thử thay được. ESP-IDF cũng theo ý này: phần kiểm thử trên máy Linux của nó là kiểm thử đơn vị trong đó một phần phần cứng được thay bằng đối tượng giả. Đối tượng giả (mock) là vật thay thế trả về những giá trị đã được viết sẵn.

Với robot lau sàn, lớp logic giữ máy trạng thái: bình thường, nghi mất liên kết, an toàn, về trạm. Lớp phần cứng giữ chân bơm, trình điều khiển bánh xe, đồng hồ và vô tuyến. Bốn thứ giả là đủ để bắt đầu:

• Cảm biến giả trả về giá trị do bài thử chọn, ví dụ kẹt bánh hoặc pin thấp.
• Đồng hồ giả chạy tới theo lệnh, nên thời hạn dài không tốn thời gian thật.
• Liên kết giả gửi nhịp tim cho tới khi bài thử cắt.
• Đầu ra giả ghi lại mọi lệnh, để bài thử hỏi được bơm đã tắt chưa.

Đây là một đoạn minh họa cho quyết định đó, viết bằng mã giả, không gắn với thư viện nào:

on_tick(now):
  if heartbeat_expired(now) and state == MOPPING:
      pump_off()
      wheels_stop()
      state = SAFE
  if state == SAFE and local_return_is_valid():
      state = HEADING_HOME

Tài liệu ESP-IDF thêm hai lưu ý. Chạy ứng dụng trên máy chủ vẫn là tính năng còn thử nghiệm, và kiểm thử trên máy Linux còn đang phát triển, chỉ một phần nhỏ thành phần hỗ trợ. Giữ mã logic của riêng bạn không gọi chip thì khỏi phụ thuộc vào phần hỗ trợ đó.

• Logic quyết định (máy trạng thái)
• Lớp giao diện mỏng
• Đồ giả: cảm biến, đồng hồ, liên kết
• Phần cứng thật: chip, bánh, bơm

Nên viết kịch bản và điều kiện kiểm tra nào?

Viết kịch bản cho những tình huống rủi ro hoặc hiếm trên robot thật: mất nhịp tim, kẹt, pin thấp và trạm bận. Điều kiện kiểm tra (assertion) là một câu bài thử xác nhận, ví dụ "bơm và bánh đã nhận lệnh dừng trong thời hạn, trước khi được phép di chuyển về trạm". Thứ tự gọi hàm không được làm chậm việc dừng bánh.

Đi hàng đầu qua hai mức. Ở bài thử trên máy chủ, bài thử đặt đồng hồ giả, gửi nhịp tim, cắt nhịp, đẩy đồng hồ qua thời hạn rồi đọc các lệnh đã ghi. Bài thử chỉ đạt khi cả hai lệnh dừng được phát trong thời hạn; đầu vào mất định vị phải giữ trạng thái an toàn. Ghi lệnh đầu ra chưa chứng minh bơm hay bánh thật đã dừng. Lần chạy chỉ mất một phần nhỏ của giây.

Ở lần chạy giả lập, chính ảnh firmware đó khởi động trong bộ giả lập. Lệnh idf.py qemu monitor của Espressif dựng ứng dụng, khởi động QEMU và nối bộ giám sát với cổng UART giả lập, nên nhật ký trên console cho thấy trạng thái đổi. Wokwi có một mạng Wi-Fi mô phỏng với truy cập Internet đầy đủ cùng một điểm truy cập ảo cho liên kết, và có thể kết nối tới máy chủ MQTT để gửi dữ liệu cảm biến. Cắt kết nối đó trong kịch bản đóng vai mất nhịp tim.

• Các nhịp tim đều đặn
• Khoảng im lặng đến hết thời hạn
• Bơm tắt
• Bánh xe dừng
• Về trạm khi đủ điều kiện cục bộ
• Điều kiện kiểm tra đạt

Các bài thử chạy sau mỗi thay đổi bằng cách nào?

Chạy bài thử trên máy chủ sau mỗi thay đổi, lần chạy giả lập sau mỗi lần gộp mã và phần cứng trong vòng lặp trước mỗi bản phát hành. Renode được thiết kế để chạy nền trên máy chủ CI, và nó tích hợp với bộ kiểm thử Robot Framework. Tích hợp liên tục (continuous integration, CI) nghĩa là một máy chủ tự dựng mã và chạy các bài thử sau mỗi thay đổi.

Sổ tay của NASA xếp việc này vào phân tích: phân tích gồm cả việc dùng mô hình và mô phỏng như công cụ phân tích. Một lần mô phỏng đạt là dự đoán, không thay được robot thật.

Có những thứ vẫn vô hình ở mọi mức trên bo thật. Tài liệu ESP-IDF nói thẳng: giả lập môi trường và dùng đối tượng giả không phản ánh đầy đủ thiết bị thật, nên vẫn phải thử trên thiết bị. Theo lập luận thiết kế, ba giới hạn đáng kể với robot này là thời gian thực của vòng điều khiển, hành vi của ngoại vi thật như trình điều khiển động cơ và cảm biến, và vô tuyến thật trong một tòa nhà thật. Liên kết Wi-Fi giả lập không có tường và không có nhiễu.

• Thay đổi mã
• Máy chủ dựng và chạy bài thử
• Kết quả từng bài thử
• Báo kết quả cho người viết

Ví dụ trong đời sống

Đây là kịch bản minh họa, không phải kết quả đo. Một người làm có bo điều khiển nhưng chưa có robot. Họ viết quy tắc nhịp tim thành một hàm chỉ phụ thuộc đồng hồ và lần nhịp tim cuối, rồi thêm bốn thứ giả. Bài thử mất nhịp tim hỏng vì bơm chưa nhận lệnh dừng trong thời hạn. Họ sửa nhánh dừng để phát đủ hai lệnh và giữ trạng thái an toàn khi mất định vị; bài thử đạt, và máy chủ CI chạy nó sau mỗi thay đổi từ đó.

Sau đó họ khởi động chính firmware ấy trong bộ giả lập và cắt liên kết ảo; nhật ký cho thấy trạng thái đổi. Chỉ khi bo thật đầu tiên về tay, họ mới thấy thời hạn quá ngắn so với lúc Wi-Fi chuyển điểm truy cập. Kịch bản mô phỏng trước đó chưa đưa độ trễ chuyển điểm truy cập vào; họ thêm kịch bản này và điều chỉnh thời hạn theo phép đo.

Hiểu lầm thường gặp

Bài thử trên máy chủ đạt nghĩa là robot sẽ cư xử đúng. Bài thử trên máy chủ chứng minh logic, chưa chứng minh thời gian, ngoại vi hay vô tuyến.

Bộ giả lập giống hệt chip thật. Bản QEMU này mô phỏng một số ngoại vi, nên hãy kiểm tra các ngoại vi robot dùng có nằm trong đó không.

Muốn thử phải có robot hoàn chỉnh. Phần lớn logic an toàn, như về trạm khi mất liên kết, thử được trước khi có bánh xe nào quay.

Câu hỏi thường gặp

Có thử firmware ESP32 mà không cần bo không?

Một phần thì có. Bạn thử logic trên máy tính và chạy firmware trong bộ giả lập như bản QEMU của Espressif hoặc Wokwi. Vẫn cần bo thật cho thời gian, ngoại vi thật và vô tuyến.

Đối tượng giả khác bộ giả lập thế nào?

Đối tượng giả thay một phần của mã bằng vật thay thế có kịch bản cho bài thử. Bộ giả lập bắt chước cả con chip để chạy ảnh firmware cho chip và các ngoại vi mà nó hỗ trợ; không bảo đảm mọi bo hoặc ngoại vi đều chạy nguyên trạng.

Có cần máy chủ CI mới bắt đầu được không?

Không cần. Cứ chạy bài thử trên máy chủ bằng tay trước. Khi chúng ổn định thì chuyển sang máy chủ CI, để mỗi thay đổi đều được kiểm mà không ai phải nhớ chạy.

Tóm tắt

• Firmware thử được trên máy chủ, trong vi điều khiển giả lập và trên bo thật với đầu vào mô phỏng; mức càng rẻ thì càng ít nói được về robot thật.
• Tách quyết định khỏi phần cứng và dùng cảm biến giả, đồng hồ giả, liên kết giả cùng đầu ra được ghi lại, để một kịch bản như mất nhịp tim thành bài thử tự động.
• Chạy bài thử trên máy chủ sau mỗi thay đổi; thời gian thực, ngoại vi thật và vô tuyến thật vẫn cần bo thật.