Seberapa matang pemrograman waktu nyata dalam robotika? [Tutup]

20

Sunting: Saya tidak tahu mengapa, tetapi pertanyaan ini tampaknya membingungkan banyak orang. Saya mengetahui kapan / di mana / mengapa / bagaimana menggunakan waktu nyata. Saya tertarik mengetahui apakah orang yang memiliki tugas waktu nyata benar-benar cukup peduli untuk menerapkannya dalam waktu nyata atau tidak.

Tidak perlu menyebutkan mengapa operasi real-time penting untuk robot. Namun pertanyaan saya, berapa banyak sebenarnya digunakan dalam robotika?

Ambil contoh pertanyaan ini . Hanya satu jawaban yang menyebutkan platform apa pun dengan kemampuan waktu nyata, dan itu juga jauh dari atas. ROS rupanya, menjadi platform yang sangat populer yang tidak real-time.

Namun di dunia real-time, RTAI 1 tampaknya menjadi satu-satunya platform penggunaan real-time gratis yang bisa diterapkan . Namun demikian, terbatas pada Linux (tidak ada masalah), didokumentasikan dengan buruk dan dikembangkan dengan lambat.

Jadi, berapa banyak perilaku waktu nyata dicari di antara pengembang robotika?Pertanyaannya adalah, seberapa banyak pengembang cenderung untuk menulis aplikasi real-time ketika perilaku real-time sebenarnya dibutuhkan? Jika tidak banyak, mengapa?

Misalnya, perilaku refleksif berdasarkan data taktil, tidak dapat melalui ROS karena akan kehilangan properti waktu nyata. Tetapi apakah orang benar-benar menghasilkan solusi waktu nyata atau tetap menggunakan ROS, mengabaikan properti waktu nyata?

1 atau lebih tepatnya Xenomai

software platform real-time Shahbaz
sumber
1
Saya pikir ini adalah pertanyaan yang bagus. Pertimbangkan membaginya menjadi dua dan mengklarifikasi pertanyaan utama Anda. 'Bisakah ROS digunakan secara real-time?' atau 'Apakah ROS digunakan dengan waktu nyata?' (2 pertanyaan berbeda) terpisah dari pertanyaan utama Anda.
hauptmech
@hauptmech, well ROS tentu saja tidak dapat digunakan secara real-time, karena tidak!
Shahbaz
Saya setuju dengan @hauptmech. Pertanyaannya membingungkan. Di atas Anda bertanya, berapa banyak orang / seberapa sering sistem real-time digunakan dan kemudian Anda bertanya kapan / dalam hal ini . Keduanya adalah pertanyaan yang bagus, jadi tolong bagi menjadi dua atau kurangi menjadi satu. Terima kasih!
bit-bajak laut
@ bit-bajak laut, saya tidak mengerti mengapa Anda mengatakan bahwa saya bertanya kapan / dalam hal ini . Saya tidak pernah menanyakan hal seperti itu. Seperti yang saya katakan , pertanyaannya adalah, seberapa banyak pengembang cenderung untuk menulis aplikasi waktu nyata ketika perilaku waktu nyata sebenarnya diperlukan? Dengan kata lain, berapa persen aplikasi yang memang membutuhkan perilaku waktu-nyata, yang sebenarnya diimplementasikan dalam waktu-nyata? Saya pribadi tahu kapan dan dalam hal mana perilaku waktu nyata diperlukan dan sama sekali tidak memiliki pertanyaan mengenai hal itu. Bahkan, saya terkejut melihat jawaban yang menjelaskan itu .
Shahbaz
Terimakasih atas klarifikasinya! Bagi saya, judul itu membingungkan. IMO pemrograman + implementasi real-time sudah matang dalam Robotika, tetapi melibatkan lebih banyak upaya (waktu, uang, keterampilan dll), sehingga kebanyakan orang menghindarinya, ketika itu tidak benar-benar diperlukan.
bit-bajak laut

Jawaban:

10

Ingatlah bahwa ada Waktu Nyata dan ada Waktu Nyata .

Hard Real time sulit untuk diraih tanpa dukungan perangkat keras atau perangkat lunak tingkat rendah, tetapi Anda seringkali tidak membutuhkan semuanya untuk menjadi Hard Real Time . Respons Real & Soft Time Firm jauh lebih mudah untuk dicapai dan seringkali lebih dari cukup untuk banyak aplikasi.

