Merancang robot layanan. Pernyataan masalah, arsitektur solusi

Kami dengan tim ( yang dapat Anda bergabung ) dari orang-orang yang berpikiran sama dari Habr sedang mengembangkan robot untuk mengumpulkan bola golf di driving range .



Vladimir Goncharov Shadow_ru berbicara tentang mengumpulkan persyaratan, merumuskan tugas untuk pekerjaan, mengembangkan arsitektur dan membuat prototipe untuk menjalankan perangkat lunak.



Proyek ini dimulai untuk saya, dengan pengumpulan persyaratan, generalisasi dan dekomposisi subtugas berikutnya. Tugas untuk robot pada pandangan pertama adalah sederhana, tetapi kesalahan pada tahap perencanaan sangat merusak hasil pekerjaan dan tidak selalu terlihat dengan segera, jadi melewatkan tahap ini adalah cara ke mana-mana.

Merangkum persyaratan menyederhanakan komunikasi dengan anggota tim lainnya - pemahaman bersama tentang masalah dikembangkan, situasi ketika setiap robot di kepalanya tidak lagi muncul. Juga, ketika anggota baru memasuki tim, cukup untuk membaca dokumen serupa, yang mengurangi waktu untuk fase entri.

Selalu ada keseimbangan antara persyaratan pengumpulan dan generalisasi - Saya ingin menjelaskan secara lebih rinci, tetapi jika Anda bukan pengacara yang terbiasa bekerja dengan ratusan paragraf terkait - ini tidak akan menyelesaikan masalah penglihatan umum. Tentu saja ada pendekatan yang tepat ketika beberapa irisan persyaratan dibuat untuk anggota tim yang berbeda dan pelanggan dan kontraktor eksternal. Tetapi untuk sekarang, ini jelas tidak perlu, karena Setiap perubahan dalam persyaratan akan mengarah pada investasi waktu yang serius untuk memperbarui irisan tersebut, yang tidak mempengaruhi produktivitas startup dengan baik.

Untuk saya sendiri, saya memutuskan untuk memecah menjadi persyaratan fungsional dan non-fungsional dan memasukkan semuanya ke dalam satu halaman A4. Versi pertama keluar seperti ini:

Fase 1. Pernyataan masalah

Tantangan: Jalan memutar maksimal yang berkesinambungan dari lapangan golf pelatihan diperlukan dalam kondisi iklim yang sulit untuk mengumpulkan bola.

Masalah: Kendaraan Darat Tanpa Awak ( UGV ) diperlukan untuk melakukan misi siklik untuk memotong ruang yang ditentukan oleh perimeter dengan koordinat titik-titik dalam notasi WGS-84.

Misi harus mencakup operasi berikut:

1. Normal mulai dari posisi rumah yang dikenal
2. Darurat mulai dari posisi yang tidak diketahui sebelumnya (mulai setelah operasi WD, perlindungan daya, dll.)
3. Menghindari area dengan cakupan setidaknya 98% dari ruang untuk 1 balapan atau lebih (mulai memotong lapangan lagi setelah mengisi hopper setelah 15 menit tidak diperlukan)
4. Kembali ke posisi semula untuk mengisi hopper, menguras baterai, mengakhiri jalan memutar
5. Berlomba di platform peluncuran untuk mengatur ulang bola, isi daya baterai

Versi algoritma yang disederhanakan



Selain itu, UGV harus memenuhi persyaratan berikut:

1. Jangan meninggalkan perimeter yang ditentukan saat berkendara di sekitar perimeter yang ditentukan
2. Posisi rumah mungkin di luar batas yang ditentukan.
3. Monitor konsumsi baterai dan rencanakan pengembalian berdasarkan daya habis. Memindahkan hopper yang terisi membutuhkan lebih banyak daya baterai daripada yang kosong.
4. Menyimpan log telemetri termasuk, tetapi tidak terbatas pada, koordinat di pesawat, nilai 6 sumbu rotasi, level sinyal telemetri dan sensor eksternal.
5. Untuk memiliki tiga sistem penentuan posisi - GPS untuk mendapatkan koordinat kasar, IMU untuk verifikasi dan koreksi koordinat di pesawat, optik untuk penentuan posisi yang akurat dengan spidol.
6. Memiliki dua sistem Watch Dog - perangkat lunak dan perangkat keras. Status Verifikasi Perangkat Lunak
7. Memiliki saluran komunikasi darurat jangka panjang dengan catu daya terpisah, yang digunakan ketika parameter misi melebihi parameter yang ditentukan (koordinat, kecelakaan, kegagalan daya, kegagalan peralatan)
8. Memiliki kemampuan untuk mengubah parameter misi saat di rumah
9. Untuk memiliki dua saluran komunikasi - telemetri berkecepatan rendah dan berkecepatan tinggi untuk transmisi informasi audiovisual. Kecepatan tinggi harus dapat mengaktifkan / menonaktifkan dengan perintah telemetri.

