Wallace - Robot Otonom DIY - Bagian 5 - Tambahkan IMU: 9 Langkah

2024 Pengarang: John Day | [email protected]. Terakhir diubah: 2024-01-30 09:57

Kami melanjutkan bersama dengan Wallace. Nama Wallace berasal dari campuran "Wall-E", dan dari proyek sebelumnya (pengenalan suara), dan dalam menggunakan utilitas "espeak", itu terdengar agak Inggris. Dan seperti pelayan atau kepala pelayan. Dan itulah tujuan akhirnya: agar proyek ini berubah menjadi sesuatu yang berguna. Jadi "Wallace".

Wallace bisa bergerak, dia bisa menghindari rintangan menggunakan sensor jarak IR (baru-baru ini, entah bagaimana mereka goreng(?) (harus melihatnya ketika saya mendapat kesempatan), juga memiliki beberapa sensor jarak akustik (tiga di antaranya menjadi buruk pada saat yang sama time, bersama dengan expander MCP23017), dan akhirnya, dapat mendeteksi perubahan arus motor untuk mengetahui kapan ia menabrak sesuatu.

Selain sensor, Wallace "mengingat" 100 gerakan, dan memiliki beberapa analisis dasar menggunakan riwayat gerakan.

Sejauh ini tujuan Wallace hanyalah mencoba untuk terus bergerak maju, dan untuk mengetahui kapan ia terjebak dalam pola berulang (seperti di sudut) dan tidak benar-benar bergerak maju.

Saya telah melalui beberapa iterasi untuk gerakan dan navigasi, dan sakit kepala yang konsisten terjadi selama rotasi.

Karena Wallace adalah robot yang dilacak, dan saya ingin membuatnya lebih sederhana dalam perangkat lunak (untuk nanti), untuk mengubahnya, saya hanya meminta dia berputar/memutar di tempatnya. Jadi, terapkan daya / siklus kerja yang sama tetapi berlawanan ke motor.

Masalah yang dihadapi adalah karena desain platform robot Agent 390. Sabuk lintasan cenderung bergesekan dengan sisi-sisinya. Dan lebih buruknya, satu sisi melakukannya lebih dari yang lain.

Di lantai dan lurus, itu tidak menjadi masalah. Itu muncul di karpet. Saya memilih untuk menjauhkan Wallace dari karpet setelah jejaknya menjadi kotor (mereka mengambil kotoran dengan sangat mudah).

Masalah sebenarnya adalah ketika berputar di lantai.

Jika saya memiliki perangkat lunak yang menerapkan siklus tugas tingkat tinggi, maka itu kurang lebih secara konsisten berubah. Namun, selama siklus tugas rendah, mungkin atau mungkin tidak benar-benar berputar. Atau mungkin berputar sebentar dan kemudian melambat. Tindakan berputar tampaknya tidak dapat dikendalikan melalui perangkat lunak, atau paling-paling sangat sulit.

Masalah muncul selama navigasi dan bergerak di sekitar atau menjauh dari rintangan. Itu bisa berayun terlalu liar, atau bisa macet saat mencoba membuat pergeseran yang sangat kecil, bahkan tanpa benar-benar bergerak.

Dan penjelasan di atas memotivasi Instructable ini.

Awalnya, saya ingin membuang, atau menunda memperkenalkan unit penginderaan gerak (IMU), karena mereka A) rumit, B) berisik, C) kesalahan dapat terjadi seiring waktu, dan lain-lain, dll. Pikiran saya telah adalah bahwa kami dapat melakukannya dengan sangat baik dengan melompat ke depan ke sensor laser IR waktu penerbangan. Dan kita bisa - menggunakan laser kita bisa tahu apakah robot itu berputar atau tidak, dengan melacak perubahan jarak.

Bahkan, kami juga bisa (semacam) melakukannya sekarang, dengan sensor akustik.

Namun, semua itu adalah cara yang sangat tidak langsung dan rumit untuk menjawab satu pertanyaan sederhana: "sudahkah kita melakukan rotasi atau tidak?"

Bagi saya, melompat untuk menggunakan sensor laser ToF akan membawa saya ke tingkat perangkat lunak berikutnya; yaitu, SLAM (Simultaneous Localization and Mapping). Saya belum siap untuk pergi ke sana dulu.