Juga, berbagai bagian sistem dapat memiliki persyaratan waktu nyata yang sangat berbeda . Jika Anda menjalankan loop PID perangkat lunak, mereka benar-benar harus memiliki respons waktu nyata yang sulit (Anda benar-benar tidak ingin harus memilih antara menyetel lembut PID Anda atau menyetelnya dengan keras dan membuatnya kadang-kadang menjadi tidak stabil, misalnya). Sistem visi mungkin memiliki persyaratan respons waktu nyata yang tegas , kinerja akan menurun jika Anda tidak dapat memproses gambar pada waktunya untuk keputusan berikutnya, tetapi itu tidak perlu mencegah sistem berjalan, dalam hal ini jika Anda tidak dapat memprosesnya pada waktu Anda lebih baik membuang hasil parsial dan tidak kehilangan waktu memulai analisis pada frame berikutnya. Akhirnya, perencanaan dan koordinasi keseluruhan Anda (mungkin yang paling rumitbagian dari sistem robot Anda) sering dapat tetap kuat dalam domain waktu nyata lunak .

Bahkan di ranah PC Windows Anda bisa mendapatkan kinerja waktu nyata yang sulit , Anda hanya perlu perangkat lunak yang tepat dengan kait yang tepat ke dalam kernel. TwinCat soft PLC dari Beckhoff dengan gembira menjalankan PLC tingkat pemindaian tinggi dengan memotong setengah dari siklus mesin Pentium, memberikan separuh lainnya ke Windows NT, dan ini lebih dari satu dekade yang lalu. Bahkan sistem kontrol modern seperti beberapa opsi dalam rentang A3200 Aerotech melakukan pekerjaan kasar pada PC host, dengan kernel level rendah mengambil sebanyak waktu CPU yang diperlukan untuk persyaratan waktu nyata yang sulit dan meninggalkan sisa siklus CPU untuk Windows 7 menggunakan!

Mark Booth
sumber
Perbedaannya di sini cukup relevan ... bahkan dalam sistem tingkat rendah "dunia nyata", bit waktu nyata benar-benar cukup kecil (berdasarkan pada timer tick interrupt) sedangkan sebagian besar sistem secara nominal waktu-nyata (tetapi + / - beberapa nano-detik di sana-sini ditoleransi). Saya tersenyum ketika saya melihat orang-orang berbicara tentang aplikasi waktu nyata yang dibangun pada WindowsCE atau Linux ...
Andrew
1
Seperti yang saya katakan @Andrew dengan perangkat lunak yang tepat, bahkan Windows 7 dapat dibuat sulit real time dengan RTX . Tidak yakin mengapa Anda tidak menganggap Windows CE sebagai real-time, itu sudah penjadwalan tugas deterministik real-time karena versi 2 dan Linux dapat dibuat realtime dengan kernel seperti RTLinux .
Mark Booth
Hai lagi Tandai (tidak yakin siapa yang menguntit siapa di sini ...) - Saya setuju bahwa Anda dapat melakukannya, tetapi pengalaman keras telah menunjukkan bahwa dalam banyak (? Sebagian besar) kasus, pengguna (manajer) mengabaikan pengaya yang diperlukan dan menganggap bahwa sistem vanila akan melakukannya.
Andrew
@Andrew - Pengalaman saya dengan RTX hanya berhasil . Kembali di Pentium 4 hari Anda harus berhati-hati untuk tidak menggunakan grafik atau audio terintegrasi yang memenuhi bus PCI, tapi itu seharusnya tidak menjadi masalah akhir-akhir ini.
Mark Booth
Sudah lama, tetapi membaca kembali halaman ini, terutama yang berkaitan dengan windows, saya hanya ingin mengatakan Anda menyebutkan hanya bagian dari bagaimana suatu sistem dibuat secara realtime. Penjadwalan waktu nyata itu penting tentu saja, tetapi ada segala macam hal yang dapat menghasilkan lonjakan yang juga perlu ditangani untuk membuat sistem waktu nyata. Interupsi adalah contoh umum, SMI, cache dan bandwidth memori adalah contoh lainnya. Hanya karena ada penjadwal waktu nyata tidak membuat sistem waktu nyata.
Shahbaz
8

Sistem waktu nyata sebenarnya tidak diperlukan untuk banyak sistem kontrol robot (kebanyakan?). Selama Anda memiliki loop kontrol yang berjalan cukup cepat, dengan jitter yang cukup rendah, dan tidak melewatkan siklus terlalu banyak, maka ini cukup memadai untuk kontrol dan servo robot.

