Mochi là gì?

Mochi bắt đầu như một bài tập sản phẩm

Mochi là một robot nhỏ mình đang phát triển tại Nastrotek. Mình xem Mochi như một bài tập làm sản phẩm hơn là một món đồ trình diễn. Điều đáng quan tâm không chỉ là robot có thể di chuyển hay phản hồi, mà còn là cách toàn bộ hệ thống được nghĩ, làm, ghi lại và cải thiện qua từng vòng.

Một robot nhỏ có nhiều lớp việc. Nó cần phần cứng đủ ổn để chạy lâu hơn vài phút. Nó cần firmware đủ rõ để dễ debug. Nó cần thiết kế cơ khí để không làm việc lắp ráp trở nên khó chịu. Nó cũng cần một dạng giao diện hoặc tín hiệu để người dùng hiểu robot đang làm gì. Vì vậy, Mochi là nơi phù hợp để gom Hardware, Firmware, PCB Design, Embedded UI và Product Design vào cùng một câu chuyện.

Nếu bạn cũng thích học qua một sản phẩm thật, mình hy vọng hành trình này sẽ cho bạn một góc nhìn gần gũi về cách các lớp đó ảnh hưởng lẫn nhau.

Vì sao lại là robot nhỏ?

Robot là một bài toán dễ thấy nhưng không hề đơn giản. Khi một đèn LED không sáng, nguyên nhân có thể nằm ở sơ đồ mạch, chân GPIO, nguồn cấp, code khởi tạo, hoặc chỉ là dây nối chưa chắc. Khi một chuyển động không đúng, lỗi có thể đến từ cơ khí, thuật toán điều khiển, pin yếu, hoặc cách người dùng đang tương tác.

Chính vì vậy, Mochi giúp mình luyện cách nghĩ theo hệ thống. Không thể chỉ chăm chăm vào một lớp rồi bỏ qua lớp khác. Một quyết định nhỏ ở PCB có thể ảnh hưởng đến firmware. Một giới hạn về pin có thể ảnh hưởng đến hành vi của sản phẩm. Một chi tiết trên vỏ có thể khiến việc sửa lỗi sau này khó hơn.

Bản prototype thật còn khá thô; ảnh này ghi đúng trạng thái của dự án lúc đó.

Mochi không cần hoàn hảo ngay

Trong giai đoạn đầu, Mochi không được định nghĩa bằng một danh sách tính năng thật dài. Mình muốn bắt đầu bằng vài câu hỏi nhỏ: robot cần thể hiện trạng thái như thế nào, người dùng cần một màn hình hay chỉ cần đèn và âm thanh, firmware nên chia module ra sao để dễ thử, và PCB đầu tiên nên ưu tiên nhỏ gọn hay dễ đo đạc?

Những câu hỏi đó giúp phạm vi rõ hơn. Một bản thử đầu tiên có thể xấu, to, và còn nhiều dây. Điều đó chấp nhận được nếu nó giúp kiểm chứng giả định. Khi đã hiểu điều gì quan trọng, phiên bản sau mới nên gọn hơn.

Bên trong prototype đầu tiên còn nhiều dây và chưa tối ưu cho việc tháo lắp.

Nhật ký Mochi sẽ ghi gì?

Các bài viết về Mochi sẽ không chỉ ghi lại phần thành công. Mình muốn giữ cả những quyết định đã đổi, lỗi đáng nhớ, cách đọc datasheet, cách đặt test point, cách viết firmware dễ theo dõi và cách chọn tương tác phù hợp với một robot nhỏ.

Mỗi devlog nên trả lời ba câu hỏi: đã thử gì, học được gì và bước tiếp theo là gì. Nếu có file thiết kế hoặc đoạn source code liên quan, chúng có thể được đưa vào Resources sau khi đủ gọn và đủ dễ hiểu.

Sơ đồ đã dùng để kiểm tra kết nối trước khi gom mạch vào một PCB riêng.

Điều mình muốn giữ

Mình muốn Mochi có cảm giác thân thiện nhưng không cần biến nó thành một sản phẩm quá tham vọng ngay từ đầu. Một robot nhỏ vẫn có thể dạy mình rất nhiều nếu quá trình làm được ghi lại cẩn thận. Nó cho thấy một ý tưởng đi qua phần cứng, firmware, giao diện và thiết kế sản phẩm như thế nào.

Với Nastrotek, Mochi là một đường dây dài hạn. Mỗi ghi chú chỉ là một bước nhỏ. Nhưng nếu các bước nhỏ được viết rõ, sau một thời gian chúng sẽ trở thành một tài liệu phát triển sản phẩm có ích.

Đọc thêm liên quan

• Devlog giai đoạn đầu của Mochi
• Phần cứng Mochi ESP32-S3
• Tài nguyên model 3D cho Mochi