Merupakan hal yang baik untuk melakukan proyek robot berlapis-lapis, dengan lapisan pertama (bawah) menjadi lebih sederhana, dan lapisan terakhir (atas) menjadi lebih abstrak dan menangani masalah yang lebih sulit.

Lapisan dapat dianggap seperti ini:

1. kerangka fisik robot / dasar struktural mekanis
2. sistem penggerak yang belum sempurna (Raspberry, Roboclaw, motor, kabel, dll, perangkat lunak dasar, yang digerakkan oleh keyboard)
3. sirkuit penting untuk mendukung sensor (penggeser tegangan dua arah, port expander, E-Stop, distribusi daya, dll)
4. sensor penghindar rintangan (akustik, IR)
5. penting, pemosisian dasar dan gerakan - deteksi (akselerometer, gyro, magnetometer, encoder motor, encoder roda)

Anda dapat membuat daftar Anda sendiri. Poin tentang daftar ini adalah bahwa Anda mungkin harus melakukan ini lebih atau kurang dalam urutan itu, dan juga bahwa jika Anda meluangkan waktu di setiap lapisan untuk mendapatkan masing-masing ke keadaan kerja yang baik, itu akan membantu Anda nanti karena segalanya menjadi lebih rumit.

Daftar di atas bisa lebih atau kurang dipetakan ke lapisan konseptual ini dalam perangkat lunak.

• SLAM (Lokalisasi dan Pemetaan Simultan)
• Kontrol dan Kesadaran Gerakan, Rotasi
• Penghindaran Rintangan Dasar
• Kontrol dan Deteksi Data Sensor
• Gerakan Penting Maju, Mundur, Kiri dan Kanan, Mempercepat, Memperlambat, Berhenti

Seperti yang Anda lihat, untuk daftar ini, item pertama adalah lapisan atas yang lebih rumit yang menangani masalah dan pertanyaan yang lebih abstrak, seperti "ke mana saya" dan "ke mana saya pergi", sedangkan item terakhir adalah lapisan perangkat lunak yang lebih rendah yang menangani "cara berbicara/mendengarkan sensor A" atau "cara menggerakkan roda ini".

Sekarang, saya tidak mengatakan bahwa ketika Anda memulai pada sebuah lapisan, Anda akan menyelesaikannya dan kemudian berada di lapisan berikutnya, tidak pernah kembali ke yang sebelumnya. Proyek robot bisa sangat mirip dengan metode pengembangan perangkat lunak modern dan berulang (gesit, SCRUM, dll).

Aku hanya mengatakan untuk mengambil waktu di masing-masing. Anda harus menyeimbangkan berapa banyak yang harus dilakukan pada masing-masing, dan memutuskan apa yang Anda coba pada lapisan tertentu yang sepadan dengan waktu dan masalah.

Ada "konflik" atau "ketegangan" tertentu antara dua ide atau arah yang bersaing.

Salah satunya adalah apa yang saya sebut "plug-n-play" untuk menyelesaikan masalah A.

Yang lainnya adalah DIY (lakukan sendiri). Dan itu mungkin bukan label terbaik untuk ide lain ini.

Berikut adalah contoh masing-masing, semoga Anda akan melihat ketegangan atau konflik antara dua pilihan.

Untuk contoh ini, mari kita gabungkan SLAM, rintangan-menghindari, dan gerakan dasar esensial semua sebagai satu masalah untuk dipecahkan pada saat yang bersamaan.

1. Jika kami memutuskan untuk mengambil rute plug-n-play, kami langsung melompat (tergantung anggaran) ke hal-hal seperti laser berputar yang dipasang di atas, atau kamera depth-of-field, atau laser ToF, dan IMU (topik ini dapat diinstruksikan).
2. Jika kita, di sisi lain, ingin menempuh rute kedua, kita dapat mencoba mengekstrak setiap bit informasi yang mungkin dari beberapa sensor akustik atau sensor IR, atau tanpa sensor sama sekali - kita hanya menggunakan pemantauan arus motor (bump)

Apa yang bisa dikatakan tentang #1 vs #2? Satu hal adalah bahwa kita akan belajar lebih banyak dengan melakukan #2. Keterbatasan hanya memiliki sensor akustik untuk bekerja, memaksa kita untuk memikirkan lebih banyak masalah.