Sebagai bukti dari ini, izinkan saya menyajikan PR2 dan Bayangan Robot Tangan:

PR2

Robot ini memiliki sekitar 20 derajat kebebasan, yang semuanya diservis melalui loop utama ROS. Atau bagaimana dengan Shadow Robot Hand, yang juga memiliki 20 DOF, ditambah sejumlah taktil dan sensor lainnya, dan juga diservis melalui loop utama ROS.

Loop utama ROS menderita sedikit jitter, kadang-kadang sebanyak 100us, dan bahkan terkadang melewatkan siklus sama sekali. Tetapi tidak masalah jika 99,9% dari siklus dieksekusi dengan sukses.

Penggunaan banyak core di dalam PC host berarti bahwa satu inti penuh didedikasikan untuk menjalankan loop utama, sehingga sangat jarang ditunda oleh tugas-tugas lain.

Alasan utama untuk menggunakan OS yang benar-benar real-time untuk sistem robot adalah untuk keamanan. Jika robot bekerja dalam situasi kritis keamanan, maka itu adalah tanggung jawab Anda untuk menjamin kontrol 100% up-time, dan bagian dari ini adalah jaminan sifat waktu nyata itu.

Apakah Anda menggunakan OS real-time atau tidak, servos Anda harus melakukan sesuatu yang aman jika loop kontrol mati sepenuhnya. Sistem keamanan ini juga akan sangat membantu jika OS non-real-time Anda melompat lebih dari satu siklus. Misalnya, pada Shadow Hand, motor dihentikan jika loop kontrol meleset lebih dari 20 siklus (20 ms). Saya belum pernah melihat ini terjadi.

Ditambahkan

Cara lain untuk memikirkannya adalah ini: Berapa tingkat pembaruan yang dibutuhkan oleh sistem servo Anda? Jika itu lengan yang besar, dan tidak perlu kinerja super tinggi, penentuan posisi kecepatan tinggi, maka 500Hz mungkin cukup. Untuk berkeliling, 200Hz mungkin cukup. Dalam kedua kasus ini, jika loop Anda benar-benar berjalan pada 1000Hz, maka siklus yang terlambat atau hilang benar-benar tidak ada masalah sama sekali, selama algoritma kontrol Anda memperhitungkan waktu sebenarnya yang telah berlalu antara loop.

Roket
sumber
Jadi singkatnya, Anda mengatakan bahwa real-time sering tidak digunakan, karena perangkat lunak non-real-time bekerja "cukup baik"?
Shahbaz
@ Shahbaz - Saya tidak bisa mengomentari seberapa sering itu benar-benar digunakan, tetapi saya dapat mengatakan bahwa jika digunakan, maka itu mungkin tidak perlu. Kami dulu menggunakan RTAI, lalu meninggalkannya karena itu sebenarnya lebih menghambat daripada membantu.
Rocketmagnet
1
Saya ingin menekankan satu hal: Anda memiliki begitu banyak kekuatan pemrosesan pada PR2 sehingga Anda mungkin mendapatkan sesuatu yang "cukup baik". Saya bekerja pada robot dengan "hanya" Core2 Duo. Itu bukan pilihan di sana: tumpukan lengkap mengambil setiap inti 100% sebagian besar waktu. Di sini, Rock (Orocos) dan RT-Linux diperlukan untuk menahan loop kontrol 1kHz bersama.
sylvain.joyeux
@ sylvain.joyeux - Saya setuju. ROS berkinerja sangat buruk untuk kontrol ketika Anda hanya memiliki 2 core.
Rocketmagnet
@Rocketmagnet Saya minta maaf harus membatalkan yang satu ini, tetapi bagian PR2 salah. Pada PR2 terdapat loop real-time tunggal yang berjalan pada 1000Hz paralel dengan ROS (di Linux + RT PREEMPT), yang berkomunikasi melalui Ethercat dengan papan pengontrol motor, melakukan kontrol motor aktual dari masing-masing DOF. Anda harus berhati-hati ketika memprogram pengontrol (mis. Pengontrol lintasan gabungan) agar tidak rusak waktu-nyata dan mereka juga memiliki alat khusus untuk mengelolanya (mis. Memuat / membongkar mereka). Lihat di sini untuk detail lebih lanjut.
bit-bajak laut
4

