Di bagian pertama kita sudah mengetahui apa itu MAVLink dan bagaimana karakteristik protokol tersebut. Meski tidak terlalu panjang, paling tidak kita memahami struktur data dan cara kerja singkat dari protokol MAVLink v1.
Pada bagian ini kita akan meneruskan pembacaan data byte ke-7 dan seterusnya. Agar kita mengingatnya kembali, data yang kita bahas di bagian pertama adalah sebagai berikut:
fe1cad010121351a06009b244afc75768b3fe6a50000daedffffc60062f6f8ffd76b2267
Enam byte pertama yakni fe 1c ad 01 01 21 sudah kita singgung sebelumnya, maka data selanjutnya adalah:
351a06009b244afc75768b3fe6a50000daedffffc60062f6f8ffd76b2267
Sebelum kita mengetahui isi informasi daripada data tersebut, pertama yang harus kita lakukan adalah mengetahui data apa itu sebenarnya. Cara mengetahuinya adalah dengan membaca nomor identitas pesan atau msgid yang ada pada byte ke-6 dari 6 byte pertama dan berapa panjang data informasi tersebut.
Panjang Data
Jika kita kembali pada pembahasan bagian pertama, diketahui bahwa panjang data adalah 28 byte. Untuk mengetahuinya pun mudah, hanya dengan mengkonversi byte kedua dari Hexa ke Desimal. Nilai 28 byte dihitung sejak byte ke-7. Agar lebih jelas, simak kembali tabel berikut:
Byte ke-2 adalah payload length. Dimana payload dimulai dari byte ke-7. Apakah benar isi dari payload sebanyak 28 byte? Kita akan hitung manual sebagai berikut:
Benar, kan? Total keseluruhan adalah benar 28 byte. Mungkin ada yang bertanya, kemana 2 byte terakhir dari satu frame tersebut? Dua byte terakhir adalah checksum. Fungsinya adalah sebagai bentuk pengamanan dari kerusakan data saat transmisi berlangsung. Apabila hitungan checksum saat data diterima tidak cocok dengan checksum yang diberikan, maka bisa dipastikan data tersebut bermasalah. Bisa karena rusak karena pengaruh Layer 1, atau ada ulah hacker. Ulasan mengenai checksum di protokol MAVLink tidak dibahas disini, tetapi akan dibahas di lain waktu apabila ada kesempatan.
Identitas Pesan
Alias msgid sebagai tanda pengenal payload apa yang dimuat. Baik, langsung saja kita menuju byte ke-6 yang dengan nilai 0x21. Hasil konversi ke desimal adalah 33. Jika kita merujuk pada web ini maka kode 33 adalah nomor identitas data GPS. Berikut keterangannya:
Sejauh ini kita sudah mengetahui banyak hal soal ini. Pertanyaan yang muncul, jika kita sudah mengetahui jenis data apa yang disampaikan, kita juga tau panjang datanya, jenis protokolnya, lantas apa informasi yang sebenarnya disampaikan?
Cryptii
Cryptii adalah aplikasi berbasis web yang menawarkan fungsi konversi modular, penyandian, dan enkripsi secara online. Seluruh proses konversi data yang kita kehendaki dilakukan sepenuhnya oleh browser disaat kita mengakses web tersebut. Web ini didukung oleh Wierk Studio yang berlisensikan dari MIT.
Ya, benar, kita akan menggunakan bantuan dari layanan web ini untuk membaca payload MAVLink itu. Hal yang mesti diperhatikan adalah dari byte mana kita konversikan dengan tool tersebut? Semua atau sebagian? Jawabannya adalah dimulai dari byte ke-7, atau byte dimana dimulainya payload. Bagaimana dengan 2 byte terakhir? Checksum untuk hal ini boleh diikutkan, boleh tidak.
Pertama kita konfigurasi tool dari Cryptii tersebut. Panel sebelah kiri atau panel "View", ganti "Text" menjadi "Bytes". Muncul kotak dropdown di bawahnya, pastikan untuk bagian "Format" dipilih "Hexadecimal", dan pada dropdows "Group By" maka pilih "Byte".
Lanjut di panel bagian tengah atau panel kedua, pada menu dropbox pertama pilih "Integer". Di menu dropbox setelahnya, tepatnya bagian "Format" pilih dengan "Decimal". Untuk bagian "Type", pilih "32-bit signed integer (I32)". Kemudian di bagian "Byte Order" pilih "Little-Endian". Tampilannya kurang lebih seperti ini:
Lanjut konfigurasi pada panel ketiga. Menu dropdown yang tersedia, kita pilih "Text". Jadinya seperti ini:
Kembali ke panel pertama, copy-paste kan data payload dari byte ke-7 sampai terakhir ke dalamnya. Checksum pada dua byte terakhir boleh tidak diikutkan karena tidak memengaruhi. Maka panel ketiga adalah data yang sudah bisa dibaca langsung oleh manusia. Tentunya masih dengan kaidah-kaidah pembacaan yang benar. Mestinya kita dapatkan tampilan seperti ini:
Bagaimana? Bingung? Jika ada yang belum dimengerti, silahkan tulis pertanyaan di kolom komentar atau hubungi langsung melalui email dan Telegram yang tertera di bagian akhir blog ini.
Data GPS
Cara membaca data yang sudah di tampilkan di panel ketiga adalah dengan mencocokkan tabel yang tertera pada sub-bab "Panjang Data" di atas. Jika kalian bingung maksudnya bagaimana, lihat gambar di bawah ini:
Mulai paham? Baik, kita tidak perlu pusing dulu dengan apa itu time_boot_ms, alt, relative_alt, dll. Kita sudah ketahui sebelumnya bahwa data itu adalah data GPS. Apa yang umumnya orang pakai pada GPS adalah Latitude dan Longitude saja. Maka kita perhatikan langsung pada bagian lat dan lon. Tipe datanya adalah integer 32 bit atau berarti data berukuran 4 byte, dengan Unit atau satuan degE7. Maksud dari degE7 adalah 7 angka di belakang koma. Atau bisa kita pahami yaitu dengan memberikan koma setelah 7 angka dari belakang.
Di panel ketiga, data lat dan lon secara berurutan adalah -62249829 dan 1066104437. Apabila kita berikan koma setelah 7 angka dari belakang maka hasilnya adalah -6,2249829 dan 106,6104437. Dengan cara ini kita akan coba copy-paste data koordinat GPS tersebut ke Google Maps. Hasilnya:
Kita bisa bayangkan bahwa posisi UAV atau Drone atau mungkin mobil autonomous yang kita kendalikan dari jarak jauh, sedang berjalan melewati jalan toll Tangerang, entah sedang menuju Jakarta atau menuju arah toll Merak.
Bagus, sekarang kita punya pertanyaan. Ke arah mana data GPS tersebut? Jawabannya adalah pada byte terakhir dari payload yang kita gunakan sebagai contoh di atas. Byte terakhir atau data terakhir pada perbandingan tabel di atas merupakan data heading alias arah hadap dari objek wahana. Atau bisa juga arah hadap kompas yang ada pada GPS. Permasalahannya adalah, jika kita bandingkan langsung seperti cara di atas, maka data tidak cocok.
Lantas bagaimana cara mencocokkannya? Akan kita bahas di artikel selanjutnya, artikel bagian 3.
![Komunikasi Serial Raspberry Pi 3B Menggunakan OS Linux OpenSUSE [Native Serial Port]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCo5ytrcoyejQd9K4E9URUR26IB0WXYZYDxlWgOuXKi8o0LTaIk8JHs0LZSCphI9-0dPQ27Pb4WJO7MXMHc-ZLfUVOSKOcXjAzcJsPcaLSqn4s7wBBbCyI1mJmsbz9PEyyzCI8wsmj_BE/w100/image.png)
0 Komentar