Di sisi lain, jika kita terlalu fokus melakukan sesuatu melalui #2, kita mungkin membuang-buang waktu, karena kita meminta lebih dari yang seharusnya dari sensor akustik.

Satu lagi konsep atau ide untuk dipikirkan: Campuran perangkat keras dan perangkat lunak apa yang paling baik menjawab pertanyaan "bagaimana", dan campuran perangkat lunak (dan perangkat keras?) apa yang menjawab pertanyaan "apa", "kapan", "di mana". Karena "bagaimana" biasanya merupakan pertanyaan tingkat rendah di mana "apa", "kapan", dan "di mana" bergantung untuk mendapatkan jawaban.

Bagaimanapun, semua hal di atas hanyalah sesuatu untuk dipikirkan.

Dalam kasus saya, setelah banyak usaha dan memiliki masalah gesekan trek yang konsisten dan tidak bisa mendapatkan kontrol dan gerakan yang konsisten, sekarang saatnya untuk melakukan sesuatu yang lain.

Jadi Instructable ini - sebuah IMU.

Tujuannya adalah jika IMU mengatakan bahwa robot TIDAK berputar, kami meningkatkan siklus kerja. Jika kita berputar terlalu cepat, kita mengurangi siklus tugas.

Langkah 1: Sensor IMU

Jadi sensor kami berikutnya untuk ditambahkan ke Wallace adalah IMU. Setelah beberapa penelitian, saya memilih MPU6050. Tapi kemudian saat ini, MPU9050 (dan bahkan lebih baru lagi, MPU9250) tampak seperti ide yang lebih baik.

Sumber masuk saya adalah Amazon (di AS). Jadi saya memesan dua dari mereka.

Apa yang saya dapatkan sebenarnya (sepertinya tidak ada kontrol atas ini; itulah yang saya tidak suka tentang Amazon) adalah dua MPU92/65. Saya sedikit bertanya-tanya tentang penunjukan itu. Lihatlah gambar; yang tampaknya menjadi sebutan "keluarga". Dalam hal apapun, itulah yang saya terjebak dengan.

Menambahkannya sangat sederhana - dapatkan papan proto dengan trek penghubung, solder sensor ke papan, tambahkan blok terminal sekrup 10-pin (saya mendapatkan milik saya dari Pololu).

Untuk meminimalkan gangguan apa pun, saya mencoba menempatkan sensor ini jauh dari segala hal lainnya.

Itu juga berarti menggunakan beberapa baut/mur nilon.

Saya akan menggunakan protokol I2C. Semoga total panjang kawat tidak terlalu buruk.

Ada banyak informasi di tempat lain tentang koneksi dasar dan level tegangan, dll, jadi saya tidak akan mengulanginya di sini.

Langkah 2: Segalanya Tidak Selalu Bersih, Mudah

Pada tulisan ini, sepertinya tidak banyak yang online untuk MPU-92/65 khusus ini. Apa yang tersedia, seperti kebanyakan sensor, tampaknya menjadi contoh menggunakan Arduino.

Saya mencoba membuat Instructables ini sedikit berbeda dengan menghadirkan proses yang tidak terlalu bersih, karena segala sesuatunya tidak selalu langsung berfungsi.

Saya kira Instructables ini lebih mirip dengan blog daripada A-B-C lurus, 1-2-3 "ini adalah bagaimana Anda melakukannya".

Langkah 3: Tes Awal

Dari gambar pada langkah sebelumnya, kabel merah dan hitam yang menuju ke sensor tentu saja VCC (5V) dan GND. Kabel hijau dan kuning adalah koneksi I2C.

Jika Anda telah melakukan proyek I2C lain, atau telah mengikuti seri ini, maka Anda sudah tahu tentang "i2cdetect", dan itulah langkah pertama untuk mengetahui apakah Raspberry dapat melihat sensor baru.

Seperti yang Anda lihat dari gambar di langkah ini, upaya pertama kami tidak berhasil. IMU tidak muncul (harus id perangkat 0x68).