Tujuan dari perangkat lunak menentukan apakah perlu benar-benar waktu nyata.

Di mana tujuannya adalah perencanaan jalur atau lokalisasi, seringkali frekuensi rendah cukup, misalnya, 10Hz. Dalam kasus ini, pengaturan pemain / stage yang berjalan di Linux baik-baik saja. Kita dapat melihat bahwa ada beberapa masalah jika satu langkah waktu sedikit lebih lama atau lebih pendek.

Perilaku real-time yang ketat diperlukan jika dinamika robot cepat. Misalnya, menggerakkan lengan robot untuk melacak posisi, atau untuk menangani / menggenggam objek, dan memindahkannya. Jika langkah waktu terlewati, posisi mungkin melampaui overshoot, dan kami mungkin ingin perilaku yang lebih dapat diprediksi. Dalam hal ini, kami mungkin memiliki frekuensi hingga 1kHz atau lebih. Jika sistem operasi digunakan, kami menginginkan sistem operasi waktu nyata.

Perilaku real-time dapat dicapai dalam aplikasi tertanam, dengan menggunakan timer dan interupsi (kode C dikompilasi pada mikrokontroler). Dalam hal ini, kita harus memastikan bahwa beban pemrosesan tidak terlalu tinggi sehingga frekuensi pengambilan sampel yang teratur dapat dipertahankan.

Robot yang menggunakan komputer / mikroprosesor (karena lebih banyak daya pemrosesan diperlukan), perlu menggunakan sistem operasi waktu nyata untuk menjamin tingkat pengambilan sampel yang tinggi.

Oleh karena itu, apakah perilaku waktu-nyata diperlukan tergantung pada tujuan pengembang menggunakannya.

ronalchn
sumber
Terima kasih balasannya. Mungkin pertanyaan saya perlu kata-kata yang lebih baik, tetapi saya tidak ingin bertanya "kapan harus menggunakan real-time", tetapi "seberapa sering orang benar-benar menggunakan real-time ketika real-time diperlukan". Namun demikian, perilaku real-time Anda pada mikrokontroler, tanpa perlu platform waktu nyata adalah poin bagus yang belum saya pertimbangkan.
Shahbaz
Sebagai catatan, waktu nyata dan cepat adalah dua konsep ortogonal. Jika perencana jalur harus memutuskan secara ketat dalam satu menit, maka itu adalah aplikasi waktu nyata. Meskipun saya mengerti mengapa Anda menyebutkan robot cepat.
Shahbaz
2

Perusahaan kami membuat robot menggunakan FreeRTOS yang berjalan di mikrokontroler PIC. Bagi kami, alasan utama untuk menggunakan FreeRTOS adalah kemudahan mengatur ulang prioritas pada tugas, menangani beberapa jalur komunikasi secara bersamaan, dan komunikasi yang mudah antara interrupt handler dan tugas utama. Mikrokontroler jauh lebih murah daripada menempatkan mesin linux penuh ke dalam setiap robot yang kami hasilkan juga.

Berbunyi nyaring
sumber
2

Jika Anda benar-benar membutuhkan waktu nyata, maka Anda menggunakan sistem operasi waktu nyata. Pemantauan keamanan, akuisisi data, dan loop kontrol laju sampel konstan adalah subsistem umum yang menggunakan penjadwalan waktu-nyata.

Bagian real-time dari pemrograman biasanya sekecil mungkin, karena lebih sulit untuk di-debug dan lebih sedikit kode lebih mudah untuk memeriksa kebenarannya. Dokumentasi pada OS waktu-nyata biasanya cukup bagus (termasuk RTAI / Xenomai).

Saya telah menggunakan QNX dan RTAI-> Xenomai di berbagai proyek robotik sungguhan . Saya lebih suka QNX tetapi Xenomai sama efektifnya.

hauptmech
sumber
2

Orocos adalah kerangka kerja perangkat lunak kontrol robotika real-time yang matang. Saya telah melihatnya digunakan untuk berhasil mengendalikan manipulator robot kecepatan tinggi dengan persyaratan waktu nyata yang sulit. Ini memiliki banyak komponen tingkat kerangka kerja yang sama seperti ROS, komunikasi, konfigurasi, serialisasi, dan pengemasan berbasis komponen.

Joe
sumber
2

