Уолъс - Направи си сам автономен робот - Част 5 - Добавяне на IMU: 9 стъпки

2024 Автор: John Day | [email protected]. Последно модифициран: 2024-01-30 07:53

Продължаваме заедно с Уолъс. Името Уолъс идва от комбинация от „Wall-E“и от предишен проект (разпознаване на глас) и при използването на помощната програма „espeak“звучеше малко британско. И като камериер или иконом. И това е крайната цел: този проект да се превърне в нещо полезно. Така "Уолъс".

Уолъс може да се движи, може да избягва препятствия с помощта на инфрачервени сензори за разстояние (наскоро някак си се запържиха (?) (Трябва да разгледам това, когато имам възможност), също има някои акустични сензори за разстояние (три от тях се повредиха едновременно време, заедно с разширител MCP23017), и накрая, може да открие промени в тока на двигателя, за да знае кога се е ударил в нещо.

В допълнение към сензорите, Уолъс "помни" 100 -те хода и има някои елементарни анализи, използващи историята на движенията.

Целта досега за Уолъс е просто да се опита да продължи да се движи напред и да знае кога е заседнал в някакъв повтарящ се модел (например в ъгъла) и всъщност не се движи напред.

Преминах през няколко повторения за движение и навигация и постоянното главоболие е било по време на въртене.

Тъй като Уолъс е проследен робот и исках да запазя нещата по -опростени в софтуера (за по -късно), за да се обърна, просто го карам да се завърта/завърта на място. По този начин прилагайте еднаква, но противоположна мощност / работен цикъл към двигателите.

Възникналият проблем се дължи на дизайна на робот платформата Agent 390. Коланите на релсите са склонни да се трият отстрани. И по -лошото е, че едната страна прави това повече от другата.

При настилките и при движение направо, това не беше проблем. Показва се на килими. Избрах да пазя Уолъс от килимите, след като следите му станаха мръсни (те улавят мръсотия изключително лесно).

Истинският проблем е при завъртане на подови настилки.

Ако софтуерът приложи работен цикъл на високо ниво, той повече или по -малко последователно се обръща. Въпреки това, по време на нисък работен цикъл, той може или не може действително да се обърне. Или може да се обърне за малко и след това да се забави. Извършващото действие изглежда неконтролируемо чрез софтуера или в най -добрия случай много трудно.

Проблемът се проявява по време на навигация и преместване около или далеч от препятствия. Той може или да се отклони твърде диво, или да се забие, опитвайки се да направи много малки смени, без дори да се движи.

И така горното обяснение мотивира този Instructable.

Първоначално исках да се откажа от или да забавя въвеждането на устройство за откриване на движение (IMU), защото те са A) сложни, B) шумни, C) грешки могат да бъдат въведени с течение на времето и т.н., и т.н. беше, че можем да се справим много добре, като преминем напред към IR лазерните сензори по време на полета. И ние бихме могли - използвайки лазери, бихме могли да знаем дали роботът се върти или не, като проследяваме промените в разстоянието.

Всъщност бихме могли (някак) да направим това сега с акустичните сензори.

Всичко това обаче е много индиректен, сложен начин да се отговори на един прост въпрос: "ротирахме ли се или не?"

Струваше ми се, че скачането с помощта на лазерни сензори ToF ще ме отведе до следващото ниво на софтуер; а именно SLAM (едновременно локализиране и картографиране). Още не бях готов да отида там.

Добре е да направите проект на робот на слоеве, като първите (долните) слоеве са по -прости, а последните (горните) слоеве са по -абстрактни и се справят с по -трудни въпроси.

Слоевете могат да се мислят за нещо подобно:

1. физическа рамка на робота / механична структурна основа
2. елементарна задвижваща система (Raspberry, Roboclaw, двигатели, окабеляване и т.н., основен софтуер, управляван от клавиатура)
3. основни схеми за поддържане на сензори (двупосочен превключвател на напрежение, разширител на портове, E-Stop, разпределение на мощността и т.н.)
4. сензори за избягване на препятствия (акустични, IR)
5. съществено, основно позициониране и движение - откриване (акселерометър, жироскоп, магнитометър, енкодери на двигателя, енкодери на колела)

