Wallace - DIY autonóm robot - 5. rész - IMU hozzáadása: 9 lépés

2024 Szerző: John Day | [email protected]. Utoljára módosítva: 2024-01-30 09:42

Wallace -nal együtt haladunk. A Wallace név a "Wall-E" keverékéből és egy korábbi projektből (hangfelismerés) származik, és az "espeak" segédprogram használatakor kissé briten hangzott. És mint egy inas vagy inas. És ez a végső cél: hogy ez a projekt valami hasznossá váljon. Így "Wallace".

Wallace mozoghat, elkerülheti az akadályokat az IR távolságérzékelők használatával (nemrégiben valahogy megsültek (?) idő, az MCP23017 bővítővel együtt), és végül képes érzékelni a motoráram változásait, hogy megtudja, mikor ütközik valamibe.

Az érzékelőkön kívül Wallace "emlékszik" a 100 mozdulatra, és van néhány kezdetleges elemzése a mozgástörténet felhasználásával.

A Wallace eddigi célja pusztán az, hogy megpróbáljon előre haladni, és hogy mikor ragadt meg valamilyen ismétlődő mintában (például egy sarokban), és nem igazán halad előre.

Több iteráción mentem keresztül a mozgáshoz és a navigációhoz, és az állandó fejfájás a forgás során volt.

Mivel Wallace lánctalpas robot, és szerettem volna egyszerűbbé tenni a dolgokat a szoftverben (későbbre), hogy fordulhassak, csak el kell forgatnom a helyén. Így egyenlő, de ellentétes teljesítmény / terhelési ciklust alkalmazzon a motorokra.

A felmerült probléma az Agent 390 robotplatform kialakításának köszönhető. A nyomszíjak hajlamosak az oldalukra dörzsölni. És ami még rosszabb, az egyik oldal többet tesz, mint a másik.

A padlón és az egyenes úton nem volt probléma. Ez megjelenik a szőnyegen. Úgy döntöttem, hogy Wallace -t távol tartom a szőnyegektől, miután a zeneszámok mocskosak lettek (rendkívül könnyen felveszik a piszkot).

Az igazi probléma a padlón való elforgatás.

Ha a szoftvert magas szintű terhelési ciklusban alkalmazom, akkor többé -kevésbé következetesen fordul. Alacsony terhelési ciklus során azonban ténylegesen elfordulhat vagy nem. Vagy fordulhat egy kicsit, majd lelassul. Úgy tűnik, hogy a forgó művelet a szoftver segítségével ellenőrizhetetlen, vagy a legjobb esetben nagyon nehéz.

A probléma navigáció közben és az akadályok körül vagy azoktól való elmozdulás során jelenik meg. Vagy túl vadul lendülhet el, vagy elakadhat, amikor nagyon apró műszakokat próbál végrehajtani, anélkül, hogy valóban megmozdulna.

És így a fenti magyarázat motiválta ezt az Instructable -t.

Kezdetben el akartam hagyni a mozgásérzékelő egység (IMU) bevezetését vagy késleltetni annak bevezetését, mert ezek A) bonyolultak, B) zajosak, C) hibák jelentkezhetnek idővel, stb., Stb. az volt, hogy nagyon jól teljesíthetünk, ha előreugrunk a repülési idő infravörös lézeres érzékelőihez. És a lézerek segítségével megtudhattuk, hogy a robot forog -e vagy sem, a távolság változásának követésével.

Valójában most is (valahogy) megtehetjük ezt az akusztikus érzékelőkkel.

Mindez azonban nagyon közvetett, bonyolult módja egy egyszerű kérdés megválaszolásának: "forogtunk vagy sem?"

Úgy tűnt számomra, hogy a ToF lézeres érzékelők használatának folytatása a szoftver következő szintjére visz; nevezetesen a SLAM (szimultán lokalizáció és leképezés). Még nem álltam készen arra, hogy odamenjek.

Jó dolog egy robotprojektet rétegekben elvégezni, az első (alsó) rétegek egyszerűbbek, az utóbbi (felső) rétegek pedig elvontabbak és nehezebb problémákat oldanak meg.