Namun, kabar baiknya adalah bus I2C sedang beroperasi. Kami memang melihat satu perangkat 0x20 dan itu adalah port expander MCP23017 (saat ini bertanggung jawab atas sensor akustik HCSR04).

Tidak mudah untuk melihat pada gambar, tetapi saya menghubungkan kabel berwarna hijau dan kuning yang sama dari IMU ke MCP23017 (lihat kiri bawah pada gambar)

Kami harus melakukan beberapa pemecahan masalah.

Langkah 4: Pemecahan Masalah

Menggunakan pengaturan kontinuitas pada voltmeter (yang bernada tinggi), saya menguji koneksi VCC(5V), GND, SDA, dan SCL. Itu bagus.

Upaya selanjutnya adalah memutuskan sambungan MCP23017 dari bus I2C, hanya menyisakan MPU-92/65 di bus. Itu terbukti sia-sia - "i2cdetect" kemudian tidak menunjukkan perangkat.

Jadi, selanjutnya, saya melepas sensor dari tiang totem, dan menyambungkannya kembali langsung ke bus dua arah 5V-ke-3V; yaitu, langsung ke Raspberry. (kabel lebih pendek?).

Dan voila. Kali ini ada kesuksesan. Kami melihat 0x68 muncul menggunakan "i2cdetect".

Tapi kami belum tahu mengapa kali ini berhasil. Bisa jadi panjang kabelnya? Lokasi sebelumnya?

Catatan: Tidak ada bedanya apakah ADO di-ground atau tidak. Bisa jadi ada resistor pullup dan pull-down on-board. Hal yang sama mungkin berlaku untuk FSYNC.

Selanjutnya, saya menghubungkan kembali MCP23017. Jadi sekarang kami memiliki dua perangkat di bus I2C. (lihat gambar). Berhasil, kita sekarang melihat 0x20 dan 0x68 dengan i2cdetect.

Video membahas sedikit lebih banyak tentang apa yang terjadi selama pemecahan masalah.

Langkah 5: Membaca Data Sensor

Berbagai Pendekatan

Saya memutuskan untuk mengambil beberapa pendekatan untuk mendapatkan informasi yang berguna dari sensor. Ini dia, tidak dalam urutan apa pun:

1. coba beberapa pemrograman dasar
2. lihat beberapa dokumentasi online di register
3. lihat contoh dan/atau kode orang lain

Mengapa pendekatan ini? Mengapa tidak mencari beberapa pustaka atau kode yang ada?

Dengan bereksperimen dan mencoba beberapa ide, kita dapat lebih menyerap beberapa pengetahuan tentang tidak hanya sensor khusus ini, tetapi juga mendapatkan beberapa teknik, keterampilan, dan cara berpikir tentang menangani sesuatu yang baru, dan sesuatu yang mungkin tidak memiliki banyak dokumentasi; sesuatu yang mungkin memiliki banyak hal yang tidak diketahui.

Juga, setelah kami bermain dan mencoba beberapa ide kami sendiri dan memperoleh beberapa wawasan, kami berada dalam posisi yang lebih baik untuk mengevaluasi kode atau perpustakaan orang lain.

Misalnya, setelah melihat beberapa kode C++ untuk MPU9250 di github, saya menyadari itu memaksa saya untuk menggunakan interupsi, yang belum ingin saya lakukan.

Juga, ia datang dengan hal-hal tambahan seperti kalibrasi; lagi, sesuatu yang saya belum tertarik.

Mungkin yang perlu saya lakukan untuk menjawab pertanyaan sederhana "apakah robot berputar ya atau tidak" dapat dijawab dengan sangat sederhana hanya dengan membaca beberapa register.

Daftar

Pada tulisan ini, sepertinya tidak banyak yang tersedia pada sensor ini. Sebenarnya, jika Anda melihat gambar yang disertakan dengan Instruksi ini, dan melihat dari dekat tulisan pada chip yang sebenarnya, itu membuat saya bertanya-tanya apakah ini bukan tiruan. Saya tidak menghubungkan apa yang saya lihat dengan apa pun dari Invense. Terlepas dari itu, saya memilih untuk melihat informasi register untuk model yang saya temukan: MPU-6050, dan MPU-9250.

Dalam kedua kasus, berikut ini adalah sama untuk keduanya. Dan sebagai permulaan, kami menganggap itu juga akan sama untuk MPU-92/65 ini.