Berdasarkan persyaratan ini, arsitektur solusi berikut dipilih:

Struktur kompleks robot meliputi: satu pusat kendali (Kontrol Stasiun Tanah) - selanjutnya GSC .

Mengizinkan pengguna melakukan yang berikut:

• Atur perimeter
• Merencanakan misi berdasarkan waktu hari dan beban pengadilan
• Mampu memantau robot golf dengan pembacaan diskrit minimal 1 menit
• Memiliki kemampuan untuk membatalkan misi

Perangkat lunak GSC harus merencanakan tindakan robot golf, sedangkan robot itu sendiri harus cukup sederhana. Solusinya tidak terlalu fleksibel, tentu saja, tetapi solusi yang konsisten sendiri dan jaringan mesh bukanlah sesuatu yang dapat diselesaikan dalam waktu singkat, dan bahkan murah. Plus - ini adalah pendekatan yang khas, dan karena itu masalah terkenal. Satu atau lebih robot golf (Golf rover) - selanjutnya disebut GR .

Lakukan tindakan khas berikut:

• Mendapat misi ketika dalam jarak 10 meter dari stasiun bumi
• Memenuhi misi
• Dalam kasus misi tipikal, melaporkan saluran telemetri dengan frekuensi minimal 1 kali per menit
• Kembali ke stasiun bumi
• Menunggu Misi Baru
• Setiap misi harus terganggu oleh peristiwa-peristiwa berikut:
  
  
  • Isi bola hopper
  • Kecelakaan nutrisi
  • Tidak mungkin bergerak (kudeta, rintangan mendadak)
  • Mulai ulang darurat
  • Gangguan misi manual
• Setiap gangguan misi harus ditransmisikan melalui telemetri konvensional dan saluran cadangan
• Setelah interupsi - GR kembali ke stasiun bumi, jika kondisinya memungkinkan

Karena mungkin ada 1 stasiun bumi, tetapi ada banyak GR - mengisi bola hopper adalah keadaan darurat. Ini memecahkan dua masalah sekaligus - GSC tahu dengan kepastian tingkat tinggi bahwa robot pergi ke stasiun dan sering menguji saluran cadangan. Juga diasumsikan bahwa pengisian bola harus dilakukan selama misi, dan jika tidak demikian, GSC di suatu tempat membuat kesalahan dalam perencanaan dan ini harus diperbaiki. Secara intuitif, saya ingin melepaskan robot di bidang yang bersih, dan ketika mengumpulkan bola, itu akan kembali. Tapi di sini ekonomi ikut berperan, jika 1-2 orang terlibat, lebih baik bagi robot untuk berdiri di stasiun, dan mulai bergerak ketika bola sudah menumpuk. Konsumsi sumber daya dan energi lebih sedikit.

Satu atau lebih stasiun bumi (Stasiun Bumi) - selanjutnya GS.

• Pengisian daya
• Pelompat bola
• Komunikasi dengan GR

Skema seluruh kompleks adalah seperti ini:

Fase kedua adalah penilaian risiko dan kemungkinan masalah dari seluruh kompleks ini

Demi kebaikan, Anda perlu memberikan tabel risiko dan penilaian mereka, tetapi saya khawatir tiga lembar A4 hanya akan menyebabkan menguap. Saya hanya akan memberikan penekanan yang menarik:

Masalah utama dari semua penjelajah perayap otonom adalah tugas untuk mendapatkan posisi tepat mereka. Selain itu, posisinya harus benar-benar akurat - sebaiknya dalam jarak 10-15 cm. Justru karena masalah ini tidak dapat benar-benar diselesaikan pada platform seluler kecil, tidak ada drone pertanian / transportasi / militer yang murah dan besar.

