# Chẩn đoán đội robot ở kho hàng: đọc log như một Forward Deployed Robotics Engineer

> Khi robot làm rơi hộp, đoán nguyên nhân thì nhanh, nhưng phải tái hiện được lỗi rồi đặt lệnh cạnh phản hồi trong log thì bạn mới khoanh được vùng lỗi: phần cứng, độ trễ hay hành vi của model.

Bản gốc: https://fdetimes.net/vi/bach-khoa/fde-physical-intelligence-robot-fleet-telemetry-debug/

Thử hình dung một ticket mới vào hàng đợi lúc đầu ca: "Robot ở trạm 7 làm rơi hộp." Không có ảnh, không có mốc giờ, chỉ có một người vận hành kho đang sốt ruột. Bạn có thể đoán ngay là tay gắp mòn, camera bẩn hay model "ngáo". Cả ba đều nghe hợp lý. Và đoán theo cách đó là con đường ngắn nhất để mất hai ngày.

Physical Intelligence mô tả vị trí Forward Deployed Robotics Engineer của họ là tuyến phòng thủ kỹ thuật đầu tiên cho một đội robot đang lớn dần. Các robot này chạy trong kho hàng và trong những môi trường thu thập dữ liệu bên ngoài.

Công việc được liệt kê khá thẳng: phân tích ticket từ hiện trường, tái hiện lỗi, thu dữ liệu chẩn đoán và theo đến khi lỗi được giải quyết.

Không phải làm robot mới cần kỹ năng này. Đọc dữ liệu nhiều luồng theo dòng thời gian, khoanh vùng nguyên nhân rồi biến một sự cố lẻ thành bài học cho cả hệ thống là việc của bất kỳ FDE nào phải gỡ lỗi production trên dữ liệu thật.

Điểm khác là với robot, một lần đoán sai để lại hậu quả nhìn thấy được ngay: chiếc hộp nằm trên sàn kho.

## Ticket đến trước chưa chắc được xử lý trước

Bản mô tả công việc yêu cầu xếp ưu tiên hàng đợi ticket theo ảnh hưởng tới cả đội robot và theo mục tiêu vận hành, chứ không theo thứ tự ticket đến. Vì thế, câu hỏi đầu tiên với ticket trạm 7 không phải "vì sao" mà là "có ở đâu khác không".

Thử hình dung bạn lọc hàng đợi theo từ khóa "rơi" và "gripper" trong tuần qua và thấy ba trạm khác cũng báo lỗi tương tự, cả ba đều chạy cùng một phiên bản firmware. Lúc đó ticket trạm 7 không còn là sự cố của một robot.

Nó là triệu chứng của một vấn đề cả đội, và phải được đẩy lên đầu hàng. Ngược lại, nếu chỉ có đúng trạm 7, bạn đang tìm thứ gì đó riêng của trạm này: phần cứng, cách bố trí, ánh sáng hay loại hộp.

Chỉ cần Bash cho bước này. Một lệnh `grep -il "rơi\|drop" tickets/*.txt | xargs grep -h "station"` rồi `sort | uniq -c` cho bạn bức tranh ban đầu trong ba mươi giây. Không cần dashboard.

## Chưa tái hiện được thì chưa có gì để chẩn đoán

Bước tiếp theo nhiều kỹ sư phần mềm muốn bỏ qua: đi tới trạm. Physical Intelligence ghi rõ nhiệm vụ kiểm tra vật lý và chạy thử chức năng ngay tại trạm robot để xác nhận lỗi tái hiện được. Một lỗi không tái hiện được có thể là hộp đặt lệch đúng một lần, hoặc là người báo nhầm robot.

Tại trạm 7, bạn cho robot gắp lặp lại cùng một loại hộp. Giả sử sau 40 lần gắp có 6 lần rơi. Đây là con số do bạn tạo ra trong điều kiện bạn kiểm soát, và quan trọng hơn, bạn biết chính xác 6 lần rơi đó xảy ra lúc mấy giờ. Những mốc giờ ấy là chìa khóa để mở file log.