59 hingga 64 - pengukuran akselerometer

65, 66 - pengukuran suhu 67 hingga 72 - pengukuran giroskop 73 hingga 96 - data sensor eksternal

Catatan: MPU-6050 tampaknya TIDAK memiliki magnetometer, sedangkan MPU-9250 (dan kami menganggap yang ini juga) memilikinya.

Beberapa informasi yang lebih menarik, semoga bermanfaat yang diperoleh dari dokumen register:

Informasi Magnetometer:

magnetometer id: 0x48 register 00 sampai 09: 00H WIA 0 1 0 0 1 0 0 0 01H INFO INFO7 INFO6 INFO5 INFO4 INFO3 INFO2 INFO1 INFO0 02H ST1 0 0 0 0 0 0 DOR DRDY 03H HXL HX7 HX6 HX5 HX4 HX3 HX0 04H1 HX0 HXH HX15 HX14 HX13 HX12 HX11 HX10 HX9 HX8 05H HYL HY7 HY6 HY5 HY4 HY3 HY2 HY1 HY0 06H HYH HY15 HY14 HY13 HY12 HY11 HY10 HY9 HY8 07H HZL HZ7 HZ6 HZ5 HZ4 HZ3 HZ2 HZ1 HZ0 08H HZH HZ15 HZ14 HZ13 HZ12 HZ11 HZ10 HZ9 HZ8 09h ST2 0 0 0 BITM HOFL 0 0 0 rincian arti setiap register: HXL[7:0]: Data pengukuran sumbu X lebih rendah 8bit HXH[15:8]: Data pengukuran sumbu X lebih tinggi 8bit HYL[7:0]: Data pengukuran sumbu Y lebih rendah 8bit HYH[15:8]: Data pengukuran sumbu Y lebih tinggi 8bit HZL[7:0]: Data pengukuran sumbu Z lebih rendah 8bit HZH[15:8]: Data pengukuran sumbu Z lebih tinggi 8bit

Pemrograman

Satu informasi lain dari register docs adalah bahwa sepertinya hanya ada sekitar 100 atau lebih register. Jadi salah satu taktiknya adalah menulis program sederhana yang mengakses perangkat (0x68) dan mencoba membaca serangkaian register secara berurutan, tanpa memperhatikan artinya, hanya untuk melihat data apa yang dapat dilihat.

Dan kemudian, lakukan passing berturut-turut, menggunakan kode yang sama, dan bandingkan data dari satu pass vs yang berikutnya.

Idenya adalah bahwa kita mungkin bisa menghilangkan register yang tampaknya tidak memiliki data (nol atau FF ?) atau yang sama sekali tidak pernah berubah, dan kita juga bisa fokus pada register yang berubah.

Kemudian, yang kita lihat hanya yang berubah, tambahkan fungsi rata-rata yang rata-rata membaca N terakhir dari register itu, untuk melihat apakah sebenarnya ada nilai tetap tertentu untuk register itu. Ini akan mengasumsikan kita menjaga sensor tetap diam, dan di lokasi yang sama.

Akhirnya, kita kemudian dapat dengan lembut mencoba berbagai hal dengan sensor, seperti menyenggolnya (akselerometer, gyro), atau meniupnya (suhu), atau memutarnya (dua magnetometer plus sebelumnya) dan melihat apa pengaruhnya terhadap nilai.

Saya suka menggunakan perpustakaan wiringPi sebanyak mungkin. Ini memiliki dukungan untuk I2C.

Lari pertama:

