Fully Understanding the System Pipeline in ROS1 Navigation

Ketika pertama kali belajar ROS1 Navigation, saya mengira keberhasilan berarti satu hal sederhana: robot bisa bergerak dari titik A ke titik B.

Dan pada awalnya, itu benar terjadi.

Robot bergerak. Tujuan tercapai. Sistem terlihat berjalan. Saya merasa sudah “mengerti” ROS.

Namun perasaan itu tidak bertahan lama.

Begitu robot berhenti tiba-tiba, berputar tanpa arah, atau menabrak obstacle yang jelas terlihat, saya kebingungan. Saya mengubah parameter secara acak, menjalankan ulang node, dan mencari jawaban di forum. Kadang berhasil, sering kali tidak.

Di titik itu saya sadar, saya sedang menggunakan ROS, tetapi belum benar-benar memahami sistem di baliknya.

Menggunakan ROS Tidak Sama dengan Memahami Sistemnya

Banyak orang, termasuk saya di awal, belajar ROS Navigation lewat tutorial. Kita menyalin launch file, mengikuti langkah demi langkah, lalu puas ketika robot akhirnya bergerak.

Pendekatan ini wajar, tetapi menyimpan masalah mendasar.

Saya mulai menyadari bahwa ROS Navigation sering diperlakukan seperti kumpulan node yang berdiri sendiri, bukan sebagai satu sistem utuh. Ketika terjadi kegagalan, pertanyaan yang muncul biasanya seperti:

• Parameter mana yang salah
• Node mana yang bermasalah
• Kenapa di setup lain bisa jalan

Masalahnya bukan pada pertanyaannya, tetapi pada cara pandang. Autonomous navigation pada ROS adalah sistem sebab akibat dari awal sampai akhir. Jika satu bagian tidak dipahami, seluruh sistem terasa rapuh dan sulit dijelaskan.

Apa Arti Fully Understanding the System Pipeline

Bagi saya, fully understanding the system pipeline bukan berarti menghafal semua node atau parameter ROS. Ini juga bukan soal menyelesaikan sebanyak mungkin tutorial.

Yang saya maksud adalah memahami navigation sebagai sistem real-time end-to-end, di mana sensing, localization, planning, dan control saling memengaruhi setiap saat.

Perumpamaannya seperti tubuh manusia. Sensor adalah indra, localization adalah kesadaran posisi, planner adalah otak yang mengambil keputusan, dan control adalah otot yang bergerak. Jika satu bagian tidak sinkron, tubuh tetap bergerak, tetapi dengan cara yang aneh.

Ketika pipeline ini mulai saya pahami, banyak hal berubah. Error tidak lagi terasa acak. Debugging menjadi lebih logis. Perilaku robot terasa masuk akal, bahkan ketika gagal.

Melihat ROS1 Navigation sebagai Alur Sistem

Untuk memahami navigation dengan benar, saya berhenti melihat ROS sebagai sekadar software. Saya mulai mengikuti aliran data dan keputusan di dalam sistem.

Sensor sebagai Titik Awal Sistem

Semua dimulai dari sensor. Pada robot mobile, LiDAR biasanya mempublikasikan data jarak melalui topik /scan.

lidar scan visualization

Pada tahap ini, data masih mentah. Sensor tidak tahu apa itu obstacle atau jalur aman. Ia hanya melaporkan jarak dan sudut. Jika sensor bermasalah, terlambat, atau tidak sinkron, maka semua komponen di atasnya ikut bermasalah.

Bagi saya, sensor adalah fondasi sistem. Jika fondasi ini rapuh, tidak ada planner yang bisa menyelamatkannya.

Representasi Lingkungan melalui Costmap

Data sensor kemudian diterjemahkan menjadi costmap. Costmap merepresentasikan tingkat risiko di sekitar robot, termasuk obstacle statis, obstacle dinamis, dan area inflasi sebagai jarak aman.

costmap layers example

Saya sering mengibaratkan costmap seperti peta panas. Area aman berwarna dingin, area berbahaya berwarna panas. Planner tidak melihat dunia secara visual seperti manusia, tetapi lewat peta risiko ini.