## Log là nơi các luồng dữ liệu được đặt cạnh nhau

Trên robot chạy ROS 2, thứ bạn mở ra thường là một file MCAP. Đây là định dạng container mã nguồn mở cho log dữ liệu đa phương thức và là định dạng log mặc định của ROS 2.

Nó ghi và phát lại được các message nhị phân ở bất kỳ định dạng nào. Một file có thể chứa đồng thời ảnh camera, trạng thái khớp, lệnh gửi tới tay gắp và dòng cảm biến lực.

Sai lầm hay gặp là mở cả file trong công cụ trực quan rồi kéo thanh thời gian một cách vô định. Hãy làm ngược lại: cắt đúng khoảng vài giây quanh mỗi lần rơi và chỉ đọc các topic liên quan. Đoạn script dưới đây minh họa ý đó. Tên topic và tên file chỉ là ví dụ; bạn thay bằng tên trong hệ thống thật.

```python
from mcap.reader import make_reader
from mcap_ros2.decoder import DecoderFactory

TOPICS = ["/gripper/command", "/gripper/state"]
DROPS = [1730955612.4, 1730955987.1]  # mốc giờ các lần rơi khi tái hiện
WINDOW = 3.0  # giây trước và sau mỗi lần rơi

with open("tram7_tai_hien.mcap", "rb") as f:
    reader = make_reader(f, decoder_factories=[DecoderFactory()])
    for _, channel, message, msg in reader.iter_decoded_messages(topics=TOPICS):
        t = message.log_time / 1e9
        if any(abs(t - d) <= WINDOW for d in DROPS):
            print(f"{t:.3f}  {channel.topic:18}  {msg}")
```

Kết quả là một dòng thời gian ngắn, trong đó lệnh và phản hồi nằm ngay cạnh nhau. Bạn đọc nó như đọc một đoạn hội thoại: robot ra lệnh "đóng tay", tay gắp trả lời gì, sau bao lâu?

## Ba câu chuyện mà một dòng thời gian có thể kể

Thử hình dung ba kết quả. Câu chuyện thứ nhất: lệnh đóng được gửi đi, nhưng trạng thái tay gắp báo lực kẹp thấp hơn hẳn so với những lần gắp thành công. Nghiêng về phần cứng: đệm tay gắp mòn hoặc mô-tơ yếu.

Câu chuyện thứ hai: lệnh đóng đến muộn so với thời điểm tay chạm hộp. Nghiêng về độ trễ trong hệ thống. Bạn hãy so sánh độ trễ đó ở những lần rơi và những lần không rơi.

Câu chuyện thứ ba khó nhất: phần cứng phản hồi đúng, độ trễ bình thường, nhưng tay gắp chọn điểm kẹp lệch hẳn mép hộp. Lúc này bạn phải hỏi về model.

Physical Intelligence viết rằng π0.5 nhắm tới khả năng tổng quát hóa sang môi trường mới, và các thí nghiệm của họ được làm trong những ngôi nhà không có trong dữ liệu huấn luyện.

Khi công bố mã nguồn π0, họ cũng nói thẳng đây là thử nghiệm, vì π0 được phát triển cho chính robot của họ.

Với người chẩn đoán, những câu đó là lời nhắc về kỳ vọng: môi trường ở hiện trường có thể khác hẳn những gì model từng thấy khi huấn luyện. Một loại hộp mới, băng keo bóng hay ánh đèn lạ đều có thể đổi hành vi của model mà không có linh kiện nào hỏng. Hãy ghi lại ảnh camera ở các lần rơi.

Physical Intelligence cho biết từ 1 đến 20 giờ dữ liệu đã đủ để fine-tune π0 cho nhiều tác vụ khác nhau, nên những cảnh thất bại được ghi lại cẩn thận có thể có ích cho cả đội huấn luyện, không chỉ cho riêng ticket của bạn.

**Điểm mấu chốt:** Chưa có dòng thời gian cho thấy lỗi thì mọi giả thuyết vẫn chỉ là đoán.