A rétegek ilyesmire gondolhatnak:

1. robot fizikai keret / mechanikai szerkezeti alap
2. kezdetleges meghajtórendszer (Málna, Roboclaw, motorok, kábelezés, stb., alapszoftver, billentyűzetvezérelt)
3. alapvető áramkör az érzékelők támogatásához (kétirányú feszültségváltó, portbővítő, E-Stop, áramelosztás stb.)
4. akadálykerülő érzékelők (akusztikus, IR)
5. alapvető, alapvető pozicionálás és mozgásérzékelés (gyorsulásmérő, giroszkóp, magnetométer, motorkódolók, kerék enkóderek)

Saját listát készíthet. A listával kapcsolatban az a lényeg, hogy valószínűleg ezeket többé -kevésbé ebben a sorrendben kell elvégeznie, és azt is, hogy ha minden rétegen eltölt egy kis időt, hogy mindegyiket jó állapotba hozza, akkor ez később segíthet, amikor a dolgok bonyolultabbá válnak.

A fenti lista többé -kevésbé hozzárendelhető ezekhez a fogalmi rétegekhez a szoftverben.

• SLAM (szimultán lokalizáció és leképezés)
• Mozgás, forgásirányítás és tudatosság
• Alapvető akadálykerülés
• Az érzékelőadatok ellenőrzése és észlelése
• Alapvető mozgás előre, hátra, balra és jobbra, gyorsítás, lassítás, leállítás

Amint láthatja, ebben a listában az első elemek a felső, bonyolultabb rétegek, amelyek elvontabb kérdéseket és kérdéseket kezelnek, mint például a "hol vagyok" és a "hová megyek", míg az utóbbi tételek a alsó szoftverrétegek, amelyek kezelik az "hogyan kell beszélni/hallgatni az A érzékelőt" vagy "hogyan kell mozgatni ezt a kereket".

Most nem azt mondom, hogy amikor egy rétegből indul, akkor befejezte, majd a következő rétegen van, és soha nem tér vissza az előzőhöz. A robotprojekt sokban hasonlíthat a modern, iteratív szoftverfejlesztési módszerekhez (agilis, SCRUM stb.).

Csak azt mondom, hogy szánjon időt mindegyikre. Kiegyensúlyoznia kell, hogy mennyit kell tennie mindegyiken, és el kell döntenie, hogy mit próbál egy bizonyos réteggel, ami megéri az időt és a fáradságot.

Van egy bizonyos "konfliktus" vagy "feszültség" két versengő elképzelés vagy irány között.

Az egyik az, amit "plug-n-play" -nek neveznék az A probléma megoldásához.

A másik a barkács (csináld magad). És talán nem is ez a legjobb címke ennek a másik ötletnek.

Íme egy példa mindegyikre, remélhetőleg látni fogja a feszültséget vagy konfliktust a két választás között.

Ebben a példában vegyük fel a SLAM-ot, az akadályok elkerülését és az alapvető alapvető mozgásokat, mint egy megoldandó problémát.

1. Ha úgy döntünk, hogy a plug-n-play útvonalat választjuk, azonnal (a költségvetéstől függően) olyan dolgokra ugrunk, mint a fent elhelyezett forgó lézerek, vagy a mélységélességű kamera, vagy a ToF lézerek, és az IMU (ennek témája) Utasítható).
2. Ha viszont a második utat akarjuk választani, akkor megpróbálhatunk minden lehetséges információt kinyerni néhány akusztikus érzékelőből vagy infravörös érzékelőből, vagy egyáltalán nem - csak a motoráram -figyelést (bump) használjuk

Mit lehet mondani az #1 vs #2 -ről? Egy dolog az lenne, hogy sokkal többet tanultunk volna a 2. lépéssel. A korlátozások, amelyek miatt csak akusztikus érzékelők használhatók, arra kényszerít bennünket, hogy sokkal több kérdésen gondolkodjunk.

