Saya sedang mengerjakan sebuah proyek baru-baru ini dan itu adalah yang pertama yang cukup terlibat untuk membuat jaringan sensor rumit. Pada akhirnya, saya pikir komunikasi adalah hambatan dalam hal kinerja keseluruhan dan saya bertanya-tanya bagaimana orang yang lebih berpengalaman akan menyelesaikan masalah ini. Ini sudah lama dibaca, tapi saya pikir ini cukup menarik, jadi tolong tetap ikuti. Masalahnya adalah untuk merancang balon udara otonom yang mampu menavigasi rintangan dan menjatuhkan bola ping pong ke target kotak cokelat. Ini dia:
Sensor
- Sistem 4D modul kamera uCAM-TTL - antarmuka UART
- HMC6352 Digital Compass - I2C interface
- Maxbotix Sonar ez4 - antarmuka analog 1 pin
Aktuator
- Driver motor 2x L293D (terhubung ke motor hobi sederhana) - Ini digunakan untuk menggerakkan 6 motor secara dua arah. Mereka membutuhkan input PWM untuk memvariasikan kecepatan. Sekarang 3 motor kami selalu melakukan hal yang sama (yang mengendalikan gerakan naik / turun) sehingga mereka hanya membutuhkan 2 output PWM dari pengontrol kami untuk mengendalikan ketiga motor. 3 motor lainnya yang mengendalikan pergerakan lateral semuanya membutuhkan kontrol individu (untuk pergerakan omni-directional) sehingga dibutuhkan 6 output PWM lain dari pengontrol kami.
- Servo motor - antarmuka PWM
Pengontrol
Untuk alasan yang akan menjadi jelas nanti, kami akhirnya menggunakan 2x ATmega328Ps. Kami menggunakan Arduino Uno untuk memprogram mereka (kami tidak memiliki akses ke ISP) tetapi kami membuat PCB kustom sehingga kami tidak harus menggunakan papan Arduino karena itu hanya akan menambah bobot yang tidak perlu untuk balon udara kami. Adapun mengapa kami memilih ATmega328P, saya sangat akrab dengan lingkungan arduino dan saya pikir itu membuat pengembangan kode lebih cepat dan mudah.
Komunikasi & Pemrosesan
- 2x Xbee Basic
- 2x ATmega328P
- Komputer desktop yang menjalankan C ++ w / openCV
Jadi seperti yang Anda tahu dari modul kamera, sebagian besar proyek kami mengandalkan visi komputer. Balon hanya bisa membawa begitu banyak beban dan kami tidak merasa nyaman menerapkan visi komputer pada mikrokontroler. Jadi yang akhirnya kami lakukan adalah menggunakan XBee untuk menyampaikan data gambar kembali ke komputer desktop. Jadi di sisi server kami menerima data gambar dan menggunakan openCV untuk memproses gambar dan mencari tahu hal itu. Sekarang sisi server juga perlu mengetahui informasi ketinggian (dari sonar) dan informasi kompas.
Kerutan pertama adalah kami tidak dapat memiliki kamera yang dikendalikan oleh mikrokontroler karena beberapa alasan. Masalah utamanya adalah memori internal pada uP yang tidak dapat menyimpan seluruh frame. Mungkin ada beberapa cara untuk mengatasi hal ini melalui pengkodean yang cerdik tetapi untuk keperluan pertanyaan ini mari kita berpura-pura tidak mungkin. Jadi untuk mengatasi masalah ini, kami meminta pihak server mengirim perintah kamera melalui transceiver XBee dan penerima XBee (on board the blimp) keluarannya dihubungkan ke input kamera.
Kerutan berikutnya adalah bahwa tidak ada cukup PWM pada ATmega328P tunggal untuk mengontrol semua motor KARENA antarmuka I2C menggunakan salah satu pin PWM (sialan mereka ...). Itu sebabnya kami memutuskan untuk menggunakan yang ke-2. Kode sebenarnya meminjamkan dirinya dengan sempurna ke pemrosesan paralel karena kontrol ketinggian benar-benar independen dari kontrol gerakan lateral (jadi 2 micros mungkin lebih baik daripada yang terpasang pada pengontrol PWM). Oleh karena itu, U1 bertanggung jawab untuk 2 output PWM (atas / bawah) dan membaca Sonar. U2 bertanggung jawab untuk membaca kompas, mengendalikan 6 output PWM (motor lateral), dan juga membaca Sonar. U2 juga bertanggung jawab untuk menerima perintah dari server melalui XBee.
Itu menyebabkan masalah komunikasi pertama kami. Garis XBee DOUT terhubung ke mikrokontroler dan kamera. Sekarang tentu saja kami merancang protokol sehingga perintah mikro kami akan mengabaikan perintah kamera dan perintah kamera akan mengabaikan perintah mikro sehingga itu baik-baik saja. Namun, kamera, ketika mengabaikan perintah mikro kami, akan mengirim kembali data NAK pada jalur outputnya. Karena perintah itu dimaksudkan untuk mikro, kami perlu cara untuk mematikan output kamera ke XBee. Untuk mengatasi ini, kami membuat kontrol mikro 2 FET yang berada di antara kamera dan XBee (itulah FET pertama) dan juga antara U2 dan XBee (itulah FET kedua). Karena itu, ketika kamera mencoba mengirim info kembali ke server, FET pertama 'aktif' dan FET kedua 'mati'.
Jadi untuk memberi Anda gambaran bagaimana ini bekerja di sini adalah beberapa contoh:
- Server meminta gambar - PIC_REQUEST melewati XBee dan tiba di U2 dan kamera. U2 mengabaikannya dan kamera mengirim kembali data gambar.
- Server baru saja selesai memproses gambar dan mengirimkan data motor untuk memberitahu balon agar belok kanan - MOTOR_ANGLE (70) mulai melalui XBee dan tiba di U2 dan kamera. U2 mengenali sebagai perintah mikro dan dengan demikian mematikan FET Kamera (tapi mungkin kamera sudah merespons dengan NAK ?? siapa tahu ...). U2 kemudian merespons perintah dengan mengubah output PWM motor. Ini kemudian mengaktifkan FET Kamera kembali (ini adalah pengaturan default karena data gambar paling penting).
- Server menyadari bahwa kita telah sampai pada suatu titik di rintangan di mana ketinggian hover default kita sekarang harus 90 inci, bukan 50 inci. SET_HEIGHT melewati XBee dan hal yang sama terjadi seperti pada contoh 2. U2 mengenali perintah SET_HEIGHT dan memicu interupsi pada U1. U1 sekarang keluar dari loop kontrol ketinggiannya dan menunggu untuk menerima data serial dari U2. Benar, lebih banyak data serial. Pada titik ini, FET U2 aktif (dan FET kamera tidak aktif) sehingga server menerima ketinggian yang juga dikirimkan U2 ke U1. Itu untuk keperluan verifikasi. Sekarang U1 me-reset variabel internal untuk height2HoverAt. U2 sekarang mematikan FET dan menghidupkan FET kamera kembali.
Saya jelas meninggalkan banyak informasi, tetapi saya pikir itu cukup untuk memahami beberapa komplikasi. Pada akhirnya, masalah kami hanya menyinkronkan semuanya. Terkadang akan ada data yang tersisa di buffer, tetapi hanya 3 byte (semua perintah kami adalah urutan 6 byte). Terkadang kami kehilangan koneksi dengan kamera kami dan harus melakukan sinkronisasi ulang.
Jadi pertanyaan saya adalah: Teknik apa yang kalian sarankan untuk membuat komunikasi antara semua komponen itu lebih dapat diandalkan / kuat / lebih sederhana / lebih baik?
Sebagai contoh, saya tahu seseorang akan menambahkan sirkuit tunda antara papan XBee keluar dan kamera sehingga mikro memiliki kesempatan untuk mematikan jalur bicara kamera sebelum menanggapi perintah mikro dengan NAK. Ada ide lain seperti itu?
Terima kasih dan saya yakin ini akan membutuhkan banyak pengeditan jadi tetaplah disini.
Sunting1:Splicing data UART kamera melalui salah satu micros tampaknya tidak mungkin bagi kami. Ada dua opsi untuk data kamera, peta bit mentah, atau JPEG. Untuk bitmap mentah, kamera hanya mengirim data kepada Anda secepat mungkin. ATmega328P hanya memiliki 128 byte untuk buffer serial (secara teknis ini dapat dikonfigurasi tetapi saya tidak yakin bagaimana) dan kami tidak berpikir kami bisa mengeluarkannya dari buffer dan melalui XBee dengan cukup cepat. Itu meninggalkan metode JPEG di mana ia mengirim setiap paket dan menunggu controller untuk ACK itu (protocl handshaking kecil). Yang tercepat untuk ini adalah 115200 baud. Sekarang untuk beberapa alasan, tercepat yang dapat kami andalkan mengirimkan sejumlah besar data melalui XBee adalah 57.600 baud (ini bahkan setelah kami melakukan pemasangan simpul / jaringan untuk memungkinkan kemampuan mengirim ulang otomatis). Menambahkan penghentian ekstra di jaringan kami (kamera ke mikro ke XBee sebagai lawan dari hanya kamera ke XBee) karena mikro hanya memperlambat waktu yang diperlukan untuk mentransfer gambar terlalu banyak. Kami membutuhkan kecepatan refresh tertentu pada gambar agar algoritma kontrol motor kami berfungsi.