Meskipun tampaknya ada solusi untuk drone terbang, gunakan kembali semuanya di darat. Tapi ini di udara 10-15 meter ke kiri atau kanan pada putar-U tidak menyelesaikan hampir semua hal, tetapi di tanah itu akan menyebabkan kecelakaan dan bencana. Selain itu, batu-batu tidak mengubah tempat mereka di udara, hewan tidak menyeberang jalan. Burung, ya, tapi ada lebih banyak ruang di udara.

Penentuan posisi dilakukan oleh modul GPS / GLONASS, yang langsung mengarah pada dua konsekuensi: keakuratan posisi tidak terlalu besar dan kecepatan untuk mendapatkan koordinat. Koordinat untuk modul uBlox M8N untuk pengujian stasioner: 2-3 meter dalam kondisi penerimaan yang baik, 7-10 dalam kondisi cuaca buruk dan visibilitas. Secara umum, kesalahan seperti itu untuk tugas mengumpulkan bola bahkan bagus - penjelajah untuk beberapa misi akan menangkap bola lebih dari mengemudi di atas rel. Namun, dalam kasus ini ternyata tidak mungkin untuk melakukan itu di dekat rintangan seperti dinding atau batu besar dan di daerah ini bola akan menumpuk. Sistem navigasi optik dan ultrasonik dianalisis, tetapi ternyata sejumlah besar beacon / kamera diperlukan dengan bidang geometri yang kompleks, ada masalah dengan zona visibilitas (bidang tidak selalu setinggi lantai di hanggar) dan stabilitas sistem tersebut dalam kondisi cuaca yang sulit ( hujan, kabut). Jadi untuk saat ini, GPS kami adalah segalanya, tetapi dengan pemesanan. Selain itu, Anda dapat meningkatkan akurasi GPS agak murah - RTK, tetapi itu tidak akan menyelesaikan masalah dinding.

Menjadi jelas bahwa pendekatan yang dipilih, ketika rover merayap di sepanjang titik yang dimuat dengan akurasi 5-10 meter kiri-kanan, memerlukan verifikasi. Mendaki kereta bernama SLAM dengan kaki untuk tugas sederhana sepertinya tidak perlu. Jika memasuki stasiun melalui objek yang terang secara optik (Kode Aruco) jelas, dan berapa banyak membutuhkan sumber daya juga, maka memecahkan masalah mengklasifikasikan semua objek yang mungkin di lapangan atau menemukan batas adalah tugas yang sama sekali berbeda.

Saatnya untuk fase 3 - Bukti Konsep

Penting untuk membuat model sistem, mengujinya dalam tindakan di lapangan, dan mengevaluasi penerapannya. Menurut persyaratan yang dikembangkan, segalanya menjadi jauh lebih menyenangkan:

Sebagai penjelajah perangkat lunak, Ardurover terpilih - perangkat lunak yang aktif berkembang yang dimulai sebagai firmware untuk quadcopters di Arduino. Namun, hingga saat ini, mendukung papan Linux dengan inti RTL, dan terbuka untuk perbaikan. Di masa depan, saya harus menyelesaikannya, tetapi untuk mempercepat pekerjaan daripada jika perlu.

Sebagai otak penjelajah, BeagleBone Blue dipilih - sistem robotika yang sangat terintegrasi.


Fitur yang khas adalah penggunaan chip TI Sitara / Octavo, dibandingkan dengan Raspberry yang sama, ada Programtime Realtime Unit - PRU. Ini adalah dua inti 200 MHz terpisah yang dapat mengontrol setrika secara real time tanpa mengganggu inti utama dengan interupsi, benang, dan sihir teknologi lainnya.

Selain itu, platform ini segera memiliki WiFi, Bluetooth, konektor yang disolder untuk kabel penyeimbang, pengontrol untuk mengisi baterai Li-Po, konektor USB untuk menghubungkan telemetri dan komputer, konektor untuk servomotors, regulator daya 5 dan 3,3 volt, ADC segera ditutup dengan satu saluran per baterai, beberapa UART. Secara umum, ambil dan buat robot.