Можете да създадете свой собствен списък. Въпросите в този списък са, че вероятно трябва да ги направите горе -долу в този ред, а също и че ако прекарвате известно време на всеки слой, за да приведете всеки в добро работно състояние, това би трябвало да ви помогне по -късно, тъй като нещата се усложняват.

Горният списък може повече или по -малко да бъде съпоставен с тези концептуални слоеве в софтуера.

• SLAM (едновременно локализиране и картографиране)
• Контрол и осъзнаване на движението, въртене
• Основно избягване на препятствия
• Контрол и откриване на сензорни данни
• Основно движение напред, назад, наляво и надясно, ускоряване, забавяне, спиране

Както можете да видите, за този списък първите елементи биха били горните, по -сложни слоеве, които се занимават с по -абстрактни въпроси и въпроси, като „къде съм“и „къде отивам“, докато последните елементи биха били по -ниски софтуерни слоеве, които управляват „как да говоря/слушам сензор А“или „как да преместя това колело“.

Сега не казвам, че когато започнете от слой, ще го завършите и след това той е на следващия слой, никога да не се връща към предишния. Проектът на робот може много да прилича на съвременните итеративни методи за разработка на софтуер (гъвкав, SCRUM и т.н.).

Просто казвам да отделяте време за всеки. Ще трябва да балансирате колко да правите на всеки и да решите какво се опитвате на определен слой, което си струва времето и проблемите.

Има известен „конфликт“или „напрежение“между две конкуриращи се идеи или посоки.

Едното е това, което бих нарекъл „plug-n-play“за решаване на проблем А.

Другият е DIY (направи си сам). И това може би дори не е най -добрият етикет за тази друга идея.

Ето пример за всеки, надявам се да видите напрежението или конфликта между двата избора.

За този пример нека обединим SLAM, избягване на препятствия и съществено основно движение като един проблем, който трябва да решим едновременно.

1. Ако решим да преминем към plug-n-play маршрута, веднага прескачаме (в зависимост от бюджета) към неща като онези въртящи се въртящи се лазери или камера за дълбочина на рязкост или ToF лазери и IMU (темата на това Инструктивни).
2. Ако, от друга страна, искаме да преминем по втория маршрут, може да се опитаме да извлечем всяка възможна информация от някои акустични сензори или инфрачервени сензори или изобщо да няма сензори - просто използваме мониторинг на тока на двигателя (удар)

Какво може да се каже за #1 срещу #2? Едно нещо би било, че ще научим много повече, като направим #2. Ограниченията да имаме само акустични сензори за работа, ни принуждават да мислим за много повече въпроси.

От друга страна, ако сме твърде фокусирани да правим неща чрез #2, може да губим време, защото искаме повече, отколкото трябва от акустичните сензори.

Още една концепция или идея за размисъл: Каква смес от хардуер и софтуер отговаря най -добре на въпросите „как да се прави“и каква смес от софтуер (и хардуер?) Отговаря на въпроса „какво“, „кога“, „къде“. Защото „как да“обикновено е въпрос от по-ниско ниво, от който зависи „какво“, „кога“и „къде“, за да се получи отговор.

Както и да е, всичко по -горе беше просто нещо, върху което да се замислим.

В моя случай, след много усилия и постоянен досаден проблем с триенето на коловоза и невъзможност за постоянен контрол и движение, е време да се направи нещо друго.

Така този Instructable - IMU.

Целта е, ако IMU каже, че роботът НЕ се върти, ние увеличаваме работния цикъл. Ако се въртим твърде бързо, намаляваме работния цикъл.

Стъпка 1: IMU сензор

И така следващият ни сензор за добавяне към Уолъс е IMU. След известно проучване се спрях на MPU6050. Но тогава по това време MPU9050 (и още по -скоро MPU9250) изглеждаше като още по -добра идея.

Моят източник е Amazon (в САЩ). Затова поръчах две от тях.

Това, което получих всъщност (изглежда няма контрол върху това; това не ми харесва в Amazon) бяха два MPU92/65. Чудя се малко за обозначението. Разгледайте изображенията; това изглежда е "семейно" обозначение. Във всеки случай това е, което съм заседнал.