/********************************************************************************

* untuk membangun: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * untuk menjalankan: sudo./first.test.mpu9265 * * program ini hanya mengeluarkan sejumlah (mungkin) register dari MCP23017, * dan kemudian dari MPU9265 (atau MPU lain di alamat 0x68 itu) * * Saya menggunakannya untuk memvalidasi apakah saya bahkan dapat membaca dari sensor, karena saya sudah * memiliki kepercayaan pada MCP23017. * ************************************************* ****************************/ #include #include #include #include #include int main(int argc, char** argv) { puts("Mari kita lihat apa yang MCP23017 @ 0x20 katakan:"); salah = 0; int deviceId1 = 0x20; int fd1 = wiringPiI2CSetup(deviceId1); if (-1 == fd1) { fprintf (stderr, "Tidak dapat membuka perangkat wiringPi I2C: %s\n", strerror (errno)); kembali 1; } for (int reg=0;reg<300;reg++) { fprintf(stderr, "%d ", wiringPiI2CReadReg8(fd1, reg));fflush(stderr); penundaan (10); } menempatkan(""); puts("Mari kita lihat apa yang dikatakan MPU9265 @ 0x20:"); salah = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup(deviceId2); if (-1 == fd2) { fprintf (stderr, "Tidak dapat membuka perangkat wiringPi I2C: %s\n", strerror (errno)); kembali 1; } for (int reg=0;reg<300;reg++) { fprintf(stderr, "%d ", wiringPiI2CReadReg8(fd2, reg));fflush(stderr); penundaan (10); } menempatkan(""); kembali 0; }

Lari kedua:

/********************************************************************************

* untuk membangun: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * untuk menjalankan: sudo./second.test.mpu9265 * * Program ini menampilkan nomor register di samping nilai yang dibaca. * * Ini membuatnya berguna untuk menyalurkan (mengarahkan ulang) output ke file, dan kemudian * beberapa proses dapat dilakukan, untuk membandingkan. Ini mungkin memberikan beberapa wawasan tentang * register apa yang penting, dan bagaimana data mungkin berperilaku. * ************************************************* ****************************/ #include #include #include #include #include #include int main(int argc, char** argv) { int deviceId = -1; if (0) { } else if (!strncmp(argv[1], "0x20", strlen("0x20"))) { deviceId = 0x20; } else if (!strncmp(argv[1], "0x68", strlen("0x68"))) { deviceId = 0x68; } else if (!strncmp(argv[1], "0x69", strlen("0x69"))) { deviceId = 0x69; } puts("Mari kita lihat apa yang MPU9265 @ 0x20 katakan:"); salah = 0; int fd = wiringPiI2CSetup(deviceId); if (-1 == fd) { fprintf (stderr, "Tidak dapat membuka perangkat wiringPi I2C: %s\n", strerror (errno)); kembali 1; } for (int reg=0;reg<300;reg++) { fprintf(stderr, "%d:%d\n", reg, wiringPiI2CReadReg8(fd, reg));fflush(stderr); penundaan (10); } kembalikan 0; }

Lari ketiga:

/********************************************************************************

* untuk membangun: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * untuk menjalankan: sudo./third.test.mpu9265 * * Program ini merupakan hasil dari yang kedua. Itu hanya membaca dari * register yang menunjukkan perbedaan antara satu run dan berikutnya.* ************************************************* ****************************/ #include #include #include #include #include #include int main(int argc, char** argv) { int deviceId = -1; if (0) { } else if (!strncmp(argv[1], "0x68", strlen("0x68"))) { deviceId = 0x68; } else if (!strncmp(argv[1], "0x69", strlen("0x69"))) { deviceId = 0x69; } puts("Mari kita lihat apa yang MPU9265 @ 0x20 katakan:"); salah = 0; int fd = wiringPiI2CSetup(deviceId); if (-1 == fd) { fprintf (stderr, "Tidak dapat membuka perangkat wiringPi I2C: %s\n", strerror (errno)); kembali 1; } for (int reg=61;reg<=73;reg++) { fprintf(stderr, "%d:%d\n", reg, wiringPiI2CReadReg8(fd, reg));fflush(stderr); penundaan (10); } for (int reg=111;reg<=112;reg++) { fprintf(stderr, "%d:%d\n", reg, wiringPiI2CReadReg8(fd, reg));fflush(stderr); penundaan (10); } for (int reg=189;reg<=201;reg++) { fprintf(stderr, "%d:%d\n", reg, wiringPiI2CReadReg8(fd, reg));fflush(stderr); penundaan (10); } for (int reg=239;reg<=240;reg++) { fprintf(stderr, "%d:%d\n", reg, wiringPiI2CReadReg8(fd, reg));fflush(stderr); penundaan (10); } kembalikan 0; }

Jadi apa yang kita pelajari sejauh ini? Gambar tabel dengan area yang disorot berwarna menunjukkan bahwa output tampaknya cocok dengan set register pertama.

