Bagaimana saya bisa mengontrol sistem realtime cepat (200Hz) dengan sistem lambat (30Hz)?

Kami saat ini merancang robot mobile + lengan yang terpasang dengan beberapa derajat kebebasan dan sensor yang terkontrol.

Saya sedang mempertimbangkan arsitektur dalam dua bagian:

1. Seperangkat pengendali waktu nyata (baik Raspeberry Pis menjalankan RTOS seperti Xenomai atau mikrokontroler logam telanjang) untuk mengontrol motor lengan dan enkoder. Mari kita sebut mesin ini RTx, dengan x = 1,2,3 ... tergantung pada jumlah mikrokontroler. Loop kontrol ini akan berjalan pada 200Hz.

2. Mesin linux vanilla yang tangguh yang menjalankan ROS untuk menghitung SLAM, mocap, dan menjalankan logika tingkat tinggi (memutuskan tugas robot dan menghitung posisi dan kecepatan yang diinginkan motor). Loop kontrol ini akan berjalan pada 30Hz.

Saya tahu kerangka kerja saya harus dapat diukur untuk memperhitungkan lebih banyak motor, lebih banyak sensor, lebih banyak PC (mis. Untuk mocap eksternal).

Masalah utama saya adalah memutuskan bagaimana agar RTx berbeda berkomunikasi dengan PC1. Saya telah melihat makalah yang berkaitan dengan arsitektur robot (mis. HRP2 ), paling sering mereka menggambarkan arsitektur kontrol tingkat tinggi tetapi saya belum menemukan informasi tentang cara berkomunikasi tingkat rendah dengan tingkat tinggi dan dengan cara yang dapat diskalakan. Apakah saya melewatkan sesuatu?

Untuk menghubungkan mesin RT cepat yang memastikan kontrol motor dengan PC1, saya telah mempertimbangkan TCP / IP, CAN dan UART:

• TCP / IP: tidak deterministik tetapi mudah diterapkan. Apakah non determinisme merupakan masalah nyata (karena hanya akan digunakan pada kecepatan lambat 30Hz)?
• CAN: lambat, sangat andal, ditargetkan untuk mobil (telah melihat ada beberapa contoh menggunakan CAN dengan robot tetapi terlihat eksotis)
• UART: jika saya hanya memiliki satu mesin RT untuk kontrol motor saya akan mempertimbangkan UART tetapi saya kira port ini tidak skala dengan banyak RTx Apakah TCP / IP benar-benar tidak jalan karena karakteristik non-deterministiknya? Sangat mudah digunakan ...

Saat ini tidak ada solusi yang tampak jelas bagi saya. Dan karena saya tidak dapat menemukan contoh robot serius menggunakan solusi spesifik yang andal dan dapat diskalakan, saya tidak merasa percaya diri untuk membuat pilihan.

Adakah yang memiliki pandangan yang jelas tentang hal ini atau literatur yang harus ditunjukkan? Apakah ada solusi komunikasi khas atau mainstream yang digunakan pada robot?

Saya pikir Anda telah mengambil langkah pertama yang baik; Anda telah membagi masalah menjadi platform seluler (yang memiliki ketidakpastian posisi dan harus dinavigasi) dan lengan (yang memiliki kepastian posisi yang adil dalam waktu nyata, melalui penyandi).

Saya telah melihat makalah yang berkaitan dengan arsitektur robot [...] tetapi saya belum menemukan informasi tentang cara berkomunikasi tingkat rendah dengan tingkat tinggi dan dengan cara yang dapat diskalakan. Apakah saya melewatkan sesuatu?

Dari keterangan Anda, sepertinya Anda mencoba untuk mengikat setiap pengontrol RTx langsung ke PC1, yang menjalankan ROS. Apa yang Anda lewatkan adalah bahwa ROS dirancang untuk menangani sekelompok aplikasi yang dapat menghasilkan dan menggunakan data pada tingkat yang berbeda.

Apa yang dibutuhkan aplikasi Anda adalah jembatan komunikasi - antarmuka tunggal antara loop 200Hz Anda dan lingkungan ROS Anda. Dengan kata lain, bukannya mengikat setiap RTX controller untuk PC1, mengikat semua pengontrol RTX bersama-sama dan terhubung yang ke PC1.

Misalnya, gunakan Bus I2C untuk menghubungkan sistem RTx bersama-sama, dan menambahkan pengontrol RTx lain untuk menjadi "Arm Master" (AM). Tugas AM adalah menerima perintah yang masuk dalam beberapa format dan protokol ramah-PC1, dan mengonversi perintah-perintah itu ke pesan I2C. Maka Anda akan menulis aplikasi ROS untuk mengirim perintah ke AM.

Cara lain untuk melakukannya dengan I2C adalah dengan meletakkan pengontrol I2C langsung pada PC1 dan menulis semua lengan yang mengendalikan logika dalam aplikasi ROS. Ini mungkin tampak seperti cara yang lebih ramping untuk mencapai tujuan Anda, tetapi itu bisa membuat debugging lebih sulit karena Anda menghapus modularitas sistem - Anda harus memecahkan masalah itu sebagai satu sistem kompleks besar, bukan dua komponen yang mudah diuji.