Добавянето му е много просто -вземете прото платка със свързващи писти, запоявайте сензора към платката, добавете 10 -пинов винтов клемен блок (аз си взех моя от Pololu).

За да минимизирам всякакви смущения, се опитах да поставя тези сензори далеч от всичко друго.

Това означаваше и използване на найлонови болтове/гайки.

Ще използвам протокола I2C. Да се надяваме, че общата дължина на проводника няма да бъде твърде лоша.

Навсякъде има много информация за основните връзки и нива на напрежение и т.н., така че няма да повтарям това тук.

Стъпка 2: Нещата не винаги са чисти, лесни

На този етап не изглежда да има много онлайн за този конкретен MPU-92/65. Наличното, както и при повечето сензори, изглежда са примери за използване на Arduino.

Опитвам се да направя тези инструкции малко по-различни, като представя не толкова чист процес, защото нещата не винаги работят веднага.

Предполагам, че тези инструкции са по-подобни на блог, отколкото на прави A-B-C, 1-2-3 "така се прави".

Стъпка 3: Първоначален тест

От изображенията в предишната стъпка, червените и черните проводници към сензорите, разбира се, са VCC (5V) и GND. Зелените и жълтите проводници са I2C връзките.

Ако сте правили други проекти на I2C или сте следвали заедно с тези серии, тогава вече знаете за „i2cdetect“и това е първата стъпка да разберете дали малината може да види новия сензор.

Както можете да видите от изображенията в тази стъпка, първият ни опит беше неуспешен. IMU не се появява (трябва да е идентификатор на устройството 0x68).

Добрата новина обаче е, че I2C шината работи. Виждаме едно устройство 0x20 и това е разширител на порта MCP23017 (в момента отговаря за акустичните сензори HCSR04).

Не е лесно да се види на изображението, но свързах еднакви цветни зелени и жълти проводници от IMU към MCP23017 (вижте долу вляво на изображението)

Ще трябва да отстраним някои проблеми.

Стъпка 4: Отстраняване на неизправности

Използвайки настройката за непрекъснатост на волтметър (този с висок тон), тествах VCC (5V), GND, SDA и SCL връзки. Това бяха добри.

Следващият опит беше да изключите MCP23017 от I2C шината, оставяйки само MPU-92/65 в шината. Това се оказа безплодно - „i2cdetect“тогава не показа никакви устройства.

И така, след това демонтирах сензора от тотемния стълб и го свързах отново директно към двупосочната шина 5V към 3V; директно към малината. (по -къси проводници?).

И воала. Този път има успех. Виждаме, че 0x68 се показва с помощта на "i2cdetect".

Но все още не знаем защо се получи този път. Възможно ли е дължината на проводниците? Предишното местоположение?

Забележка: Няма значение дали ADO е основан или не. Възможно е да има вградени резистори за издърпване и изтегляне. Същото може да е вярно и за FSYNC.

След това отново свързах MCP23017. Така че сега имаме две устройства на I2C шината. (вижте изображението). Успех, сега виждаме както 0x20, така и 0x68 с i2cdetect.

Видеоклиповете разказват малко повече за случилото се по време на отстраняването на неизправности.

Стъпка 5: Четене на данните на сензора

Различни подходи

Реших да използвам няколко подхода за получаване на полезна информация от сензора. Ето ги, не в никакъв ред:

1. опитайте някои основни програми
2. разгледайте някаква онлайн документация за регистрите
3. разгледайте примери и / или код на други хора

Защо тези подходи? Защо просто не потърсите някаква съществуваща библиотека или код?

Експериментирайки и изпробвайки някои идеи, можем по -добре да усвоим някои знания не само за този конкретен сензор, но и да придобием известна техника, умения и начини за мислене за справяне с нещо ново и нещо, което може да няма много документация; нещо, което може да има много неизвестни.

Също така, след като сме си поиграли и изпробвали някои от нашите собствени идеи и сме разбрали, ние сме в по -добра позиция да оценим кода или библиотеката на някой друг.

Например, след като погледнах някой C ++ код за MPU9250 в github, осъзнах, че ме принуждава да използвам прекъсвания, което все още не искам да правя.

Също така, той идва с допълнителни неща като калибриране; отново нещо, което все още не ме интересува.

