Wallace - DIY Autonomous Robot - Bahagi 5 - Magdagdag ng IMU: 9 Mga Hakbang

2024 May -akda: John Day | [email protected]. Huling binago: 2024-01-30 13:14

Nagpapatuloy kami kasama si Wallace. Ang pangalang Wallace ay nagmula sa isang halo ng "Wall-E", at mula sa isang nakaraang proyekto (pagkilala sa boses), at sa paggamit ng "espeak" na utility, tunog ito ng medyo british. At tulad ng isang valet o butler. At iyon ang wakas na layunin: para sa proyektong ito na maging isang kapaki-pakinabang na bagay. Kaya "Wallace".

Si Wallace ay maaaring lumipat, maiiwasan niya ang mga hadlang gamit ang mga IR distansya sensor (kamakailan, sa paanuman pinirito sila (?) (Kailangang tingnan iyon kapag nagkakaroon ako ng isang pagkakataon), mayroon ding ilang mga acoustic distansya sensor (tatlo sa mga naging masama pareho oras, kasama ang isang MCP23017 expander), at sa wakas, ay maaaring makakita ng mga pagbabago sa motor-kasalukuyang upang malaman kapag ito ay nabunggo sa isang bagay.

Bilang karagdagan sa mga sensor, "naaalala" ni Wallace ang 100 galaw, at mayroong ilang panimulang pagsusuri na ginagamit ang kasaysayan ng paggalaw.

Ang layunin sa ngayon para sa Wallace ay subukan lamang upang magpatuloy na sumulong, at malaman kung kailan ito natigil sa ilang paulit-ulit na pattern (tulad ng sa isang sulok) at hindi talaga sumusulong.

Dumaan ako sa maraming mga pag-ulit para sa paggalaw at pag-navigate, at ang pare-pareho ang sakit ng ulo ay habang umiikot.

Dahil ang Wallace ay isang sinusubaybayan na robot, at nais kong panatilihing mas simple ang mga bagay sa software (para sa paglaon), upang maibalik ko lang sa kanya ang pivot / paikutin sa lugar. Kaya, maglapat ng pantay ngunit kabaligtaran ng ikot ng kuryente / tungkulin sa mga motor.

Ang problemang nakasalamuha ay dahil sa disenyo ng Agent 390 robot platform. Ang mga sinturon ng track ay may posibilidad na kuskusin laban sa mga gilid. At ang mas masahol pa, ang isang panig ay higit pa kaysa sa iba.

Sa sahig at dumidiretso, hindi ito naging problema. Lumilitaw ito sa carpeting. Pinili kong panatilihin ang Wallace mula sa carpeting pagkatapos na ang mga track ay naging marumi (pumili sila ng dumi na napakadali).

Ang totoong problema ay kapag pivoting sa sahig.

Kung mayroon akong software na mag-apply ng isang mataas na antas ng cycle ng tungkulin, pagkatapos ay higit pa o mas mababa na patuloy na lumiliko. Gayunpaman, sa panahon ng isang mababang ikot ng tungkulin, maaari o hindi talaga ito nakabukas. O maaari itong lumiko nang kaunti at pagkatapos ay bumagal. Ang pagkilos ng pivoting ay tila hindi mapigil sa pamamagitan ng software, o sa pinakamahirap.

Lumilitaw ang problema sa panahon ng pag-navigate at paglipat o paglayo sa mga hadlang. Maaari itong mag-swing masyadong wildly ang layo, o maaari itong makaalis sa pagtatangka na gumawa ng isang minutong paglilipat, nang hindi talaga gumagalaw.

At sa gayon ang paliwanag sa itaas ay nag-udyok sa Instructable na ito.

Sa una, nais kong itapon, o antalahin ang pagpapakilala sa isang unit ng paggalaw-galaw (IMU), sapagkat sila A) kumplikado, B) maingay, C) mga error ay maaaring ipakilala sa paglipas ng panahon, atbp, atbp. naging magagawa natin nang napakahusay sa pamamagitan ng pagtalon nang maaga sa mga sensor ng laser ng time-of-flight na IR. At maaari naming - gamit ang mga laser maaari naming malaman kung ang robot ay umiikot o hindi, sa pamamagitan ng pagsubaybay sa mga pagbabago sa distansya.

