Автономен робот на Уолъс - Част 4 - Добавяне на сензори за IR разстояние и "усилвател": 6 стъпки

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

Здравейте, днес започваме следващата фаза на подобряване на възможностите на Уолъс. По-конкретно, ние се опитваме да подобрим способността му да открива и избягва препятствия с помощта на инфрачервени сензори за разстояние, а също така да се възползваме от способността на Roboclaw мотор-контролера да следи тока и да го превърне във виртуален (софтуерен) "сензор". Накрая ще разгледаме как да се движите без SLAM (едновременно местоположение и картографиране) (засега), тъй като роботът все още няма IMU (единица за измерване на инерцията) или ToF (време на полет) сензори.

По навигация първоначално това ще бъде само две основни цели:

1. избягвайте препятствията
2. разпознава, когато е заседнал някъде и не постига никакъв напредък. („напредък“означава дали се е придвижил напред на някакво значимо разстояние)
3. възможна трета цел би могла да бъде да се опита да се подреди директно към стена.

Този проект започна с робот комплект и получаване на основни движения за работа с помощта на клавиатура и ssh връзка.

Втората фаза беше да се добави достатъчно поддържаща схема, за да се подготви за добавяне на много сензори.

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

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

Едно подобрение може да бъде проследяването на типичните моторни токове и ако стойностите скочат, тогава роботът трябва да е ударил нещо. Това е добър „план Б“или дори В. Но това всъщност не му помага да се движи из зоната за хранене.

(Актуализация: всъщност, засега мониторингът на тока е план А при заден ход, тъй като временно съм премахнал и сензорите отзад).

Видеоклипът за този раздел представлява последната фаза на сензорите за избягване на препятствия.

Това, което виждате във видеото, е шест предни акустични сензора HCSR04 и два IR сензора Sharp. Инфрачервените сензори не играят много роля във видеото. Тяхната сила е най -вече, когато роботът се озове в зоната за хранене с лице към масата и краката на стола.

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

И накрая, той използва историята на последните 100 хода и някои основни анализи, за да отговори на един въпрос:

"Има ли наскоро реален напредък напред (или е заседнал в някой повтарящ се танц)?"

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

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

Стъпка 1: Добавяне на поддържаща схема (MCP3008)

Преди да можем да добавим IR сензорите, ще ни е необходима интерфейсната схема между тях и Raspberry Pi.

Ще добавим аналогово-цифров преобразувател MCP3008. Има много онлайн ресурси как да свържете този чип към Raspberry Pi, така че няма да навлизам много в това тук.

По същество имаме избор. Ако версията на IR сензорите работи на 3V, може да работи и MCP3008 и тогава можем директно да се свържем с Raspberry.

[3V IR сензор] - [MCP3008] - [Raspberrry Pi]

В моя случай обаче работя предимно с 5V, така че това означава двупосочен превключвател на нива.

[5V IR сензор]-[MCP3008]-[двупосочна шина 5V към 3V]-[Raspberry Pi]

Забележка: Има само един изходен сигнал от IR сензора. Той отива директно към една от входните аналогови сигнални линии на MCP3008. От MCP3008 има 4 линии за данни, които трябва да свържем (чрез двупосочната шина) към Raspberry Pi.

В момента нашият робот ще работи само с два IR сензора, но лесно бихме могли да добавим още. MCP3008 осем аналогови входни канала.

Стъпка 2: Монтирайте IR сензори

Sharp произвежда няколко различни IR сензора и те имат различни обхвати и зона на покритие. Случайно бях поръчал модела GP2Y0A60SZLF. Избраният от вас модел ще повлияе на разположението и ориентацията на сензора. За мое съжаление не проучих точно кои сензори да си взема. Това беше по -скоро решение „кои мога да получа на разумен час и цена от реномиран източник, извън тези, които предлагат“.

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

Има поне три начина за монтиране на тези сензори върху робота.

