Apakah ROS (Sistem Operasi Robot) wajib?

Apakah kita harus membuat ROS untuk penelitian / aplikasi robot? Apa keunggulan utama? Kapan atau dalam situasi apa ROS wajib?

Saya kembali ke komputer!

Seperti yang saya katakan di komentar ini , ROS umumnya tidak wajib. ROS adalah salah satu platform di antara banyak, terkenal sebagian besar karena Willow Garage memberikan robot gratis di beberapa titik waktu kepada siapa pun yang paling banyak menulis modul ROS. Yang mengatakan, itu bukan platform terbaik, dan tentu saja tidak ada yang terlalu istimewa. Khususnya, kontes tersebut menghasilkan banyak modul berkualitas rendah hanya untuk mendapatkan angka yang lebih tinggi.

Seiring waktu, kualitas modul ROS menjadi lebih baik dan ada banyak juga. Oleh karena itu, menggunakan ROS, Anda mendapat manfaat dari menggunakan kembali banyak dari apa yang sudah dilakukan. Anda dapat membaca di sini beberapa alasan mengapa Anda mungkin ingin menggunakan ROS.

Dengan mengingat hal itu, Anda juga harus memperhatikan efek sampingnya.

Kontrol Terdistribusi

Dengan ROS, Anda memiliki banyak node yang saling berbicara melalui jaringan. Ini kadang-kadang bagus dan mudah, tetapi umumnya menghasilkan penundaan yang sangat bervariasi dalam penerimaan pesan. Akibatnya, Anda harus memiliki penundaan kontrol yang besar untuk memastikan semua pesan masuk, yang berarti Anda tidak dapat bereaksi cepat terhadap peristiwa, yang pada gilirannya berarti Anda harus memindahkan robot Anda pada kecepatan yang lebih lambat agar tidak ketinggalan acara tersebut.

Percaya atau tidak, orang benar-benar melakukan kontrol robot melalui ROS ( MoveIt! Adalah nama dari set komponen yang relevan). Lambat. Tidak aman. Tapi mudah!

Non-waktu nyata

Bahkan ketika tidak didistribusikan, ROS bukanlah platform waktu nyata. Itu berarti Anda berada pada kebijaksanaan penuh dari kernel Linux untuk menjadwalkan tugas Anda kapan saja sesuai keinginan. Ini ok untuk beberapa aplikasi, tetapi tidak ok untuk yang lain. Jadi, Anda perlu melihat kebutuhan Anda sendiri. Apakah Anda perlu memiliki jaminan bahwa tugas Anda akan selesai dalam jangka waktu yang diketahui? Jika demikian, Anda memerlukan sistem waktu nyata.

Host Runtime Environment

Hal lain yang perlu dipertimbangkan adalah bahwa, meskipun ROS adalah protokol komunikasi umum, pada dasarnya hanya didukung untuk lingkungan yang dihosting. Hosted berarti kode berjalan di atas kernel, tidak seperti berdiri bebas yang berarti kode secara langsung mengendalikan perangkat keras (misalnya, pada mikrokontroler).

Jika aplikasi robot Anda dijalankan dekat dengan perangkat keras, dan karena itu Anda memerlukan program yang berjalan pada mikrokontroler, ROS tidak membantu Anda.

Platform Lock-in

Last but not least, pengembangan untuk ROS menghasilkan penguncian platform. Ini berarti bahwa jika di masa depan, karena satu dan lain alasan, Anda memutuskan untuk mendasarkan pekerjaan Anda pada platform robot lain, seperti OROCOS, YARP, dll, itu akan sangat menyebalkan.

Anda juga akan agak terkunci ke Linux. Linux adalah yang terbaik, tidak diragukan lagi, tetapi suatu hari nanti Anda mungkin harus mendukung sistem lain, seperti QNX, VxWorks dll, dan Anda akan mengalami masalah di sana.

Jika Anda menulis untuk mikrokontroler, lupakan ROS. Jika Anda menulis modul tingkat tinggi, saya sangat merekomendasikan menulis kode portabel. Misalnya, Anda telah mengembangkan sensor baru, dan Anda ingin menulis modul yang memperoleh data dari sensor ini, yang terhubung ke komputer Anda melalui bus CAN.

Apa yang dapat Anda lakukan dalam situasi ini adalah menulis perpustakaan independen, dengan fungsi yang dapat bekerja dengan sensor Anda dan memperoleh data. Anda bahkan bisa memikirkan menelurkan utas di perpustakaan yang memperoleh dan meminta data secara berkala.

Setelah Anda memiliki perpustakaan bantuan ini, Anda bebas menulis CLI, GUI, modul ROS, modul OROCOS, modul YARP, sambungkan ke Matlab, atau apa pun yang ingin Anda gunakan untuk berinteraksi dengan sensor Anda.

