Sebuah pandangan humoris tentang sejarah robotika telah memicu diskusi yang penuh gairah mengenai salah satu alat paling kontroversial di bidang ini: Robot Operating System ( ROS ). Perdebatan tersebut mengungkap perpecahan mendalam dalam komunitas robotika tentang apakah framework yang banyak digunakan ini merupakan alat yang membantu atau beban teknis yang sulit ditinggalkan oleh perusahaan-perusahaan.
Hubungan Cinta-Benci dengan ROS
Komunitas robotika mendapati diri mereka terjebak dalam siklus yang terus berulang dengan ROS . Banyak organisasi memulai proyek dengan ROS untuk bergerak cepat selama fase prototyping, namun kemudian menghadapi tantangan untuk bermigrasi darinya saat mereka melakukan scale up. Hal ini menciptakan pola yang familiar di mana tim-tim menemukan bahwa ROS menawarkan solusi siap pakai yang dapat menggantikan ribuan baris kode custom, menarik mereka kembali ke dalam ekosistemnya meskipun sebelumnya berencana untuk beralih.
Seorang developer menangkap frustrasi ini dengan sempurna, menggambarkan ROS sebagai cara untuk dengan cepat mengevaluasi seberapa bingungnya sebuah organisasi tentang pilihan teknis mereka. Kritik tersebut berpusat pada ROS sebagai kumpulan komponen yang masing-masing merepresentasikan versi inferior dari alat-alat yang sudah ada, diimplementasikan oleh orang-orang yang mungkin tidak sepenuhnya memahami alternatif yang lebih baik yang tersedia.
Siklus Pengembangan ROS yang Umum:
- Mulai dengan ROS untuk pembuatan prototipe cepat
- Merencanakan migrasi dari ROS saat proyek berkembang
- Menemukan komponen ROS yang menggantikan kode kustom
- Kembali ke ROS meskipun sudah merencanakan migrasi
- Siklus berulang dengan proyek-proyek baru
Tantangan Teknis dan Kekhawatiran Arsitektural
Masalah inti dengan ROS melampaui sekadar masalah usability sederhana. Para kritikus menunjukkan bahwa ROS mendorong arsitektur terdistribusi yang membuat sebagian besar masalah robotika menjadi lebih sulit dipecahkan, terutama yang memerlukan respons latensi rendah. Hal ini sangat bermasalah karena sebagian besar aplikasi robotika secara inheren sensitif terhadap waktu.
Bagi pendatang baru yang mencoba memahami ROS , kurva pembelajaran terbukti sangat curam. Dokumentasi sering kali dimulai di tengah-tengah konsep daripada membangun pemahaman dari dasar atau memberikan gambaran top-down yang jelas. Hal ini membuat banyak developer bingung tentang pertanyaan dasar seperti bagaimana mengontrol motor sederhana melalui Arduino menggunakan sistem messaging ROS .
Komponen ROS dan Kritik:
- Sistem build untuk mengelola proyek robotika
- Pesan komunikasi antar-proses (IPC)
- Kumpulan pustaka dan alat debugging
- Mendorong arsitektur terdistribusi yang meningkatkan latensi
- Setiap komponen digambarkan sebagai inferior dibandingkan alat khusus yang sudah ada
Konteks yang Lebih Luas dari Alat-alat Robotika
Perdebatan ROS menyoroti tantangan yang lebih besar dalam pengembangan robotika: kesenjangan antara alat penelitian akademis dan aplikasi komersial praktis. Meskipun ROS menyediakan koleksi alat yang komprehensif termasuk sistem build, protokol messaging, dan utilitas debugging, setiap komponen sering kali tidak mencapai standar alternatif khusus yang tersedia di dunia pengembangan software yang lebih luas.
Diskusi ini juga mengungkap bagaimana bidang robotika berjuang dengan transisi dari lingkungan penelitian ke sistem produksi. Alat-alat yang bekerja dengan baik di laboratorium universitas mungkin tidak dapat scale secara efektif ke deployment komersial, meninggalkan perusahaan-perusahaan terjebak antara solusi yang familiar namun terbatas dan upaya signifikan yang diperlukan untuk membangun alternatif yang lebih baik.
Perdebatan yang sedang berlangsung ini mencerminkan growing pains dari sebuah bidang yang berada di persimpangan rekayasa hardware dan software, di mana kompleksitas aplikasi robotika dunia nyata sering kali melampaui apa yang dapat ditangani dengan elegan oleh framework tujuan umum.
Referensi: A Brief, Incomplete, and Mostly Wrong History of Robotics