Saat Anda mulai mempelajari ROS, Anda biasanya ingin bekerja dengan platform fisik, dan bukan dengan model dalam simulator. Faktanya, Gazebo cukup untuk mempelajari algoritme gerakan atau hanya mengajarkan ROS itu sendiri, tetapi bekerja dengan platform nyata segera memungkinkan untuk memahami dalam praktik semua masalah dengan gerakan roda. Yah, dan seringkali platform dibutuhkan hanya sebagai prasyarat untuk proyek tersebut.
Untuk kedepannya, lebih baik memulai dengan yang ronde, karena untuk alasan yang jelas, konfigurasi seperti itu dapat memutar sumbu tanpa memperhitungkan ukuran bagian yang menonjol. Persegi panjang putar balik jauh lebih tidak nyaman, misalnya, di koridor sempit - terkadang perlu membuka 3 trik atau lebih, saya pikir pengendara akan mengerti.
Membeli platform yang sudah jadi
Tidak banyak platform siap pakai di pasaran, semuanya terdaftar di situs web ROS .
Pada saat yang sama, biaya mereka di Rusia cukup tinggi untuk mulai bekerja; opsi termurah adalah Turtlebot Burger 3 - $ 549. Kami menemukan pengecer langsung di Rusia dengan harga sekitar 90.000 rubel.
Di Cina, Anda dapat membeli dengan harga 45-50 tr ... Bagaimanapun, ini adalah platform berukuran kecil dan daya dukung, tidak mampu melakukan tugas nyata.
Anda dapat membangun platform sendiri, ada banyak panduan dan konfigurasi yang berbeda. Tapi secara rata-rata, ternyata seperti:
- Lidar kelas Slamtech A1-A2
- Roda murah berdasarkan motor kolektor dengan kotak roda gigi
- , PWM , UART + rosserial.
- Single Board Computer — Raspberry, Jetson Nano
- 2
- gmapping + amcl/rosbot_ekf + move_base
Kami tidak suka motor yang disikat karena berisik, memiliki konsumsi yang tinggi, dan diperlukan gearbox. Di sini saya harus mengatakan bahwa platform dianggap cukup berat - mis. gearbox yang saling bertautan + motor sesuatu seperti motor dari foto tidak akan berfungsi.
Karenanya, motor roda BLDC dipilih sebagai penggerak. Pilihan paling terjangkau saat ini adalah roda 6,5 hoverboard. Tetap hanya untuk mengelolanya dari ROS.
Tapi kemudian satu masalah muncul: bahkan ketika bekerja dengan robot golf , masalah yang signifikan terlihat dengan rotasi platform seperti itu dengan kecepatan rendah - robot itu berputar agak tersentak-sentak.
Alasan perilaku ini sederhana: gaya gesekan geser memainkan peran penting dalam ketahanan terhadap gerakan di belokan. Dan mereka memiliki kekhasan - resistansi tergantung pada massa dan sifat permukaan itu sendiri - itulah sebabnya baut kecil menahan struktur besar dengan 2-3 putaran pertama.
Oleh karena itu, membuat roda menyempit di tengah sehingga berputar menjadi agak sia-sia - hambatannya akan sedikit berubah. Roda karet bergesekan dengan rumput dan tanah, yang sama sekali tidak rata dan gaya dapat berubah secara dramatis, sebagai hasilnya, sesuatu seperti kotak roda gigi dibuat - dengan kecepatan rendah kami mengontrol momen di roda, dan dengan gerakan langsung - kecepatan itu sendiri.
Tampaknya saat mengemudi di atas parket atau linoleum, situasinya harus lebih baik, tetapi sayangnya, koefisien gesekannya hampir sama (ingat bahwa sepatu anti selip juga terbuat dari karet).
Dan hasilnya, robot seberat 10-15 kilogram itu sudah mulai terungkap dengan sentakan yang nyata.
Bagian kedua dari masalah ini ditambahkan oleh paket ROS diff_drive yang dikombinasikan dengan papan SBC yang agak lemah.
Berikut adalah daftar apa yang berhasil saya pahami
Manajemen dilakukan menggunakan implementasi waktu nyata, tetapi tidak memperhitungkan bahwa paket lain harus mengharapkan pendekatan ini ketika bekerja dengan manajemen.
Di sini kita harus ingat bahwa real-time bukanlah respons instan terhadap suatu peristiwa, tetapi jaminan bahwa peristiwa tersebut akan diproses pada interval waktu fisik yang dijamin. Itu. pembangkit listrik tenaga air bersyarat, diatur setiap menit (harus setiap) juga sistem real-time.
Ada kemungkinan pesan akan menyumbat topik perencana rute, dan untuk pemosisian dan subsistem perencanaan rute, perilaku ini biasanya mengarah pada penghentian dan memulai ulang aliran, atau mencoba menyesuaikan proses dengan cepat.
Akibatnya, pada SBC yang lemah , situasi muncul dengan penghitungan ulang jalur yang terus menerus, atau pencarian untuk pelokalan memakan waktu prosesor yang cukup besar - dan semakin banyak upaya yang dilakukan untuk mengikuti komponen RT, semakin banyak waktu run-up terakumulasi. Dalam bentuknya yang murni, umpan balik positif, yang dalam hal ini tidak diperlukan sama sekali.
Selain itu, pemetaan tidak mulai bekerja dengan sangat cepat dengan perubahan mendadak pada posisi platform dan lidar yang lemah - jeda hingga setengah detik diamati, yang juga sangat membingungkan perencana rute.
Motor dikontrol secara terpisah, jadi saat menggunakan SBC dan implementasi driver yang naif, roda akan dikontrol dengan beberapa penundaan.
Di sini masalahnya bahkan lebih sederhana - kita perlu mengontrol 2-4 roda melalui saluran komunikasi, yang mana. Dengan demikian, sinyal kontrol berbaris dan mulai dipancarkan satu demi satu - roda kiri, roda kanan, roda kiri, roda kanan.
Akibatnya, roda itu sendiri, dan lebih buruk lagi, posisi roda dari pembuat enkode mulai berkontribusi pada pembentukan PIC antara perencanaan jalur dan pengendalian motor.
Odometri bawaan sangat sederhana.
Karena kami tidak mencari cara sederhana untuk menyinkronkan perintah dan mengembalikan odometri - saya tidak dapat menemukannya. Sinkronisasi selalu dikaitkan dengan menunggu beberapa perintah di input, tetapi mereka tidak teratur dalam waktu dan akibatnya odometri mulai berlama-lama di output. Mungkin pembaca akan menyarankan cara mudah - di sini kami tidak menganggap diri kami seorang guru di ROS.
Kami tidak berhasil memastikan bahwa pertemuan seperti itu berjalan dengan baik. Lebih tepatnya, percepatan perpindahan dapat diremehkan menjadi 0,05-0,1 m / s ^ 2 dan kecepatan sudut menjadi 0,03 rad / s.
Saya pikir akan menyenangkan memiliki:
- Platform murah
- Kemudi roda sinkron
- Perhitungan odometri berdasarkan perilaku dan penanganan roda
- Modus gerak putar dengan kontrol berbeda
- Pembatasan berbeda dalam mode berbeda
Apa yang terjadi pada akhirnya
Kontroler diambil dari papan gyro-scooter dan kontrol roda ditulis sedemikian rupa sehingga kontrol torsi digunakan saat memulai gerakan dan berbelok. Dan jika kereta melaju lurus dan dipercepat ke kecepatan tertentu, mode kontrol kecepatan diaktifkan. Di kedua mode, data dari encoder diproses di dalam pengontrol, dengan mempertimbangkan kecepatan dan mode, dan data dikeluarkan dengan beberapa prediksi sebelum 10-15 ms.
Encoder selalu dibaca di pengontrol, terakumulasi dalam buffer 2-3 elemen dan ditransmisikan dengan penundaan. Intinya adalah ketika kontrol diterima, respons hanya berjalan setelah perintah dijalankan - mis. buffer diblokir sampai nilai encoder yang diubah diterima. Tapi odometri sedang dikeluarkan, itu hanya menggunakan nilai terakhir yang sudah dikirimkan.
Karena Semua masalah di atas bermuara pada fakta bahwa dalam hal apa pun perlu untuk menyinkronkan kontrol pada terima-transmisi sinkron dari port UART, kemudian kami menganggap tidak masuk akal untuk memperkenalkan sinkronisasi paksa ke dalam paket diff_drive, jadi kami menulis paket kontrol kami sendiri.
Itu ada di sini github.com/Shadowru/hoverboard_driver dan saat ini sedang diselesaikan secara aktif:
Paket disertakan dalam file peluncuran sebagai:
<node name="hoverboard_driver" pkg="hoverboard_driver" type="node" output="screen">
<param name="uart" value="{ }"/>
<param name="baudrate" value="115200"/>
<param name="wheel_radius" value="0.116"/>
<param name="base_width” value="0.43"/>
<param name="odom_frame” value="odom"/>
<param name="base_frame” value="base_link"/>
</node>
Porta uart itu sendiri harus memiliki hak akses yang sesuai, pada beberapa platform ia tidak selalu memiliki akses untuk pengguna. Sebagai contoh, untuk Jetson Nano di direktori hoverboard_driver / scripts / jetson_nano_serial.sh, sebuah skrip dilampirkan yang mengatur hak saat OS dimulai.
Paket itu sendiri berisi membaca aliran data dari pengontrol dan mengeluarkan informasi yang relevan dengan topik:
hoverboard_driver / hoverboard_msg dengan paket seperti hoverboard_msg
Struktur pesannya adalah sebagai berikut:
int16 state1 - informasi internal pada roda 1
int16 state2 - informasi internal pada roda 2
int16 speed1 - kecepatan sesaat roda 1
int16 speed2 - kecepatan sesaat roda 2
int16 batVoltage - tegangan baterai
papan int16Temp - suhu pengontrol
int16 error1 - wheel 1 error
int16 error2 - wheel 2 error
int32 pulseCount1 - penghitung encoder roda 1
int32 pulseCount2 - penghitung encoder roda 2
Selain itu, topik hoverboard_driver / odometry menerima pesan tipikal nav_msgs :: Odometry
Posisi dihitung sebagai berikut:
Berdasarkan parameter wheel_radius - radius roda dalam meter, base_width - jarak antara pusat roda, kami menghitung seberapa banyak setiap roda telah bergerak selama waktu antara posisi sebelumnya dan yang dibaca.
double curr_wheel_L_ang_pos = getAngularPos((double) feedback.pulseCount1); double curr_wheel_R_ang_pos = getAngularPos((double) feedback.pulseCount2); double dtime = (current_time - last_time).toSec(); double delta_L_ang_pos = curr_wheel_L_ang_pos - raw_wheel_L_ang_pos; double delta_R_ang_pos = -1.0 * (curr_wheel_R_ang_pos - raw_wheel_R_ang_pos);
Kemudian kami menghitung percepatan masing-masing roda
wheel_L_ang_vel = delta_L_ang_pos / (dtime); wheel_R_ang_vel = delta_R_ang_pos / (dtime);
Selanjutnya, kami menghitung percepatan linier robot di sepanjang masing-masing sumbu
robot_angular_vel = (((wheel_R_ang_pos - wheel_L_ang_pos) * wheel_radius / base_width) - robot_angular_pos) / dtime; robot_angular_pos = (wheel_R_ang_pos - wheel_L_ang_pos) * wheel_radius / base_width; robot_x_vel = ((wheel_L_ang_vel * wheel_radius + robot_angular_vel * (base_width / 2.0)) * cos(robot_angular_pos)); robot_y_vel = ((wheel_L_ang_vel * wheel_radius + robot_angular_vel * (base_width / 2.0)) * sin(robot_angular_pos));
Hasilnya, satu set lengkap diperoleh - percepatan linier, percepatan sudut dan mengalikannya dengan waktu - perpindahan posisi robot.
robot_x_pos = robot_x_pos + robot_x_vel * dtime; robot_y_pos = robot_y_pos + robot_y_vel * dtime;
Setelah itu, pesan odometri dikirim, ditambah terjemahan tf antara frame odometri dan base.
Pengontrol pada input dikendalikan oleh satu paket dengan 2 parameter - kecepatan dan putaran, paket ditransmisikan dari putaran hampir secara asli - kecepatan dibagi dengan keliling dan belokan diperoleh.
double v = vel.linear.x;
double rps = v / rpm_per_meter;
double rpm = rps * 60;
int16_t speed = static_cast(rpm);
dan percepatan sudut diubah menjadi perbedaan kecepatan roda dalam bentuk perkalian dengan faktor, perhitungan ulang lebih lanjut akan ditambahkan dengan mempertimbangkan dasar roda, tetapi dalam praktiknya ini hanya diperlukan untuk robot yang cukup besar dan berat.
double w = vel.angular.z;
int16_t steer = static_cast<int>(-1 * w * 30);
Hasilnya, kontrol troli yang sangat stabil dapat dicapai pada komponen yang murah.
Kami menciptakan robot, seperti sebagian besar dari Anda. Kami memiliki produk utama kami, yang sedang kami kembangkan secara aktif. Telah diuji coba dan siap untuk produksi. Ini adalah robot untuk mengumpulkan bola golf.
Kami mengembangkan robot khusus dan solusi turunannya. Terkadang ini adalah pekerjaan dari tugas teknis dan sketsa hingga produk jadi, terkadang bagian dari pekerjaan.
Dalam banyak kasus, robot membutuhkan roda untuk berinteraksi dengan dunia luar. Paling sering ini adalah motor tanpa sikat, karena kemampuan untuk mengontrol kecepatan dan posisi secara akurat.
Untuk robot kecil, roda hoverboard sering digunakan; ini dibenarkan karena produksi massal dan harga solusi ini. Siapa pun yang telah melihat daftar harga mesin Rusia pasti mengerti pentingnya produksi massal.
Adapun pengontrol, paling sering ini adalah model esc, vesc, odrive, BLD-300B, atau solusi buatan sendiri.
Untuk masuk dengan mudah dalam membuat robot sungguhan dan memecahkan kutukan Gazebo, sebagian besar pengembang membutuhkan ikan paus agar mudah masuk. Banyak hal di dunia nyata berbeda dari yang ideal.
Terkadang hal-hal yang tidak dapat diprediksi terjadi, sensor berisik, real-time, buffer overflow. Pada perangkat video ini, yang sebelumnya kami uji dengan kontaktor dan kilswitch jarak jauh.
Kami menawarkan sesuatu yang akan membantu kami menyelamatkan saraf pada waktunya, ini adalah kit untuk merakit casing (parallelepiped dan silinder), dua roda motor, baterai, pengisi daya, dan pengontrol flash yang memberikan odometri dan bekerja dengan paket ROS kami di luar kotak untuk 19.000 gosok. Ini lebih murah daripada pemotongan milling, biaya material komposit, pengencang dan roda putar yang empuk.
Hubungi kami atau ajukan permohonan platform untuk ROS online . Ayo buat robot bersama. Kami akan memberi tahu Anda
lebih banyak tentang platform ini pada pertemuan Sistem Operasi Robot pada 5 Desember. Pendaftaran peserta sudah dibuka.
→ Pendaftaran untuk pemirsa