## Đóng ticket mới xong một nửa việc

Bản mô tả công việc còn một nhiệm vụ dễ bị quên: nhận diện các lỗi lặp lại trong cả đội robot và chỉ ra những điểm yếu về độ bền để đội thiết kế cải tiến.

Nếu đệm tay gắp ở trạm 7 mòn sau một số chu kỳ nhất định, câu hỏi tiếp theo là các trạm khác đã chạy bao nhiêu chu kỳ. Thay đệm là sửa một robot. Báo cho đội thiết kế rằng đệm cần bền hơn là sửa cả đội.

Một bản root cause tốt chỉ cần một trang: triệu chứng, cách tái hiện và tỷ lệ lỗi, đoạn log làm bằng chứng, nguyên nhân, cách khắc phục tại chỗ, và pattern đã báo về cho đội thiết kế. Viết nó theo cùng một khuôn mỗi lần, thì sau vài tháng bạn có một kho dữ liệu để thấy lỗi nào đang lặp lại.

## Những lỗi khiến một ca chẩn đoán kéo dài

Lỗi phổ biến nhất là chẩn đoán trước khi tái hiện: sửa theo giả thuyết, thấy lỗi biến mất trong năm phút rồi đóng ticket, trong khi tỷ lệ lỗi chỉ 6 trên 40 thì năm phút không chứng minh được gì.

Lỗi thứ hai là kết luận "model sai" hay "phần cứng hỏng" chỉ vì đó là phần bạn quen thuộc. Lỗi thứ ba là đọc toàn bộ log thay vì khoanh đúng khoảng thời gian, và lỗi cuối cùng là đóng ticket mà không bao giờ hỏi trạm khác có bị giống vậy không.

## Cách chứng minh kỹ năng này khi đi xin việc

Phần yêu cầu của Physical Intelligence nêu tối thiểu 2 năm kinh nghiệm gỡ lỗi và điều tra nguyên nhân gốc, cùng kinh nghiệm phân tích log và viết script chẩn đoán bằng Python hoặc Bash. Trước một JD như vậy, câu "có kinh nghiệm debug" trong CV không thuyết phục được ai.

Hãy viết cụ thể. Ví dụ: "Viết script Python cắt log quanh các sự cố, giảm thời gian tìm nguyên nhân của một lỗi gián đoạn", kèm một bản root cause đã ẩn thông tin nhạy cảm.

Khi phỏng vấn, hãy kể một lỗi theo đúng trình tự trong bài: bạn xếp ưu tiên ra sao, tái hiện thế nào, log cho thấy gì, và bạn đã báo về cho đội thiết kế điều gì.

Robot ở trạm 7 sẽ còn làm rơi hộp, và trạm 12 cũng vậy. Người được tin cậy ở hiện trường là người biết tìm trong log đúng khoảnh khắc hộp rơi.

**Thử ngay tuần này:**

- Tải một file MCAP mẫu công khai, viết script in ra danh sách topic và tần suất của từng topic, rồi cắt ra một khoảng 10 giây quanh một sự kiện bạn tự chọn
- Viết lại một lần debug khó của bạn thành bản root cause dài một trang, gồm triệu chứng, cách tái hiện, bằng chứng trong log, nguyên nhân và việc đã đẩy về đội thiết kế, rồi đưa nó vào portfolio

## Nguồn

- [Forward Deployed Robotics Engineer (Physical Intelligence, via Designer Fund job board)](https://jobs.designerfund.com/companies/physical-intelligence/jobs/65751894-forward-deployed-robotics-engineer)

- [Forward Deployed Robotics Engineer (Physical Intelligence, via Thrive Capital job board)](https://jobs.thrivecap.com/companies/physical-intelligence/jobs/65751894-forward-deployed-robotics-engineer)

- [MCAP](https://mcap.dev/)

- [π0.5: a VLA with Open-World Generalization (Physical Intelligence)](https://www.pi.website/blog/pi05)

- [Open Sourcing π0 (Physical Intelligence)](https://www.pi.website/blog/openpi)