Sa katunayan, maaari rin nating (uri ng) gawin iyon ngayon, gamit ang mga acoustic sensor.

Gayunpaman, lahat ng iyon ay isang napaka-di-derekta, kumplikadong paraan upang sagutin ang isang simpleng tanong: "Naiikot ba kami o hindi?"

Tila sa akin na ang paglukso upang magamit ang mga sensor ng ToF laser ay magdadala sa akin sa susunod na antas ng software; katulad, SLAM (Sabayang Lokalisasyon at Pagma-map). Hindi pa ako handa na pumunta doon.

Mahusay na bagay na gumawa ng isang proyekto ng robot sa mga layer, na ang mga unang (mas mababang) mga layer ay mas simple, at ang huli (itaas) na mga layer ay mas abstract at pagharap sa mas mahirap na mga isyu.

Maaaring maiisip ang mga layer ng tulad nito:

1. batayan ng pisikal na robot / batayan ng istrakturang mekanikal
2. rudimentary drive system (Raspberry, Roboclaw, motors, cabling, atbp, pangunahing software, driven na keyboard)
3. mahahalagang circuitry upang suportahan ang mga sensor (bi-directional boltahe shifter, port expander, E-Stop, pamamahagi ng kuryente, atbp)
4. mga sensor ng pag-iwas sa balakid (acoustic, IR)
5. mahalaga, pangunahing pagpoposisyon at paggalaw - pagtuklas (accelerometer, gyro, magnetometer, motor encoder, wheel encoder)

Maaari kang magkaroon ng iyong sariling listahan. Ang mga puntos tungkol sa listahang ito ay marahil ay dapat mong gawin ang mga ito nang higit pa o mas kaunti sa pagkakasunud-sunod na iyon, at gayun din kung gumugol ka ng ilang oras sa bawat layer upang makuha ang bawat isa sa isang mabuting estado ng pagtatrabaho, makakatulong iyon sa iyo sa paglaon habang mas nagiging kumplikado ang mga bagay.

Ang listahan sa itaas ay maaaring higit pa o mas mababa na nai-map sa mga haka-haka na layer sa software.

• SLAM (Sabayang Lokalisasyon at Pagma-map)
• Pagkontrol at Kamalayan ng Pagkilos, Pag-ikot
• Pangunahing Pag-iwas sa Balakid
• Pagkontrol at Pagtuklas ng Data ng Sensor
• Mahalagang Paggalaw Pasulong, Paatras, Kaliwa at Kanan, Bilis, Mabagal, Huminto

Tulad ng nakikita mo, para sa listahang ito, ang mga unang item ay ang pinakamataas, mas kumplikadong mga layer na tumatalakay sa mas maraming mga abstract na isyu at katanungan, tulad ng "saan ako" at "saan ako pupunta", habang ang mga huling item ay ang babaan ang mga layer ng software na hawakan ang "kung paano makipag-usap / makinig sa sensor A" o "kung paano ilipat ang gulong ito".

Ngayon, hindi ko sinasabi na kapag nagsimula ka sa isang layer, nakumpleto mo na ito at pagkatapos ay nasa susunod na layer, hindi na babalik sa naunang isa. Ang isang proyekto ng robot ay maaaring maging katulad ng moderno, umuulit na mga pamamaraan sa pagbuo ng software (maliksi, SCRUM, atbp).

Sinasabi ko lang na maglaan ng oras sa bawat isa. Kailangan mong balansehin kung magkano ang gagawin sa bawat isa, at magpasya ang iyong sinusubukan sa isang tiyak na layer na nagkakahalaga ng oras at gulo.

Mayroong isang tiyak na "salungatan" o "pag-igting" sa pagitan ng dalawang magkakalaban na ideya o direksyon.

Ang isa ay ang tatawagin kong "plug-n-play" upang malutas ang problema A.

Ang isa pa ay DIY (gawin ito sa iyong sarili). At iyon ay maaaring hindi kahit na ang pinakamahusay na label para sa iba pang ideyang ito.

Narito ang isang halimbawa ng bawat isa, sana makita mo ang pag-igting o hidwaan sa pagitan ng dalawang pagpipilian.

Para sa halimbawang ito, lumpingan natin ang SLAM, pag-iwas sa balakid, at mahahalagang pangunahing kilusan lahat bilang isang problema upang malutas nang sabay.

