Jaringan sensor yang agak rumit

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:

1. Server meminta gambar - PIC_REQUEST melewati XBee dan tiba di U2 dan kamera. U2 mengabaikannya dan kamera mengirim kembali data gambar.
2. 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).
3. 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.

Saya mengerti bahwa Anda ingin memilih lingkungan pengembangan yang sudah Anda kenal sehingga Anda dapat menjalankannya, tetapi saya pikir perangkat keras / lunaknya dapat membuat Anda masuk dengan tetap menggunakan Arduino dan tidak memilih bagian yang memiliki semua periferal perangkat keras yang Anda butuhkan dan menulis semuanya dalam interrupt-driven C sebagai gantinya.

Saya setuju dengan saran @Matt Jenkins dan ingin mengembangkannya.

Saya akan memilih UC dengan 2 UART. Satu terhubung ke Xbee dan satu terhubung ke kamera. UC menerima perintah dari server untuk memulai pembacaan kamera dan rutin dapat ditulis untuk mentransfer data dari saluran UART kamera ke saluran XBee UART berdasarkan byte per byte - sehingga tidak ada buffer (atau paling banyak hanya sangat kecil) satu) dibutuhkan. Saya akan mencoba untuk menghilangkan UC lainnya bersama-sama dengan memilih bagian yang juga mengakomodasi semua kebutuhan PWM Anda (8 saluran PWM?) Dan jika Anda ingin tetap dengan 2 UC berbeda mengurus sumbu masing-masing maka mungkin antarmuka komunikasi yang berbeda akan lebih baik karena semua UART Anda yang lain akan diambil.

Orang lain juga menyarankan untuk pindah ke platform linux yang tertanam untuk menjalankan semuanya (termasuk openCV) dan saya pikir itu akan menjadi sesuatu yang dapat dijelajahi juga. Saya sudah pernah ke sana sebelumnya, sebuah proyek sekolah 4 bulan dan Anda hanya perlu menyelesaikannya secepat mungkin, tidak dapat terhenti karena kelumpuhan dengan analisis - Saya harap itu ternyata baik-baik saja untuk Anda!

EDIT # 1 Sebagai balasan untuk komentar @JGord:

Saya melakukan proyek yang mengimplementasikan penerusan UART dengan ATmega164p. Ini memiliki 2 UART. Berikut adalah gambar dari tangkapan penganalisa logika (Saleae USB logic analyzer) dari proyek yang menunjukkan penerusan UART:

Baris atas adalah sumber data (dalam hal ini akan menjadi kamera Anda) dan garis bawah adalah saluran UART yang diteruskan ke (XBee dalam kasus Anda). Rutin yang ditulis untuk melakukan ini menangani UART menerima interupsi. Sekarang, apakah Anda percaya bahwa selagi penerusan UART ini berlangsung, Anda dapat dengan senang hati mengkonfigurasi saluran PWM Anda dan menangani rutinitas I2C Anda juga? Biarkan saya jelaskan caranya.

Setiap perangkat UART (untuk AVR saya bagaimanapun) terdiri dari register shift pasangan, register data, dan register kontrol / status. Perangkat keras ini akan melakukan hal-hal sendiri (dengan asumsi bahwa Anda telah menginisialisasi baud rate dan semacamnya) tanpa ada intervensi Anda jika:

1. Satu byte masuk atau
2. Satu byte ditempatkan dalam register data dan ditandai untuk output

