IMPLEMENTASI PEMETAAN PADA ROBOT BERGERAK

OTONOM UNTUK NAVIGASI DALAM RUANGAN

MENGGUNAKAN SENSOR RPLiDAR, ALGORITME HECTOR
SLAM, DAN ALGORITME DIJKSTRA

IMPLEMENTASI PEMETAAN DAN NAVIGASI DALAM

RUANGAN PADA AUTONOMOUS MOBILE ROBOT
MENGGUNAKAN SENSOR RPLiDAR, ALGORITMA HECTOR
SLAM, DAN ALGORITME DIJKSTRA BERBASIS ROBOT
OPERATING SYSTEM

PURWARUPA ROBOT BERGERAK OTONOM UNTUK

MAPPING DAN INDOOR NAVIGATION PADA PLATFORM
ROBOT OPERATING SYSTEM (ROS)

IMPLEMENTASI SISTEM NAVIGASI OTOMATIS DALAM

RUANGAN PADA ROBOT BERODA MENGGUNAKAN
PLATFORM ROBOT OPERATING SYSTEM (ROS)

IMPLEMENTASI SISTEM NAVIGASI OTOMATIS DALAM

RUANGAN PADA ROBOT BERODA MENGGUNAKAN MULTI-
SENSOR DAN MULTI-ALGORITHM

SKRIPSI

Untuk memenuhi sebagai persyaratan

memperoleh gelar Sarjana Teknik

Disusun oleh:
Bambang Gunawan Tanjung
NIM: 185150300111051
PROGRAM STUDI TEKNIK KOMPUTER
JURUSAN TEKNIK INFORMATIKA
FAKULTAS ILMU KOMPUTER
UNIVERSITAS BRAWIJAYA
MALANG
2021
 PERSETUJUAN

IMPLEMENTASI PEMETAAN DAN NAVIGASI DALAM RUANGAN PADA

AUTONOMOUS MOBILE ROBOT MENGGUNAKAN SENSOR RPLiDAR, ALGORITMA
HECTOR SLAM DAN ALGORITME DIJKSTRA PADA PLATFORM ROBOT OPERATING
SYSTEM
SKRIPSI

Diajukan untuk memenuhi sebagian persyaratan

memperoleh gelar Sarjana Teknik

Disusun Oleh :
Bambang Gunawan Tanjung
NIM: 185150300111051

Dosen Pembimbing I Dosen Pembimbing 2

Rizal Maulana, S.T., M.T., M.Sc. Rakhmadhany Primananda, S.T., M.Kom.

NIK: 2016078910091001 NIK: 2016098604061001
 PERNYATAAN ORISINALITAS

Saya menyatakan dengan sebenar-benarnya bahwa sepanjang pengetahuan

saya, di dalam naskah skripsi ini tidak terdapat karya ilmiah yang pernah
diajukan oleh orang lain untuk memperoleh gelar akademik di suatu perguruan
tinggi, dan tidak terdapat karya atau pendapat yang pernah ditulis atau
diterbitkan oleh orang lain, kecuali yang secara tertulis disitasi dalam naskah ini
dan disebutkan dalam daftar referensi.
Apabila ternyata di dalam naskah skripsi ini dapat dibuktikan terdapat unsur-
unsur plagiasi, saya bersedia skripsi ini digugurkan dan gelar akademik yang telah
saya peroleh (sarjana) dibatalkan, serta diproses sesuai dengan peraturan
perundang-undangan yang berlaku (UU No. 20 Tahun 2003, Pasal 25 ayat 2 dan
Pasal 70).

Malang, 20 Maret 2022

Bambang Gunawan Tanjung

NIM: 185150300111051
 PRAKATA

Syukur Alhamdulillah penulis panjatkan ke hadirat Allah SWT atas berkat

rahmat, hidayah dan ridho-Nya sehingga penulis dapat menyelesaikan tugas
akhir “skripsi” sebagai salah satu syarat yang diperlukan untuk menyelesaikan
Program Sarjana (S1) Program Studi Teknik Komputer Fakultas Ilmu Komputer
Universitas Brawijaya. Dalam ke penulisan skripsi ini, penulis telah menempuh
mata kuliah pendukung embedded system (CCE62204), sistem kendali
(CCE62160) dan sistem cerdas (CCE61151), guna mengimplementasikan topik
pada riset ini. Selain itu dalam penyusunan skripsi ini, tidak akan terselesaikan
tanpa adanya bantuan serta kemurahan hati dari berbagai pihak. Maka dari itu
tidak lupa penulis panjatkan terima kasih kepada seluruh pihak yang telah
memberikan inspirasi, bantuan, dan dukungan moral ataupun finansial. Ucapan
terima kasih juga penulis sampaikan kepada Bapak Rizal Maulana, S.T., M.T.,
M.Sc. selaku dosen pembimbing pertama dan Bapak Rakhmadhany Primananda,
S.T., M.Kom. selaku dosen pembimbing kedua atas bimbingan motivasi, saran
dan diskusi yang diberikan kepada penulis, mulai dari persiapan usulan penelitian
hingga penulis mampu menyelesaikan skripsi ini dengan baik.
Selanjutnya dengan penuh rasa hormat penulis mengucapkan terima kasih
kepada kedua orang tua tercinta, Syukri Amsyah Tanjung dan Misnawati, karena
semua keberhasilan ini tidak luput dari jasa, pengorbanan, limpahan cinta kasih
sayang, dukungan moral dan finansial serta doa beliau yang selalu dipanjatkan
setiap hari.
Dalam kesempatan ini penulis juga mengucapkan terima kasih sebesar-
besarnya kepada:
1. Bapak Achmad Basuki, S.T., M.M.G., Ph.D. selaku ketua Jurusan Teknik
Informatika Fakultas Ilmu Komputer Universitas Brawijaya.
2. Bapak Barlian Henryranu Prasetio, S.T., M.T., Ph.D. selaku ketua Program
Studi Teknik Komputer Fakultas Ilmu Komputer Universitas Brawijaya.
3. Bapak Gembong Edhi Setyawan, S.T., M.T. dan Bapak Dahnial Syauqy,
S.T., M.T., M.Sc. selaku dosen yang pernah menjadi dosen penasihat
akademik saya selama melaksanakan perkuliahan di Universitas
Brawijaya.
4. Bapak dan Ibu dosen yang telah mengajarkan saya mata kuliah selama di
teknik komputer maupun memberikan dukungan selama perkuliahan
saya.
5. Teman-teman terdekat saya yang selalu memberikan dukungan selama
perkuliahan dan mendorong saya untuk cepat menyelesaikan skripsi.
6. Teman-teman seperjuangan teknik komputer baik dari angkatan 2016,
2017, 2018, 2019, dan 2020 yang juga membantu saya pada pengerjaan
skripsi ini maupun selama perkuliahan saya.
 7. Hamdan Zuhdi Dewa yang telah menjadi sahabat karib saya sekaligus
partner skripsi yang mengerjakan proyek robot bersama-sama.
8. Seluruh anggota Komunitas Hoverboard Hack dan Robaka Internasional
yang senantiasa membantu menjawab pertanyaan ketika penulis sedang
mengalami kesulitan.
9. Seluruh tim pengembang ROS yang senantiasa mempublikasikan library
dan dokumentasi ROS secara open source.
Akhir kata, penulis menyadari bahwasanya dalam penyusunan skripsi ini
terdapat banyak kekurangan, baik berupa tata ke penulisan ataupun aspek
lainnya di dalam skripsi ini. Untuk itu, penulis menerima dengan lapang dada atas
segala kritikan ataupun saran yang diberikan oleh pihak pembaca ataupun
peneliti lainnya agar ke depannya penulis dapat memperbaiki karya tulis ini
ataupun karya tulis selanjutnya menjadi lebih baik lagi.

Malang, 20 Maret 2021

Penulis
bambanggunawan887@gmail.com
 ABSTRAK

Bambang Gunawan Tanjung, Implementasi Pemetaan Dan Navigasi Dalam

Ruangan Pada Autonomous Mobile Robot Menggunakan Sensor RPLiDAR,
Algoritma Hector SLAM Dan Algoritme Dijkstra Dengan Platform Robot
Operating System.
Pembimbing: Rizal Maulana, S.T., M.T., M.Sc. dan Rakhmadhany Primananda,
S.T., M. Kom.
Bagian ini diisi dengan abstrak dalam Bahasa Indonesia. Abstrak adalah
uraian singkat (umumnya 200-300 kata) yang merupakan inti sari dari sebuah
skripsi. Abstrak membantu pembaca untuk mendapatkan gambaran secara cepat
dan akurat tentang isi dari sebuah skripsi. Melalui abstrak, pembaca juga dapat
menentukan apakah akan membaca skripsi lebih lanjut. Oleh karena itu, abstrak
sebaiknya memberikan gambaran yang padat tetapi tetap jelas dan akurat
tentang (1) apa dan mengapa penelitian dikerjakan: sedikit latar belakang,
pertanyaan atau masalah penelitian, dan/atau tujuan penelitian; (2) bagaimana
penelitian dikerjakan: rancangan penelitian dan metodologi/metode dasar yang
digunakan dalam penelitian; (3) hasil penting yang diperoleh: temuan utama,
karakteristik artefak, atau hasil evaluasi artefak yang dibangun; (4) hasil
pembahasan dan kesimpulan: hasil dari analisis dan pembahasan temuan atau
evaluasi artefak yang dibangun, yang dikaitkan dengan pertanyaan/tujuan
penelitian.
Yang harus dihindari dalam sebuah abstrak diantarnya (1) penjelasan latar
belakang yang terlalu panjang; (2) sitasi ke pustaka lainnya; (3) kalimat yang tidak
lengkap; (3) singkatan, jargon, atau istilah yang membingungkan pembaca,
kecuali telah dijelaskan dengan baik; (4) gambar atau tabel; (5) angka-angka yang
terlalu banyak.
Di akhir abstrak ditampilkan beberapa kata kunci (normalnya 5-7) untuk
membantu pembaca memosisikan isi skripsi dengan area studi dan masalah
penelitian. Kata kunci, beserta judul, nama penulis, dan abstrak biasanya
dimasukkan dalam basis data perpustakaan. Kata kunci juga dapat di indeks
dalam basis data sehingga dapat digunakan untuk proses pencarian tulisan ilmiah
yang relevan. Oleh karena itu pemilihan kata kunci yang sesuai dengan area
penelitian dan masalah penelitian cukup penting. Pemilihan kata kunci juga bisa
didapatkan dari referensi yang dirujuk.

Kata kunci: abstrak, skripsi, inti sari, kata kunci, artefak

 ABSTRACT

Bambang Gunawan Tanjung, Implementation of Mapping and Indoor Naviga-

tion on Autonomous Mobile Robot Using RPLiDAR Sensor, Hector SLAM Algo-
rithm and Dijkstra Algorithm with Robot Operating System Platform.
Supervisor: Rizal Maulana, S.T., M.T., M.Sc. dan Rakhmadhany Primananda,
S.T., M. Kom.
This section is filled with abstracts in Indonesian. Abstract is a short
description (usually 200-300 words) which is the essence of a thesis. Abstract
helps readers to get a quick and accurate picture of the contents of a thesis.
Through the abstract, the reader can also determine whether to read the thesis
further. Therefore, the abstract should provide a concise but clear and accurate
description of (1) what and why the research was carried out: a little background,
research questions or problems, and/or research objectives; (2) how the research
is carried out: the research design and the basic methodology/methods used in
the research; (3) important results obtained: main findings, characteristics of
artifacts, or evaluation results of built artifacts; (4) the results of the discussion
and conclusions: the results of the analysis and discussion of the findings or
evaluation of the built artifacts, which are related to the research
questions/objectives.
Things to avoid in an abstract include (1) a background explanation that is
too long; (2) citation to other libraries; (3) incomplete sentences; (3)
abbreviations, jargon, or terms that confuse the reader, unless they are well
explained; (4) pictures or tables; (5) the numbers are too many.
At the end of the abstract, several keywords are displayed (normally 5-7) to
help the reader position the content of the thesis with the area of study and
research problem. Keywords, along with title, author name, and abstract are
usually entered in the library database. Keywords can also be indexed in the
database so that they can be used for the process of searching for relevant
scientific papers. Therefore, the selection of keywords that are appropriate to the
research area and research problem is quite important. Selection of keywords
can also be obtained from referenced references.

Keywords: abstract, thesis, essence, keywords, artifact

 DAFTAR ISI

PERSETUJUAN..........................................................................................................
PERNYATAAN ORISINALITAS...................................................................................
PRAKATA...................................................................................................................
ABSTRAK.................................................................................................................
ABSTRACT..............................................................................................................
DAFTAR ISI...............................................................................................................
DAFTAR TABEL........................................................................................................
DAFTAR GAMBAR...................................................................................................
DAFTAR LAMPIRAN................................................................................................
BAB 1 PENDAHULUAN..............................................................................................
1.1 Latar Belakang........................................................................................
1.2 Rumusan Masalah..................................................................................
1.3 Tujuan.....................................................................................................
1.4 Manfaat..................................................................................................
1.5 Batasan Masalah.....................................................................................
1.6 Sistematika Pembahasan........................................................................
BAB 2 LANDASAN KEPUSTAKAAN............................................................................
2.1 Tinjauan Pustaka.....................................................................................
2.1.1 Autonomous Mobile Robot Berbasis Landmark
Menggunakan Particle Filter Dan Occupancy Grid Maps Untuk
Navigasi, Penentuan Posisi, Dan Pemetaan............................................
2.1.2 2D LiDAR-Based SLAM and Path Planning for Indoor
Rescue Using Mobile Robots.................................................................
2.1.3 Navigasi Indoor Berbasis Peta Pada Robot Beroda
Dengan Platform Robot Operating System...........................................
2.1.4 Sistem Navigasi Mobile Robot Dalam Ruangan Berbasis
Autonomous Navigation.......................................................................
2.1.5 Path Planning for Smart Car Based on Dijkstra Algorithm
and Dynamic Window Approach..........................................................
2.2 Dasar Teori............................................................................................
2.2.1 Robot............................................................................................
2.2.2 Autonomous Mobile Robot (AMR)...............................................
 2.2.3 Mekanisme Kemudi Robot Beroda..............................................
2.2.4 Autonomous Navigation..............................................................
2.2.5 Kalman Filter untuk Lokalisasi......................................................
2.2.6 Simultaneous Localization And Mapping (SLAM)........................
2.2.7 Hector Simultaneous Localization and Mapping (Hector
SLAM)....................................................................................................
2.2.8 Navigasi........................................................................................
2.2.9 Path Planning...............................................................................
2.2.10 Algoritme Dijkstra......................................................................
2.2.11 Algoritma Dynamic Window Approach (DWA)..........................
2.2.12 Komponen Utama Robot...........................................................
2.2.13 Light Detection and Ranging......................................................
2.2.14 Wheel Odometry........................................................................
2.2.15 Inertial Measurement Unit (IMU)..............................................
2.2.16 Robot Operating System (ROS)..................................................
2.2.17 ROS Tool.....................................................................................
2.2.18 Virtual Network Computing (VNC).............................................
2.2.19 Firmware....................................................................................
2.2.20 Metode Statistik.........................................................................
BAB 3 METODOLOGI PENELITIAN..........................................................................
3.1 Tipe Penelitian......................................................................................
3.2 Strategi dan Rencana Penelitian...........................................................
3.3 Metode Penelitian................................................................................
3.4 Subjek Penelitian..................................................................................
3.5 Lokasi Penelitian...................................................................................
3.6 Teknik Pengumpulan Data....................................................................
3.7 Teknik Analisis Data..............................................................................
3.8 Peralatan Pendukung............................................................................
BAB 4 Rekayasa Kebutuhan...................................................................................
4.1 Gambaran Umum Sistem.....................................................................
4.2 Analisis Kebutuhan Sistem....................................................................
4.2.1 Kebutuhan Fungsional.................................................................
 4.2.2 Kebutuhan Non-Fungsional.........................................................
BAB 5 Perancangan dan implementasi..................................................................
5.1 Perancangan Sistem.............................................................................
5.1.1 Perancangan Skematis Prototype Sistem....................................
5.1.2 Perancangan Perangkat Keras Sistem..........................................
5.1.3 Perancangan Perangkat Lunak.....................................................
5.2 Implementasi Sistem..........................................................................
5.2.1 Implementasi Skematis Prototype Sistem.................................
5.2.2 Implementasi Perangkat Keras..................................................
5.2.3 Implementasi Perangkat Lunak.................................................
BAB 6 PeNGUJIAN................................................................................................
BAB 7 Penutup.....................................................................................................
7.1 Kesimpulan.........................................................................................
7.2 Saran...................................................................................................
DAFTAR REFERENSI..............................................................................................
LAMPIRAN A PERSYARATAN FISIK DAN TATA LETAK...........................................
LAMPIRAN B PERSYARATAN FISIK DAN TATA LETAK...........................................
LAMPIRAN C PERSYARATAN FISIK DAN TATA LETAK...........................................
LAMPIRAN D PERSYARATAN FISIK DAN TATA LETAK...........................................
LAMPIRAN E PERSYARATAN FISIK DAN TATA LETAK...........................................
 DAFTAR TABEL

Tabel 2.1 Tinjauan Penelitian Sebelumnya..............................................................7

Tabel 2.2 Penjelasan Variabel Persamaan Fungsi EKF...........................................20
Tabel 2.3 Penjelasan Variabel Persamaan Fungsi Hector Mapping......................26
Tabel 2.4 Pseudocode Algoritme Dijkstra..............................................................32
Tabel 2.5 Persamaan pada Dynamic Window Approach.......................................33
Tabel 2.6 Pseudocode Dynamic Window Approach..............................................34
Tabel 4.1 Kebutuhan Fungsional Sistem................................................................58
Tabel 4.2 Spesifikasi Motherboard Hoverboard....................................................60
Tabel 4.3 Spesifikasi Mikrokontroler Jetson Nano 3B...........................................62
Tabel 4.4 Spesifikasi Motor DC Brushless..............................................................63
Tabel 4.5 Spesifikasi Catu Daya untuk Suplai Motherboard Hoverboard..............64
Tabel 4.6 Spesifikasi Catu Daya untuk Suplai Jetson Nano....................................64
Tabel 4.7 Spesifikasi RPLiDAR A1...........................................................................65
Tabel 4.8 Spesifikasi Sensor IMU GY-521 MPU6050..............................................66
Tabel 4.9 Datasheet STLink V2 mini USB...............................................................67
Tabel 4.10 Parameter Hoverboard Driver..............................................................71
Tabel 4.11 Parameter RPLiDAR ROS Driver............................................................73
Tabel 4.12 Parameter MPU6050 Driver.................................................................73
Tabel 4.13 Parameter Hector Mapping.................................................................74
Tabel 4.14 Parameter EKF Localization..................................................................76
Tabel 4.15 Parameter AMCL Localization..............................................................76
Tabel 4.16 Parameter Move Base..........................................................................77
Tabel 4.17 Parameter Konfigurasi 2D Costmap.....................................................79
Tabel 4.18 Parameter Konfigurasi Dijkstra Global Planner...................................80
Tabel 4.19 Konfigurasi DWA Local Planner............................................................81
Tabel 5.1 Penjelasan Konfigurasi Pinout Motherboard Hoverboard.....................91
Tabel 5.2 Penjelasan pinout sensor RPLiDAR.........................................................93
Tabel 5.3 Penjelasan pinout sensor GY-521 IMU MPU6050..................................94
Tabel 5.4 Parameter Konfigurasi hoverboard_driver Driver Hoverboard.............99
Tabel 5.5 Parameter Konfigurasi paket rplidar_ros Sensor RPLIDAR..................100
Tabel 5.6 Parameter Konfigurasi mpu6050_driver Sensor IMU..........................100
Tabel 5.7 Daftar Paket Yang Digunakan pada AMR Navigation Package.xml......101
Tabel 5.8 Parameter Konfigurasi Paket Hector Mapping....................................115
Tabel 5.9 Parameter Konfigurasi Paket Hector Geotiff.......................................116
Tabel 5.10 Parameter Konfigurasi Paket Hector Trajectory................................116
Tabel 5.11 Parameter Konfigurasi Paket EKF Localization...................................118
Tabel 5.12 Parameter Konfigurasi Paket AMCL Localization...............................124
Tabel 5.13 Parameter Konfigurasi Paket Move Base...........................................128
Tabel 5.14 Parameter Konfigurasi 2D Common Costmap...................................129
Tabel 5.15 Parameter Konfigurasi Dijkstra Global Planner.................................133
Tabel 5.16 Parameter Konfigurasi DWA Local Planner........................................135
Tabel 5.17 Daftar Bagian Yang Dicetak................................................................139
Tabel 5.18 Mur, Baut, Dan Sekrup Yang Digunakan............................................141
Tabel 5.19 Pemasangan Kabel Untuk Flashing Motherboard.............................144
Tabel 5.20 Pemasangan Kabel Perangkat Keras Sistem Penggerak....................146
Tabel 5.21 Pemasangan Kabel Sistem Sensor......................................................147
Tabel 5.22 Kode Program Konfigurasi Firmware Motherboard Hoverboard......149
Tabel 5.23 Kode Program Konfigurasi Driver Hoverboard..................................155
Tabel 5.24 Kode Program Konfigurasi Launcher Hoverboard.............................156
Tabel 5.25 Kode Program Konfigurasi Launcher RPLiDAR...................................157
Tabel 5.26 Kode Program Konfigurasi Nama Topik Output IMU.........................158
Tabel 5.27 Kode Program Launcher Mapping Default.........................................159
Tabel 5.28 Kode Program Launcher AMR Mapping pada Hector SLAM Launch. 160
Tabel 5.29 Kode Program Paket ROS pada package.xml.....................................162
Tabel 5.30 Kode Program Konfigurasi Parameter MPU6050..............................165
Tabel 5.31 Perbandingan Output Sensor IMU Sebelum Dan Sesudah................166
Tabel 5.32 Kode Program Pemetaan...................................................................167
Tabel 5.33 Kode Program Parameter Hoverboard Driver
(controllers_hoverboard.yaml)............................................................................170
Tabel 5.34 Kode Program Parameter Hoverboard Driver (hardware.yaml)........172
Tabel 5.35 Kode Program Parameter Hoverboard Driver (joint_limits.yaml).....172
Tabel 5.36 Kode Program Navigasi......................................................................173
Tabel 5.37 Kode Program Lokalisasi AMCL..........................................................177
Tabel 5.38 Kode Program Move Base..................................................................179
Tabel 5.39 Kode Parameter Konfigurasi Common Costmap................................181
Tabel 5.40 Kode Parameter Konfigurasi Move Base............................................183
Tabel 5.41 Kode Parameter Konfigurasi Global Planner......................................184
Tabel 5.42 Kode Algoritme Dijkstra.....................................................................185
Tabel 5.43 Kode Path Planning Global Dengan Dijkstra......................................189
Tabel 6.1 Pengujian Odometry Motor BLDC........................................................192
Tabel 6.2 Hasil Akurasi Pengujian Fungsionalitas Nilai Odometry......................193
Tabel 6.3 Pengujian Fungsionalitas RPLIDAR.......................................................194
Tabel 6.4 Hasil Akurasi Pengujian Fungsionalitas RPLIDAR.................................196
 DAFTAR GAMBAR

Gambar 2.1 Robot Humanoid Pada Lomba RoboCup............................................13

Gambar 2.2 Robot Roomba Penyedot Debu.........................................................13
Gambar 2.3 Autonomous Mobile Robot................................................................14
Gambar 2.4 Penggunaan Robot Pada Gudang Logistik.........................................14
Gambar 2.5 Robot Membawa Paket Di Gudang Ekspedisi....................................15
Gambar 2.6 Kinematics Differential Drive..............................................................16
Gambar 2.7 Forward Kinematics Differential Drive...............................................17
Gambar 2.8 Ilustrasi Autonomous Navigation.......................................................18
Gambar 2.9 Aplikasi Indoor Navigation Di Dalam Mall.........................................18
Gambar 2.10 Ilustrasi Permasalahan Komputasi SLAM.........................................21
Gambar 2.11 SLAM Dengan Cara Landmark Observation dan Cara Sensor View. 22
Gambar 2.12 Occupancy Map Terletak Pada Pixel Warna Hitam.........................23
Gambar 2.13 Representasi Multiresolution Dari Sel Petak Peta Hector SLAM.....24
Gambar 2.14 Skema Sistem Hector SLAM.............................................................25
Gambar 2.15 Hubungan Antara Node dan Topik Pada Konfigurasi Navigasi........27
Gambar 2.16 Hubungan Antara Jarak ke Rintangan dan Nilai Costmap...............28
Gambar 2.17 Representasi Costmap.....................................................................29
Gambar 2.18 Perencanaan Jalur Terpendek Menggunakan Algoritme Dijkstra...30
Gambar 2.19 Grid Map Hasil Pemetaan................................................................31
Gambar 2.20 Ruang Pencarian Kecepatan Robot dan Dynamic Window.............33
Gambar 2.21 Kecepatan translasi v dan kecepatan rotasi w.................................34
Gambar 2.22 Motherboard Hoverboard................................................................35
Gambar 2.23 Motherboard Hoverboard................................................................36
Gambar 2.24 Nvidia Jetson Nano..........................................................................37
Gambar 2.25 Motor BLDC 6.5” 36V 350W dan build in Encoder..........................37
Gambar 2.26 Sensor RPLiDAR................................................................................38
Gambar 2.27 Sensor IMU GY-521..........................................................................39
Gambar 2.28 Menghitung Jarak Dengan LDS/LiDAR.............................................40
Gambar 2.29 ROS Sebagai Sistem Operasi Meta Pada Sistem Operasi Lain.........42
Gambar 2.30 Koordinat Pada Rangkaian Robot....................................................46
Gambar 2.31 Frame Transformasi Robot Beroda..................................................46
Gambar 2.32 Tampilan Loading Screen RViz.........................................................47
Gambar 2.33 Tampilan Antarmuka Aplikasi rqt Dan Semua Plugin......................48
Gambar 2.34 Komunikasi Dua Komputer Dengan VNC.........................................49
Gambar 3.1 Diagram Alir Penelitian......................................................................53
Gambar 3.2 Denah Basemen Gedung G FILKOM UB.............................................54
Gambar 4.1 Blok Diagram Sistem..........................................................................57
Gambar 4.2 Perangkat Motherboard Hoverboard................................................60
Gambar 4.3 Nvidia Jetson Nano.............................................................................61
Gambar 4.4 Perangkat Motor BLDC Hoverboard..................................................62
Gambar 4.5 Baterai Hoverboard............................................................................63
Gambar 4.6 Sensor RPLiDAR A1.............................................................................64
Gambar 4.7 Sensor GY-521 IMU6050....................................................................65
Gambar 4.8 STM32Cube Programmer..................................................................68
Gambar 4.9 Diagram pohon directory catkin workspace....................................69
Gambar 4.10 ROS Melodic.....................................................................................69
Gambar 4.11 Tampilan Antarmuka RViz................................................................71
Gambar 5.1 Desain Chassis Badan Depan Robot...................................................84
Gambar 5.2 Desain Semua Bagian Cetak 3D.........................................................85
Gambar 5.3 Assembling Semua Bagian Chassis Belakang Robot..........................85
Gambar 5.4 Rancangan Sistem Kemudi Utama Robot..........................................86
Gambar 5.5 Grafik Kinematik Sistem Kemudi Diff-drive........................................86
Gambar 5.6 Rancangan Prototype Keseluruhan Sistem Tampak Samping...........87
Gambar 5.7 Rancangan Prototype Keseluruhan Sistem Tampak Atas..................88
Gambar 5.8 Rancangan Prototype Keseluruhan Sistem Tampak Bawah..............88
Gambar 5.9 Rancangan Perangkat Keras Sistem...................................................89
Gambar 5.10 Skema Sistem Penggerak Robot......................................................90
Gambar 5.11 Pinout Sensor RPLiDAR A1...............................................................93
Gambar 5.12 Pinout sensor GY-521 IMU MPU6050..............................................94
Gambar 5.13 Arsitektur Keseluruhan Sistem.........................................................95
Gambar 5.14 Diagram Alir Tahap Persiapan Awal Motherboard..........................96
Gambar 5.15 Pinout dari Motherboard ke STLink.................................................97
Gambar 5.16 Diagram Alir Persiapan Awal Jetson Nano.......................................98
Gambar 5.17 Diagram Alir Persiapan Awal Jetson Nano.....................................102
Gambar 5.18 Diagram Alir Program Utama.........................................................103
Gambar 5.19 Diagram Alir Sub Proses Kalibrasi Sensor IMU..............................104
Gambar 5.20 Diagram Alir Program Pemetaan...................................................106
Gambar 5.21 Transformasi Frame Pada Pemetaan.............................................108
Gambar 5.22 Diagram Alir Proses Algoritme Hector SLAM.................................110
Gambar 5.23 Diagram Alir Sub Proses Hector Mapping......................................111
Gambar 5.24 Diagram Alir Sub Proses Estimasi Pose 2D.....................................112
Gambar 5.25 Diagram Alir Sub Proses Occupancy Grid Map..............................114
Gambar 5.26 Diagram Alir Proses Algoritme Extended Kalman Filter (EKF).......117
Gambar 5.27 Diagram Alir Program Navigasi......................................................119
Gambar 5.28 Transformasi Frame Pada Navigasi................................................121
Gambar 5.29 Diagram Alir Algoritme Adaptive Monte Carlo Localization (AMCL)
..............................................................................................................................122
Gambar 5.30 Diagram Alir Sub Proses AMCL: Scan Matching.............................123
Gambar 5.31 Diagram Alir Sub Proses Path Planning..........................................127
Gambar 5.32 Grafik Semua Node Pada Proses Navigasi.....................................128
Gambar 5.33 Diagram Alir Algoritme Dijkstra.....................................................131
Gambar 5.34 Diagram Alir Algoritme Dynamic Window Approach.....................134
Gambar 5.35 Simulasi Maju Prediksi Pergerakan Robot.....................................135
Gambar 5.36 Dokumentasi Hasil Pembuatan Chassis Badan Robot...................138
Gambar 5.37 Dokumentasi Pencetakan Desain Dengan 3D Printer....................139
Gambar 5.38 Dokumentasi Pemasangan Brass Nut............................................140
Gambar 5.39 Hasil Assembling Chassis Robot.....................................................142
Gambar 5.40 Implementasi Prototype Sistem Robot Tampak Samping.............142
Gambar 5.41 Implementasi Prototype Sistem Robot Tampak Atas....................143
Gambar 5.42 Perangkat Hoverboard Yang Digunakan........................................144
Gambar 5.43 Dokumentasi Pembuatan Sistem Mainboard Robot.....................144
Gambar 5.44 Implementasi Sistem Penggerak Robot.........................................145
Gambar 5.45 Implementasi Sistem Persepsi Robot Dengan Sensor...................147
Gambar 5.46 Pesan Berhasil Melakukan Hapus Penuh Chip...............................148
Gambar 5.47 Implementasi Hasil Compile, Upload, dan Flashing Motherboard
Hoverboard..........................................................................................................151
Gambar 5.48 Implementasi Hasil Remote Access Ke Jetson Nano via VNC Berhasil
..............................................................................................................................152
Gambar 5.49 Implementasi Hasil Konfigurasi Port USB......................................154
Gambar 5.49 Directory Tree workspace catkin...................................................154
Gambar 5.50 Implementasi Hasil Compile Persiapan Jetson Nano.....................163
Gambar 5.51 Implementasi Pembacaan IMU Sebelum Kalibrasi........................164
Gambar 6.1 Menganalisis RPM Odometry Hoverboard Dengan Membandingkan
Dengan RPM Observasi........................................................................................192
Gambar 6.2 Kondisi Lingkungan Sekitar Pada Pengujian Jarak Data RPLIDAR....194
 DAFTAR LAMPIRAN

LAMPIRAN A PERSYARATAN FISIK DAN TATA LETAK...........................................

A.1 Kertas..................................................................................................
A.2 Margin................................................................................................
A.3 Jenis dan Ukuran Huruf......................................................................
A.4 Spasi....................................................................................................
A.5 Kepala Bab dan Subbab......................................................................
A.6 Nomor Halaman.................................................................................
LAMPIRAN B PERSYARATAN FISIK DAN TATA LETAK...........................................
B.1 Margin................................................................................................
B.2 Jenis dan Ukuran Huruf......................................................................
B.3 Spasi....................................................................................................
B.4 Kepala Bab dan Subbab......................................................................
B.5 Nomor Halaman.................................................................................
LAMPIRAN C PERSYARATAN FISIK DAN TATA LETAK...........................................
C.1 Margin................................................................................................
C.2 Jenis dan Ukuran Huruf......................................................................
C.3 Spasi....................................................................................................
C.4 Kepala Bab dan Subbab......................................................................
C.5 Nomor Halaman.................................................................................
LAMPIRAN D PERSYARATAN FISIK DAN TATA LETAK...........................................
D.1 Margin................................................................................................
D.2 Jenis dan Ukuran Huruf......................................................................
D.3 Spasi...................................................................................................
D.4 Kepala Bab dan Subbab......................................................................
D.5 Nomor Halaman.................................................................................
LAMPIRAN E PERSYARATAN FISIK DAN TATA LETAK...........................................
E.1 Margin.................................................................................................
E.2 Jenis dan Ukuran Huruf......................................................................
E.3 Spasi....................................................................................................
E.4 Kepala Bab dan Subbab......................................................................
E.5 Nomor Halaman..................................................................................
 BAB A PENDAHULUAN

Pada bab pendahuluan akan membahas terkait latar belakang penelitian,

rumusan masalah, tujuan penelitian, manfaat penelitian, serta sistematika
penulisan dari penelitian ini.

A.1 Latar Belakang

Menurut Badan Pusat Statistik (BPS, 2019), Indonesia merupakan negara
kepulauan yang banyak memanfaatkan jasa transportasi sebagai penghubung
antar wilayah, sehingga menciptakan peluang dan pasar yang besar khususnya
bagi sektor pos dan kurir modern. Seiring dengan berkembangnya teknologi,
kegiatan transaksi barang dapat dilakukan secara online dengan memanfaatkan
internet dan jasa kurir modern. Jasa pos dan kurir modern pada umumnya
memiliki layanan seperti pengiriman paket, dokumen, dan lain sebagainya.
Berdasarkan data (BPS, 2018), sejak tahun 2014 hingga 2017, Indonesia
mengalami peningkatan PDB disektor pergudangan, jasa penunjang angkutan,
pos dan kurir secara signifikan. Pada laporan Index Triwulan tahun 2019, (BPS,
2020) mengungkapkan bahwa sektor pergudangan mengalami kenaikan
eksponensial, hal ini disebabkan pertumbuhan pengguna e-commerce yang
cukup besar sejak tahun 2017. Menurut (Databoks, 2021) berdasarkan data
(Statista, 2019), tercatat jumlah pengguna e-commerce di Indonesia pada 2017
mencapai 139 juta pengguna dan diperkirakan akan mencapai 212,2 juta
pengguna pada tahun 2023.
Pada survei yang dilakukan oleh (Parcel Perform dan iPrice Group, 2019),
mengemukakan bahwa 36% konsumen melihat pengiriman sebagai masalah
paling besar dalam e-commerce. Dari 36% pelanggan yang menyatakan
ketidakpuasan, 90% di antaranya mengeluhkan tentang keterlambatan
pengiriman, waktu transit tidak memenuhi harapan, dan kurangnya komunikasi
tentang status pengiriman. Dari kumpulan fakta tersebut, disimpulkan bahwa
setiap tahunnya jumlah permintaan pengiriman barang selalu meningkat, akan
tetapi sistem distribusi dan sortir di gudang penyimpanan atau transit mengalami
kendala pada waktu dan banyaknya paket yang masuk. Selain itu peningkatan
kebutuhan jasa ekspedisi juga akan berdampak pada cepatnya proses masuk dan
keluar barang yang terjadi di gudang penyimpanan ekspedisi. Proses suplai yang
cepat ini akan mempengaruhi waktu, tenaga dan biaya yang digunakan di dalam
gudang. Meningkatnya waktu dan tenaga yang dibutuhkan untuk manajemen
persediaan akan mempengaruhi biaya operasional kerja.
Dalam jurnalnya (Koumanakos, 2008) mengatakan bahwa hampir semua
literatur tentang manajemen persediaan yang optimal menggunakan kriteria
biaya minimal dan keuntungan maksimal. Untuk itu, penting untuk memiliki
biaya persediaan yang rendah dan pada saat yang sama dapat memberikan apa
yang diinginkan konsumen. Sehingga diperlukannya solusi yang mampu
mengurangi ke tidak efisien manajemen persediaan tanpa menambah jumlah
waktu dan tenaga. Dari masalah yang ada, sangat diperlukan suatu sistem yang
21
dapat menggantikan peran manusia dalam melakukan distribusi barang di dalam
gudang.
Penulis berhipotesis sebuah solusi dari masalah ini berupa pengembangan
robot bergerak otonom dengan sistem yang saling terintegrasi. Sistem saling
terintegrasi antar robot atau dengan server akan membuat proses manajemen
persediaan gudang menjadi lebih mudah dan efisien, hal ini di uji dengan waktu
manuver dan komputasi sistem. Robot bergerak otonom memiliki tugas utama
untuk membawa barang dari proses penyortiran hingga transit di dalam gudang.
Jika proses pergudangan dikerjakan oleh robot-robot secara otomatis dan saling
terintegrasi, maka proses distribusi akan semakin cepat sehingga dengan kondisi
ini pihak ekspedisi bisa berfokus pada manajemen alur logistik dan penjadwalan.
Akan tetapi solusi dari robot ini memiliki permasalahan pada sistem
navigasinya, hal ini disebabkan sistem navigasi global tidak bisa
diimplementasikan di dalam gudang atau ruangan. Dalam tesisnya (Utomo,
2015) mengatakan bahwa permasalahan utama robot bergerak otonom terletak
pada masalah navigasi, masalah penentuan posisi dan masalah pemetaan. Robot
membutuhkan perencanaan jalur untuk navigasi, namun perencanaan jalur
hanya bisa dilakukan jika lingkungan sekitar sudah diketahui. Jadi untuk
melakukan navigasi, robot harus mampu melakukan pemetaan area kerja
terlebih dahulu sejauh batas area cakupan di dalam ruangan gudang. (Galov dan
Moschevikin, 2014) mengatakan untuk melakukan pemetaan diperlukan lokasi
robot secara akurat selama proses pemetaan yang dilakukan secara simultan.
Ketika peta sudah dibuat maka robot baru dapat melakukan penentuan jalur dan
akhirnya melakukan navigasi. Menurut (Galov dan Moschevikin, 2014; Muliady,
Sartika dan Reynaldo, 2015) proses berurut ini merupakan metode yang
dilakukan untuk permasalahan sistem robot di dalam ruangan yang memerlukan
proses simultan dalam waktu yang singkat, metode komputasi ini disebut dengan
Simultaneous Localization and Mapping (SLAM).
Ada beberapa penelitian yang dilakukan sebelumnya, penelitian yang
pertama dilakukan oleh (Utomo, 2015) dengan menggunakan Hector SLAM
sebagai algoritme pemetaan. Hasil pemetaan dari penelitian ini yang tidak begitu
baik, disebabkan sensor ultrasonik yang memiliki jangkauan pembacaan terbatas.
Penelitian kedua dilakukan oleh (Putra, Muliady dan Setiadikarunia, 2020) yang
mengimplementasikan sistem navigasi indoor berbasis ROS menggunakan Hector
SLAM dan EKF sebagai lokalisasinya. Hasil pemetaan sangat baik, akan tetapi
terdapat banyak noise sehingga pada proses navigasi, terdapat percobaan yang
gagal karena mengira noise tersebut adalah halangan. Penelitian ketiga yang
dilakukan oleh (Liu, dkk., 2021) dengan menggunakan algoritme Dijkstra dan
DWA local planner sebagai perencanaan jalur dengan peta yang dibuat
menggunakan GMapping. Keseluruhan penelitian ini berjalan dengan baik dan
kombinasi algoritme navigasi yang digunakan sangat cocok satu dengan yang
lain. Namun kekurangannya adalah proses pengujian tidak mencoba
menggunakan halangan yang bergerak jauh lebih dinamis, sehingga tidak
mengoptimalkan penggunaan perencanaan jalur lokal.

22
 Untuk itu dari permasalahan ketiga peneliti sebelumnya, penulis
mengusulkan suatu robot otonom dengan sensor laser yang memiliki pembacaan
luas serta berakurasi tinggi untuk mengimplementasikan pemetaan dan navigasi
dalam ruangan menggunakan algoritme Hector SLAM dan algoritme Dijkstra
pada platform Robot Operating System (ROS). (Utomo, 2015) menyarankan
untuk menggunakan sensor jarak yang memiliki jangkauan dengan sudut 360
derajat. Dalam bukunya (Brombach, 2021) menyarankan untuk menggunakan
Raspberry Pi 4 atau Jetson Nano 4GB sebagai kontroler utama robot karena
resource pemrosesannya yang cukup besar.
Navigasi robot menggunakan perencanaan jalur global Dijkstra untuk
mengoptimalkan waktu dan resource komputasi karena area gudang yang luas.
Kemudian sebagai tambahan, digunakan perencanaan jalur lokal dengan DWA
ketika mendeteksi halangan bergerak. Sebelum melakukan navigasi robot
membutuhkan data peta lokal, maka dari itu Hector SLAM akan berperan sebagai
pemetaan dan membuat peta lokal. Selama proses pemetaan dan navigasi
berlangsung, robot perlu mengetahui lokasi terkini secara simultan melalui
proses lokalisasi. Lokalisasi yang dipakai menggunakan dua sensor pendeteksi
percepatan, yakni sensor IMU dan odometry. Kedua sensor ini digabungkan
menggunakan algoritme EKF sekaligus melakukan koreksi kesalahan. Pada proses
navigasi, untuk mengonfirmasi posisi robot agar benar-benar presisi dan
menghindari kesalahan posisi yang besar dibutuhkan lokalisasi dengan data laser
dan peta menggunakan algoritme AMCL.
Hasil akhir dari penelitian ini adalah purwarupa robot otonom yang
digunakan di dalam gudang penyimpanan dengan mengimplementasikan proses
navigasi menggunakan peta. Harapan dari penelitian ini, agar perusahaan jasa
ekspedisi di Indonesia dapat meningkatkan efisiensi waktu, tenaga kerja dan
mengurangi biaya produksi pada proses distribusi atau sortir barang dengan
memanfaatkan pengembangan robot bergerak otonom dari hasil penelitian ini.

A.2 Rumusan Masalah

Berdasarkan latar belakang yang telah dijelaskan sebelumnya, maka rumusan
masalah dalam penelitian ini adalah sebagai berikut.
1. Bagaimana hasil akurasi dari pembacaan sensor RPLiDAR, sensor IMU dan
sensor Odometry?
2. Bagaimana hasil bentuk peta yang dihasilkan pada proses pemetaan
menggunakan algoritme Hector SLAM?
3. Bagaimana hasil akurasi dan waktu komputasi pada proses navigasi global
menggunakan algoritme Dijkstra?
4. Bagaimana hasil akurasi dan waktu komputasi pada proses navigasi global
dan lokal menggunakan gabungan algoritme Dijkstra dan DWA?
5. Apa konfigurasi parameter yang digunakan untuk mendapatkan hasil
pemetaan dan navigasi yang terbaik?

23
A.3 Tujuan
Berdasarkan rumusan masalah yang telah dijelaskan sebelumnya, maka
tujuan dari penelitian ini adalah sebagai berikut.
1. Menguji hasil akurasi dari pembacaan sensor RPLiDAR, sensor IMU dan
sensor Odometry.
2. Menguji hasil akurasi bentuk peta yang dihasilkan pada proses pemetaan
menggunakan algoritme Hector SLAM.
3. Menguji hasil akurasi dan waktu komputasi pada proses navigasi global
menggunakan algoritme Dijkstra.
4. Menguji hasil akurasi dan waktu komputasi pada proses navigasi global
dan lokal menggunakan gabungan algoritme Dijkstra dan DWA.
5. Mengetahui konfigurasi parameter yang digunakan untuk mendapatkan
hasil pemetaan dan navigasi yang terbaik.

A.4 Manfaat
Manfaat yang diharapkan adalah agar penelitian ini bisa menjadi solusi
efisien dalam proses pendistribusian barang di dalam gudang penyimpanan
ekspedisi, sehingga proses logistik pada sistem ekspedisi pengiriman paket
menjadi lebih cepat dan terotomatisasi. Purwarupa robot bergerak otonom ini
juga bisa menjadi referensi pengembang robot selanjutnya dalam pembuatan
robot secara masif karena biaya pembuatan robot yang terjangkau. Selain itu
penelitian ini juga diharapkan bermanfaat bagi akademik di lingkungan
Universitas Brawijaya sebagai referensi penggunaan middleware robot operating
system (ROS), sehingga mampu meningkatkan pengembangan robot mendekati
pengembangan perangkat lunak yang digunakan di Industri.

A.5 Batasan Masalah

Untuk menjawab rumusan masalah dan agar penelitian ini dapat
terselesaikan dengan tenggat waktu yang ada, maka peneliti akan menerapkan
batasan masalah sebagaimana berikut:
1. Penelitian berfokus pada manuver pergerakan robot untuk mampu
menjalankan sistem navigasi otomatis.
2. Robot tidak mampu menaiki tangga dan lift secara mandiri.
3. Robot tidak mampu membuka atau menutup pintu.
4. Robot hanya mampu melakukan navigasi berdasarkan koordinat tujuan
yang dikirimkan dari komputer server.
5. Robot hanya mampu membawa barang tidak lebih dari 60 kg.
6. Robot tidak mampu mendeteksi objek berupa kaca, plastik transparan, air
dan benda-benda lainnya yang mampu membelokkan cahaya infrared.

24
 7. Robot tidak mampu mendeteksi halangan yang berada di bawah dan di
atas bidang datar 2 dimensi laser sensor RPLiDAR, termasuk
tanjakan/ganjalan parkir.
8. Robot tidak mampu mendeteksi selokan, lubang besar, anak tangga, dan
permukaan yang tidak rata lainnya.
9. Robot tidak mampu mendeteksi berat atau kondisi barang yang dibawa.
10. Robot dan komputer server harus terus terhubung dengan tethering
smartphone selama proses navigasi berlangsung.

A.6 Sistematika Pembahasan

Tugas akhir skripsi ini terbagi atas tujuh bagian utama dengan penjabaran
sebagaimana berikut:
1. BAB 1: Pendahuluan
Bab ini berisi penjelasan mengenai beberapa hal yang memberitahukan
hal-hal mendasar dari sebuah penelitian, seperti latar belakang, rumusan
masalah, tujuan, manfaat, batasan masalah, dan sistematika
pembahasan.
2. BAB 2: Landasan Kepustakaan
Bab ini membahas landasan teori yang akan digunakan dalam penelitian
ini yang memiliki keterkaitan dengan robot otonom, autonomous mobile,
robot, metode pemetaan, sistem navigasi, sensor yang digunakan dan
penjelasan beberapa algoritme yang digunakan serta penjelasan
penggunaan middle ware Robot Operating System (ROS) beserta
library/framework yang digunakan sebagai penunjang dalam proses
penelitian, tentunya tidak keluar dari batasan masalah yang sudah
ditetapkan.
3. BAB 3: Metodologi
Bab ini menjelaskan tahapan apa saja yang perlu dilakukan oleh peneliti
untuk menyelesaikan permasalahan yang dibahas dalam penelitian. Bab
ini juga memuat informasi tipe penelitian apa yang diambil oleh penulis
dan juga pembahasan mengenai strategi dari penelitian.
4. BAB 4: Rekayasa Kebutuhan Sistem
Bab ini membahas penguraian kebutuhan pokok baik fungsional maupun
non fungsional mengenai mekanisme dari perancangan perangkat keras
dan perangkat lunak yang akan digunakan dalam penelitian ini.
5. BAB 5: Perancangan dan Implementasi
Bab ini berisi penjelasan mengenai proses perancangan pada sistem dan
cara pengoperasiannya sebagai jawaban dari permasalahan dan rekayasa
kebutuhan yang sudah didefinisikan sebelumnya. Terdiri dari

25
 perancangan dan implementasi perangkat keras maupun perangkat
lunak.
6. BAB 6: Pengujian dan Analisis
Bab ini membahas percobaan dari hasil perancangan dan implementasi
mengenai data dari keluaran sistem dengan bentuk pengujian yang
berbeda-beda dan melakukan analisa data dengan parameter yang
berbeda untuk bisa membandingkan tingkat akurasi dan keberhasilan
sistem.
7. BAB 7: Penutup
Bab ini berisi tentang kesimpulan yang ditarik dari hasil dari pengujian
dan analisis yang dilakukan sebelumnya dari sisi perancangan,
implementasi, dan pengujian sehingga mampu dijadikan acuan dalam
pengembangan penelitian sejenis yang terangkum dalam saran.

26
 BAB B LANDASAN KEPUSTAKAAN

Dalam bab landasan kepustakaan ini, penulis akan menjabarkan mengenai

tinjauan pustaka yang telah penulis pelajari sebelumnya dan dasar teori yang
berisikan teori pendukung penelitian ini. Adapun tinjauan pustaka adalah
sekumpulan penelitian sebelumnya yang dilakukan oleh peneliti di dunia dalam
lingkup serupa dan bagaimana hasil penelitian tersebut. Lalu mengenai dasar
teori, penulis akan menjabarkan dasar fundamental agar tercapainya tujuan
akhir penelitian ini.

B.1 Tinjauan Pustaka

Penelitian ini merupakan bentuk dari pengembangan dan gabungan dari
penelitian-penelitian sebelumnya yang berhubungan dengan metode komputasi,
pemetaan, lokalisasi, navigasi, sensor-sensor dan algoritme yang digunakan.
Tinjauan pustaka dilakukan untuk memperdalam teori dasar yang akan dibahas
dan sebagai bahan pembelajaran pada penelitian sebelumnya yang terangkum
dan tersusun ke dalam sebuah tabel yang dapat dilihat pada tabel 2.1.
Tabel 2.1 Tinjauan Penelitian Sebelumnya

Perbedaan
Tinjauan
No Persamaan
Pustaka Penelitian Rencana
Terdahulu Penelitian
1 Utomo, Eko Menggunakan Penelitian
Penelitian
Budi.2015. jenis menggunakan
menggunakan
Autonomous algoritme sensor ultrasonik,
sensor RPLiDAR,
Mobile Robot lokalisasi yang PSD,
IMU dan
Berbasis sama akselerometer,
Odometer dari
Landmark Extended sensor kamera
DYI robot beroda
Menggunakan Kalman Filter dari platform
diff-drive yang
Particle Filter (EKF) untuk robot HBE
otonom
Dan Occupancy melakukan Robocar
Grid Maps fusion pada
Pengujian
Untuk Navigasi, sensor Pengujian
dilakukan dengan
Penentuan dilakukan dengan
menunjukkan
Posisi, Dan membandingkan
hasil pemetaan
Pemetaan hasil pemetaan
dan hasil navigasi
Arsitektur akhir Arsitektur akhir
penelitian penelitian
menggunakan menggunakan
pemetaan pemetaan Hector
Occupancy grid SLAM dan
dan navigasi navigasi

27
 menggunakan
global planning
dengan Dijkstra
menggunakan dan local
Dynamic A* planning dengan
Dynamic
Windows
Approach (DWA)
Pengujian
berfokus pada
Salah satu mapping saja
Pengujian
algoritme seperti
berfokus pada hal
yang perbandingan
yang lebih luas
digunakan algoritme
seperti pengujian
sebagai mapping
Zhang, dkk. semua sensor
perbandingan menggunakan
2020. 2D LiDAR- yang digunakan
pada GMapping,
Based SLAM and hingga pemetaan,
penelitian Hector SLAM, dan
2 Path Planning navigasi dan
sama, yakni Cartographer
for Indoor lokalisasi.
Hector SLAM untuk mencari
Rescue Using hasil pemetaan
Mobile Robots yang optimal
Menggunakan
Menggunakan
platform
perangkat Menggunakan
perangkat
personal perangkat Jetson
lunak yang
komputer Nano
sama, yakni
notebook intel i5
ROS
3 Tara Anggada Penelitian Pengontrol utama Menggunakan
Putra, dkk. 2020. menggunakan robot adalah Jetson Nano dan
Navigasi Indoor metode ODROID-XU4 dan Motor Driver
Berbasis Peta pemetaan robot dikontrol Hoverboard
Pada Robot yang sama, dengan 4 buah sebagai perangkat
Beroda Dengan yakni Hector roda sebagai keras utamanya
Platform Robot SLAM penggeraknya serta
Operating menggunakan
System jenis robot
differential drive
pada kemudinya,
yakni hanya
menggunakan 2
buah roda
sebagai
penggeraknya

28
 Menggunakan
Penelitian ini Menggunakan
algoritme
menggunakan algoritme Dijkstra
Dynamic A-Star
algoritme untuk global path
untuk global path
fusion EKF, planning
planning

Penelitian ini
menggunakan Menggunakan Menggunakan
Dwiky algoritme algoritme g- algoritme Hector
Erlangga.2019. AMCL untuk mapping untuk SLAM untuk
Sistem Navigasi lokalisasi pemetaan pemetaan
Mobile Robot navigasinya
4
Dalam Ruangan
Berbasis Penelitian ini Menggunakan
Autonomous menggunakan sensor RGB-D
Menggunakan
Navigation algoritme untuk
sensor RPLiDAR
DWA untuk mendapatkan
local planner data

Menggunakan Menggunakan
Penelitian ini
robot dengan robot dengan
menggunakan
Li-sang Liu, dkk. jenis kemudi jenis kemudi
sensor
2021. Path Ackerman dengan Differential Drive
RPLiDAR
Planning for 4 roda dengan 3 roda
Smart Car Based
5 on Dijkstra Penelitian ini
Pengujian sistem
Algorithm and menggunakan Pengujian sistem
pemetaan
Dynamic algoritme pemetaan
dilakukan di
Window perencanaan dilakukan di
dalam basemen
Approach jalur yang dalam rumah
parkir dengan
sama, yaitu dengan ruangan
ruangan yang
Dijkstra dan yang sempit
sangat luas
DWA

B.1.1 Autonomous Mobile Robot Berbasis Landmark Menggunakan

Particle Filter Dan Occupancy Grid Maps Untuk Navigasi,
Penentuan Posisi, Dan Pemetaan
Penelitian yang dilakukan oleh (Utomo, 2015) mengimplementasikan
mengenai 3 proses utama dalam robot bergerak otonom yaitu navigasi, posisi
dan pemetaan. Kesimpulan yang didapatkan dari penelitian ini adalah bahwa
sensor yang terbatas seperti kamera dan ultrasonik bisa digunakan sebagai
pemetaan dan menerapkan metode SLAM. Hal ini didapat setelah melihat hasil
dari pengujian, didapati hasil berupa hasil pemetaan. Dari hasil mapping

29
menunjukkan cell occupied (warna putih) tidak berada di tepi peta. Hal ini
disebabkan karena sensor ultrasonik pada robot hanya berada di bagian depan
robot. Sedangkan di sisi kanan dan kiri pada badan robot tidak terdapat sensor
ultrasonik. Kemudian Semakin kecil jumlah partikel, diperlukan iterasi yang lebih
banyak dalam mencapai konvergen partikel (estimasi pose (𝑥, 𝑦, θ)). Lalu
Semakin banyak jumlah partikel, waktu komputasi yang diperlukan semakin
lama. Hasil dari algoritmenya Penggunaan algoritme A* dapat membantu robot
menemukan jalur terpendek dengan eror pose robot untuk data arah sebesar
4.34 % dan error jarak tempuh robot sebesar 4.8 %.

B.1.2 2D LiDAR-Based SLAM and Path Planning for Indoor Rescue Using
Mobile Robots
Penelitian yang dilakukan oleh (Zhang, dkk., 2020) mengimplementasikan 4
algoritme untuk pemetaan yakni GMapping, Hector-SLAM, Cartografer dan RGB-
D. Penelitian ini membahas mengenai pemetaan dan navigasi akan tetapi yang
lebih terlihat dengan detail adalah proses penggunaan algoritme untuk proses
Mapping. Dari pengujian yang dilakukan didapatkan kesimpulan bahwa
algoritme GMapping, Hector-SLAM dan Cartographer memiliki performa yang
baik di dalam ruangan. Sedangkan RGB-D sangat buruk karena tidak bisa
mendeteksi pada kondisi pencahayaan yang redup. Kemudian didapatkan data
bahwa GMapping dan Cartographer memiliki potensi yang sangat baik dalam
melakukan pemetaan. Terutama hasil peta yang dibuat dengan Cartographer
menghasilkan peta yang paling akurat dengan bentuk bangunan aslinya (Zhang,
dkk., 2020).

B.1.3 Navigasi Indoor Berbasis Peta Pada Robot Beroda Dengan Platform
Robot Operating System
Penelitian yang dilakukan oleh (Putra, Muliady dan Setiadikarunia, 2020)
mengimplementasikan sistem navigasi indoor berbasis peta pada robot beroda
dengan platform Robot Operating System (ROS) menggunakan algoritme Hector
Mapping untuk pemetaan. Hasilnya adalah robot berhasil melakukan pemetaan
lingkungan indoor dengan eror rata-rata 0.174 meter dan berhasil melakukan
lokalisasi dengan eror rata-rata 0.05 meter pada koordinat x, 0.028 meter pada
koordinat y, dan 1.506° pada sudut orientasi. Path planner memiliki tingkat
keberhasilan sebesar 62.5% dalam menghasilkan jalur yang dapat dilewati robot
dan tingkat keberhasilan 75% dalam mengikut jalurnya. Kesimpulan yang
didapatkan pada jurnal ini adalah bahwa pemetaan menggunakan Hector SLAM,
lokalisasi data fusion menggunakan Extended Kalman Filter (EKF), path planning
dengan Field Dynamic A-Star dan Trajectory tracking dengan pengontrol on-off
berhasil di implementasikan dengan ROS. Hasil yang didapat berupa kesimpulan
bahwa kecepatan robot berpengaruh terhadap hasil pemetaan. Lokalisasi Wheel
Odometer berhasil menentukan posisi robot dengan tingkat kesalahan kurang
dari 0.05 meter. Untuk navigasi peneliti sebelumnya menyarankan untuk
menggunakan local path planner agar robot dapat beroperasi pada lingkungan
dinamis serta menggunakan PID untuk meningkatkan performa robot.

30
B.1.4 Sistem Navigasi Mobile Robot Dalam Ruangan Berbasis
Autonomous Navigation
Penelitian yang dilakukan oleh (Erlangga, dkk., 2019) mengimplementasikan
navigasi mobile robot dalam ruangan yang menerapkan sistem kemudi otonom.
Pembuatan peta menggunakan algoritme Simultaneous Localization and
Mapping (SLAM) yang mengolah data dari sensor kamera RGB-D dan bumper
yang di konversi ke laser scan dan point cloud digunakan untuk memperoleh
perception. Sedangkan wheel encoder dan gyroscope digunakan untuk
mendapatkan data odometry yang digunakan untuk membangun peta perjalanan
dengan algoritme SLAM, GMapping dan melakukan autonomous navigation.
Sistem terdiri dari tiga sub-sistem yaitu: sensor sebagai input, single board
computer untuk proses, dan aktuator sebagai penggerak. Hasil dari pengujian
menunjukkan sistem dapat memberikan data depth yang dikonversi ke laser
scan, data bumper, dan data odometry kepada single board computer berbasis
ROS sehingga mobile robot yang dikendalikan secara Wireless dari Workstation
dapat membangun peta grid 2 dimensi dengan akurasi total error rate sebesar
0.987%. Dengan menggunakan peta, data dari sensor, dan odometry tersebut
mobile robot dapat melakukan autonomous navigation secara konsisten dan
mampu melakukan path replanning, menghindari rintangan-rintangan statis dan
terus menerus melakukan localization untuk mencapai titik tujuan.

B.1.5 Path Planning for Smart Car Based on Dijkstra Algorithm and
Dynamic Window Approach
Penelitian ini dilakukan oleh (Liu, dkk., 2021) menjelaskan mengenai
percobaan penggunaan algoritme Dijkstra dan DWA local planner sebagai
perencanaan jalur. Algoritme ini dipilih karena hasil riset yang sudah dilakukan
sebelumnya oleh peneliti. Setelah melakukan perancangan alat dan perangkat
lunak, peneliti melakukan pengujian di dalam rumah dengan kondisi ruangan
yang sempit. Hasil dari pengujian tersebut adalah halangan diam atau statis
cenderung mudah untuk dilewati dengan mudah, bahkan saat ditambahkan
halangan yang lebih banyak untuk menciptakan lingkungan lebih kompleks,
hasilnya tetap robot mampu melewati halangan dengan sangat baik. Namun
sangat disayangkan pada hasil penelitian tersebut tidak disebutkan atau tidak
dilakukan pengujian pada benda yang bergerak secara dinamis. Dari hasil
pengujiannya hanya dijelaskan bahwa benda-benda diam diletakkan di depan
robot, selanjutnya robot yang sedang diam di posisi awal diberikan koordinat
tujuan dan diharapkan mampu melewati halangan statis tersebut. Akan lebih
baik jika pengujian juga dilakukan dengan menggunakan halangan yang bergerak
secara dinamis, baik itu bergerak cepat ataupun lambat.
Berdasarkan ke-5 tinjauan pustaka di atas, dapat disimpulkan bahwa
permasalahan komputasi pada robot bergerak otonom terdiri dari 3 proses
utama, yaitu lokalisasi, pemetaan dan navigasi (Utomo, 2015, hal.1). Selain itu
pada penelitian oleh (Putra, Muliady dan Setiadikarunia, 2020) dijelaskan bahwa
sensor IMU dan Odometer akan menghasilkan nilai lokalisasi dengan kesalahan

31
yang rendah dengan bantuan algoritme fusion sensor yaitu Extended Kalman
Filter, maka dari itu berdasarkan pertimbangan hasil penelitian tersebut maka
penulis akan menerapkan metode yang sama untuk mendapatkan nilai lokalisasi
yang konsisten dan sedikit kesalahan. Kemudian pada tinjauan pustaka yang
terakhir, yakni pada penelitian yang dilakukan oleh (Liu, dkk., 2021) dapat
disimpulkan bahwa algoritme Dijkstra sebagai perencanaan global dan algoritme
DWA sebagai perencanaan lokal dapat berjalan dengan sangat baik.
Kemudian dalam pengimplementasiannya robot yang digunakan pada setiap
referensi penelitian tidak dirancang khusus untuk menjalani tugas tertentu. Pada
penelitian tersebut hanya berfokus pada metode komputasi yang digunakan
sehingga tidak memfokuskan untuk membuat robot yang bekerja secara riil.
Maka dari itu dengan penelitian ini, penulis akan melengkapi kekurangan dari
penelitian sebelumnya. Data-data dari penelitian sebelumnya akan dijadikan
sebagai metode pembanding dari apa yang penulis temukan dalam penelitian.
Penulis akan menggunakan nilai parameter terbaik yang bisa digunakan dan
tetap memperhatikan akurasi dan waktu komputasi serta penggunaan daya CPU.
Dengan demikian, penelitian ini bertujuan untuk membuat purwarupa robot riil
sesuai dengan kebutuhan yang perlukan pada distribusi gudang dibidang
ekspedisi.

B.2 Dasar Teori

Pada subbab dasar teori menjabarkan terkait teori yang digunakan dalam
melakukan penelitian, tujuannya adalah memperjelas sistematika dan kerangka
pemikiran dari fakta yang ada dalam rumusan suatu hubungan konsep dari
masing-masing ilmu pengetahuan.

B.2.1 Robot
Robot adalah alat berupa orang-orangan dan sebagainya yang dapat
bergerak (berbuat seperti manusia) yang dikendalikan oleh mesin (KBBI, 2016).
Menurut (Bekey, 2005) robot didefinisikan sebagai sebuah mesin yang mampu
merasakan, berpikir, dan bertindak. Dengan demikian, robot harus dilengkapi
dengan sensor, kemampuan pemrosesan yang meniru beberapa aspek
kecerdasan dan aktuator. (Bekey, 2005) menambahkan bahwa sensor
dibutuhkan untuk memperoleh informasi dari lingkungan, kecerdasan bawaan
diperlukan jika robot ingin melakukan tugas-tugas penting secara mandiri, dan
actuation diperlukan untuk memungkinkan robot mengerahkan kekuatan pada
lingkungan. Ilustrasi mengenai robot dapat dilihat pada gambar 2.1.

32
 Gambar 2.1 Robot Humanoid Pada Lomba RoboCup
Sumber: (www.robocupgermanopen.de, 2020)

B.2.2 Autonomous Mobile Robot (AMR)

Menurut (Bekey, 2005) autonomous robot atau robot otonom adalah mesin
cerdas yang mampu melakukan tugas di dunia sendiri, tanpa kontrol manusia
yang eksplisit. Kata otonom mengacu pada sistem yang mampu beroperasi di
lingkungan dunia nyata tanpa kontrol eksternal untuk waktu yang lama. Menurut
(Todd, 1986) mobile robot atau robot bergerak adalah mesin yang dapat
bergerak secara keseluruhan dengan cara yang terkontrol dengan beberapa
tingkat otonomi. Sebagian besar robot bergerak menggunakan roda karena
metode penggeraknya yang paling sederhana. Contoh dari robot bergerak
otonom adalah robot helikopter otonom hingga Roomba, robot penyedot debu.
Ilustrasi mengenai Roomba, robot penyedot debu dapat dilihat pada gambar 2.2.

Gambar 2.2 Robot Roomba Penyedot Debu

Sumber: (www.irobot.com, 2013)
Menurut (Bekey, 2005) robot memiliki banyak tipe dan jenis yang berbeda-
beda, banyak jenis robot yang hanya digunakan untuk proses navigasi saja
menggunakan remote control atau ada pula robot yang hanya digunakan sebagai
sistem tertutup yang memerlukan input dari manusia, jadi tidak semuanya bisa
disebut sebagai robot otonom.

33
 Gambar 2.3 Autonomous Mobile Robot
Sumber: (www.panasonic.com, 2020)
Pada gambar 2.3 dapat dilihat bahwa terdapat robot drone dan robot beroda
yang memiliki tipe penggerak yang beda namun memiliki tugas yang sama.
Menurut (Bräunl, 2008) salah satu tipe penggerak pada mobile robot adalah tipe
robot beroda differential drive. Penggerak ini terdiri dari dua roda penggerak dan
memiliki satu atau lebih roda pasif atau caster. (Bräunl, 2008) berpendapat
keuntungan dari desain penggerak differential drive adalah aksi kemudi dan
berbelok telah sepenuhnya dipisahkan dengan menggunakan dua motor yang
berbeda. Oleh karena itu, perangkat lunak kontrol untuk mengemudi akan
sangat sederhana. Kerugian dari desain ini adalah bahwa robot tidak dapat
berputar di tempat, karena roda yang digerakkan tidak terletak di tengahnya.
Menurut (Bodrenko, 2019) robot bergerak tepat digunakan pada sektor yang
mengangkut barang dalam jumlah banyak, misalnya sektor pergudangan
ekspedisi. Robot bergerak dapat dimanfaatkan pada proses distribusi ataupun
penyortiran paket kiriman.
B.2.2.1 Autonomous Mobile Robot Dibidang Pergudangan

Gambar 2.4 Penggunaan Robot Pada Gudang Logistik

Sumber: (www.ttnews.com, 2020)

34
 Mengutip dari (Zetes, 2021) perusahaan pengembang robot bergerak
otonom untuk logistik, menjelaskan bahwa robot bergerak otonom bekerja
secara kolaboratif dengan operator gudang, baik itu memindahkan stok selama
pemetikan, mengambil pengisian ulang, atau mentransfer stok massal. Robot ini
melakukan tugas dengan mengangkut barang ke tahap pemrosesan berikutnya,
dengan ini memungkinkan pekerja untuk melanjutkan ke tugas berikutnya
sehingga proses distribusi barang menjadi lebih cepat seperti yang diperlihatkan
pada gambar 2.4. Autonomous Mobile Robot (AMR) memiliki karakteristik dan
tugas utama dalam pekerjaannya, meliputi (Zetes, 2021):
a. Beroperasi secara mandiri, AMR tidak memerlukan infrastruktur khusus
untuk bekerja, seperti sebuah garis atau jalur lintasan khusus.
b. Sensor, peta, dan sistem pemrosesan terpasang memungkinkan robot
untuk merencanakan rute dan beradaptasi secara dinamis dengan
perubahan di sekitarnya.
c. AMR dapat memindahkan stok di dalam gudang atau antar fasilitas.
Robot ini juga dapat melakukan tugas rutin seperti penghitungan
inventaris dan pengecekan stok barang.

Gambar 2.5 Robot Membawa Paket Di Gudang Ekspedisi

Sumber: (www.zetes.com, 2022)
Penelitian akan mengadaptasi bentuk robot dari pergudangan yang memiliki
bagian atap dengan luas yang lebar sebagai alas atau dudukan barang. Ilustrasi
dari robot pembawa barang di dalam gudang dapat dilihat pada gambar 2.5.

B.2.3 Mekanisme Kemudi Robot Beroda

Robot beroda memiliki beberapa jenis penggerak dengan teknik yang
berbeda. Sistem penggerak yang paling sering dan umum digunakan pada robot
beroda, yaitu Single Wheel Drive, Tracked Robots, Ackerman Steering dan
Differential Drive. Namun pada penelitian ini akan digunakan sistem steering
differential drive dengan satu roda statis di bagian depan sehingga terdapat 3
buah roda, penjelasan mengenai mekanisme kemudi sebagai berikut.

35
B.2.3.1 Differential Drive Robot
Menurut (Dudek dan Jenkin, 2001) dalam bukunya, differential drive atau
penggerak diferensial adalah sistem penggerak dua roda dengan aktuator
independen untuk setiap roda. Menurut (Bräunl, 2008, hal.5) keuntungan dari
desain ini adalah motor dan roda berada pada posisi tetap dan tidak perlu
diputar, ini sangat menyederhanakan desain mekanik robot. (Dudek dan Jenkin,
2001) menjelaskan meskipun kita dapat memvariasikan kecepatan setiap roda
agar robot dapat melakukan gerakan bergulir, robot harus berputar di sekitar
titik yang terletak di sepanjang sumbu roda kiri dan kanan. Titik di mana robot
berputar dikenal sebagai ICC (Instantaneous Center of Curvature).
(Dudek dan Jenkin, 2001) juga menjelaskan bahwa variasi kecepatan kedua
roda menentukan lintasan yang diambil robot. Sistem kerja dari mekanisme
kemudi ini memanfaatkan gerak forward kinematic dengan mengandalkan
putaran independen kedua roda untuk mendapatkan manuver yang diinginkan.
Roda penggerak biasanya ditempatkan di setiap sisi robot dan mengarah ke
depan atau sebaliknya.

Gambar 2.6 Kinematics Differential Drive

Pada gambar 2.6 terdapat diagram kinematika dari differential drive.
Dikarenakan laju putaran terhadap ICC harus sama untuk kedua roda, dapat
dituliskan persamaan berikut (Dudek dan Jenkin, 2001):

( 2l )=V r
ω R+ (2.1)

ω ( R− ) =V l
l
(2.2)
2
dimana l adalah jarak dari pusat antara kedua roda, V𝑙 dan V𝑟 adalah
kecepatan roda (translasi), R merupakan jarak antara titik tengah l (l/2) jika
diukur dari salah satu roda) dan ICC yang merupakan titik dimana robot berotasi
(Dudek dan Jenkin, 2001).
Jika Persamaan (2.1) dan (2.2) digabungkan dengan persamaan v=ω R maka

R= ( L2 vrvr−vl
+ vl
) (2.3)

36
 ω= ( vr−vl
l )
(2.4)

Dari persamaan-persamaan di atas dapat ditarik beberapa hal, antara lain:

1. Jika 𝑣𝑙 = 𝑣𝑟, maka akan diperoleh gerak lurus linear ke depan.
2. Jika 𝑣𝑙 = −𝑣𝑟, maka akan diperoleh rotasi pada titik 𝑙/2 atau berputar di
tempat.
3. Jika 𝑣𝑙 = 0, maka akan diperoleh gerak poros ke kiri karena 𝑅 = 𝑙/2,
kemudian sebaliknya untuk roda kanan jika 𝑣r = 0.
Differential drive robot tidak bisa bergerak ke arah sumbu kedua roda atau
dengan kata lain, memiliki non-holonomic constraint. Selain itu, kebanyakan
differential drive robot memiliki sebuah roda tambahan yang pasif sebagai
support wheel agar lebih stabil karena kesalahan kecil dalam kecepatan relatif
antara roda dapat mempengaruhi lintasan robot. Differential drive juga sangat
sensitif terhadap variasi kecil di bidang tanah, dan mungkin memerlukan roda
caster menopangnya (Dudek dan Jenkin, 2001).

Gambar 2.7 Forward Kinematics Differential Drive

Dari gambar 2.7 digambarkan bahwa untuk mendapatkan gerak berbelok
dibutuhkan persamaan forward kinematic dengan memanipulasi parameter
kontrol V𝑙 dan V𝑟. Dengan mengetahui kecepatan V𝑙, V𝑟, dan menggunakan
persamaan 2.3 dan 2.4 kita dapat menemukan nilai ICC (Dudek dan Jenkin,
2001):
ICC =[ x−R sin(θ) , y + R cos(θ)] (2.5)
Dan pada waktu t+ δt maka pose robot menjadi:

[][ ]
x cos ( ωδt ) −sin ( ωδt ) 0
y = sin ( ωδt ) cos ( ωδt ) 0 (2.6)
θ 0 0 1
Persamaan ini secara sederhana menggambarkan gerakan robot yang
berputar sejauh R terhadap ICC dengan kecepatan sudut ω.

37
B.2.4 Autonomous Navigation

Gambar 2.8 Ilustrasi Autonomous Navigation

Sumber: (www.therobotreport.com, 2018)
Menurut (Michelson, 2017) navigasi otonom berarti bahwa kendaraan dapat
merencanakan jalurnya dan melaksanakan rencananya tanpa campur tangan
manusia. Ilustrasi mengenai autonomous navigation dapat dilihat pada gambar
2.8. Cakupan sistem penentuan posisi yang sering digunakan dalam robotika
adalah dan outdoor navigation dan indoor navigation. Namun pada penelitian
kali ini, kita akan mengimplementasikan sistem indoor navigation.
B.2.4.1 Indoor Navigation

Gambar 2.9 Aplikasi Indoor Navigation Di Dalam Mall

Sumber: (virtualrealitytimes.com, 2019)
Menurut (Rajendra, 2015) navigasi dalam ruangan adalah sistem yang
digunakan untuk menemukan lokasi yang tepat di dalam gedung. Dikutip dari
jurnal (Putra, Muliady dan Setiadikarunia, 2020), navigasi berbasis peta (map-
based navigation) merupakan salah satu metode navigasi autonomous yang bisa
diterapkan di lingkungan indoor terstruktur seperti gudang atau di dalam pusat
perbelanjaan. Ilustrasi dari pengaplikasian indoor navigation dalam pusat
perbelanjaan dapat dilihat pada gambar 2.9.

38
B.2.5 Kalman Filter untuk Lokalisasi
Dalam buku yang berjudul “ROS: Robot Programming” (Pyo, dkk., 2017)
menjelaskan bahwa Kalman Filter yang digunakan dalam proyek Apollo NASA
dikembangkan oleh Dr. Rudolf E. Kalman, yang sejak saat itu menjadi terkenal
menjadi sebuah algoritme. Filternya adalah filter recursive yang melacak keadaan
objek dalam sistem linier dengan noise. (Pyo, dkk., 2017) menambahkan bahwa
filter didasarkan pada probabilitas Bayes yang mengasumsikan model dan
menggunakan model ini untuk memprediksi keadaan saat ini dari keadaan
sebelumnya. Kemudian, kesalahan antara nilai prediksi dari langkah sebelumnya
dan nilai aktual terukur yang diperoleh oleh alat ukur digunakan untuk
melakukan langkah pembaruan untuk memperkirakan nilai keadaan yang lebih
akurat.
Berdasarkan penjelasan (Siegwart, Nourbakhsh dan Scaramuzza, 2004) di
dalam teori filter Kalman, sistem diasumsikan linier dan dengan noise Gaussian.
Teori filter Kalman didasarkan pada asumsi bahwa sistemnya linier dan bahwa
secara keseluruhan konfigurasi robot, model kesalahan odometri, dan model
kesalahan pengukuran dipengaruhi oleh noise putih Gaussian (Siegwart,
Nourbakhsh dan Scaramuzza, 2004). Menurut (Pyo, dkk., 2017) Kalman Filter
hanya dapat diaplikasikan pada sistem yang linier, sedangkan kebanyakan robot
memiliki sistem non linier. Maka dari itu dibuat sebuah varian algoritme dari
hasil modifikasi Kalman Filter yang dikenal dengan Extended Kalman Filter (EKF).
B.2.5.1 Extended Kalman Filter (EKF)
Berdasarkan penjelasan dari (Siegwart, Nourbakhsh dan Scaramuzza, 2004;
Pyo, dkk., 2017) sebelumnya, Extended Kalman Filter (EKF) adalah versi non linier
dari filter Kalman yang terlinear mengenai perkiraan rata-rata dan kovarians saat
ini. (Siegwart, Nourbakhsh dan Scaramuzza, 2004) mengatakan EKF sering
disebut sebagai algoritme fusion sensor karena dalam penggunaannya EKF
digunakan untuk menggabungkan dua buah atau lebih sensor, seperti sensor
IMU, GPS, kompas dan odometry menjadi satu output. Hasil dari algoritme ini
menghasilkan keluaran gabungan sensor yang mampu melacak posisi suatu
robot dengan mengalkulasi nilai dari setiap keluaran sensor yang dimasukkan ke
dalam parameter EKF. Algoritme lokalisasi ini bertujuan untuk mencapai tingkat
akurasi yang tinggi dan cakupan yang luas (Siegwart, Nourbakhsh dan
Scaramuzza, 2004).
(Pyo, dkk., 2017) mengatakan bahwa EKF Localization tergabung ke dalam
paket robot localization yang tersedia pada paket driver ROS dengan node
paketnya bernama ekf_localization_node. Paket ini berisi template launcher dan
file konfigurasi untuk membantu pengguna dalam melakukan lokalisasi. Untuk
penggunaannya, paket lokalisasi ini dapat digunakan pada file launch secara
langsung atau dengan membuat file config dengan extensi .yaml yang nantinya
juga di impor pada file launch (Pyo, dkk., 2017).
(Siegwart, Nourbakhsh dan Scaramuzza, 2004) menjelaskan bahwa EKF
berbasis pada proses iterasi untuk mengestimasi posisi terkini atau suatu state
39
berdasarkan informasi sebelumnya. berdasarkan informasi sebelumnya. Proses
estimasi tersebut dapat dideskripsikan sebagai sistem dinamis non linier yang
ditunjukkan pada Persamaan (2.7). Observation vector atau measurement vector
yang merupakan hasil pengukuran ditunjukkan pada Persamaan (2.8). Variabel x k
adalah state sistem robot pada waktu k , x k−1 adalah state sistem pada waktu
k −1, f adalah fungsi yang menunjukkan hubungan state sistem pada waktu k
dengan state sistem pada waktu k −1. W k −1 adalah process noise, Z k adalah
observation vector (pengukuran pada waktu k), h adalah fungsi non linier yang
mendeskripsikan hubungan antara x k dengan Z k dan V k adalah measurement
noise dengan distribusi normal (Siegwart, Nourbakhsh dan Scaramuzza, 2004).
Berikut adalah persamaan yang digunakan pada EKF.
x k =f ( x k−1+ W k−1) (2.7)
Z k =h( x k +V k ) (2.8)
(Siegwart, Nourbakhsh dan Scaramuzza, 2004) menambahkan bahwa
algoritma EKF terdiri dari 2 fase, yaitu state predict dan state update. Dalam
bukunya (Siegwart, Nourbakhsh dan Scaramuzza, 2004) menjelaskan State
predict merupakan fase prediksi terhadap informasi priori state vector ^x k dengan
menggunakan informasi posteriori state vector x k−1. Pada fase ini informasi priori
state vector diperbaiki dengan menggunakan observation vector dan Fase state
predict ditunjukkan oleh Persamaan 2.9 dan Persamaan 2.10 serta fase state
update ditunjukkan oleh Persamaan 2.11, Persamaan 2.12, dan Persamaan 2.13
(Siegwart, Nourbakhsh dan Scaramuzza, 2004).
^
x k =f (x k−1) (2.9)
^ T
Pk =F Pk−1 F +Q (2.10)
^k H (H P
K= P ^k H + R)
T T −1
(2.11)
x k = x^k + K ( z k − H x^k ) (2.12)
Pk =(1−KH ) ^
T T
Pk (1−KH ) + KRK (2.13)
Tabel 2.2 Penjelasan Variabel Persamaan Fungsi EKF
Sumber: (Siegwart, Nourbakhsh dan Scaramuzza, 2004)
No Notasi Keterangan
1 xk
^ Hasil prediksi state sistem (priori state vector)
2 Pk Kovariansi error sistem pada waktu k
3 Pk−1 Kovariansi error pada waktu k-1
4 ^
Pk Hasil prediksi kovariansi error
5 F Matriks Jacobian dari f
6 Q Process noise covariance
7 K Kalman gain
40
 8 H Matriks Jacobian dari h
9 R Kovariansi pengukuran

B.2.6 Simultaneous Localization And Mapping (SLAM)

Menurut (Pyo, dkk., 2017) SLAM (Simultaneous Localization And Mapping)
artinya menjelajahi dan memetakan lingkungan yang tidak diketahui sambil
memperkirakan pose robot itu sendiri dengan menggunakan sensor yang
terpasang pada robot. (Pyo, dkk., 2017) juga menambahkan bahwa SLAM
dikembangkan untuk memungkinkan robot membuat peta dengan atau tanpa
bantuan manusia. Ini adalah metode membuat peta saat robot menjelajahi
ruang yang tidak diketahui dan mendeteksi sekitarnya dan memperkirakan
lokasinya saat ini serta membuat peta.
Menurut (Siegwart, Nourbakhsh dan Scaramuzza, 2004) tujuan SLAM adalah
untuk memulihkan jalur robot dan peta lingkungan hanya dengan menggunakan
data yang dikumpulkan oleh sensor proprioceptive dan exteroception. Data ini
biasanya adalah perpindahan robot yang diperkirakan dari odometri dan fitur
(misalnya, sudut, garis, bidang) yang diekstraksi dari gambar laser, ultrasonik,
atau kamera. Menurut (Birk dan Pfingsthorn, 2016; Siegwart, Nourbakhsh dan
Scaramuzza, 2004) SLAM berurusan dengan masalah ayam dan telur dalam
membangun peta. Untuk melakukan pemetaan dibutuhkan pembaharuan lokasi
robot terkini secara simultan. Sedangkan untuk melakukan pembaharuan lokasi
dibutuhkan data peta dari hasil pemetaan. Istilah SLAM digunakan untuk
masalah itu sendiri serta untuk solusi algoritme yang mencoba menyelesaikan
permasalahan seperti yang di ilustrasikan pada gambar 2.10.

Gambar 2.10 Ilustrasi Permasalahan Komputasi SLAM

Sumber: (arreverie.com, 2018)
Dikutip dari (Birk dan Pfingsthorn, 2016) pada prinsipnya ada dua cara
berbeda di mana pengamatan lingkungan dapat dimasukkan ke dalam metode
SLAM yang dapat dilihat pada gambar 2.11. Cara pertama, yakni sensor dapat
mengenali lingkungan dan melokalisasi landmark alami, yaitu fitur pengenalan
lingkungan yang dapat diidentifikasi di lokasi yang tetap. Ini dapat menjadi
tempat yang berbeda secara visual di lingkungan yang terdeteksi dan dilokalisasi
melalui kamera stereo pada robot (Birk dan Pfingsthorn, 2016).

41
Gambar 2.11 SLAM Dengan Cara Landmark Observation dan Cara Sensor View
Sumber: (Birk dan Pfingsthorn, 2016)
(Birk dan Pfingsthorn, 2016) melanjutkan pada cara kedua, yakni
menggunakan opsi untuk menggunakan registrasi, yaitu metode yang
menyelaraskan data sensor secara spasial berdasarkan isi data sensor. Misalnya,
laser range finder (LRF) memindai sektor lingkungan untuk menghasilkan profil
jangkauan ke rintangan terdekat. Dua pemindaian berikutnya kemudian dapat
didaftarkan dengan menemukan transformasi spasial dan karenanya gerakan
relatif x t dari robot yang mengarah ke kecocokan terbaik dari dua pemindaian.
Pemilihan cara bertujuan menghasilkan bentuk peta yang sama, akan tetapi
perbedaan cara akan menentukan bentuk algoritma SLAM mana yang paling
cocok untuk memecahkan masalah (Birk dan Pfingsthorn, 2016).
Menurut (Birk dan Pfingsthorn, 2016) Implementasi sistem SLAM biasanya
dibagi menjadi dua bagian utama, yaitu frontend dan backend. Frontend
berurusan dengan metode khusus aplikasi yang menghasilkan batasan spasial,
masing-masing mendeteksi dan melokalisasi landmark yang kemudian dipelihara
dan dioptimalkan di backend dengan algoritme generik. Sedangkan backend
adalah inti komputasi dari sistem SLAM di mana optimasi generik terjadi.
Backend juga digunakan untuk memitigasi dan mengurangi kesalahan pada lokasi
(Birk dan Pfingsthorn, 2016). Penelitian ini akan menggunakan metode dari cara
kedua, yakni dengan menggunakan data laser untuk mendapatkan sensor view
dan menggunakan sensor Inertia Measurement Unit untuk melakukan motion
estimate agar pemetaan dapat berjalan dengan baik.

42
B.2.6.1 Occupancy Grid Map

Gambar 2.12 Occupancy Map Terletak Pada Pixel Warna Hitam

Sumber: (Pyo, dkk., 2017)
Menurut (Pyo, dkk., 2017) map atau peta digambar berdasarkan odometri
robot, informasi tf, dan informasi pemindaian sensor saat robot bergerak. Pada
gambar 2.12 dapat dilihat bahwa area di peta diwakili oleh nilai skala abu-abu
yang berkisar dari '0' hingga '255'. (Pyo, dkk., 2017) mengatakan bahwa nilai ini
diperoleh melalui probabilitas posterior dari teorema Bayes, yang menghitung
probabilitas hunian yang mewakili status hunian. Probabilitas hunian 'occ'
dinyatakan sebagai 'occ = (255 - color_avg) / 255.0'. Jika gambar 24 bit,
'color_avg = (nilai skala abu-abu satu sel / 0xFFFFFF x 255)'. Semakin dekat 'occ'
ini ke 1, semakin tinggi kemungkinannya ditempati. Sedangkan semakin dekat
‘occ’ ke '0', maka semakin kecil kemungkinannya untuk ditempati (Pyo, dkk.,
2017).
(Pyo, dkk., 2017) menjelaskan ketika probabilitas hunian dipublikasikan
sebagai pesan ROS (nav_msgs/OccupancyGrid), itu didefinisikan ulang menjadi
bilangan bulat [0 ~ 100]. Area yang dekat dengan '0' adalah area bebas yang
didefinisikan sebagai area yang tidak dihuni sedangkan '100' didefinisikan
sebagai area yang ditempati, dan '-1' secara khusus didefinisikan untuk area yang
tidak diketahui (Pyo, dkk., 2017).

B.2.7 Hector Simultaneous Localization and Mapping (Hector SLAM)

Mengutip dari (Manuel dan Ferrão, 2018), dijelaskan bahwa Hector SLAM
adalah algoritma SLAM yang dikembangkan oleh tim HECTOR (Heterogeneous
Cooperating Team of Robots) di Universitas Darmstadt untuk digunakan pada
Robot Darat Tak Berawak, Kendaraan Permukaan Tak Berawak, Perangkat
Pemetaan genggam dan data log dari UAV quadrotor. Menurut (Kohlbrecher,
dkk., 2014) Hector SLAM berisi sekumpulan paket ROS yang digunakan untuk
melakukan komputasi SLAM dengan mengkorelasikan perkiraan posisi robot dan
peta di lingkungan yang tidak terstruktur.

43
 (Manuel dan Ferrão, 2018) menambahkan bahwa Hector SLAM
bertentangan dengan solusi SLAM lainnya karena tidak dibagi menjadi front-end
dan back-end. Metode hanya berfungsi sebagai front-end dan tidak didasarkan
pada grafik atau tidak menyediakan teknik pengoptimalan global apa pun.
Pendekatan yang digunakan untuk pencocokan pemindaian didasarkan pada
optimasi penyelarasan titik laser dengan peta grid dengan menggunakan
pengoptimalan berbasis Gauss-Newton dan data baru dari laser ditulis langsung
ke peta grid setelah diterima (Manuel dan Ferrão, 2018). Hector SLAM tidak
menyediakan kemampuan penutupan loop eksplisit, sehingga bergantung pada
penyelarasan dan pengoptimalan data yang berkelanjutan (Manuel dan Ferrão,
2018).
(Manuel dan Ferrão, 2018) berpendapat untuk mengurangi risiko terjebak
dalam minimum lokal selama pengoptimalan gradien naik, Hector SLAM
menggunakan pendekatan peta multi-resolution. Beberapa peta dibuat dengan
resolusi berbeda yang diatur dalam piramida, setiap tingkat piramida memiliki
setengah resolusi dari tingkat sebelumnya. Gambar 2.13 menyajikan hasil
pemetaan simultan multiresolution Hector SLAM.

Gambar 2.13 Representasi Multiresolution Dari Sel Petak Peta Hector SLAM
Sumber: (Kohlbrecher, dkk., 2011)
Mengutip dari (Kohlbrecher, dkk., 2011) menjelaskan bahwa pada Hector
SLAM terdapat proses utama untuk pembuatan peta, yaitu Hector Mapping.
Hector Mapping memanfaatkan sistem LiDAR dengan frekuensi tinggi tanpa
menggunakan informasi Odometry (Kohlbrecher, dkk., 2011). Pada jurnalnya
(Kohlbrecher, dkk., 2011) mengatakan bahwa Hector Mapping menggunakan
algoritma scan matching yang dikembangkan dengan cara menyelaraskan data
dari sensor untuk membangun peta. Scan matching adalah proses
menyelaraskan hasil pemindaian (pengukuran jarak) pada waktu t dengan LIDAR
dengan hasil pemindaian pada waktu t - 1 yang bertujuan untuk memperoleh
posisi robot untuk kemudian memperbarui peta (Kohlbrecher, dkk., 2011).
Pada jurnal lainnya (Kohlbrecher, dkk., 2014) menjelaskan lebih lanjut
mengenai Hector SLAM, hector mapping, hector geotiff, dan lain-lain beserta alur
proses yang terjadi di dalamnya pada skema yang terdapat pada gambar 2.14.

44
 Gambar 2.14 Skema Sistem Hector SLAM
Sumber : (Kohlbrecher, dkk., 2014)
Seperti yang dapat dilihat pada gambar 2.14, (Kohlbrecher, dkk., 2014)
menjelaskan bahwa skema Hector SLAM selalu melakukan reset pada awalnya.
Diagram persegi panjang melambangkan semua node yang memegang semacam
informasi status berlangganan topik perintah yang terutama digunakan untuk
mengatur ulang sistem kapan pun diperlukan. Pada proses mapping terdapat tiga
masukkan berupa tf (transformation), laser scan dan reset. Data laser scan
didapat dari sensor laser lidar, misalnya sensor RPLiDAR, sedangkan tf didapat
dari node tf yang terdapat pada file launch atau konfigurasi EKF. Output dari
mapping menghasilkan 2D map yang langsung di proses oleh map server
(Kohlbrecher, dkk., 2014). Output yang disimpan dari map server akan disimpan
pada geotiff dan menghasilkan object tracker.
(Kohlbrecher, dkk., 2014) menjelaskan bahwa hasil dari mapping juga
menghasilkan 2D pose yang dikirimkan ke proses pose estimation yang nantinya
digunakan trajectory server untuk menyimpan jalur path yang sudah dilalui
robot. Jika ingin melakukan navigasi, bisa dengan menambahkan paket
move_base yang nantinya membuat robot memperhitungkan cost mapping dan
mampu membuat exploration planner sehingga akhirnya pendapat kan path
yang bebas dari halangan dan memerintahkan motor untuk berputar
(Kohlbrecher, dkk., 2014). Node yang terpenting pada proses ini adalah mapping
dan geotiff yang mana dua node ini merupakan proses utama untuk membuat
peta menggunakan Hector SLAM. Maka dari itu pada sub bab selanjutnya akan
dijelaskan hector mapping dan hector geotiff.
B.2.7.1 Hector Mapping
Seperti yang telah dijelaskan sebelumnya pada jurnal (Kohlbrecher, dkk.,
2011), bahwa Mapping dengan hector adalah pendekatan SLAM yang dapat
digunakan tanpa odometry serta pada platform yang menunjukkan gerakan
roll/pitch (dari sensor, platform, atau keduanya). Dikombinasikan dengan

45
attitude estimation system dan opsi unit pitch/roll untuk menstabilkan pemindai
laser, sistem ini dapat menyediakan peta lingkungan bahkan jika tanahnya tidak
datar seperti yang ditemui di arena Penyelamatan RoboCup (Kohlbrecher, dkk.,
2014).
Dalam jurnalnya (Kohlbrecher, dkk., 2011) terdapat beberapa persamaan
yang menjadi formula utama pada proses pemetaan dengan Hector Mapping. Di
jelaskan bahwa metode scan matching pada Hector Mapping berbasis pada
pendekatan Gauss- Newton. (Kohlbrecher, dkk., 2011) menambahkan bahwa
perpindahan posisi robot dihitung dengan Persamaan (2.14) dan nilai H dihitung
dengan Persamaan (2.15). Untuk mengetahui penjelasan lebih lanjut mengenai
kegunaan atau fungsi dari setiap variabel dapat dilihat pada tabel 2.3.

[ ][
T
r
∂ S (ξ)
∆ ξ=H −1
∑ ∇ M (Si ( ξ)) i
∂ξ
1−M ( Si (ξ )) ] (2.14)
i=1

[ ][ ]
T
r
∂ S i (ξ) ∂ S i (ξ )
H =∑ ∇ M ( Si ( ξ)) ∇ M (S i (ξ)) (2.15)
i=1 ∂ξ ∂ξ
Tabel 2.3 Penjelasan Variabel Persamaan Fungsi Hector Mapping
Sumber: (Kohlbrecher, dkk., 2011)
No Notasi Keterangan
Perpindahan posisi robot dalam koordinat
1 ∆ξ
Kartesian (x, y, θ)
2 r Jumlah titik pemindaian LIDAR
Koordinat-koordinat hasil pemindaian LiDAR
3 Si (ξ )
berdasarkan posisi robot ξ ( x , y , θ)
4 M (Si (ξ )) Probabilitas adanya halangan pada Si (ξ )

B.2.7.2 Hector Geotiff

Hector Geotiff adalah node yang dapat digunakan untuk menyimpan peta
jaringan hunian, lintasan robot, dan data objek yang diinginkan ke peta format
Geotiff dengan informasi georeferencing. Sedangkan peta Geotiff adalah gambar
peta dengan bentuk berupa data occupancy grid berisikan data free space dan
obstacle. Dalam ROS Geotiff digunakan sebagai format standar untuk peta, jadi
bukan format gambar biasa seperti JPEG atau PNG melainkan Geotiff dengan
extensi format .pgm. Node ini dapat berjalan di atas sistem robot dan
menyimpan peta ke penyimpanan permanen berdasarkan pengatur waktu,
mengurangi kemungkinan hilangnya peta jika terjadi masalah konektivitas.

B.2.8 Navigasi
Menurut (Pyo, dkk., 2017) navigasi adalah memindahkan robot dari satu
lokasi ke tujuan yang ditentukan dalam lingkungan tertentu. Untuk tujuan ini,
peta yang berisi informasi geometri furnitur, benda, dan dinding dari lingkungan
46
yang diberikan diperlukan. Seperti yang dijelaskan pada bagian SLAM
sebelumnya, peta dibuat dengan informasi jarak yang diperoleh sensor dan
informasi pose robot itu sendiri. Sedangkan untuk pengertian navigasi dikutip
dari penelitian (Utomo, 2015) dalam tesisnya mengatakan navigasi diartikan
sebagai proses atau aktivitas untuk merencanakan atau menuju jalur secara
langsung dalam sebuah misi yang diberikan pada sebuah autonomous mobile
robot dari satu tempat ke tempat yang lain tanpa kehilangan arah atau
mengalami tabrakan dengan objek. (Pyo, dkk., 2017) menjelaskan bahwa
navigasi memungkinkan robot untuk berpindah dari pose saat ini ke pose tujuan
yang ditentukan di peta dengan menggunakan peta, encoder robot, sensor
inersia, dan sensor jarak.

Gambar 2.15 Hubungan Antara Node dan Topik Pada Konfigurasi Navigasi
Sumber: (Pyo, dkk., 2017)
Pada gambar 2.15 terdapat diagram transformasi yang menyusun proses
navigasi pada sebuah robot. Proses utama yang terjadi pada navigasi terletak
pada bagian diagram tertutup (kotak) dengan melakukan beberapa pengambilan
data dari node lain (Pyo, dkk., 2017).
(Pyo, dkk., 2017) juga menambahkan bahwa, dalam navigasi terdapat suatu
peta biaya atau costmap yang membuat proses navigasi terhindar dari tabrakan,
tidak lupa AMCL untuk lokalisasi robot. Selain itu terdapat pula sistem
perencanaan jalur (path planning) untuk mencari jalur terpendek dari posisi saat
ini menuju posisi tujuan.
B.2.8.1 Costmap
Dalam bukunya (Pyo, dkk., 2017) menjelaskan bahwa dalam navigasi, peta
biaya atau costmap dipakai untuk menghitung area rintangan, kemungkinan area
tabrakan, dan robot yang dapat dipindahkan daerah berdasarkan empat faktor.
Faktor tersebut adalah peta statis, manfaatkan area yang diduduki, area bebas,
dan area yang tidak diketahui untuk navigasi. Costmap dapat dibagi menjadi dua,
salah satunya adalah 'global_costmap', yang menyiapkan rencana jalur untuk
bernavigasi di area global peta tetap. Yang lainnya adalah 'local_costmap' yang
digunakan untuk perencanaan jalur dan penghindaran rintangan di area terbatas

47
di sekitar robot. Meskipun tujuannya berbeda, kedua peta biaya
direpresentasikan dengan cara yang sama (Pyo, dkk., 2017).
(Pyo, dkk., 2017) menjelaskan bahwa peta biaya dinyatakan sebagai nilai
antara '0' dan '255'. Nilai digunakan untuk mengidentifikasi apakah robot dapat
bergerak atau bertabrakan dengan rintangan. Perhitungan setiap area
tergantung pada parameter konfigurasi costmap yang dapat diubah oleh
pengembang. Nilai tersebut sebagai berikut (Pyo, dkk., 2017):
1. 000: Area bebas di mana robot dapat bergerak bebas
2. 001~127: Area dengan kemungkinan tabrakan rendah
3. 128~252: Area dengan kemungkinan tabrakan tinggi
4. 253~254: Area tabrakan
5. 255: Area pendudukan di mana robot tidak bisa bergerak

Gambar 2.16 Hubungan Antara Jarak ke Rintangan dan Nilai Costmap

Sumber: (Pyo, dkk., 2017)
Sebagai contoh pada gambar 2.16, terdapat model robot di tengah dan
kotak persegi panjang di sekelilingnya sesuai dengan permukaan luar robot.
Ketika garis outline ini menyentuh dinding, robot akan menabrak dinding juga
(Pyo, dkk., 2017). Warna hijau mewakili hambatan dengan nilai sensor jarak yang
diperoleh dari sensor laser. Sebagai costmap skala abu-abu menjadi lebih gelap,
lebih cenderung menjadi area tabrakan. Jadi robot tidak akan mendekati bagian
yang cenderung gelap atau hitam karena costmap sudah menganggap bahwa
daerah tersebut rawan terjadi tabrakan (Pyo, dkk., 2017).

48
 Gambar 2.17 Representasi Costmap
Sumber: (Pyo, dkk., 2017)
B.2.8.2 Adaptive Monte Carlo Localization (AMCL)
Mengutip dari (Pyo, dkk., 2017) menjelaskan bahwa AMCL (Adaptive Monte
Carlo Localization) adalah algoritme untuk menentukan di mana robot berada di
lingkungan tertentu. Metode ini dapat dianggap sebagai versi perbaikan dari
estimasi pose Monte Carlo, yang meningkatkan kinerja waktu nyata dengan
mengurangi waktu eksekusi dengan jumlah sampel yang lebih sedikit dalam
algoritma estimasi pose Monte Carlo. (Pyo, dkk., 2017) mengatakan AMCL
menggunakan metode particle filter yang merupakan metode lokalisasi dengan
menggunakan data jarak dari laser.
AMCL menggunakan beberapa persamaan pada prosesnya, seperti posterior
probability menggunakan Bayes, generate dengan particle filter dan sampling
and resampling untuk mendapatkan lokasi dengan presisi. Dengan mengulangi
proses SIR (Sampling Importance weighting Re-sampling) sambil menggerakkan
partikel, perkiraan posisi robot meningkat akurasinya (Pyo, dkk., 2017).

B.2.9 Path Planning

Mengutip dari (Pyo, dkk., 2017), dijelaskan bahwa path planning atau
perencanaan jalur adalah metode komputasi untuk menciptakan lintasan dari
pose saat ini ke pose target yang ditentukan pada peta. Rencana jalur yang
dibuat mencakup perencanaan jalur global di seluruh peta dan perencanaan jalur
lokal untuk area yang lebih kecil di sekitar robot. Terdapat 2 hal pada
perencanaan jalur, yakni global plan dan local plan (Pyo, dkk., 2017).
B.2.9.1 Global Plan
Menurut (Pyo, dkk., 2017) perencanaan global adalah metode dalam
membuat jalur global ke target utama untuk menggerakkan robot. (Marin-Plaza,
dkk., 2018) menjelaskan bahwa global plan membutuhkan peta lingkungan untuk
49
menghitung rute terbaik. Maka dari itu diperlukan peta sebelum melakukan
navigasi dengan global plan.
B.2.9.2 Local Plan
Local planner atau perencana lokal merupakan metode untuk mengubah
jalur global menjadi perencanaan jalan lokal yang sesuai dengan kondisi sekitar
(Marin-Plaza, dkk., 2018). Menurut (Pyo, dkk., 2017) perencanaan lokal
menggunakan informasi odometry untuk melihat kecepatan robot agar mampu
menghindari halangan pada perencanaan jalur global.

B.2.10 Algoritme Dijkstra

Menurut (Bräunl, 2008) Dijkstra adalah algoritme untuk menghitung semua
jalur terpendek dari node awal yang diberikan dalam grafik yang terhubung
penuh. Algoritme ini ditemukan oleh (Dijkstra, 1959) yang ditujukan untuk
menyelesaikan dua masalah dalam suatu hubungan grafik. (Siegwart,
Nourbakhsh dan Scaramuzza, 2004) menjelaskan bahwa dalam aplikasi robot,
pencarian Dijkstra biasanya dihitung dari tujuan robot posisi. Akibatnya, tidak
hanya jalur terbaik dari node awal ke tujuan yang dihitung, tetapi juga semua
jalur biaya terendah dari setiap posisi awal dalam grafik ke node tujuan.
Algoritme ini sering digunakan dalam perangkat GPS untuk menemukan jalur
terpendek antara lokasi saat ini dan tujuan (Siegwart, Nourbakhsh dan
Scaramuzza, 2004).

Gambar 2.18 Perencanaan Jalur Terpendek Menggunakan Algoritme Dijkstra

Sumber: (www.programiz.com, 2020)
Pada gambar 2.18 dapat dilihat bahwa algoritme Dijkstra biasanya
digunakan pada perencanaan jalur menggunakan GPS atau Global Positioning
System. Pada penelitian ini, Dijkstra dijadikan algoritme perencanaan jalur
menggunakan sistem global dengan menggunakan hasil peta dari proses
pemetaan menggunakan (Dijkstra, 1959).

50
 Gambar 2.19 Grid Map Hasil Pemetaan
Tidak seperti layaknya GPS, sistem lokalisasi indoor tidak memiliki peta
semesta seukuran bumi. Maka dari itu perlu dibuat sebuah peta semesta dengan
ukuran terbatas sesuai dengan area kerja robot. Peta ini merupakan bentuk dari
proses mapping dan menghasilkan berupa file Geotiff dengan bentuk Grid Map.
Pada gambar 2.19 terlihat ilustrasi dari proses path planning dari kotak biru
menuju kotak merah. Terdapat banyak kemungkinan jalur yang akan dituju,
robot tidak mengetahui mana jalur terpendek dan bagaimana mengambil
keputusan untuk melewati suatu jalur. Maka dari itu diperlukan sebuah
perencanaan global yang menghitung dimana jarak terpendek dari titik awal
menuju titik tujuan (Bräunl, 2008).
B.2.10.1 Implementasi algoritme Dijkstra
Algoritme Dijkstra terdiri dari beberapa tahapan berupa langkah-langkah
secara sistematis, antara lain sebagai berikut (Dijkstra, 1959; Bräunl, 2008):
1. Tandai simpul awal Anda dengan g_cost 0, tambahkan simpul awal Anda
ke open_list
Fase pertama:
Ulangi yang berikut ini saat open_list tidak kosong:
2. Ekstrak node dengan g_cost terkecil dari open_list dan beri nama
current_node.
3. Tandai sebagai dikunjungi dengan menambahkannya ke closed_list.
4. Periksa apakah current_node adalah node target, jika demikian lanjutkan
ke fase II, jika tidak lanjutkan dengan langkah 5
5. Temukan tetangga dari current_node
For each untuk setiap node dalam daftar tetangga current_node:

51
 6. Jika tetangga ada di dalam closed_list, lewati dan pilih tetangga
berikutnya
7. Jika tetangga ada di dalam open_list:
o Jika nilai g_cost baru lebih kecil dari nilai g_cost saat ini:
 Perbarui g_cost tersebut
 Perbarui simpul induknya
8. Jika tetangga tidak ada di dalam open_list:
o Setel g_cost
o Setel node induknya
o Tambahkan ke open_list
Ketika kita selesai mempertimbangkan semua tetangga dari current_node
lanjutkan ke langkah 2.
Fase kedua:
Membangun jalan dari awal sampai akhir.
1. Telusuri kembali dari node target ke node awal, menggunakan node induk
setiap node
Bentuk sederhana dari hasil implementasi ini adalah berupa pseudocode pada
tabel 2.4.
Tabel 2.4 Pseudocode Algoritme Dijkstra
1 BEGIN dijkstra(G, S)
2 for each vertex V in G
3 distance[V] <- infinite
4 previous[V] <- NULL
5 If V != S, add V to Priority Queue Q
6 distance[S] <- 0
7
8 while Q IS NOT EMPTY
9 U <- Extract MIN from Q
10 for each unvisited neighbour V of U
11 tempDistance <- distance[U] + edge_weight(U, V)
12 if tempDistance < distance[V]
13 distance[V] <- tempDistance
14 previous[V] <- U
15 return distance[], previous[]
16 END

Setelah melakukan perencanaan jalur maka robot sudah dapat melakukan

navigasi. Dengan memanfaatkan data dari peta dan tangkapan sensor maka
robot bisa bernavigasi dengan lancar dan mampu menghindari halangan.

52
B.2.11 Algoritma Dynamic Window Approach (DWA)
Menurut (Pyo, dkk., 2017) Dynamic Window Approach (DWA) adalah
metode populer untuk perencanaan penghindaran rintangan dan menghindari
rintangan. Ini adalah metode pemilihan kecepatan yang dapat dengan cepat
mencapai titik target sambil menghindari rintangan yang mungkin dapat
bertabrakan dengan robot di ruang pencarian kecepatan. (Pyo, dkk., 2017)
menjelaskan di ROS, Perencana lintasan digunakan untuk perencanaan jalur
lokal, tetapi DWA diganti karena kinerjanya yang unggul.

Gambar 2.20 Ruang Pencarian Kecepatan Robot dan Dynamic Window

Sumber: (Pyo, dkk., 2017)
Pertama, robot tidak berada pada koordinat sumbu x dan y, tetapi pada
ruang pencarian kecepatan dengan kecepatan translasi v dan kecepatan rotasi
sebagai sumbunya, seperti terlihat pada gambar 2.20. Di ruang ini, robot
memiliki kecepatan maksimum yang diizinkan karena keterbatasan perangkat
keras, dan ini disebut Jendela Dinamis. Berikut ini adalah persamaan yang
digunakan pada DWA (Pyo, dkk., 2017):
G(v, ω)=σ (α × heading (v , ω)+ β × dist ( v , ω)+ γ × velocity( v , ω))
Yang merupakan fungsi utama dari DWA, mengenai penjelasan dari setiap
variabel dapat dilihat pada tabel 2.5.
Tabel 2.5 Persamaan pada Dynamic Window Approach
Sumber: (Pyo, dkk., 2017)
No Notasi Keterangan
1 v Kecepatan translasi (meter/detik)
2 ω Kecepatan rotasi (radian/dtk)
3 Vs Area kecepatan maksimum
4 Va Area kecepatan yang diizinkan
5 Vc Kecepatan arus
6 Vr Area kecepatan di Dynamic Window
7 a max Tingkat akselerasi / deselerasi maksimum
8 heading( v , ω ) 180 - (selisih antara arah robot dan arah titik
53
 target)
9 dist( v , ω) Jarak ke rintangan
10 velocity( v , ω) Kecepatan yang dipilih
11 α , β, γ Konstanta pembobotan
12 σ (x) Fungsi Halus

Gambar 2.21 Kecepatan translasi v dan kecepatan rotasi w

Sumber: (Pyo, dkk., 2017)
(Pyo, dkk., 2017) mengatakan bahwa dalam DWA, fungsi tujuan G(v, ω)
digunakan untuk menghitung translasi kecepatan v dan kecepatan rotasi ω yang
memaksimalkan fungsi objektif yang mempertimbangkan arah, kecepatan dan
tubrukan. Jika kita plot, kita dapat menemukan kecepatan optimal di antara
berbagai opsi v dan ω ke tujuan seperti yang ditunjukkan pada gambar 2.21
Akan lebih mudah untuk menjelaskan alur proses algoritma ini jika kita
melihat kodenya terlebih dahulu dalam pseudocode DWA pada tabel 2.6 sebagai
berikut (Pyo, dkk., 2017):
Tabel 2.6 Pseudocode Dynamic Window Approach
1 BEGIN DWA(robotPose,robotGoal,robotModel)
2 desiredV = calculateV(robotPose,robotGoal)
3 laserscan = readScanner()
4 allowable_v = generateWindow(robotV, robotModel)
5 allowable_w = generateWindow(robotW, robotModel)
6 for each v in allowable_v
7 for each w in allowable_w
8 dist = find_dist(v,w,laserscan,robotModel)
9 breakDist = calculateBreakingDistance(v)
10 if (dist > breakDist) //can stop in time
11 heading = hDiff(robotPose,goalPose, v,w)

54
 12 clearance = (dist-breakDist)/(dmax - breakDist)
13 cost = costFunction(heading,clearance,
14 abs(desired_v - v))
15 if (cost > optimal)
16 best_v = v
17 best_w = w
18 optimal = cost
19 set robot trajectory to best_v, best_w
20 END

B.2.12 Komponen Utama Robot

Komponen utama robot pengantar barang berisikan alat-alat yang
digunakan guna membangun sistem robot ini. Pada sub bab ini akan dijelaskan
spesifikasi dan pengertian dari setiap komponen yang digunakan. Berikut ini
adalah komponen utama yang dibutuhkan dalam membuat robot pengantar
barang.
B.2.12.1 Motor Driver Motherboard Hoverboard
Menurut (Joseph, 2018) driver motor adalah papan sirkuit elektronik yang
menyesuaikan kecepatan motor dengan memasukkan sinyal modulasi lebar-
pulsa (PWM) sebagai input. Menurut (Reilly, 2003) motherboard adalah papan
logika utamanya yang berisi unit pemrosesan pusat dan chip memori. Pada
penelitian ini, motherboard hoverboard digunakan sebagai mainboard atau
papan pemrosesan utama dari robot sekaligus sebagai driver motor dc. Di dalam
motherboard terdapat chip mikroprosesor dengan seri GD32F103RCT6 yang
digunakan sebagai otak dari kontroler sekaligus sebagai driver untuk mengontrol
kecepatan dan arah putaran roda. Gambar 2.22 merupakan gambar
motherboard hoverboard.

Gambar 2.22 Motherboard Hoverboard

Sumber: (github.com/EFeru/hoverboard-firmware-hack-FOC, 2021)

55
 Perlu diperhatikan bahwa motherboard hoverboard memiliki tipe dan
bentuk yang berbeda-beda. Pada penelitian ini digunakan motherboard
hoverboard dengan tipe single motherboard dan berbentuk seperti pada
gambar 2.22. Hal ini perlu diperhatikan karena penggunaan selain single
motherboard akan sangat menyulitkan proses flashing firmware karena
perbedaan port dan fabrikasi. Misalnya saja dual board motherboard pada
gambar 2.24 yang memiliki port flashing di kedua board, jadi selalu gunakan
single motherboard.

Gambar 2.23 Motherboard Hoverboard

Sumber: (aliexpress.com, 2021)
B.2.12.2 Komputer Nvidia Jetson Nano
Menurut (Williman dan Jelinek, 1976) sistem komputer mikro berisi
komputer mikro ditambah catu daya pendukung, panel kontrol, dll., yang
memberi pengguna kemampuan yang hampir sama dengan komputer mini.
Hal ini termasuk mikroprosesor, memori dan sirkuit input/output (I/O) yang
dipasang pada satu papan sirkuit tercetak (PCB) dan Jetson Nano termasuk
salah satu komputer mini tersebut. Penelitian ini menggunakan komputer
mini Jetson Nano sebagai pemrosesan utama kedua setelah mikrokontroler
hoverboard. Penggunaan dari Jetson Nano berdasarkan saran dari
(Brombach, 2021), yang menyarankan untuk menggunakan Jetson Nano 4GB
karena jauh lebih kuat dan jauh lebih baik dibanding dengan Raspberry Pi 3.
Bentuk fisik dari Nvidia Jetson Nano dapat dilihat pada gambar 2.24.

56
 Gambar 2.24 Nvidia Jetson Nano
Sumber: (www.nvidia.com, 2021)
B.2.12.3 Aktuator Motor BLDC Hoverboard dan Sensor Rotary Encoder
Menurut (Wang, 2012) Motor BLDC memiliki beberapa keunggulan
dibandingkan motor DC brushed konvensional, terutama pada karakteristik
kecepatan versus torsi yang lebih baik, efisiensi tinggi, respons dinamis tinggi,
masa pakai yang lama, pengoperasian tanpa suara, rentang kecepatan yang lebih
tinggi, dan perawatan yang rendah. (Wang, 2012) juga menjelaskan bahwa
karena BLDC menggunakan metode kontrol konduksi berpasangan, maka ketika
arah putaran BLDC bolak-balik, hanya ada dua MOSEFT daya yang menyala.
Ketika sensor Hall mendeteksi posisi baru berikutnya, yang memberi tahu
mikroprosesor chip GD32 untuk memberikan sinyal kontrol baru.
Kontroler menyesuaikan fase dan amplitudo pulsa arus DC untuk mengontrol
kecepatan dan torsi motor. Sistem kontrol ini merupakan alternatif dari
komutator mekanis (sikat) yang digunakan di banyak motor listrik konvensional
(Wang, 2012).

57
 Gambar 2.25 Motor BLDC 6.5” 36V 350W dan build in Encoder
Sumber: (www.hoverboardforlife.blogspot.com, 2016)
Pada gambar 2.25 dapat dilihat bahwa di dalam motor BLDC terdapat sensor
encoder yang berfungsi untuk mengetahui posisi motor berdasarkan data yang
dikirimkan dari HALL sensor. Sensor Encoder ini akan mengirimkan data berupa
odometry yang nantinya akan digunakan sebagai input pada sistem. Pembahasan
lebih lanjut mengenai odometry akan dibahas pada bagian selanjutnya.
B.2.12.4 Sensor RPLiDAR A1

Gambar 2.26 Sensor RPLiDAR

Sumber: (www.RoboPeak.com, 2013)
Mengutip dari (RoboPeak Team, 2014) RPLiDAR A1 (RoboPeak Light Distance
and Ranging) adalah pemindai laser 2D (Laser Distance Sensor) 360 derajat
berbiaya rendah yang dikembangkan oleh RoboPeak dengan versi penjualan A1
atau versi LiDAR pertama. Menggunakan teknologi sensor jarak jauh yang
memakai laser untuk memindai halangan atau dinding dan menghitung jaraknya.
Data titik 2D yang dihasilkan dapat digunakan dalam pemetaan, pelokalan, dan
permodelan objek/lingkungan. Pada gambar 2.26 dapat dilihat bentuk fisik dari
RPLiDAR dengan keterangan berupa fitur utama dan nilai tegangannya
(RoboPeak Team, 2014).
(RoboPeak Team, 2014) menjelaskan bahwa frekuensi pemindaian RPLiDAR
mencapai 5,5 hz saat pengambilan sampel 360 titik setiap putaran dan dapat
dikonfigurasi hingga maksimum 10 hz. Hasil scan atau pemindaian LiDAR ini
berupa titik-titik awan (point clouds) dalam bidang 2 dimensi, karena sensor ini
hanya memindai bidang horizontal. (RoboPeak Team, 2014) menambahkan
bahwa RPLiDAR berisi sistem pemindai jangkauan dan sistem motor. Setelah
menyalakan setiap sub-sistem, RPLiDAR mulai berputar dan memindai searah
jarum jam. Pengguna bisa mendapatkan data pemindaian jarak jauh melalui
antarmuka komunikasi (Port serial/USB). Sistem mengukur data jarak lebih dari
2000 kali per detik dan dengan output jarak resolusi tinggi (<1% dari jarak).
Dalam dokumentasinya (RoboPeak Team, 2014) menjelaskan bahwa RPLiDAR
memancarkan sinyal laser inframerah termodulasi dan sinyal laser tersebut

58
kemudian dipantulkan oleh objek yang akan dideteksi. Sinyal kembali di sampel
oleh sistem akuisisi visi di RPLiDAR dan DSP yang tertanam di RPLiDAR mulai
memproses data sampel dan nilai jarak keluaran dan nilai sudut antara objek dan
RPLiDAR melalui antarmuka komunikasi. Hasil dari pemindaian ini akan
dikirimkan melalui komunikasi USART melalui adapter USART dan dihubungkan
ke Jetson Nano menggunakan Port USB. Data yang didapat berupa koordinat dari
setiap titik laser yang terbaca.
B.2.12.5 Sensor IMU GY-521 MPU-6050 6DOF

Gambar 2.27 Sensor IMU GY-521

Sumber: (www.digiwarestore.com, 2013)
GY-521 MPU-6050 merupakan modul sensor yang berfungsi sebagai
akselerometer dan giroskop yang dikemas dalam bentuk satu modul yang kokoh,
seperti yang terlihat pada gambar 2.27. Menurut (Pyo, dkk., 2017) Chip
MPU6050 yang terintegrasi dengan triple-axis gyroscope dan triple-axis
accelerometer dalam satu chip, dapat digunakan tanpa menambahkan sensor
inertial lain. Baca dan tulis mampu melakukannya dengan kecepatan tinggi
karena data sensor ditransfer dengan komunikasi I2C atau SPI. (Pyo, dkk., 2017)
menambahkan bahwa nilai sensor akselerometer dan giroskop dikonversi ke nilai
Roll, Pitch, dan Yaw papan dengan fusi sensor. Saat kelas IMU dibuat sebagai
objek dan fungsi update() dipanggil, nilai akselerasi dan gyro dibaca secara
berkala dari sensor.

B.2.13 Light Detection and Ranging

Mengutip dari (Pyo, dkk., 2017) Laser Distance Sensor (LDS) disebut dengan
berbagai nama seperti Light Detection and Ranging (LiDAR), Laser Range Finder
(LRF) dan Laser Scanner. (Pyo, dkk., 2017) menjelaskan bahwa LDS adalah sensor
yang digunakan untuk mengukur jarak suatu objek dengan menggunakan laser
sebagai sumbernya. Sensor LDS memiliki keunggulan kinerja tinggi, kecepatan
tinggi, akuisisi data waktu nyata, sehingga memiliki berbagai aplikasi dalam
kaitannya dengan pengukuran jarak. Ini adalah sensor yang banyak digunakan di
bidang robot untuk pengenalan objek dan orang, dan sensor jarak berbasis SLAM
(sensor berbasis jarak), dan juga banyak digunakan pada kendaraan tak berawak
karena akuisisi data waktu nyata (Pyo, dkk., 2017).

59
 Gambar 2.28 Menghitung Jarak Dengan LDS/LiDAR
(Pyo, dkk., 2017) mengatakan Sensor LDS/LiDAR menghitung perbedaan
panjang gelombang ketika sumber laser dipantulkan oleh objek, seperti yang
ditunjukkan gambar 2.28. Jika dianalogikan, ini sama seperti ketika kita
mengarahkan cahaya senter ke suatu permukaan. Sebenarnya yang terjadi
adalah kita dapat melihat pantulan cahaya senter dari suatu permukaan ke
retina, namun karena prosesnya sangat cepat, maka hal tersebut terjadi seolah-
olah secara instan. Untuk menghitung jarak, LiDAR menggunakan rumus sebagai
berikut:
c∗t
d= (2.16)
2
d = jarak antara sensor dan objek yang diukur (m)
c = Kecepatan cahaya (3 x 108 m/s)
t = Waktu tempuh cahaya/sinyal

B.2.14 Wheel Odometry

Menurut (Holland, 2004) odometry adalah informasi relatif yang memberi
tahu kita seberapa banyak kita telah pindah, tetapi bukan di mana kita berada.
Menurut (Ben-Ari dan Mondada, 2018) Wheel Odometry merupakan teknik
lokalisasi yang menghitung posisi robot berdasarkan perputaran roda (kecepatan
putaran roda atau jumlah perputaran roda). Kecepatan putaran roda atau jumlah
perputaran roda dapat diukur menggunakan rotary encoder. Jika rotary encoder
menggunakan tipe incremental (menghitung jumlah perputaran roda dalam
satuan pulsa / ticks), maka perpindahan roda dalam satuan meter menggunakan
Persamaan (2.18) dengan i merupakan roda kiri ( l ) atau roda kanan ( r ) , R adalah
jari-jari roda, ∆ pulsa adalah perbedaan pulsa pada waktu t dan t −1, dan
resolusi_sensor adalah jumlah pulsa per revolusi roda (Ben-Ari dan Mondada,
2018; Putra, Muliady dan Setiadikarunia, 2020).
Untuk mendapatkan jumlah pulsa setiap satu kali putaran roda digunakan
rumus sebagai berikut (Utomo, 2015; Ben-Ari dan Mondada, 2018):
keliling roda=2 π r (2.17)
keliling roda ×∆ pulsa
d i= (2.18)
resolusi sensor
60
 Menurut (Putra, Muliady dan Setiadikarunia, 2020), setelah masing-masing
perpindahan roda dihitung, perpindahan sudut orientasi robot dapat dihitung
menggunakan Persamaan (2.19) dengan b adalah jarak antar roda. Perpindahan
robot dalam koordinat x dapat dihitung menggunakan Persamaan (2.20) dan
perpindahan robot dalam koordinat y dihitung menggunakan Persamaan (2.21),
dengan variabel dc pada Persamaan (2.20) dan Persamaan (2.21) dihitung
dengan Persamaan (2.22) serta variabel φ merupakan sudut orientasi awal robot
(Ben-Ari dan Mondada, 2018; Putra, Muliady dan Setiadikarunia, 2020).
θ=( d r −d i ) /b (2.19)
dx=d c cos ( θ+ φ ) (2.20)
dy =d c sin ( θ+ φ ) (2.21)
d c =( d r +d l ) /2 (2.22)

B.2.15 Inertial Measurement Unit (IMU)

Menurut (Siegwart, Nourbakhsh dan Scaramuzza, 2004) Inertial
Measurement Unit (IMU) adalah perangkat yang menggunakan giroskop dan
akselerometer untuk memperkirakan posisi relatif, kecepatan, dan percepatan
kendaraan yang bergerak. Namun pada penelitian, hanya akselerometer yang
dimanfaatkan untuk mendapatkan data inersia dari pergerakan robot, sedangkan
giroskop tidak.
B.2.15.1 Akselerometer
Menurut (Siegwart, Nourbakhsh dan Scaramuzza, 2004) akselerometer
adalah perangkat yang digunakan untuk mengukur semua gaya eksternal yang
bekerja padanya, termasuk gravitasi. Akselerometer termasuk dalam kelas
sensor proprioceptive. (Siegwart, Nourbakhsh dan Scaramuzza, 2004)
menambahkan bahwa secara konseptual, akselerometer adalah sistem pegas
massa peredam di mana posisi tiga dimensi massa bukti relatif terhadap
selubung akselerometer dapat diukur dengan beberapa mekanisme.

B.2.16 Robot Operating System (ROS)

Mengutip dari buku “ROS Robot Programming” (Pyo, dkk., 2017),
menjelaskan bahwa ROS (Robot Operating System) adalah sistem operasi meta
yang terbuka untuk umum yang menyediakan layanan seperti sistem operasi,
abstraksi perangkat keras, kontrol perangkat tingkat rendah, implementasi
fungsionalitas umum, pengiriman pesan antar proses, dan manajemen paket.
ROS menyediakan berbagai alat dan library untuk dapat membangun, menulis,
dan menjalankan kode di banyak komputer. (Pyo, dkk., 2017) menambahkan
bahwa sistem operasi meta menggambarkan sebuah sistem yang melakukan
proses seperti penjadwalan, pemuatan, pemantauan, dan penanganan kesalahan
dengan memanfaatkan lapisan virtualization antara aplikasi dan sumber daya
komputasi terdistribusi. Pada dasarnya ROS bukanlah sistem operasi seperti
Windows, Linux, dan Android, melainkan sebuah sistem operasi yang berjalan

61
pada sistem operasi yang sudah ada, contohnya ROS pada sistem operasi Linux
(Pyo, dkk., 2017).

Gambar 2.29 ROS Sebagai Sistem Operasi Meta Pada Sistem Operasi Lain
Sumber: (Pyo, dkk., 2017)
(Pyo, dkk., 2017) menjelaskan bahwa ROS mengembangkan, mengelola, dan
menyediakan aplikasi paket untuk berbagai keperluan, dan telah membentuk
ekosistem yang mendistribusikan paket yang dikembangkan oleh pengguna.
Seperti yang dijelaskan pada gambar 2.29, ROS adalah sistem pendukung untuk
mengendalikan sensor dengan abstraksi perangkat keras dan mengembangkan
aplikasi robot berdasarkan sistem operasi konvensional yang telah ada. (Pyo,
dkk., 2017) mengatakan untuk mengembangkan robot yang terkait dengan ROS,
perlu memahami komponen dan konsep penting dari ROS. Sub bab di bawah ini
akan memperkenalkan terminologi yang digunakan dalam ROS dan konsep
penting ROS seperti komunikasi pesan, file pesan, nama, transformasi koordinat
(TF), pustaka klien, komunikasi antar perangkat heterogen, sistem file, dan
sistem pembangunan.
B.2.16.1 Terminologi Pada Ekosistem ROS
Pada buku “ROS Robot Programming” menjelaskan beberapa terminologi-
terminologi yang digunakan pada ekosistem ROS sebagai komponen atau konsep
penting, berikut ini adalah terminologi yang sering digunakan (Pyo, dkk., 2017).
1. ROS, middle ware yang menyediakan layanan sistem operasi standar
seperti abstraksi perangkat keras, driver perangkat, implementasi fitur
yang umum digunakan termasuk pengindraan, pengenalan, pemetaan,
perencanaan gerak, pengiriman pesan antar proses, manajemen paket,
visualisasi dan perpustakaan kode untuk pengembangan serta alat
debugging (Pyo, dkk., 2017).
2. Master, sebutan untuk node yang bertindak sebagai node server dari
koneksi node-to-node dan komunikasi pesan. Koneksi antara node dan
62
 komunikasi pesan seperti topik dan layanan tidak mungkin tanpa master.
Saat menjalankan ROS, master akan dikonfigurasi dengan alamat dan
port URI dikonfigurasi di ROS_MASTER_URI. Secara default, alamat URI
menggunakan alamat IP PC lokal, dan nomor port 11311, kecuali jika
konfigurasi diubah. (Pyo, dkk., 2017).
3. Slave, sebutan untuk node yang terkoneksi dan menerima perintah dari
master. Komunikasi Master dengan slave menggunakan XML Remote
Procedure Call yang merupakan protokol berbasis HTTP yang tidak
membutuhkan konektivitas (Pyo, dkk., 2017).
4. Node, merujuk pada unit terkecil dari proses yang berjalan pada ROS,
seperti program yang berjalan pada satu program executable. ROS
merekomendasikan untuk membuat satu node tunggal untuk setiap
tujuan, dan direkomendasikan untuk dikembangkan agar dapat
digunakan kembali dengan mudah. Saat pertama kali dijalankan, node
mendaftarkan informasi berupa nama, tipe pesan, alamat URI, dan nomor
port. Node yang sudah terdaftar bisa bertindak sebagai publisher,
subscriber, dan service berdasarkan informasi yang terdaftar. Pada
implementasinya node digunakan sebagai media pertukaran pesan
menggunakan topic dan service (Pyo, dkk., 2017).
5. Package, unit dasar dari ROS. Aplikasi ROS dikembangkan berdasarkan
paket-paket dasar yang berisi konfigurasi untuk meluncurkan node
lainnya. Package berisikan semua file penting yang saling terhubung
dengan paket lainnya termasuk dependensi library ROS untuk
menjalankan beberapa proses, dataset, dan konfigurasi (Pyo, dkk., 2017).
6. Metapackage, bagian dari package yang memiliki tujuan umum. Sebagai
contoh pada metapackage “Navigation” yang berisikan 10 paket
termasuk AMCL, DWA, EKF, dan map_server (Pyo, dkk., 2017).
7. Message, variabel yang digunakan untuk mengirim atau menerima pesan
di antara node-node. Message dapat berupa variabel integer, float,
Boolean dan array. Protokol komunikasi TCPROS dan UDPROS digunakan
untuk pengiriman pesan. Topik digunakan dalam pengiriman pesan
searah sementara layanan digunakan dalam pengiriman pesan dua arah
yang melibatkan permintaan dan respons (Pyo, dkk., 2017).
8. Topic, secara harfiah seperti topik di dalam pembicaraan. Node publisher
mendaftarkan topiknya ke master dan kemudian mulai memublikasikan
pesan tentang suatu topik. Node subscriber yang ingin menerima
informasi permintaan topik dari node publisher di sesuaikan dengan nama
topik yang terdaftar di master. Berdasarkan informasi ini, node subscriber
langsung terhubung ke node publisher untuk bertukar pesan sebagai
topik. Sehingga dengan konsep seperti ini sistem dapat mendapatkan
pesan dari banyak sensor yang digunakan untuk mengambil keputusan
menggerakkan aktuator (Pyo, dkk., 2017).

63
9. Publish and Publisher, istilah “publish atau terbitkan” merujuk pada
tindakan mentransmisikan pesan relatif yang sesuai dengan topic yang
diminta. Node publisher mendaftarkan informasi dan topiknya sendiri ke
master, kemudian menerbitkan pesan, untuk nantinya di dapat request
oleh node subscriber. Publisher dideklarasikan di dalam node dan dapat
dideklarasikan beberapa kali dalam satu node (Pyo, dkk., 2017).
10. Subscribe and Subscriber, istilah “subscribe atau berlangganan” merujuk
pada tindakan menerima pesan relatif yang sesuai dengan topik. Node
subscriber mendaftarkan informasi dan topiknya sendiri pada master dan
menerima informasi publisher yang menerbitkan topik relatif dari master.
Berdasarkan informasi publisher yang diterima, node subscriber secara
langsung meminta koneksi ke node publisher yang terhubung. Subscriber
dideklarasikan dalam node dan dapat dideklarasikan beberapa kali dalam
satu node (Pyo, dkk., 2017).
11. Service, komunikasi dua arah yang sinkron antara service client yang
meminta layanan mengenai tugas tertentu dan service server yang
bertanggung jawab untuk menanggapi permintaan (Pyo, dkk., 2017).
12. Service Server, server dalam komunikasi pesan layanan yang menerima
permintaan sebagai input dan mengirimkan respons sebagai output. Baik
permintaan maupun tanggapan adalah berupa pesan. Server layanan
diimplementasikan di node yang menerima dan menjalankan permintaan
yang diberikan (Pyo, dkk., 2017).
13. Service Client, klien dalam komunikasi pesan layanan yang meminta
layanan ke server dan menerima respons sebagai input. Klien
mengirimkan permintaan ke server layanan dan menerima respons.
Service client diimplementasikan di node yang meminta perintah tertentu
dan menerima hasil (Pyo, dkk., 2017).
14. Bag, data dari ROS message dapat disimpan dan hasil penyimpanan
pesan tersebut disebut sebagai bag. Pada ROS, bag digunakan untuk
merekam dan menjalankan ulang pesan untuk menciptakan ulang
lingkungan sebelum perekaman. Fungsi rekam dan jalankan sangat
berguna ketika proses pengembangan algoritme dengan beberapa
pengulangan ulang program untuk dimodifikasi (Pyo, dkk., 2017).
15. Action, metode komunikasi pesan lain yang digunakan untuk komunikasi
dua arah asinkron. Action digunakan ketika dibutuhkan waktu lebih lama
untuk merespons perantara hingga hasilnya dikembalikan (Pyo, dkk.,
2017).
16. Parameter, merujuk pada parameter yang dipakai pada node. Nilai
default diatur dalam parameter dan dapat dibaca atau ditulis jika perlu,
hal ini sangat berguna ketika nilai yang dikonfigurasi ingin dimodifikasi
secara real-time (Pyo, dkk., 2017).

64
 17. Catkin, merujuk pada build system dari ROS. Sistem build pada dasarnya
menggunakan Cmake (Cross Platform Make) yang terdefinisi tiap proses
build pada file ‘CMakeLists.txt’. Sistem build Catkin memudahkan
penggunaan build terkait ROS, manajemen paket, dan dependensi di
antara paket (Pyo, dkk., 2017).
18. URI, memiliki kepanjangan Uniform Resource Identifier merupakan
alamat unik yang mewakili sumber daya di internet. URI adalah salah satu
komponen dasar yang memungkinkannya terjadi interaksi dengan
internet dan digunakan sebagai pengenal dalam protokol internet (Pyo,
dkk., 2017).
B.2.16.2 Perintah Dasar Pada ROS
ROS memiliki beberapa perintah operasi dasar yang sering digunakan pada
imbuhan awal setiap perintah yang dilakukan, antara lain sebagai berikut (Pyo,
dkk., 2017):
1. roscore, merupakan perintah yang menjalankan master ROS. Jika
beberapa komputer berada di dalam yang sama jaringan, dapat
dijalankan dari komputer lain dalam jaringan. Namun, kecuali untuk kasus
khusus yang mendukung banyak roscore, hanya satu roscore yang harus
berjalan di jaringan. Ketika ROS master sedang berjalan, alamat URI dan
nomor port ditetapkan untuk ROS_MASTER_URI variabel lingkungan yang
digunakan. Jika pengguna belum mengatur variabel lingkungan, arus
alamat IP lokal digunakan sebagai alamat URI dan nomor port 11311
digunakan yang merupakan port default nomor untuk master (Pyo, dkk.,
2017).
2. rosrun, merupakan perintah eksekusi dasar pada ROS. Rosrun digunakan
untuk menjalankan satu node dalam paket. Node menggunakan variabel
environment ROS_HOSTNAME yang disimpan di komputer tempat node
dijalankan sebagai jalan URI dan port disetel ke nilai unik yang berubah-
ubah (Pyo, dkk., 2017).
3. roslaunch, sementara rosrun adalah perintah untuk mengeksekusi satu
node, maka sebaliknya roslaunch digunakan untuk mengeksekusi banyak
node sekaligus. roslaunch adalah perintah ROS khusus dalam eksekusi
node dengan fungsi tambahan seperti mengubah parameter paket atau
nama node, mengkonfirmasi namespace node, mengatur ROS_ROOT dan
ROS_PACKAGE_PATH, serta mengubah variabel environment saat
mengeksekusi node (Pyo, dkk., 2017).
4. rostopic, perintah untuk mengakses topik yang ditentukan dalam grafik
komputasi (Pyo, dkk., 2017).
5. rosparam, perintah untuk mendapatkan, mengatur, menghapus
parameter dari ROS Parameter Server (Pyo, dkk., 2017).

65
 6. rosservice, perintah untuk mengakses layanan yang didefinisikan dalam
grafik komputasi (Pyo, dkk., 2017).
7. rosbeg, perintah untuk menyimpan pesan dengan melakukan perekaman
dari kondisi lingkungan sebelumnya untuk memudahkan proses
pengembangan, sehingga hanya perlu memuat ulang kondisi yang sudah
dicapai sebelumnya (Pyo, dkk., 2017).
B.2.16.3 Coordinate Transformation (TF)

Gambar 2.30 Koordinat Pada Rangkaian Robot

Sumber: (Pyo, dkk., 2017)
Mengutip dari (Pyo, dkk., 2017), pada gambar 2.30 memperlihatkan pose
lengan robot sebagai transformasi koordinat relatif dari masing-masing sendi.
Misalnya tangan robot humanoid yang terhubung ke pergelangan tangan,
pergelangan tangan terhubung ke siku, dan siku terhubung ke bahu. Robot dapat
menghitung posisi objek relatif terhadap posisinya dipeta berdasarkan data dari
TF. Dalam pemrograman robotika, sendiri robot dan posisi masing-masing robot
sangat penting, sehingga pada ROS hal ini diwakili oleh TF (transform) (Pyo, dkk.,
2017).

Gambar 2.31 Frame Transformasi Robot Beroda

Sumber: (wiki.ros.org, 2022)

66
 Pada gambar 2.31, merupakan transformasi koordinat relatif dari masing-
masing titik koordinat pada pose robot beroda. Penelitian ini menggunakan
robot beroda sebagai platform dari implementasi sistem pemetaan dan navigasi.
Mengutip dari (Pyo, dkk., 2017) dengan menggunakan dua frame di antara frame
odom dan base_footprint dapat digunakan sebagai representasi dari pose 2D
robot. Frame base_stabilized menambahkan informasi tentang tinggi relatif
robot terhadap map atau odometry. Frame base_link melekat erat pada robot
dan menambahkan sudut roll dan pitch dibandingkan dengan frame
base_stabilized (Pyo, dkk., 2017).
(Pyo, dkk., 2017) juga mengatakan bahwa dalam ROS, transformasi koordinat
TF adalah salah satu konsep yang paling berguna saat mendeskripsikan bagian
robot serta rintangan dan objek. Pose dapat digambarkan sebagai kombinasi
posisi dan orientasi. Untuk posisi dinyatakan oleh tiga vektor x, y, dan z
sedangkan orientasi dinyatakan oleh empat vektor, yakni vektor x, y, z, dan w
atau yang disebut dengan quaternion. Bentuk quaternion bebas dari gimbal lock
atau masalah kecepatan yang ada pada vektor roll, pitch, dan yaw metode Euler.
Maka dari itu tipe quaternion lebih banyak digunakan pada robotika dan ROS
menggunakan quaternion karena alasan ini.

B.2.17 ROS Tool

Mengutip dari (Pyo, dkk., 2017) mengatakan bahwa ada cukup banyak tool
atau alat pada ROS, termasuk alat yang telah dirilis oleh pengguna ROS secara
pribadi. Ini adalah alat tambahan yang sangat berguna untuk pemrograman
dengan ROS, salah satunya adalah aplikasi visualisasi 3D yang lengkap dengan
alat untuk memberikan koordinat tujuan, yaitu RViz dan aplikasi dengan
segudang fitur untuk development dan monitoring, yaitu rqt.
B.2.17.1 RViz (3D Visualization Tool)
Menurut (Pyo, dkk., 2017) RViz adalah alat visualisasi 3D dari ROS yang
tujuan utamanya adalah untuk menampilkan pesan ROS dalam 3D dan
memungkinkan untuk memverifikasi data secara visual. Misalnya, untuk
memvisualisasikan jarak dari sensor Laser Distance Sensor (LDS) ke rintangan,
Point Cloud Data (PCD) dari sensor jarak 3D seperti RealSense, Kinect, atau Xtion,
nilai gambar yang diperoleh dari kamera, dan banyak lagi tanpa harus
mengembangkan perangkat lunak secara terpisah. Tampilan dari RViz dapat
dilihat pada gambar 2.32.

67
 Gambar 2.32 Tampilan Loading Screen RViz
Sumber: (github.com/ros-visualization/rviz, 2021)
(Pyo, dkk., 2017) juga menjelaskan bahwa RViz Ini juga mendukung berbagai
Penanda Interaktif memungkinkan pengguna untuk melakukan gerakan interaktif
dengan perintah dan data yang diterima dari node pengguna. Selain itu, ROS
memiliki fitur untuk menampilkan visualisasi robot dalam bentuk Unified Robot
Description Format (URDF), yang dinyatakan sebagai model 3D di mana setiap
model dapat dipindahkan atau dioperasikan sesuai dengan derajat
kebebasannya, sehingga dapat digunakan untuk simulasi atau kontrol.
B.2.17.2 rqt (ROS GUI Development Tool)
rqt adalah alat yang dapat digunakan sebagai alat GUI yang memiliki banyak
fitur untuk keperluan pengembangan. Contohnya seperti graphical tool yang
menunjukkan hierarki dari setiap node sebagai diagram, hierarki ini
menunjukkan status node dan topik yang saat ini. Kemudian ada alat plot yang
mampu membuat skema pesan sebagai grafik 2D dan masih plugins lainnya
seperti rqt_plugins, rqt_image_view, rqt_graph, rqt_plot, dan rqt_bag.

68
 Gambar 2.33 Tampilan Antarmuka Aplikasi rqt Dan Semua Plugin
Sumber: (www. ros.guru, 2021)

B.2.18 Virtual Network Computing (VNC)

Menurut (Richardson, dkk., 1998) Virtual Network Computing (VNC) atau
Komputasi Jaringan Virtual adalah sistem klien ultra tipis berdasarkan protokol
tampilan sederhana yang tidak bergantung pada platform. Mesin server tidak
hanya menyediakan aplikasi dan data tetapi juga seluruh lingkungan desktop
yang dapat diakses dari mesin yang terhubung ke Internet menggunakan
perangkat lunak sederhana NC (Richardson, dkk., 1998).

Gambar 2.34 Komunikasi Dua Komputer Dengan VNC

Sumber: (www.computer.org, 1998)
(Richardson, dkk., 1998) mengatakan teknologi yang mendasari sistem VNC
adalah protokol sederhana untuk akses jarak jauh ke antarmuka pengguna grafis.
Sistem ini bekerja pada tingkat frame buffer dan oleh karena itu berlaku untuk
semua sistem operasi, sistem windowing, dan aplikasi untuk perangkat dengan
beberapa bentuk tautan komunikasi. Protokol VNC akan beroperasi melalui
semua transportasi yang dapat diandalkan seperti TCP/IP. (Richardson, dkk.,
1998) menambahkan bahwa titik akhir di mana perubahan pada frame buffer
berasal (yaitu, sistem windowing dan aplikasi) dikenal sebagai server VNC seperti
yang terlihat pada gambar 2.34.

B.2.19 Firmware
Mengutip dari (Pyo, dkk., 2017) dikatakan robot sebagian besar
diklasifikasikan ke dalam perangkat keras dan perangkat lunak. Mekanisme,
motor, roda gigi, sirkuit, sensor dikategorikan sebagai perangkat keras. (Pyo,
dkk., 2017) menjelaskan bahwa firmware mikro kontroler yang menggerakkan
atau mengontrol perangkat keras robot, dan perangkat lunak aplikasi yang
membuat peta, menavigasi, membuat gerakan, dan memersepsikan lingkungan
berdasarkan data sensor diklasifikasikan sebagai perangkat lunak.
Pada penelitian ini pemrograman firmware dibutuhkan untuk mengubah
firmware default dari motherboard hoverboard dengan menggunakan firmware
yang dapat di download pada link berikut,
https://github.com/EFeru/hoverboard-firmware-hack-FOC. Firmware ini ditulis

69
untuk chip STM32 dan GD32 yang banyak digunakan sebagai mikro kontroler
perangkat mainan hoverboard.

B.2.20 Metode Statistik

Metode statistik merupakan prosedur-prosedur yang digunakan dalam
penyajian data yang meliputi pengumpulan, pengorganisasian, peringkasan, dan
penyajian data. Metode statistik digunakan untuk mengukur data dari suatu
metode untuk mengetahui tingkat keberhasilan pengujiannya.
1. Weighted Absolute Percentage Error (WAPE)
(Chase, 2013; Ragnerstam, 2016) menjelaskan bahwa untuk mengukur
kesalahan perkiraan rata-rata di seluruh kelompok item untuk periode
tertentu, gunakan metode yang memperhitungkan bobot setiap item
dalam hubungannya dengan total. Salah satu metode yang
memperhitungkan hal ini adalah WAPE. (Chase, 2013; Ragnerstam, 2016)
menggambarkan bahwa rumus dari WAPE adalah sebagai berikut.
n

∑ ¿ At −F t∨¿
WAPE= t=1n ¿ (2.23)
∑ ¿ A t ∨¿ ¿
t=1

(Chase, 2013; Ragnerstam, 2016) mengatakan bahwa WAPE

memperhitungkan setiap item dengan menimbang permintaan aktual
setiap item dalam kaitannya dengan total permintaan aktual. Dengan
demikian, WAPE menghubungkan perbedaan antara nilai aktual dan nilai
perkiraan. (Louhichi, Jacquet dan Butault, 2012) juga menyebutkan bahwa
WAPE adalah metode yang bermanfaat untuk digunakan untuk
menghitung akurasi ramalan dan paling optimal ketika variabel mendekati
nol.
2. Persentase Keberhasilan
Persentase keberhasilan merupakan metode untuk menghitung nilai
persentase keberhasilan dalam suatu pengujian. Untuk menghitung tingkat
keberhasilan akan digunakan persamaan 2.24.
Keberhasilan
Presentase Keberhasilan= ×100 % (2.24)
Total

70
 BAB C METODOLOGI PENELITIAN

Dalam bab metodologi penelitian akan dijelaskan tahapan-tahapan yang akan

dilakukan untuk mendukung penelitian dengan judul “Implementasi Pemetaan
Dan Navigasi Dalam Ruangan Pada Autonomous Mobile Robot Menggunakan
Algoritma Hector SLAM Dan Dijkstra Berbasis Robot Operating System” dan pada
bagian metodologi akan memaparkan lebih lanjut terkait tipe penelitian, metode
penelitian, subjek penelitian, lokasi penelitian, teknik pengumpulan data, teknis
analisis data, dan peralatan pendukung yang digunakan.

C.1 Tipe Penelitian

Tipe penelitian yang digunakan pada penelitian ini adalah tipe implementatif
pengembangan. Implementatif menunjukkan bahwa penelitian ini memerlukan
pengujian melalui perangkat lunak dan perangkat keras, tidak hanya analisis data
saja. Hasil dari penelitian ini adalah sebuah purwarupa robot bergerak otonom
dari hoverboard yang mampu memetakan area sekitar dan mampu menghindari
halangan.

C.2 Strategi dan Rencana Penelitian

Pada penelitian ini, dibutuhkan strategi dan rencana yang jelas agar
memenuhi tujuan yang hendak dicapai. Untuk memenuhi hal tersebut penulis
akan menjelaskan secara umum setiap perangkat keras dan perangkat lunak
yang digunakan sebagai sistem dari robot bergerak. Untuk memenuhi tujuan
yang telah dirumuskan pada bab sebelumnya maka disusun perancangan sistem
yang menjelaskan peran dari perangkat keras sebagai penyedia sumber
pemrosesan untuk melakukan komputasi dan perangkat lunak yang berperan
sebagai pengolahan data dan pemrosesan mapping, localization and navigation.
Pemecahan masalah pada penelitian ini dilakukan dengan menjalankan 3
tahap, yaitu pengambilan data untuk mapping, pengolahan data untuk
localization, dan hasil pemrosesan peta-lokasi untuk proses navigation. Pada
tahap awal, pengambilan data berdasarkan perhitungan jarak oleh hasil
pembacaan 2 sensor, yakni RPLiDAR dalam bentuk sinar inframerah yang
ditembakkan dan Inertial Measurement Unit atau IMU. Perhitungan dari kedua
sensor ini nantinya akan menghasilnya lokasi robot berupa posisi x, y, z dan
benda di sekitarnya seluas 6-6 meter yang menghasilkan bentuk visual pada
perangkat lunak yang ditampilkan dalam monitor komputer/Jetson Nano berupa
partikel titik merah yang sangat banyak, sehingga membentuk pola berdasarkan
area sekitar seperti air yang di wadah maka air akan berbentuk seperti wadah.
Kemudian setelah peta sudah dibangun, selanjutnya adalah tahap akhir yaitu
navigasi, dengan memanfaatkan sensor RPLiDAR, IMU, peta dan gabungan
algoritme navigasi, kita dapat melakukan proses navigasi dengan memasukkan
titik tujuan pada visualisasi peta. Dengan begitu robot akan berjalan ke dari titik
awal (posisi robot saat ini) menuju titik tujuan (posisi input pengguna).

71
C.3 Metode Penelitian
Demi sepenuhnya mencapai tujuan, maka pada penelitian ini dilakukan
secara struktur dan sistematis dalam metode penelitian. Metode yang digunakan
untuk mengembangkan suatu karya harus sesuai dengan kebutuhan pembuatan
karya. Kebutuhan awal yang diperlukan untuk merancang robot ini yaitu
pendalaman informasi terkait permasalahan, pengumpulan, pengkajian teori,
dan penelitian sebelumnya yang telah dilakukan dengan tujuan mendukung
pengembangan robot ini sehingga dapat ditemukan solusi dari permasalahan
dalam pengembangan karya ini. Jurnal ilmiah, artikel ilmiah, situs web, buku, dan
lain sebagainya digunakan sebagai studi literatur pada penelitian ini. Setelah
melakukan studi literatur, maka langkah selanjutnya adalah melakukan definisi
masalah yang ingin diselesaikan, misalnya seperti perangkat lunak (software),
perangkat keras (hardware), algoritme yang digunakan, dan lain sebagainya.
Setelah itu dirumuskan dasar teori yang berisi penelitian secara ilmiah sangat
diperlukan sebagai referensi penunjang dalam pengembangan robot ini
sehingga menghasilkan karya dari permasalahan yang ada dan bisa
dipertanggungjawabkan. Hasil pengkajian teori dari studi literatur yang relevan
digunakan dalam mengaplikasikan proses rekayasa kebutuhan sistem yang sesuai
lalu melakukan perancangan sistem atau gambaran sistem, implementasi sistem,
dan pengujian sistem. Sistem yang telah dilakukan pengujian kemudian dilakukan
analisis. Dari hasil analisis pengujian akan digunakan untuk menginformasikan
bahwa sistem ini belum atau telah memenuhi kebutuhan dalam permasalahan
yang diajukan. Diagram alir tahapan penelitian dapat dilihat pada gambar 3.1.

72
 Gambar 3.35 Diagram Alir Penelitian
Penggunaan diagram alir penelitian seperti gambar 3.1 akan membuat proses
lebih tepat arah dan teratur. Setelah analisis hasil pengujian apabila penulis
merasa bahwa rumusan permasalahan tidak terjawab, maka penulis akan
memperbaiki sistem pada perancangan sistem, kemudian melakukan
implementasi sistem, pengujian sistem, dan kembali melakukan analisis hasil
pengujian. Setelah analisis hasil berhasil menjawab rumusan permasalahan,
maka penulis akan mendapatkan kesimpulan dan saran yang dibutuhkan dalam
penelitian.

73
C.4 Subjek Penelitian
Subjek dari penelitian ini memiliki hubungan dengan sebuah tempat
penyimpanan paket pengiriman yang merupakan sebuah gudang ekspedisi yang
memiliki tingkat intensitas aktivitas tinggi dalam penyortiran barang dan
membutuhkan sistem yang terotomatisasi untuk meningkatkan efisiensi waktu
dan tenaga kerja.

C.5 Lokasi Penelitian

Untuk lokasi pengujian dilakukan pada bangunan yang tempatnya dapat
diukur. Lokasi penelitian dilakukan pada basemen parkir gedung G Fakultas Ilmu
Komputer dengan desain denah seperti yang terlihat pada gambar 3.2.

Gambar 3.36 Denah Basemen Gedung G FILKOM UB

C.6 Teknik Pengumpulan Data

Pengambilan data sensor yang telah di kalibrasi, observasi parameter
berdasarkan dokumentasi dan data dari terminal Linux digunakan sebagai teknik
pengumpulan data dalam penelitian ini. Dengan menggunakan data yang
diperoleh dari hasil proses observasi langsung yang dilakukan pada semua
sensor, diharapkan penulis mengetahui betul bahwa data semua sensor telah
benar berdasarkan pengukuran asli dan dokumentasi datasheet setiap sensor.
Hal ini dilakukan agar pada pengujian, hasil bisa lebih objektif karena sensor

74
sudah berjalan sebagaimana mestinya dan menghindari kesalahan sehingga
berbeda dari penelitian sebelumnya. Observasi yang dilakukan bertujuan untuk
mengetahui apakah sistem yang dibuat berjalan sesuai dengan fungsi dan
kebutuhannya. Proses observasi meliputi percobaan setiap parameter pada
algoritme yang telah ditentukan dan dicari nilai yang optimal. Pencarian nilai
optimal ini didasari pada hasil riset pada penelitian yang serupa. Hal ini dilakukan
untuk mengetahui apakah parameter sebagai perhitungan dipengaruhi oleh
lingkungan yang dilihat dari hasil log pada terminal Linux dan hasil visualisasi
bentuk peta dan navigasi pada aplikasi RViz yang merupakan salah satu tool di
dalam ROS. Selanjutnya sampel data hasil observasi digunakan sebagai data
untuk proses analisa lebih lanjut.

C.7 Teknik Analisis Data

Analisa data dilakukan menggunakan data yang telah dikumpulkan
sebelumnya. Hal ini dilakukan untuk menguji kemampuan sistem yang akan
menjawab rumusan permasalahan yang ada untuk dievaluasi agar berguna untuk
penelitian ke depannya. Berikut adalah aspek yang diuji pada sistem.
1. Pengujian tingkat keakuratan data sensor IMU, Odometer, dan RPLiDAR.
2. Pengujian tingkat ketepatan bentuk peta berdasarkan denah bangunan asli
dari hasil pemetaan yang dihasilkan oleh ROS melalui pemindaian dari data
sensor RPLiDAR dan IMU.
3. Pengujian tingkat keakuratan navigasi robot terhadap halangan
menggunakan algoritme Dijkstra dan DWA yang diperoleh dari data
pemetaan yang telah dibuat.
4. Pengujian keakuratan pergerakan robot serta waktu komputasi yang
dibutuhkan sistem untuk berjalan pada posisi awal menuju posisi yang telah
ditentukan yang diperoleh dari masukkan titik koordinat RViz.

C.8 Peralatan Pendukung

Peralatan pendukung diperlukan untuk menunjang penelitian ini agar bisa
berjalan dengan lancar dan sistem bisa berjalan sesuai kebutuhan. Peralatan ini
terdiri dari perkakas atau peralatan yang berfungsi untuk membantu penulis
dalam pembuatan robot. Di bawah ini akan disebutkan peralatan pendukung
terkait perangkat keras serta perangkat lunak yang digunakan pada penelitian ini,
sebagai berikut.
1. Perangkat keras
 Motherboard Hoverboard
 Nvidia Jetson Nano
 Motor Brushless DC dan encoder
 Baterai 10S2P 4000mAh
 Power bank

75
  Sensor RPLiDAR
 Sensor IMU GY-521 MPU6050
 Dongle Wi-Fi
 Push button on-off
 Adapter dan port charger hoverboard
 STLink V2 Programmer
 FTDI to mini USB adapter
 Komputer (Personal Komputer)
 Chassis papan kayu
 3D Printer dan filamen
 Keyboard dan Mouse
 Kabel Jumper
 Kabel micro USB
2. Perangkat lunak
 Hoverboard Firmware
 STMCube Programmer
 Catkin workspace
 Robot operating system (ROS)
 Terminator
 Visual Studio Code
 Platform IO
 Virtual Network Computing (VNC)
 RViz
 rqt
 Hoverboard driver
 RPLiDAR driver
 MPU6050 dan I2C driver
 Hector SLAM library
 Robot localization (EKF & AMCL) library
 Move base (Global & local planner) library

76
 BAB D REKAYASA KEBUTUHAN

Dalam bab rekayasa kebutuhan, penulis akan menjelaskan kebutuhan apa

saja yang diperlukan untuk mengimplementasikan sistem dalam penelitian ini.
Rekayasa kebutuhan mencakup gambaran umum sistem, analisis kebutuhan
fungsional dan kebutuhan non-fungsional, kebutuhan perangkat keras,
kebutuhan perangkat lunak dan batasan desain sistem. Diharapkan dengan
rekayasa kebutuhan ini, sistem yang dibuat bisa berfungsi sesuai dengan tujuan
penelitian.

D.1 Gambaran Umum Sistem

Sistem yang dibuat pada penelitian ini merupakan sistem yang mempunyai
fungsi untuk membawa barang dari titik awal menuju titik tujuan yang bergerak
menggunakan roda serta mendeteksi area sekitar dengan sensor-sensornya.
Barang yang dibawa oleh sistem dianalogikan sebagai paket ekspedisi
pengiriman asli dengan berat beragam yang nantinya akan dibawa mengelilingi
area gudang. Mekanisme yang dilakukan oleh robot dianalogikan sebagai pekerja
penyortiran barang. Barang yang disortir berupa paket yang akan dipindahkan
dari gudang penyimpanan menuju area distribusi. Setiap informasi yang sudah
diselesaikan akan mengirimkan sebuah pesan menuju komputer server.

Gambar 4.37 Blok Diagram Sistem

Dari gambar 4.1 menunjukkan Blok Diagram dari sistem yang memiliki tiga
bagian yaitu input, proses, dan output. Bagian input dari sistem akan
menggunakan sensor RPLiDAR, IMU dan Odometer. Ketiga sensor ini digabung
menjadi satu kesatuan untuk menjalankan proses lokalisasi. Hasil dari sensor
RPLiDAR akan digunakan untuk lokalisasi dengan metode AMCL dimana data
laser dan map akan di fusi sehingga menghasilkan perkiraan pemosisian. Untuk
sensor IMU dan Odometer akan digabungkan sekaligus menggunakan algoritme
EKF sehingga menghasilkan odom_combined yang membuat posisi robot selalu
terkoreksi dan terfilter. Sedangkan input dari komputer server berupa perintah-
perintah command line dan input letak koordinat tujuan melalui RViz atau
terminal. Semua bagian input ini akan diteruskan ke bagian proses untuk
77
nantinya diolah oleh Jetson Nano sebagai sistem kontrol utama. Pada bagian
proses sistem menggunakan dua alat yaitu Jetson Nano dan Hoverboard
Motherboard. Jetson Nano akan menjadi sistem kendali utama dari sistem yang
bertugas untuk mencakup seluruh proses pengolahan data sensor, data
odometer, dan proses SLAM serta navigasi. Setiap data dari sensor akan
dikirimkan ke Jetson Nano yang kemudian akan diproses untuk lokalisasi robot.
Hanya sensor RPLiDAR yang mengirimkan data berupa laser scan dengan output
yang sudah jadi dan siap digunakan. Jadi tidak perlu melakukan konfigurasi
maupun menghitung manual data raw sensor. Hoverboard motherboard juga
mengirimkan data yang sudah jadi berupa odometry, data ini sudah diolah di
dalam motherboard. Hal ini bisa dilakukan karena kita melakukan custom
firmware dan memproses data odometer menjadi data odometry yang bisa
langsung digunakan tanpa perlu di filtrasi.
Untuk menggerakkan robot, kita hanya perlu memutar motor BLDC. Untuk
memutar motor kita perlu memanipulasi nilai pada variabel cmd_vel. Variabel
cmd_vel merupakan variabel yang digunakan untuk trigger nilai voltase pada
motherboard hoverboard sehingga motor dapat berputar, hal ini terjadi karena
kode biner yang di tanam ke dalam chip motherboard. Untuk memanipulasi
cmd_vel kita perlu membuat kode di dalam Jetson Nano. Setelah Jetson Nano
menentukan nilai cmd_vel maka nilai cmd_vel akan berubah dari kondisi
sebelumnya, hal ini juga berlaku pada variabel cmd_vel motherboard karena
Jetson Nano saling berkomunikasi dengan motherboard melalui serial USART.
Dengan begitu akan menghasilkan output berupa pergerakan motor, sehingga
robot bergerak. Setelah data berubah motherboard juga mengirimkan balik nilai
Odometer yang terdeteksi ke Jetson Nano untuk mengetahui secara simultan
lokasi dari robot. Kemudian Jetson Nano akan mengirimkan semua data pesan
yang diterimanya ke dalam RViz, sehingga kita dapat melihat perubahan yang
terjadi.

D.2 Analisis Kebutuhan Sistem

Pada sub bab terkait analisis kebutuhan sistem, proses ini bertujuan agar
peneliti tahu segala kebutuhan yang diperlukan oleh sistem pada perangkat
keras dan perangkat lunak, baik secara fungsional dan non-fungsional.

D.2.1 Kebutuhan Fungsional

Kebutuhan fungsional merupakan kebutuhan sistem yang di dalamnya berisi
proses apa saja yang harus disediakan oleh sistem, seperti bagaimana sistem
merespons input dan bagaimana respons sistem pada kondisi tersebut.
Kebutuhan fungsional disajikan ke dalam tabel yang dapat diliat pada tabel 4.1.
Tabel 4.7 Kebutuhan Fungsional Sistem
No Kebutuhan Sistem Skenario Pengujian
1 Sensor RPLiDAR dapat membaca Dapat mengirimkan data ke
jarak benda sekitar robot dengan mikrokontroler dan pengujian hasil

78
 pemindaian pada area seluas 360 data berupa pengukuran jarak
derajat. Nilai yang dihasilkan antara robot dengan halangan
berupa nilai distance atau jarak menggunakan alat pengukur
dari range 0.15 meter hingga 6 sebenarnya seperti meter ukur
meter
Sensor Inertial measurement unit Dapat mengirimkan posisi robot
(IMU) dapat membaca nilai derajat pada mikrokontroler terhadap
kemiringan dan gerak akselerasi posisi sebenarnya robot
2 pada robot. Berfungsi untuk menggunakan pemantauan secara
melakukan Sensing proyeksi langsung dan proyeksi melalui 3D
terhadap kemiringan dan gerak visual RViz
akselerasi robot
Motor DC Brushless atau BLDC Diujinya jumlah putaran motor DC
dapat menggerakkan robot menggunakan odometry dan
berdasarkan nilai PWM yang perhitungan secara manual
3 diberikan dari motherboard sehingga dipastikan data odometry
hoverboard adalah putaran sebenarnya dan
robot bergerak sesuai dengan yang
didesain
Sistem mikrokontroler di dalam Diujinya pengiriman data dan
robot mampu mengirim dan penerimaan data ketika diam dan
4
menerima data sensor IMU untuk bergerak
dilaksanakan
Sistem mikrokontroler di dalam Diujinya pengiriman data ketika
robot mampu mengirim dan robot melakukan proses
5
menerima data sensor RPLiDAR pembuatan peta atau mapping
untuk dilaksanakan
Mikrokontroler dapat memproses Diujinya navigasi robot
data dari sensor menjadi menggunakan data yang diberikan
6 kesimpulan arah gerak dan oleh sensor
kecepatan sistem pada aplikasi
ROS
Sistem Motherboard Hoverboard Diujinya kecepatan berdasarkan
dapat menggerakkan kedua motor perputaran roda melalui encoder
7
serta memberi tegangan pada motor BLDC menggunakan metode
semua komponen elektronik. debugging
Aplikasi RViz dapat memantau Diujinya penggunaan RViz untuk
pengontrolan sistem secara melihat hasil pengontrolan otonom
8 otomatis ketika bergerak secara real-time
menggunakan sistem otonom
robot operating system

79
D.2.2 Kebutuhan Non-Fungsional
Kebutuhan non-fungsionalitas pada sistem ini terbagi menjadi dua kebutuhan
yaitu perangkat keras dan perangkat lunak yang diperlukan untuk menunjang
sistem.
D.2.2.1 Kebutuhan Perangkat Keras
1. Motherboard Hoverboard

Gambar 4.38 Perangkat Motherboard Hoverboard

Sumber: (aliexpress.com, 2021)
Pada gambar 4.2 dapat dilihat pinout dari motherboard hoverboard yang
memiliki banyak pin di bagian bawah. Motherboard Hoverboard digunakan
sebagai driver dan controller pada motor BLDC. Hoverboard motherboard
menjadi komponen penting yang menyimpan data firmware yang telah di
flash sebelumnya. Motherboard merupakan komponen wajib yang ada pada
penelitian, ini dikarenakan tanpa adanya motherboard hoverboard maka
tidak akan bisa mengendalikan motor dan akan sangat sulit jika
menggunakan motor BLDC driver eksternal karena permasalahan biaya dan
kompatibilitas dengan firmware yang ada. Berikut adalah spesifikasi yang
diambil dari datasheet motherboard hoverboard yang ditunjukkan pada tabel
4.2.
Tabel 4.8 Spesifikasi Motherboard Hoverboard
Sumber: (beta.ivc.no dan www.st.com, 2021)
Keterangan Spesifikasi
Prosesor GD32F103RCT6 ARM Cortex-M3 32-bit MCU
Flash memory 256 KB sampai 512 KB
SRAM 64 KB
Clock speed 108MHz
Flasher ST-Link V2 Programming Unit

80
 Tegangan operasi 36V
Pengisian daya 42V 2A
Port Fast I/O 80 Port (45P, 9ADC, 16PWM, 6RXTX, 4SC, 3.3V,
5V, GND)
Kekuatan putaran maksimal 1000 r.p.m. 1-25A 350W
Tegangan dan arus DC Pin 5V 100mA
I/O motor
Tegangan dan arus DC Pin 15V 200mA
I/O sensor
Komunikasi USART, SPI, I2C, I2S, USB

2. Nvidia Jetson Nano

Nvidia Jetson Nano merupakan pemrosesan inti dari sistem pada
penelitian ini, fungsinya sebagai tempat pemrosesan input dari ketiga sensor
dan menjalankan fungsi mulai dari lokalisasi, pemetaan dan perencanaan
jalur serta komunikasi VNC pada slave (komputer). Semua metode, algoritme
dan komunikasi yang digunakan akan diproses di dalam sini. Alasan dipilihnya
Jetson Nano sebagai mikrokomputer dan pemrosesan utama adalah
pertimbangan kemampuan dari perangkat ini yang memiliki CPU Quad-core
dengan clock speed 1.43 GHz dan RAM sebesar 4 GB LPDDR. Gambar 4.3
merupakan bentuk fisik dari Nvidia Jetson Nano

Gambar 4.39 Nvidia Jetson Nano

Sumber: (www.nvidia.com, 2022)
Dengan spesifikasi seperti ini diharapkan Nvidia Jetson Nano mampu
melakukan pemrosesan mapping dan navigation. Proses pemetaan
menggunakan sumber daya yang cukup banyak karena terdapat banyak
sistem ROS yang berjalan di belakang layar ditambah dengan sistem
perencanaan gerak menggunakan Dijkstra yang banyak menguras CPU untuk
menemukan jalur terpendek. Memori RAM sebesar 4 GB dirasa sudah
mumpuni untuk menjalankan semua proses ini. Walaupun pemrosesan pada

81
 RViz dilakukan di Slave atau Komputer, akan tetapi untuk melakukan load
data hasil pemetaan juga dibutuhkan sumber daya CPU dan RAM yang besar.
Oleh karena itu, kesimpulannya adalah Nvidia Jetson Nano mampu
menjalankan sistem secara baik pada penelitian ini. Berikut adalah datasheet
dari mikrokontroler Jetson Nano 3B yang ditunjukkan pada tabel 4.3.
Tabel 4.9 Spesifikasi Mikrokontroler Jetson Nano 3B
Sumber: (developer.nvidia.com, 2021)
Keterangan Spesifikasi
CPU Quad-core ARM A57 @ 1.43 GHz
NVIDIA Maxwell architecture with 128 NVIDIA
GPU
CUDA® cores
Memory 4 GB 64-bit LPDDR4, 1600MHz 25.6 GB/s
Storage microSD
4K @ 30 | 4x 1080p @ 30 | 9x 720p @ 30
Video Encode
(H.264/H.265)
4K @ 60 | 2x 4K @ 30 | 8x 1080p @ 30 | 18x
Video Decode
720p @ 30 (H.264/H.265)
Kamera 2x MIPI CSI-2 DPHY
Konektivitas Gigabit Ethernet, M.2 Key E
Display HDMI 2.0 and display port
USB 4x USB 3.0, USB 2.0 Micro-B
Lainnya GPIO, I2C, I2S, SPI, USART
Mechanical 69.6 mm x 45 mm 260-pin edge connector
Memory External 64GB Mikro SD
Power Micro USB 5V 2.5A and DC Barrel Jack 5V 4A

3. Motor DC Brushless dan build-in encoder

Gambar 4.40 Perangkat Motor BLDC Hoverboard

Sumber: (www.jaxlec.top, 2021)

82
 Motor BLDC menggunakan pengontrol loop tertutup elektronik untuk
mengalihkan arus DC ke putaran kawat motor yang menghasilkan medan magnet
yang secara efektif berputar di ruang angkasa dan yang diikuti oleh rotor magnet
permanen. Kontroler menyesuaikan fase dan amplitudo pulsa arus DC untuk
mengontrol kecepatan dan torsi motor. Sistem kontrol ini merupakan alternatif
dari komutator mekanis (sikat) yang digunakan di banyak motor listrik
konvensional. Motor BLDC digunakan sebagai aktuator utama penggerak robot
bergerak otonom, berikut adalah datasheet motor dc brushless yang ditunjukkan
pada tabel 4.4 dan bentuk fisik dari motor BLDC hoverboard ditunjukkan pada
gambar 4.4.
Tabel 4.10 Spesifikasi Motor DC Brushless
Sumber: (www.aliexpress.com, 2021)
Keterangan Spesifikasi
Komunikasi Brushless
Kecepatan 5 - 1500 RPM
Tegangan 36V
Arus 1A - 25A
Power Motor 250 - 350W
Kecepatan Maksimal 26km/h
Kecepatan rata-rata 800 RPM
Diameter roda 6.5”

4. Catu Daya

Gambar 4.41 Baterai Hoverboard

Sumber: (ubuy.com, 2020)
Catu daya merupakan hal penting dari sistem yang digunakan untuk penyedia
sumber tegangan untuk mengaktifkan keseluruhan sistem. Selain itu, catu daya
tergolong jenis yang portabel dengan daya tampung energi listrik yang dapat diisi
ulang kembali. Untuk penggunaan catu daya harus dapat menyesuaikan
tegangannya yang dibutuhkan oleh sistem (Cahyadi, et al., 2016). Ada dua catu
daya yang digunakan pada robot ini, pertama yaitu baterai li-ion dengan besar

83
tegangan 32V dan kuat arus 2A. Catu daya ini digunakan untuk memberikan
power ke motherboard hoverboard dan yang nantinya akan disalurkan lagi ke
motor BLDC. Bentuk fisik dari baterai ini dapat dilihat pada gambar 4.5.
Kemudian catu daya yang kedua adalah power bank ke Jetson Nano dengan
besar tegangan 5V dan kuat arus 1A. Berikut adalah tabel spesifikasi Baterai Li-
ion 10S2P dan Power bank yang masing-masing ditunjukkan pada tabel 4.5 dan
tabel 4.6.
Tabel 4.11 Spesifikasi Catu Daya untuk Suplai Motherboard Hoverboard
Sumber: (www. hovertech.co.za, 2021)
Keterangan Spesifikasi
Tipe Baterai Litium-Ion
Ukuran Cell 18650 Litium Ion
Tegangan ke motherboard 25.2V - 36V
Arus sistem kerja 1A - 20A
Maksimal pemakaian arus 15A
Tegangan Pengisian 43.2V
Kapasitas 4400 mAh
Struktur 10S2P
Tabel 4.12 Spesifikasi Catu Daya untuk Suplai Jetson Nano
Sumber: (www.shopee.co.id, 2021)
Keterangan Spesifikasi
Tipe Baterai Lithium Polymer
Output 1 USB A DC 5V/3A, 9V/2A, 12V/1,5A
Output 2 USB A DC 5V/3A, 9V/2A, 12V/1,5A
Output 3 Type C 5V/3A, 9V/2,33A, 12V/1,7A
Kapasitas 10000 mAh

5. Sensor RPLiDAR A1

Gambar 4.42 Sensor RPLiDAR A1

Sumber: (amazon.com, 2022)

84
 Pada gambar 4.6 ditunjukkan bentuk fisik dari sensor RPLiDAR yang
digunakan pada penelitian ini. Terdiri dari sensor RPLiDAR, kabel socket, dan
converter port lidar ke mikro USB. RPLiDAR A1 digunakan sebagai input utama
dari sistem berupa tangkapan jarak dari tembakan laser yang nantinya akan
diproses oleh sistem. Penggunaan RPLiDAR didasarkan dari kemampuannya
mendeteksi objek seluas 360 derajat dan sejauh 6 meter. Selain itu RPLiDAR juga
sangat praktis untuk digunakan karena kita tidak perlu menghitung nilai ataupun
kalibrasi data karena RPLiDAR memiliki prosesornya sendiri dan mampu
mengirimkan data setengah jadi berupa koordinat-koordinat data jarak. Atas
semua pertimbangan dan kemampuannya yang powerful maka dari itu RPLiDAR
dipilih menjadi sensor utama pada penelitian ini. Berikut adalah spesifikasi
sensor RPLiDAR yang ditunjukkan pada tabel 4.7.
Tabel 4.13 Spesifikasi RPLiDAR A1
Sumber: (www.slamtec.com, 2021)
Keterangan Spesifikasi
Measuring Range 0.15 – 12 meter
Angular Field of View 0 - 360°
Angular Resolution: ≤1°
Sampling frequency 4000 - 8000 Hz
Rotational Speed 5.5Hz
Laser wave length 775 - 795nm
Pulse width 110 us
System Voltage 5V
System Current 100mA
Power Consumption 0.5W
Output USART Serial 3.3 Voltage level
≤1% of the range（≤12m)
Range Resolution
≤2% of the range（12m～16m)
1% of the range（≤3 m）
Accuracy 2% of the range（3-5 m）
2.5% of the range（5-25m）

6. Sensor IMU GY-521

85
 Gambar 4.43 Sensor GY-521 IMU6050
Sumber: (geekbuying.com, 2022)
Sensor GY-521 memiliki 3 DOF akselerometer dan 3 DOF giroskop yang dapat
mendeteksi nilai akselerasi dan gerakan roll, pitch atau yaw pada robot. Sensor
GY-521 digunakan sebagai input dari sistem berupa mendeteksi posisi robot
secara lokal. Hal ini sangat berguna dalam proses lokalisasi, walaupun proses
lokalisasi dapat dilakukan hanya dengan menggunakan data dari Odometer, akan
tetapi masih perlu dilakukan validasi lebih lanjut lagi menggunakan sensor yang
mampu membaca akselerasi robot. Ini dikarenakan terkadang ketika motor BLDC
tersangkut atau berputar di tempat maka data yang dikirimkan akan dianggap
sedang melakukan suatu gerakan. Tentunya hal ini tidak diinginkan karena dapat
membuat robot tidak bergerak semestinya dan posisinya akan berbeda ketika di
aplikasi RViz dan keadaan didunia riil. Maka dari itu atas pertimbangan ini, sensor
GY-521 dipilih karena sangat dibutuhkan untuk memvalidasi nilai dari Odometer
dan membuat robot untuk tetap diposisi semestinya walaupun motor BLDC
berputar di tempat. Berikut adalah spesifikasi sensor IMU GY-512 yang
ditunjukkan pada tabel 4.8 dan bentuk fisik dari sensor GY-521 yang digunakan
ditunjukkan pada gambar 4.7.
Tabel 4.14 Spesifikasi Sensor IMU GY-521 MPU6050
Sumber: (www. berrybase.de, 2022)
Keterangan Spesifikasi
Chipset MPU-5060
Tegangan sistem kerja 3.3 - 5V DC
Jalur Komunikasi I2C up to 400kHz
Range Gyroscope 250, 500, 1000, 2000/s
Range Gyroscope 2, 4, 6, 8, 16g
Pin VCC, RX, TX, GND, RST, B0, SCL, SDA

7. Wi-Fi Dongle
Wi-Fi dongle digunakan sebagai Wi-Fi extension karena Jetson Nano tidak
memiliki modul Wi-Fi setelah pabrik. Wi-Fi dongle akan menjadi komunikasi
utama robot dengan komputer server.
8. Tombol Power On-Off
Tombol power on-off digunakan untuk menyalakan atau mematikan
perangkat robot. Tombol ini berupa push button yang kondisinya hanya 1 dan 0.
9. Adapter dan Port Charger Hoverboard
Adapter charger baterai digunakan untuk mengisi ulang daya dari baterai
hoverboard. Adapter ini merupakan adapter AC ke DC yang nantinya ditancapkan
pada lubang port adapter yang terhubung langsung ke motherboard hoverboard.
10. STLink V2
86
 STLink bukanlah bagian dari komponen utama robot, alat ini digunakan
dalam proses flashing motherboard hoverboard. Tepatnya STlink berfungsi
sebagai perantara USB Flashing antara komputer dengan motherboard. Flashing
dilakukan untuk reset semua kode yang ada di motherboard sekaligus
menuliskan ulang motherboard dengan kode baru yang sudah di modifikasi.
Spesifikasi dari STLink yang digunakan pada penelitian ini dapat dilihat pada tabel
4.9.
Tabel 4.15 Datasheet STLink V2 mini USB
Sumber: (www.waveshare.com, 2022)
Keterangan Spesifikasi
SWD voltage range 1.65V - 3.6V
SWIM voltage range 1.65V - 5.5V
Supports SWV No
Debug interfaces 2
LED indicator Dual color LED

11. FTDI mini USB F23RL

FTDI merupakan kepanjangan dari Future Technology Devices International
yang merupakan nama perusahaan semiconductor yang mengkhususkan diri
dalam teknologi Universal Serial Bus. FTDI digunakan untuk komunikasi serial
Jetson Nano dengan motherboard hoverboard menggunakan protokol serial
USART. FTDI akan terhubung dengan kabel sensor kanan dari hoverboard yang
memiliki pin RX/TX dan akan ditancapkan dengan port USB pada Jetson Nano.
12. Komputer (Personal komputer)
Komputer yang dimaksud merupakan sebuah komputer pribadi fleksibel yang
dapat dijinjing dengan mudah atau dengan kata lain adalah laptop. Pada
penelitian ini, komputer pribadi memiliki peran yang sangat penting dan banyak
berkontribusi pada penelitian ini. Personal komputer digunakan sebagai server
dan seterusnya penulis akan menggunakan kata komputer server sebagai
maksud dari komputer pribadi penulis. Komputer server digunakan sebagai
setting up Master - Slave pada robot operating system. Robot bergerak otonom
merupakan slave sedangkan komputer berperan sebagai master. Fungsi master
(komputer) adalah menerima semua jenis data feedback yang dikirim atau di
ekspor dari slave (robot) yang kemudian data-data tersebut dapat digunakan
untuk proses visualisasi menggunakan aplikasi third party.
13. Chassis papan kayu
Chassis merupakan rangka penyangga suatu struktur. Rangka penyangga
pada robot AMR terbuat dari gabungan papan kayu berukuran 40x40 cm
sejumlah 4 buah dengan ketebalan 2 cm yang digunakan sebagai bahan
pembuatan chassis robot. Papan kayu ini nantinya akan menjadi tempat

87
penyimpanan komponen utama seperti Jetson Nano dan bagian atasnya
berperan sebagai tutup sekaligus alas untuk tempat menaruh barang.
14. Filamen 3D print
Filamen 3D printer sebagai bahan utama tinta 3D printer. Chassis robot
menggunakan desain custom maka dari nantinya akan ada beberapa bagian yang
hanya bisa dibuat menggunakan mesin 3D printer. Jenis filamen yang digunakan
adalah PETG berwarna hitam sebanyak 2 kilogram.
15. 3D printer
3D Printer digunakan untuk mencetak bagian utama robot. Jenis 3D printer
yang digunakan pada penelitian ini adalah printer dengan jenis FDM bermerek
Creality CR-10S Pro dengan spesifikasi minimal panjang 30 cm, lebar 30 cm dan
tinggi 20 cm.
16. Kabel jumper
Kabel jumper digunakan untuk menghubungkan serial USART sensor kanan
motherboard dengan FTDI yang terhubung pada Jetson Nano melalui USB mini.
17. Kabel micro USB
Kabel micro USB digunakan untuk menghubungkan sensor RPLiDAR dengan
Jetson Nano melalui USB. Selain itu juga digunakan untuk menghubungkan
Jetson Nano ke catu daya, yakni Power bank.
D.2.2.2 Kebutuhan Non-Fungsional Perangkat Lunak
Kebutuhan non-fungsional adalah batasan dari sistem terhadap layanan yang
diberikan. Batasan tersebut dapat berupa waktu, batasan proses pengembangan
dan batasan terhadap standar tertentu.
1. Hoverboard Firmware
Firmware hoverboard tersimpan di dalam chip GD32 yang menjadi
pemrosesan utama hoverboard. Firmware ini dapat diubah dan dimanipulasi
nilainya dengan mengunggah file ekstensi biner ke dalam chip tersebut.
Penelitian ini akan menggunakan firmware yang dikembangkan oleh Emanuel
Feru dan komunitas hoverboard di GitHub pada link berikut,
https://github.com/EFeru/hoverboard-firmware-hack-FOC.
2. STM32Cube Programmer
Aplikasi STM32Cube Programmer digunakan untuk melakukan flashing pada
motherboard hoverboard. STM32CubeProgrammer dikirimkan dalam versi GUI
(antarmuka pengguna grafis) dan CLI (antarmuka baris perintah). Gambar 4.8
merupakan tampilan GUI dari aplikasi STM32Cube Programmer.

88
 Gambar 4.44 STM32Cube Programmer
3. Catkin workspace
Mengutip dari (Pyo, dkk., 2017) mengatakan bahwa ROS menggunakan
sistem pembuatan khusus ROS yang disebut catkin. Catkin mengacu pada sistem
build ROS yang pada dasarnya menggunakan CMake (Cross Platform Make) dan
lingkungan build dijelaskan dalam file 'CMakeLists.txt' di folder paket. CMake
dimodifikasi di ROS untuk membuat sistem build khusus ROS. Menurut (Pyo,
dkk., 2017) catkin merupakan salah satu metode workspace bertujuan untuk
memudahkan proses developing dan compiling, konsep ini sama dengan konsep
webpack yang ada pada web developing, diagram pohon dari struktur catkin
seperti yang terdapat pada gambar 4.9.

Gambar 4.45 Diagram pohon directory catkin workspace

Sumber: (www.medium.com/swlh, 2021)
4. ROS 1: Melodic Morenia

89
 Gambar 4.46 ROS Melodic
Sumber: (wiki.ros.org, 2018)
Saat ini ROS sudah mempunyai 2 major version dengan arsitektur yang
berbeda, yaitu ada ROS1 dan ROS2. Pada penelitian ini, penulis menggunakan
ROS1 dengan versi Melodic pada mikro komputer Jetson Nano dan
menggunakan versi Noetic pada komputer server. Perbedaan versi ini di karena
kan perbedaan versi Ubuntu pada Jetson Nano dan komputer server, akan tetapi
ROS mampu melakukan komunikasi antar perangkat walaupun memiliki versi
yang berbeda. ROS Melodic Morenia terutama ditargetkan pada rilis Ubuntu
18.04 (Bionic).
5. Terminator
Terminator atau terminal digunakan sebagai terminal pemerintah utama
dalam melakukan penelitian ini, hal ini dikarenakan fiturnya lebih kaya dari pada
terminal default milik Linux. Kelebihan terminal ini adalah mampu membelah
atau membagi tampilan tabnya menjadi beberapa bagian. Dikarenakan proses
untuk menjalankan file terjadi lewat terminal, untuk itu dibutuhkan terminal
yang mampu membelah diri di dalam satu tampilan Window.
6. Visual Studio Code (IDE)
Visual Studio Code atau yang biasa disingkat dengan VSCode merupakan
kode editor yang banyak digunakan oleh developer. Kode editor ini digunakan
karena kemudahan dalam auto koreksi dan kemudahan navigasi antar file. Selain
itu fitur debugging dalam melakukan tracking error akan sangat membantu
sekali.
7. Platform IO
Penggunaan extension Platform IO ini dikarenakan kemudahannya dalam
proses compiling dan flash ke motherboard hoverboard. Dengan cukup
melakukan 1 kali klik maka proses compile dan upload akan sekaligus dilakukan
sehingga mempercepat proses pengembangan robot di dalam penelitian ini.
8. Creality Slicer
Creality Slicer merupakan perangkat lunak pengiris digunakan dalam
pencetakan 3D untuk memotong model 3D menjadi beberapa lapisan (irisan) dan
90
menggambar jalur pencetakan yang dapat diikuti oleh mesin. Creality Slicer
adalah alat pengiris milik Creality, yang juga memproduksi banyak printer 3D
populer seperti seri Ender 3. Aplikasi ini dipakai sebelum melakukan pencetakan
3D, fungsinya adalah melakukan convert dari file ekstensi umum menjadi gcode,
sehingga 3D printer dapat mengenali file tersebut
9. VNC Viewer & VNC Server
VNC Viewer dan VNC Server merupakan software remote-control yang
memungkinkan untuk mengontrol komputer lain melalui koneksi network
(Richardson, dkk., 1998). Komputer server akan di install VNC Viewer sedangkan
Jetson Nano sebagai mikro komputer akan di install VNC Server. Kegunaan
perangkat lunak ini adalah untuk melakukan proses yang membutuhkan
tampilan user interface pada Jetson Nano.
10. RViz
Menurut (Pyo, dkk., 2017) RViz merupakan aplikasi Linux berbasis GUI yang
mendukung visualisasi dari Robot Operating System (ROS). Pada penelitian ini
RViz digunakan sebagai aplikasi untuk melihat sejauh mana pembuatan peta atau
mapping bekerja. Hampir setiap pengembangan ROS pasti menggunakan RViz
sebagai aplikasi visualisasinya. RViz memiliki fitur pendukung utama untuk
melakukan navigasi, yakni 2D Nav Goal. (Pyo, dkk., 2017) mengatakan bahwa
fitur ini mengirimkan data koordinat pada peta yang dijadikan fixed frame,
sehingga ketika robot sudah dilengkapi dengan sistem navigasi maka akan
terbuat sebuah path planning sehingga robot akan mengikuti arahan dari jalur
yang sudah dibuat dan di visualisasikan melalui RViz. Gambar 4.11 merupakan
tampilan antar muka aplikasi RViz.

Gambar 4.47 Tampilan Antarmuka RViz

11. rqt
Menurut (Pyo, dkk., 2017) rqt adalah kerangka kerja perangkat lunak ROS
yang mengimplementasikan berbagai alat GUI dalam bentuk plugin). Tools ini
masih dapat berjalan dalam metode mandiri tradisional, tetapi rqt memudahkan
untuk mengelola semua berbagai jendela di layar pada satu tampilan.
12. Hoverboard driver
91
 Hoverboard driver terdiri dari sekumpulan file dengan bahasa C++ yang
menjembatani antara perangkat lunak dengan firmware hoverboard.
Hoverboard driver berisikan library-library yang dibutuhkan untuk
mengendalikan hoverboard melalui node ROS. Driver ini tidaklah ditulis dari awal
oleh penulis, melainkan menggunakan driver dari pengembang lain yang
membuat tim untuk fokus mengembangkan driver hoverboard, link yang
digunakan sebagai berikut, https://github.com/alex-makarov/hoverboard-driver.
Dengan menggunakan driver ini kita dapat melakukan kontrol pada
hoverboard dengan mudah, hal ini karena driver ini sudah berisikan kode untuk
komunikasi firmware dengan komputer. Hoverboard driver memiliki beberapa
parameter pada paketnya yang digunakan sebagai konfigurasi pada robot. Nilai
dari parameter ini disesuaikan berdasarkan data nyata pada pengukuran robot
sesungguhnya. Tabel parameter yang digunakan paket Hoverboard driver dapat
dilihat pada tabel 4.10.
Tabel 4.16 Parameter Hoverboard Driver
Sumber: (wiki.ros.org, 2022)
No Parameter Keterangan
1 left_wheel Nama sambungan roda kiri
2 right_wheel Nama sambungan roda kanan
Diagonal matriks kovarians untuk
3 pose_covariance_diagonal
penerbitan pose odometri
Diagonal matriks kovarians untuk
4 twist_covariance_diagonal
penerbitan twist odometri
Ini digunakan untuk menjelaskan
5 wheel_separation_multiplier perbedaan antara model robot dan
robot nyata.
Periode yang diizinkan (dalam s)
6 cmd_vel_timeout diperbolehkan antara dua perintah
kecepatan yang berurutan.
Digunakan untuk mengisi child_frame_id
7 base_frame_id
dari pesan Odometry dan TF
Publikasikan ke TF secara langsung atau
8 enable_odom_tf
tidak
Jari-jari roda. Diharapkan mereka semua
9 wheel_radius
memiliki ukuran yang sama.
10 wheel_separation Jarak roda kiri dan kanan.
11 allow_multiple_cmd Setel ke true akan mengizinkan lebih dari
satu topik masukan ~/cmd_vel. Setel ke
_vel_publishers
false akan menyebabkan pengontrol
92
 mengerem jika ada lebih dari satu
publisher di ~/cmd_vel.
12 linear/x/min_velocity Kecepatan linier minimum (dalam m/s).
13 linear/x/max_velocity Kecepatan linier maksimum (dalam m/s)
Percepatan linier maksimum (dalam
14 linear/x/max_acceleration
m/s^2)
Kecepatan sudut minimum (dalam
rad/s). Mengatur ini ke 0,0 akan
15 angular/z/min_velocity
menonaktifkan rotasi berlawanan arah
jarum jam.
Kecepatan sudut maksimum (dalam
16 angular/z/max_velocity
rad/s)
Percepatan sudut minimum (dalam
17 angular/z/min_acceleration
rad/s^2)

13. RPLiDAR ROS driver

Menurut (RoboPeak Team, 2014) RPLiDAR driver adalah sekumpulan library
sebagainya yang menjembatani antara perangkat lunak dengan perangkat
RPLiDAR. Driver ini diciptakan langsung oleh tim riset dari perusahaan yang
menjual produk RPLiDAR A1, yaitu RoboPeak. Untuk melakukan download driver
bisa di download di GitHub resmi RoboPeak, link yang digunakan sebagai berikut:
https://github.com/robopeak/RPLiDAR_ros. Driver ini sudah bisa langsung di
gunakan tanpa harus melakukan pengaturan yang berarti. Tabel parameter yang
digunakan paket RPLiDAR ROS driver dapat dilihat pada tabel 4.11.
Tabel 4.17 Parameter RPLiDAR ROS Driver
Sumber: (wiki.ros.org, 2022)
No Parameter Keterangan
1 serial_port nama port serial yang digunakan di sistem Anda.
2 serial_baudrate kecepatan baud port serial
3 frame_id Frame id untuk perangkat RPLiDAR.
4 inverted menunjukkan apakah LiDAR dipasang terbalik.
5 angle_compensate menunjukkan apakah pengemudi perlu
melakukan kompensasi sudut.
6 scan_mode mode pemindaian lidar.

14. MPU6050 dan I2C driver

93
 MPU6050 merupakan driver sensor yang digunakan untuk menjembatani
sensor IMU 6050 dengan mikro komputer atau mikro kontroler. Sedangkan I2C
merupakan library untuk komunikasi jalur serial I2C antara kontroler dengan
sensor IMU. Untuk mendapatkan driver ini, kita bisa mengunduh driver
MPU6050 dan I2C driver pada link berikut:
- https://github.com/Brazilian-Institute-of-Robotics/mpu6050_driver
- https://github.com/Brazilian-Institute-of-Robotics/i2c_device_ros
Driver ini bertujuan untuk membaca nilai percepatan dari sensor akselerometer,
giroskop dan magnetometer. Dengan menggunakan driver ini kita mampu
mengakses sensor IMU dengan mudah. Tabel parameter yang digunakan paket
MPU6050 dan I2C driver dapat dilihat pada tabel 4.12.
Tabel 4.18 Parameter MPU6050 Driver
Sumber: (wiki.ros.org, 2022)
No Parameter Keterangan
1 bus_uri I2C Bus URI digunakan untuk berkomunikasi dengan
perangkat I2C
2 mpu_address Alamat I2C dari MPU6050 yang biasanya memiliki
alamat default 0x68
3 pub_rate Frekuensi dalam Hertz yang data IMU diterbitkan
4 frame_id Bingkai jika pesan IMU
5 axes_offsets Offset untuk memperbaiki nilai yang salah yang
disebabkan oleh misalignment. Nilai ini didapat setelah
melakukan kalibrasi
6 ki Konstanta PID yang digunakan dalam prosedur
kalibrasi.
7 kp Konstanta PID yang digunakan dalam prosedur
kalibrasi
8 delta Proses kalibrasi selesai ketika kesalahan mendekati nol
dengan presisi yang ditetapkan oleh delta

15. Hector SLAM library

Menurut (Kohlbrecher, dkk., 2014) Hector SLAM merupakan sekumpulan
paket fungsi atau library yang dipakai untuk membuat pemetaan. Library ini
bertujuan untuk melakukan pemetaan dan lokalisasi dengan mengandalkan data
dari laser. Library ini memiliki kemampuan melakukan mapping tanpa harus
mengetahui kondisi sekitarnya terlebih dahulu (Kohlbrecher, dkk., 2011). Fungsi-
fungsi pada paket ini tersedia pada directory GitHub pengembangnya yaitu
Technical University Darmstats, link yang digunakan sebagai berikut:

94
https://github.com/tu-darmstadt-ros-pkg/hector_slam. Hector SLAM library
memiliki dari beberapa library lagi di dalamnya, terdiri dari library hector
mapping, hector Geotiff, hector Trajectory, hector SLAM dan masih banyak lagi.
Tabel parameter yang digunakan paket robot pose EKF dapat dilihat pada tabel
4.13.
Tabel 4.19 Parameter Hector Mapping
Sumber: (wiki.ros.org, 2022)
No Parameter Keterangan
1 base_frame Nama rangka dasar robot. Ini adalah
frame yang digunakan untuk pelokalan
dan transformasi data pemindaian laser.
2 map_frame Nama dari frame peta
3 odom_frame Nama dari frame odometry
4 map_resolution Resolusi peta [m]. Ini adalah panjang tepi
sel grid.
5 map_size Ukuran [jumlah sel per sumbu] peta. Peta
berbentuk persegi dan memiliki sel kisi
(map_size * map_size).
6 map_start_x Lokasi asal [0.0, 1.0] bingkai /peta pada
sumbu x relatif terhadap peta kisi. 0,5 di
tengah.
7 map_start_y Lokasi asal [0.0, 1.0] bingkai /peta pada
sumbu y relatif terhadap peta kisi. 0,5 di
tengah.
8 map_update Ambang batas untuk melakukan
pembaruan peta.
_distance_thresh
9 map_update Ambang batas untuk melakukan
pembaruan peta.
_angle_thresh
10 map_multi_res_levels Jumlah tingkat petak multi-resolusi.
11 update_factor_free Pengubah pembaruan peta untuk
pembaruan sel gratis dalam kisaran.
12 update_factor_occupied Pengubah pembaruan peta untuk
pembaruan sel yang ditempati dalam
kisaran
13 laser_z_min_value Tinggi minimum [m] relatif terhadap
bingkai pemindai laser untuk titik akhir
pemindaian laser yang akan digunakan

95

14 laser_z_max_value
15 pub_map_odom_transform
16 tf_map_scanmatch
_transform_frame_name
oleh sistem
Tinggi maksimum [m] relatif terhadap
bingkai pemindai laser untuk titik akhir
pemindaian laser yang akan digunakan
oleh sistem
Tentukan apakah transformasi map-
>odom harus dipublikasikan oleh sistem.
Nama frame saat memublikasikan
scanmatcher ke transformasi peta seperti
yang dijelaskan dalam parameter
sebelumnya.

16. Robot Pose EKF Localization library

Menurut (Siegwart, Nourbakhsh dan Scaramuzza, 2004) algoritme EKF adalah
implementasi dari filter Kalman yang diperluas. Library termasuk ke dalam paket
eksternal dari ROS yang dapat langsung di install menggunakan perintah $ sudo
apt install ros-melodic-robot-pose-ekf. Library EKF digunakan baik dalam proses
mapping ataupun navigasi, hal ini dikarenakan kedua proses itu membutuhkan
metode untuk menggabungkan sensor agar peta yang dihasilkan menjadi lebih
baik atau yang disebut dengan teknik fusi sensor (Pyo, dkk., 2017). Output dari
paket ini adalah sebuah frame bernama odom_combined yang sudah dilakukan
koreksi nilai kesalahan data odometry dengan menggunakan data IMU. Tabel
parameter yang digunakan paket robot pose EKF dapat dilihat pada tabel 4.14.
Tabel 4.20 Parameter EKF Localization
Sumber: (wiki.ros.org, 2022)
No Parameter Keterangan
1 output_frame Nama frame dari odometry, dalam hal ini
adalah /odom
2 base_footprint_frame Nama frame dari base footprint
3 freq Frekuensi bernilai nyata dalam Hz, di mana filter
menghasilkan perkiraan keadaan
4 sensor_timeout Ketika sensor berhenti mengirimkan informasi
ke filter, berapa lama filter harus menunggu
sebelum melanjutkan tanpa sensor itu.
5 odom_used Aktifkan atau nonaktifkan input sensor
odometry
6 imu_used Aktifkan atau nonaktifkan input sensor IMU
7 vo_used Aktifkan atau nonaktifkan input sensor visual

96
 odometry
8 gps_used Aktifkan atau nonaktifkan input sensor GPS
9 debug Parameter yang menentukan apakah akan
dijalankan dalam mode debug atau tidak.

17. ROS Navigation Stack: AMCL library

Menurut (Pyo, dkk., 2017) ROS navigation library merupakan sekumpulan
paket fungsi yang dipakai untuk proses path planning robot Library termasuk ke
dalam paket eksternal dari ROS yang dapat langsung di install menggunakan
perintah $ sudo apt install ros-melodic-navigation. Sedangkan AMCL atau
Adaptive Monte Carlo Localization adalah sistem lokalisasi probabilistik untuk
robot yang bergerak dalam 2D. Ini menerapkan pendekatan lokalisasi Monte
Carlo adaptif yang menggunakan filter partikel untuk melacak pose robot
terhadap peta yang diketahui (Pyo, dkk., 2017). AMCL digunakan pada lokalisasi
proses navigasi robot, yaitu dengan memanfaatkan data lidar dan hasil pemetaan
untuk mendapatkan lokasi dan pose terkini dari robot. Tabel parameter yang
digunakan paket AMCL dapat dilihat pada tabel 4.15.
Tabel 4.21 Parameter AMCL Localization
Sumber: (wiki.ros.org, 2022)
No Parameter Keterangan
1 odom_frame_id Frame mana yang digunakan untuk odometri.
2 odom_model_type Model mana yang akan digunakan, baik "diff",
"omni", "diff-corrected" atau "omni-corrected".
3 base_frame_id Bingkai mana yang digunakan untuk basis robot
4 update_min_d Jumlah partikel minimum yang diizinkan
5 update_min_a Jumlah partikel maksimum yang diizinkan
6 global_frame_id Nama kerangka koordinat yang diterbitkan oleh
sistem lokalisasi
7 tf_broadcast Setel ini ke false untuk mencegah amcl
memublikasikan transformasi antara frame
global dan frame odometri.
8 initial_pose_x Mean pose awal (x), digunakan untuk
menginisialisasi filter dengan distribusi
Gaussian.
9 initial_pose_y Pose awal mean (y), digunakan untuk
menginisialisasi filter dengan distribusi
Gaussian.
10 initial_pose_a Pose mean awal (yaw), digunakan untuk
97
 menginisialisasi filter dengan distribusi
Gaussian.

18. ROS Navigation Stack: Move base library

Menurut (Pyo, dkk., 2017) di dalam paket ROS navigation stack terdapat
paket move base yang merupakan paket utama untuk mengirimkan pesan twist
yang nantinya di konversi. Di dalam paket ini juga terdapat base global planner
untuk path planning secara global, DWA local planner untuk path planning local
serta dan masih banyak lagi (Pyo, dkk., 2017). Semua ini tentunya berisikan
fungsi-fungsi yang bertujuan untuk menunjang sistem navigasi robot. Paket
move base melakukan subscribe pada beberapa topik antara lain,
move_base/goal yang merupakan sebuah koordinat tujuan untuk di capai robot
dan move_base/cancel yang merupakan permintaan untuk membatalkan tujuan
tertentu. Output dari paket ini adalah sebuah topic yang digunakan untuk
menggerakkan robot, yaitu cmd_vel. Parameter yang digunakan pada paket ini
dapat dilihat pada tabel 4.16
Tabel 4.22 Parameter Move Base
Sumber: (wiki.ros.org, 2022)
No Parameter Keterangan
1 base_global_planner Nama plugin untuk perencana global
untuk digunakan dengan move_base
2 base_local_planner Nama plugin untuk perencana lokal untuk
digunakan dengan move_base
3 recovery_behaviors Daftar plugin perilaku pemulihan untuk
digunakan dengan move_base
4 controller_frequency Laju dalam Hz untuk menjalankan loop
kontrol dan mengirim perintah kecepatan
ke pangkalan.
5 planner_patience Berapa lama perencana akan menunggu
dalam hitungan detik dalam upaya untuk
menemukan rencana yang valid sebelum
operasi pembersihan ruang dilakukan.
6 controller_patience Berapa lama pengontrol akan menunggu
dalam hitungan detik tanpa menerima
kontrol yang valid sebelum operasi
pembersihan ruang dilakukan.
7 conservative_reset_dist Jarak dari robot dalam meter di mana
rintangan akan dibersihkan dari peta biaya
saat mencoba mengosongkan ruang di
peta

98
 8 recovery_behavior_enabled Apakah akan mengaktifkan perilaku
pemulihan move_base atau tidak untuk
mencoba mengosongkan ruang
9 clearing_rotation_allowed Menentukan apakah robot akan mencoba
melakukan rotasi di tempat atau tidak
saat mencoba mengosongkan ruang
10 shutdown_costmaps Menentukan apakah akan mematikan
peta biaya node atau tidak saat
move_base dalam keadaan tidak aktif
11 oscillation_timeout Berapa lama dalam detik untuk
memungkinkan osilasi sebelum
menjalankan perilaku pemulihan
12 oscillation_distance Berapa jauh dalam meter robot harus
bergerak agar dianggap tidak berosilasi
13 planner_frequency Laju dalam Hz untuk menjalankan loop
perencanaan global
14 max_planning_retries Berapa kali untuk memungkinkan
perencanaan ulang sebelum menjalankan
perilaku pemulihan

Parameter paket move base hanya berisikan variabel untuk menentukan

plugin dari perencanaan jalur global dan lokal. Terdapat beberapa parameter
penting yang menjadi konfigurasi pada proses navigasi. Pada dokumentasi ROS
hal ini disebut dengan Component APIs. Node move_base berisi komponen yang
memiliki ROS API sendiri. Komponen ini dapat bervariasi berdasarkan nilai
masing-masing yang terdiri dari global costmap, local costmap, global planner,
local planner, dan recovery behaviors. Global costmap adalah semua yang
diketahui robot dari kunjungan sebelumnya dan pengetahuan yang tersimpan
misalnya peta. Sedangkan Local costmap adalah segala sesuatu yang dapat
diketahui dari posisi saat ini dengan sensor yang tepat. Misalnya. orang berjalan
dan benda bergerak lainnya, serta setiap dinding yang dapat dilihat.
Parameter yang ada pada costmap memiliki kesamaan hanya berbeda di
penggunaan dan topik yang akan di subscribe, maka dari itu penjelasan
mengenai parameter global costmap dan local costmap akan dijadikan satu tabel
saja. Berikut ini akan dijelaskan parameter-parameter apa saja yang ada pada
setiap komponen yang sudah disebutkan sebelumnya. Untuk parameter
komponen 2D costmap dapat dilihat pada tabel 4.17, sedangkan untuk
komponen global planner dapat dilihat pada tabel 4.18 dan local planner 4.19.
Tabel 4.23 Parameter Konfigurasi 2D Costmap
Sumber: (navigation.ros.org, 2022)
No Parameter Keterangan
99
1 Apakah akan cost map secara lengkap
always_send_full_costmap
setiap pembaruan, bukan pembaruan.
2 footprint_padding Jumlah alas pad footprint (m).
3 Kumpulan titik jejak yang dipesan yang
footprint diteruskan sebagai string, harus disetel
tertutup
4 global_frame Frame referensi global
5 height Tinggi cost map.
6 width Mebar cost map
7 Biaya minimum occupancy grid dianggap
lethal_cost_threshold
sebagai hambatan yang mematikan.
8 map_topic Topik peta dari map_server atau SLAM.
9 Daftar sumber sensor sebagai string,
observation_sources untuk digunakan jika tidak ditentukan
dalam konfigurasi khusus plugin
10 X asal peta biaya relatif terhadap lebar
origin_x
(m).
11 Y asal peta biaya relatif terhadap tinggi
origin_y
(m).
12 Frekuensi untuk mempublikasikan
publish_frequency
costmap ke topik.
13 resolution Resolusi 1 piksel peta biaya, dalam meter.
14 robot_base_frame Frame referensi robot base
15 Jari-jari robot untuk digunakan, jika
robot_radius
koordinat tapak kaki tidak disediakan.
16 Apakah peta biaya harus digulung dengan
rolling_window
bingkai dasar robot.
17 Jika salah, perlakukan ruang yang tidak
track_unknown_space diketahui sebagai ruang kosong, yang lain
sebagai ruang yang tidak diketahui.
18 transform_tolerance Toleransi transformasi TF.
19 ika peta kisi hunian harus ditafsirkan
sebagai hanya 3 nilai (bebas, terisi, tidak
trinary_costmap
diketahui) atau dengan nilai yang
tersimpan.

100
20 Biaya ruang yang tidak diketahui jika
unknown_cost_value
melacaknya.
21 update_frequency Frekuensi pembaruan peta biaya.
22 apakah saat menggabungkan peta biaya
use_maximum
untuk menggunakan biaya maksimum
23 Daftar nama plugin yang dipetakan untuk
plugins
ruang nama dan nama parameter
24 Daftar nama filter peta biaya yang
filters dipetakan untuk ruang nama dan nama
parameter.
25 Plugin untuk cost map static layer seperti
plugins/static_layer
peta
26 Plugin untuk cost map obstacle layer
plugins/ obstacle_layer
seperti data laser
27 Plugin untuk melipat gandakan ukuran
plugins/ inflation_layer
costmap
Tabel 4.24 Parameter Konfigurasi Dijkstra Global Planner
Sumber: (wiki.ros.org, 2022)
No Parameter Keterangan
1 allow_unknown Menentukan apakah akan mengizinkan
perencana membuat rencana yang melintasi
ruang yang tidak diketahui atau tidak
2 default_tolerance Sebuah toleransi pada titik tujuan untuk
perencana. Path planner akan mencoba
membuat rencana yang sedekat mungkin
dengan tujuan yang ditentukan tetapi tidak
lebih jauh dari default_tolerance.
3 visualize_potential Menentukan apakah akan memvisualisasikan
area potensial yang dihitung melalui
PointCloud2 atau tidak.
4 use_dijkstra Jika ya, gunakan algoritma dijkstra. Jika tidak,
A*.
5 old_navfn_behavior Jika karena alasan tertentu, kita ingin
global_planner benar-benar mencerminkan
perilaku navfn, setel ini ke true (dan gunakan
default untuk parameter boolean lainnya)
6 lethal_cost Biaya dari lethal area pada konfigurasi ulang
secara dinamis

101
7 neutral_cost Biaya dari netral area pada konfigurasi ulang
secara dinamis
8 cost_factor Faktor yang mengalikan beberapa biaya dari
biaya peta pada konfigurasi ulang secara
dinamis
9 publish_potential Publikasikan Peta Biaya Potensial pada
konfigurasi ulang dinamis
10 orientation_mod Cara mengatur orientasi setiap titik
11 orientation_window_size Window mana yang digunakan untuk
menentukan orientasi berdasarkan turunan
posisi yang ditentukan oleh mode orientasi
12 outline_map Menguraikan peta biaya global dengan
rintangan mematikan. Untuk penggunaan
peta biaya global non-statis (jendela
bergulir), ini perlu disetel ke false

Tabel 4.25 Konfigurasi DWA Local Planner

Sumber: (wiki.ros.org, 2022)
No Parameter Keterangan
1 acc_lim_x Batas percepatan x robot dalam
meter/detik^2
2 acc_lim_y Batas percepatan y robot dalam
meter/detik^2
3 acc_lim_th batas percepatan rotasi robot dalam
radian/detik^2
4 max_vel_trans Nilai absolut dari kecepatan translasi
maksimum untuk robot dalam m/s
5 min_vel_trans Nilai absolut dari kecepatan translasi
minimum untuk robot dalam m/s
6 max_vel_x Kecepatan x maksimum untuk robot dalam
m/s.
7 min_vel_x Kecepatan x minimum untuk robot dalam
m/s, negatif untuk gerak mundur.
8 max_vel_y Kecepatan y maksimum untuk robot dalam
m/s
9 min_vel_y Kecepatan y minimum untuk robot dalam m/s
10 max_rot_vel Nilai mutlak kecepatan putar maksimum

102
 robot dalam rad/s
11 min_rot_vel Nilai mutlak kecepatan putar minimum robot
dalam rad/s
12 yaw_goal_tolerance Toleransi dalam radian untuk pengontrol
dalam yaw/rotasi saat mencapai tujuannya
13 xy_goal_tolerance Toleransi dalam meter untuk pengontrol
dalam jarak x & y saat mencapai tujuan
14 latch_xy_goal_ Jika toleransi tujuan terkunci, jika robot
pernah mencapai lokasi tujuan xy, ia hanya
tolerance
akan berputar di tempatnya, bahkan jika itu
berakhir di luar toleransi tujuan saat
melakukannya.
15 sim_time Parameter untuk simulasi. Jumlah waktu
untuk meneruskan simulasi lintasan dalam
hitungan detik
16 sim_granularity Parameter untuk simulasi. Ukuran langkah,
dalam meter, untuk mengambil antara titik
pada lintasan tertentu
17 vx_samples Parameter untuk simulasi. Jumlah sampel
yang akan digunakan saat menjelajahi ruang
kecepatan x
18 vy_samples Parameter untuk simulasi. Jumlah sampel
yang akan digunakan saat menjelajahi ruang
kecepatan y
19 vth_samples Parameter untuk simulasi. Jumlah sampel
yang akan digunakan saat menjelajahi ruang
kecepatan theta
20 controller_frequency Parameter untuk simulasi. Frekuensi di mana
pengontrol ini akan dipanggil dalam Hz.
21 path_distance_bias Pembobotan untuk seberapa banyak
pengontrol harus tetap dekat dengan jalur
yang diberikan
22 goal_distance_bias dia menimbang berapa banyak pengontrol
harus berusaha mencapai tujuan lokalnya,
juga mengontrol kecepatan
23 occdist_scale Pembobotan untuk seberapa banyak
pengontrol harus berusaha menghindari
rintangan
24 forward_point_distance Jarak dari titik pusat robot untuk

103
 menempatkan titik penilaian tambahan,
dalam meter
25 stop_time_buffer Jumlah waktu robot harus berhenti sebelum
tabrakan agar lintasan dianggap valid dalam
hitungan detik
26 scaling_speed Nilai absolut dari kecepatan untuk mulai
menskalakan jejak robot, dalam m/s
27 max_scaling_factor Faktor maksimum untuk menskalakan jejak
robot
28 publish_cost_grid Apakah akan mempublikasikan kisi biaya yang
akan digunakan perencana saat
merencanakan atau tidak
29 oscillation_reset_dist Seberapa jauh robot harus berjalan dalam
meter sebelum tanda osilasi direset
30 prune_plan Menentukan apakah akan memakan rencana
saat robot bergerak di sepanjang jalan.

104
 BAB E PERANCANGAN DAN IMPLEMENTASI

Dalam bab perancangan dan implementasi, penulis akan menjabarkan

tahapan perancangan dari sistem secara skematis hingga
pengimplementasiannya secara riil. Di dalam bab ini penulis akan menjelaskan
mengenai perancangan dan implementasi dari sistem yang digunakan pada
penelitian. Perancangan di sini mencakup perancangan secara fisik yang berupa
wiring dan assembling, serta perancangan secara perangkat lunak dengan
perancangan arsitektur dibangunnya sistem robot dan komunikasi. Sementara
itu implementasi terfokus pada aspek bagaimana sistem tersebut berhasil
dibentuk di dunia riil dan bagaimana pemrograman sistem ini bekerja. Hasil dari
perancangan sistem kemudian direalisasikan dan dijelaskan pada implementasi
sistem. Oleh karena itu disusunlah proses bagaimana merancang sistem dan
mengimplementasikannya sebagai berikut.

E.1 Perancangan Sistem

Perancangan sistem bertujuan untuk memahami cara kerja beserta alur kerja
sistem, seperti apa yang nantinya akan dibuat sehingga dalam penjelasannya
dalam perancangan sistem nantinya akan lebih terstruktur dan lebih sistematis.
Perancangan sistem dibagi menjadi tiga bagian yaitu perancangan skematis
arsitektur sistem, perancangan perangkat keras, dan perancangan perangkat
lunak.

E.1.1 Perancangan Skematis Prototype Sistem

Gambar 5.48 Desain Chassis Badan Depan Robot

Prototype dari autonomous mobile robot dirancang dengan menggabungkan
3 komponen utama, yaitu chassis robot, robot beroda, dan sensor robot. Chassis
robot dibuat dengan ukuran 40x40 cm berbahan kayu dengan ketebalan 2 cm.
Pembuatan chassis ini cukup mudah, dari ke-4 papan kayu yang sudah disiapkan
dipilih 1 papan sebagai alas. Kemudian papan ke-2 digunakan sebagai pembatas
sisi dengan memotong papan tersebut menjadi 4 buah bagian dengan lebar
masing-masing 10 cm. Lalu papan ke-3 dipotong dengan lebar 20 cm yang akan

105
dijadikan sebagai penghubung sisi bagian belakang. Terakhir, papan ke-4
dibiarkan utuh yang nantinya digunakan sebagai penutup chassis. Untuk detail
bentuk dari chassis ini dapat dilihat pada gambar 5.1. Selanjutnya untuk bagian
chassis robot beroda yang merupakan komponen utama robot sebagai
penggerak dan dudukan motor. Terdiri dari gabungan hasil 3D print dan
komponen elektronik hoverboard. Keseluruhan desain 3D ini dapat dilihat pada
gambar 5.2.

Gambar 5.49 Desain Semua Bagian Cetak 3D

Desain dari komponen ini menggunakan desain dari proyek Hover Mower,
yang merupakan robot pemotong rumput. Didesain oleh Patrick Weber dan
dapat di download pada link berikut:
https://github.com/HoverMower/hovermower-chassis. Desain ini dapat
digunakan bebas karena menggunakan lisensi GPL 3, jadi diperbolehkan
menggunakan dan mengubah desain tersebut. Lisensi ini memperbolehkan untuk
keperluan pembelajaran, riset, dan keperluan komersial. Akan tetapi desain ini
tidak boleh diperjual belikan tanpa izin pembuatnya yakni Patrick Weber
(https://hobby.weberpatrick.de). Pada bagian kedua sepatbor dijepit
menggunakan baut M4, sedangkan bagian tutup cukup dijepit menggunakan
baut M3. Semua komponen yang akan diberikan baut dipasangkan terlebih
dahulu brass knurled sebagai dudukan untuk baut. Hasil dari gabungan semua
desain ini dapat dilihat pada gambar 5.3.

106
 Gambar 5.50 Assembling Semua Bagian Chassis Belakang Robot

Komponen utama kedua adalah robot beroda yang menjadi penggerak

utama dan tempat pemrosesan gerak robot. Bagian ini di isi oleh motherboard
hoverboard, motor BLDC, baterai 10S2P, power button, dan kabel-kabel yang
terhubung langsung dengan motor DC. Untuk lebar dari mainboard itu sendiri
sekitar 40 cm dengan panjang 25 cm yang detailnya dapat dilihat pada gambar
5.4.

Gambar 5.51 Rancangan Sistem Kemudi Utama Robot

Sistem kemudi yang digunakan pada robot ini menggunakan kemudi dua
buah roda berputar independen yang dikenal sebagai Differential Drive. Metode
kemudi ini memanipulasi nilai RPM tiap rodanya untuk mendapatkan gerak maju
atau berputar. Metode ini disediakan pada paket ROS navigation, sehingga kita
tidak perlu melakukan pemrograman atau perhitungan secara manual
berdasarkan rumus Kinematik seperti yang dapat dilihat pada gambar 5.5.

107
 Gambar 5.52 Grafik Kinematik Sistem Kemudi Diff-drive
Untuk menggerakkan atau mengemudikan robot kita hanya perlu
memublikasikan pesan geometric_msgs/Twist ke topik cmd_vel. Cmd_vel
merupakan topik yang digunakan oleh paket move_base untuk mengirim
perintah navigasi. Twist message menggunakan m/s untuk satuan kecepatan
linier dan radian/s untuk satuan kecepatan sudut. Untuk melakukan gerak linier
adalah dengan mengalikan kecepatan linier dengan rasio linier dan atur setiap
roda ke kecepatan ini. Dengan menyamakan putaran tiap rasio roda maka akan
mendapatkan gerak lurus. Untuk melakukan gerakan sudut putar, caranya
hampir persis seperti gerak linier hanya saja kita perlu menemukan rasio yang
berbeda, antara radian per sekon dan output kontrol dan pastikan roda berputar
ke arah yang berlawanan. Untuk mendapatkan gerakan berbelok sedikit atau
gerak non-holonomic maka dibutuhkan sedikit kecepatan rasio disalah satu
rodanya. Gerakan ini sebenarnya merupakan gerakan linier dengan sedikit gerak
angular. Cukup tambahkan kecepatan sudut dan linier untuk setiap roda
bersama-sama untuk mendapatkan kecepatan akhir. Pada akhirnya, jelas
terdapat kecepatan maksimum yang dapat diputar oleh roda robot dan twist
message bisa melakukan ini dengan mudah. Jika kita menurunkan kecepatan
kedua roda dengan rasio yang sama sehingga berada dalam kisaran yang mampu
dilakukan motor, maka robot akan mengikuti lintasan yang sama seperti yang
diperintahkan oleh twist message tetapi pada kecepatan yang rendah.
Komponen utama ketiga adalah sensor robot yang terletak pada bagian
depan robot. Sensor terdiri dari sensor utama RPLiDAR, dan dua sensor untuk
lokalisasi yaitu sensor IMU dan build-in Odometer. Sensor ini berfungsi agar
robot mengetahui kondisi sekitarnya dan mampu mengambil keputusan path
planning. Gambar 5.6, gambar 5.7 dan gambar 5.8 merupakan gambar
Rancangan Prototype Keseluruhan Sistem yang terdiri dari bagian mainboard
robot beroda sebagai penggerak, chassis robot sebagai kerangka dan sensor
robot sebagai penglihatan dari robot. Semua desain ini dibuat menggunakan
aplikasi Autodesk Fusion 360 yang merupakan aplikasi untuk desain 3D yang
dikembangkan oleh Autodesk.

108
Gambar 5.53 Rancangan Prototype Keseluruhan Sistem Tampak Samping

109
 Gambar 5.54 Rancangan Prototype Keseluruhan Sistem Tampak Atas

Gambar 5.55 Rancangan Prototype Keseluruhan Sistem Tampak Bawah

Sistem ini merupakan implementasi pengembangan dari penelitian
sebelumnya yang dibahas pada bab 2 yang hanya berfokus pada mapping saja
atau navigasi saja. Fokus utama dari penelitian ini adalah menciptakan prototype
autonomous mobile robot yang mampu bergerak dari titik awal menuju titik
tujuan dengan menggabungkan mapping dan navigasi. Proses input titik
koordinat tujuan dapat dilakukan baik secara otomatis maupun manual. Proses
secara otomatis menggunakan metode penjadwalan dengan melakukan perintah
terminal dengan memanfaatkan fungsi waktu. Untuk proses manual
menggunakan tampilan antar muka RViz dan meletakkan 2D Nav Goal pada
aplikasi RViz. Pada penelitian ini, penulis akan menerapkan kedua metode ini
pada pengujian sistem. Navigasi menggunakan global dan lokal path planning,
sehingga sistem dapat bergerak pada lintasan dengan halangan statis dan
dinamis.

E.1.2 Perancangan Perangkat Keras Sistem

Subbab ini akan menjelaskan mengenai rancangan perangkat keras yang
digunakan pada penelitian ini. Pada subbab sebelumnya, penulis telah
menganalisis kebutuhan sistem yang selanjutnya akan dijelaskan proses kerja
dari perangkat keras menggunakan blok diagram. Blok diagram digunakan
sebagai alat untuk membantu pembaca dalam mengenali titik masalah atau
fokus perhatian secara cepat pada perangkat keras keseluruhan sistem.
Pembahasan dari sistem ini akan dibagi menjadi 2 fokus, antara lain sistem
kendali utama dan sistem robot hoverboard yang masing-masing tergabung
menjadi satu, hal ini dapat dilihat pada gambar 5.7.

110
 Gambar 5.56 Rancangan Perangkat Keras Sistem
Pada gambar 5.9 dapat diperhatikan bahwa sistem akan menggunakan
perangkat utama yang saling terintegrasi satu sama lain menggunakan beberapa
protokol komunikasi sebagai penghubung. Perangkat utama yang dimaksud
adalah Jetson Nano, personal komputer dan hoverboard motherboard,
sedangkan protokol komunikasi penghubung yang dimaksud adalah serial
protocol dengan FTDI mini USB dan VNC dengan jaringan Wi-Fi. Namun karena
Jetson Nano tidak memiliki modul Wi-Fi pada komponen utamanya, maka kita
perlu menambahkan modul berupa Wi-Fi dongle yang ditancapkan pada salah
satu port USB Jetson Nano. Berikut ini merupakan penjelasan mengenai sistem
kendali utama robot. Personal komputer atau komputer server berkomunikasi
dengan Jetson Nano menggunakan protokol komunikasi Virtual Network
Computing (VNC) pada jaringan yang saling terhubung dengan Wi-Fi yang sama.
Sedangkan untuk Jetson Nano dengan hoverboard motherboard menggunakan
111
komunikasi data serial USART melalui perangkat elektronik bernama FTDI mini
USB converter. Jetson Nano merupakan komponen utama penyusun sistem
penggerak.
Sistem penggerak berperan sebagai aktuator yang sekaligus mengirimkan
data berupa data odometry. Sistem ini terdiri dari motherboard hoverboard,
motor BLDC, baterai, power on/off dan Jetson Nano yang terhubung dengan FTDI
melalui komunikasi USART. Motherboard di sini berfungsi sebagai motor driver
utama yang mengatur arah putar dan kecepatan putar motor BLDC. Dengan
menggunakan 3 kabel phase di tiap sisi motor, motherboard hoverboard dapat
dengan mudah mengatur kecepatan dengan memanipulasi nilai voltase yang
dialirkan melalui 3 kabel phase ini. Berbeda dengan motor DC biasa yang
menggunakan VCC dan ground saja, motor BLDC memerlukan 3 kabel phase
untuk mengatur tegangan yang masuk di tiap phase magnetnya. Selain itu
dibutuhkan juga 5 pin hall sensor yang digunakan untuk mengetahui posisi
putaran robot sehingga didapatkan data Odometry pada motor BLDC. Untuk
mendeskripsikan rancangan keseluruhan sistem penggerak ini, dapat dilihat pada
gambar 5.10.

Gambar 5.57 Skema Sistem Penggerak Robot

Pada gambar 5.10 terdapat diagram skematis dari sistem gerak robot dimana
motherboard hoverboard yang berfungsi sebagai driver motor BLDC, terhubung
langsung dengan kabel phase, hall, on/off, charger dan supply. Kabel phase dan
kabel hall sudah dijelaskan sebelumnya, yakni untuk mengendalikan dan
mendapatkan data odometry dari motor BLDC. Kabel on/off power button
terhubung dengan soket yang sudah tersedia pada motherboard begitu pula
dengan kabel charger port. Kemudian untuk dapat berkomunikasi dengan Jetson

112
Nano, kita perlu menghubungkan motherboard dengan kabel sensor yang ada di
sisi bawah motherboard hoverboard.
Kedua sisi sensor motherboard hoverboard memiliki total 8 buah kabel yang
masing-masing terdiri dari VCC, RX, TX, dan ground. Kedua kabel ini seharusnya
terhubung dengan sensor giroskop pada hoverboard, namun kita bisa membuang
bagian sensor tersebut dan mengambil bagian motherboard saja. Namun secara
pabrikan, hoverboard tidak dibuat untuk tujuan ini maka diperlukan proses
flashing firmware pada motherboard hoverboard. Dari kedua port sensor ini, kita
hanya akan menggunakan kabel sensor sebelah kanan. Kabel sebelah kanan
digunakan karena tegangannya dapat mentoleransi komunikasi data dengan
tegangan maksimal 5V. Konfigurasi ini dapat dilihat pada datasheet jenis
motherboard hoverboard yang digunakan.
Hal ini dilakukan untuk menghindari kerusakan pada Jetson Nano yang mana
jika kita menggunakan kabel sensor sebelah kiri maka motherboard bisa saja
mengirimkan data dengan voltase sebesar 15V. Voltase sebesar itu tidak akan
bisa diterima oleh Jetson Nano dan hal ini akan memicu terjadi short aliran listrik
sehingga Jetson Nano bisa saja terjadi hubungan arus pendek atau lebih
parahnya adalah terbakar. Kemudian perlu diperhatikan juga, dari ke-4 kabel
sensor kanan (VCC MCU, RX MCU, TX MCU, GND MCU) hanya menggunakan 3
dari 4, jadi bagian pin yang digunakan hanyalah RX, TX, dan GND. Pin VCC tidak
digunakan karena akan mengakibatkan short circuit dan membuat rusak
motherboard. Dengan menghubungkan pin VCC berarti sama saja kita
menabrakkan dua tegangan dengan voltase yang jauh berbeda. Output dari pin
VCC pada sensor kanan motherboard memiliki nilai tegangan yang tinggi yaitu
15V, maka dari itu pin ini akan digunting dan di isolasi agar tidak membahayakan
jikalau lupa bahwa pin VCC ini tidak boleh digunakan.
Selanjutnya untuk terhubung dengan Jetson Nano melalui USB port,
dibutuhkan sebuah adapter yang mampu menjembatani komunikasi antar
perangkat. Dalam penelitian ini digunakan FTDI mini USB untuk menjembatani
kabel RX/TX sensor kanan dengan RX/TX Jetson Nano. Dari perangkat FTDI akan
dilanjutkan dengan kabel mini USB menuju port USB Jetson Nano. Untuk
penjelasan lebih lanjut mengenai apa saja pin-pin yang digunakan dari
motherboard dapat dilihat pada tabel 5.1.
Tabel 5.26 Penjelasan Konfigurasi Pinout Motherboard Hoverboard
Sumber: (github.com/EFeru/hoverboard-firmware-hack-FOC, 2018)
No Pin motherboard Pin tujuan Deskripsi
1 XT60 VCC 36V Pin daya motherboard
2 XT60 GND GND Pin ground motherboard
3 Button Pin Button Pin Pin tombol power kondisi on
4 Latch Pin Latch Pin Pin tombol power kondisi off
5 Charger Charger Konektor charger baterai
113
 Connector Connector
6 Pin daya untuk kutub A pada motor
Phase A LEFT Phase A
kiri
7 Pin daya untuk kutub B pada motor
Phase B LEFT Phase B
kiri
8 Pin daya untuk kutub C pada motor
Phase C LEFT Phase C
kiri
9 HALL A LEFT HALL A Pin data encoder pada motor kiri
10 HALL B LEFT HALL B Pin data encoder pada motor kiri
11 HALL C LEFT HALL C Pin data encoder pada motor kiri
12 GND LEFT GND Pin ground encoder motor kiri
13 VCC LEFT VCC Pin daya encoder motor kiri
14 Pin daya untuk kutub A pada motor
Phase A RIGHT Phase A
kanan
15 Pin daya untuk kutub B pada motor
Phase B RIGHT Phase B
kanan
16 Pin daya untuk kutub C pada motor
Phase C RIGHT Phase C
kanan
17 HALL A RIGHT HALL A Pin data encoder pada motor kanan
18 HALL B RIGHT HALL B Pin data encoder pada motor kanan
19 HALL C RIGHT HALL C Pin data encoder pada motor kanan
20 GND RIGHT GND Pin ground encoder motor kanan
21 VCC RIGHT VCC Pin daya encoder motor kanan
22 Pin USART untuk data yang
TX/USART3 RX terhubung dengan FTDI ke Jetson
Nano
23 Pin USART untuk data yang
PB11/RX/USART3 TX terhubung dengan FTDI ke Jetson
Nano
24 GND GND Pin ground USART3
25 3.3V MCU 3.3V Pin daya STLink untuk flashing
26 SWCLK MCU SWCLK Pin clock STLink untuk flashing
27 GND MCU GND Pin ground STLink untuk flashing
28 Pin data input dan output untuk
SWDIO MCU SWDIO
flashing

114
 Jetson Nano menerima catu daya pada power bank dengan tegangan sebesar
5V dan kuat arus sebesar 1A melalui kabel USB to micro USB. Daya ini juga akan
dipergunakan untuk menenagai sensor RPLiDAR dan GY-521 IMU MPU6050.
Wiring dari Jetson Nano ke RPLiDAR dapat dilihat pada gambar 5.11.

Gambar 5.58 Pinout Sensor RPLiDAR A1

Sensor RPLiDAR bekerja dengan ideal pada tegangan sebesar 5V yang
bersumber dari Jetson Nano yang terhubung melalui kabel USB 2.0 to micro USB,
sehingga dengan kabel ini kita dapat mendapatkan memberikan masukkan
tegangan sekaligus mengirim dan menerima data. Data yang diterima oleh Jetson
Nano dari sensor RPLiDAR merupakan mentah berupa point cloud yang diproses
oleh driver. Untuk menghubungkan RPLiDAR dengan kabel mikro USB diperlukan
sebuah adapter dengan nama RPLiDAR A1 UART Bridge. Adapter ini berfungsi
untuk menjembatani komunikasi sekaligus mengubah pin dari kabel kecil pada
input dan output RPLiDAR menjadi port mikro USB. Sensor ini memiliki 7 buah
pin yang memiliki fungsi seperti supply daya laser, data laser, supply daya motor,
dan sinyal untuk motor. Untuk melihat penjelasan lebih lanjut mengenai pin dari
RPLiDAR dapat dilihat pada tabel 5.2 dan untuk perangkat RPLiDAR dapat dilihat
pada gambar 5.11.
Tabel 5.27 Penjelasan pinout sensor RPLiDAR
Sumber: (www.slamtec.com, 2016)
No Pin modul Pin tujuan Deskripsi
1 GND GND Pin ground laser
2 TX RX Pin data dengan komunikasi serial USART
3 RX TX Pin data dengan komunikasi serial USART
4 V5 VCC Pin daya pada laser
5 GND GND Pin ground motor
6 MOTOCLT DTR Pin sinyal motor
7 VMOTO VCC Pin daya pada motor

115
 Sedangkan pada sensor GY-521 menggunakan tegangan sebesar 3.3V yang
terhubung dengan pin Jetson Nano. Sensor GY-521 ini memiliki port dengan
jumlah 8 pin, namun pin yang digunakan hanya berjumlah 4 buah yakni VCC &
Ground, yang memiliki fungsi masukan daya dan pin SCL & SDA, yang berfungsi
sebagai pengirim data dengan protokol komunikasi I2C. Untuk melihat
penjelasan lebih lanjut mengenai pin dari GY-521 dapat dilihat pada tabel 5.3 dan
untuk perangkat GY-521 dapat dilihat pada gambar 5.12.

Gambar 5.59 Pinout sensor GY-521 IMU MPU6050

Tabel 5.28 Penjelasan pinout sensor GY-521 IMU MPU6050

Sumber: (xtcomp.co.za, 2022)
No Pin modul Pin tujuan Deskripsi
1 VCC 3.3V Pin daya
2 GND GND Pin ground
3 SCL GPIO 5 (SCL) Pin data dengan komunikasi serial I2C
4 SDA GPIO 3 (SDA) Pin data dengan komunikasi serial I2C

Dari penjelasan keseluruhan sistem kita sudah mengetahui konfigurasi yang

akan di implementasikan pada penelitian ini. Baik konfigurasi pin maupun
konfigurasi komunikasi, semua hal ini menghasilkan arsitektur sistem secara
keseluruhan. Untuk memberikan gambaran mengenai arsitektur yang mencakup
keseluruhan sistem maka dibuat blok diagram yang dapat dilihat pada gambar
5.13. Arsitektur ini merupakan sentuhan akhir dari rancangan perangkat keras,
dimaksudkan untuk memberikan penjelasan lebih lanjut kepada pembaca
tentang mengapa perangkat-perangkat keras ini dibutuhkan. Jadi sebelum masuk
ke subbab perangkat lunak, minimal pembaca sudah mengerti hubungan
116
perangkat keras yang digunakan dan hubungannya dengan perangkat lunak yang
akan dirancang nanti.

Gambar 5.60 Arsitektur Keseluruhan Sistem

Pada gambar 5.13 dapat diperhatikan bahwa semua perangkat keras
digunakan sebagai sistem persepsi, yakni sistem yang mampu mengetahui
kondisi sekitar dan mengetahui lokasi presisi dari sistem. Terdiri dari data-data
yang dihasilkan oleh sensor-sensor yang sudah dijelaskan sebelumnya. Kemudian
ada pula sistem gerak, yakni sistem yang bertugas untuk memproses data
masukan PWM yang kemudian diteruskan ke motor BLDC dalam sebuah nilai
tegangan. Kemudian yang terakhir adalah sistem kontrol, yakni sistem yang
mengendalikan keseluruhan kinerja sistem mulai dari pembacaan data dari
sensor persepsi maupun perencanaan gerak untuk sistem gerak. Ada pula sistem
interaksi manusia-komputer yang akan dijelaskan pada subbab perancangan
perangkat lunak.

E.1.3 Perancangan Perangkat Lunak

Pada subbab ini, penulis akan menjelaskan mengenai rancangan perangkat
lunak yang digunakan pada penelitian ini. Perangkat lunak merupakan komponen
penting dalam sistem guna menentukan bagaimana cara sistem bekerja.
Penelitian ini memiliki fokus untuk menciptakan sistem otomatis untuk robot
beroda yang mampu bergerak secara mandiri dari titik awal menuju titik tujuan
menggunakan gabungan beberapa sensor dan algoritme. Perancangan dari
sistem ini terbagi menjadi tiga proses besar yakni proses persiapan awal, proses

117
utama dan proses bagian. Proses persiapan awal merupakan proses yang
pertama kali harus dijalankan sebelum memasuki proses utama maupun proses
bagian. Sedangkan proses utama merupakan proses yang mencakup keseluruhan
sistem. Proses utama terdiri dari 2 hal utama yang menjadi pokok penelitian ini,
yakni proses pemetaan dan proses navigasi. Sedangkan proses bagian atau sub
proses merupakan pecahan proses utama atau penjelasan lebih lanjut mengenai
bagian-bagian yang memiliki algoritme lagi di dalam proses utama yang
tujuannya adalah untuk memperjelas beberapa fungsi pada proses tertentu.
E.1.3.1 Perancangan Persiapan Awal Motherboard

Gambar 5.61 Diagram Alir Tahap Persiapan Awal Motherboard

Pada gambar 5.14 ditunjukkan bahwa perancangan persiapan awal
motherboard terdiri dari beberapa proses-proses persiapan sebelum merancang
perangkat lunak sistem. Jadi tahap persiapan awal bukanlah proses atau alur
algoritme sistem, melainkan tahap-tahap yang harus dijalankan sebelum
membuat perangkat lunak sistem. Hal ini penting dikarenakan sistem perangkat
lunak yang tidak biasa. Perangkat lunak pada robot ini terdiri dari banyak sekali
dependensi dan paket-paket. Selain itu robot pada penelitian ini menggunakan
robot dari komponen hoverboard yang di modifikasi sedemikian rupa sehingga
proses persiapan awal ini sangat penting dilakukan untuk menciptakan robot
modifikasi ini.
Hal yang pertama dilakukan adalah menghubungkan komputer personal
dengan motherboard. Ini merupakan tahap “connecting” untuk nantinya

118
dilakukan proses flashing. Proses ini dimulai dengan memberikan kabel jumper
pada perangkat STLink yang kemudian dihubungkan dengan 4 buah pin yang ada
di motherboard. Proses ini dijelaskan lebih lanjut pada sub bab implementasi.
Untuk detail mengenai pin ini dapat dilihat pada gambar 5.15.

Gambar 5.62 Pinout dari Motherboard ke STLink

Pada gambar 5.15 dapat dilihat bahwa secara berurutan posisi pin flash
firmware terdiri dari VCC, SWCLK, GND, SWDIO. Port ini dihubungkan dengan
kabel jumper male to female menuju STLink untuk selanjutnya ditancapkan ke
port USB ke personal komputer. Selanjutnya untuk motherboard hoverboard
proses ini dimulai dengan menghapus seluruh data yang ada di dalam chip
motherboard. Hal ini bertujuan untuk menghapus kode program pabrik yang
ditulis oleh pembuat hoverboard. Langkah selanjutnya adalah melakukan
konfigurasi firmware yang merupakan proses utama dalam tahap persiapan awal
motherboard. Konfigurasi firmware dibutuhkan untuk menyesuaikan jenis board
yang digunakan berdasarkan kebutuhannya pengembang. Proses konfigurasi ini
dimulai dengan melakukan download firmware hoverboard hack FOC. Firmware
hoverboard ini sudah selesai ditulis, maka dari itu kita hanya perlu melakukan
konfigurasi pada beberapa baris kode untuk menyesuaikan dengan kebutuhan
penelitian. File yang menjadi fokus modifikasi adalah file config maka dari itu
pada proses selanjutnya adalah dengan melakukan edit beberapa baris pada file
config.h yang akan dijelaskan lebih lanjut pada sub bab implementasi.
Tahap selanjutnya adalah melakukan flashing motherboard, jadi setelah
firmware sudah siap dan file config sudah di edit, langkah selanjutnya adalah
dengan melakukan building code menjadi sebuah file dengan ekstensi biner
dengan melakukan proses compile dengan klik ikon centang atau “PlatformIO:
build”. Maka langkah selanjutnya adalah dengan melakukan proses upload file
firmware.bin dengan klik ikon panah atau “PlatformIO: upload” maka terjadi
proses penyalinan data biner pada file firmware.bin ke motherboard dan pesan
berhasil akan muncul. Maka dengan begini proses persiapan awal motherboard
telah selesai. Motherboard sudah berada dalam kondisi siap digunakan dan
sudah bisa dikendalikan menggunakan kabel sensor motherboard bagian kanan.
Setelah proses ini maka berlanjut pada tahap persiapan awal perangkat Jetson
Nano.

119
E.1.3.2 Perancangan Persiapan Awal Jetson Nano

Gambar 5.63 Diagram Alir Persiapan Awal Jetson Nano

Pada gambar 5.16 dapat dilihat bahwa diagram alir dimulai dengan sub-
proses komunikasi antara Jetson Nano dengan komputer server melalui Virtual
Network Computing (VNC). Proses ini sangat berguna karena untuk melakukan
mapping dibutuhkan sebuah kendali remote yang mampu menampilkan aplikasi
GUI, metode yang paling mudah adalah dengan menggunakan VNC viewer.
Tahap selanjutnya setelah koneksi remote melalui VNC adalah melakukan
koneksi remote melalui terminal.
Selanjutnya adalah melakukan konfigurasi port USB, hal ini dilakukan untuk
mengubah konfigurasi default pada Linux dan membuat port USB yang
terhubung ke RPLiDAR dan FTDI menjadi lebih fleksibel dan mudah untuk
dikenali. Setelah melakukan konfigurasi port USB selanjutnya melakukan
pembuatan workspace catkin dengan membuat folder catkin_ws di dalam folder
home Linux dan membuat folder src di dalam folder catkin_ws. Workspace ini
yang nantinya akan menjadi directory parent yang mewadahi src atau source
pemrograman ROS pada development software robot. Jika sudah, maka
selanjutnya adalah melakukan instalasi beberapa driver yang dibutuhkan ke
dalam folder src seperti driver hoverboard, driver rplidar_ros, paket hector_slam
dan folder autonomous_mobile_robot_navigation yang masing-masing terdapat
pada tabel 5.4, 5.5, 5.6 dan 5.7.
Tabel 5.29 Parameter Konfigurasi hoverboard_driver Driver Hoverboard
No Parameter Default Konfigurasi Penelitian
1 left_wheel “left_wheel” “left_wheel”
2 right_wheel “right_wheel” “right_wheel”

120
 pose_covariance_diago [0.001, 0.001,
[0.0, 0.0, 0.0, 0.0,
3 nal 1000000.0, 1000000.0,
0.0, 0.0]
1000000.0, 1000.0]
twist_covariance_diago [0.001, 0.001,
[0.0, 0.0, 0.0, 0.0,
4 nal 1000000.0, 1000000.0,
0.0, 0.0]
1000000.0, 1000.0]
5 publish_rate 50 50
wheel_separation_
6 1.0 0.34
multiplier
7 cmd_vel_timeout 0.5 0.5
8 base_frame_id “base_link” “base_footprint”
linear/x/
9 false true
has_velocity_limits
10 linear/x/max_velocity double 1.0
11 linear/x/mix_velocity double -0.5
linear/x/
12 false true
has_acceleration_limits
linear/x/
13 double 0.8
max_acceleration
linear/x/
14 double double
min_acceleration
15 linear/x/has_jerk_limits false false
16 linear/x/max_jerk 0.0 0.0
angular/z/
17 false true
has_velocity_limits
18 angular/z/max_velocity double 3.14
19 angular/z/min_velocity double -3.14
angular/z/
20 false true
has_acceleration_limits
angular/z/
21 double 3.14
max_acceleration
angular/z/
22 double double
min_acceleration
angular/z/
23 false true
has_jerk_limits

121
 24 angular/z/max_jerk double 3.14
25 enable_odom_tf true false
26 wheel_separation 0.0 0.32
27 wheel_radius 0.0 0.0825
28 odom_frame_id “/odom” “/odom”
29 publish_cmd false false
allow_multiple_cmd_vel
30 false true
_publisher
velocity_rolling_window
31 10 10
_size

Tabel 5.30 Parameter Konfigurasi paket rplidar_ros Sensor RPLIDAR

No Parameter Default Konfigurasi Penelitian
1 serial_port /dev/ttyUSB0 /dev/ttyRPLIDAR
2 serial_baudrate 115200 115200
3 frame_id laser_frame laser
4 inverted false false
5 angle_compensate false true
6 scan_mode std::string() std::string()

Tabel 5.31 Parameter Konfigurasi mpu6050_driver Sensor IMU

No Parameter Default Konfigurasi Penelitian
1 bus_uri /dev/i2c-1 /dev/i2c-1
2 mpu_address 0x68 0x68
3 pub_rate 30 25
4 frame_id imu imu
[-1340, -9, 1463, 123, -42,
5 axes_offsets [0, 0, 0, 0, 0, 0]
42]
6 ki 0.1 0.2
7 kp 0.1 0.1
8 delta 0.5 0.5
Untuk konfigurasi folder pemrograman utama, yaitu
autonomous_mobile_robot_navigation dengan membuat folder dengan perintah

122
di teriminal $ catkin_create_pkg autonomous_mobile_robot_navigation
std_msgs roscpp rospy . Detail mengenai konfigurasi ini akan dijelaskan pada sub
bab implementasi. Pada file package.xlm terdapat beberapa paket dan library
yang akan di butuh kan pada penelitian ini, daftar paket dan library yang
dibutuhkan terdapat pada tabel 5.6.
Tabel 5.32 Daftar Paket Yang Digunakan pada AMR Navigation Package.xml
No Nama Paket Tag
1 amcl <depend> #namaPaket
</depend>
2 actionlib
3 actionlib_msgs
4 geometry_msgs
5 control_msgs
6 message_generation
7 controller_manager
8 gmapping
9 move_base
10 roscpp
11 rospy
12 std_msgs
13 std_srvs
14 tf
15 tf2
16 control_toolbox
17 map_server
18 rosparam_shortcuts
19 hardware_interface
20 laser_filters
21 imu_filter_madgwick
22 rviz_imu_plugin
23 robot_localization
24 dwa_local_planner
25 global_planner
26 twist_mux
123
 27 nmea_navsat_driver
28 moveit_ros_planning_interface
Proses berikutnya akan dilanjutkan pada diagram alir pada gambar 5.17.

Gambar 5.64 Diagram Alir Persiapan Awal Jetson Nano

Pada gambar 5.17 yang merupakan lanjutan dari proses sebelumnya, setelah
semua driver terpasang di dalam folder ~/catkin_ws/src maka lakukan install
dependensi semua library yang dibutuhkan ke dalam internal ROS dengan cara
mengetikkan perintah $ rosdep install –from-paths src –ignore-src-r -y . Ketika
perintah dijalankan maka terjadi proses download dan install dependensi yang di
deklarasikan pada file package.xml. Setelah itu masukkan perintah $ catkin_make
pada terminal sehingga terjadi proses generate oleh cmake sehingga file
generate tersebut dapat digunakan pada platform ROS. Namun jika terjadi error
pada baris kode, perbaiki kode dan lakukan alur dari page A, akan tetapi jika
tidak ada error pada kode maka akan di lakukan pemeriksaan pada dependensi,
apakah node yang di generate sudah memiliki library masing-masing di dalam
sistem Linux. Jika “ya” maka akan kembali ke proses install dependensi ROS,
namun jika tidak maka program compile berlanjut dan menampilkan output
compile berhasil.

124
E.1.3.3 Perancangan Program Utama
Perancangan program utama akan mencakup program utama pada penelitian
ini, mulai dari melakukan kalibrasi sensor IMU, pemetaan, dan navigasi robot.
Kalibrasi hanya dilakukan pada sensor IMU karena sensor lainnya seperti
RPLiDAR dan encoder di dalam motor BLDC sudah memiliki nilai raw yang presisi.
Semua alur pada perancangan program utama menjadi diagram alir utama
terhadap sub program lainnya. Diagram alir yang menjelaskan proses dari
program utama dapat dilihat pada gambar 5.18.

Gambar 5.65 Diagram Alir Program Utama

Pada gambar 5.18 merupakan diagram alir perancangan program utama akan
berisi poin-poin penting dari sebuah program secara keseluruhan. Semua urutan
program ini sudah mencakup hal-hal atau kriteria yang dibutuhkan untuk
membuat robot dengan sistem Autonomous Mobile Robot yaitu pemetaan dan
navigasi. Hal pertama yang dilakukan dalam program ini adalah melakukan
kalibrasi pada sensor IMU. Proses kalibrasi yang hanya dilakukan pada sensor
IMU dikarenakan sensor IMU membutuhkan nilai kalibrasi pada setiap kondisi
peletakannya. Jadi jika sensor IMU dipindahkan ke tempat lain, maka perlu
dilakukan kalibrasi ulang. Hal ini tidak diperlukan kedua sensor lainnya, yaitu
RPLiDAR dan encoder pada motor BLDC dikarenakan data raw yang konsisten
dan perangkat dilengkapi dengan mikrokontroler masing-masing. Detail lebih
lanjut mengenai alur dari kalibrasi ini dapat dilihat pada gambar 5.19.

125
 Gambar 5.66 Diagram Alir Sub Proses Kalibrasi Sensor IMU
Pada diagram alir yang di tunjukkan pada gambar 5.19 menjelaskan bahwa
proses awal melakukan kalibrasi adalah dengan menjalankan perintah pada $
roslaunch mpu6050_driver mpu6050_calibration.launch pada terminal. Setelah
menjalankan perintah tersebut maka terminal akan menjalankan proses kalibrasi
dan menghasilkan output berupa topik baru dengan nama /imu/data dan
/imu_offsets. Lihat nilai dari output tersebut dengan mencetaknya pada terminal
dengan perintah $ rostopic echo /imu_offsets kemudian simpan nilai tersebut
pada text editor. Langkah selanjutnya adalah mengubah file setting dari driver
MPU pada directory mpu6050_driver/config/mpu_setting.yaml. Setelah proses
edit selesai, langkah selanjutnya adalah menjalankan file launcher driver IMU
dengan mengetikkan perintah $ roslaunch mpu6050_driver

126
mpu6050_driver.launch pada terminal. Untuk dapat melihat output yang
dihasilkan dari sensor, jalankan perintah $ rostopic echo /imu pada terminal.
Output yang ditampilkan adalah nilai x,y,z pada akselerometer tidak mendekati 0
m/s, 0 m/s, dan 9.8 m/s maka proses kalibrasi perlu di ulang. Akan tetapi jika
sudah mendekati nilai tersebut maka proses kalibrasi IMU sudah selesai.
E.1.3.4 Perancangan Program Pemetaan
Proses selanjutnya adalah mapping atau pemetaan, proses ini merupakan
sub proses dari program utama, jadi penjelasan lebih lanjut mengenai pemetaan
ini akan di bahas pada sub nomor berikutnya. Proses mapping ini kurang lebih
berguna untuk mendapatkan data “map” pada suatu area di dalam ruangan.
Map ini nantinya akan berguna untuk proses navigasi, hal ini dikarenakan untuk
melakukan navigasi diperlukan proses path planning atau perencanaan jalur.
Sehingga untuk mendapatkan data koordinat tujuan dan melakukan
perencanaan jalur dibutuhkan data peta 2D, agar koordinat dapat di inisialisasi.
Setelah map berhasil dibuat, maka langkah selanjutnya adalah menyimpan map
tersebut ke dalam folder yang sudah disiapkan khusus untuk file-file map.
Perancangan program pemetaan akan mencakup proses pembacaan sensor,
lokalisasi, dan hector mapping. Program pemetaan merupakan salah satu
program utama yang harus dijalankan terlebih dahulu sebelum melakukan
program navigasi. Diagram alir dari perancangan program pemetaan akan
ditunjukkan pada gambar 5.20.

127
 Gambar 5.67 Diagram Alir Program Pemetaan
Pada gambar 5.20 merupakan diagram alir program pemetaan dengan proses
yang saling berkaitan satu paket dengan paket lainnya. Diagram ini menjelaskan

128
mengenai node-node yang dibutuhkan dalam proses mapping, seperti
menjalankan semua driver sensor, fusion sensor, lokalisasi, transform frame, dan
parameter-parameter yang digunakan. Semua hal ini dijadikan satu proses besar
yang dinama kan mapping dan perencanaan dari proses-proses ini digabungkan
ke dalam file dengan ekstensi .launch yang diberi nama mapping.launch.
Semua proses ini bermula dari perintah terminal yang di input oleh komputer
server yang terhubung dengan VNC client. Seperti yang sudah dijelaskan pada
bab 2 mengenai ROS dan perintah-perintah yang ada di dalamnya, terdapat
prefix perintah “roslaunch” yang akan sering digunakan pada penelitian ini.
Prefix ini memiliki arti, jalankan sebuah ros system core yang melakukan
launching dengan file yang memiliki ekstensi “. launch” kemudian jalankan
semua perintah-perintah di dalamnya. Jadi isi dari file launch ini adalah
kumpulan perintah untuk menjalankan node-node beserta parameternya. File ini
juga dapat memanggil file launch lainnya sehingga terjadi sinkronisasi karena
tidak perlu memanggil file launch secara berulang-ulang. Setelah kita
menjalankan file launch mapping, maka yang terjadi selanjutnya adalah terminal
Linux akan berperan sebagai aplikasi berbasis konsol yang menampilkan hasil log
berupa sistem mapping. Terminal tidak bisa di terminate atau dihentikan, karena
akan berakibat pada node-node yang sedang dijalankan pada terminal tersebut.
Saat terminal menjalankan file launch, maka hal yang pertama kali dilakukan
adalah melakukan pengecekan driver dan paket yang digunakan. Pengecekan ini
hanya berlaku pada node yang disebutkan di dalam file launch tersebut, apabila
terdapat dependency yang kurang atau ada beberapa paket pendukung node
tersebut yang belum di install maka terminal akan menampilkan pesan error dan
meminta untuk memasang paket tersebut. Selain menampilkan error karena
paket yang belum terpasang, terkadang terminal juga menampilkan pesan
warning jika terdapat kekurangan pada kode program. Selanjutnya jika semua
driver dan paket sudah tersedia di dalam dependency ROS maka langkah
selanjutnya adalah mengirimkan input dari ketiga sensor, yaitu pemindaian laser
oleh RPLiDAR, akselerasi pergerakan robot oleh IMU, dan putaran odometry roda
oleh encoder motor.
Perlu diperhatikan juga bahwa selagi proses ini berlangsung, secara paralel
terminal juga menjalankan aplikasi RViz dan juga menampilkan aplikasi rqt robot
steering. Kedua aplikasi ini merupakan aplikasi pendukung yang memiliki
tugasnya masing-masing. Aplikasi RViz digunakan sebagai visualisasi proses untuk
monitoring hasil dari mapping. Hasil pemosisian robot akan terus di perbaharui
secara simultan, sehingga kita dapat melihat posisi robot pada saat itu .
Sedangkan aplikasi rqt robot steering digunakan menjadi remote control untuk
mengendali robot selama proses mapping terjadi. Aplikasi ini melakukan
subscribe pada topik hoverboard_velocity_controller/cmd_vel yang mana topik
ini akan publish topik geometry/pose untuk menggerakkan motor, sehingga
robot dapat bergerak dan sekaligus memberikan input data sensor odometry
untuk digunakan pada proses selanjutnya

129
 Ketika pertama kali dijalankan, setiap komponen akan membuat frame
transformasi pada node masing-masing. Setiap frame tersebut harus saling
terhubung dan terkoordinasi, perancangan yang diinginkan adalah seperti yang
terlihat pada gambar 2.21.

Gambar 5.68 Transformasi Frame Pada Pemetaan

Pada gambar 5.21 dapat terlihat bahwa setiap node dengan broadcaster
saling menghubungkan sehingga membuat diagram alir yang sejajar. Untuk
melakukan hal ini diperlukan konfigurasi static transformasi (TF) pada file
launcher di program pemetaan. Terdapat beberapa keterangan seperti
broadcaster yang merupakan node pengirim atau publisher output sebuah TF,
average rate yang merupakan rata-rata pengiriman dalam Hz Flow dimulai dari
node map, node ini didapat dari publisher node hector_mapping. Selanjutnya TF
tersebut dilanjutkan ke odom_combined yang di broadcast oleh algoritme EKF.

130
 Melanjutkan proses sebelumnya yaitu mengirimkan input sensor ke
mikrokomputer, proses ini dilakukan oleh driver pada masing-masing sensor.
Driver ini memiliki library untuk melakukan pembacaan data sensor, pengolahan
data, dan mengirimkan pesan catatan jika terjadi error. Pada input sensor
pemindaian laser, driver RPLiDAR_ros berperan untuk membaca data dari
tembakan laser dan mengubahnya ke dalam data point cloud. Point cloud
merupakan setumpuk data array yang terdiri dari ribuan data per detiknya,
dalam implementasinya point cloud ini berupa data jarak yang berhasil di scan.
Pada umumnya sensor yang menggunakan teknik laser hanya mampu
mengirimkan jarak pada satu titik fokus, namun sensor RPLiDAR memiliki
kemampuan untuk melakukan pemindaian secara 360 derajat. Untuk
memproses data putaran laser tersebut dibutuhkan driver khusus yang sudah
disediakan oleh RoboPeak yang bisa di download langsung pada website atau
repository GitHub. Tabel 5.5 adalah konfigurasi parameter yang terdapat pada
launcher rplidar_ros.
Selagi proses pemindaian laser dilakukan, sistem juga melakukan pembacaan
data akselerasi dari sensor IMU. Sensor ini akan memberikan data berupa
percepatan pada sumbu x, y, dan z. X merupakan sumbu horizontal, jadi nilai
akselerasi sumbu x akan berubah jika robot bergerak secara horizontal seperti
berbelok kiri atau kanan. Sedangkan sumbu Y merupakan sumbu vertikal, jadi
nilai akselerasi dari sumbu y akan berubah jika robot bergerak secara linier
seperti maju atau mundur. Sedangkan nilai Z secara default akan bernilai 9.8 m/s
mengikuti percepatan gravitasi bumi. Kemudian masih di proses paralel yang
sama sistem ROS akan menjalankan node odometry dimana driver hoverboard
akan melakukan pembacaan sensor encoder. Data yang didapatkan adalah
sebuah pose dan orientasi dari roda, jadi perubahan orientasi dari posisi
sebelumnya dapat terlihat langsung. Nilai dari orientasi dan posisi ini dihitung
berdasarkan nilai putaran tiap rodanya yang dikonversi ke dalam radian per
sekon.
Proses selanjutnya mulai menggunakan algoritme yang digunakan pada
penelitian ini. Setelah mendapatkan data dari sensor, sistem pada program
mapping akan menggunakan dua algoritme yakni algoritme Hector SLAM dan
algoritme EKF. Pada data sensor laser yang sudah menjadi data jarak ke dalam
point cloud, langkah selanjutnya adalah memberikan data tersebut ke algoritme
Hector SLAM.

131
E.1.3.5 Perancangan Proses Algoritme Hector SLAM

Gambar 5.69 Diagram Alir Proses Algoritme Hector SLAM

Pada gambar 5.22 dapat dilihat bahwa proses dimulai dengan mengambil
input dari scanning sensor laser dengan data berupa point cloud dan input dari
transformation pose robot. Setelah itu input scan di olah ke dalam sub proses
Hector Mapping dan menghasilkan 2D map serta pose, sedangkan
132
transformation akan diolah oleh proses Hector Trajectory Server. Detail lebih
lanjut mengenai sub proses Hector Mapping dapat dilihat pada gambar 5.22.

Gambar 5.70 Diagram Alir Sub Proses Hector Mapping

133
 Pada gambar 5.23 dapat dilihat bahwa diagram alir terdiri dari beberapa
proses konfigurasi dan terdapat proses inti berupa estimasi pose 2D. Diagram alir
Hector Mapping dikutip dari jurnal peneliti yang dilakukan oleh (Souliman, 2019).
Dimulai dengan mendapatkan data informasi atau data dari pemindaian laser,
kemudian proses beralir ke konfigurasi Hector Mapping berdasarkan konfigurasi
pada file mapping_default.launch yakni berupa posisi scanning pada frame
/base_link dan posisi odom menjadi frame /odom. Selanjutnya lakukan proses
pengaturan laser value pada parameter laser_z_min_value, laser_z_max_value,
laser_min_dist, laser_max_dist. Setelah konfigurasi dijalankan oleh program
maka selanjutnya adalah menjalankan sub-proses, yaitu diagram alir estimasi
pose 2D yang dapat dilihat pada gambar 5.24.

Gambar 5.71 Diagram Alir Sub Proses Estimasi Pose 2D

Pada gambar 5.24 dapat dilihat bahwa sub proses dimulai dengan sebuah
proses yang mengatur pose estimate, selanjutnya proses terbagi menjadi 2 yaitu
pose dari iterasi sebelumnya dan pose menggunakan perkiraan awal
134
transformation. Setelah itu dilanjutkan dengan proses titik akhir proyek ke peta
berdasarkan pose saat ini dan dilanjutkan dengan melakukan perkiraan peta
occupancy probability di titik akhir pemindaian laser. Selanjutnya dilakukan
proses iterasi menggunakan metode Gauss-Newton untuk memperbaiki nilai
estimasi pose yang salah dengan rumus

[ ][ ]
T
∂ S i (ξ ) ∂ Si ( ξ)
H= ∇ M (Si ( ξ) ) ∇ M (S i (ξ) ) (5.1)
∂ξ ∂ξ
Rumus ini akan digunakan untuk melakukan koreksi nilai estimasi pose
menggunakan iterasi. Iterasi ini nantinya akan digunakan sebagai perhitungan
pergerakan robot berdasarkan banyaknya jumlah iterasi yang menghasilkan titik
proyeksi pose robot untuk selanjutnya akan proses akan dikembalikan ke titik
akhir proyek ke peta berdasarkan perkiraan pose. Proses estimasi pose berakhir
di sini yang kemudian akan kembali ke proses di dalam diagram alir pada gambar
5.28.
Sub proses selanjutnya adalah occupancy grid map yang merupakan
tambahan dari diagram alir yang dibuat oleh Aya Souliman. Proses ini akan
memanfaatkan output yang dihasilkan proses estimasi pose 2D. Diagram alir
algoritme occupancy grid diambil dari penelitian Xu, Lichao, dkk (Xu, dkk., 2019).
Berdasarkan gambar 5.30, diagram alir menunjukkan proses dimulai dari
melakukan subscribe topik Pose dan Laser Scan, kemudian lakukan seleksi kondisi
apakah pesan topik tersebut dapat diambil atau tidak. Jika tidak maka lakukan
subscribe topik kembali dan lakukan proses yang sama, namun jika ya maka akan
mendapatkan pesan output Pose dan Laser scan. Proses dilanjutkan dengan
melintasi pose 2D dan pemindaian laser secara berurutan dan akhirnya bisa
memperbaharui peta. Jika pose sudah mencapai titik akhir dari pemindaian laser,
dalam arti laser ditembakkan kemudian bergerak mencapai posisi robot kembali
maka dilakukan proses set dan publish transformasi laser pose, laser scan, dan
grid map. Namun jika tidak maka proses akan dikembalikan ke pelintasan pose
2D dan pemindaian laser secara berurutan untuk nantinya bisa memperbaharui
peta.
Setelah melakukan set dan publish topik, maka akan didapatkan output
berupa pesan laser pose, laser scan, dan grid map. Output ini akan digunakan
kembali ke proses awal yaitu subscribe pose dan laser scan topik sehingga
algoritme akan terus berulang menciptakan proses recursive. Diagram alir proses
ini dapat dilihat pada gambar 5.25.

135
 Gambar 5.72 Diagram Alir Sub Proses Occupancy Grid Map
Setelah proses occupancy selesai, maka kita sudah mendapatkan data grid
map yang menjadi output dari proses occupancy grid map. Map ini digunakan
sementara untuk nantinya disimpan dan digunakan pada proses navigasi.
Kembali mengacu pada gambar 5.15, ketika proses mapping di akhiri maka
proses selesai, namun jika belum maka proses akan terus berlanjut hingga
nantinya di terminate paksa melalui terminal.
Hasil akhir perancangan dari diagram alir dari algoritme Hector SLAM berupa
konfigurasi pada file launcher. Jadi untuk mencapai diagram alir tersebut, perlu
dilakukan konfigurasi parameter terlebih dahulu pada paket hector_slam agar
sesuai dengan yang diharapkan. Konfigurasi ini dapat dilihat pada tabel 5.8, tabel
5.9, dan tabel 5.10.

136
 Tabel 5.33 Parameter Konfigurasi Paket Hector Mapping
Konfigurasi
No Parameter Default
Penelitianan
1 base_frame base_link base_link
2 map_frame map_link map
3 odom_frame odom odom
4 map_resolution 0.025 5.050
5 map_size 1024 2048
6 map_start_x 0.5 0.5
7 map_start_y 0.5 0.5
map_update_distance_t
8 0.4 0.4
hresh
map_update_angle_thre
9 0.9 0.06
sh
map_pub_period 2.0 2.0
10 map_multi_res_levels 3 2
11 update_factor_free 0.4 0.4
12 update_factor_occupied 0.9 0.9
13 laser_min_dist 0.4 0.4
14 laser_max_dist 30.0 30.0
15 laser_z_min_value -1.0 -1.0
16 laser_z_max_value 1.0 1.0
pub_map_odom_transfo
17 true false
rm
18 output_timing false false
scan_subscriber_queue_
19 5 5
size
pub_map_scanmatch_tr
20 true false
ansform
tf_map_scanmatch_tran
21 scanmatcher_frame scanmathcer_frame
sform_frame_name
22 pub_odometry false true
23 advertise_map_service false true

137
 Tabel 5.34 Parameter Konfigurasi Paket Hector Geotiff
No Parameter Default Konfigurasi Penelitian
"$(find
1 map_file_path “.”
hector_geotiff)/maps"
2 map_file_base_name “GeoTiffMap” "hector_slam_map"
3 geotiff_save_period 0.0 0.0
draw_background_
4 false true
checkerboard
5 draw_free_space_grid false true
"hector_geotiff_plugins/
6 plugins “”
TrajectoryMapWriter"

Tabel 5.35 Parameter Konfigurasi Paket Hector Trajectory

No Parameter Default Konfigurasi Penelitian
1 target_frame_name “map” “/map”
2 source_frame_name “base_link” “/base_link”
3 trajectory_update_rate 4.0 4.0
4 trajectory_publish_rate 0.25 0.25

E.1.3.6 Perancangan Proses Algoritme Extended Kalman Filter (EKF)

Proses algoritme EKF digunakan untuk melakukan koreksi terhadap lokalisasi
robot. Pada penelitian sebelumnya, algoritme Hector SLAM saja tidak akan
mencukup untuk membaca posisi terkini robot dikarenakan area pengujian yang
sangat luas, yaitu gudang sehingga pada saat laser tidak mendeteksi halangan
sama sekali maka bisa menghasilkan pose estimate yang keliru. Maka dari itu
digunakan algoritme EKF sekaligus untuk menggabungkan 2 buah input dari
sensor IMU dan odometry. Diagram alir dari algoritme EKF dapat dilihat pada
gambar 5.26.

138
 Gambar 5.73 Diagram Alir Proses Algoritme Extended Kalman Filter (EKF)
Pada gambar 5.26 dapat dilihat bahwa proses dari algoritme EKF melakukan
proses secara bersamaan dengan asinkron. Dimulai dari melakukan perkiraan
kesalahan asli, perkiraan asli, pengambilan input dari data IMU dan data
odometry. Semua ini dilakukan secara bersamaan sehingga pada proses
perkiraan kesalahan asli didapatkan nilai kesalahan dalam perkiraan dan
kesalahan dalam data di dapatkan dari perkiraan sebelumnya. Untuk proses
perkiraan asli data diambil dari hasil pembaharuan perkiraan yang secara default
pada awal mula proses dimulai perkiraan asli diambil dari nilai perkiraan awal
berupa covariant sensor. Langkah selanjutnya adalah mendapatkan input dari
data sensor IMU dan data odometry melalui topik yang dihasilkan oleh masing-
masing driver, lalu kemudian dilakukan proses pengukuran nilai.
Setelah itu proses berlanjut ke menghitung nilai dengan Kalman Gain untuk
memprediksi posisi dan kesalahan perkiraan dengan input kesalahan dalam
perkiraan dan kesalahan dalam data. Nilai prediksi ini dilanjutkan ke proses
menghitung perkiraan saat ini yang juga mendapatkan input dari perkiraan
sebelumnya. Setelah menghitung perkiraan saat ini, proses dilanjutkan dengan
proses memperbaharui perkiraan yang hasil akhirnya berupa output frame
transformasi EKF dan topik baru berupa /odom_combined yang didapat
berdasarkan posisi odometry dan IMU pada robot. Proses memperbaharui
perkiraan dikembalikan ke proses perkiraan asli sehingga terjadi proses recursive.

139
 Setelah melakukan proses algoritme Hector SLAM dan EKF maka dari masing-
masing algoritme akan menghasilkan output. Algoritme hector SLAM
memperbaharui topik /scan sehingga bisa digunakan untuk proses occupancy
grid pada aplikasi RViz, selain itu algoritme ini juga menghasilkan frame
penggabungan transformasi map dengan odometry yang diberi nama
“map_to_odom”. Selain itu juga menghasilkan frame hector_mapping dan
hector_trajectory yang dimanfaatkan untuk membuat map. Sedangkan algoritme
EKF menghasilkan topik baru dengan nama /odom_combined, begitu pula
dengan frame transformasinya dengan nama odom_combined. Semua hasil
lokalisasi yang berupa posisi robot dan transformasinya digunakan untuk
melakukan update posisi terkini yang pada akhirnya dikirimkan ke RViz dan
output topik /map. Dengan gabungan dua algoritme ini akan menghasilkan
transformasi robot yang lebih akurat dan proses mapping akan berjalan dengan
lancar. Output topik /map tadi yang berupa peta dalam bentuk sementara akan
disimpan menjadi output file baru dengan ekstensi .yaml dan .pgm yang nantinya
digunakan pada proses navigasi. Namun hal ini berlaku jika proses map sudah
selesai, jika belum maka proses akan dikembalikan ke algoritme Hector SLAM
hingga semua area sudah di mapping.
Ini adalah keseluruhan dari proses mapping, secara garis besar dapat
diperhatikan kembali pada gambar 5.20. Output dari proses ini yang berupa file
map akan digunakan pada program selanjutnya yaitu navigasi. Pada program
navigasi terdapat pula algoritme EKF dengan proses yang sama persis, maka dari
itu pada sub proses Algoritme EKF di program navigasi tidak akan dijelaskan
karena sudah dijelaskan pada proses mapping. Konfigurasi EKF Localization dapat
dilihat pada dan tabel 5.11.
Tabel 5.36 Parameter Konfigurasi Paket EKF Localization
No Parameter Default Konfigurasi Penelitian
1 output_frame “odom” “odom”
2 base_footprint_frame “base_footprint” “base_footprint”
3 freq 30.0 100.0
4 sensor_timeout 1.0 1.0
5 odom_used true true
6 imu_used true true
7 vo_used true false
8 gps_used false false
9 debug false false
self-diagnose false false
Setelah melakukan konfigurasi EKF, sub program selanjutnya akan membahas
mengenai perancangan navigasi sebagai bentuk lanjutan dari program utama.

140
E.1.3.7 Perancangan Program Navigasi

Gambar 5.74 Diagram Alir Program Navigasi

Diagram alir dari perancangan keseluruhan program ditunjukkan pada
gambar 5.27. Pada gambar tersebut kita dapat melihat bahwa terdapat banyak
141
proses yang saling terkait satu dengan yang lain. Diagram alir ini menjelaskan
mengenai node-node yang dibutuhkan dalam proses navigasi, seperti
menjalankan semua driver sensor kemudian membaca sensor, penggabungan
sensor teknik fusion sensor, lokalisasi, transform frame, dan parameter-
parameter yang digunakan. Semua hal ini dijadikan satu proses besar yang diberi
nama autonomous_nav. Semua proses yang terjadi di dalam program ini
digabungkan ke dalam file dengan ekstensi launch.
Proses awal pada navigasi kurang lebih sama seperti proses mapping, yakni
dimulai dari melakukan input pada terminal berupa perintah $ roslaunch
autonomous_nav.launch. Maka selanjutnya proses berpindah ke terminal
dengan menjalankan semua node dan parameter pada file launcher tersebut.
Dilanjutkan dengan membuka program RViz dan melakukan pengecekan pada
semua driver dan paket yang digunakan, jika didapati adanya kesalahan maka
akan mengirimkan pesan error dan program di terminate untuk nantinya
dievaluasi kembali mengenai pesan error tersebut. Namun jika semua driver dan
paket sudah tersedia maka dilanjutkan dengan proses paralel dengan melakukan
pembacaan pada masing-masing sensor yang nantinya digunakan untuk proses
subscribe.
Pada aplikasi RViz terdapat dua tool utama yang digunakan untuk melakukan
navigasi, yaitu 2D Pose Estimate dan 2D Nav Goal. 2D Pose estimate digunakan
untuk mengkonfirmasi ulang posisi robot berdasarkan posisi robot sebenarnya di
dunia nyata. Sedangkan untuk 2D Nav Goal berguna untuk memberikan input
berupa koordinat tujuan robot yang digunakan untuk input awal proses path
planning. Untuk melakukan navigasi diperlukan 2 input ini, terutama input dari
2D Nav Goal. Kembali ke proses pembacaan data sensor, nilai pemindaian laser
akan diolah oleh driver RPLiDAR sehingga didapatkan output topik baru
berupa /scan yang merupakan data point cloud. Selanjutnya pada input
akselerasi robot akan dibaca oleh sensor IMU yang di proses menggunakan
driver IMU sehingga menghasilkan output topik baru berupa /imu.
Ketika pertama kali dijalankan, setiap komponen akan membuat frame
transformasi pada node masing-masing. Setiap frame tersebut harus saling
terhubung dan terkoordinasi, perancangan yang diinginkan adalah seperti yang
terlihat pada gambar 2.28.

142
 Gambar 5.75 Transformasi Frame Pada Navigasi
Pada gambar 5.28 dapat terlihat bahwa setiap node dengan broadcaster
saling menghubungkan sehingga membuat diagram alir yang sejajar. Untuk
melakukan hal ini diperlukan konfigurasi static transformasi (TF) pada file
launcher di program pemetaan. Terdapat beberapa keterangan seperti
broadcaster yang merupakan node pengirim atau publisher output sebuah TF,
average rate yang merupakan rata-rata pengiriman dalam Hz Flow dimulai dari
node map, node ini didapat dari publisher node hector_mapping. Selanjutnya TF
tersebut dilanjutkan ke odom_combined yang di broadcast oleh algoritme EKF.
Selanjutnya pada input nilai putaran roda akan dibaca oleh driver hoverboard
yang menghasilkan topik baru berupa /odom yang merupakan data posisi roda
dan orientasinya. Terdapat tambahan berupa input dari file map yang disimpan
di folder tertentu dengan nama maps. File ini akan di generate oleh paket map
server dan dikirimkan ke dalam sub proses algoritme AMCL sebagai input

143
awalnya begitu pula dengan data yang didapat dari sensor RPLiDAR
menggunakan topik /scan. Sedangkan data dari sensor IMU dan odometry akan
di kirimkan ke sub proses Fusion Sensor EKF menggunakan topik /imu/data
dan /odom.
E.1.3.8 Perancangan Proses Algoritme Adaptive Monte Carlo Localization
(AMCL)
Proses algoritme AMCL digunakan untuk melakukan koreksi terhadap
lokalisasi robot. AMCL memanfaatkan file map yang sudah dibuat di program
mapping sebelumnya. Detail mengenai algoritme ini dirangkum ke dalam
diagram alir yang dapat dilihat pada gambar 5.29.

Gambar 5.76 Diagram Alir Algoritme Adaptive Monte Carlo Localization (AMCL)
Pada gambar 5.29 dapat dilihat bahwa proses diagram alir terdiri dari
beberapa proses dan seleksi kondisi. Diagram alir ini dikutip dari penelitian yang
dilakukan oleh Gang Peng dan kawan-kawan (Peng, dkk., 2018). Dalam penelitian
tersebut disebutkan bahwa untuk memecahkan masalah selama algoritma AMCL
untuk memperkirakan pose robot sebagai deviasi pusat tertimbang dari kawanan
partikel di lingkungan tidak terstruktur yang kompleks, penelitian ini
menambahkan pencocokan pemindaian yang cocok dengan pemindaian laser
dengan peta. Proses yang terjadi dalam algoritme AMCL adalah kumpulan
partikel (point cloud) yang didapat dari data laser. Kemudian dilakukan simulasi
pergerakan partikel sebagai bentuk pose estimate. Selanjutnya dilakukan
perhitungan nilai skor tiap partikel. Setelah dilakukan perhitungan skor tiap
partikel, dilakukan proses scan matching, proses ini menggunakan rumus matriks
Hessian dan gabungan dari metode Gaussian-Newton iteration untuk melakukan

144
perkiraan menggantikan model regresi non-linier. Detail mengenai proses ini
dapat dilihat pada gambar 5.30.

Gambar 5.77 Diagram Alir Sub Proses AMCL: Scan Matching

Pada gambar 5.30 dapat dilihat bahwa setelah memasuki proses scan
matching, pertama akan dilakukan seleksi kondisi terlebih dahulu untuk
mengetahui apakah gerombolan partikel (particle cloud) sedang dalam posisi
terpusat atau terkonsentrasi (solusi dari estimasi pose konvergen). Jika
145
kondisinya adalah tidak, maka akan proses akan langsung di terminate dan
proses scan matching sudah selesai, sehingga berlanjut ke proses sampel ulang
partikel. Hal ini dikarenakan algoritme scan matching digunakan untuk lebih
mengoptimalkan pose. Sehingga hanya akan memproses data-data point cloud
yang terkonsentrasi saja. Metode ini merupakan bentuk dari koreksi data laser
yang error dan tidak bisa digunakan untuk menentukan posisi.
Setelah menginisialisasi nilai dari scan match, maka langkah selanjutnya
adalah dengan melakukan kalkulasi iterasi Gaussian-Newton dilakukan layer per
layer dari resolusi rendah hingga ke resolusi tinggi pada peta multiresolution.
Kemudian dilakukan seleksi kondisi, jika Jumlah maksimum iterasi tercapai, atau
kurang dari kesalahan maksimum maka didapatkan output berupa solusi yang
cocok. Setelah sebelumnya melakukan iterasi dan mendapatkan pose yang lebih
akurat dari sebelumnya. Dilakukan seleksi kondisi untuk menyeleksi apakah hasil
dari perhitungan sudah merupakan hasil dari peta resolusi tertinggi, jika belum
maka artinya error yang dihasilkan lebih besar dari threshold yang didapat, ini
berarti terdapat solusi scan matching yang error dan itu harus di batalkan.
Setelah dibatalkan maka akan dikembalikan ke proses awal yaitu inisialisasi nilai
awal dari scan match.
Namun jika peta sudah memiliki resolusi tertinggi maka, dilakukan solusi
pencocokan pemindaian untuk memenuhi persyaratan. Hal ini dikarenakan
pencocokan pemindaian menggunakan solusi AMCL sebagai nilai awal, jika solusi
AMCL sangat berbeda dari pose sebenarnya, pencocokan pemindaian akan gagal.
Jadi jika hasil sangat berbeda dari pose sebelumnya maka hasil perhitungan akan
diabaikan dan proses scan matching di terminate ke selesai. Namun jika
persyaratan sudah memenuhi kriteria dan tidak terlalu melebihi nilai
sebelumnya, maka data dimasukkan ke dalam gerombolan particle AMCL dan
hasil dari proses filtrasi data point cloud akan dikembalikan ke seleksi kondisi
awal, jika terdapat gerombolan partikel yang terpusat kembali, maka lakukan
kalkulasi ulang, begitu seterusnya hingga terbentuk proses yang recursive.
Konfigurasi AMCL Localization dapat dilihat pada dan tabel 5.12.
Tabel 5.37 Parameter Konfigurasi Paket AMCL Localization
No Parameter Default Konfigurasi Penelitian
1 min_particles 100 500
2 max_particles 5000 5000
3 kld_err 0.01 0.01
4 kld_z 0.99 0.99
5 update_min_d 0.2 meters 0.1
6 update_min_a π/6.0 radians 0.2
7 resample_interval 2 2
8 transform_tolerance 0.1 second 0.1 second

146
9 recovery_alpha_slow 0.0 0.0
10 recovery_alpha_fast 0.0 0.0
11 initial_pose_x 0.0 0.0
12 initial_pose_y 0.0 0.0
13 initial_pose_a 0.0 0.0
14 initial_cov_xx 0.5*0.5 meters 0.5*0.5 meters
15 initial_cov_yy 0.5*0.5 meters 0.5*0.5 meters
16 initial_cov_aa (π/12)*(π/12) rad (π/12)*(π/12) rad
17 gui_publish_rate -1.0 Hz -1.0 Hz
18 save_pose_rate 0.5 Hz 0.5 Hz
19 use_map_topic false false
20 first_map_only false false
21 selective_resampling false false
22 laser_min_range -1.0 -1.0
23 laser_max_range -1.0 -1.0
24 laser_max_beams 30 30
25 laser_z_hit 0.95 0.95
26 laser_z_short 0.1 0.1
27 laser_z_max 0.05 0.05
28 laser_z_rand 0.05 0.05
29 laser_sigma_hit 0.2 meter 0.2 meter
30 laser_lambda_short 0.1 0.1
31 laser_likelihood_max_dist 2.0 meter 2.0 meter
32 laser_model_type “likelihood_field" “likelihood_field"
33 odom_model_type “diff” “diff-corrected”
34 odom_alpha1 0.2 0.2
35 odom_alpha2 0.2 0.2
36 odom_alpha3 0.2 0.2
37 odom_alpha4 0.2 0.2
38 odom_alpha5 0.2 0.2
39 odom_frame_id “odom” “odom”
40 base_frame_id “base_link” “base_link”
147
 41 global_frame_id “map” “map”
42 tf_broadcast true true

E.1.3.9 Perancangan Proses Algoritme Lokalisasi EKF pada Navigasi

Proses algoritme EKF digunakan untuk melakukan koreksi terhadap lokalisasi
robot. Untuk dapat melakukan lokalisasi dengan baik diperlukan gabungan dari
banyak transformasi yang membangun kesatuan robot. Dalam penelitian ini
penulis menggunakan sensor IMU dan odometry sebagai validitas data
pergerakan robot dalam melakukan navigasi, selain dari menggunakan data
laser. Untuk menggabungkan kedua sensor ini dibutuhkan algoritme fusion,
maka dari itu digunakan algoritme EKF sekaligus sebagai filter untuk memvalidasi
data yang didapat dari data odometer raw. Secara garis besar proses EKF pada
pemetaan dan navigasi tidaklah berbeda.
Output yang dihasilkan dari algoritme lokalisasi EKF adalah robot position dan
transformasi. Output ini digunakan untuk melakukan update posisi yang
dikirimkan ke aplikasi RViz dan proses perencanaan jalur. Di dalam proses path
planning atau perencanaan jalur terdapat beberapa input dari berbagai hal,
seperti input koordinat tujuan 2D Nav Goal dari aplikasi RViz, input deteksi
halangan dari topik /scan, dan input pembaharuan posisi robot terkini.
E.1.3.10 Perancangan Proses Path Planning pada Navigasi
Pada gambar 5.31 kita dapat melihat bahwa tahap awal pada diagram alir
dimulai dengan menampilkan input-input yang diterima pada proses ini, dimulai
dari input lokalisasi berupa robot pose dan transformasi, input topik /map, input
koordinat tujuan, dan input topik /scan. Setiap input ini diproses masing-masing
menjadi cost map dan robot pose pada node move base. Misalnya input dari
robot pose & transformation yang merupakan frame dari lokalisasi robot akan
digunakan pada proses update posisi. Kemudian topik /map digunakan pada
proses Global Cost Map, cost map di sini mengacu pada proses yang terdapat
pada paket move base, di dalam move base kita bisa mengatur parameter
costmap yang digunakan.

148
 Gambar 5.78 Diagram Alir Sub Proses Path Planning
Cost map sangat penting karena menjadi variabel halangan untuk proses path
planning, baik itu halangan diam ataupun halangan bergerak. Pada input topik
/scan juga digunakan pada proses Local Cost Map, kurang lebih sama seperti
Global Cost Map bedanya cost map ini digunakan dalam jarak pendek dan
terbaca ketika topik /scan mendeteksi halangan. Kemudian yang terakhir adalah
input dari koordinat tujuan yang berasal dari 2D Nav Goal RViz, input ini
digunakan pada proses Move Base Goal, dimana nilai dari koordinat akan di
publish ke move base goal, sehingga move base akan meminta global path
planning untuk membuatkan jalur terpendek dari posisi robot saat ini menuju
titik koordinat yang di masukkan.
Kemudian dilakukan seleksi kondisi jika koordinat tujuan sudah ditentukan
maka akan memberikan pesan global path planning ke move base, namun jika
149
tidak maka proses akan kembali di ulang ke awal sampai nantinya koordinat
tujuan sudah ditentukan. Ketika koordinat tujuan sudah ditentukan maka akan
mengirimkan pesan global path planning ke move base, sehingga akan
memerintahkan global path planning untuk menentukan jalur terpendek
menggunakan Algoritme Dijkstra. Algoritme Dijkstra mendapatkan 3 input
sekaligus dan mengolahnya ke dalam sub proses Algoritme Dijkstra. Sebagai
tambahan, penggunaan algoritme global dapat diubah dengan mengganti node
global planner di dalam kode paket move base. Penjelasan lebih detail dan
diagram alir mengenai sub proses algoritme Dijkstra dapat dilihat pada gambar
5.32.

Gambar 5.79 Grafik Semua Node Pada Proses Navigasi

Konfigurasi paket move base untuk menggerakkan robot dapat dilihat pada
dan tabel 5.13.
Tabel 5.38 Parameter Konfigurasi Paket Move Base
Konfigurasi
No Parameter Default
Penelitian
base_global_planner "srv_client_plugin/
1 "navfn/NavfnROS"
SrvClientPlugin"
base_local_planner "base_local_planner/ "dwa_local_planner
2 /
TrajectoryPlannerROS
" DWAPlannerROS"
3 recovery_behaviors [] []
4 controller_frequency 20.0 5.0
5 planner_patience 5.0 5.0

150
 6 controller_patience 15.0 15.0
7 conservative_reset_dist 3.0 3.0
recovery_behavior_enabl
8 true true
ed
clearing_rotation_allowe
9 true true
d
10 shutdown_costmaps false false
11 oscillation_timeout 0.0 0.0
12 oscillation_distance 0.5 0.5
13 planner_frequency 0.0 0.0
14 max_planning_retries -1 0

Navigasi membutuhkan cost map untuk memisahkan jalur dengan halangan,

berikut konfigurasi common_costmap.yaml pada dapat dilihat pada tabel 5.14.
Tabel 5.39 Parameter Konfigurasi 2D Common Costmap
No Parameter Default Konfigurasi Penelitian
1 min_particles 100 500
2 max_particles 5000 5000
3 kld_err 0.01 0.01
4 kld_z 0.99 0.99
5 update_min_d 0.2 meters 0.1
6 update_min_a π/6.0 radians 0.2
7 resample_interval 2 2
8 transform_tolerance 0.1 second 0.1 second
9 recovery_alpha_slow 0.0 0.0
10 recovery_alpha_fast 0.0 0.0
11 initial_pose_x 0.0 0.0
12 initial_pose_y 0.0 0.0
13 initial_pose_a 0.0 0.0
14 initial_cov_xx 0.5*0.5 meters 0.5*0.5 meters
15 initial_cov_yy 0.5*0.5 meters 0.5*0.5 meters
16 initial_cov_aa (π/12)*(π/12) rad (π/12)*(π/12) rad

151
17 gui_publish_rate -1.0 Hz -1.0 Hz
18 save_pose_rate 0.5 Hz 0.5 Hz
19 use_map_topic false false
20 first_map_only false false
21 selective_resampling false false
22 laser_min_range -1.0 -1.0
23 laser_max_range -1.0 -1.0
24 laser_max_beams 30 30
25 laser_z_hit 0.95 0.95
26 laser_z_short 0.1 0.1
27 laser_z_max 0.05 0.05
28 laser_z_rand 0.05 0.05
29 laser_sigma_hit 0.2 meter 0.2 meter
30 laser_lambda_short 0.1 0.1
31 laser_likelihood_max_dist 2.0 meter 2.0 meter
32 laser_model_type “likelihood_field" “likelihood_field"
33 odom_model_type “diff” “diff-corrected”
34 odom_alpha1 0.2 0.2
35 odom_alpha2 0.2 0.2
36 odom_alpha3 0.2 0.2
37 odom_alpha4 0.2 0.2
38 odom_alpha5 0.2 0.2
39 odom_frame_id “odom” “odom”
40 base_frame_id “base_link” “base_link”
41 global_frame_id “map” “map”
42 tf_broadcast true true

152
E.1.3.11 Perancangan Proses Algoritme Dijkstra

Gambar 5.80 Diagram Alir Algoritme Dijkstra

Pada gambar 5.33 dapat dilihat bahwa berdasarkan diagram alir, algoritme
Dijkstra dimulai dari memasukkan input awal, tujuan, cost map, dan resolusi ke
dalam parameter fungsi ini. Kemudian terdapat inisialisasi variabel yang

153
dibutuhkan dalam fungsi seperti, variabel open_list, close_list, parents, g_costs,
shortest_path, dan path_found. Lalu terdapat pula inisialisasi fungsi
find_neighbors yang berisikan fungsi untuk melakukan kunjungan ke delapan sisi
tetangga dan inisialisasi variabel array neighbor dan lethal_cost. Tidak lupa untuk
melakukan inisialisasi bahwa nilai free space pada cost map = open_list,
sedangkan obstacle = lethal_cost. Kemudian melakukan inisialisasi pada titik
awal atau node awal berupa indeks awal = parent node dan node awal = g_cost =
0. Selanjutnya semua inisialisasi fungsi dan variabel digabungkan ke dalam fungsi
Dijkstra.
Hal pertama yang dilakukan adalah melakukan looping dengan kondisi, hanya
akan berhenti jika array open_list bernilai kosong. Logika ini digunakan untuk
melakukan pencarian ke seluruh area free space yang ada, jadi selama masih
terdapat nilai pada array open_list maka proses pencarian akan terus berlanjut
hingga target ditemukan. Jika hasilnya true maka program akan mengubah status
node baru menjadi current_node, setelah itu dilakukan seleksi kondisi apakah
current_node merupakan titik koordinat target. Jika true maka status path_found
akan diubah menjadi True dan mengirimkan break untuk menghentikan looping.
Namun jika tidak maka akan dilakukan pencarian ke seluruh tetangga terdekat
dari current_node sebanyak 8 node berdasarkan maksimal sisi yang bisa diraih
dalam 1 node.
Setelah melakukan kunjungan ke node tetangga, maka lakukan seleksi kondisi
untuk memeriksa apakah tetangga sudah pernah dikunjungi. Jika hasilnya true,
maka akan masuk ke proses penambahan jumlah close_list berdasarkan indeks
current_node untuk mencegah mengunjungi node ini lagi dan ubah grid peta
berdasarkan indeks current_node menjadi orange. Jika hasilnya false, maka akan
lakukan proses untuk update nilai g_cost baru dengan menambahkan g_cost
tetangga + 1. Selanjutnya lakukan seleksi kondisi untuk mengetahui apakah
status neighbor atau tetangga adalah open_list, jika hasilnya false maka nilai
g_cost dan parent pada current_node akan tetap atau tidak berubah dan node
akan dimasukkan ke dalam daftar open_list yang kemudian dilanjutkan dengan
proses penambahan array indeks close_list berdasarkan posisi current_node dan
grid peta menjadi orange. Setelah itu proses akan dikembalikan ke open_list lagi
untuk melakukan pengulangan selama masih terdapat data pada open_list.
Namun jika neighbor yang baru merupakan open_list (indeksnya open_list)
maka akan memasuki seleksi kondisi lagi, yakni jika g_cost saat ini kurang dari (<)
g_cost tetangga, maka semua tetangga akan diberikan nilai g_cost yang beru
dengan melakukan update nilai g_cost tetangga = g_cost yang sudah ditambah 1.
Dengan begini tetangga yang baru dikunjungi akan mendapatkan cost+1 dan
parent status dari current_node. Setelah itu proses dilanjutkan dengan
memasukkan tetangga yang sudah di update tadi ke close_list dan ubah grid peta
menjadi orange kemudian proses kembali lagi ke pengulangan open_list. Proses
ini terus berlangsung hingga current_node mencapai titik koordinat tujuan, titik
diketahui karena pada parameter Dijkstra terdapat variabel goal yang berisi letak
koordinat dalam matriks 2 dimensi, yaitu berupa nilai koordinat x dan y. Jika hal

154
ini terjadi maka akan memasuki proses penemuan jalur dengan melakukan
perubahan status pada variabel path_found = True dan fungsi break yang mampu
menghentikan looping atau pengulangan. Perubahan status pada variabel
path_found ditujukan untuk fase rekonstruksi jalur dengan proses backtracking
atau penelusuran jalur secara terbalik dari titik awal menuju titik tujuan
berdasarkan data yang ada di close_list. Jika status path_found == false yang
artinya jalur tidak ditemukan sama sekali, maka akan melakukan skip pada fase
rekonstruksi dan mengembalikan nilai berupa output dengan pesan “path not
found”. Adapun hasil yang didapatkan akan mengembalikan nilai output berupa
variabel shortest_path proses algoritme Dijkstra telah selesai. Navigasi
membutuhkan global planner untuk menentukan jalur, berikut konfigurasi
global_planner.yaml untuk membuat path yang dapat dilihat pada dan tabel 5.15
Tabel 5.40 Parameter Konfigurasi Dijkstra Global Planner
Konfigurasi
No Parameter Default
Penelitian
1 allow_unknown true true
2 default_tolerance 0.0 0.0
3 visualize_potential false false
4 use_dijkstra true true
5 use_quadratic true true
6 use_grid_path false false
7 old_navfn_behavior false false
8 lethal_cost 253 253
9 neutral_cost 50 50
10 cost_factor 3.0 3.0
11 publish_potential true true
12 orientation_mode 0 0
13 orientation_window_size 1 1
14 outline_map true true
15 planner_window_x 0.0 0.0
16 planner_window_y 0.0 0.0
17 default_tolerance 0.0 0.0
18 publish_scale 100 100
planner_costmap_publish
19 0.0 0.0
_frequency

155
E.1.3.12 Perancangan Proses Algoritme Dynamic Local Approach (DWA)

Gambar 5.81 Diagram Alir Algoritme Dynamic Window Approach

Pada gambar 5.34 ditunjukkan diagram alir algoritme dynamic window
approach yang dikutip dari penelitian yang dilakukan oleh (Liu, dkk., 2021),
dalam penelitiannya Li-sang Liu menjelaskan diagram alir ini dengan keterangan
rumus yang terjadi di dalam setiap prosesnya. Algoritme ini dimulai dengan
melakukan analisis data posisi robot yang didapat dari data localization AMCL
dan EKF. Kemudian ada juga data dari halangan bergerak yang didapat dari
topik /scan yang mengenai halangan dan dianggap sebagai cost map. Proses
dilanjutkan dengan melakukan sampel kecepatan pada robot saat sedang

156
bergerak, proses ini menggunakan kisaran dari kecepatan robot maksimum dan
minimumnya menggunakan rumus:
V m ={ ν ∈ [V min , V max ] , ω ∈ [ ω min , ω max ] }. (5.2)

Untuk setiap kecepatan sampel, lakukan simulasi maju dari kondisi robot saat
ini untuk memprediksi apa yang akan terjadi jika kecepatan sampel diterapkan
untuk beberapa waktu (pendek). Setelah melakukan pengambilan sampel
kecepatan, dilakukan proses untuk menghasilkan jalur lintasan. Dilakukan
pemantauan dengan seleksi kondisi, apakah akan terjadi tabrakan dengan
rintangan. Jika hasilnya true, maka diperlukan hasil jalur lintasan yang baru
menggunakan fungsi hasilkan jalur lintasan. Fungsi ini menggunakan fungsi
standar DWA dengan rumus:
G ( ν , ω )=γ × vel ( ν , ω ) +α ×h eading ( ν , ω ) + β × distant ( ν ,ω ) (5.3)
Fungsi ini melakukan perhitungan kemungkinan ke setiap sudut dengan arah
lintasan yang berbeda-beda. Proses ini melakukan evaluasi (skor) setiap lintasan
yang dihasilkan dari simulasi ke depan, menggunakan metrik yang
menggabungkan karakteristik seperti: kedekatan dengan rintangan, kedekatan
dengan tujuan, kedekatan dengan jalur global, dan kecepatan. Ilustrasi mengenai
proses ini dapat dilihat pada gambar 5.35.

Gambar 5.82 Simulasi Maju Prediksi Pergerakan Robot

Namun jika hasilnya adalah false, yang artinya robot tidak akan bertabrakan
dengan rintangan. Maka akan melakukan proses pemilihan lintasan yang optimal
dari jalur lintasan sebelumnya. Proses ini memilih lintasan dengan skor tertinggi
dan mengirim kecepatan terkait ke base robot. Jika proses telah selesai lakukan
seleksi kondisi, jika jalan jalur lintasan telah selesai maka proses algoritme DWA
dapat diselesaikan, namun jika tidak maka lakukan pengulangan dari proses
menghasilkan jalur lintasan. Navigasi membutuhkan local planner untuk
menentukan jalur, berikut konfigurasi local_planner.yaml untuk membuat path
yang dapat dilihat pada dan tabel 5.16.
Tabel 5.41 Parameter Konfigurasi DWA Local Planner
No Parameter Default Konfigurasi

157
 Penelitian
1 acc_lim_x 2.5 10
2 acc_lim_y 2.5 0
3 acc_lim_th 3.2 3.4
4 max_vel_trans 0.55 1.0
5 min_vel_trans 0.1 0.05
6 max_vel_x 0.55 0.7
7 min_vel_x 0.0 0.2
8 max_vel_y 0.1 0.0
9 min_vel_y -0.1 0.0
10 max_rot_vel 1.0 0.5
11 min_rot_vel 0.4 0.2
12 yaw_goal_tolerance 0.05 0.4
13 xy_goal_tolerance 0.10 0.4
14 latch_xy_goal_tolerance false false
15 sim_time 1.7 1.7
16 sim_granularity 0.025 0.025
17 vx_samples 3 3
18 vy_samples 10 10
19 vth_samples 20 20
20 controller_frequency 20.0 20.0
21 path_distance_bias 32.0 32.0
22 goal_distance_bias 24.0 24.0
23 occdist_scale 0.01 20
24 forward_point_distance 0.325 0.325
25 stop_time_buffer 0.2 0.2
26 scaling_speed 0.25 0.25
27 max_scaling_factor 0.2 0.2
28 publish_cost_grid false false
29 oscillation_reset_dist 0.05 0.25
30 prune_plan true true
31 controller_frequency 0.0 5.0
158
 32 recovery_behavior_enabled false true
33 conservative_reset_dist 0.0 0.2

Setelah melakukan tahapan algoritme DWA maka proses akan kembali ke

diagram perencanaan jalur. Dihasilkan output berupa perencanaan jalur terdekat
lokal dan melakukan proses pembaharuan jalur lintasan yang ada pada output
perencanaan jalur utama dari titik koordinat awal hingga koordinat tujuan.
Setelah itu maka proses perencanaan jalur telah selesai.
Kembali ke program utama navigasi, alir terhenti pada sub proses path
planning dengan Dijkstra dan DWA, setelah jalur dibuat maka akan mengirimkan
jalur tersebut ke geometry_msgs/Twist dan mengubah nilai menjadi kecepatan,
vector, dan pose. Selama proses ini robot akan mulai bergerak hingga terjadi
beberapa perubahan kondisi. Jika koordinat tujuan sudah tercapai, maka akan
mengirimkan pesan “goal reached” dan program navigasi telah selesai. Namun
jika tidak maka akan dilakukan seleksi kondisi kembali, apakah navigasi
dibatalkan paksa, jika ya maka mengirimkan pesan navigasi selesai dan robot
berhenti. Namun jika tidak, maka akan memberikan input topik cmd_vel berupa
nilai kecepatan dalam m/s dan motor pun akan berputar sehingga robot
bergerak. Output dari motor akan menghasilkan putaran roda yang nantinya
digunakan untuk data odometry. Proses ini terus berulang hingga robot
mencapai titik tujuan dan akhirnya program utama navigasi selesai.
Tahapan perancangan telah selesai, kini memasuki tahapan implementasi
sistem untuk diimplementasikan secara riil. Pada tahapan ini penulis akan
mendokumentasikan bagaimana sistem tersebut berbentuk dan bagaimana
pemrograman dari sistem ini bekerja.

E.2 Implementasi Sistem

Implementasi sistem merupakan realisasi dari tahapan perancangan yang
telah disusun sebelumnya untuk diimplementasikan secara riil. Dalam
implementasi sistem ini akan terbagi menjadi 3 bagian yaitu implementasi
prototype sistem, implementasi perangkat keras, dan implementasi perangkat
lunak. Pada tiap proses implementasi akan dijelaskan terkait proses untuk
pengaplikasian secara langsung menjadi sebuah satu sistem yang utuh.

E.2.1 Implementasi Skematis Prototype Sistem

Implementasi skematis prototype sistem merupakan bentuk implementasi
dari desain yang telah dirancang sebelumnya, mulai dari chassis kayu, chassis 3D,
dan prototype keseluruhan sistem. Pada perancangan chassis badan robot dari
kayu sebelumnya pada dapat dilihat gambar 5.1, digunakan bahan dengan dasar
papan kayu sebagai badan robot bagian depan untuk menyimpan beberapa

159
komponen sekaligus tempat barang akan ditaruh. Dokumentasi mengenai hasil
pembuatan chassis badan robot dari kayu dapat dilihat pada gambar 5.36.

Gambar 5.83 Dokumentasi Hasil Pembuatan Chassis Badan Robot

Pada gambar 5.36 diperlihatkan hasil dari pembuatan chassis bagian robot
yang terbuat dari kayu. Pada implementasinya dibutuhkan 4 buah papan kayu
dengan ukuran minimal 40 cm x 40 cm. Papan kayu pertama dijadikan sebagai
alas dan papan kedua lagi dijadikan sebagai penahan bagian samping. Penahan
bagian samping ini berasal dari 1 papan 40 cm x 40 cm yang di potong
menggunakan gergaji menjadi 4 bagian yang masing-masing berukuran 10 cm x
40 cm. Bagian penahan ini hanya digunakan untuk sisi kiri, kanan, dan belakang.
Bagian sisi depan akan di isi dengan papan kayu yang ketiga yang di potong
berukuran 30 cm x 40 cm. Kemudian papan yang ke empat digunakan sebagai
penutup atas tanpa perlu di potong. Penutup ini berfungsi sebagai dudukan dari
barang yang akan dibawa oleh robot dan sekaligus sebagai pelindung komponen
di dalamnya dari tetesan air.
Setelah membuat chassis badan robot, langkah selanjutnya adalah membuat
chassis untuk menyimpan motherboard dan baterai yang kita sebut sebagai
chassis mainboard. Chassis ini dibuat menggunakan cetakan 3D print yang
mencetak beberapa bagian dari semua desain yang ada pada gambar 5.2 dan
menggabungkannya menjadi satu. Gambar 5.41 merupakan dokumentasi dari
proses pencetakan desain menggunakan 3D printer.

160
 Gambar 5.84 Dokumentasi Pencetakan Desain Dengan 3D Printer
Semua bagian dirancang untuk dicetak pada printer 3D dengan teknologi
FFM/FDM. Volume cetak setidaknya minimal harus berukuran 300mm x 300mm
x 200mm. Gambar 5.37 merupakan gambar mesin 3D print yang digunakan
untuk mencetak bagian mainboard robot. Bahan yang digunakan untuk
mencetak adalah filamen 3D dengan tipe PETG sebanyak 2 kilogram. PETG
memiliki titik leleh reaksi lebih tinggi dari PLA sehingga dapat digunakan di
bawah terik matahari (titik leleh terendah 70-80 derajat Celsius) dan titik leleh
hingga ke bentuk cairan juga cukup tinggi walau tidak setinggi ABS (titik leleh
bentuk cair berada pada 230-240 derajat Celsius. Titik ini digunakan sebagai
acuan minimal panas yang dibutuhkan oleh 3D print untuk mencairkan PETG.
Penggunaan PETG juga ramah lingkungan dan tidak beracun serta aman jika
tertelan (tidak mengandung toxic, murni plastik dan campuran bahan penguat
lainnya akan tetapi tetap tidak boleh dimakan). ABS memiliki sifat beracun dan
berbahaya saat melakukan 3D print tanpa penutup karena menghasilkan gas
buang yang berbahaya jika terhirup. Detail mengenai bagian yang dicetak dapat
dilihat pada tabel 5.17.
Tabel 5.42 Daftar Bagian Yang Dicetak
No Nama bagian Berat Durasi Jumlah
1 Motor lower 800 gram 96 jam 1
2 Motor upper 486 gram 52 jam 1
3 Wheel arch 406 gram 36 jam 2
4 Sensor base 90 gram 8 jam 1
5 Upper cover 80 gram 7 jam 1
6 Motor clamp 25 gram 2 jam 2
7 Motor cover 48 gram 5 jam 1

161
 Sebelum melakukan cetak, desain yang sudah dibuat harus di konversi ke file
yang dapat dibaca oleh 3D printer menggunakan aplikasi Creality Slicer. Di dalam
aplikasi Creality Slicer terdapat banyak pengaturan yang dapat diubah
sedemikian rupa mengikuti jenis filamen yang digunakan. Pengaturan yang
digunakan untuk mencetak daftar bagian pada tabel 5.12 menggunakan aturan
sebagai berikut:
 0.2 mm Layer Height
 0.4 mm Nozzle
 4 Bottom and 4 Top Layer
 4 Perimeter
 18% Infill
 Suhu Nozzle 240o C
 Suhu Plat/Alas 70o C
 Speed printing 100%
Hasil cetak 3D print digabungkan satu sama lainnya menggunakan brass nut.
Lubang brass nut sudah tersedia pada desain 3D dan semua lubang yang ada
harus dipasangi brass nut sebagai dudukan yang mengunci baut. Untuk
memasang brass nut diperlukan tambahan mesin bor listrik dan solder. Brass nut
sering digunakan pada kayu sebagai dudukan dari baut agar tidak merusak
sekaligus mengunci baut. Teknik memasangnya adalah dengan menambahkan
area permukaan lubang dengan mata bor yang ukurannya sebesar lubang, ini
dilakukan agar ketika solder memanaskan brass nut dan dimasukkan ke dalam,
sisa filamen yang terjebak di dalam lubang tidak keluar dari lubang brass nut, hal
ini dapat merusak brass nut karena disusupi oleh filamen. Dokumentasi dari
pemasangan brass nut dapat dilihat pada gambar 5.38.

Gambar 5.85 Dokumentasi Pemasangan Brass Nut

Setelah semua komponen cetak di pasang dengan brass nut, langkah
selanjutnya adalah menggabungkan chassis mainboard dengan chassis badan

162
kayu menggunakan baut dan mur lock. Terkait jumlah baut dan mur yang
dibutuhkan dapat dilihat pada tabel 5.18.
Tabel 5.43 Mur, Baut, Dan Sekrup Yang Digunakan
No Nama
Knurled brass nut M3 -
1 min. 20
tinggi 4mm
Knurled brass nut M4 -
2 min. 20
tinggi 8mm
3 Cylinder screw M2 x 5
4 Cylinder screw M3 x 10
5 Cylinder screw M3 x 32
6 Cylinder screw M4 x 16
7 Cylinder screw M5 x 25
8 Cylinder screw M5 x 40
9 Cylinder screw M8 x 30
10 Bolt Screw M3 x 16
11 Bolt Screw M3 x 20
12 Bolt Screw M3 x 30
13 Bolt Screw M3 x 40
14 Angle Bracket Clips
15 Bolt Screw Stainless
16 Lock Nuts M4
17 Lock Nuts M5
Jumlah Keterangan
dudukan baut M3 di dalam
bagian 3D
dudukan yang sambung wheel
arch dengan motor lower
mengunci sensor RPLiDAR
4
dengan bagian sensor_base
mengunci bagian depan mow
2
upper
mengunci bagian belakang
2
mow upper
mengunci arch wheel ke motor
8
lower
mengunci motor lower dengan
10
chassis kayu
mengunci caster wheel dengan
8
chassis kayu
mengunci motor hoverboard di
4
dalam motor lower
mengunci bagian motor upper
2
ke motor lower sisi depan
mengunci bagian upper cover
4
dengan motor upper
mengunci bagian motor upper
1
ke motor lower sisi belakang
mengunci bagian motor upper
2
ke motor lower sisi belakang
menahan bagian bawah chassis
3
kayu bagian tengah
mengunci bracket dengan
6
chassis kayu
8 menjepit motor clamp
30 menjepit bagian baut M5
163
 18 Washers M5 20 alas dari screw dan nuts

Gambar 5.86 Hasil Assembling Chassis Robot

Daftar kebutuhan baut, mur, sekrup, dan brass nut yang digunakan,
merupakan bentuk implementasi dari penelitian ini. Hasil dari proses assembling
ini dapat dilihat pada gambar 5.39, dimana robot sudah berhasil terpasang
dengan sedikit penambahan tampilan.
Setelah komponen dan chassis telah siap, tahap selanjutnya kita perlu
melakukan assembling komponen menjadi satu kesatuan robot. Hal ini
merupakan akhir dari perancangan skematis prototype sistem. Hasil
implementasi robot dapat dilihat pada gambar 5.40 dan gambar 5.41.

Gambar 5.87 Implementasi Prototype Sistem Robot Tampak Samping

164
 Gambar 5.88 Implementasi Prototype Sistem Robot Tampak Atas
Hasil akhir dari implementasi sistem adalah sebuah prototype robot
pengantar barang dengan dua roda penggerak dan satu roda statis. Seperti
dalam perancangannya bahwa semua komponen ditelakan di dalam chassis
badan yang terbuat dari kayu. Kemudian bagian depan robot ditambahkan
dudukan untuk menaruh sensor RPLiDAR.

E.2.2 Implementasi Perangkat Keras

Implementasi perangkat keras merupakan bagian dari merealisasikan hasil
dari perancangan perangkat keras sebelumnya. Semua komponen perangkat
keras yang telah dirancang dipastikan berfungsi atau tidaknya dalam mencapai
tujuan yang diinginkan. Implementasi pada perangkat keras akan menggunakan
mikro komputer dan personal komputer sebagai media pendukung dalam
pembuatan. Personal komputer juga dijadikan sebagai komputer server yang
memantau dan menampilkan output dari sistem. Hal pertama yang ditunjukkan
pengimplementasiannya adalah proses pembuatan sistem mainboard/penggerak
robot.
Sesuai dengan perancangan, komponen mainboard/penggerak pada
penelitian tidak menggunakan bagian yang terpisah, melainkan menggunakan
perangkat elektronik yang dijual secara masal yaitu hoverboard. Komponen
motherboard, baterai Li-ion, dan motor BLDC diambil dari perangkat hoverboard
tersebut. Jenis hoverboard yang dipakai adalah hoverboard dengan lebar roda
6.5 inch dan memiliki single motherboard. Untuk melihat dokumentasi dan
perangkat hoverboard yang dipakai dapat dilihat pada gambar 5.42.

165
 Gambar 5.89 Perangkat Hoverboard Yang Digunakan
Pembuatan sistem ini dimulai dengan melakukan percobaan menggunakan
motherboard dengan komputer personal terlebih dahulu tanpa menggunakan
mikro komputer, Jetson Nano. Tujuan dari percobaan ini adalah untuk
memastikan bahwa roda dapat berputar dengan kendali dari output komputer.
Selain memastikan roda dapat berputar, dalam implementasinya proses ini
digunakan untuk memasangkan firmware baru ke dalam motherboard.

Gambar 5.90 Dokumentasi Pembuatan Sistem Mainboard Robot

Pada gambar 5.43 ditunjukkan bahwa kita dapat melihat roda berputar dan
motherboard sudah dalam keadaan flashing firmware, diperlihatkan dengan
STLink yang sudah terlepas dari motherboard. Pemasangan kabel untuk
melakukan flashing motherboard ditunjukkan pada tabel 5.19.
Tabel 5.44 Pemasangan Kabel Untuk Flashing Motherboard
Perangkat Keras Pin Motherboard Komputer
3.3 V 3.3 V MCU
SWCLK SWCLK MCU
STLink V2 mini Port USB
GND GND MCU
SWDIO SWDIO MCU

166
 Seperti yang sudah dijelaskan dalam perancangan perangkat keras sistem,
bahwa sistem mainboard/penggerak robot terdiri dari motherboard dan baterai
yang terhubung dengan komputer menggunakan FTDI mini USB. Hasil akhir dari
implementasi sistem penggerak robot dapat dilihat pada gambar 5.44.

Gambar 5.91 Implementasi Sistem Penggerak Robot

Gambar 5.44 merupakan hasil pengimplementasian dari sistem penggerak
robot pada prototype autonomous mobile robot. Sistem penggerak ini terdiri dari
beberapa komponen elektronik yang diletakkan di dalam chassis mainboard
robot. Dengan menggunakan 2 buah roda aktif sebagai aktuator penggeraknya
yang dihubungkan dengan motherboard hoverboard. Sebenarnya sistem ini
sudah dapat di operasikan dengan menggunakan remote kontrol karena sudah
terhubung dengan komputer. Komponen yang digunakan dalam sistem ini
merupakan komponen penyusun utama yang terdiri dari mikro komputer Jetson
Nano, motherboard hoverboard, baterai li-ion 10S2P, dan juga komponen
pendukung lainnya seperti FTDI mini USB, kabel mikro USB, power button,
charger port, power bank, dan banyak kabel lainnya. Semua komponen ini tidak
ditaruh menjadi satu di dalam chassis hitam ini saja karena sistem penggerak
robot memerlukan tutup pada chassis untuk menghindari percikan air. Jika
menggunakan tutup maka chassis ini tidak akan bisa di tutup karena tidak muat
terhalang mikro komputer dan power bank, selain itu dikhawatirkan mikro
komputer akan mengalami overheat.
Jetson Nano digunakan sebagai pemrosesan utama dalam sistem ini, semua
jenis pemrosesan seperti pengolahan data sensor dan pengendalian sistem
hoverboard juga dikendalikan oleh perangkat mikro komputer ini. Jetson Nano
mendapatkan sumber daya dari power bank dengan masukan 5 volt. Jetson Nano
juga terhubung dengan motherboard menggunakan kabel sensor sebelah kanan
motherboard. Kabel sensor ini dapat dimanipulasi sehingga mampu
menggerakkan motor BLDC. Motor ini terhubung langsung dengan motherboard
pada pin phase dan socket kabel hall. Motor ditenagai langsung oleh
motherboard yang diambil dari sumber daya baterai lithium ion dengan tipe

167
baterai 10S2P yang memiliki voltase hingga 42 volt. Penjelasan lebih lanjut
mengenai penyambungan kabel dan port akan dijelaskan pada tabel 5.20.
Tabel 5.45 Pemasangan Kabel Perangkat Keras Sistem Penggerak
Perangkat Keras Pin Tujuan Pin
Phase A Phase A MCU
Phase B Phase B MCU
Phase C Phase C MCU
HALL A HALL A
Motor BLDC Motherboard
HALL B HALL B
HALL C HALL C
GND GND
VCC VCC
PB10/TX/USART3 RX
Motherboard PB11/RX/USART3 FTDI mini USB TX
GND GND
RX
FTDI mini USB TX Jetson Nano Port USB
GND
36 volt VCC XT60 VCC
Baterai Li-Ion Motherboard
GND XT60 GND
Power Bank Port USB Jetson Nano Port Mikro USB

Setelah selesai mengimplementasikan sistem penggerak robot, maka

implementasi selanjutnya adalah menghubungkan sensor RPLiDAR dan IMU pada
Jetson Nano sebagai sistem persepsi robot. Berdasarkan perancangan, sensor ini
di pasang setelah kedua chassis terhubung dan posisi robot sudah dalam kondisi
tetap. Sensor RPLiDAR diposisikan pada bagian depan robot, hal ini ditujukan
untuk memudahkan pembacaan ketika terdapat barang di bagian tengah robot.
Jika sensor RPLiDAR ditaruh pada bagian belakang robot, maka ketika ada barang
yang lebih tinggi posisinya dari pada sensor RPLiDAR, maka robot tidak akan bisa
melihat lingkungan bagian depan yang mengakibatkan tidak bisanya dilakukan
perencanaan jalur. Sebaliknya jika di posisi depan maka setidaknya RPLiDAR
masih mampu membaca lingkungan di depan dan posisi halangan membelakangi
gerak maju robot, sehingga perencanaan jalur tidak akan terganggu.
Dokumentasi dari implementasi ini dapat dilihat pada gambar 5.45.

168
 Gambar 5.92 Implementasi Sistem Persepsi Robot Dengan Sensor
Pada gambar 5.45 dapat dilihat bahwa sensor RPLiDAR berdiri di atas
dudukan sensor dan tiang penyangga dengan tinggi 50 cm dari lantai yang
terhubung langsung dengan Jetson Nano menggunakan kabel mikro USB dan
adapter USB yang tergantung di tiang penyangga. Sedangkan sensor IMU persis
terletak di tengah robot yang terhubung langsung dengan Jetson Nano
menggunakan kabel jumper. Sensor RPLiDAR menggunakan protokol komunikasi
serial menggunakan UART, sedangkan sensor IMU menggunakan protokol
komunikasi serial menggunakan I2C. Penjelasan lebih lanjut mengenai
penyambungan kabel dan port akan dijelaskan pada tabel 5.21.
Tabel 5.46 Pemasangan Kabel Sistem Sensor
Perangkat Keras Pin Tujuan Pin
GND GND
TX TX
RX RX
RPLiDAR V5 UART TTL Adapter V5
GND GND
MOTOCLT DTR
VMOTO VCC
UART Adapter Mikro USB Jetson Nano Port USB
VCC 3.3V
GND GND
GY 521 IMU Jetson Nano
SCL GPIO (SCL)
SDA GPIO 3 (SDA)

169
E.2.3 Implementasi Perangkat Lunak
Implementasi perangkat lunak merupakan bagian dari merealisasikan
algoritma pada sistem dari bab perancangan perangkat lunak sebelumnya.
Implementasi ini akan meliputi realisasi dari persiapan awal, program utama dan
sub proses dari algoritma yang akan dijelaskan pada sub bab berikut.
E.2.3.1 Implementasi Persiapan Awal Motherboard
Implementasi persiapan awal motherboard ditujukan untuk melakukan
proses flashing firmware yang sudah diubah ke dalam motherboard dengan
menggunakan adapter berupa STLink V2. Urutan untuk melakukan proses ini
sesuai dengan yang sudah dijelaskan sebelumnya pada perancangan perangkat
lunak. Pin firmware pada motherboard dihubungkan terlebih dahulu dengan
STLink menggunakan kabel jumper dengan susunan pin yang diperlihatkan pada
gambar 5.16. Setelah selesai pemasangan kabel, selanjutnya adalah melakukan
koneksi dengan komputer personal via STMCube dengan klik tombol “Connect”
hingga status berubah menjadi “Connected” dan tombol berubah menjadi
“Disconnect” kemudian uncheck value RDP pada tab Option Bytes dan klik apply.
Koneksi berhasil jika pesan yang muncul seperti pada gambar 5.46.

Gambar 5.93 Pesan Berhasil Melakukan Hapus Penuh Chip

Setelah selesai melakukan hapus firmware dan unlock protection, langkah
selanjutnya adalah melakukan konfigurasi firmware, tepatnya mengubah file
config.c yang ada pada firmware open source yang sudah di fork pada
https://github.com/EFeru/hoverboard-firmware-hack-FOC. Konfigurasi ini
bertujuan untuk menyesuaikan varian yang dibutuhkan dengan mengubah baris
kode yang berbeda dari firmware asalnya, dengan uncomment, comment, atau
edit baris kode tertentu. Varian di sini adalah jenis protokol komunikasi apa yang
akan digunakan, apakah menggunakan ADC, USART, PPM, PWM, IBUS dan masih
banyak lagi. Terkait kode program untuk konfigurasi firmware dapat dilihat pada
tabel 5.22.

170
 Tabel 5.47 Kode Program Konfigurasi Firmware Motherboard Hoverboard
Kode Program
No
hoverboard-firmware-hack-FOC/Inc/config.h
12 #if !defined(PLATFORMIO)
13 //#define VARIANT_ADC
14 #define VARIANT_USART
15 //#define VARIANT_NUNCHUK
16 //#define VARIANT_PPM
17 //#define VARIANT_PWM
18 //#define VARIANT_IBUS
19 //#define VARIANT_HOVERCAR
20 //#define VARIANT_HOVERBOARD
21 //#define VARIANT_TRANSPOTTER
22 //#define VARIANT_SKATEBOARD
23 #endif
... ...
176 #define INACTIVITY_TIMEOUT 30
177 #define BEEPS_BACKWARD 0
178 #define ADC_MARGIN 100
179 #define ADC_PROTECT_TIMEOUT 100
180 #define ADC_PROTECT_THRESH 200
181 //#define AUTO_CALIBRATION_ENA
... ...
310 // ############ VARIANT_USART SETTINGS ############
311 #ifdef VARIANT_USART
312
313 //#define CONTROL_SERIAL_USART2 0
314 //#define FEEDBACK_SERIAL_USART2
315
316 // #define SIDEBOARD_SERIAL_USART2 0
317 // #define CONTROL_SERIAL_USART2 0
318 // #define FEEDBACK_SERIAL_USART2
319
320 // #define SIDEBOARD_SERIAL_USART3 0
321 #define CONTROL_SERIAL_USART3 0
322 #define FEEDBACK_SERIAL_USART3
323
324 // #define DUAL_INPUTS
325 #define PRI_INPUT1 3, -1000, 0, 1000, 0
326 #define PRI_INPUT2 3, -1000, 0, 1000, 0
327 #ifdef DUAL_INPUTS
328 #define FLASH_WRITE_KEY 0x1102
329 /// #define SIDEBOARD_SERIAL_USART2 1
330 /// #define SIDEBOARD_SERIAL_USART3 1
331 #define AUX_INPUT1 3, -1000, 0, 1000, 0
332 #define AUX_INPUT2 3, -1000, 0, 1000, 0
333 #else
334 #define FLASH_WRITE_KEY 0x1002
335 #endif
336
337 // #define SUPPORT_BUTTONS_LEFT
338 // #define SUPPORT_BUTTONS_RIGHT
339 #endif
340 // ############ END OF VARIANT_USART SETTINGS ############

171
 Tabel di atas merupakan kode program untuk mengonfigurasi firmware
motherboard hoverboard yang berisikan potongan-potongan baris yang
pentingnya saja. Jumlah baris kode pada file config.h adalah 772, akan tetapi
hanya beberapa baris kode saja yang diubah tetapi mampu mempengaruhi
keseluruhan kode. File config.c merupakan file library menggunakan bahasa
pemrograman C. Di bawah ini penjelasan mengenai kode program konfigurasi
firmware motherboard hoverboard.
1. Baris ke-12, merupakan if preprocessor dengan kondisi jika macro
PLATFORMIO tidak terdefinisi maka kondisi true, jika tidak maka false.
Baris ini bertujuan agar proses flashingdapat menggunakan extensi
PlatformIO, sehingga melakukan upload bisa dilakukan dengan mudah.
2. Baris ke-13 (non aktif/dikomentar), merupakan macro define varian
untuk input ADC. Jika ingin melakukan kontrol menggunakan sensor
potensiometer maka baris ini di aktifkan.
3. Baris ke-14, merupakan macro define varian untuk input menggunakan
serial control USART. Jika ingin melakukan kontrol menggunakan
komputer melalui RX/TX maka baris ini harus di aktifkan. Penelitian ini
menggunakan kontrol dari USART, maka dari itu baris ini di aktifkan
dengan batalkan komentar.
4. Baris ke-15 hingga 22 (non aktif/dikomentar), merupakan macro define
varian untuk input dengan mode-mode lainnya, setiap dari setiap baris
kode memiliki sinyalnya masing-masing namun karena Penelitian ini
menggunakan USART maka kita berfokus pada baris ke 14 saja.
5. Baris ke-23, merupakan akhir atau penutup dari if preprocessor. Jika #if
preprocessor sudah dilakukan maka wajib mengakhirinya menggunakan
#endif.
6. Baris ke-176, merupakan INACTIVITY_TIMEOUT, yaitu ketika motor tidak
bergerak sama define macro sekali setelah motherboard menyala maka
motherboard akan mati. Nilai 30 berarti baru akan shutdown ketika 30
menit tidak bergerak.
7. Baris ke-177, merupakan define macro BEEPS_BACKWARD, yaitu ketika
roda mundur maka akan berbunyi. Nilai 0 berarti false, dan beep tidak
akan berbunyi.
8. Baris ke-178 - 180, merupakan define macro ADC_MARGIN, yaitu min dan
max menggunakan input ADC.
9. Baris ke-179, merupakan define macro ADC_PROTECTED_TIMEOUT, yaitu
timeout yang digunakan untuk proteksi dari kesalahan input ADC.
10. Baris ke-180, merupakan define macro ADC_PROTECT_THRESH, yaitu
threshold yang dibutuhkan untuk proteksi input ADC. ADC perlu ada
proteksi karena nilainya yang cepat dan sensitif untuk berubah.

172
 11. Baris ke-181 (non aktif/dikomentar), merupakan define
AUTO_CALIBRATION_ENA, yaitu ketika hoverboard baru menyala maka
akan melakukan auto kalibrasi namun sebelumnya harus menekan
tombol power dengan waktu yang lama. Macro ini tidak dibutuhkan jadi
non aktifkan atau dikomentar saja.
12. Baris ke-310 hingga 340, merupakan konfigurasi untuk menggunakan
USART3 (kabel sensor motherboard kanan) sebagai input RX/TX.
Komentar semua define yang berhubungan dengan USART2 atau
SIDEBOARD, cukup aktifkan baris CONTROL_SERIAL_USART3 0 dan
FEEDBACK_SERIAL_USART3. Masing-masing fungsinya untuk melakukan
kontrol dan menerima feedback, sehingga mampu menerima sinyal
cmd_vel dan membaca topik odometry.
Setelah melakukan konfigurasi file config.h sesuai dengan proses yang ada
pada perancangan perangkat lunak, langkah selanjutnya adalah melakukan
flashing. Namun sebelum melakukan flashing, kita harus mengonfigurasi file
platformio.ini. Batalkan komentar pada baris ke-13 yang berisi default_envs =
VARIANT_USART, hal Ini agar secara otomatis platform io melakukan compile dan
upload pada varian USART. Jika tidak di batalkan komentar, maka semua varian
akan di compile sekaligus. Jika sudah maka langkah selanjutnya adalah compile
keseluruhan firmware dengan klik ikon check pada bagian status bar. Jika sudah
maka hasil compile disimpan pada directory .pio/build/VARIANT_USART. Langkah
selanjutnya adalah melakukan upload file biner dengan klik ikon panah ke kanan
pada status bar, pastikan motherboard masih terkoneksi dengan komputer
personal. Jika sudah maka akan muncul pesan sukses di terminal Visual Studio
Code seperti yang terlihat pada gambar 5.47.

Gambar 5.94 Implementasi Hasil Compile, Upload, dan Flashing Motherboard

Hoverboard
E.2.3.2 Implementasi Persiapan Awal Jetson Nano (Proses A)
Implementasi persiapan awal Jetson Nano terdiri dari beberapa pengaturan
komunikasi dan konfigurasi. Persiapan awal Jetson Nano bertujuan untuk
memudahkan pembaca dalam mengetahui apa saja yang dibutuhkan sebelum
membuat kode untuk program utama. Penelitian ini menggunakan banyak sekali
library dan paket/modul dari berbagai kode sumber untuk menunjang sistem
173
otomatisasi manuver robot. Sesuai dengan diagram alir perancangan perangkat
lunak pada sub bab sebelumnya, proses awal dari persiapan ini adalah membuat
komunikasi antara Jetson Nano dengan komputer server via Virtual Network
Computing (VNC). Langkah-langkahnya sebagaimana berikut:
1. Hubungkan Jetson Nano dengan jaringan Wi-Fi yang sama dengan komputer
server. Pada implementasinya kedua perangkat ini terhubung pada Wi-Fi
dengan SSID “Redmi” yang merupakan nama hotspot smartphone. Jadi pada
penelitian ini, penulis menggunakan hotspot portable dari smartphone
sebagai media komunikasi Jetson Nano dengan personal komputer/komputer
server.
2. Jalankan perintah pada terminal Jetson Nano untuk mendapatkan alamat
IPv4 yang diberikan Wi-Fi ke Jetson Nano
$ ip addr
Pada pengimplementasiannya alamat IPv4 yang ada di Jetson Nano adalah
192.168.43.133
3. Pada sisi personal komputer/komputer server, masukkan alamat IP Jetson
Nano ke dalam VNC Client, lalu tekan enter. VNC akan meminta password
untuk login ke OS Ubuntu, masukkan password tersebut sesuai dengan
password user.
4. Jika berhasil maka akan muncul tampilan OS Ubuntu Jetson Nano seperti
halnya tampilan saat melakukan virtual operating system.

Gambar 5.95 Implementasi Hasil Remote Access Ke Jetson Nano via VNC
Berhasil
Setelah berhasil melakukan remote access ke VNC seperti yang terlihat pada
gambar 5.48, maka langkah selanjutnya adalah konfigurasi port USB dan driver
sensor. Konfigurasi port USB berguna untuk memudahkan penamaan dan
penggunaannya. Sama halnya dengan sistem operasi Windows, di Linux setiap
USB yang memiliki data di dalamnya akan memiliki nama port masing-masing,
yaitu ttyUSB. Namun permasalahannya jika port yang di masukkan lebih dari

174
satu, maka akan menyulitkan proses penelitian karena perlu mengubah kode
launch ketika USB FTDI dengan USB RPLiDAR tertukar. Selain itu jika tidak
memberikan penamaan khusus, maka kita harus terus menuliskan ulang hak
akses setiap port USB baru ditancapkan. Dengan memberikan alias pada setiap
port USB, maka masalah ini dapat diselesaikan dan proses penelitian menjadi
lebih mudah. Berikut ini langkah-langkah melakukan konfigurasi port USB:
1. Pertama hubungkan RPLiDAR dan FTDI pada port USB Jetson Nano. Pada
terminal Jetson Nano periksa apakah perangkat terbaca dengan mengetik
perintah:
$ ls /dev/ttyUSB*
2. Selanjutnya berikan hak akses read, write, dan execute pada kedua port
dengan mengetikan perintah:
$ sudo chmod 666 /dev/ttyUSB*
3. Setelah itu periksa idVender dan idProduct dengan mengetik perintah pada
terminal Jetson Nano kemudian catat output tersebut pada text editor.
$ udevadm info -a -n /dev/ttyUSB0
$ udevadm info -a -n /dev/ttyUSB1
4. Selanjutnya adalah membuat dan mengedit file udev rules dengan mengetik
perintah:
$ sudo gedit /etc/udev/rules.d/10-local.rules
Kemudian tuliskan konfigurasi berikut pada text editor gedit serta sesuaikan
idVendor dan idProduct dengan output yang sudah disimpan tadi.
ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001",
SYMLINK+="ttyRPLIDAR"
ACTION=="add", ATTRS{idVendor}=="1001", ATTRS{idProduct}=="2002",
SYMLINK+="ttyHOVER"
Fungsi dari konfigurasi di atas adalah untuk menambahkan alias dengan
nama ttyRPLIDAR dan ttyHOVER pada rules udev, sehingga setiap port sudah
tetap pemiliknya tanpa perlu tertukar.
5. Jika sudah simpan file tersebut dan restart Jetson Nano. Setelah Jetson Nano
sudah siap, kita bisa melakukan pemeriksaan pembacaan USB lagi untuk
memeriksa apakah proses alias sudah berjalan dengan lancar dengan
mengetik
$ ls /dev/ttyUSB*

175
 Gambar 5.96 Implementasi Hasil Konfigurasi Port USB
Pada gambar 5.49 jika ttyHOVER dan ttyRPLIDAR sudah muncul, artinya
proses konfigurasi port sudah berhasil dan selesai.
Setelah menyelesaikan konfigurasi VNC dan port USB, maka konfigurasi
selanjutnya adalah melakukan perubahan-perubahan kecil pada beberapa file
driver sensor. Namun sebelum itu kita harus melakukan pembuatan workspace
pada Jetson Nano dengan cara membuat baru folder dengan nama “catkin_ws”
di directory /home atau ~. Kemudian dilanjutkan dengan membuat folder dengan
nama “src” di dalam directory /catkin_ws.

Gambar 5.97 Directory Tree workspace catkin

Selanjutnya masuk ke folder src dan buka terminal pada directory tersebut
seperti yang terlihat pada gambar 5.50, atau ketikan perintah:
$ cd ~/catkin_ws/src/
Kemudian download file driver hoverboard driver pada link GitHub berikut
https://github.com/alex-makarov/hoverboard-driver dan letakkan di dalam file
src, atau bisa dengan mengetikan perintah:
$ git clone https://github.com/alex-makarov/hoverboard-driver
176
 Ubah nama folder tersebut menjadi “hoverboard_driver” dan ubah juga file
config.h pada path “hoverboard_driver/include/config.h” seperti yang dapat
dilihat pada tabel 5.23.
Tabel 5.48 Kode Program Konfigurasi Driver Hoverboard
Kode Program
No
hoverboard_driver/include/config.h
1 #pragma once
2
3 #define DEFAULT_PORT "/dev/ttyHOVER"
4
5 #define ENCODER_MIN 0
6 #define ENCODER_MAX 9000
7 #define ENCODER_LOW_WRAP_FACTOR 0.3
8 #define ENCODER_HIGH_WRAP_FACTOR 0.7
9
10 #define TICKS_PER_ROTATION 90
Tabel di atas merupakan kode program untuk mengonfigurasi driver
hoverboard. Berikut ini penjelasan mengenai Kode Program Konfigurasi Driver
Hoverboard.
1. Baris ke-1, merupakan preprocessor #pragma yang ditujukan untuk
menyebabkan file sumber saat ini (config.h) disertakan hanya sekali
dalam satu kompilasi. Keuntungan lainnya lebih sedikit kode,
menghindari bentrokan nama, dan meningkatkan kecepatan kompilasi.
2. Baris ke-3, merupakan preprocessor define yang menginisialisasi macro
DEFAULT_PORT bernilai “/dev/ttyHOVER” sehingga port ttyHOVER
menjadi default port driver hoverboard.
3. Baris ke-5, merupakan macro ENCODER_MIN bernilai 0 yang artinya
pembacaan encoder atau odometry dimulai dari 0
4. Baris ke-6, merupakan macro ENCODER_MAX bernilai 9000 yang artinya
pembacaan encoder atau odometry berakhir atau maksimal mencapai
9000.
5. Baris ke-7, merupakan macro ENCODER_LOW_WRAP_FACTOR bernilai
0.3 yang artinya pembungkus encoder terkecil bernilai 0.3
6. Baris ke-8, merupakan macro ENCODER_HIGH_WRAP_FACTOR bernilai
0.7 yang artinya pembungkus encoder terbesar bernilai 0.7
7. Baris ke-10, merupakan macro TICKS_PER_ROTATION bernilai 90 yang
artinya encoder mempunyai 90 tick per 1 revolusi/rotasi roda.
Setelah mengubah file config, langkah selanjutnya adalah mengubah file
hoverboard.launch pada directory “hoverboard_driver/hoverboard.launch”
seperti yang dapat dilihat pada tabel 5.24. Kesimpulan dari konfigurasi ini adalah
mengubah nilai “/dev/ttyTH1” menjadi “/dev/ttyHOVER” sesuai dengan nama
alias yang sebelumnya sudah dibuat.

177
 Tabel 5.49 Kode Program Konfigurasi Launcher Hoverboard
Kode Program
No
hoverboard_driver/hoverboard.launch
1 <launch>
2 <param name="port" type="str" value="/dev/ttyHOVER"/>
3
4 <rosparam file="$(find
hoverboard_driver)/config/hardware.yaml" command="load"/>
5 <rosparam file="$(find
hoverboard_driver)/config/controllers.yaml"
command="load"/>
6 <node name="hoverboard_driver" pkg="hoverboard_driver"
type="hoverboard_driver" output="screen"/>
7 <node name="controller_spawner" pkg="controller_manager"
type="spawner" respawn="false" output="screen"
args="hoverboard_joint_publisher
hoverboard_velocity_controller" />
8
9 </launch>
Tabel di atas merupakan kode program untuk mengonfigurasi launcher
hoverboard. Berikut ini penjelasan mengenai Kode Program Konfigurasi Launcher
Hoverboard.
1. Baris ke-1, merupakan open tag tipe launch file.
2. Baris ke-2, merupakan inisialisasi nilai parameter port = /dev/ttyHOVER.
3. Baris ke-4 dan ke-5, merupakan inisialisasi parameter ros dengan
pengambil nilai parameter yang ada pada file hardware.yaml dan
controllers.yaml.
4. Baris ke-6, merupakan inisialisasi node hoverboard_driver yang diambil
dari paket hoverboard_driver pada sub folder include.
5. Baris ke-7, merupakan inisialisasi node controller_spawner pada paket
controller manager dengan nilai argumen di ambil dari controllers.yaml
berupa hoverboard_join_publisher dan hoverboard_velocity_controller.
Di dalam hoverboard_velocity_controller memanggil node
diff_drive_controller untuk mengendalikan roda.
6. Baris ke-9, merupakan penutup tak tipe launch file.
Proses selanjutnya adalah install driver RPLiDAR ROS ke dalam workspace.
Caranya adalah dengan download file driver rplidar-ros driver pada link GitHub
berikut https://github.com/robopeak/rplidar_ros dan letakkan di dalam file src,
atau bisa dengan mengetikan perintah:
$ git clone https://github.com/robopeak/rplidar_ros
Ubah nama folder tersebut menjadi “rplidar_ros” dan ubah juga file
RPLiDAR.launch pada path “rplidar_ros/launch/rplidar.launch” seperti yang
dapat dilihat pada tabel 5.25. Konfigurasi ini untuk mengubah nilai
“/dev/ttyUSB0” menjadi “/dev/ttyRPLIDAR " seperti nama alias yang sudah
dibuat sebelumnya
178
 Tabel 5.50 Kode Program Konfigurasi Launcher RPLiDAR
Kode Program
No
rplidar_ros/launch/rplidar.launch
1 <launch>
2 <node name="rplidarNode" pkg="rplidar_ros"
type="RPLiDARNode" output="screen">
3 <param name="serial_port" type="string"
value="/dev/ttyRPLIDAR"/>
4 <param name="serial_baudrate" type="int"
value="115200"/><!--A1/A2 -->
5 <param name="frame_id" type="string"
value="laser"/>
6 <param name="inverted" type="bool"
value="false"/>
7 <param name="angle_compensate" type="bool"
value="true"/>
8 </node>
9 </launch>
Tabel di atas merupakan kode program untuk mengonfigurasi launcher driver
RPLiDAR. Berikut ini penjelasan mengenai Kode Program Konfigurasi Launcher
RPLiDAR.
1. Baris ke-1, merupakan open tag tipe launch file.
2. Baris ke-2, merupakan inisialisasi node rplidarNode pada paket
rplidar_ros
3. Baris ke-3, merupakan inisialisasi nilai parameter serial port =
/dev/ttyRPLIDAR.
4. Baris ke-4, merupakan inisialisasi parameter serial_baudrate dengan nilai
baud rate sebesar 115200.
5. Baris ke-5, merupakan inisialisasi parameter nama frame pada RPLiDAR,
yaitu “laser”
6. Baris ke-6, merupakan parameter inverted yang artinya jika RPLiDAR
dalam kondisi terbalik/digunakan terbalik, maka nilai inverted harus true.
Namun karena posisi RPLiDAR normal maka dari itu value false
7. Baris ke-7, merupakan parameter angle_compensate untuk
compensation sudut karena prinsip message pemindaian ros dengan
sudut yang ditingkatkan akan tetap.
8. Baris-8 dan ke-9, merupakan tag penutup dari node dan launch
Proses selanjutnya adalah install driver sensor IMU dan melakukan kalibrasi.
Caranya adalah dengan download file driver mpu6050 driver dan i2c driver pada
link GitHub berikut:
https://github.com/Brazilian-Institute-of-Robotics/mpu6050_driver dan
https://github.com/Brazilian-Institute-of-Robotics/i2c_device_ros, letakkan di
dalam file src, atau bisa dengan mengetikan perintah:
$ git clone https://github.com/Brazilian-Institute-of-Robotics/mpu6050_driver

179
$ git clone https://github.com/Brazilian-Institute-of-Robotics/i2c_device_ros
Kemudian ubah file mpu6050_node.cpp pada path “mpu6050_driver/src/
mpu6050_node.cpp” dan ubah baris ke 39 dari "imu/data_raw" menjadi
"imu/data" seperti yang dapat dilihat pada tabel 5.26.
Tabel 5.51 Kode Program Konfigurasi Nama Topik Output IMU
Kode Program
No
mpu6050_driver/src/ mpu6050_node.cpp
38 void MPU6050Node::init() {
39 mpu_data_pub_ =
nh_.advertise<sensor_msgs::Imu>("imu/data", 1);
40
41 this->loadParameters();
42
43 mpu6050_.setAddress(static_cast<uint8_t>(mpu6050_addr_));
44 mpu6050_.initialize(i2c_bus_uri_);
45 mpu6050_.setDLPFMode(static_cast<uint8_t>(4));
46 mpu6050_.setIntDataReadyEnabled(true);
47 this->setMPUOffsets();
48
49 ROS_INFO("MPU6050 Node has started");
50 }
Tabel di atas merupakan kode program untuk mengonfigurasi Nama Topik
Output IMU. Berikut ini penjelasan mengenai Kode Program Konfigurasi Nama
Topik Output IMU.
1. Baris ke-38, merupakan inisialisasi void init() dalam kelas MPU6050Node
2. Baris ke-39, merupakan call function advertise dengan parameter
“imu/data dan nilai 1.
3. Baris ke-41, merupakan call function loadParameters
4. Baris ke-43 hingga ke-50, merupakan inisialisasi objek mpu6050_ seperti
menentukan alamat, inisialisasi alamat i2c, menentukan DLPMode,
inisialisasi fungsi setIntDataReadyEnable bernilai true dan mencetak ke
terminal “MPU6050 Node has started”
Selanjutnya kita akan berpindah pada pemasangan modul atau paket yang
digunakan pada program pemetaan, yaitu Hector SLAM. Untuk mendapatkan
library ini, penulis menggunakan library yang dikembangkan oleh Technical
University of Darmstadt, German. Library ini digabungkan ke dalam paket yang
diberi nama Hector. Paket atau modul ini dapat di download pada link GitHub
berikut: https://github.com/tu-darmstadt-ros-pkg/hector_slam untuk
menghindari perbedaan versi dari yang digunakan pada penelitian ini. Copy
folder hector_slam ke dalam folder src atau bisa juga dengan menggunakan git
clone:
$ git clone https://github.com/tu-darmstadt-ros-pkg/hector_slam
Setelah itu, lakukan perubahan pada beberapa file yang ada di folder
hector_slam terutama file mapping_default.launch pada directory
180
“hector_slam/hector_mapping/launch/mapping_default.launch, dengan kode
yang ada pada tabel 5.27.
Tabel 5.52 Kode Program Launcher Mapping Default
Kode Program
No
hector_slam/hector_mapping/launch/mapping_default.launch
1 <?xml version="1.0"?>
2
3 <launch>
4 <arg name="tf_map_scanmatch_transform_frame_name"
default="scanmatcher_frame"/>
5 <arg name="base_frame" default="base_link"/>
6 <arg name="odom_frame" default="odom_combined"/>
7 <arg name="pub_map_odom_transform" default="false"/>
8 <arg name="scan_subscriber_queue_size" default="5"/>
9 <arg name="scan_topic" default="scan"/>
10 <arg name="map_size" default="2048"/>
11 <!-- New -->
12 <arg name="pub_odometry" default="true"/>
13
14 <node pkg="hector_mapping" type="hector_mapping"
name="hector_odom" output="screen">
15
16 <!-- Frame names -->
17 <param name="map_frame" value="map" />
18 <param name="base_frame" value="$(arg base_frame)" />
19 <param name="odom_frame" value="$(arg odom_frame)" />
20
21 <!-- Tf use -->
22 <param name="use_tf_scan_transformation"
value="true"/>
23 <param name="use_tf_pose_start_estimate"
value="false"/>
24 <param name="pub_map_odom_transform" value="$(arg
pub_map_odom_transform)"/>
25 <!-- New -->
26 <param name="pub_odometry" value="$(arg
pub_odometry)"/>
27
28 <!-- Map size / start point -->
29 <param name="map_resolution" value="0.050"/>
30 <param name="map_size" value="$(arg map_size)"/>
31 <param name="map_start_x" value="0.5"/>
32 <param name="map_start_y" value="0.5" />
33 <param name="map_multi_res_levels" value="2" />
34
35 <!-- Map update parameters -->
36 <param name="update_factor_free" value="0.4"/>
37 <param name="update_factor_occupied" value="0.9" />
38 <param name="map_update_distance_thresh" value="0.4"/>
39 <param name="map_update_angle_thresh" value="0.06" />
40 <param name="laser_z_min_value" value = "-1.0" />
41 <param name="laser_z_max_value" value = "1.0" />
42
43 <!-- Advertising config -->
44 <param name="advertise_map_service" value="true"/>
45 <param name="scan_subscriber_queue_size" value="$(arg

181
 scan_subscriber_queue_size)"/>
46 <param name="scan_topic" value="$(arg scan_topic)"/>
<param name="tf_map_scanmatch_transform_frame_name"
47 value="$(arg tf_map_scanmatch_transform_frame_name)" />
</node>
48 </launch>
49
Tabel di atas merupakan kode program untuk mengonfigurasi file mapping
pada hector mapping. Berikut ini penjelasan mengenai Kode Program Launcher
Mapping Default.
1. Baris ke-1 hingga ke-3, merupakan open tag untuk format launch dengan
define xml version dan open tag <launch>
2. Baris ke-4 hingga ke-12, merupakan inisialisasi argumen yang akan
digunakan nantinya pada parameter. Argumen pada launch file persis
seperti sebuah variabel pada bahasa pemrograman, yaitu penyimpanan
sementara yang nilaunya akan digunakan pada baris berikutnya.
Keuntungan menggunakan tag arg atau argumen pada launch file ada
kode yang rapi dan memudahkan jika menginginkan perubahan value
karena tidak perlu mencari setiap parameter pada node atau rosparam.
3. Baris ke-14 hingga ke-50, merupakan inisialisasi node hector_mapping
dengan nilai parameter menggunakan variabel argumen yang sudah
ditentukan sebelumnya.
4. Baris ke-53, merupakan penutup tag launch
Setelah selesai dengan konfigurasi file launcher mapping_default.launch,
proses berlanjut pada konfigurasi file tutorial.launch pada directory
“hector_slam/hector_slam_launch/launch/tutorial.launch”. File ini akan
memanggil file mapping_default.launch yang sebelumnya sudah di konfigurasi,
dan mengaktifkan beberapa node pendukung lainnya seperti geotiff mapping
untuk menyimpan secara sementara file map dan pergerakan robot. Di dalam
geotiff juga memanggil node trajectory_server, namun saat ini kita akan berfokus
pada mengubah file tutorial.launch menjadi file tutorial.launch dengan kode
program yang terdapat pada tabel 5.28.
Tabel 5.53 Kode Program Percobaan Launcher pada Hector SLAM Launch
Kode Program
No
hector_slam/hector_slam_launch/launch/map_tutorial.launch
1 <?xml version="1.0"?>
2
3 <launch>
4
5 <arg name="geotiff_map_file_path" default="$(find
hector_geotiff)/maps"/>
6
7 <param name="/use_sim_time" value="true"/>
8
9 <node pkg="rviz" type="rviz" name="rviz" args="-d $(find
hector_slam_launch)/rviz_cfg/mapping_demo.rviz"/>
10
182
 11 <include file="$(find
hector_mapping)/launch/mapping_default.launch"/>
12
13 <include file="$(find
hector_geotiff_launch)/launch/geotiff_mapper.launch">
14 <arg name="trajectory_source_frame_name"
value="scanmatcher_frame"/>
15 <arg name="map_file_path" value="$(arg
geotiff_map_file_path)"/>
16 </include>
17
18 </launch>
Tabel di atas merupakan kode program untuk mengonfigurasi file
tutorial.launch pada hector slam launch. Berikut ini penjelasan mengenai Kode
Program Launcher Map Hector pada AMR Launch.
1. Baris ke-1 hingga ke-3, merupakan open tag untuk format launch dengan
define xml version dan open tag <launch>.
2. Baris ke-5, merupakan argumen dengan nama geotiff_map_file_path
untuk parameter letak map sementara yang dihasilkan oleh hector
mapping.
3. Baris ke-7, merupakan parameter jika menggunakan simulasi atau dunia
3D. Berikan value false jika robot berada di dunia nyata dan true jika
bermain dengan simulasi.
4. Baris ke-9, merupakan node yang digunakan untuk memanggil aplikasi
RViz. Node ini diberikan tambahan argumen berupa file
mapping_demo.rviz yang ada di folder rviz_cgf. File ini berisi parameter
untuk mengaktifkan atau mematikan fitur/topik/frame pada aplikasi RViz.
5. Baris ke-13 hingga ke-16, merupakan pemanggilan file
hector_mapper.launch, namun bedanya pemanggilan file ini ditambahkan
dengan 2 argumen tambahan, yaitu trajectory_source_frame_name
dengan nilai frame = frame hasil hector_mapping dan parameter yang
kedua map_file_path yang berisikan path folder dimana map sementara
disimpan.
6. Baris ke-17-18, merupakan penutup tag launch.
Selesai melakukan konfigurasi pada semua driver sensor berupa library atau
paket algoritme yang dibutuhkan pada penelitian ini, maka langkah selanjutnya
adalah melakukan konfigurasi pada folder utama penyusun sistem robot yang
diberi nama folder “autonomous_mobile_robot_navigation”. Folder ini tidak
didapatkan dari sumber mana pun, jadi pada kali ini penulis akan benar-benar
membuat kode dari awal hingga akhir. Folder
autonomous_mobile_robot_navigation atau yang nanti pada penulisan akan
disingkat dengan AMR Navigation.
Proyek pada folder autonomous mobile robot navigation dibuat dengan
menggunakan perintah create catkin package pada terminal pada folder src.

183
$ catkin_create_pkg autonomous_mobile_robot_navigation std_msgs rospy
roscpp
Maka akan dibuatkan sebuah folder dengan nama tersebut dengan file dan
folder template di dalam, seperti include, package.xml, dan CMakeLists.txt.
Langkah selanjutnya adalah mengubah isi dari file package.xml, tujuannya adalah
untuk mengunduh semua paket yang dibutuhkan pada penelitian ini yang dapat
dilihat pada tabel 5.29.
Tabel 5.54 Kode Program Paket ROS pada package.xml
Kode Program
No
autonomous_mobile_robot_navigation/package.xml
1 <?xml version="1.0"?>
2 <package format="2">
3 <name>autonomous_mobile_robot_navigation</name>
4 <version>0.0.2</version>
5 <description>The AMR Navigation package</description>
6 <maintainer email="bambanggunawan887@gmail.com">Bambang
Gunawan</maintainer>
7
8 <license>BSD</license>
9 <buildtool_depend>catkin</buildtool_depend>
10
11 <depend>amcl</depend>
12 <depend>actionlib</depend>
13 <depend>actionlib_msgs</depend>
14 <depend>geometry_msgs</depend>
15 <depend>control_msgs</depend>
16 <depend>message_generation</depend>
17 <depend>controller_manager</depend>
18 <depend>gmapping</depend>
19 <depend>move_base</depend>
20 <depend>roscpp</depend>
21 <depend>rospy</depend>
22 <depend>std_msgs</depend>
23 <depend>std_srvs</depend>
24 <depend>tf</depend>
25 <depend>tf2</depend>
26 <depend>control_toolbox</depend>
27 <depend>map_server</depend>
28 <depend>rosparam_shortcuts</depend>
29 <depend>hardware_interface</depend>
30 <depend>laser_filters</depend>
31 <depend>imu_filter_madgwick</depend>
32 <depend>rviz_imu_plugin</depend>
33 <depend>robot_localization</depend>
34 <depend>teb_local_planner</depend>
35 <depend>dwa_local_planner</depend>
36 <depend>global_planner</depend>
37 <depend>twist_mux</depend>
38 <depend>nmea_navsat_driver</depend>
39 <depend>moveit_ros_planning_interface</depend>
40 </package>
Tabel di atas merupakan kode program untuk inisialisasi semua paket yang
dibutuhkan. Berikut ini penjelasan mengenai Kode Program.
184
 1. Baris ke-1 hingga ke-9, merupakan open tag xml dan beberapa deskripsi
pada file serta deklarasi build tool menggunakan catkin.
2. Baris ke-11 hingga ke-39, merupakan nama-nama paket yang dibutuhkan
pada penelitian ini, dengan menjadikan satu semua paket maka tidak
perlu memasang paket satu persatu.
E.2.3.3 Implementasi Persiapan Awal Jetson Nano (Proses B)
Setelah melakukan konfigurasi-konfigurasi paket, maka langkah selanjutnya
adalah menginisialisasi dan mengunduh semua paket yang dibutuhkan dengan
perintah,
$ rosdep install --from-paths src --ignore-src -r -y
Selanjutnya adalah melakukan build pada file src agar ROS dapat dijalankan
dengan perintah,
$ catkin_make
Setelah menjalankan perintah tersebut, maka terminal akan meminta cmake
untuk melakukan build program pada semua kode sumber yang ada
catkin_ws/src. Semua file ini akan disimpan di folder catkin_ws/build dan
catkin_ws/devel, hasil akhir dari proses compile terlihat pada gambar 5.51.

Gambar 5.98 Implementasi Hasil Compile Persiapan Jetson Nano

Untuk dapat memanggil perintah ROS, kita harus mendeklarasikan path devel
terlebih dahulu pada file ~/.bashrc yang ada di home dengan perintah,
$ sudo gedit ~/.bashrc
Setelah itu masukkan path lokasi dari path pada text di bawah,
source /opt/ros/noetic/setup.bash
source ~/catkin_ws/devel/setup.bash

E.2.3.4 Implementasi Kalibrasi sensor IMU

Program implementasi selanjutnya adalah proses kalibrasi sensor IMU.
Proses kalibrasi merupakan proses pengecekan dan pengaturan akurasi dari alat
ukur dengan cara membandingkannya dengan standar/tolak ukur. Kalibrasi
185
sensor dilakukan tersedia di dalam driver mpu6050_driver sehingga kita hanya
perlu menjalankan file launch tersebut. Namun sebelum menjalankan file
launcher, kita perlu melakukan build ulang pada paket mpu6050_driver dan i2c
untuk memastikan bahwa semua kode sudah terbangun dengan sempurna,
$ catkin_make
Kemudian setelah semua dependensi di build, kita bisa menjalankan terlebih
dahulu file launcher IMU biasa untuk melihat perbedaan sebelum dan sesudah di
kalibrasi. Untuk menjalankan driver IMU caranya adalah dengan mengetikan
perintah pada terminal:
$ roslaunch mpu6050_driver mpu6050_driver.launch
Setelah dikirimkan perintah, terminal akan menjalankan node mpu_node dan
untuk melihat output yang dihasilkan sensor IMU adalah dengan menjalankan
topic echo pada terminal lainnya dan hasilnya dapat dilihat pada gambar 5.52.
$ rostopic echo /imu/data
Jika sudah selesai, untuk memulai kalibrasi dapat dengan mengetikan
perintah pada terminal:
$ roslaunch mpu6050_driver mpu6050_calibration.launch
Maka terminal akan menjalankan node mpu_calibration_node dan untuk
menampilkan hasil dari implementasi kalibrasi sensor IMU dapat dilihat
menggunakan perintah:
$ rostopic echo /imu_offsets
Maka akan tampil parameter berupa ax, ay,az dan sebagainya yang
merupakan parameter dari hasil kalibrasi, catat nilai tersebut pada text editor,
dalam hal ini peneliti mendapatkan nilai offsets berkisar di [-1340, -9, 1463, 123,
-42, 42].

Gambar 5.99 Implementasi Pembacaan IMU Setelah Kalibrasi

Setelah menyimpan hasil kalibrasi, langkah selanjutnya adalah menaruh hasil
kalibrasi tersebut pada file mpu_settings.yaml pada directory
“mpu6050_driver/config/mpu_settings.yaml” dan ubah kode baris 15 pada
variabel axes_offsets sesuai dengan nilai kalibrasi yang sudah disimpan tadi,
seperti yang terlihat pada tabel 5.30.
Tabel 5.55 Kode Program Konfigurasi Parameter MPU6050
Kode Program
No
mpu6050_driver/config/mpu_settings.yaml
186
 1 # I2C Bus URI used to comunicate with I2C devices
(default: "/dev/i2c-1")
2 bus_uri: "/dev/i2c-1"
3
4 # I2C address of MPU6050 (default: 0x68)
5 mpu_address: 0x68
6
7 # Frequency in Hertz wich IMU data is published (default:
30)
8 pub_rate: 25
9
10 # Frame if of IMU message (default: "imu")
11 frame_id: "imu"
12
13 # Offsets to fix wrong values caused by misalignment
14 # Sequence is (ax, ay, az, gx, gy, gz) (default: [0, 0, 0,
0, 0, 0])
15 axes_offsets: [-1340, -9, 1463, 123, -42, 42]
16
17 # PID constants used in calibration procedure
18 ki: 0.2 # (default: 0.1)
19 kp: 0.1 # (default: 0.1)
20
21 # The calibration process is finished when the error is
aproximate zero with
22 # the precision set by delta (default: 0.5)
23 delta: 0.5
Tabel di atas merupakan kode program untuk mengonfigurasi pengaturan
utama IMU. Berikut ini penjelasan mengenai Kode Program Konfigurasi
Parameter MPU6050.
1. Baris ke-2, merupakan inisialisasi variabel bus_uri= “/dev/i2c-1”
2. Baris ke-5, merupakan inisialisasi alamat sensor GY 521 pada jalur i2c.
Alamat menggunakan nilai default, yakni 0x68
3. Baris ke-8, merupakan inisialisasi kecepatan publish dengan satuan hertz,
nilai yang diberikan = 25 hertz
4. Baris ke-11, merupakan inisialisasi nama frame dari pesan IMU,
menggunakan nilai default yaitu “imu”
5. Baris ke-15, merupakan nilai offsets untuk membenarkan kesalahan nilai
karena posisi yang tidak sejajar. Nilai offsets ini yang keluar saat
melakukan kalibrasi, ubah nilai offsets berdasarkan data kalibrasi yang
diberikan. Dalam hal ini, nilai kalibrasi sensor pada penelitian ini adalah [-
1340, -9, 1463, 123, -42, 42].
6. Baris ke-18 dan ke-19, merupakan nilai PID tetap saat proses kalibrasi
7. Baris ke-23, merupakan nilai delta 0.5 yang berarti proses kalibrasi baru
akan berhenti ketika kesalahan mendekati 0 dengan presisi diatur oleh
delta.
Setelah melakukan kalibrasi, nilai dari output sensor di bandingan antara
sebelum dan sesudah melakukan kalibrasi, hasilnya dapat dilihat pada tabel 5.31.

187
 Tabel 5.56 Perbandingan Output Sensor IMU Sebelum Dan Sesudah
Sebelum Kalibrasi Sesudah Kalibrasi
No
ax ay az ax ay az

1 -3.881 0.358 8.412 0.152 0.152 9.821

2 -3.392 0.324 8.444 0.037 0.151 9.820

3 -3.378 0.341 8.432 0.028 0.029 9.831

4 -3.891 0.363 8.401 0.025 0.014 9.804

5 -3.401 0.335 8.395 0.038 0.152 9.959

6 -3.389 0.344 8.439 0.038 0.017 9.808

7 -3.378 0.352 8.401 0.028 0.018 9.794

8 -3.368 0.336 8.421 0.030 0.012 9.808

9 -3.372 0.355 8.399 0.041 0.022 9.833

10 -3.491 0.334 8.412 0.038 0.018 9.822

Dapat dilihat bahwa proses kalibrasi sangat berpengaruh pada output hasil
pembacaan sensor IMU, perbedaan sekitar 5-10% dapat berdampak pada ke
presisi posisi yang terbaca. Kondisi ini menandakan bahwa sensor IMU dalam
keadaan stabil sehingga menghasilkan output akselerasi yang akurat.
E.2.3.5 Implementasi Program Pemetaan
Implementasi program pemetaan merupakan salah satu dari proses program
utama. Implementasi dari program ini akan memanfaatkan paket Hector SLAM
untuk pemetaan dan paket EKF untuk lokalisasinya. Program pemetaan terdiri
dari file launcher yang memanggil file launcher lainnya. Implementasi proses
launcher mapping akan memanggil beberapa file lain dan node dari driver. File
yang dimaksud adalah file launcher dari driver yang sebelumnya sudah di
konfigurasi. Memanggil file launcher lain di dalam file adalah kelebihan yang ada
pada ekstensi launcher, dengan begitu kita dapat menghemat baris dan
membuat kode lebih terstruktur dengan rapi. Semua kode yang berhubungan
dengan pemetaan dapat dilihat pada tabel 5.32.
Tabel 5.57 Kode Program Pemetaan
N Kode Program
o autonomous_mobile_robot_navigation/launch/map_hector.launch
1 <?xml version="1.0"?>
2 <launch>
3 <!-- Desclare launch rviz first -->
4 <arg name="use_rviz" default="true"/>

188
5 <param name="/use_sim_time" value="false"/>
6
7 <!-- Static transformation for TF -->
8 <node pkg="tf" type="static_transform_publisher"
name="base_laser_broadcaster" args="0 0.06 0.02 0 0 0
base_link laser 100" />
<node pkg="tf" type="static_transform_publisher"
9 name="imu_broadcaster" args="0 0.06 0.02 0 0 0 base_link imu
100" />
<node pkg="tf" type="static_transform_publisher"
10 name="dummy_broadcaster" args="0 0 0 0 0 0 base_link dummy
100" />
<node pkg="tf" type="static_transform_publisher"
11 name="caster_broadcaster" args="0 0 0 0 0 0 base_link
caster_wheel 100" />
<node pkg="tf" type="static_transform_publisher"
12 name="base_link_broadcaster" args="0 0 0.09 0 0 0
base_footprint base_link 100" />

13 <!-- odom to base_footprint transform will be provided by

14 the robot_pose_ekf node -->
<node pkg="tf" type="static_transform_publisher"
15 name="hectorscan_to_odom" args="0 0 0 0 0 0
scanmatcher_frame odom_combined 100" />
<node pkg="tf" type="static_transform_publisher"
16 name="map_to_hector" args="0 0 0 0 0 0 map scanmatcher_frame
100" />

17 <!-- Hoverboard usb port -->

18 <param name="port" type="str" value="/dev/ttyHOVER"/>
19
20 <!-- Run RPLIDAR and IMU driver launch -->
21 <include file="$(find
22 rplidar_ros)/launch/rplidar.launch" />
<include file="$(find
23 mpu6050_driver)/launch/mpu6050_driver.launch" />
<!-- Hoverboard Driver Setup Parameter -->
24 <include file="$(find
25 hoverboard_driver)/launch/hoverboard.launch" />

26 <!-- Robot model -->

27 <arg name="model" default="$(find
28 autonomous_mobile_robot_navigation)/urdf/mobile_robot_v2.xac
ro"/>
<!-- <arg name="model" default="$(find
29 autonomous_mobile_robot_navigation)/urdf/mobile_robot_v2.xac
ro"/> -->
<param name="robot_description" command="$(find
30 xacro)/xacro $(arg model)" />
<rosparam file="$(find
31 autonomous_mobile_robot_navigation)/config/joint_limits.yaml
" command="load"/>
<node name="robot_state_publisher"
32 pkg="robot_state_publisher" type="robot_state_publisher"/>

33 <!-- Rviz config param declare -->

34 <node name="rviz" pkg="rviz" type="rviz" args="-d $(find
35 autonomous_mobile_robot_navigation)/rviz/mapping_config.rviz
"/>
189
 36 <!-- Extended Kalman Filter from robot_pose_ekf Node-->
37 <!-- Subscribe: /odom, /imu_data, /vo -->
38 <!-- Publish: /robot_pose_ekf/odom_combined -->
39 <remap from="odom"
40 to="/hoverboard_velocity_controller/odom" />
<remap from="imu" to="/imu/data" />
41 <node pkg="robot_pose_ekf" type="robot_pose_ekf"
42 name="robot_pose_ekf">
<param name="output_frame" value="odom_combined"/>
43 <param name="base_footprint_frame"
44 value="base_footprint"/>
<param name="freq" value="100.0"/>
45 <param name="sensor_timeout" value="1.0"/>
46 <param name="odom_used" value="true"/>
47 <param name="imu_used" value="true"/>
48 <param name="vo_used" value="false"/>
49 <param name="gps_used" value="false"/>
50 <param name="debug" value="false"/>
51 <param name="self_diagnose" value="false"/>
52 </node>
53
54 <!-- Hector SLAM -->
55 <arg name="geotiff_map_file_path" default="$(find
56 hector_geotiff)/maps"/>
<include file="$(find
57 hector_mapping)/launch/mapping_default.launch"/>

58 <include file="$(find
59 hector_geotiff_launch)/launch/geotiff_mapper.launch">
<arg name="trajectory_source_frame_name"
60 value="scanmatcher_frame"/>
<arg name="map_file_path" value="$(arg
61 geotiff_map_file_path)"/>
</include>
62 <!-- Rqt Robot Steering -->
63 <node name="rqt_robot_steering" pkg="rqt_robot_steering"
64 type="rqt_robot_steering">
<remap from="/cmd_vel"
65 to="/hoverboard_velocity_controller/cmd_vel"/>
</node>
66
67 </launch>
68
Tabel di atas merupakan kode program untuk melakukan pemetaan. Berikut
ini penjelasan mengenai kode program tersebut,
1. Baris ke-1 hingga ke-2, merupakan deklarasi penggunaan versi 1.0 xml
dan deklarasi tag pembuka launch file
2. Baris ke-4, merupakan argumen untuk deklarasi penggunaan RViz = true
3. Baris ke-7 hingga ke 12, merupakan inisialisasi node static transformation
untuk mendeklarasikan secara manual TF dari setiap node yang ada.
a. Baris ke-7, posisi TF sensor laser RPLIDAR terhubung (child)
terhadap base_link (parent), agar posisi laser mengikuti
pergerakan badan robot,
190
 b. Baris ke-8, posisi TF sensor IMU terhubung (child) terhadap
base_link (parent), agar posisi IMU mengikuti pergerakan badan
robot,
c. Baris ke-9, posisi TF base_link terhubung (child) terhadap
base_footprint (parent) yang merupakan bagian paling dasar
dekat tanah pada robot, agar base_link mengetahui posisi
permukaan,
d. Baris ke-12, posisi TF odom_combined terhubung (child) terhadap
scanmatcher_frame (parent).
4. Baris ke-15, merupakan redefinisi parameter penamaan port USB
hoverboard.
5. Baris ke-18 hingga ke-19, merupakan pemanggilan file launcher dari
driver rplidar_ros dan mpu6050_driver yang masing-masing dapat dilihat
pada tabel 2.25 dan 5.30.
6. Baris ke-22 hingga ke-23, merupakan deklarasi parameter dan argumen
untuk menggunakan model robot yang ada pada file urdf. Kode
keseluruhan paket urdf ini dapat dilihat pada lampiran.
7. Baris ke-26 hingga ke-27, merupakan pendeklarasian dan inisialisasi paket
robot state publisher yang merupakan paket untuk memungkinkan robot
mengirimkan TF untuk setiap komponen di dalamnya.
8. Baris ke-30 hingga ke-31, merupakan deklarasi parameter untuk paket
driver hoverboard berdasarkan file konfigurasi dari hardware.yaml dan
controllers.hoverboard.yaml. Kedua file ini dapat ditemukan pada paket
driver hoverboard yang kemudian di salin ke folder AMR navigation.
Implementasi dari konfigurasi ini dapat dilihat pada tabel 5.
9. Baris ke-32 hingga ke-35, merupakan pemanggilan paket hoverboard
driver menggunakan parameter yang sudah di deklarasikan sebelumnya
pada baris 30 dan 31. Fungsi dari paket ini adalah menjadikan driver
hoverboard sebagai kontrol utama untuk penggerak karena control
spawner menyediakan hard loop real-time (seperti fungsi loop pada
Arduino) untuk mengontrol mekanisme robot. Kontrol yang disediakan
antara lain adalah memuat, menghapus muat, memulai, dan
menghentikan pengontrol. Paket ini menghasilkan topik
“/hoverboard_velocity_controller/".
10. Baris ke-39 hingga ke-41, merupakan pemanggilan node rqt robot
steering untuk menggerakkan robot secara manual dengan
memanfaatkan salah satu fitur rqt. Topik yang di subscribe oleh paket ini
adalah “/cmd_vel” yang merupakan topik utama untuk menggerakkan
robot dan diganti dengan “/hoverboard_velocity_controller/cmd_vel".
11. Baris ke-46, merupakan deklarasi dan inisialisasi paket RViz dengan
parameter RViz berupa nav_config.rviz yang ada pada folder RViz. Dengan

191
 mendeklarasikan parameter kita dapat menentukan topik-topik apa yang
mau di munculkan dan topik apa yang tidak.
12. Baris ke-51 hingga ke-64, merupakan deklarasi dan inisialisasi paket
Extended Kalman Filter untuk lokalisasi. Dengan melakukan remap pada
TF odom yang diambil dari "/hoverboard_velocity_controller/odom" dan
remap pada TF imu yang di ambil dari "/imu/data" untuk menginisialisasi
ulang topik dengan TF nya. Kemudian mendeklarasikan parameter-
paramater yang digunakan pada penelitian ini, seperti output_frame =
odom, odom_used = true dan sebagainya seperti yang sudah ada pada
perancangan sebelumnya.
13. Baris ke-69, merupakan penutup dari tag launch.
a. Implementasi Parameter Hoverboard Driver
Implementasi konfigurasi hoverboard driver berisikan file konfigurasi untuk
tiap-tiap parameter yang dipakai pada perencanaan sebelumnya, jika tidak
terdefinisi maka nilai yang dipakai adalah nilai default. Semua kode yang
berhubungan dengan parameter hoverboard driver dapat dilihat pada tabel 5.33,
5.34 dan 5.35.
Tabel 5.58 Kode Program Parameter Hoverboard Driver
(controllers_hoverboard.yaml)
Kode Program
N
autonomous_mobile_robot_navigation/config/
o
controllers_hoverboard.yaml
1 hoverboard_joint_publisher:
2 type: "joint_state_controller/JointStateController"
3 publish_rate: 50
4 left_wheel : "left_wheel"
5 right_wheel : "right_wheel"
6
7 hoverboard_velocity_controller:
8 type : "diff_drive_controller/DiffDriveController"
9 left_wheel : "left_wheel"
10 right_wheel : "right_wheel"
11 pose_covariance_diagonal : [0.001, 0.001, 1000000.0,
1000000.0, 1000000.0, 1000.0]
12 twist_covariance_diagonal: [0.001, 0.001, 1000000.0,
1000000.0, 1000000.0, 1000.0]
13 publish_rate: 50.0 # default: 50
14 # Wheel separation and radius multipliers
15 wheel_separation_multiplier: 1.0 # default: 1.0
16 wheel_radius_multiplier : 1.0 # default: 1.0
17
18 # Velocity commands timeout [s], default 0.5
19 cmd_vel_timeout: 0.5
20
21 # Base frame_id
22 base_frame_id: base_footprint #default: base_link
23
24 # Velocity and acceleration limits
25 # Whenever a min_* is unspecified, default to -max_*
192
 26 linear:
27 x:
28 has_velocity_limits : true # default false
29 max_velocity : 1.0 # m/s
30 min_velocity : -0.5 # m/s
31 has_acceleration_limits: true # default false
32 max_acceleration : 0.8 # m/s^2
33 has_jerk_limits : false # default false
34 max_jerk : 0.0 # m/s^3
35 angular:
36 z:
37 has_velocity_limits : true # default false
38 max_velocity : 3.14 # rad/s
39 min_velocity : -3.14 # rad/s
40 has_acceleration_limits: true # default false
41 max_acceleration : 3.14 # rad/s^2
42 has_jerk_limits : true # default false
43 max_jerk : 3.14 # rad/s^3
44
45 enable_odom_tf: false # default true
46 wheel_separation : 0.34
47 wheel_radius : 0.0825
48 odom_frame_id: "/odom" # default: "/odom"
49 publish_cmd: false # default false
50 allow_multiple_cmd_vel_publishers: true
51 velocity_rolling_window_size: 10 # default 10
Tabel di atas merupakan kode program untuk melakukan pemetaan. Berikut
ini penjelasan mengenai kode program tersebut,
1. Baris ke-1 hingga ke-5, merupakan parameter objek dengan nama
hoverboard_joint_publisher.
"joint_state_controller/JointStateController" digunakan sebagai tipe
kontrolnya agar sistem mengenali bahwa hoverboard menggunakan join
pada setiap TF nya, sehingga TF dari setiap komponen robot dapat
bergerak karena saling terhubung. Publish rate dari paket ini adalah 50 hz
dan deklarasi left_wheel dan right_wheel dengan nilai masing-masingnya
karena kendali robot adalah differential drive, sehingga setiap roda
independen antara satu dengan yang lain.
2. Baris ke-7 hingga ke-22, merupakan parameter deklarasi untuk paket
move_base sehingga pose robot dan ukuran roda dapat diketahui.
3. Baris ke-26 hingga ke-43, merupakan parameter untuk deklarasikan
velocity dan acceleration pada gelar linier dan angular.
4. Baris ke-45 hingga ke-51, merupakan parameter deklarasi untuk
transformasi odom.
Tabel 5.59 Kode Program Parameter Hoverboard Driver (hardware.yaml)
Kode Program
No
autonomous_mobile_robot_navigation/config/hardware.yaml
1 amr_oclone:
2 direction: 1
3 hardware_interface:

193
 4 loop_hz: 50 # hz
5 joints:
6 - left_wheel
7 - right_wheel
Tabel di atas merupakan kode program untuk melakukan pemetaan. Berikut
ini penjelasan mengenai kode program tersebut,
1. Baris ke-1 hingga ke-7, merupakan parameter objek dengan nama
amr_oclone. Arah atau direction yang di deklarasikan adalah 1 dan
hardware interfacenya kurang lebih sama yaitu left wheel dan right wheel
yang di joint.
Tabel 5.60 Kode Program Parameter Hoverboard Driver (joint_limits.yaml)
Kode Program
No
autonomous_mobile_robot_navigation/config/joint_limits.yaml
1 joint_limits:
2 right_wheel_joint:
3 has_position_limits: false
4 min_position: 0
5 max_position: 0
6 has_velocity_limits: true
7 max_velocity: 2.62
8 min_velocity: -2.62
9 has_acceleration_limits: false
10 max_acceleration: 0.0
11 has_jerk_limits: false
12 max_jerk: 0
13 has_effort_limits: false
14 max_effort: 0
15 min_effort: 0
16
17 left_wheel_joint:
18 has_position_limits: false
19 min_position: 0
20 max_position: 0
21 has_velocity_limits: true
22 max_velocity: 2.62
23 min_velocity: -2.62
24 has_acceleration_limits: false
25 max_acceleration: 0.0
26 has_jerk_limits: false
27 max_jerk: 0
28 has_effort_limits: false
29 max_effort: 0
30 min_effort: 0
Tabel di atas merupakan kode program untuk melakukan pemetaan. Berikut
ini penjelasan mengenai kode program tersebut,
1. Baris ke-1 hingga ke-15, merupakan parameter objek dengan nama
right_wheel_joint. Fungsinya adalah melakukan limitasi pada proses join
dari roda sebelah kanan dengan badan robot sehingga posisi robot dan TF
roda akan berjalan dengan sempurna.
2. Baris ke-17 hingga ke-30, merupakan parameter objek dengan nama
left_wheel_joint. Fungsinya adalah melakukan limitasi pada proses join
194
 dari roda sebelah kiri dengan badan robot sehingga posisi robot dan TF
roda akan berjalan dengan sempurna.
E.2.3.6 Implementasi Program Navigasi
Implementasi program navigasi merupakan salah satu dari proses program
utama. Implementasi dari program ini akan utamanya memanfaatkan paket
Move Base, EKF, AMCL, dan Map Server. Program pemetaan terdiri dari file
launcher yang memanggil file launcher lainnya. Implementasi proses launcher
navigasi akan memanggil beberapa file lain dan node dari driver dan paket
navigasi lainnya. Semua kode yang berhubungan dengan pemetaan dapat dilihat
pada tabel 5.36.
Tabel 5.61 Kode Program Navigasi
Kode Program
No
autonomous_mobile_robot_navigation/launch/autonomous_nav.launch
1 <?xml version="1.0"?>
2 <launch>
3 <!-- Desclare launch rviz first -->
4 <arg name="use_rviz" default="true"/>
5
6 <!-- Static transformation for TF -->
7 <node pkg="tf" type="static_transform_publisher"
name="base_laser_broadcaster" args="0 0.06 0.02 0 0 0
base_link laser 100" />
8 <node pkg="tf" type="static_transform_publisher"
name="imu_broadcaster" args="0 0.06 0.02 0 0 0 base_link
imu 100" />
9 <node pkg="tf" type="static_transform_publisher"
name="base_link_broadcaster" args="0 0 0.09 0 0 0
base_footprint base_link 100" />
10 <node pkg="tf" type="static_transform_publisher"
name="dummy_broadcaster" args="0 0 0 0 0 0 base_link dummy
100" />
11
12 <!-- map to odom will be provided by the AMCL -->
13 <node pkg="tf" type="static_transform_publisher"
name="map_to_odom" args="0 0 0 0 0 0 map odom_combined 100"
/>
14
15 <!-- Hoverboard usb port -->
16 <param name="port" type="str" value="/dev/ttyHOVER"/>
17
18 <!-- Run RPLIDAR and IMU driver launch -->
19 <include file="$(find rplidar_ros)/launch/rplidar.launch"
/>
20 <include file="$(find
mpu6050_driver)/launch/mpu6050_driver.launch" />
21
22 <!-- Desclare map file -->
23 <arg name="map_file" default="$(find
mobile_robot_autonomous_navigation)/maps/basemen_g_per4_nic
eeeee.yaml"/>
24
25 <!-- Robot model urdf -->

195
26 <arg name="model" default="$(find
autonomous_mobile_robot_navigation)/urdf/mobile_robot_v2.xa
cro"/>
27 <param name="robot_description" command="$(find
xacro)/xacro $(arg model)" />
28
29 <!-- Robot join state -->
30 <rosparam file="$(find
autonomous_mobile_robot_navigation)/config/joint_limits.yam
l" command="load"/>
31 <node name="robot_state_publisher"
pkg="robot_state_publisher" type="robot_state_publisher"/>
32
33 <!-- Hoverboard Driver Setup Parameter -->
34 <rosparam file="$(find
autonomous_mobile_robot_navigation)/config/hardware.yaml"
command="load"/>
35 <rosparam file="$(find
autonomous_mobile_robot_navigation)/config/controllers_hove
rboard.yaml" command="load"/>
36 <node name="hoverboard_driver" pkg="hoverboard_driver"
type="hoverboard_driver" output="screen">
37 <remap from="/hoverboard_velocity_controller/cmd_vel"
to="/cmd_vel"/>
38 </node>
39 <node name="controller_spawner" pkg="controller_manager"
type="spawner" respawn="false" output="screen"
args="hoverboard_joint_publisher
hoverboard_velocity_controller">
40 </node>
41
42 <!-- Rviz config param declare -->
43 <!-- Subscribe: -->
44 <!-- Publish: -->
45 <node name="rviz" pkg="rviz" type="rviz" args="-d $(find
46 autonomous_mobile_robot_navigation)/rviz/nav_config.rviz"/>

47 <!-- Desclare map file -->

48 <arg name="map_file" default="$(find
49 autonomous_mobile_robot_navigation)/maps/tesaja.yaml"/>

50 <!-- Map server -->

51 <!-- Subscribe: /map -->
<!-- Publish: /map, /map_metadata -->
52 <node name="map_server" pkg="map_server"
53 type="map_server" args="$(arg map_file)" respawn="true" />

54 <!-- Extended Kalman Filter from robot_pose_ekf Node-->

55 <!-- Subscribe: /odom, /imu_data, /vo -->
56 <!-- Publish: /robot_pose_ekf/odom_combined -->
57 <remap from="odom"
58 to="/hoverboard_velocity_controller/odom" />
<remap from="imu" to="/imu/data" />
59 <node pkg="robot_pose_ekf" type="robot_pose_ekf"
60 name="robot_pose_ekf">
<param name="output_frame" value="odom"/>
61 <param name="base_footprint_frame"
62 value="base_footprint"/>
<param name="freq" value="100.0"/>
196
 63 <param name="sensor_timeout" value="1.0"/>
64 <param name="odom_used" value="true"/>
65 <param name="imu_used" value="true"/>
66 <param name="vo_used" value="false"/>
67 <param name="gps_used" value="false"/>
68 <param name="debug" value="false"/>
69 <param name="self_diagnose" value="false"/>
70 </node>
71
72 <!-- Add AMCL example for differential drive robots for
73 Localization -->
<!-- Subscribe: /scan, /tf, /initialpose, /map -->
74 <!-- Publish: /amcl_pose, /particlecloud, /tf -->
75 <node pkg="amcl" type="amcl" name="amcl" output="screen">
76 <remap from="scan" to="scan"/>
77 <param name="odom_frame_id" value="odom"/>
78 <param name="odom_model_type" value="diff-corrected"/>
79 <param name="base_frame_id" value="base_link"/>
80 <param name="update_min_d" value="0.1"/>
81 <param name="update_min_a" value="0.2"/>
82 <param name="min_particles" value="500"/>
83 <param name="global_frame_id" value="map"/>
84 <param name="tf_broadcast" value="true" />
85 <param name="initial_pose_x" value="0.0"/>
86 <param name="initial_pose_y" value="0.0"/>
87 <param name="initial_pose_a" value="0.0"/>
88 </node>
89
90 <!-- Start service server that responds with a plan for
91 global path planning -->
<node pkg="unit2_pp" name="main" type="main.py"
92 output="screen"/>

93 <!-- Import move base -->

94 <include file="$(find
95 autonomous_mobile_robot_navigation)/launch/move_base_dijkst
96 ra.launch" />

</launch>
97
Tabel di atas merupakan kode program untuk melakukan pemetaan. Berikut
ini penjelasan mengenai kode program tersebut,
1. Baris ke-1 hingga ke-2, merupakan deklarasi penggunaan versi 1.0 xml
dan deklarasi tag pembuka launch file
2. Baris ke-4, merupakan argumen untuk deklarasi penggunaan RViz = true
3. Baris ke-7 hingga ke 12, merupakan inisialisasi node static transformation
untuk mendeklarasikan secara manual TF dari setiap node yang ada.
a. Baris ke-7, posisi TF sensor laser RPLIDAR terhubung (child)
terhadap base_link (parent), agar posisi laser mengikuti
pergerakan badan robot,
b. Baris ke-8, posisi TF sensor IMU terhubung (child) terhadap
base_link (parent), agar posisi IMU mengikuti pergerakan badan

197
 robot,
c. Baris ke-9, posisi TF base_link terhubung (child) terhadap
base_footprint (parent) yang merupakan bagian paling dasar
dekat tanah pada robot, agar base_link mengetahui posisi
permukaan,
d. Baris ke-12, posisi TF odom_combined terhubung (child) terhadap
scanmatcher_frame (parent).
4. Baris ke-15, merupakan redefinisi parameter penamaan port USB
hoverboard.
5. Baris ke-18 hingga ke-19, merupakan pemanggilan file launcher dari
driver rplidar_ros dan mpu6050_driver yang masing-masing dapat dilihat
pada tabel 2.25 dan 5.30.
6. Baris ke-22 hingga ke-23, merupakan deklarasi parameter dan argumen
untuk menggunakan model robot yang ada pada file urdf. Kode
keseluruhan paket urdf ini dapat dilihat pada lampiran.
7. Baris ke-26 hingga ke-27, merupakan pendeklarasian dan inisialisasi paket
robot state publisher yang merupakan paket untuk memungkinkan robot
mengirimkan TF untuk setiap komponen di dalamnya.
8. Baris ke-30 hingga ke-31, merupakan deklarasi parameter untuk paket
driver hoverboard berdasarkan file konfigurasi dari hardware.yaml dan
controllers.hoverboard.yaml. Kedua file ini dapat ditemukan pada paket
driver hoverboard yang kemudian di salin ke folder AMR navigation.
Implementasi dari konfigurasi ini dapat dilihat pada tabel 5.
9. Baris ke-32 hingga ke-35, merupakan pemanggilan paket hoverboard
driver menggunakan parameter yang sudah di deklarasikan sebelumnya
pada baris 30 dan 31. Fungsi dari paket ini adalah menjadikan driver
hoverboard sebagai kontrol utama untuk penggerak karena control
spawner menyediakan hard loop real-time (seperti fungsi loop pada
Arduino) untuk mengontrol mekanisme robot. Kontrol yang disediakan
antara lain adalah memuat, menghapus muat, memulai, dan
menghentikan pengontrol. Paket ini menghasilkan topik
“/hoverboard_velocity_controller/".
10. Baris ke-39 hingga ke-41, merupakan pemanggilan node rqt robot
steering untuk menggerakkan robot secara manual dengan
memanfaatkan salah satu fitur rqt. Topik yang di subscribe oleh paket ini
adalah “/cmd_vel” yang merupakan topik utama untuk menggerakkan
robot dan diganti dengan “/hoverboard_velocity_controller/cmd_vel".
11. Baris ke-46, merupakan deklarasi dan inisialisasi paket RViz dengan
parameter RViz berupa nav_config.rviz yang ada pada folder RViz. Dengan
mendeklarasikan parameter kita dapat menentukan topik-topik apa yang
mau di munculkan dan topik apa yang tidak.

198
 12. Baris ke-51 hingga ke-64, merupakan deklarasi dan inisialisasi paket
Extended Kalman Filter untuk lokalisasi. Dengan melakukan remap pada
TF odom yang diambil dari "/hoverboard_velocity_controller/odom" dan
remap pada TF imu yang di ambil dari "/imu/data" untuk menginisialisasi
ulang topik dengan TF nya. Kemudian mendeklarasikan parameter-
paramater yang digunakan pada penelitian ini, seperti output_frame =
odom, odom_used = true dan sebagainya seperti yang sudah ada pada
perancangan sebelumnya.
13. Baris ke-67, merupakan pemanggilan file launcher move_base.launch.
Paket ini digunakan sebagai kendali kontrol utama dari robot agar bisa
mencapai target tertentu, tujuannya agar proses mapping selain
menggunakan rqt tetapi juga dapat dikendalikan langsung dengan
memberikan target tujuan.
14. Baris ke-69, merupakan penutup dari tag launch.
b. Implementasi Lokalisasi AMCL
Implementasi launcher AMCL berisikan node dan parameter untuk lokalisasi
dengan AMCL berdasarkan data laser dan odometry. Semua kode yang
berhubungan dengan parameter hoverboard driver dapat dilihat pada tabel 5.37.
Tabel 5.62 Kode Program Lokalisasi AMCL
Kode Program
No
/opt/ros/noetic/share/amcl/example/amcl_diff.launch
1 <?xml version="1.0"?>
2 <launch>
3 <arg name="use_map_topic" default="false"/>
4 <arg name="scan_topic" default="scan" />
5 <node pkg="amcl" type="amcl" name="amcl">
6 <param name="odom_model_type" value="diff-corrected"/>
<param name="use_map_topic" value="$(arg
7 use_map_topic)"/>
8 <!-- Publish scans from best pose at a max of 10 Hz -->
9 <param name="gui_publish_rate" value="10.0"/>
10 <param name="laser_max_beams" value="720"/>
11 <param name="laser_min_range" value="0.1"/>
12 <param name="laser_max_range" value="16.0"/>
13 <param name="min_particles" value="500"/>
14 <param name="max_particles" value="5000"/>
15 <!-- Maximum error between the true distribution and the
estimated distribution. -->
16 <param name="kld_err" value="0.05"/>
17 <param name="kld_z" value="0.99"/>
18 <param name="odom_alpha1" value="0.2"/>
19 <param name="odom_alpha2" value="0.2"/>
20 <!-- translation std dev, m -->
21 <param name="odom_alpha3" value="0.2"/>
22 <param name="odom_alpha4" value="0.2"/>
23 <param name="laser_z_hit" value="0.5"/>
24 <param name="laser_z_short" value="0.05"/>
25 <param name="laser_z_max" value="0.05"/>
26 <param name="laser_z_rand" value="0.5"/>

199
 27 <param name="laser_sigma_hit" value="0.2"/>
28 <param name="laser_lambda_short" value="0.1"/>
29 <param name="laser_model_type"
value="likelihood_field"/>
30 <!-- Maximum distance to do obstacle inflation on map,
for use in likelihood_field model. -->
31 <param name="laser_likelihood_max_dist" value="2.0"/>
32 <!-- Translational movement required before performing a
filter update. -->
33 <param name="update_min_d" value="0.1"/>
34 <!--Rotational movement required before performing a
filter update. -->
35 <param name="update_min_a" value="0.314"/>
36 <param name="odom_frame_id" value="odom"/>
37 <param name="base_frame_id" value="base_link"/>
38 <param name="global_frame_id" value="map"/>
39 <!-- Number of filter updates required before
resampling. -->
40 <param name="resample_interval" value="1"/>
41 <!-- Increase tolerance because the computer can get
quite busy -->
42 <param name="transform_tolerance" value="1.0"/>
43 <!-- Exponential decay rate for the slow average weight
filter, used in deciding when to recover by adding random
poses. A good value might be 0.001. -->
44 <param name="recovery_alpha_slow" value="0.0"/>
45 <!--Exponential decay rate for the fast average weight
filter, used in deciding when to recover by adding random
poses. A good value might be 0.1. -->
46 <param name="recovery_alpha_fast" value="0.1"/>
47 <!-- Initial pose mean -->
48 <param name="initial_pose_x" value="0.0" />
49 <param name="initial_pose_y" value="0.0" />
50 <param name="initial_pose_a" value="0.0" />
51 <!-- When set to true, AMCL will subscribe to the map
topic rather than making a service call to receive its
map.-->
52 <param name="receive_map_topic" value="true"/>
53 <!-- When set to true, AMCL will only use the first map
it subscribes to, rather than updating each time a new one
is received. -->
54 <param name="first_map_only" value="false"/>
55 <remap from="scan" to="$(arg scan_topic)"/>
56 </node>
57
58 </launch>
Tabel di atas merupakan kode program untuk melakukan pemetaan. Berikut
ini penjelasan mengenai kode program tersebut,
1. Baris ke-1 hingga ke-5, merupakan parameter objek dengan nama
hoverboard_joint_publisher.
"joint_state_controller/JointStateController" digunakan sebagai tipe
kontrolnya agar sistem mengenali bahwa hoverboard menggunakan join
pada setiap TF nya, sehingga TF dari setiap komponen robot dapat
bergerak karena saling terhubung. Publish rate dari paket ini adalah 50 hz
dan deklarasi left_wheel dan right_wheel dengan nilai masing-masingnya

200
 karena kendali robot adalah differential drive, sehingga setiap roda
independen antara satu dengan yang lain.
2. Baris ke-7 hingga ke-22, merupakan parameter deklarasi untuk paket
move_base sehingga pose robot dan ukuran roda dapat diketahui.
3. Baris ke-26 hingga ke-43, merupakan parameter untuk deklarasikan
velocity dan acceleration pada gelar linier dan angular.
4. Baris ke-45 hingga ke-51, merupakan parameter deklarasi untuk
transformasi odom.
c. Implementasi Navigasi Otomatis Dengan Move Base
Implementasi paket launcher move base yang terdiri dari konfigurasi untuk
tiap-tiap parameter yang dipakai pada perencanaan sebelumnya, jika tidak
terdefinisi maka nilai yang dipakai adalah nilai default. Semua kode yang
berhubungan dengan launcher move base dapat dilihat pada tabel 5.33.
Tabel 5.63 Kode Program Move Base
Kode Program
N
autonomous_mobile_robot_navigation/launch/
o
move_base_dijkstra.launch
1 <?xml version="1.0"?>
2 <launch>
3 <!-- Declare topic argument for remap position -->
4 <arg name="scan_topic" default="/scan"/>
5 <arg name="cmd_vel_topic"
default="/hoverboard_velocity_controller/cmd_vel"/>
6 <arg name="odom_topic" default="/odom_combined"/>
7
8 <!-- Call Dijkstra global planners using SrcClient Plugin
-->
9 <arg name="base_global_planner"
default="srv_client_plugin/SrvClientPlugin"/>
10
11 <!-- Move base node -->
12 <node pkg="move_base" type="move_base" respawn="false"
name="move_base" output="screen" default="$(find
autonomous_mobile_robot_navigation)/param/move_base.yaml">
13 <!-- Move base costmap parameter -->
14 <rosparam file="$(find
autonomous_mobile_robot_navigation)/param/costmap_common_2.y
aml" command="load" ns="global_costmap" />
15 <rosparam file="$(find
autonomous_mobile_robot_navigation)/param/costmap_common_2.y
aml" command="load" ns="local_costmap" />
16
17 <!-- Move Base Planner parameter -->
18 <rosparam file="$(find
autonomous_mobile_robot_navigation)/param/move_base.yaml"
command="load" />
19 <rosparam file="$(find
autonomous_mobile_robot_navigation)/param/global_planner.yam
l" command="load" />
20
201
 21 <!-- Remap robot position -->
22 <remap from="cmd_vel" to="$(arg cmd_vel_topic)"/>
23 <remap from="odom" to="$(arg odom_topic)"/>
24 <remap from="scan" to="$(arg scan_topic)"/>
25
26 <!-- Override the plugin for the global planner to use
with move_base -->
27 <param name="base_global_planner" value="$(arg
base_global_planner)"/>
28 <param name="base_local_planner" value="$(arg
base_local_planner)"/>
29
30 </node>
31 </launch>
Tabel di atas merupakan kode program untuk melakukan pemetaan. Berikut
ini penjelasan mengenai kode program tersebut,
1. Baris ke-1 hingga ke-5, merupakan parameter objek dengan nama
hoverboard_joint_publisher.
"joint_state_controller/JointStateController" digunakan sebagai tipe
kontrolnya agar sistem mengenali bahwa hoverboard menggunakan join
pada setiap TF nya, sehingga TF dari setiap komponen robot dapat
bergerak karena saling terhubung. Publish rate dari paket ini adalah 50 hz
dan deklarasi left_wheel dan right_wheel dengan nilai masing-masingnya
karena kendali robot adalah differential drive, sehingga setiap roda
independen antara satu dengan yang lain.
2. Baris ke-7 hingga ke-22, merupakan parameter deklarasi untuk paket
move_base sehingga pose robot dan ukuran roda dapat diketahui.
3. Baris ke-26 hingga ke-43, merupakan parameter untuk deklarasikan
velocity dan acceleration pada gelar linier dan angular.
4. Baris ke-45 hingga ke-51, merupakan parameter deklarasi untuk
transformasi odom.
d. Implementasi Parameter Konfigurasi Common Costmap
Implementasi paket launcher move base yang terdiri dari konfigurasi untuk
tiap-tiap parameter yang dipakai pada perencanaan sebelumnya, jika tidak
terdefinisi maka nilai yang dipakai adalah nilai default. Semua kode yang
berhubungan dengan launcher move base dapat dilihat pada tabel 5.33.
Tabel 5.64 Kode Parameter Konfigurasi Common Costmap
Kode Program
N
autonomous_mobile_robot_navigation/param/
o
common_costmap_2.yaml
1 global_costmap:
2 global_costmap:
3 ros__parameters:
footprint: [[-0.12, -0.12], [-0.12, 0.12], [0.12,
4 0.12], [0.12, -0.12]]
footprint_padding: 0.03

202
5 update_frequency: 1.0
6 publish_frequency: 1.0
7 global_frame: map
8 robot_base_frame: base_link
9 use_sim_time: false
10 robot_radius: 0.22
11 resolution: 0.05
12 plugins: ["static_layer", "obstacle_layer",
13 "voxel_layer", "inflation_layer"]
obstacle_layer:
14 plugin: "nav2_costmap_2d::ObstacleLayer"
15 enabled: true
16 observation_sources: scan
17 footprint_clearing_enabled: true
18 max_obstacle_height: 2.0
19 combination_method: 1
20 scan:
21 topic: /scan
22 obstacle_max_range: 2.5
23 obstacle_min_range: 0.0
24 raytrace_max_range: 3.0
25 raytrace_min_range: 0.0
26 max_obstacle_height: 2.0
27 min_obstacle_height: 0.0
28 clearing: true
29 marking: true
30 data_type: "LaserScan"
31 inf_is_valid: false
32 voxel_layer:
33 plugin: "nav2_costmap_2d::VoxelLayer"
34 enabled: true
35 footprint_clearing_enabled: true
36 max_obstacle_height: 2.0
37 publish_voxel_map: true
38 origin_z: 0.0
39 z_resolution: 0.05
40 z_voxels: 16
41 unknown_threshold: 15
42 mark_threshold: 0
43 observation_sources: pointcloud
44 combination_method: 1
45 pointcloud:
46 topic: /depth_image/points
47 max_obstacle_height: 2.0
48 min_obstacle_height: 0.0
49 obstacle_max_range: 2.5
50 obstacle_min_range: 0.0
51 raytrace_max_range: 3.0
52 raytrace_min_range: 0.0
53 clearing: true
54 marking: true
55 data_type: "PointCloud2"
56 static_layer:
57 plugin: "nav2_costmap_2d::StaticLayer"
58 map_subscribe_transient_local: true
59 enabled: true
60 subscribe_to_updates: true
61 transform_tolerance: 0.1
62 inflation_layer:
203
 63 plugin: "nav2_costmap_2d::InflationLayer"
64 enabled: true
65 inflation_radius: 0.55
66 cost_scaling_factor: 1.0
67 inflate_unknown: false
68 inflate_around_unknown: true
69 always_send_full_costmap: true
70
71 local_costmap:
72 local_costmap:
73 ros__parameters:
74 update_frequency: 5.0
75 publish_frequency: 2.0
76 global_frame: odom
77 robot_base_frame: base_link
78 use_sim_time: true
79 rolling_window: true
80 width: 20
81 height: 20
82 resolution: 0.05
83 plugins:
84 - {name: obstacles_laser, type:
85 "costmap_2d::ObstacleLayer"}
- {name: inflation_l, type:
86 "costmap_2d::InflationLayer"}

Tabel di atas merupakan kode program untuk melakukan pemetaan. Berikut

ini penjelasan mengenai kode program tersebut,
1. Baris ke-1 hingga ke-5, merupakan parameter objek dengan nama
hoverboard_joint_publisher.
"joint_state_controller/JointStateController" digunakan sebagai tipe
kontrolnya agar sistem mengenali bahwa hoverboard menggunakan join
pada setiap TF nya, sehingga TF dari setiap komponen robot dapat
bergerak karena saling terhubung. Publish rate dari paket ini adalah 50 hz
dan deklarasi left_wheel dan right_wheel dengan nilai masing-masingnya
karena kendali robot adalah differential drive, sehingga setiap roda
independen antara satu dengan yang lain.
2. Baris ke-7 hingga ke-22, merupakan parameter deklarasi untuk paket
move_base sehingga pose robot dan ukuran roda dapat diketahui.
3. Baris ke-26 hingga ke-43, merupakan parameter untuk deklarasikan
velocity dan acceleration pada gelar linier dan angular.
4. Baris ke-45 hingga ke-51, merupakan parameter deklarasi untuk
transformasi odom.
e. Implementasi Parameter Konfigurasi Move Base
Implementasi parameter konfigurasi global planner yang terdiri dari
konfigurasi untuk tiap-tiap parameter yang dipakai pada perencanaan
sebelumnya, jika tidak terdefinisi maka nilai yang dipakai adalah nilai default.

204
Semua kode yang berhubungan dengan Parameter Konfigurasi Move Base dapat
dilihat pada tabel 5.33.
Tabel 5.65 Kode Parameter Konfigurasi Move Base
Kode Program
No
autonomous_mobile_robot_navigation/param/move_base.yaml
1 shutdown_costmaps: false
2 max_planning_retries: 0
3 recovery_behavior_enabled: false
4 controller_frequency: 5.0
5 controller_patience: 3.0
6
7 planner_frequency: 0.0 # 0.5
8 planner_patience: 5.0
9
10 oscillation_timeout: 0.0
11 oscillation_distance: 0.2
12
13 # local planner - default is trajectory rollout
14 base_local_planner: "dwa_local_planner/DWAPlannerROS"
15
16 base_global_planner: "srv_client_plugin/SrvClientPlugin"
Tabel di atas merupakan kode program untuk melakukan pemetaan. Berikut
ini penjelasan mengenai kode program tersebut,
1. Baris ke-1 hingga ke-5, merupakan parameter objek dengan nama
hoverboard_joint_publisher.
"joint_state_controller/JointStateController" digunakan sebagai tipe
kontrolnya agar sistem mengenali bahwa hoverboard menggunakan join
pada setiap TF nya, sehingga TF dari setiap komponen robot dapat
bergerak karena saling terhubung. Publish rate dari paket ini adalah 50 hz
dan deklarasi left_wheel dan right_wheel dengan nilai masing-masingnya
karena kendali robot adalah differential drive, sehingga setiap roda
independen antara satu dengan yang lain.
2. Baris ke-7 hingga ke-22, merupakan parameter deklarasi untuk paket
move_base sehingga pose robot dan ukuran roda dapat diketahui.
3. Baris ke-26 hingga ke-43, merupakan parameter untuk deklarasikan
velocity dan acceleration pada gelar linier dan angular.
4. Baris ke-45 hingga ke-51, merupakan parameter deklarasi untuk
transformasi odom.
f. Implementasi Parameter Konfigurasi Global Planner
Implementasi parameter konfigurasi global planner yang terdiri dari
konfigurasi untuk tiap-tiap parameter yang dipakai pada perencanaan
sebelumnya, jika tidak terdefinisi maka nilai yang dipakai adalah nilai default.
Semua kode yang berhubungan dengan Parameter Konfigurasi Global Planner
dapat dilihat pada tabel 5.33.

205
 Tabel 5.66 Kode Parameter Konfigurasi Global Planner
Kode Program
No
autonomous_mobile_robot_navigation/param/global_planner.yaml
1 GlobalPlanner:
2 old_navfn_behavior: false
3 use_quadratic: true
4 use_dijkstra: true
5 use_grid_path: false
6
7 allow_unknown: true
8 planner_window_x: 0.0
9 planner_window_y: 0.0
10 default_tolerance: 0.0
11
12 publish_scale: 100
13 planner_costmap_publish_frequency: 0.0
14
15 lethal_cost: 253
16 neutral_cost: 50
17 cost_factor: 3.0
18 publish_potential: true
Tabel di atas merupakan kode program untuk melakukan pemetaan. Berikut
ini penjelasan mengenai kode program tersebut,
1. Baris ke-1 hingga ke-5, merupakan parameter objek dengan nama
hoverboard_joint_publisher.
"joint_state_controller/JointStateController" digunakan sebagai tipe
kontrolnya agar sistem mengenali bahwa hoverboard menggunakan join
pada setiap TF nya, sehingga TF dari setiap komponen robot dapat
bergerak karena saling terhubung. Publish rate dari paket ini adalah 50 hz
dan deklarasi left_wheel dan right_wheel dengan nilai masing-masingnya
karena kendali robot adalah differential drive, sehingga setiap roda
independen antara satu dengan yang lain.
2. Baris ke-7 hingga ke-22, merupakan parameter deklarasi untuk paket
move_base sehingga pose robot dan ukuran roda dapat diketahui.
3. Baris ke-26 hingga ke-43, merupakan parameter untuk deklarasikan
velocity dan acceleration pada gelar linier dan angular.
4. Baris ke-45 hingga ke-51, merupakan parameter deklarasi untuk
transformasi odom.
g. Implementasi Algoritme Dijkstra
Implementasi algoritme Dijkstra untuk navigasi terdiri dari 2 file utama, yang
pertama adalah file untuk menampung fungsi Dijkstra dan find neighbors, lalu
file kedua adalah file script yang menjadi eksekusi utama program dan
memanggil fungsi Dijkstra di file sebelumnya. Semua kode yang berhubungan
dengan Parameter Konfigurasi Global Planner dapat dilihat pada tabel 5.42.

206
 Tabel 5.67 Kode Algoritme Dijkstra
Kode Program
No
path_planning/unit2_pp/script/dijkstra.py
1 #! /usr/bin/env python
2 import rospy
3
4 def find_neighbors(index, width, height, costmap,
orthogonal_step_cost):
5 neighbors = []
6 # length of diagonal = length of one side by the square
root of 2 (1.41421)
7 diagonal_step_cost = orthogonal_step_cost * 1.41421
8 # threshold value used to reject neighbor nodes as they
are considered as obstacles [1-254]
9 lethal_cost = 1
10
11 upper = index - width
12 if upper > 0:
13 if costmap[upper] < lethal_cost:
14 step_cost = orthogonal_step_cost + costmap[upper]/255
15 neighbors.append([upper, step_cost])
16
17 left = index - 1
18 if left % width > 0:
19 if costmap[left] < lethal_cost:
20 step_cost = orthogonal_step_cost + costmap[left]/255
21 neighbors.append([left, step_cost])
22
23 upper_left = index - width - 1
24 if upper_left > 0 and upper_left % width > 0:
25 if costmap[upper_left] < lethal_cost:
26 step_cost = diagonal_step_cost +
costmap[upper_left]/255
27 neighbors.append([index - width - 1, step_cost])
28
29 upper_right = index - width + 1
30 if upper_right > 0 and (upper_right) % width != (width -
1):
31 if costmap[upper_right] < lethal_cost:
32 step_cost = diagonal_step_cost +
costmap[upper_right]/255
33 neighbors.append([upper_right, step_cost])
34
35 right = index + 1
36 if right % width != (width + 1):
37 if costmap[right] < lethal_cost:
38 step_cost = orthogonal_step_cost + costmap[right]/255
39 neighbors.append([right, step_cost])
40
41 lower_left = index + width - 1
42 if lower_left < height * width and lower_left % width !=
0:
43 if costmap[lower_left] < lethal_cost:
44 step_cost = diagonal_step_cost +
costmap[lower_left]/255
45 neighbors.append([lower_left, step_cost])
46

207
47 lower = index + width
48 if lower <= height * width:
49 if costmap[lower] < lethal_cost:
50 step_cost = orthogonal_step_cost + costmap[lower]/255
51 neighbors.append([lower, step_cost])
52
53 lower_right = index + width + 1
54 if (lower_right) <= height * width and lower_right %
width != (width - 1):
55 if costmap[lower_right] < lethal_cost:
56 step_cost = diagonal_step_cost +
costmap[lower_right]/255
57 neighbors.append([lower_right, step_cost])
58
59 return neighbors
60
61
62 def dijkstra(start_index, goal_index, width, height,
costmap, resolution, origin, grid_viz):
63 '''
64 Performs Dijkstra's shortes path algorithm search on a
costmap with a given start and goal node
65 '''
66
67 # create an open_list
68 open_list = []
69
70 # set to hold already processed nodes
71 closed_list = set()
72
73 # dict for mapping children to parent
74 parents = dict()
75
76 # dict for mapping g costs (travel costs) to nodes
77 g_costs = dict()
78
79 # set the start's node g_cost
80 g_costs[start_index] = 0
81
82 # add start node to open list
83 open_list.append([start_index, 0])
84
85 shortest_path = []
86
87 path_found = False
88 rospy.loginfo('Dijkstra: Done with initialization')
89
90 # Main loop, executes as long as there are still nodes
inside open_list
91 while open_list:
92
93 # sort open_list according to the lowest 'g_cost' value
(second element of each sublist)
94 open_list.sort(key = lambda x: x[1])
95
96 # extract the first element (the one with the lowest
'g_cost' value)
97 current_node = open_list.pop(0)[0]
98
208
99 # Close current_node to prevent from visting it again
100 closed_list.add(current_node)
101
102 # Optional: visualize closed nodes
103 grid_viz.set_color(current_node,"pale yellow")
104
105 # If current_node is the goal, exit the main loop
106 if current_node == goal_index:
107 path_found = True
108 break
109
110 # Get neighbors of current_node
111 neighbors = find_neighbors(current_node, width, height,
costmap, resolution)
112
113 # Loop neighbors
114 for neighbor_index, step_cost in neighbors:
115
116 # Check if the neighbor has already been visited
117 if neighbor_index in closed_list:
118 continue
119
120 # calculate g_cost of neighbour considering it is
reached through current_node
121 g_cost = g_costs[current_node] + step_cost
122
123 # Check if the neighbor is in open_list
124 in_open_list = False
125 for idx, element in enumerate(open_list):
126 if element[0] == neighbor_index:
127 in_open_list = True
128 break
129
130 # CASE 1: neighbor already in open_list
131 if in_open_list:
132 if g_cost < g_costs[neighbor_index]:
133 rospy.print("updated")
134 # Update the node's g_cost inside g_costs
135 g_costs[neighbor_index] = g_cost
136 parents[neighbor_index] = current_node
137 # Update the node's g_cost inside open_list
138 open_list[idx] = [neighbor_index, g_cost]
139 rospy.print("neighbor_index = %s",
140 neighbor_index)
rospy.print("g_costs[neighbor_index] = %s",
141 g_costs[neighbor_index])
rospy.print("parents[neighbor_index] = %s",
142 parents[neighbor_index])
143
144 # CASE 2: neighbor not in open_list
145 else:
146 rospy.print("not updated")
147 # Set the node's g_cost inside g_costs
148 g_costs[neighbor_index] = g_cost
149 parents[neighbor_index] = current_node
150 # Add neighbor to open_list
151 open_list.append([neighbor_index, g_cost])
152
153 # Optional: visualize frontier
209
 154 grid_viz.set_color(neighbor_index,'orange')
155
rospy.loginfo('Dijkstra: Done traversing nodes in
156 open_list')
157
158 if not path_found:
159 rospy.logwarn('Dijkstra: No path found!')
160 return shortest_path
161
162 # Reconstruct path by working backwards from target
163 if path_found:
164 node = goal_index
165 shortest_path.append(goal_index)
166 while node != start_index:
167 shortest_path.append(node)
168 # get next node
169 node = parents[node]
170 # reverse list
171 shortest_path = shortest_path[::-1]
172 rospy.loginfo('Dijkstra: Done reconstructing path')
173
return shortest_path
Tabel di atas merupakan kode program untuk melakukan pemetaan. Berikut
ini penjelasan mengenai kode program tersebut,
1. Baris ke-1 hingga ke-5, merupakan parameter objek dengan nama
hoverboard_joint_publisher.
"joint_state_controller/JointStateController" digunakan sebagai tipe
kontrolnya agar sistem mengenali bahwa hoverboard menggunakan join
pada setiap TF nya, sehingga TF dari setiap komponen robot dapat
bergerak karena saling terhubung. Publish rate dari paket ini adalah 50 hz
dan deklarasi left_wheel dan right_wheel dengan nilai masing-masingnya
karena kendali robot adalah differential drive, sehingga setiap roda
independen antara satu dengan yang lain.
2. Baris ke-7 hingga ke-22, merupakan parameter deklarasi untuk paket
move_base sehingga pose robot dan ukuran roda dapat diketahui.
3. Baris ke-26 hingga ke-43, merupakan parameter untuk deklarasikan
velocity dan acceleration pada gelar linier dan angular.
4. Baris ke-45 hingga ke-51, merupakan parameter deklarasi untuk
transformasi odom.
Implementasi algoritme Dijkstra untuk navigasi terdiri dari 2 file utama, yang
pertama adalah file untuk menampung fungsi Dijkstra dan find neighbors, lalu
file kedua adalah file script yang menjadi eksekusi utama program dan
memanggil fungsi Dijkstra di file sebelumnya. Semua kode yang berhubungan
dengan Parameter Konfigurasi Global Planner dapat dilihat pada tabel 5.42.
Tabel 5.68 Kode Path Planning Global Dengan Dijkstra
N Kode Program
o path_planning/unit2_pp/script/main.py

210
1 #!/usr/bin/env python
2
3 import rospy
4 from pp_msgs.srv import PathPlanningPlugin,
PathPlanningPluginResponse
5 from geometry_msgs.msg import Twist
6 from gridviz import GridViz
7 from dijkstra import dijkstra
8
9 def make_plan(req):
10 '''
11 Callback function used by the service server to process
12 requests from clients. It returns a msg of type
PathPlanningPluginResponse
13 '''
14 # costmap as 1-D array representation
15 costmap = req.costmap_ros
16 # number of columns in the occupancy grid
17 width = req.width
18 # number of rows in the occupancy grid
19 height = req.height
20 start_index = req.start
21 goal_index = req.goal
22 # side of each grid map square in meters
23 resolution = 0.2
24 # origin of grid map
25 origin = [-7.4, -7.4, 0]
26
27 viz = GridViz(costmap, resolution, origin, start_index,
goal_index, width)
28
29 # time statistics
30 start_time = rospy.Time.now()
31
32 # calculate the shortes path using Dijkstra
33 path = dijkstra(start_index, goal_index, width, height,
costmap, resolution, origin, viz)
34
35 if not path:
36 rospy.logwarn("No path returned by Dijkstra's shortes
path algorithm")
37 path = []
38 else:
39 execution_time = rospy.Time.now() - start_time
40 print("\n")
41 rospy.loginfo('++++++++ Dijkstra execution metrics +++++
+++')
42 rospy.loginfo('Total execution time: %s seconds',
str(execution_time.to_sec()))
43 rospy.loginfo('+++++++++++++++++++++++++++++++++++++++++++
+')
44 print("\n")
45 rospy.loginfo('Dijkstra: Path sent to navigation stack')
46
47 resp = PathPlanningPluginResponse()
48 resp.plan = path
49 return resp
50
51 def clean_shutdown():
211
 52 cmd_vel.publish(Twist())
53 rospy.sleep(1)
54
55 if __name__ == '__main__':
56 rospy.init_node('dijkstra_path_planning_service_server',
log_level=rospy.INFO, anonymous=False)
57 make_plan_service =
rospy.Service("/path_planning/SrvClientPlugin/make_plan",
PathPlanningPlugin, make_plan)
58 cmd_vel =
rospy.Publisher('hoverboard_velocity_controller/cmd_vel',
Twist, queue_size=5)
59 rospy.on_shutdown(clean_shutdown)
60
61 while not rospy.core.is_shutdown():
62 rospy.rostime.wallsleep(0.5)
63 rospy.Timer(rospy.Duration(2),
64 rospy.signal_shutdown('Shutting down'), oneshot=True)
Tabel di atas merupakan kode program untuk melakukan pemetaan. Berikut
ini penjelasan mengenai kode program tersebut,
1. Baris ke-1 hingga ke-5, merupakan parameter objek dengan nama
hoverboard_joint_publisher.
"joint_state_controller/JointStateController" digunakan sebagai tipe
kontrolnya agar sistem mengenali bahwa hoverboard menggunakan join
pada setiap TF nya, sehingga TF dari setiap komponen robot dapat
bergerak karena saling terhubung. Publish rate dari paket ini adalah 50 hz
dan deklarasi left_wheel dan right_wheel dengan nilai masing-masingnya
karena kendali robot adalah differential drive, sehingga setiap roda
independen antara satu dengan yang lain.
2. Baris ke-7 hingga ke-22, merupakan parameter deklarasi untuk paket
move_base sehingga pose robot dan ukuran roda dapat diketahui.
3. Baris ke-26 hingga ke-43, merupakan parameter untuk deklarasikan
velocity dan acceleration pada gelar linier dan angular.
4. Baris ke-45 hingga ke-51, merupakan parameter deklarasi untuk
transformasi odom.
.

212
 BAB 6 PENGUJIAN

Dalam bab pengujian, penulis akan menunjukkan bagaimana sistem ini dapat
diimplementasikan dengan pengujian untuk menilai apakah sistem yang
dirancang telah sesuai dengan tujuan maupun rumusan masalah yang di ajukan.
Hasil dari pengujian juga digunakan sebagai hasil penarikan kesimpulan pada bab
selanjutnya, berikut merupakan tahapan pengujian pada penelitian ini.

6.1 Pengujian Fungsionalitas Odometry Motor BLDC

Penelitian ini akan diuji dengan menggunakan sebuah purwarupa robot
bergerak otonom dengan ukuran yang disesuaikan dengan kebutuhan di gudang
penyimpanan. Pengujian di sini nantinya akan diuji berdasarkan fungsionalitas
dan kinerja. Pengujian ini dilakukan untuk mengetahui tingkat ketelitian dari nilai
putaran odometry pada motor BLDC dengan tujuan akhir untuk mencapai jarak
tertentu dengan error yang kecil.

6.1.1 Tujuan Pengujian

Tujuan dari pengujian fungsionalitas odometry motor BLDC yaitu untuk
mengetahui kinerja dari motor BLDC dalam berputar sebanyak putaran tertentu
yang sudah disesuaikan dengan input dari program rqt. Besarnya error dari
motor umumnya disebabkan ke tidak tepatan konfigurasi motor hoverboard,
seperti ukuran diameter roda robot dan jarak satu roda ke roda lainnya, sehingga
kesalahan perhitungan menyebabkan putaran motor dalam mencapai jarak
tertentu tidak sesuai dengan yang ada di visualisasi RViz.

6.1.2 Prosedur Pengujian

Prosedur pengujian fungsionalitas dari odometry akan dilakukan dengan
melakukan prosedur yang telah disesuaikan sebagai berikut:
1. Menyambungkan perangkat Motor BLDC dengan motor driver, yaitu
hoverboard motherboard dan Jetson Nano yang masing-masingnya
disambungkan sumber daya baterai.
2. Menghidupkan perangkat hoverboard motherboard dan Jetson Nano
yang sudah terpasang dengan sistem operasi Linux Tegra.
3. Memasang penanda pada tanda titik di motor BLDC untuk digunakan
menghitung putaran roda dengan RPM yang sudah dihitung.
4. Menjalankan kode hoverboard driver launcher dan rqt robot steering
untuk menjalankan dan menampilkan data odometry.
5. Memasukkan nilai kecepatan (m/s) melalui perintah pada aplikasi rqt
robot steering untuk menggerakkan motor dengan kecepatan yang
bervariasi.

213
 6. Mengamati jumlah putaran per cycle selama waktu observasi, yaitu 20
detik dan mengamati nilai odometry yang ditampilkan oleh topic /odom.
7. Melakukan analisis perbandingan dan perhitungan nilai RPM
menggunakan RPM converter dari setiap kecepatan yang di ujikan.

6.1.3 Hasil Pengujian

Hasil pengujian dari odometry motor BLDC akan disajikan pada tabel dan juga
terdapat dokumentasi pada gambar 6.1 dan tabel 6.1 untuk menghitung jumlah
putaran per detik dari nilai odometry motor BLDC.

Gambar 6.100 Menganalisis RPM Odometry Hoverboard Dengan

Membandingkan Dengan RPM Observasi
Tabel 6.69 Pengujian Odometry Motor BLDC

Uji akurasi sensor Odometri

Input Odometri Observasi

No Kecepatan Jumlah
Kecepatan RPM sebe- Waktu ob-
rotasi putaran RPM
(m/s) narnya servasi (s)
(rad/s) roda (cyc)
1 0.2 2.30384 22 20 7.5 22.5
2 0.4 4.7124 45 20 15.14 45.4
3 0.6 7.12096 68 20 23.5 70.5
4 0.8 9.63424 92 20 31.4 94.2
5 1 12.0428 115 20 39 117
6 1.2 14.45136 138 20 46.8 140.4
7 1.4 16.7552 160 20 54.6 163.8
8 1.6 19.26848 184 20 62.3 186.9
9 1.8 21.78176 210 20 70.7 212.1

214
 10 2 24.39976 233 20 79 237
Tabel 6.70 Hasil Akurasi Pengujian Fungsionalitas Nilai Odometry

Total RPM odometry Total RPM observasi

Pengukuran kesalahan
1267 1289.8
WAPE 1.80%
Nilai akurasi 98.20%

6.1.4 Analisis Pengujian

Dari hasil pengujian yang didapatkan untuk mencari tahu ketepatan nilai
odometry motor BLDC terhadap nilai putaran sebenarnya, dari 10 kali pengujian
dengan kecepatan yang berbeda-beda didapatkan nilai akurasi sebesar 98.20%.
Hasil akurasi ini dihitung berdasarkan persamaan 2.23 dan 2.24 mengenai WAPE
dan persentase keberhasilan. Berdasarkan hasil akurasi yang didapatkan
disimpulkan bahwa kinerja dan konfigurasi odometry dari motor BLDC yang
dipakai oleh sistem tergolong sangat baik dan presisi.

6.2 Pengujian Fungsionalitas Sensor RPLIDAR A1

Pengujian fungsionalitas laser point cloud yang menggunakan sensor RPLIDAR
A1 sebagai input dari sistem yang menghasilkan data berupa jarak. Dalam
pengujian ini akan dilakukan serangkaian uji terhadap sistem dari laser RPLIDAR
secara langsung. Pengujian ini akan dilakukan dengan pengambilan data dari
keluaran data point cloud yang dihasilkan sesuai dengan kondisi lingkungan
sekitar.

6.2.1 Tujuan Pengujian

Tujuan dari pengujian fungsionalitas laser point cloud dari sistem ini adalah
untuk mengetahui bagaimana kinerja dari perangkat RPLIDAR yang digunakan
dalam pengambilan data jarak berdasarkan kondisi lingkungan sekitar.

6.2.2 Prosedur Pengujian

Prosedur pengujian fungsionalitas dari RPLIDAR akan dilakukan dengan
melakukan prosedur yang telah disesuaikan sebagai berikut:
1. Menyambungkan perangkat RPLIDAR A1 dengan Jetson Nano
menggunakan adapter UART ke port USB.
2. Menghidupkan perangkat Jetson Nano yang sudah terpasang dengan
sistem operasi Linux Tegra .
3. Menghubungkan laptop dengan Jetson Nano menggunakan VNC Viewer.
4. Menjalankan kode pada driver rplidar_ros untuk menampilkan grafik
bentuk laser dan jarak dari pengambilan laser.

215
 5. Mengamati hasil data yang diambil dari point cloud laser RPLIDAR untuk
mengetahui kinerja dan ketepatan nilai pada perangkat lunak dengan
jarak sebenarnya.
6. Melakukan analisis perbandingan dan perhitungan data jarak perangkat
lunak rplidar_ros dengan pengukuran jarak sebenarnya dari setiap jarak
yang di ujikan.

6.2.3 Hasil Pengujian

Hasil pengujian dari fungsionalitas perangkat RPLIDAR dilakukan sebanyak
sepuluh kali percobaan dan hasil dari pengujian bisa dilihat pada gambar 6.2 dan
tabel 6.3.

Gambar 6.101 Kondisi Lingkungan Sekitar Pada Pengujian Jarak Data RPLIDAR
Tabel 6.71 Pengujian Fungsionalitas RPLIDAR
Uji akurasi jarak sensor RPLIDAR A1

Hasil Pengamatan Pengukuran

RPLIDAR A1
Observasi
No Halangan
Sudut Jarak Sudut Jarak
(∠) (cm) (∠) (cm)

1 Sangat dekat 180 9.7 180 0

216
2 Terdekat 180 10 180 10.8

3 Tembok 0 76 0 77

4 Tembok 90 65 90 66.3

5 Tembok 180 75 180 76.4

6 Tembok 270 65 270 66.5

7 Objek 1 180 43 180 43.7

217
 8 Objek 2 0 60 0 61.3

9 Objek 3 135 50 141 51.5

10 Objek 4 315 42 330 43.5

Tabel 6.72 Hasil Akurasi Pengujian Fungsionalitas RPLIDAR

Total jarak observasi Total jarak RPLIDAR

Pengukuran kesalahan
495.7 497
WAPE 0.26%
Nilai akurasi 99.74%

6.2.4 Analisis Pengujian

Dari hasil pengujian yang didapatkan untuk mencari tahu ketepatan nilai
odometry motor BLDC terhadap nilai putaran sebenarnya, dari 10 kali pengujian
dengan kecepatan yang berbeda-beda didapatkan nilai akurasi sebesar 98.20%.
Hasil akurasi ini dihitung berdasarkan persamaan 2.23 dan 2.24 mengenai WAPE
dan persentase keberhasilan. Berdasarkan hasil akurasi yang didapatkan
disimpulkan bahwa kinerja dan konfigurasi odometry dari motor BLDC yang
dipakai oleh sistem tergolong sangat baik dan presisi

6.3 Pengujian Fungsionalitas Sensor IMU GY-521

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

218
6.3.1 Tujuan Pengujian
Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.3.2 Prosedur Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.3.3 Hasil Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.3.4 Analisis Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.4 Pengujian Lokalisasi Dan Fusi Sensor Dengan Extended Kalman

Filter
Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.4.1 Tujuan Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.4.2 Prosedur Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.4.3 Hasil Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

219
6.4.4 Analisis Pengujian
Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.5 Pengujian Hasil Pemetaan Dengan Hector SLAM

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.5.1 Tujuan Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.5.2 Prosedur Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.5.3 Hasil Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.5.4 Analisis Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.6 Pengujian Hasil Pemetaan Hector SLAM Tanpa Lokalisasi EKF

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.6.1 Tujuan Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

220
6.6.2 Prosedur Pengujian
Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.6.3 Hasil Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.6.4 Analisis Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.7 Pengujian Lokalisasi Dengan Adaptive Monte Carlo Localization

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.7.1 Tujuan Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.7.2 Prosedur Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.7.3 Hasil Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.7.4 Analisis Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

221
6.8 Pengujian Manuver Gerak Robot Pada Navigasi Global Algoritme
Dijkstra Dengan Berbagai Konfigurasi Berbeda
Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.8.1 Tujuan Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.8.2 Prosedur Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.8.3 Hasil Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.8.4 Analisis Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.9 Pengujian Waktu Komputasi Pada Navigasi Global Algoritme

Dijkstra Dengan Berbagai Konfigurasi Berbeda
Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.9.1 Tujuan Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.9.2 Prosedur Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

222
6.9.3 Hasil Pengujian
Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.9.4 Analisis Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.10 6.8 Pengujian Manuver Gerak Robot Pada Navigasi Global

Algoritme Dijkstra Dan Perencanaan Lokal Dynamic Window
Approach Dengan Berbagai Konfigurasi Berbeda
Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.10.1 Tujuan Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.10.2 Prosedur Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.10.3 Hasil Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.10.4 Analisis Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

223
6.11 6.8 Pengujian Waktu Komputasi Pada Navigasi Global
Algoritme Dijkstra Dan Perencanaan Lokal Dynamic Window
Approach Dengan Berbagai Konfigurasi Berbeda
Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.11.1 Tujuan Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.11.2 Prosedur Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.11.3 Hasil Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

6.11.4 Analisis Pengujian

Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:

224
 BAB 7 PENUTUP

Dalam bab penutup, penulis akan menyampaikan hasil yang telah penulis
dapatkan selama melakukan penelitian ini. Hasil yang didapatkan berasal dari
data yang telah penulis terima dari pengujian. Adanya hasil tersebut,
memungkinkan penulis untuk menarik kesimpulan atas rumusan masalah yang
sebelumnya diutarakan. Kemudian karena kondisi penelitian ini yang juga
terbatas pada kemampuan maupun waktu yang ada, akan ada saran kedepannya
guna mengembangkan lebih lanjut sistem atau bahkan diterapkan pada kondisi
rill nantinya.

7.1 Kesimpulan
Atas hasil pengujian yang penulis dapatkan selama melakukan penelitian ini,
maka penulis dapat menarik kesimpulan untuk menjawab rumusan masalah yang
ada. Berikut adalah kesimpulan dari penulis:
1. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id
est laborum.
2. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id
est laborum.
3. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id
est laborum.

7.2 Saran
Selama pelaksanaan penelitian ini, terdapat beberapa kekurangan yang
penulis miliki. Sehingga penulis yakin bahwasannya sistem ini dapat
dikembangkan lebih lanjut secara bersama-sama dengan peneliti lainnya di
Indonesia maupun di dunia. Oleh karena itu penulis telah merangkum beberapa
saran yang mungkin dapat dilanjutkan oleh peneliti selanjutnya
225
1. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id
est laborum.
2. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id
est laborum.
3. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id
est laborum.

226
 DAFTAR REFERENSI

Bekey, G.A., 2005. Autonomous robots : from biological inspiration to

implementation and control. Intelligent Robotics and Autonomous Agents series.
Communication. MIT Press.
Ben-Ari, M. dan Mondada, F., 2018. Robotic Motion and Odometry. In: Elements
of Robotics. Springer, Cham.hal.63–93.
Birk, A. dan Pfingsthorn, M., 2016. Simultaneous Localization and Mapping
(SLAM). In: Wiley Encyclopedia of Electrical and Electronics Engineering. John
Wiley & Sons, Inc.hal.1–24.
Bodrenko, A., 2019. New Method of Using Mobile Robots for Moving Cargo in
Warehouse. Bulletin of Science and Practice, 5(6), hal.192–211.
BPS, 2018. Laporan Hasil Survei Triwulanan Kegiatan Usaha Terintegrasi 2017.
Jakarta: Badan Pusat Statistik.
BPS, 2019. Analisis Hasil SE2016 Lanjutan Analisis Usaha Jasa Aktivitas Pos dan
Kurir Modern. Jakarta: Badan Pusat Statistic.
BPS, 2020. Indeks Triwulan Kegiatan Usaha Perdagangan, Transportasi,
Keuangan, Komunikasi dan Teknologi Informasi Tahun 2019. Badan Pusat
Statistik, Jakarta, Indonesia: Badan Pusat Statistik.
Bräunl, T., 2008. Embedded Robotics: Mobile Robot Design and Applications with
Embedded Systems. Third ed. Springer. Perth, Australia: Springer.
Brombach, L., 2021. Practical Robotics in C++: Build and Program Real
Autonomous Robots Using Raspberry Pi (English Edition). English ed ed. New
Delhi: BPB Publications.
Chase, C.W., 2013. Demand-Driven Forecasting. Second ed. Demand-Driven
Forecasting. Canada: John Wiley & Sons, Inc.
Databoks, 2021. Nilai Transaksi E-Commerce Mencapai Rp 266,3 Triliun pada
2020 Nominal Transaksi E-Commerce (2017-2020). [daring]
Databoks.Katadata.Co.Id. Tersedia pada:
<https://databoks.katadata.co.id/datapublish/2021/01/29/nilai-transaksi-e-
commerce-mencapai-rp-2663-triliun-pada-2020> [Diakses 15 Des 2021].
Dijkstra, E.W., 1959. A note on two problems in connexion with graphs.
Numerische Mathematik, 1(1), hal.269–271.
Dudek, G. dan Jenkin, M., 2001. Computational Principles of Mobile Robotics. In:
Computational Principles of Mobile Robotics. hal.1–8.
Erlangga, D., D, E., H S, R., Sunarto, S., Rahardjo T.S, K. dan G, F., 2019. Sistem
Navigasi Mobile Robot Dalam Ruangan Berbasis Autonomous Navigation. Journal
of Mechanical Engineering and Mechatronics, 4(2), hal.78.
Galov, A. dan Moschevikin, A., 2014. Simultaneous localization and mapping in

227
indoor positioning systems based on round trip time-of-flight measurements and
inertial navigation. IPIN 2014 - 2014 International Conference on Indoor
Positioning and Indoor Navigation, hal.457–464.
Holland, J., 2004. Designing Autonomous Mobile Robots. Designing Autonomous
Mobile Robots. Burlington: Elsevier Inc.
Joseph, L., 2018. Robot Operating System for Absolute Beginners. Robot
Operating System for Absolute Beginners. Kerala: Apress.
KBBI, 2016. Kamus Besar Bahasa Indonesia. [daring] Tersedia pada:
<https://kbbi.web.id/robot-2> [Diakses 14 Mar 2022].
Kohlbrecher, S., Meyer, J., Graber, T., Petersen, K., Klingauf, U. dan Von Stryk, O.,
2014. Hector open source modules for autonomous mapping and navigation with
rescue robots. Lecture Notes in Computer Science (including subseries Lecture
Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 8371 LNAI,
hal.624–631.
Kohlbrecher, S., Von Stryk, O., Meyer, J. dan Klingauf, U., 2011. A flexible and
scalable SLAM system with full 3D motion estimation. In: 9th IEEE International
Symposium on Safety, Security, and Rescue Robotics, SSRR 2011. hal.155–160.
Koumanakos, D.P., 2008. The effect of inventory management on firm
performance. International Journal of Productivity and Performance
Management, 57(5), hal.355–369.
Liu, L.S., Lin, J.F., Yao, J.X., He, D.W., Zheng, J.S., Huang, J. dan Shi, P., 2021. Path
Planning for Smart Car Based on Dijkstra Algorithm and Dynamic Window
Approach. Wireless Communications and Mobile Computing, 2021.
Louhichi, K., Jacquet, F. dan Butault, J.P., 2012. Estimating input allocation from
heterogeneous data sources: A comparison of alternative estimation approaches.
Agricultural Economics Review, .
Manuel, J. dan Ferrão, M., 2018. Study of SLAM algorithms for autonomous
navigation in unstructured environments.
Marin-Plaza, P., Hussein, A., Martin, D. dan De La Escalera, A., 2018. Global and
Local Path Planning Study in a ROS-Based Research Platform for Autonomous
Vehicles. Journal of Advanced Transportation, 2018.
Michelson, R.C., 2017. Autonomous Navigation. Encyclopedia of GIS, hal.100–
100.
Muliady, Sartika, E.M. dan Reynaldo, K., 2015. The Implementation of Hector
SLAM on The Earthquake Victims Finder Robot. Jurnal Teknik dan Ilmu Komputer.
Parcel Perform dan iPrice Group, 2019. Consumers are still not happy with their
e-commerce delivery experience, a new survey by Parcel Perform and iPrice
Group reveals | Mini Me Insights. [daring] Minime Insights. Tersedia pada:
<https://www.minimeinsights.com/2019/06/26/consumers-are-still-not-happy-
with-their-e-commerce-delivery-experience-a-new-survey-by-parcel-perform-

228
and-iprice-group-reveals/> [Diakses 12 Mar 2022].
Peng, G., Zheng, W., Lu, Z., Liao, J., Hu, L., Zhang, G. dan He, D., 2018. An
improved AMCL algorithm based on laser scanning match in a complex and
unstructured environment. Complexity, 2018.
Putra, T.A., Muliady, M. dan Setiadikarunia, D., 2020. Navigasi Indoor Berbasis
Peta pada Robot Beroda dengan Platform Robot Operating System. Jetri : Jurnal
Ilmiah Teknik Elektro, 17(2), hal.121.
Pyo, Y., Cho, H., Jung, R. dan Lim, T., 2017. Robot Programming From The Basic
Concept To Practical Programming and Robot Application. First Edit ed. Seoul,
Republic of Korea: ROBOTIS Co., Ltd.
Ragnerstam, E., 2016. How to calculate forecast accuracy for stocked items with
a lumpy demand-A case study at Alfa Laval. School of Innovation, Design and
Engineering.
Rajendra, A., 2015. Indoor Navigation System. International Journal of Applied
Engineering Research, Volume 10, hal.10515–10524.
Reilly, E.D., 2003. Motherboard. [daring] Encyclopedia of Computer Science.
Tersedia pada: <https://dl.acm.org/doi/10.5555/1074100.1074618> [Diakses 20
Okt 2021].
Richardson, T., Stafford-Fraser, Q., Wood, K.R. dan Hopper, A., 1998. Virtual
network computing. IEEE Internet Computing, 2(1), hal.33–38.
RoboPeak Team, 2014. RPLIDAR Low Cost 360 degree 2D Laser Scanner ( LIDAR )
System Development Kit User Manual. hal.14.
Siegwart, R., Nourbakhsh, I.R. dan Scaramuzza, D., 2004. Introduction to
Autonomous Mobile Robots. Second edi ed. Industrial Robot: An International
Journal, London, England: The MIT Press.
Souliman, A., 2019. Mapping and Localization for Indoor Mobile Robot Based on
RGB-D Camera. (August 2017).
Statista, 2019. E-commerce in Indonesia - statistics & Facts.
Todd, D.J., 1986. Fundamentals of Robot Technology. Fundamentals of Robot
Technology. London: Kogan Page Ltd.
Utomo, E.B., 2015. Autonomous Mobile Robot Berbasis Landmark Menggunakan
Particle Filter Dan Occupancy Grid Maps Untuk Navigasi, Lokalisasi dan Mapping.
hal.1–93.
Wang, H., 2012. Design and implementation of brushless DC motor drive and
control system. In: Procedia Engineering. No longer published by
Elsevier.hal.2219–2224.
Williman, A.O. dan Jelinek, H.J., 1976. Introduction To Lsi Microprocessor
Developments. Computer, 9(6), hal.34–46.
Xu, L., Feng, C., Kamat, V.R. dan Menassa, C.C., 2019. An Occupancy Grid
229
Mapping enhanced visual SLAM for real-time locating applications in indoor GPS-
denied environments. Automation in Construction, 104, hal.230–245.
Zetes, 2021. Autonomous mobile robots (AMR), latest warehouse technology.
[daring] Zetes. Tersedia pada: <https://www.zetes.com/en/warehouse-
solutions/autonomous-mobile-robots> [Diakses 16 Des 2021].
Zhang, X., Lai, J., Xu, D., Li, H. dan Fu, M., 2020. 2D Lidar-Based SLAM and Path
Planning for Indoor Rescue Using Mobile Robots. Journal of Advanced
Transportation, 2020.

230
 LAMPIRAN A PERSYARATAN FISIK DAN TATA LETAK

A.1 Kertas
Kertas yang digunakan adalah HVS 70 mg berukuran A4. Apabila terdapat
gambar-gambar yang menggunakan kertas berukuran lebih besar dari A4,
hendaknya dilipat sesuai dengan aturan yang berlaku. Pengetikan hanya
dilakukan pada satu muka kertas, tidak bolak balik.

A.2 Margin
Batas pengetikan naskah adalah sebagai berikut :

A.3 Jenis dan Ukuran Huruf

Jenis huruf yang dipakai dalam skripsi adalah Calibri dengan ketentuan
sebagai berikut:

A.4 Spasi
Jarak standar antar baris dalam badan teks adalah satu spasi. Jarak antar
paragraf, antara judul bab dan judul subbab, antara judul subbab dan badan
teks, dan seterusnya, dapat dilihat pada masing-masing style yang digunakan dan
tersedia dalam template untuk skripsi ini.

A.5 Kepala Bab dan Subbab

Kepala bab terdiri dari kata “BAB” yang diikuti dengan nomor bab dan judul
dari bab tersebut, misalnya “BAB 1 PENDAHULUAN” . Kepala subbab diawali
dengan nomor sesuai tingkat hirarkinya dan diikuti dengan judul subbab,

A.6 Nomor Halaman

Bagian awal skripsi menggunakan nomor halaman berupa angka
Romawi kecil (i, ii, iii, iv, dan seterusnya) yang dimulai dari sampul dalam.

231
 LAMPIRAN B PERSYARATAN FISIK DAN TATA LETAK

B.1 Margin
Batas pengetikan naskah adalah sebagai berikut :

B.2 Jenis dan Ukuran Huruf

Jenis huruf yang dipakai dalam skripsi adalah Calibri dengan ketentuan
sebagai berikut:

B.3 Spasi
Jarak standar antar baris dalam badan teks adalah satu spasi. Jarak antar
paragraf, antara judul bab dan judul subbab, antara judul subbab dan badan
teks, dan seterusnya, dapat dilihat pada masing-masing style yang digunakan dan
tersedia dalam template untuk skripsi ini.

B.4 Kepala Bab dan Subbab

Kepala bab terdiri dari kata “BAB” yang diikuti dengan nomor bab dan judul
dari bab tersebut, misalnya “BAB 1 PENDAHULUAN” . Kepala subbab diawali
dengan nomor sesuai tingkat hirarkinya dan diikuti dengan judul subbab,

B.5 Nomor Halaman

Bagian awal skripsi menggunakan nomor halaman berupa angka
Romawi kecil (i, ii, iii, iv, dan seterusnya) yang dimulai dari sampul dalam.

232
 LAMPIRAN C PERSYARATAN FISIK DAN TATA LETAK

C.1 Margin
Batas pengetikan naskah adalah sebagai berikut :

C.2 Jenis dan Ukuran Huruf

Jenis huruf yang dipakai dalam skripsi adalah Calibri dengan ketentuan
sebagai berikut:

C.3 Spasi
Jarak standar antar baris dalam badan teks adalah satu spasi. Jarak antar
paragraf, antara judul bab dan judul subbab, antara judul subbab dan badan
teks, dan seterusnya, dapat dilihat pada masing-masing style yang digunakan dan
tersedia dalam template untuk skripsi ini.

C.4 Kepala Bab dan Subbab

Kepala bab terdiri dari kata “BAB” yang diikuti dengan nomor bab dan judul
dari bab tersebut, misalnya “BAB 1 PENDAHULUAN” . Kepala subbab diawali
dengan nomor sesuai tingkat hirarkinya dan diikuti dengan judul subbab,

C.5 Nomor Halaman

Bagian awal skripsi menggunakan nomor halaman berupa angka
Romawi kecil (i, ii, iii, iv, dan seterusnya) yang dimulai dari sampul dalam.

233
 LAMPIRAN D PERSYARATAN FISIK DAN TATA LETAK

D.1 Margin
Batas pengetikan naskah adalah sebagai berikut :

D.2 Jenis dan Ukuran Huruf

Jenis huruf yang dipakai dalam skripsi adalah Calibri dengan ketentuan
sebagai berikut:

D.3 Spasi
Jarak standar antar baris dalam badan teks adalah satu spasi. Jarak antar
paragraf, antara judul bab dan judul subbab, antara judul subbab dan badan
teks, dan seterusnya, dapat dilihat pada masing-masing style yang digunakan dan
tersedia dalam template untuk skripsi ini.

D.4 Kepala Bab dan Subbab

Kepala bab terdiri dari kata “BAB” yang diikuti dengan nomor bab dan judul
dari bab tersebut, misalnya “BAB 1 PENDAHULUAN” . Kepala subbab diawali
dengan nomor sesuai tingkat hirarkinya dan diikuti dengan judul subbab,

D.5 Nomor Halaman

Bagian awal skripsi menggunakan nomor halaman berupa angka
Romawi kecil (i, ii, iii, iv, dan seterusnya) yang dimulai dari sampul dalam.

234
 LAMPIRAN E PERSYARATAN FISIK DAN TATA LETAK

E.1 Margin
Batas pengetikan naskah adalah sebagai berikut :

E.2 Jenis dan Ukuran Huruf

Jenis huruf yang dipakai dalam skripsi adalah Calibri dengan ketentuan
sebagai berikut:

E.3 Spasi
Jarak standar antar baris dalam badan teks adalah satu spasi. Jarak antar
paragraf, antara judul bab dan judul subbab, antara judul subbab dan badan
teks, dan seterusnya, dapat dilihat pada masing-masing style yang digunakan dan
tersedia dalam template untuk skripsi ini.

E.4 Kepala Bab dan Subbab

Kepala bab terdiri dari kata “BAB” yang diikuti dengan nomor bab dan judul
dari bab tersebut, misalnya “BAB 1 PENDAHULUAN” . Kepala subbab diawali
dengan nomor sesuai tingkat hirarkinya dan diikuti dengan judul subbab,

E.5 Nomor Halaman

Bagian awal skripsi menggunakan nomor halaman berupa angka
Romawi kecil (i, ii, iii, iv, dan seterusnya) yang dimulai dari sampul dalam.

235