1. Kung magpasya kaming pumunta sa ruta ng plug-n-play, agad kaming tumalon (depende sa badyet) sa mga bagay tulad ng mga nangungunang naka-rotate na laser, o camera ng deep-of-field, o mga ToF laser, at ang IMU (paksa nito Maituturo).
2. Kung sa kabilang banda, nais nating puntahan ang pangalawang ruta, maaari naming subukang kunin ang bawat posibleng kaunting impormasyon mula sa ilang mga acoustic sensor o IR sensor, o wala man lang sensor. Gumagamit lang kami ng pagsubaybay sa kasalukuyang motor (bump)

Ano ang masasabi tungkol sa # 1 vs # 2? Ang isang bagay ay may natutunan pa tayo sa pamamagitan ng paggawa ng # 2. Ang mga limitasyon ng pagkakaroon lamang ng mga acoustic sensor upang gumana, pinipilit kaming mag-isip tungkol sa maraming mga isyu.

Sa kabilang banda, kung masyado tayong nakatuon sa paggawa ng mga bagay sa pamamagitan ng # 2, maaaring nagsasayang tayo ng oras, dahil humihiling tayo ng higit sa dapat nating mula sa mga acoustic sensor.

Isa pang konsepto o ideya na pag-iisipan: Anong pinaghalong hardware at software ang pinakamahusay na sumasagot sa mga tanong ng "paano", at kung anong halo ng software (at hardware?) Ang sumasagot sa tanong na "ano", "kailan", "saan". Sapagkat ang "paano" ay karaniwang isang mas mababang antas ng tanong kung saan ang "ano", "kailan", at "saan" nakasalalay upang makakuha ng isang sagot.

Gayunpaman, ang lahat sa itaas ay isang bagay lamang na iisipin.

Sa aking kaso, pagkatapos ng maraming pagsisikap at pagkakaroon ng pare-parehong nakakainis na isyu ng track-alitan at hindi makakuha ng pare-pareho na kontrol at paggalaw, oras na upang gumawa ng iba pa.

Kaya't ito ay Makatuturo - isang IMU.

Ang layunin ay na kung sinabi ng IMU na ang robot ay HINDI pivoting, pinapataas namin ang cycle ng tungkulin. Kung masyadong mabilis kaming nag-pivote, binabawasan namin ang cycle ng tungkulin.

Hakbang 1: Ang IMU Sensor

At sa gayon ang aming susunod na sensor na idaragdag sa Wallace ay ang IMU. Pagkatapos ng ilang pagsasaliksik, nag-aayos ako sa isang MPU6050. Ngunit sa oras na ito, ang MPU9050 (at kahit kamakailan lamang, ang MPU9250) ay tila isang mas mahusay na ideya.

Ang pinagmulan ko ay ang Amazon (sa U. S.). Kaya inorder ko silang dalawa.

Ang nakuha ko sa katotohanan (tila walang kontrol dito; iyon ang hindi ko gusto tungkol sa Amazon) ay ang dalawang MPU92 / 65. Nagtataka ako ng kaunti tungkol sa pagtatalaga. Tingnan ang mga imahe; iyon ay tila isang "pamilya" na pagtatalaga. Sa anumang kaso, iyon ang naiipit ko.

Ang pagdaragdag nito ay napaka-simple - kumuha ng isang board ng proto na may mga track sa pagkonekta, maghinang ang sensor upang makasakay, magdagdag ng isang 10-pin na terminal block ng tornilyo (nakuha ko ang minahan mula sa Pololu).

Upang ma-minimize ang anumang pagkagambala, sinubukan kong ilagay ang mga sensor na ito na malayo sa lahat ng bagay.

Nangangahulugan din iyon ng paggamit ng ilang mga nylon bolts / nut.

Gagamitin ko ba ang I2C protocol. Sana ang kabuuang haba ng kawad ay hindi magiging napakasama.

Maraming impormasyon sa ibang lugar tungkol sa mga pangunahing koneksyon at antas ng boltahe, atbp, kaya't hindi ko na uulitin ito dito.

Hakbang 2: Ang Mga Bagay Ay Hindi Laging Malinis, Madali