Catatan akhir: apa yang saya katakan di sini umumnya berlaku untuk semua platform robotika dan bukan hanya ROS.

"ROS" adalah istilah yang relatif, APM menjalankan kode kustom penuh yang khusus dirancang untuk kontrol quadrocopter di mana ROS kustom mungkin diinginkan agar tidak menabrak, di sisi lain Navio + berjalan pada kernel Linux dan menjalankan kode selain autopilot, dan masih berhasil mencegah crash. Kebanyakan ROS sebenarnya adalah satu set fungsi di atas OS yang ada sebagai lawan menulis os dari bawah ke atas. Seperti apa pun, itu tergantung.

Penafian: Jawaban ini entah bagaimana merupakan reaksi terhadap pos Shahbaz, sehingga memiliki bias pro-ROS.

Saya tidak berpikir bahwa ROS adalah wajib, tetapi ini adalah titik awal yang bagus dan sepadan dengan waktu untuk berinvestasi. Itu dimulai dalam Willow Garage, tetapi perusahaan ini lenyap dan ROS masih hidup, digunakan dan dikembangkan. Sebagian besar ROS sepenuhnya open source dan juga dapat digunakan secara komersial sehingga tidak mungkin ROS hilang begitu saja jika perusahaan tidak lagi tertarik dengannya. Kualitas kode tentu saja berbeda antara modul inti dan implementasi algoritma canggih yang diterbitkan oleh beberapa mahasiswa PhD dengan makalahnya.

ROS semakin cepat dalam pengaturan industri (saya akan terkejut jika ada bagian signifikan dari startup robotika di seluruh dunia yang tidak menggunakan ROS). Beberapa algoritma akan terus dipelihara dan dikembangkan oleh konsorsium industri ros dan jika Anda melihat anggotanya, ada baiknya ROS akan menjadi standar dalam industri ini:

http://rosindustrial.org/ric/current-members/

Cara didistribusikan menggunakan ROS sangat membantu untuk membuat dan memelihara paket baru, terutama dalam tim. Definisi pesan dan tindakan banyak membantu dalam mendefinisikan antarmuka sehingga perangkat keras dan algoritma dapat dipertukarkan dengan cepat. Ini juga membantu untuk mengintegrasikan anggota tim baru sebagai simpul baru akan menjatuhkan simpul lain jika rusak (asalkan tidak memakan semua RAM ..) jadi agak aman untuk mengintegrasikan sebagian node yang bekerja ke dalam sistem yang sedang berjalan karena mereka efeknya terbatas. Komunikasi menggunakan TCP yang dapat diandalkan dan cepat (pada mesin lokal), sehingga pengiriman pesan sangat cepat (beberapa ratus Hz untuk loop kontrol dimungkinkan).

Non-Real-Time

ROS saat ini tidak realtime karena sebagian besar algoritma tidak memerlukan realtime. Merasakan atau merencanakan tidak memiliki kendala waktu nyata dalam banyak kasus (berapa banyak orang yang membangun mobil self-driving berkecepatan tinggi?). Sudah cukup jika loop kontrol akhir berjalan dalam waktu nyata dan ini dalam banyak kasus dapat dilakukan secara langsung pada motor (ke mana posisi akhir dikirim misalnya via CAN). Namun, Real Time adalah salah satu tujuan inti ROS2 ( https://github.com/ros2/ros2/wiki/Real-Time-Programming ) sehingga bahkan jika Anda memerlukan ini di masa depan untuk seluruh sistem, ROS telah Anda liput .

Jika Anda benar-benar ingin menjalankan barang yang disematkan, tentu saja ada koneksi ke arduino, sehingga Anda dapat menulis pesan ROS langsung di arduino yang kemudian dikirim melalui koneksi serial.

Menjalankan ROS di Windows saat ini agak menyebalkan, tetapi karena Windows semakin dekat ke Linux (bahkan mulai memiliki sesuatu yang mirip bash), hanya tinggal menunggu waktu hingga mungkin. (Tapi siapa yang mau menjalankan robot dengan windows?)

Antarmuka dan Algoritma Perangkat Keras:

Saya pikir ini benar-benar poin kuat bagi ROS. Banyak robot yang tersedia secara komersial sudah datang dengan antarmuka ROS atau seseorang telah menginvestasikan waktu untuk mengimplementasikan antarmuka. Sebagian besar senjata komersial dapat digunakan di MoveIt sehingga sebagian besar pekerjaan untuk mendapatkan aplikasi agar berjalan dengan lengan tertentu dapat digunakan kembali dengan perangkat keras lain.

Masyarakat:

Poin kuat lain untuk ROS. Algoritma baru mendapatkan antarmuka ROS sangat cepat dan banyak orang memiliki masalah yang sama seperti Anda sehingga Anda akan menemukan seseorang untuk membantu Anda.

http://download.ros.org/downloads/metrics/metrics-report-2016-07.pdf