Másrészt, ha túlságosan összpontosítunk arra, hogy a #2 -n keresztül végezzük a dolgokat, akkor vesztegethetjük az időt, mert az akusztikus érzékelőktől többet kérünk, mint kellene.

Még egy elgondolkodtató koncepció vagy ötlet: Milyen hardver- és szoftverkeverék válaszolja a legjobban a "hogyan" kérdését, és milyen szoftver (és hardver?) Keverék válaszol a "mi", "mikor", "hol" kérdésre. Mivel a "hogyan" tipikusan egy alacsonyabb szintű kérdés, amelytől függ, hogy "mit", "mikor" és "hol" választ kapunk.

Egyébként a fentiek csak elgondolkodtatóak voltak.

Esetemben, sok erőfeszítés után, miután folyamatosan bosszantó volt a pálya-súrlódás, és nem tudtam következetes irányítást és mozgást elérni, ideje valami mást tenni.

Így ez az Instructable - egy IMU.

A cél az, hogy ha az IMU azt mondja, hogy a robot NEM forog, akkor növeljük a működési ciklust. Ha túl gyorsan forogunk, csökkentjük a működési ciklust.

1. lépés: Az IMU érzékelő

Így a következő érzékelő, amelyet Wallace -hoz adunk hozzá, az IMU. Némi kutatás után egy MPU6050 -en telepedtem le. De akkor ebben az időben az MPU9050 (és még újabban az MPU9250) még jobb ötletnek tűnt.

A forrásom az Amazon volt (az Egyesült Államokban). Így rendeltem kettőt közülük.

Amit kaptam valójában (úgy tűnik, hogy nincs kontroll ezen; ez az, amit nem szeretek az Amazon -on) két MPU92/65 volt. Kicsit kíváncsi vagyok a kijelölésre. Nézze meg a képeket; ez "család" megjelölésnek tűnik. Mindenesetre én elakadtam.

A hozzáadás nagyon egyszerű -szerezzen be egy proto kártyát összekötő pályákkal, forrasztja az érzékelőt a táblához, és adjon hozzá egy 10 tűs csavaros sorkapcsot (az enyémet a Pololu -tól kaptam).

Az interferencia minimalizálása érdekében megpróbáltam ezeket az érzékelőket minden mástól távol elhelyezni.

Ez néhány nylon csavar/anya használatát is jelentette.

Az I2C protokollt fogom használni. Remélhetőleg a vezeték teljes hossza nem lesz rossz.

Máshol rengeteg információ található az alapvető csatlakozásokról, feszültségszintekről stb., Ezért ezt itt nem ismétlem meg.

2. lépés: A dolgok nem mindig tiszták, egyszerűek

Ebben az írásban úgy tűnik, hogy nincs sok online az adott MPU-92/65 számára. Ami elérhető, csakúgy, mint a legtöbb érzékelő esetében, az Arduino használatával kapcsolatos példáknak tűnik.

Próbálom ezeket az utasításokat egy kicsit másképp elkészíteni egy nem túl tiszta folyamat bemutatásával, mert a dolgok nem mindig működnek azonnal.

Feltételezem, hogy ezek az utasítások jobban hasonlítanak egy bloghoz, mint egyenes A-B-C, 1-2-3 "így csinálod".

3. lépés: Kezdeti teszt

Az előző lépésben szereplő képek alapján az érzékelőkhöz tartozó piros és fekete vezetékek természetesen VCC (5V) és GND. A zöld és sárga vezetékek az I2C csatlakozók.

Ha más I2C projekteket is végrehajtott, vagy követte ezeket a sorozatokat, akkor már tud az "i2cdetect" -ről, és ez az első lépés annak megismeréséhez, hogy a Málna látja -e az új érzékelőt.

Amint az ebben a lépésben látható képekből kiderül, első kísérletünk sikertelen volt. Az IMU nem jelenik meg (az eszköz azonosítója 0x68).

A jó hír azonban az, hogy az I2C busz működik. Látunk egy 0x20 -as eszközt, és ez az MCP23017 portbővítő (jelenleg a HCSR04 akusztikus érzékelőkért felelős).