Може да се окаже, че това, което трябва да направя, за да отговоря на простия въпрос „върти ли се роботът да или не“, би могло да бъде отговорено много просто, само като прочета някои регистри.

Регистри

При това писане изглежда няма много налични за този сензор. Всъщност, ако разгледате снимките, които идват с този Instructable, и разгледате отблизо надписите на действителните чипове, това ме кара да се чудя дали това не е удар. Не свързвам това, което виждам, с нищо от Invense. Независимо от това, аз избрах да погледна регистърната информация за моделите, които открих: MPU-6050 и MPU-9250.

И в двата случая следното е еднакво и за двете. И за начало, ние приемаме, че ще бъде същото за този MPU-92/65.

59 до 64 - измервания на акселерометъра

65, 66 - измервания на температурата 67 до 72 - измервания с жироскоп 73 до 96 - данни от външен сензор

Забележка: Изглежда, че MPU-6050 НЯМА магнитометър, докато MPU-9250 (и ние приемаме, че и този) има такъв.

Още по-интересна, надявам се полезна информация, събрана от регистърния документ:

Информация за магнитометъра:

идентификатор на магнитометър: 0x48 регистри 00 до 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 H3 HX4 H3 HXH HX15 HX14 HX8 HZ6 HZ8 HZ6 HZ8 ST2 0 0 0 BITM HOFL 0 0 0 разбивка на значението на всеки регистър: HXL [7: 0]: Данните за измерване по оста X по-ниска 8 бита HXH [15: 8]: Данните по измерването по оста X по-висока 8 бита HYL [7: 0]: Данни за измерване по оста Y по-ниска 8 бита HYH [15: 8]: Данните от измерването по оста Y по-висока 8 бита HZL [7: 0]: Данните от измерването по оста Z по-ниски 8 бита HZH [15: 8]: Данните от измерването по оста по-висока 8 бита

Програмиране

Друга информация от регистърните документи е, че изглежда имаше само около 100 регистъра. Така че една тактика може да бъде да се напише проста програма, която осъществява достъп до устройството (0x68) и се опитва да прочете последователно поредица от регистри, без да обръща внимание на тяхното значение, само за да види какви данни могат да се видят.

След това направете последователни преминавания, използвайки същия код, и сравнете данните от едно преминаване спрямо следващото.

Идеята е, че вероятно бихме могли да премахнем всички регистри, които изглежда нямат данни (нули или FF?) Или които абсолютно никога не се променят, а също така бихме могли да се съсредоточим върху тези, които се променят.

След това разглеждаме само тези, които се променят, добавяме функция за осредняване, която осреднява последните N показания на този регистър, за да видим дали всъщност има определена постоянна стойност за този регистър. Това би предположило, че държим сензора много неподвижен и на същото място.

И накрая, след това бихме могли внимателно да изпробваме нещата със сензора, като например да го бутаме (акселерометър, жироскоп), или да духаме върху него (температура), или да го завъртаме (предишните два плюс магнитометър) и да видим какъв ефект има това върху стойностите.

Обичам да използвам библиотеката wiringPi колкото е възможно повече. Има поддръжка за I2C.

Първо изпълнение:

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

* за изграждане: gcc first.test.mpu9265.c -o first.test.mpu9265 -lwiringPi * * за изпълнение: sudo./first.test.mpu9265 * * тази програма просто извежда диапазон от (възможни) регистри от MCP23017, * и след това от MPU9265 (или всеки друг MPU на този адрес 0x68) * * Използвах го, за да проверя дали мога дори да чета от сензора, тъй като вече * имах доверие в MCP23017. ************************************************** ****************************/ #include #include #include #include #include int main (int argc, char ** argv) {пуска ("Да видим какво има да каже MCP23017 @ 0x20:"); errno = 0; int deviceId1 = 0x20; int fd1 = wiringPiI2CSetup (deviceId1); if (-1 == fd1) {fprintf (stderr, "Не мога да отворя wiringPi I2C устройство: %s / n", strerror (errno)); връщане 1; } за (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd1, reg)); fflush (stderr); забавяне (10); } пуска (""); пуска ("Нека видим какво ще каже MPU9265 @ 0x20:"); errno = 0; int deviceId2 = 0x68; int fd2 = wiringPiI2CSetup (deviceId2); if (-1 == fd2) {fprintf (stderr, "Не мога да отворя wiringPi I2C устройство: %s / n", strerror (errno)); връщане 1; } за (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d", wiringPiI2CReadReg8 (fd2, reg)); fflush (stderr); забавяне (10); } пуска (""); връщане 0; }