Sa pagsusulat na ito, tila walang masyadong online para sa partikular na MPU-92/65. Ano ang magagamit, tulad ng karamihan sa mga sensor, tila mga halimbawa gamit ang Arduino.

Sinusubukan kong gawing medyo magkakaiba ang Mga Instruction na ito sa pamamagitan ng paglalahad ng isang hindi gaanong malinis na proseso, dahil ang mga bagay ay hindi laging gumagana kaagad.

Sa palagay ko ang mga Instructable na ito ay mas katulad sa isang blog kaysa sa tuwid na A-B-C, 1-2-3 "ganito mo ito gawin".

Hakbang 3: Paunang Pagsubok

Mula sa mga imahe sa nakaraang hakbang, ang pula at itim na mga wire na papunta sa mga sensor ay syempre VCC (5V) at GND. Ang berde at dilaw na mga wire ay ang mga koneksyon sa I2C.

Kung nagawa mo ang iba pang mga proyekto ng I2C, o sumusunod sa mga seryeng ito, alam mo na ang tungkol sa "i2cdetect", at iyon ang unang hakbang upang malaman kung maaaring makita ng Raspberry ang bagong sensor.

Tulad ng nakikita mo mula sa mga imahe sa hakbang na ito, ang aming unang pagtatangka ay hindi matagumpay. Ang IMU ay hindi lilitaw (dapat na aparato id 0x68).

Gayunpaman, ang magandang balita ay ang operating bus ng I2C. Nakakakita kami ng isang aparato 0x20 at ito ang MCP23017 port expander (kasalukuyang responsable para sa mga HCSR04 acoustic sensor).

Hindi madaling makita sa imahe, ngunit nakakonekta ko ang parehong kulay na berde at dilaw na mga wire mula sa IMU hanggang sa MCP23017 (tingnan ang ibabang kaliwa sa imahe)

Kailangan naming gumawa ng ilang pag-troubleshoot.

Hakbang 4: Pag-troubleshoot

Gamit ang setting ng pagpapatuloy sa isang voltmeter (ang may mataas na tono na tono), sinubukan ko ang mga koneksyon ng VCC (5V), GND, SDA, at SCL. Mabuti ang mga iyon.

Susunod na pagsubok ay upang idiskonekta ang MCP23017 mula sa I2C bus, naiwan lamang ang MPU-92/65 sa bus. Iyon ay napatunayan na walang bunga - "i2cdetect" pagkatapos ay nagpakita ng walang mga aparato.

Kaya, sa susunod, inalis ko ang sensor mula sa totem poste, at muling i-wire ito diretso sa 5V-to-3V bidirectional bus; ibig sabihin, diretso sa Raspberry. (mas maikli na mga wire?).

At voila. This time may tagumpay. Nakikita namin ang 0x68 na nagpapakita na gumagamit ng "i2cdetect".

Ngunit hindi pa namin alam kung bakit ito gumana sa oras na ito. Maaaring ito ang haba ng mga wires? Ang dating lokasyon?

Tandaan: Hindi ito gumawa ng anumang pagkakaiba kung ang ADO ay may saligan o hindi. Maaaring mayroong mga on-board na pullup at pull-down resistors. Ang totoo ay maaaring totoo para sa FSYNC.

Susunod, muling kinonekta ko ang MCP23017. Kaya ngayon mayroon kaming dalawang mga aparato sa I2C bus. (tingnan ang imahe). Ang mga tagumpay, nakikita natin ngayon ang parehong 0x20 at 0x68 na may i2cdetect.

Ang mga video ay napunta sa medyo higit pa sa kung ano ang nangyari sa panahon ng pag-troubleshoot.

Hakbang 5: Pagbasa ng Data ng Sensor