1. Поставете ги в фиксирано положение, отпред, обърнати леко един от друг.
2. Поставете ги на серво, отпред, леко обърнати един от друг.
3. Поставете ги в фиксирано положение, отпред, но в най -левия и най -десния най -отдалечен ъгъл, под ъгъл един към друг.

Сравнявайки избор #1 с избор #3, мисля, че #3 ще обхваща повече от зоната на сблъсъка. Ако погледнете изображенията, избор #3 може да бъде направен не само така, че сензорните полета да се припокриват, но също така те могат да покрият центъра и извън външната ширина на робота.

При избор №1, колкото по -отдалечени са сензорите един от друг, толкова повече сляпо петно в центъра.

Бихме могли да направим #2 (добавих някои изображения със серво като възможност) и да ги накарам да извършат почистване и очевидно това може да обхване най -голямата област. Искам обаче да отложа използването на серво възможно най -дълго поради поне две причини:

• Ще използваме един от PWM комуникационните канали на Raspberry Pi. (Възможно е да се подобри това, но все пак …)
• Текущото теглене със серво може да бъде значително
• Той добавя повече към хардуера и софтуера

Бих искал да оставя опцията за серво за по-късно, когато добавям по-важни сензори, като Time-of-Flight (ToF) или може би камера.

Има едно друго възможно предимство при избор #2, което не е налично при другите два варианта. Тези IR сензори могат да се объркат, в зависимост от осветлението. Възможно е роботът да прочете обект, който е непосредствено близо, когато всъщност няма обект в близост. При избор #3, тъй като техните полета могат да се припокриват, и двата сензора могат да регистрират един и същ обект (от различни ъгли).

Така че ще преминем към избор на разположение №3.

Стъпка 3: Време за тестване

След като направихме всички връзки между Raspberry Pi, MCP3008 ADC и IR сензорите Sharp, е време да тестваме. Просто прост тест, за да се уверите, че системата работи с новите сензори.

Както в предишните Instructables, използвам библиотеката wiringPi C колкото е възможно повече. Улеснява нещата. Нещо, което не е много очевидно от прегледа на уебсайта wiringPi, е, че има директна поддръжка за MCP3004/3008.

Дори и без това можете просто да използвате разширението SPI. Но няма нужда. Ако разгледате отблизо git хранилището на Gordon за wiringPi, ще се натъкнете на списък с поддържани чипове, един от които е за MCP3004/3008.

Реших да прикача кода като файл, защото не успях да го покажа правилно на тази страница.

Стъпка 4: Виртуален сензор - AmpSensor

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

Понастоящем роботът разполага с осем HCSR04 акустични сонарни сензора (те не са във фокуса на този Instructable) и сега той има два Sharp IR сензора за разстояние. Както бе посочено по-рано, можем да се възползваме от нещо друго: функцията за отчитане на моторните токове на Roboclaw.

Можем да прехвърлим това извикване на заявка към мотор-контролера в клас C ++ и да го наречем AmpSensor.

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

Ако добавим известна гъвкавост към софтуера (аргументи от командния ред и / или въвеждане на клавиатура по време на работа), тогава можем да увеличим / намалим прага на "критичните усилватели", докато експериментираме, като просто оставим робота да се движи и да се блъска в обекти, както право в, така и докато се върти.

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

Стъпка 5: Навигация

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

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

Докато човек може да получи някаква индикация за разстояние с сензорите, които са в момента на робота, зрителното им поле е широко и има непредсказуемост. Акустичният сонар може да не се отразява правилно обратно; инфрачервеният може да бъде объркан от друго осветление или дори от много отразяващи повърхности. Не съм сигурен, че си струва да се опитате да проследите промяната в разстоянието като техника, за да разберете дали роботът се движи и с колко и в каква посока.

Умишлено избрах да НЕ използвам микроконтролер като Arduino, защото а) не ми харесва, че е среда psuedo-C ++, б) и че твърде много развитие ще износва паметта за четене и запис (?), И че аз ще се нуждае от хост компютър за разработване (?). Или може би просто се случвам като Raspberry Pi.

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