Вторият цикъл:

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

* за изграждане: gcc second.test.mpu9265.c -o second.test.mpu9265 -lwiringPi * * за изпълнение: sudo./second.test.mpu9265 * * Тази програма извежда номера на регистъра заедно с прочетената стойност. * * Това прави полезно изпращането (пренасочване) на изхода към файл и след това * могат да се направят няколко цикъла за сравнение. Това може да даде известна представа за това кой регистър е важен и как могат да се държат данните. ************************************************** ****************************/ #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; } иначе ако (! strncmp (argv [1], "0x68", strlen ("0x68"))) {deviceId = 0x68; } иначе ако (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } Put ("Нека видим какво ще каже MPU9265 @ 0x20:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Не мога да отворя wiringPi I2C устройство: %s / n", strerror (errno)); връщане 1; } за (int reg = 0; reg <300; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); забавяне (10); } връщане 0; }

Третият цикъл:

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

* за изграждане: gcc third.test.mpu9265.c -o third.test.mpu9265 -lwiringPi * * за изпълнение: sudo./third.test.mpu9265 * * Тази програма е резултат от втората. Той само чете от регистрите *, които показват разлика между едно изпълнение и следващо.************************************************** ****************************/ #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; } иначе ако (! strncmp (argv [1], "0x69", strlen ("0x69"))) {deviceId = 0x69; } Put ("Нека видим какво ще каже MPU9265 @ 0x20:"); errno = 0; int fd = wiringPiI2CSetup (deviceId); if (-1 == fd) {fprintf (stderr, "Не мога да отворя wiringPi I2C устройство: %s / n", strerror (errno)); връщане 1; } за (int reg = 61; reg <= 73; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); забавяне (10); } за (int reg = 111; reg <= 112; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); забавяне (10); } за (int reg = 189; reg <= 201; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); забавяне (10); } за (int reg = 239; reg <= 240; reg ++) {fprintf (stderr, "%d:%d / n", reg, wiringPiI2CReadReg8 (fd, reg)); fflush (stderr); забавяне (10); } връщане 0; }

И така, какво научихме досега? Изображението на таблицата с цветни маркирани области показва, че изходът изглежда съвпада с първите набори от регистри.

Досегашните резултати могат да генерират нови въпроси.

Въпрос: защо има само един регистър резултат за "външната" група?

Въпрос: какви са всички тези неизвестни регистри "??????"

Въпрос: Тъй като програмата не се управлява от прекъсвания, изисква ли данни твърде бавно? твърде бързо?

Въпрос: можем ли да повлияем на резултатите, като изпробваме нещата със самия сензор, докато работи?

Стъпка 6: Нека да копаем повече в показанията / данните

Мисля, че следващата стъпка преди всичко друго е да се подобри програмата до:

• бъдете гъвкави в колко забавяне на цикъла (ms)
• бъдете гъвкави в това колко показания да дадете текуща средна стойност за регистър

(Трябваше да прикача програмата като файл. Изглежда, че има проблем с вмъкването й тук. "4th.test.mpu9265.c")

Ето пробег, използващ средно последните 10 показания, при цикъл от 10 ms:

sudo./4th.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

Първата, най-лявата колона е номерът на регистъра. Следват последните 10 показания за този регистър. И накрая, последната колона е средната стойност за всеки ред.

Изглежда, че регистрите 61, 69, 71, 189, 197 и 199 са или само двоични, или готови / не са готови, или са старши байт на 16-битова стойност (отрицателна?).

Други интересни наблюдения:

• регистри 65, 193 - много стабилна и със същата стойност
• регистър 63, 191 - много стабилна и със същата стойност
• регистри 73, 112, 195, 201, 240 - всичко на нула

Нека да върнем тези наблюдения обратно към многоцветното, подчертано изображение на таблицата от по-рано.