Nem könnyű látni a képen, de ugyanazokat a zöld és sárga vezetékeket kötöttem az IMU -ból az MCP23017 -be (lásd a kép bal alsó sarkát)

El kell végeznünk néhány hibaelhárítást.

4. lépés: Hibaelhárítás

A voltmeter (a magas hangú) folytonossági beállítását használva teszteltem a VCC (5V), GND, SDA és SCL csatlakozásokat. Ezek jók voltak.

A következő kísérlet az MCP23017 leválasztása volt az I2C buszról, csak az MPU-92/65 maradt a buszon. Ez eredménytelennek bizonyult - az "i2cdetect" ekkor nem mutatott semmilyen eszközt.

Így aztán leszereltem az érzékelőt a totem pólusról, és újra bekötöttem az 5V-3V kétirányú buszba; azaz egyenesen a Málnához. (rövidebb vezetékek?).

És íme. Ezúttal siker van. Látjuk, hogy 0x68 jelenik meg az "i2cdetect" használatával.

De még nem tudjuk, miért működött ezúttal. Lehet a vezetékek hossza? Az előző helyszín?

Megjegyzés: Nem volt különbség, hogy az ADO földelt -e vagy sem. Lehet, hogy vannak fedélzeti felhúzó és lehúzható ellenállások. Ugyanez igaz lehet az FSYNC -re is.

Ezután újra csatlakoztattam az MCP23017-et. Tehát most két eszközünk van az I2C buszon. (lásd a képet). Siker, most látjuk a 0x20 -at és a 0x68 -at is az i2cdetect segítségével.

A videók egy kicsit többet tartalmaznak a hibaelhárítás során történtekről.

5. lépés: Olvassa el az érzékelő adatait

Különféle megközelítések

Úgy döntöttem, hogy többféle megközelítést alkalmazok, hogy hasznos információkat szerezzek az érzékelőből. Itt vannak, nem sorrendben:

1. próbálj ki néhány alapvető programozást
2. nézzen át néhány online dokumentációt a nyilvántartásokról
3. nézze meg mások példáit és / vagy kódját

Miért ezek a megközelítések? Miért nem keres egy létező könyvtárat vagy kódot?

Kísérletezéssel és néhány ötlet kipróbálásával jobban elsajátíthatunk bizonyos ismereteket nemcsak az adott érzékelővel kapcsolatban, hanem bizonyos technikákat, készségeket és gondolkodásmódokat is elsajátíthatunk valami új kezelésével kapcsolatban, és olyasmiről, amely nem rendelkezik sok dokumentációval; valami, amiben sok ismeretlen lehet.

Továbbá, miután eljátszottuk és kipróbáltuk néhány saját ötletünket, és betekintést nyertünk, jobb helyzetben vagyunk, hogy értékelhessük valaki más kódját vagy könyvtárát.

Például miután megnéztem a githubban az MPU9250 néhány C ++ kódját, rájöttem, hogy kényszerít a megszakítások használatára, amit még nem szeretnék.

Ezenkívül olyan extra dolgokkal is rendelkezik, mint a kalibrálás; megint valami, ami még nem érdekel.

Előfordulhat, hogy mit kell tennem ahhoz, hogy válaszoljak az egyszerű kérdésre, hogy "a robot igen vagy nem forog -e", nagyon egyszerűen meg lehet válaszolni néhány regiszter olvasásával.

Regiszterek

Ebben az írásban úgy tűnik, hogy nem sok rendelkezésre áll ezen az érzékelőn. Valójában, ha megnézi az utasításokkal együtt kapott képeket, és alaposan megnézi a tényleges zsetonok feliratait, akkor elgondolkodom azon, hogy ez nem kiütés-e. A látottakat nem kötöm Invense semmihez. Ettől függetlenül úgy döntöttem, hogy az általam talált modellek regisztrációs adatait nézem: az MPU-6050 és az MPU-9250.

Mindkét esetben a következők mindkettőre ugyanazok. Kezdetnek feltételezzük, hogy ez az MPU-92/65 esetében is ugyanaz lesz.

59-64 - gyorsulásmérő mérések