Този подход изглеждаше сложен и с не толкова голяма полза, когато можем да използваме по-добри ToF (време на полет) сензори (по-късно) за тази цел (SLAM).

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

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

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

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

Това означава, че наистина бихме могли да използваме история на команди и да разгледаме как да използваме и използваме тази информация.

Мога да се сетя за два много основни (елементарни) начина за използване на историята на движението.

• за последния X брой ходове съвпадат ли с Y модел. Един прост пример може да бъде (и това се случи) "НАПРЕД, НАВЪРНЕ, НАПРЕД, НАВЪРНЕ, …..". Така че има тази съвпадаща функция, която връща или TRUE (модел е намерен), или FALSE (не е намерен). Ако е ИСТИНА, в навигационната част на програмата опитайте други последователности на движения.
• за последния X брой ходове има ли общо или нетно движение напред. Как може да се определи какво е истинското движение напред? Е.. едно лесно сравнение е, че за последните X ходове "НАПРЕД" се среща повече от "НАВЪРНЕ". Но това не трябва да е единственото. Какво ще кажете за това: „НАДЯСНО, НАДЯСНО, НАЛЯВО, НАДЯСНО“. В този случай роботът трябва да прави десни завои, за да излезе от ъгъла, или защото се приближи до стената под ъгъл, това може да се счита за истински напредък напред. От друга страна, „НАЛЯВО, НАДЯСНО, НАЛЯВО, НАДЯСНО …“може да не се счита за реален напредък напред. По този начин, ако „НАДЯСНО“се среща повече от „НАЛЯВО“или „НАЛЯВО се появява повече от“НАДЯСНО”, това може да е реален напредък.

В началото на тази инструкция споменах, че евентуална трета цел може да бъде изравняване или подравняване към стена. За това обаче се нуждаем от повече от това „близо ли сме до някакъв обект“. Например, ако можем да получим два насочени напред акустични сензора (които не са във фокуса на тази статия), за да дадат сравнително добри, стабилни отговори по отношение на разстоянието, очевидно, ако единият отчита много по-различна стойност от другия, роботът се е приближил до стената под ъгъл и биха могли да опитат някакво маневриране, за да видят дали тези стойности се доближават една до друга (лице към стената правоъгълно).

Стъпка 6: Последни мисли, следваща фаза …

Надявам се този Instructable да даде някои идеи.

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

В горния случай всички акустични сензори работиха добре заедно и това беше доста директно със софтуера.

След като инфрачервените сензори бяха въведени в микса, стана малко по -предизвикателно. Причината е, че някои от техните зрителни полета се припокриват с тези на акустичните сензори. Инфрачервените сензори изглеждаха малко чувствителни и непредсказуеми с променящите се условия на околната светлина, докато естествено акустичните сензори не се влияят от осветлението.

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

Засега след проба и грешка нещата се озоваха в този приоритет:

1. усилвател
2. IR-засичане
3. акустично усещане

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

Досега не е имало нужда да се прави многопоточен или прекъсващ софтуер, въпреки че понякога се сблъсквам със загуба на контрол между Raspberry Pi и Roboclaw мотор-контролера (загуба на серийни комуникации).

Това е мястото, където обикновено ще се използва схемата E-Stop (вижте предишните инструкции). Въпреки това, тъй като не искам (все още) да се налага да се налага да рестартирам Roboclaw по време на разработката, а роботът не върви толкова бързо и аз присъствам, за да го наблюдавам и изключвам, не съм свържете E-Stop.

В крайна сметка най-вероятно ще е необходима многопоточна работа.

Следващи стъпки…

Благодаря ви, че стигнахте дотук.

Получих някои VL53L1X IR лазерен ToF (време на полет) сензори, така че това най-вероятно е темата на следващия Instructable, заедно със серво.