Ardurover muncul di sana bukan tanpa masalah - menggunakan PRU dari perangkat lunak saat ini hanya mungkin dilakukan dengan kernel 4.4 LTS. Di kernel yang lebih baru, memprogram PRU dari perangkat lunak pengguna mengarah ke kesalahan SIGBUS, setelah berbicara dengan pengembang dari cabang ardublue yang saya pesankan adaptor JTAG, saya akan melihat apa alasannya. Penjelajah ini sama sekali tidak mengganggu kehidupan, tetapi saya ingin pemahaman yang jelas tentang apa masalahnya.

Perangkat lunak ini memungkinkan Anda untuk melakukan hampir semua persyaratan, kecuali untuk penentuan posisi saat tiba di pangkalan, di sini saya menggunakan kamera JeVois-A33. Dia tidak akan mengirim sinyal alarm mengenai peristiwa, tetapi ini adalah tugas untuk modul terpisah dengan catu daya terpisah, seperti Modul daya mungkin tidak tahan terhadap kegagalan daya atau kudeta yang baik.

Tetap membeli receiver GPS, pemancar radio telemetri, sensor jarak ultrasonik dan menghubungkan kamera penglihatan mesin. Setelah menyolder, menghubungkan konektor dan uji coba, ternyata seperti ini:


Sebagai pusat kendali, Perencana Misi digunakan .


Perangkat lunak ini tidak dapat dibantah, antarmuka Web yang layak dan bukan pisau Swiss dengan 100500+ tombol untuk penggemar copter harus dilakukan, tetapi untuk tujuan debugging itu lebih dari cocok. Untuk berkomunikasi dengan bajak, protokol MAVLINK dari adaptor dan perangkat lunak aplikasi untuk Java / JS digunakan, banyak yang telah ditulis. Tentu saja, saya ingin memiliki paket yang lebih kecil dalam protokol, dan mempertahankan referensi parameter standar, tetapi itu akan terlalu bagus.

Sebagai dasar bajak, mesin model skala 1/18 digunakan dengan receiver dan pengontrol mesin terpisah.

Penerima dilempar keluar, konektor servo dan pengontrol motor dihubungkan langsung ke BeagleBone Blue, seperti baterai.

Dari hal yang lucu - saya ingat bahwa sebagai seorang anak saya tidak bisa menyolder sama sekali, ingus timah menggantung sepanjang waktu di situs-situs penyolderan dan saya mengambil besi solder bukan tanpa rasa takut batin. Namun, begitu pisau, kawat dan besi solder jatuh ke tangan saya, saya menjahit dengan baik sengatan itu, memotong insulasi tanpa menyentuh inti, tangan saya memutar ujung kabel, menyinari mereka dan menyegel sambungan. Dan kemudian saya ingat bahwa saya mulai bekerja sebagai pengembang tertanam dan selama beberapa bulan saya berkomunikasi dengan besi solder. Sebuah ilustrasi yang indah tentang ungkapan "Anda tidak akan minum pengalaman", menurut pendapat saya.

Saat ini, dudukannya terlihat seperti ini:


Seperti yang Anda lihat - pengontrol tanpa perumahan dan pengencang. Sayangnya, saya memesan pseudohermobox untuk dicetak dengan nilon pada printer 3D SLS, dan mereka belum berhasil melakukannya. Untuk membawa bajak di medan murni tanpa lambung - Viking seperti itu bisa berjalan selama setengah jam di udara segar. Kemudian korosi elektrokimia akan selesai, atau setelah kudeta, itu akan sepenuhnya dipancarkan. Jadi kami menunggu housing, seal dan pengencang tekanan sesuai dengan semua aturan peredam kejut dan getaran.

Video Deteksi Kode Aruco Code



Akibatnya, saya menghabiskan uji pokatushki di rumah dengan kontrol manual. Ternyata pangkalan itu dipilih tidak tepat - akselerasinya terlalu cepat, saya harus belajar pemrograman pengontrol mesin Cina. Yang kedua - gigi mundur pada keajaiban pemikiran China ini diaktifkan oleh dua sinyal "mundur" - belokan pertama pada pengereman, yang kedua berbalik terbalik. Dan itu dapat diabaikan jika sinyalnya terlalu cepat - menghemat sumber daya gigi dan mesin. Saya harus menyelesaikan ardurover, tk. trik seperti itu tidak diperhitungkan di dalamnya.