65, 66 - hőmérsékletmérés 67 - 72 - giroszkópmérés 73 - 96 - külső érzékelő adatai

Egy megjegyzés: Úgy tűnik, hogy az MPU-6050-ben NINCS magnetométer, míg az MPU-9250-ben (és feltételezzük, hogy ez is) van.

Még néhány érdekes, remélhetőleg hasznos információ a nyilvántartási dokumentumból:

Magnetométer információ:

magnetométer azonosító: 0x48 regisztrál 00 -tól 09: 00 -ig 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 HX2 HX1 H0 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 HZZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ HZ ST2 0 0 0 BITM HOFL 0 0 0 az egyes regiszterek jelentésének lebontása: HXL [7: 0]: X-tengely mérési adat alacsonyabb 8bit HXH [15: 8]: X-tengely mérési adat magasabb 8bit HYL [7: 0]: Y-tengely mérési adatok alsó 8bit HYH [15: 8]: Y-tengely mérési adatok magasabb 8bit HZL [7: 0]: Z-tengely mérési adatok alacsonyabb 8bit HZH [15: 8]: Z-tengely mérési adatok magasabb 8 bites

Programozás

Egy másik információ a nyilvántartási dokumentumokból az, hogy úgy tűnt, hogy csak körülbelül 100 regiszter létezik. Tehát az egyik taktika lehet egy egyszerű program írása, amely hozzáfér az eszközhöz (0x68), és megpróbál sorrendben olvasni egy regisztert, anélkül, hogy azok jelentését figyelembe venné, csak hogy lássa, milyen adatok láthatók.

Ezután végezze el az egymást követő áthaladásokat, ugyanazt a kódot használva, és hasonlítsa össze az egyik menet és a másik adatait.

Az elképzelés az, hogy valószínűleg kiiktathatnánk minden olyan regisztert, amely látszólag nem rendelkezik adatokkal (nulla vagy FF?), Vagy amelyek soha nem változnak, és összpontosíthatunk azokra is, amelyek változnak.

Ezután az egyiket csak azoknál nézzük, amelyek változnak, és adjunk hozzá egy átlagolási függvényt, amely átlagolja az adott regiszter legutóbbi N olvasását, hogy lássuk, van -e valójában bizonyos állandó értéke a regiszternek. Ez azt feltételezi, hogy az érzékelőt nagyon mozdulatlanul és ugyanabban a helyen tartjuk.

Végül óvatosan kipróbálhatnánk dolgokat az érzékelővel, például bökdöshetjük (gyorsulásmérő, giroszkóp), vagy fújhatnánk rá (hőmérséklet), vagy forgathatnánk (az előző két plusz magnetométer), és megnézhetjük, hogy ez milyen hatással van az értékekre.

Szeretem a wiringPi könyvtárat a lehető legnagyobb mértékben használni. Támogatja az I2C -t.

Első futás:

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

* build: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * futtatása: sudo./first.test.mpu9265 * * ez a program csak egy (lehetséges) regisztert ad ki az MCP23017 -ből, * majd az MPU9265 -ből (vagy bármely más MPU -ról azon a 0x68 -as címen) * * Ezzel ellenőriztem, hogy tudok -e olvasni az érzékelőből, mivel már * bíztam az MCP23017 -ben. ************************************************** ****************************/ #include #include #include #include #include int main (int argc, char ** argv) {put ("Lássuk, mit mond az MCP23017 @ 0x20:"); hiba = 0; int deviceId1 = 0x20; int fd1 = wiringPiI2CSetup (deviceId1); if (-1 == fd1) {fprintf (stderr, "Nem lehet megnyitni a wiringPi I2C eszközt: %s / n", strerror (errno)); visszatérés 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); késleltetés (10); } put (""); put ("Lássuk, mit mond az MPU9265 @ 0x20:"); hiba = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup (deviceId2); if (-1 == fd2) {fprintf (stderr, "Nem lehet megnyitni a wiringPi I2C eszközt: %s / n", strerror (errno)); visszatérés 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); késleltetés (10); } put (""); visszatérés 0; }