Yang terpenting di sini adalah register geser dan register data. Misalkan byte datang pada UART0 dan kami ingin meneruskan lalu lintas itu ke output UART1. Ketika byte baru telah dipindahkan ke register shift input UART0, byte tersebut akan ditransfer ke register data UART0 dan interupsi penerimaan UART0 dimatikan. Jika Anda telah menulis ISR untuk itu, Anda dapat mengambil byte dalam register data UART0 dan memindahkannya ke register data UART1 dan kemudian mengatur register kontrol untuk UART1 untuk mulai mentransfer. Apa yang dilakukannya adalah ia memberi tahu periferal UART1 untuk mengambil apa pun yang baru saja Anda masukkan ke dalam register datanya, memasukkannya ke dalam register shift keluarannya, dan mulai memindahkannya. Dari sini, Anda dapat kembali dari ISR ​​dan kembali ke tugas apa pun yang dilakukan UC Anda sebelum terputus. Sekarang UART0, setelah hanya register gesernya dihapus, dan register datanya dibersihkan dapat mulai menggeser data baru jika belum dilakukan selama ISR, dan UART1 menggeser byte yang baru saja Anda masukkan ke dalamnya - semua itu terjadi pada sendiri tanpa intervensi Anda saat UC Anda tidak aktif melakukan beberapa tugas lain. Seluruh ISR membutuhkan mikrodetik untuk dieksekusi karena kita hanya bergerak 1 byte di sekitar memori, dan ini menyisakan banyak waktu untuk mematikan dan melakukan hal-hal lain hingga byte berikutnya pada UART0 masuk (yang membutuhkan 100-an mikrodetik). dan UART1 menggeser byte yang baru saja Anda masukkan ke dalamnya - semua itu terjadi dengan sendirinya tanpa campur tangan Anda sementara UC Anda tidak aktif melakukan beberapa tugas lain. Seluruh ISR membutuhkan mikrodetik untuk dieksekusi karena kita hanya bergerak 1 byte di sekitar memori, dan ini menyisakan banyak waktu untuk mematikan dan melakukan hal-hal lain hingga byte berikutnya pada UART0 masuk (yang membutuhkan 100-an mikrodetik). dan UART1 menggeser byte yang baru saja Anda masukkan ke dalamnya - semua itu terjadi dengan sendirinya tanpa campur tangan Anda sementara UC Anda tidak aktif melakukan beberapa tugas lain. Seluruh ISR membutuhkan mikrodetik untuk dieksekusi karena kita hanya bergerak 1 byte di sekitar memori, dan ini menyisakan banyak waktu untuk mematikan dan melakukan hal-hal lain hingga byte berikutnya pada UART0 masuk (yang membutuhkan 100-an mikrodetik).

Ini adalah keindahan memiliki perangkat keras - Anda hanya menulis ke beberapa register dipetakan memori dan akan mengurus sisanya dari sana dan akan memberi sinyal untuk perhatian Anda melalui interupsi seperti yang saya jelaskan di atas. Proses ini akan terjadi setiap kali byte baru masuk pada UART0.

Perhatikan bagaimana hanya ada penundaan 1 byte dalam tangkapan logika karena kami hanya "buffering" 1 byte jika Anda ingin memikirkannya seperti itu. Saya tidak yakin bagaimana Anda membuat O(2N)estimasi Anda - saya akan berasumsi bahwa Anda telah menyimpan fungsi pustaka serial Arduino dalam loop pemblokiran menunggu data. Jika kita memperhitungkan overhead karena harus memproses perintah "baca kamera" pada UC, metode interrupt driven lebih seperti di O(N+c)mana cmencakup penundaan byte tunggal dan instruksi "baca kamera". Ini akan sangat kecil mengingat Anda mengirim sejumlah besar data (data gambar kan?).

Semua detail tentang periferal UART ini (dan setiap periferal pada uC) dijelaskan secara menyeluruh dalam datasheet dan semuanya dapat diakses di C. Saya tidak tahu apakah lingkungan Arduino memberi Anda akses yang rendah sehingga Anda dapat mulai mengakses register - dan itu masalahnya - jika tidak, Anda dibatasi oleh implementasinya. Anda mengendalikan segalanya jika Anda telah menuliskannya dalam C (bahkan lebih dari itu jika dilakukan dalam perakitan) dan Anda benar-benar dapat mendorong mikrokontroler ke potensi sebenarnya.

Mengapa Anda tidak bisa menyalurkan data kamera melalui μC? Maksud saya tidak buffering gambar, tetapi menyampaikan data UART melalui μC sehingga dapat memutuskan apa yang harus dikirim kembali dan apa yang tidak?

Paling mudah jika Anda memiliki μC dengan dua UART di dalamnya, tetapi dapat ditiru dalam perangkat lunak.

Opsi lain telah terpikir oleh saya, tetapi ini mungkin agak besar dan terlalu berat untuk proyek Anda: -

• Mengapa tidak menggunakan server USB nirkabel, yang terhubung ke hub USB kecil, dengan adaptor USB-> RS232 untuk memberikan beberapa saluran kontrol ke berbagai bagian sistem?

Ya, besar, tetapi jika Anda melepasnya, dan mungkin menggunakan USB alih-alih RS232 jika memungkinkan, Anda mungkin dapat melakukannya ...