Регистър 65 - температура

Регистрация 193 - ??????

Регистър 63 - акселерометър

Регистрация 191 - ??????

Регистър 73 - външен

Регистрирайте се на 112 и нататък - ??????

Е, все още имаме неизвестни, но научихме нещо полезно.

Регистър 65 (температура) и регистър 63 (акселерометър) бяха много стабилни. Това е нещо, което бихме очаквали. Не съм докосвал сензора; не се движи, с изключение на случайни вибрации, тъй като роботът лежи на същата маса като компютъра ми.

Има един интересен тест, който можем да направим за всеки от тези регистри на температурата/акселерометъра. За този тест се нуждаем от още една версия на програмата.

Стъпка 7: Ние можем да повлияем на температурата и ускорението

В предишните стъпки стеснихме поне един регистър за температура и един за ускорение.

С тази следваща версия на програмата ("5th.test.mpu9265.c"), всъщност можем да видим, че има промяна и в двата регистра. Моля, гледайте видеоклиповете.

Още копаене

Ако се върнем и погледнем информацията в регистъра, виждаме, че има:

• три 16 -битови изхода за жироскоп
• три 16 -битови изхода за акселерометър
• три 16 -битови изхода за магнитометър
• един 16 битов изход за температура

Въпреки това, резултатите, получени от нашите прости програми за тестване, бяха единични 8 -битови изходи. (единични регистри).

Така че нека опитаме повече от същия подход, но този път да четем 16 бита вместо 8.

Вероятно ще трябва да направим нещо подобно по -долу. Нека използваме температурата като пример, тъй като това е само един 16 -битов изход.

// получавам дескриптор на файл fd …

int tempRegHi = 65; int tempRegLo = 66; int hiByte = wiringPiI2CReadReg8 (fd, tempRegHi); int loByte = wiringPiI2CReadReg8 (fd, tempRegLo); int резултат = hiByte << 8; // поставяме 8 бита в най -горната част на резултат от 16 битова стойност | = loByte; // сега добавяме в ред lo 8 бита, давайки пълно 16 -битово число // отпечатваме това число или използваме функцията за хоризонтално графично показване от преди

От предишните ни стъпки видяхме, че регистър 65 е доста стабилен, докато регистър 66 е много шумен. Тъй като 65 е байт за най -висок ред, а 66 байт за нисък ред, това има смисъл.

За четене можем да вземем данните от регистър 65 такива, каквито са, но бихме могли да изчислим средно стойностите на регистър 66.

Или можем просто да усредним целия резултат.

Разгледайте последното видео за тази част; той демонстрира отчитане на цялата 16 -битова температурна стойност. Кодът е „шести.test.mpu9265.c“

Стъпка 8: Акселерометърът и жироскопът

Видеоклиповете за този раздел показват изход от акселерометъра и жироскопа, използвайки тестова програма "seventh.test.mpu9265.c". Този код може да чете 1, 2 или 3 последователни байт-двойки (hi и lo байтове) и преобразува стойностите в една 16-битова стойност. По този начин можем да прочетем всяка една ос, или можем да прочетем две от тях заедно (и това сумира промените), или можем да прочетем и трите (и това сумира промените).

За да повторя, за тази фаза, за този Instructable, аз просто търся да отговоря на прост въпрос: "роботът ротирал ли се е/завъртал ли е?". Не търся някаква точна стойност, като например дали се е завъртяла на 90 градуса. Това ще дойде по-късно, когато започнем да правим SLAM, но не е необходимо за просто избягване на препятствия и произволно движение.

Стъпка 9: (в процес на работа) магнитометърът

когато използвате инструмента i2cdetect, MPU9265 се показва като 0x68 в таблицата:

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

Необходими са допълнителни стъпки за четене от магнитометровата част на IMU.

От регистрите Invesense PDF doc:

РЕГИСТРИ 37 ДО 39 - I2C РАБОТЕН 0 КОНТРОЛ

• РЕГИСТЪР 37 - I2C_SLV0_ADDR
• РЕГИСТЪР 38 - I2C_SLV0_REG
• РЕГИСТЪР 39 - I2C_SLV0_CTRL