Saya akan mengatakan aplikasi apa pun di mana sejumlah besar node komunikasi diperlukan (sensor atau aktuator) akan mendapat manfaat dari diimplementasikan sebagai bus sistem (berbeda dengan point to point link seperti UART atau Ethernet), karena kompleksitas kabel, determinisme dan modularitas.

Sistem kontrol apa pun membutuhkan determinisme tingkat tinggi, di mana saluran bandwidth tinggi (seperti Ethernet) biasanya buruk (terutama bila digunakan dengan OS tujuan umum yang memperkenalkan jitter penjadwalan dalam jumlah besar, lihat tautan berikut untuk diskusi tentang penjadwalan determinisme ). Prosesor aplikasi (seperti ARM11 dari Raspberry Pi) juga mungkin kurang cocok untuk sistem waktu-nyata (karena efek seperti latensi interupsi, dan lapisan pipa instruksi). Lihat diskusi digikey berikut yang membandingkan perilaku real-time dari inti aplikasi ARM vs mikrokontroler .

Sayang sekali ketersediaan BISA terintegrasi tidak seluas UART (RS-485) atau I2C (belum), karena saya pikir itu benar-benar menyederhanakan masalah penginderaan terdistribusi dan aktuasi. Dan sementara 1 Mbps yang biasa terlihat lambat, biasanya lebih dari cukup setelah kecepatan refresh semua anggota bus dihitung (dan laju transmisi selalu dapat ditingkatkan, tergantung pada panjang bus, impedansi dan apakah transceiver Anda akan mengizinkannya). Ada juga perangkat lunak simulasi brilian yang tersedia, yang pada dasarnya menjamin waktu respons kasus terburuk (misalnya RealTime-at-work memiliki penganalisa bus CAN gratis yang disebut RTaW-Sim). Dan akhirnya, tampaknya ketersediaan sensor MEMS dengan CAN terintegrasi agak buruk.

Contoh lain di mana aktuator dikonfigurasikan sebagai bus (atau cincin), adalah Dynamixels AX dan MX series, di mana setiap motor dihubungkan secara berantai ke yang berikutnya melalui tautan UART. Ini sangat menyederhanakan desain sistem jika Anda memiliki sejumlah besar aktuator.

Tetapi, untuk kembali ke pertanyaan yang sebenarnya, saya pikir jika Anda menggambarkan sistem Anda sebagai titik setel waktu-nyata, alih-alih perintah (mis. Agak terus menerus menyiarkan sudut motor daripada menginstruksikan perintah seperti sudut goto), itu menyederhanakan penggabungan antara loop 200 Hz dan 30 Hz.

Anda tampaknya memiliki 2 masalah yang terpisah (namun terkait) yang Anda coba selesaikan secara bersamaan. Mari kita pecahkan teka-teki Anda menjadi potongan-potongan kecil:

1. Bagaimana cara saya mengkomunikasikan perintah dari sistem yang lambat (30Hz) ke pengontrol cepat (200Hz), dan bagaimana cara berkomunikasi data yang diterima pada 200Hz kembali ke thinktank 30Hz saya?
2. Bagaimana cara mengontrol apa yang terjadi pada 200Hz, ketika saya hanya bisa memberi tahu robot apa yang harus dilakukan pada 30Hz?

Butir 1 dapat diselesaikan dalam perangkat keras karena pertanyaan awal Anda tampaknya menunjukkan-Anda dapat mengantri data pada 200Hz dan mengirim paket pada 30Hz ke sistem tingkat yang lebih tinggi. Anda dapat melakukan ini dengan TCP / IP, atau mungkin BISA tergantung pada berapa banyak data yang ingin Anda kirim. Perangkat keras yang berbeda memiliki kecepatan data maks yang berbeda. Menambahkan tingkat arsitektur seperti ROS untuk bertindak sebagai jembatan / arbiter komunikasi seperti yang disarankan dalam posting lain juga dapat membantu.

Butir 2 adalah masalah teori kontrol yang tidak dapat diselesaikan dengan perangkat keras saja. SLAM, penentuan posisi dan kecepatan, dan penentuan tugas yang Anda inginkan harus lebih pintar karena mereka lebih jarang mengirim dan menerima informasi. Anda mungkin menginginkan 2 loop kontrol : 1 pada 200Hz dan 1 pada 30Hz.

Ada banyak pertanyaan lain yang mencakup putaran kontrol umpan-maju, umpan balik, dan PID, tetapi Anda secara khusus bertanya tentang skalabilitas-cara skala sistem yang paling besar adalah dengan melapiskan loop kontrol dan logika sehingga informasi minimal yang diperlukan melintasi perangkat keras apa pun Anda berakhir dengan. Misalnya, pengontrol tingkat atas Anda mungkin hanya memberikan poin posisi tujuan dan kecepatan sasaran rata-rata ke level yang lebih rendah, bukan mengubah kecepatan 30 kali per detik.