A második menet:

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

* build: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * futtatása: sudo./second.test.mpu9265 * * Ez a program a beolvasott érték mellett a regiszter számát adja ki. * * Így hasznos lehet a kimenet fájlba való átirányítása (átirányítása), majd * több futtatás is elvégezhető az összehasonlításhoz. Ez némi betekintést adhat abba, * hogy milyen regiszter fontos, és hogyan viselkednek az adatok. ************************************************** ****************************/ #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; } Put ("Lássuk, mit mond az MPU9265 @ 0x20:"); hiba = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Nem lehet megnyitni a wiringPi I2C eszközt: %s / n", strerror (errno)); visszatérés 1; } for (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); késleltetés (10); } return 0; }

A harmadik menet:

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

* build: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * futtatása: sudo./third.test.mpu9265 * * Ez a program a második eredménye. Csak a * regiszterekből olvas, amelyek különbséget jeleztek az egyik és a másik futás között.************************************************** ****************************/ #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; } Put ("Lássuk, mit mond az MPU9265 @ 0x20:"); hiba = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Nem lehet megnyitni a wiringPi I2C eszközt: %s / n", strerror (errno)); visszatérés 1; } for (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); késleltetés (10); } for (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); késleltetés (10); } for (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); késleltetés (10); } for (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); késleltetés (10); } return 0; }

Tehát mit tanultunk eddig? A színes, kiemelt területekkel rendelkező táblázat képe azt jelzi, hogy a kimenet megegyezik az első regiszterkészletekkel.

Az eddigi eredmények új kérdéseket vethetnek fel.

Kérdés: miért van csak egy regisztrációs eredmény a "külső" csoporthoz?

Kérdés: mik azok az ismeretlen regiszterek "??????"

Kérdés: mivel a program nem megszakításvezérelt, túl lassú adatokat kért? túl gyors?

Kérdés: befolyásolhatjuk -e az eredményeket, ha magával az érzékelővel próbáljuk ki a dolgokat futás közben?

6. lépés: ássunk többet az olvasmányokba / adatokba

Azt hiszem, a következő lépés minden más előtt a program továbbfejlesztése:

• rugalmas legyen a hurok késleltetésében (ms)
• rugalmasan határozza meg, hogy hány leolvasást kell adni egy regiszter futó átlagához

(Fájlként kellett csatolnom a programot. Úgy tűnt, gondot okoz a beillesztés. "4th.test.mpu9265.c")

Íme egy futtatás az utolsó 10 leolvasással, átlagosan, 10 ms -os ciklusban:

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

Az első, bal oldali oszlop a nyilvántartási szám. Ezután jöjjön a regiszter utolsó 10 leolvasása. Végül az utolsó oszlop az egyes sorok átlaga.

Úgy tűnik, hogy a 61., 69., 71., 189., 197. és 199. regiszter vagy csak bináris, vagy kész / nem kész, vagy egy 16 bites érték magas bájtja (negatív?).

További érdekes megfigyelések:

• regiszterek 65, 193 - nagyon állandó és ugyanaz az érték
• regiszter 63, 191 - nagyon állandó és azonos érték
• regiszterek 73, 112, 195, 201, 240 - mind nulla

Kapcsoljuk vissza ezeket a megfigyeléseket a korábbiak sokszínű, kiemelt táblázatképéhez.

Regisztráljon 65 - hőmérséklet

Nyilvántartás 193 - ??????

Regisztráció 63 - gyorsulásmérő

Regisztráció 191 - ??????

Regisztráció 73 - külső

Regisztrálja a 112 -t és tovább - ??????

Nos, még mindig vannak ismeretlenek, azonban megtudtunk valami hasznosat.

A 65 -ös regiszter (hőmérséklet) és a 63 -as regiszter (gyorsulásmérő) nagyon stabil volt. Ezt várjuk el. Nem nyúltam az érzékelőhöz; nem mozog, kivéve az esetleges rezgéseket, mivel a robot ugyanazon az asztalon nyugszik, mint a számítógépem.

