Pada awalnya saya menghindari menggunakan ROS2, kenapa? dan apa pilihan akhir saya?
Sempat keras kepala menghindari ROS2 dan memilih membangun custom middleware sendiri untuk robot quadruped saya, akhirnya saya 'ditampar' realita. Simak alasan teknis mengapa Docker jadi penyelamat di Raspberry Pi Bookworm dan kenapa Anda sebaiknya tidak membangun framework dari nol.
Ketika kita ingin membangun sebuah Robot, ada beberapa framework yang bisa kita gunakan untuk membantu kita membangun proyek robot kita. tapi supaya ga panjang lebar saya hanya menyebutkan 1 saja sebuah Framework yang bisa digunakan untuk segala projek robot, nama-nya ROS (Robot Operating System), ini jagoan, banyak yang menggunakan ini untuk membangun proyek robotika nya. ROS sendiri bisa dibilang bukan sekedar framework, tapi lebih dari itu ini adalah “ekosistem raksasa”, pokoknya wah deh. Nah pasti ada alasan nya dong kenapa populer? jadi begini, ini ekosistem memiliki ribuan paket siap pakai untuk navigasi, visi komputer, hingga kontrol lengan robot. Jika kita ketemu suatu masalah, forum komunitas siap membantu kita (ini yang penting).
Lalu apa Robot Quadruped Autonomous yang saya rencanakan akan menggunakan ROS? hm... Pada awalnya Jawaban-nya tidak, saya mencoba membangun Custom Middleware sebagai wadah pada otak robot saya sehingga semua sensor dan Aktuator yang digunakan bisa saling berkomunikasi dan berkolaborasi. Ada beberapa alasan yang saya miliki, yang antara lain:
- Ada 2 versi ROS yang stabil saat ini yaitu ROS 2 Humble Hawksbill → targetnya Ubuntu 22.04 (Jammy), dan ROS 2 Jazzy Jalisco → targetnya Ubuntu 24.04 (Noble) nah bagaimana sudah terlihat? Saya menggunakan OS Raspberry Pi Bookworm, dimana tidak support untuk ke dua-nya.
- Kompatibilitas dengan Hailo-8 AI Hat, Hailo-8 itu punya ekosistem sendiri, dan tidak ada official ROS2 package untuk Hailo. Memang akan selalu ada cara agar Hailo, bisa membantu ROS menjalankan pekerja-an nya tapi dengan kondisi yang seperti ini, saya pikir akan menambah lama proses development nya nanti (ini asumsi saya sekilas ya kawan)
- Akses Hardware (Camera, SPI, I2C, GPIO), dimana kalau ga pake ROS, kita bisa akses langsung, mantab dan mudah. Dengan ROS? tunggu dulu, perjalanan panjang akan dimulai.
- Dan alasan lain-nya yang saya lupa, karena memang tidak terdokumentasi penelitian awal nya proyek ini, dan waktu itu, wadah curhat saya di web ini belum saya bangun. (Note: Tapi kalau saya ingat nanti saya tambahkan ya).
Lalu apa solusi yang saya ambil? Bisa dibilang saya membuat Custom Middleware, dimana saya mencoba membangun sebuah program yang menjadi wadah pada otak robot saya, sehingga semua sensor dan Aktuator yang digunakan bisa saling berkomunikasi dan berkolaborasi, sampai saya menyadari, dan ditampar realita:
- Membangun "Roda" yang Sama: Saya sadar sedang membangun ulang fungsi yang sudah ada di ROS. Malah jadi lebih rumit dan lama.
- Investasi Waktu yang Mahal: Proyek ini terancam jadi "proyek abadi" karena dikerjakan sendiri tanpa tim dan manajemen yang matang.
- Skalabilitas & Dokumentasi: Tanpa struktur standar seperti ROS, sistem buatan sendiri akan sulit dikembangkan di masa depan. Apalagi dokumentasi sering terabaikan kalau kerja sendiri.
- Stabilitas: ROS sudah teruji bertahun-tahun. Sistem buatan saya? Masih penuh bug kompleks yang menguras energi.
- Distraksi Fokus: Tujuan utama saya adalah membangun Autonomous Quadruped, bukan membangun framework robotika dari nol.
Lalu apa pilihan terakhirnya?
“Kembali ke ROS Broh, jalankan ROS dengan Docker untuk menengahi kondisinya yang tidak kompatibel dengan OS Raspberry Pi Bookworm ini”. Dan akhirnya kita akan masuk ke teknis, mencoba hal baru untuk mencapai kepuasan.
— Prahastha