Mulailah berpikir tentang robot Anda dalam beberapa CPU dan pergantian pertanyaan waktu nyata. Jika Anda memiliki algoritme yang membutuhkan umpan balik kecepatan tinggi yang dapat diandalkan seperti penyeimbang roda dua atau stabilizer quad-copter atau pulsa servo, waktu nyata sangat penting, tetapi tugas itu juga sangat terbatas.

Anda dapat melepaskan loop kontrol seperti ini ke CPU real-time khusus seperti AVR 8 bit yang murah atau ARM 32 bit low-end yang ditemukan di kelas perangkat Arduino. Tidak ada yang mencegah Anda menambahkan banyak lusinan MCU kecil ini yang menjalankan loop kontrol khusus, enumerasi perangkat USB bahkan membuatnya mudah.

Sekarang setelah Anda memiliki loop kontrol sensitif waktu yang ditangani oleh CPU khusus, Anda dapat mengendurkan kebutuhan waktu nyata dari 'otak' robot yang dapat menjalankan logika ujung yang lebih tinggi menggunakan komponen seperti ROS di Linux atau Kinect untuk Windows.

Jay Beavers
sumber
0

Menanggapi "kapan / dalam hal ini" sistem waktu nyata digunakan:

Dalam pengalaman saya, kontrol gerak adalah aplikasi utama untuk sistem real-time. Untuk mengendalikan motor, frekuensi tinggi (100 hz, 1000 hz, dan lainnya) dan jitter rendah (variasi waktu) adalah penting. Keamanan adalah poin besar di sini. Pertimbangkan sebuah robot di antara manusia: Misalnya, Anda ingin / perlu memastikan bahwa robot (lengan) berhenti dalam jangka waktu / jarak tertentu.

Untuk tugas-tugas lain seperti perencanaan jalur, pemrosesan visi, dan sistem penalaran waktu-nyata tidak begitu penting dan sering dihindari karena overhead dalam waktu pengembangan dan biaya perangkat keras.

Saat ini, robot besar seperti PR2 menggabungkan kedua dunia. Dalam konteks real-time dari sistem operasi yang diaktifkan RT (mis. Linux + Xenomai) kontrol gerakan sedang terjadi dan di bagian non-real-time (lahan pengguna), pemrosesan dan perencanaan visi tertanam dalam sistem seperti ROS. Keduanya dapat berjalan di komputer yang sama.

Saya senang mengedit jawaban ini, setelah pertanyaannya diklarifikasi. :-)

bit-bajak laut
sumber
0

Ya, dengan asumsi sumber daya perangkat keras dapat memenuhi persyaratan waktu (daya pemrosesan yang cukup, latensi yang cukup rendah), ketika penjadwal tidak dapat mengurutkan proses dan utas dengan tepat, maka orang menggunakan penjadwal waktu-nyata, biasanya dilampirkan ke kernel yang secara khusus dioptimalkan untuk tantangan ini. Driver perangkat keras juga dapat dioptimalkan untuk kondisi waktu-nyata.

Ya, jika perangkat lunak yang tidak dapat dijamin untuk melakukan pekerjaannya dalam batasan waktu yang diperlukan, maka orang menggunakan pendekatan real-time.

hauptmech
sumber
0

Salah satu solusi yang baik adalah dengan melakukan KEDUA. Sebuah desain yang saya gunakan tempat fungsi "keras" waktu nyata pada pengontrol mikro kecil, loop kontrol servo ketat dan semacamnya. Lalu ada CPU lain yang lebih besar, menjalankan Linux dan ROS. Saya membiarkan ROS menangani tugas tingkat yang lebih tinggi dan uP menangani hal-hal seperti mengendalikan motor stepper atau menjalankan loop PID.

Seperti dikatakan di atas oleh orang lain, Anda BISA mengizinkan OS non-real-time untuk menjalankan loop kontrol 1KHz tetapi agar ini berfungsi, Anda memerlukan komputer berukuran terlalu besar yang menghabiskan sebagian besar waktunya dalam loop kosong. Jika Anda menjalankan komputer Linux / ROS pada utilisasi CPU mendekati 100% kinerja real-time buruk. Menggunakan desain dua tingkat memungkinkan Anda untuk selalu mendapatkan kinerja RT yang sangat baik dan juga menggunakan komputer yang lebih kecil, lebih haus daya (mungkin tugas tingkat tinggi Pi2.) UP saya saat ini tidak menjalankan OS apa pun tetapi saya pindah ke FreeRTOS

pengguna3150208
sumber