Ezen hőmérséklet/gyorsulásmérő regiszterek mindegyikére van egy érdekes teszt. Ehhez a teszthez szükségünk van a program egy újabb verziójára.

7. lépés: Képesek vagyunk befolyásolni a hőmérsékletet és a gyorsulást

Az előző lépésekben szűkítettünk legalább egy hőmérsékleti és egy gyorsulási regisztert.

A program következő verziójával ("4th.test.mpu9265.c") valójában láthatjuk, hogy mindkét regiszterben változás történik. Kérjük, nézze meg a videókat.

További ásás

Ha visszamegyünk, és megnézzük a nyilvántartási adatokat, azt látjuk, hogy vannak:

• három 16 bites kimenet giroszkóphoz
• három 16 bites kimenet a gyorsulásmérőhöz
• három 16 bites kimenet a magnetométerhez
• egy 16 bites kimenet a hőmérséklethez

Az egyszerű tesztprogramjaink által kapott eredmények azonban egyetlen 8 bites kimenetek voltak. (egyetlen regiszter).

Tehát próbálkozzunk inkább ugyanazzal a megközelítéssel, de ezúttal 8 bit helyett 16 bitet olvasunk.

Valószínűleg az alábbiak szerint kell tennünk valamit. Vegyük példaként a hőmérsékletet, mivel ez csak egy 16 bites kimenet.

// fájlleíró beszerzése fd …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8 (fd, tempRegHi); int loByte = wiringPiI2CReadReg8 (fd, tempRegLo); int eredmény = hiByte << 8; // helyezze a 8 soros bitrendet a 16 bites eredmény felső részébe | = loByte; // most adja hozzá a sorrendben 8 bitet, így kap egy teljes 16 bites számot // nyomtatja ki ezt a számot, vagy használja a kijelző vízszintes grafikon funkcióját

Korábbi lépéseinkből láttuk, hogy a 65 -ös regiszter meglehetősen sziklaszilárd, míg a 66 -os regiszter nagyon zajos. Mivel 65 a hi sorrendű bájt, és 66 az alacsony rendű bájt, így van értelme.

Olvasáshoz vehetjük a 65-ös regiszter adatait úgy, ahogy vannak, de átlagolhatjuk a 66-os regiszter értékeit.

Vagy csak átlagolhatjuk a teljes eredményt.

Nézze meg ennek a résznek az utolsó videóját; a teljes 16 bites hőmérsékleti érték leolvasását mutatja. A kód "sixth.test.mpu9265.c"

8. lépés: A gyorsulásmérő és a giroszkóp

Az ehhez a szakaszhoz tartozó videók a gyorsulásmérő és a giroszkóp kimenetét mutatják, a "septth.test.mpu9265.c" tesztprogram segítségével. Ez a kód 1, 2 vagy 3 egymást követő bájtpárt (hi és lo bájt) tud olvasni, és az értékeket egyetlen 16 bites értékké alakítja át. Így bármely tengelyt kiolvashatunk, vagy kettőt együtt (és ez összefoglalja a változásokat), vagy mindhármat (és összefoglalja a változásokat).

Ismétlem, ebben a fázisban, ebben az Instructable -ban csak egy egyszerű kérdésre szeretnék választ kapni: "forgott/forgott a robot?". Nem keresek pontos értéket, például, hogy elfordult -e 90 fokkal. Ez később fog megtörténni, amikor elkezdjük a SLAM-ot, de ez nem szükséges az egyszerű akadálykerüléshez és a véletlenszerű mozgáshoz.

9. lépés: (folyamatban lévő munka) a magnetométer

az i2cdetect eszköz használatakor az MPU9265 0x68 formátumban jelenik meg a táblázatban:

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

További lépések szükségesek az IMU magnetométer részének leolvasásához.

Az Invesense regiszterek PDF dokumentumából:

REGISZTRÁCIÓK 37 - 39 - I2C SLAVE 0 CONTROL

• 37. REGISZTER - I2C_SLV0_ADDR
• REGISZTRÁCIÓ 38 - I2C_SLV0_REG
• 39. REGISZTER - I2C_SLV0_CTRL