Banyak masalah navigation yang saya temui ternyata berasal dari sini. Costmap yang terlambat diperbarui membuat robot bereaksi lambat. Inflasi yang terlalu besar membuat robot terlihat takut bergerak.

Costmap tidak mengambil keputusan. Ia hanya memberi gambaran dunia kepada planner.

Localization dan Estimasi Posisi

Localization menjawab satu pertanyaan sederhana tetapi krusial: saya sedang berada di mana.

Dalam ROS1, tugas ini biasanya dilakukan oleh AMCL. AMCL mengestimasi posisi robot berdasarkan peta dan data sensor, lalu menghasilkan pose berupa koordinat x, y, dan orientasi.

amcl particle distribution

Saya mengibaratkan AMCL seperti seseorang yang berdiri di tengah kota sambil menebak posisinya berdasarkan bangunan di sekitar. Ia tidak peduli ke mana akan pergi, yang penting ia tahu sedang berada di mana.

Ketika localization tidak stabil, semua perencanaan di atasnya ikut kacau, meskipun sensor dan planner terlihat baik-baik saja.

Global Planning sebagai Rencana Jangka Panjang

Global planner menentukan jalur dari posisi saat ini menuju tujuan berdasarkan peta statis.

Bagi saya, global planner seperti Google Maps. Ia memberi rute terbaik berdasarkan peta, tetapi tidak tahu jika ada orang tiba-tiba menyeberang jalan.

Ketika global planner gagal, robot bisa berhenti atau menolak bergerak. Masalah ini sering terlihat seperti error kecil, padahal sumbernya ada pada perencanaan jalur global.

Local Planning dan Perilaku Real-Time

Local planner bertanggung jawab atas bagaimana robot bergerak saat ini. Ia memilih kecepatan dan arah dengan mempertimbangkan obstacle dinamis dan kondisi sekitar.

Jika global planner adalah Google Maps, local planner adalah refleks kita saat berjalan di keramaian. Menghindar, melambat, atau berhenti.

Sebagian besar perilaku aneh robot yang saya temui berasal dari tahap ini. Robot berputar, ragu-ragu, atau berhenti mendadak sering kali bukan bug, tetapi hasil keputusan local planner.

Control sebagai Eksekusi Keputusan

Tahap terakhir adalah pengiriman perintah ke robot melalui topik /cmd_vel.

cmd vel flow

Controller tidak membuat keputusan. Ia hanya mengeksekusi apa yang sudah diputuskan oleh seluruh pipeline sebelumnya. Jika robot tidak bergerak, belum tentu controller bermasalah. Bisa jadi memang tidak ada keputusan yang aman untuk dieksekusi.

Mengapa Error Terasa Tidak Masuk Akal

Dulu saya sering menganggap ROS Navigation tidak stabil atau sulit diprediksi. Setelah memahami pipeline, saya sadar sistem ini jarang benar-benar acak.

Yang terasa tidak masuk akal biasanya berasal dari interaksi tersembunyi antar komponen, seperti perbedaan frekuensi update, delay sensor, atau konflik antar layer costmap.

Tanpa pemahaman pipeline, semua ini terlihat seperti keajaiban buruk. Dengan pemahaman sistem, semuanya bisa ditelusuri.

Dari Pengguna Tutorial ke Pemikir Sistem

Ada perubahan cara berpikir yang saya rasakan.

Saat masih mengikuti tutorial, saya bertanya parameter apa yang harus diubah. Setelah memahami sistem, saya bertanya komponen mana yang bertanggung jawab atas perilaku ini.

Perubahan ini membuat belajar robotika terasa lebih masuk akal. Navigation tidak lagi seperti kotak hitam, tetapi sistem yang bisa dianalisis dan dipahami.

Penutup

Dalam robotika, kemajuan sejati tidak dimulai ketika robot bergerak.

Kemajuan dimulai ketika saya memahami mengapa ia bergerak seperti itu.

ROS1 Navigation bukan sihir. Ia adalah sistem. Dan sistem hanya bisa benar-benar dipahami ketika pipeline-nya dilihat secara utuh.