Hasil sejauh ini dapat menimbulkan pertanyaan baru.

Pertanyaan: mengapa hanya ada satu hasil register untuk grup "eksternal"?

Pertanyaan: apa saja register yang tidak dikenal itu "?????"

Pertanyaan: karena program ini tidak digerakkan oleh interupsi, apakah permintaan data terlalu lambat? terlalu cepat?

Pertanyaan: dapatkah kita memengaruhi hasil dengan mencoba berbagai hal dengan sensor itu sendiri saat bekerja?

Langkah 6: Mari Menggali Lebih Dalam Bacaan / Data

Saya pikir langkah selanjutnya sebelum hal lain adalah meningkatkan program untuk:

• fleksibel dalam berapa banyak loop delay (ms)
• fleksibel dalam berapa banyak bacaan untuk memberikan rata-rata berjalan per register

(Saya harus melampirkan program sebagai file. Sepertinya ada masalah saat memasukkannya di sini. "fourth.test.mpu9265.c")

Berikut run menggunakan 10 pembacaan terakhir untuk rata-rata, pada loop 10ms:

sudo./fourth.test.mpu9265 0x68 10 10

61:255 0 255 0 255 0 255 0 0 0: 102 62:204 112 140 164 148 156 188 248 88 228: 167 63:189 188 189 187 189 188 188 188 188 189: 188 64: 60 40 16 96 208 132 116 252 172 36: 112 65: 7 7 7 7 7 7 7 7 7 7: 7 66:224 224 224 240 160 208 224 208 144 96: 195 67: 0 0 0 0 0 0 0 0 0 0: 0 68:215 228 226 228 203 221 239 208 214 187: 216 69: 0 255 0 255 255 0 255 0 0 0: 102 70:242 43 253 239 239 45 206 28 247 207: 174 71: 0 255 255 0 255 255 255 255 255 255: 204 72: 51 199 19 214 11 223 21 236 193 8: 117 73: 0 0 0 0 0 0 0 0 0 0: 0 111: 46 149 91 199 215 46 142 2 233 199: 132 112: 0 0 0 0 0 0 0 0 0 0: 0 189:255 0 255 0 255 0 0 255 0 255: 127 190: 76 36 240 36 100 0 164 164 152 244: 121 191:188 188 188 188 187 188 187 189 187 189: 187 192: 8 48 48 196 96 220 144 0 76 40: 87 193: 7 7 7 7 7 8 7 7 7 7: 7 194:208 224 144 240 176 240 224 208 240 224: 212 195: 0 0 0 0 0 0 0 0 0 0: 0 196:243 184 233 200 225 192 189 242 188 203: 209 197:255 0 0 0 255 0 255 0 0 255: 102 198:223 39 247 43 245 22 255 221 0 6: 130 199: 0 255 255 255 0 255 255 255 255 0: 178 200:231 225 251 1 252 20 211 216 218 16: 164 201: 0 0 0 0 0 0 0 0 0 0: 0 239: 21 138 196 87 26 89 16 245 187 144: 114 240: 0 0 0 0 0 0 0 0 0 0: 0

Kolom pertama, paling kiri adalah nomor register. Kemudian datang 10 bacaan terakhir untuk register itu. Akhirnya, kolom terakhir adalah rata-rata untuk setiap baris.

Sepertinya register 61, 69, 71, 189, 197, dan 199 hanya biner, atau siap / tidak siap, atau mereka adalah byte tinggi dari nilai 16-bit (negatif?).

Pengamatan menarik lainnya:

• register 65, 193 - nilai yang sangat stabil dan sama
• register 63, 191 - nilai yang sangat stabil dan sama
• register 73, 112, 195, 201, 240 - semuanya nol

Mari kita hubungkan pengamatan ini kembali ke gambar tabel multi-warna yang disorot dari sebelumnya.

Daftar 65 - suhu

Daftar 193 - ??????

Daftar 63 - akselerometer

Daftar 191 - ??????

Daftar 73 - eksternal

Daftar 112 dan seterusnya - ??????

Yah, kami masih memiliki yang tidak diketahui, namun, kami telah mempelajari sesuatu yang berguna.