Tindakan berikut - memutar kembali rute 5-7 kali, menghapus log telemetri dan trek GPS dari rute. Saya menemukan stadion sepak bola dengan lapangan panas, jadi jika salju turun, tidak apa-apa. Rover jelas tidak akan mengebor salju, jika tidak Faina Ranevskaya akan menambahkan golf di sepanjang salju itu ke daftar penyimpangan selain hoki lapangan dan balet es. Bukan hiburan termurah, tentu saja, tetapi di mana lagi di Rusia, dan pada bulan November Anda dapat menemukan rumput hijau. Pekerjaan juga telah dimulai pada implementasi sasis yang dilacak, di mana kecepatannya jauh lebih rendah (model saat ini berakselerasi hingga 20 km / jam dalam 15 detik) dan ada belokan U di tempat, daripada segitiga pada tambalan. Kemungkinan besar, dalam beberapa minggu, kedua sasis akan berjalan pada saat yang sama untuk menguji operasi detektor hambatan dan memutar algoritma.

Pada akhirnya, saya ingin mencatat bahwa memeriksa solusi pada model skala penuh sangat cepat dan murah. Banyak masalah yang ditangkap jauh sebelumnya, dan terlebih lagi, ada waktu untuk melakukan perubahan pada desain robot besar saat ini masih dalam tahap desain atau prototipe. Maka akan lebih mahal, lebih lama, dan sesuatu akan merusak sesuatu dalam menghubungkan node. Terlebih lagi, pada model semacam itu hampir semua perangkat lunak yang diperlukan untuk tugas mudah dikembangkan dan diverifikasi. Idealnya, yang Anda perlukan untuk beralih ke model lain adalah mengganti protokol pengontrol mesin dengan yang baru. Yah, dimungkinkan untuk mengubah model dinamis.

Selain itu, penggunaan solusi khusus dan terbukti sangat menghemat waktu dan energi. Menemukan papan sirkuit densitas tinggi Anda sendiri, protokol komunikasi Anda sendiri, perangkat lunak berbasis tanah dan rover perangkat lunak, algoritma penghindaran kendala debugging dan komunikasi dengan pengontrol mesin Cina tentu sangat menarik, tetapi dalam hal ini Anda dapat segera menambahkan setengah tahun ke jalur yang panjang dan bergelombang. Sudah melewati seseorang.

Saya butuh bantuan Anda:

• Jika Anda siap bekerja pada versi ROS.
• Membutuhkan persiapan papan koneksi modul untuk versi raspberry pi dan orange pi
• Membantu pengujian jangkauan mengemudi, terutama jika Anda tinggal di negara tempat Anda bermain golf secara aktif;
• Masalah hukum, ekspor robot dari negara, hukum paten, persyaratan desain legislatif;
• Perlu bantuan dengan kemasan awal, pencarian investasi. Kami berkembang dengan baik dan tanpa investasi, kami memiliki rencana aksi, tim sedang dibentuk. Daripada uang investor, kita perlu lebih banyak pengalaman dan kompetensi dalam mengembangkan proyek yang sukses secara komersial.

Status proyek saat ini

Kami sedang mempersiapkan versi kedua tubuh. Dalam seminggu, kasing akan siap dengan cetakan vakum, tentang ini kami akan menulis posting terpisah.



Bagian bawah tubuh dibuat dengan menggiling bahan komposit.



Tubuh dan mekanik dirancang oleh NikitaKhvoryk . Kami telah menunggu lama untuk membayar modul koneksi untuk versi raspberry pi dan oranye dari n12eq3 . Versi dengan Ardupilot Vladimir Goncharov Shadow_ru

Kami berterima kasih kepada Process0169 , Trif , tersuren , vasimv , vovaekb90 , Vyacheslav Soldatov, Levon Zakaryan, Sergey Pomazkin, Vladi Kuban, Karen Musaelyan, Alexey Platonov untuk bantuan dan saran yang ditawarkan. Jika Anda ingin membantu - silakan menulis kepada saya di LAN atau VK , FB .

Paket:

Kami memiliki perjanjian awal tentang penempatan robot untuk pengujian di klub golf di Rusia, Jerman, Amerika Latin dan Selandia Baru. Dalam waktu dekat, kami akan menyelesaikan algoritme dan desain, melakukan pengujian di Moskow, dan melakukan peningkatan. Buat 5 robot dan letakkan gratis di klub golf untuk tes panjang untuk musim baru.



Terima kasih telah membaca, bertanya dan mengkritik kami sepenuhnya.