Iba`t ibang mga Approach

Napagpasyahan kong gumawa ng maraming diskarte upang makakuha ng kapaki-pakinabang na impormasyon mula sa sensor. Narito ang mga ito, wala sa anumang pagkakasunud-sunod:

1. subukan ang ilang pangunahing programa
2. tumingin sa pamamagitan ng ilang mga online na dokumentasyon sa mga rehistro
3. tingnan ang mga halimbawa at / o code ng iba

Bakit ang mga pamamaraang ito? Bakit hindi na lang maghanap para sa ilang mayroon nang library o code?

Sa pamamagitan ng pag-eksperimento at pagsubok sa ilang mga ideya, mas mahusay nating maihihigop ang ilang kaalaman tungkol sa hindi lamang sa partikular na sensor na ito, ngunit nakakakuha rin ng ilang pamamaraan, kasanayan, at mga paraan ng pag-iisip tungkol sa pagharap ng isang bagong bagay, at isang bagay na maaaring walang maraming dokumentasyon; isang bagay na maaaring may maraming hindi alam.

Gayundin, kapag nakapaglaro na kami at nasubukan ang ilan sa aming sariling mga ideya at nakakuha ng kaunting pananaw, nasa mas mahusay na posisyon kami upang suriin ang code o silid aklatan ng iba.

Halimbawa, pagkatapos tumingin sa ilang C ++ code para sa MPU9250 sa github, napagtanto kong pinipilit ako nitong gumamit ng mga interrupts, na hindi ko pa nais gawin.

Gayundin, ito ay may dagdag na mga bagay tulad ng pagkakalibrate; muli, isang bagay na hindi ko pa interesado.

Maaaring ang kailangan kong gawin upang masagot ang simpleng tanong na "ang robot na umiikot na oo o hindi" ay masasagot nang napakasimpleng sa pamamagitan lamang ng pagbabasa ng ilang mga rehistro.

Mga rehistro

Sa pagsusulat na ito, tila walang gaanong magagamit sa sensor na ito. Sa katunayan, kung titingnan mo ang mga imaheng kasama ng Instructable na ito, at suriin nang mabuti ang mga inskripsiyon sa mga aktwal na chips, pinapaisip ako kung hindi ito isang knock-off. Hindi ko naiugnay ang nakikita ko sa anumang bagay mula sa Invense. Anuman, pinili kong tingnan ang rehistro-impormasyon para sa mga modelo na nakita ko: ang MPU-6050, at ang MPU-9250.

Sa parehong kaso, ang sumusunod ay pareho para sa pareho. At para sa mga nagsisimula, ipinapalagay namin na magiging pareho din ito para sa MPU-92/65 na ito.

59 hanggang 64 - mga sukat ng accelerometer

65, 66 - mga sukat ng temperatura 67 hanggang 72 - mga sukat ng gyroscope 73 hanggang 96 - data ng panlabas na sensor

Isang item ng tala: Ang MPU-6050 ay lilitaw na HINDI magkaroon ng isang magnetometer, samantalang ang MPU-9250 (at ipinapalagay namin ang isang ito, din) ay mayroong isa.

Ang ilan pang mga kagiliw-giliw, inaasahan na kapaki-pakinabang na impormasyon na nakuha mula sa rehistro-dokumento:

Impormasyon ng magnet

magnetometer id: 0x48 rehistro 00 hanggang 09: 00H WIA 0 1 0 0 1 0 0 0 01H INFO INFO7 INFO6 INFO5 INFO4 INFO3 INFO2 INFO1 INFO0 INFO0 02H ST1 0 0 0 0 0 0 DOR DRDY 03H HXL HX7 HX6 HX5 HX4 HX3 HX2 HX1 HX0 04H 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 HZ HZ HZ HZ HZ HZ HZ HZ HZ8 HZ7 HZ8 ST2 0 0 0 BITM HOFL 0 0 0 isang pagkasira ng kung ano ang ibig sabihin ng bawat rehistro: HXL [7: 0]: Ang data ng pagsukat ng X-axis ay mas mababa 8bit HXH [15: 8]: Ang data ng pagsukat ng X-axis ay mas mataas 8bit HYL [7: 0]: Y-axis data ng pagsukat mas mababa 8bit HYH [15: 8]: Ang data ng pagsukat ng Y-axis mas mataas na 8bit HZL [7: 0]: Ang data ng pagsukat ng Z-axis ay mas mababa 8bit HZH [15: 8]: Ang data ng pagsukat ng Z-axis ay mas mataas 8bit

Programming

Ang isa pang kaunting impormasyon mula sa mga register doc ay ang tila 100 lamang ang mga rehistro. Kaya't ang isang taktika ay maaaring magsulat ng isang simpleng programa na nag-a-access sa aparato (0x68) at nagtatangkang basahin ang isang serye ng mga pagrehistro nang sunud-sunod, nang walang pagsasaalang-alang sa kanilang kahulugan, upang makita lamang kung anong data ang maaaring makita.

At pagkatapos, gawin ang sunud-sunod na mga pass, gamit ang parehong code, at ihambing ang data mula sa isang pass kumpara sa susunod.

Ang ideya ay maaari nating matanggal ang anumang mga pagrehistro na tila walang data (zero o FF?) O na talagang hindi nagbabago, at maaari rin kaming mag-focus sa mga nagbabago.

Pagkatapos, isa na tinitingnan lamang namin ang mga nagbabago, idagdag sa isang pag-andar sa pag-average na nag-average ng pinakabagong mga nabasa na N ng rehistro na iyon, upang makita kung sa katunayan ay may isang tiyak na matatag na halaga para sa rehistro na iyon. Ipagpapalagay nito na pinapanatili namin ang sensor nang napakatahimik, at sa parehong lokasyon.

Sa wakas, maaari naming marahang subukan ang mga bagay gamit ang sensor, tulad ng pag-nudging nito (accelerometer, gyro), o paghihip dito (temperatura), o pag-ikot nito (ang nakaraang dalawang plus magnetometer) at makita kung ano ang epekto nito sa mga halaga.

Gusto kong gamitin ang wiringPi library hangga't maaari. Mayroon itong suporta para sa I2C.

Unang takbo:

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

* to build: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * to run: sudo./first.test.mpu9265 * * Ang program na ito ay naglalabas lamang ng isang saklaw ng (posibleng) mga rehistro mula sa MCP23017, * at pagkatapos ay mula sa MPU9265 (o anumang iba pang MPU sa 0x68 address na iyon) * * Ginamit ko ito upang mapatunayan kung makakabasa pa ako mula sa sensor, dahil mayroon na akong * kumpiyansa sa MCP23017. * ***** ***** {naglalagay ("Tingnan natin kung ano ang sasabihin ng MCP23017 @ 0x20:"); errno = 0; int aparatoId1 = 0x20; int fd1 = mga kablePiI2CSetup (aparatoId1); kung (-1 == fd1) {fprintf (stderr, "Hindi mabubuksan ang aparato ng kabelPi I2C:% s / n", strerror (errno)); ibalik ang 1; } para sa (int reg = 0; reg <300; reg ++) {fprintf (stderr, "% d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); antala (10); } naglalagay (""); naglalagay ("Tingnan natin kung ano ang sasabihin ng MPU9265 @ 0x20:"); errno = 0; int aparatoId2 = 0x68; int taut2 = mga kablePiI2CSetup (aparatoId2); kung (-1 == fd2) {fprintf (stderr, "Hindi mabubuksan ang aparato ng kabelPi I2C:% s / n", strerror (errno)); ibalik ang 1; } para sa (int reg = 0; reg <300; reg ++) {fprintf (stderr, "% d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); antala (10); } naglalagay (""); ibalik ang 0; }

Ang pangalawang pagtakbo:

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

* to build: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * to run: sudo./second.test.mpu9265 * * Ang program na ito ay naglalabas ng numero ng rehistro kasabay ng nabasang halagang. * * Ginagawa nitong kapaki-pakinabang sa tubo (redirect) ang output sa isang file, at pagkatapos ay * maraming mga pagpapatakbo ay maaaring gawin, upang ihambing. Maaari itong magbigay ng ilang pananaw sa * kung anong rehistro ang mahalaga, at kung paano maaaring kumilos ang data. * ***** ***** argv) {int deviceId = -1; kung (0) {} iba pa kung (! strncmp (argv [1], "0x20", strlen ("0x20"))) {deviceId = 0x20; } iba pa kung (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } iba pa kung (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } naglalagay ("Tingnan natin kung ano ang sasabihin ng MPU9265 @ 0x20:"); errno = 0; int taut = mga kablePiI2CSetup (aparatoId); kung (-1 == fd) {fprintf (stderr, "Hindi mabubuksan ang aparato ng wiringPi I2C:% s / n", strerror (errno)); ibalik ang 1; } para sa (int reg = 0; reg <300; reg ++) {fprintf (stderr, "% d:% d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); antala (10); } ibalik ang 0; }

Ang pangatlong run:

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

* to build: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * to run: sudo./third.test.mpu9265 * * Ang program na ito ay isang resulta ng pangalawa. Nagbabasa lamang ito mula sa * mga rehistro na nagsasaad ng pagkakaiba sa pagitan ng isang takbo at ng susunod.* ***** ***** argv) {int deviceId = -1; kung (0) {} iba pa kung (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } iba pa kung (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } naglalagay ("Tingnan natin kung ano ang sasabihin ng MPU9265 @ 0x20:"); errno = 0; int taut = mga kablePiI2CSetup (aparatoId); kung (-1 == fd) {fprintf (stderr, "Hindi mabubuksan ang aparato ng wiringPi I2C:% s / n", strerror (errno)); ibalik ang 1; } para sa (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "% d:% d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); antala (10); } para sa (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "% d:% d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); antala (10); } para sa (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "% d:% d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); antala (10); } para sa (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "% d:% d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); antala (10); } ibalik ang 0; }

Kaya ano ang natutunan natin sa ngayon? Ang imahe ng talahanayan na may kulay na naka-highlight na mga lugar ay nagpapahiwatig na ang output ay tila tumutugma sa mga unang hanay ng mga rehistro.

Ang mga resulta sa ngayon ay maaaring makabuo ng mga bagong katanungan.

Tanong: bakit may isang resulta lamang sa pagrehistro para sa "panlabas" na pangkat?

Tanong: ano ang lahat ng mga hindi kilalang rehistro na "??????"

Tanong: dahil ang programa ay hindi nagaganyak, hiniling ba nito na masyadong mabagal ang data? masyadong mabilis?

Tanong: maaari ba nating maapektuhan ang mga resulta sa pamamagitan ng pagsubok ng mga bagay gamit ang sensor mismo habang tumatakbo ito?

Hakbang 6: Maghukay Pa Pa Sa Mga Pagbasa / Data

Sa palagay ko ang susunod na hakbang bago ang anumang bagay ay upang mapahusay ang programa upang:

• maging may kakayahang umangkop sa kung magkano ang pagkaantala ng loop (ms)
• maging may kakayahang umangkop sa kung gaano karaming mga pagbabasa upang magbigay ng isang tumatakbo average sa bawat rehistro

(Kailangan kong ikabit ang programa bilang isang file. Tila isang isyu sa pagpasok dito. "Ika-apat.test.mpu9265.c")

Narito ang isang run gamit ang huling 10 pagbasa para sa isang average, sa isang 10ms loop:

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

Ang una, kaliwa-pinaka-haligi ay ang numero ng rehistro. Pagkatapos ay dumating ang huling 10 pagbasa para sa rehistro na iyon. Panghuli, ang huling haligi ay ang average para sa bawat hilera.

Mukhang ang mga rehistro 61, 69, 71, 189, 197, at 199 ay alinman sa binary lamang, o handa / hindi handa, o sila ang mataas na byte ng isang 16-bit na halaga (negatibo?).

Iba pang mga kagiliw-giliw na obserbasyon:

• nagrerehistro 65, 193 - napaka-matatag at parehong halaga
• magparehistro 63, 191 - napaka-matatag at parehong halaga
• nagrerehistro 73, 112, 195, 201, 240 - lahat ay zero

Iugnay natin ang mga obserbasyong ito pabalik sa maraming kulay, naka-highlight na imahe ng talahanayan mula nang mas maaga.

Magrehistro 65 - temperatura

Magrehistro 193 - ??????

Magrehistro 63 - accelerometer

Magrehistro 191 - ??????

Magrehistro 73 - panlabas

Magrehistro 112 at sa - ??????

Sa gayon, mayroon pa rin kaming mga hindi alam, gayunpaman, natutunan namin ang isang bagay na kapaki-pakinabang.

Magrehistro ng 65 (temperatura) at magrehistro ng 63 (accelerometer) ay parehong napakatatag. Ito ay isang bagay na aasahan natin. Hindi ko pa nahawakan ang sensor; hindi ito gumagalaw, maliban sa anumang hindi sinasadyang mga panginginig, dahil ang robot ay nakasalalay sa parehong mesa ng aking computer.

Mayroong isang kagiliw-giliw na pagsubok na maaari naming para sa bawat isa sa mga rehistro ng temperatura / accelerometer. Para sa pagsubok na iyon, kailangan pa namin ng isa pang bersyon ng programa.

Hakbang 7: Nakakaapekto Kami sa Temperatura at Pagpapabilis

Sa mga nakaraang hakbang pinaliit namin ang kahit isang rehistro para sa temperatura, at isa para sa pagpapabilis.

Sa susunod na bersyon ng programa na ito ("ikalawa.test.mpu9265.c"), talagang makikita natin ang isang pagbabago na nagaganap para sa parehong mga pagrehistro. Panoorin ang mga video.

Higit pang paghuhukay

Kung babalik tayo at tingnan ang impormasyon sa pagrehistro, nakikita natin na may:

• tatlong 16 bit na output para sa gyroscope
• tatlong 16 bit na output para sa accelerometer
• tatlong 16 bit na output para sa magnetometer
• isang 16 bit na output para sa temperatura

Gayunpaman, ang mga resulta na nakuha ng aming simpleng mga programa sa pagsubok ay lahat ng solong 8 bit na output. (solong rehistro).

Kaya't subukan natin ang higit pa sa parehong diskarte, ngunit sa oras na ito basahin ang 16 bits sa halip na 8.

Marahil ay kakailanganin nating gumawa ng isang bagay tulad sa ibaba. Gamitin natin ang temperatura bilang isang halimbawa, dahil isa lamang ito 16 na output.

// kumuha ng deskriptor ng file na …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = mga kablePiI2CReadReg8 (taut, tempRegHi); int loByte = mga kablePiI2CReadReg8 (taut, tempRegLo); int resulta = hiByte << 8; // ilagay ang hi order 8 bits sa itaas na bahagi ng isang 16 bit na resulta ng halaga | = loByte; // ngayon idagdag sa lo order 8 bits, magbubunga ng isang kumpletong numero ng 16 bit // i-print ang numerong iyon o gamitin ang display pahalang na graphing function mula dati

Mula sa aming nakaraang mga hakbang na nakita namin na ang pagrehistro ng 65 ay medyo matatag, habang ang pagrehistro ng 66 ay napakaingay. Dahil 65 ang hi order byte, at 66 ang mababang byte ng order, may katuturan iyon.

Para sa pagbabasa, maaari naming kunin ang data ng rehistro ng 65 na as-is, ngunit maaari naming i-average ang mga halaga ng pagrehistro ng 66.

O maaari lang naming average ang buong resulta.

Tingnan ang huling video para sa bahaging ito; ipinapakita nito ang pagbabasa ng buong 16 na bit na halaga ng temperatura. Ang code ay "pang-anim.test.mpu9265.c"

Hakbang 8: Ang Accelerometer at Gyroscope

Ang mga video para sa seksyong ito ay nagpapakita ng output mula sa accelerometer at gyroscope, na gumagamit ng isang test program na "ikapitong.test.mpu9265.c". Ang code na iyon ay maaaring mabasa ang 1, 2, o 3 magkasunod na byte-pares (hi at lo bytes) at binabago ang mga halaga sa isang solong 16 bit na halaga. Kaya, maaari nating basahin ang anumang solong axis, o maaari nating basahin ang dalawa sa mga ito (at binubuo nito ang mga pagbabago), o maaari nating basahin ang lahat ng tatlo (at binubuo nito ang mga pagbabago).

Upang ulitin, para sa yugtong ito, para sa Instructable na ito, naghahanap lang ako upang sagutin ang isang simpleng tanong: "umikot ba ang robot / pivot?". Hindi ako naghahanap para sa anumang tumpak na halaga, tulad ng, umikot ito ng 90 degree. Darating iyon mamaya pagdating sa paggawa ng SLAM, ngunit hindi ito kinakailangan para sa simpleng pag-iwas sa balakid at random na paggalaw.

Hakbang 9: (magtrabaho sa Isinasagawa) ang Magnetometer

kapag ginagamit ang tool na i2cdetect, ang MPU9265 ay nagpapakita ng 0x68 sa talahanayan:

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: -- -- -- -- -- -- -- --

Mayroong mga karagdagang hakbang na kinakailangan upang mabasa mula sa bahagi ng magnetometer ng IMU.

Mula sa Invesense ay nagrerehistro ng PDF doc:

REGISTERS 37 TO 39 - I2C SLAVE 0 CONTROL

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