Register 65 (suhu) dan register 63 (akselerometer) keduanya sangat stabil. Ini adalah sesuatu yang kami harapkan. Saya belum menyentuh sensornya; itu tidak bergerak, selain getaran insidental, karena robot sedang beristirahat di meja yang sama dengan komputer saya.

Ada satu tes menarik yang bisa kita lakukan untuk masing-masing register suhu/akselerometer ini. Untuk pengujian itu, kita membutuhkan versi program yang lain.

Langkah 7: Kami Mampu Mempengaruhi Suhu dan Percepatan

Pada langkah sebelumnya kami mempersempit setidaknya satu register untuk suhu, dan satu untuk akselerasi.

Dengan versi program berikutnya ("fifth.test.mpu9265.c"), kita sebenarnya dapat melihat perubahan yang terjadi pada kedua register. Silakan tonton video-videonya.

Lebih Menggali

Jika kita kembali dan melihat informasi register, kita melihat bahwa ada:

• tiga output 16 bit untuk giroskop
• tiga output 16 bit untuk akselerometer
• tiga output 16 bit untuk magnetometer
• satu output 16 bit untuk suhu

Namun, hasil yang diperoleh oleh program pengujian sederhana kami semuanya adalah keluaran 8 bit tunggal. (register tunggal).

Jadi mari kita coba lebih banyak pendekatan yang sama, tetapi kali ini membaca 16 bit, bukan 8.

Kita mungkin harus melakukan sesuatu seperti di bawah ini. Mari kita gunakan suhu sebagai contoh, karena hanya satu keluaran 16 bit.

//mendapatkan file deskriptor fd…

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8(fd, tempRegHi); int loByte = wiringPiI2CReadReg8(fd, tempRegLo); int hasil = hiByte<<8; // letakkan urutan hi 8 bit ke bagian atas dari hasil nilai 16 bit |= loByte; // sekarang tambahkan urutan lo 8 bit, menghasilkan angka 16 bit lengkap // cetak angka itu atau gunakan fungsi grafik tampilan horizontal dari sebelumnya

Dari langkah kami sebelumnya, kami telah melihat bahwa register 65 cukup stabil, sedangkan register 66 sangat bising. Karena 65 adalah byte urutan tinggi, dan 66 adalah byte urutan rendah, itu masuk akal.

Untuk membaca, kita bisa mengambil data register 65 apa adanya, tapi kita bisa rata-rata mengeluarkan nilai register 66.

Atau kita bisa rata-rata seluruh hasil.

Lihatlah video terakhir untuk bagian ini; itu menunjukkan membaca seluruh nilai suhu 16 bit. Kodenya adalah "sixth.test.mpu9265.c"

Langkah 8: Akselerometer dan Giroskop

Video untuk bagian ini menunjukkan keluaran dari akselerometer dan giroskop, menggunakan program uji "seventh.test.mpu9265.c". Kode itu dapat membaca 1, 2, atau 3 pasangan byte berturut-turut (hi dan lo byte) dan mengubah nilai menjadi nilai 16 bit tunggal. Dengan demikian, kita dapat membaca sumbu tunggal apa pun, atau kita dapat membaca dua sumbu secara bersamaan (dan menjumlahkan perubahannya), atau kita dapat membaca ketiganya (dan menjumlahkan perubahannya).

Untuk mengulangi, untuk fase ini, untuk Instructable ini, saya hanya ingin menjawab pertanyaan sederhana: "apakah robot berputar/berputar?". Saya tidak mencari nilai yang tepat, seperti, apakah itu berputar 90 derajat. Itu akan datang nanti ketika kita melakukan SLAM, tetapi itu tidak diperlukan untuk menghindari rintangan sederhana dan gerakan acak.

Langkah 9: (bekerja dalam Progres) Magnetometer

saat menggunakan alat i2cdetect, MPU9265 muncul sebagai 0x68 dalam tabel:

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --

Ada langkah ekstra yang diperlukan untuk membaca dari bagian magnetometer IMU.

Dari dokumen PDF register Invesense:

DAFTAR 37 SAMPAI 39 – I2C SLAVE 0 KONTROL

• DAFTAR 37 - I2C_SLV0_ADDR
• DAFTAR 38 - I2C_SLV0_REG
• DAFTAR 39 - I2C_SLV0_CTRL