Robot autonomiczny Wallace - część 4 - dodanie czujników odległości na podczerwień i czujników „wzmacniacza”: 6 kroków

2024 Autor: John Day | [email protected]. Ostatnio zmodyfikowany: 2024-01-30 11:31

Witam, dzisiaj rozpoczynamy kolejny etap ulepszania możliwości Wallace'a. W szczególności staramy się poprawić jego zdolność wykrywania i omijania przeszkód za pomocą czujników odległości na podczerwień, a także wykorzystać zdolność kontrolera silnika Roboclaw do monitorowania prądu i przekształcania go w wirtualny (programowy) „czujnik”. Na koniec przyjrzymy się, jak nawigować bez SLAM (jednoczesna lokalizacja i mapowanie) (na razie), ponieważ robot nie ma jeszcze czujników IMU (jednostki pomiaru bezwładności) ani ToF (czasu lotu).

Nawigując, początkowo będą to tylko dwa główne cele:

1. unikaj przeszkód
2. rozpoznać, kiedy gdzieś utknął i nie robi żadnych postępów. („postęp” oznacza, że przesunął się na jakąkolwiek znaczącą odległość)
3. możliwym trzecim celem może być próba wyrównania się prostopadle do ściany.

Ten projekt rozpoczął się od zestawu robota i uzyskania podstawowych ruchów do pracy za pomocą klawiatury i połączenia ssh.

Druga faza polegała na dodaniu wystarczającej liczby obwodów pomocniczych, aby przygotować się na dodanie wielu czujników.

W poprzednim Instructable dodaliśmy kilka czujników akustycznych HCSR04, a robot może teraz omijać przeszkody podczas poruszania się po mieszkaniu.

Chociaż dobrze radzi sobie w kuchni i przedpokoju z dobrymi, solidnymi, płaskimi powierzchniami, jest całkowicie ślepy, gdy zbliża się do jadalni. Nie "widzi" nóg stołu i krzesła.

Jednym z ulepszeń może być śledzenie typowych prądów silnika, a jeśli wartości skaczą, robot musiał w coś uderzyć. To dobry „plan B”, a nawet C. Ale to nie pomaga mu poruszać się po jadalni.

(Aktualizacja: właściwie na razie monitorowanie prądu to plan A podczas cofania, ponieważ tymczasowo usunąłem i czujniki z tyłu).

Film do tej sekcji stanowi końcową fazę czujników omijania przeszkód.

To, co widzisz na filmie, to sześć przednich czujników akustycznych HCSR04 i dwa czujniki podczerwieni Sharp. Czujniki podczerwieni nie odgrywały zbyt wielkiej roli w filmie. Ich mocna strona polega głównie na tym, że robot znajduje się w jadalni naprzeciwko stołu i nóg krzeseł.

Oprócz czujników do gry wszedł monitor prądu, zwłaszcza podczas cofania, na wypadek, gdyby w coś wpadł.

Na koniec wykorzystuje historię ostatnich 100 ruchów i kilka podstawowych analiz, aby odpowiedzieć na jedno pytanie:

„Czy ostatnio nastąpił prawdziwy postęp naprzód (czy może utknął w jakimś powtarzającym się tańcu)?”

Więc w filmie, kiedy widzisz powtórzenie ruchu przód-tył, a potem się obraca, oznacza to, że rozpoznał wzorzec przód-tył, więc próbuje czegoś innego.

Jedynym zaprogramowanym celem tej wersji oprogramowania była próba ciągłego postępu naprzód i próba omijania przeszkód.

Krok 1: Dodaj obwód pomocniczy (MCP3008)

Zanim będziemy mogli dodać czujniki podczerwieni, będziemy potrzebować obwodów interfejsu między nimi a Raspberry Pi.

Dodamy konwerter analogowo-cyfrowy MCP3008. Istnieje wiele zasobów internetowych, jak podłączyć ten układ do Raspberry Pi, więc nie będę się tutaj zbytnio zagłębiał.

Zasadniczo mamy wybór. Jeśli wersja z czujnikami IR pracuje na 3V, tak samo może być z MCP3008, a my możemy wtedy połączyć się bezpośrednio z Raspberry.

[Czujnik 3V IR] - [MCP3008] -- [Raspberry Pi]

W moim przypadku jednak używam głównie 5V, więc oznacza to dwukierunkowy przesuwnik poziomu.

[Czujnik 5V IR] -- [MCP3008] -- [Magistrala dwukierunkowa 5V--3V] -- [Raspberry Pi]

Uwaga: Z czujnika podczerwieni jest tylko jeden sygnał wyjściowy. Przechodzi bezpośrednio do jednej z wejściowych linii sygnału analogowego MCP3008. Z MCP3008 do Raspberry Pi należy podłączyć 4 linie danych (za pośrednictwem dwukierunkowej magistrali).

W tej chwili nasz robot będzie działał na dwóch czujnikach podczerwieni, ale bez problemu moglibyśmy dodać więcej. MCP3008 osiem analogowych kanałów wejściowych.

Krok 2: Zamontuj czujniki podczerwieni

Sharp produkuje kilka różnych czujników podczerwieni, które mają różne zasięgi i obszar zasięgu. Zdarzyło mi się zamówić model GP2Y0A60SZLF. Wybrany model będzie miał wpływ na umiejscowienie i orientację czujnika. Niestety dla mnie, tak naprawdę nie szukałem dokładnie, które czujniki uzyskać. To była bardziej decyzja „które mogę uzyskać w rozsądnym czasie i cenie z renomowanego źródła, spośród tych, które oferują”.

(Aktualizacja: może to jednak nie mieć znaczenia, ponieważ te czujniki wydają się być mylone przez wewnętrzne oświetlenie otoczenia. Nadal badam ten problem)

Istnieją co najmniej trzy sposoby montażu tych czujników na robocie.

1. Umieść je w stałej pozycji, z przodu, lekko od siebie odwrócone.
2. Umieść je na serwo z przodu, lekko od siebie odwrócone.
3. Umieść je w stałej pozycji, z przodu, ale w najdalszych rogach po lewej i prawej stronie, pod kątem do siebie.

Porównując wybór nr 1 z wyborem nr 3, myślę, że nr 3 obejmie większą część obszaru kolizji. Jeśli spojrzysz na obrazy, wybór nr 3 może być dokonany nie tylko po to, aby pola czujników na siebie nachodziły, ale także pokryły środek i poza zewnętrzną szerokość robota.

Przy wyborze nr 1 im bardziej oddalone są od siebie czujniki, tym bardziej martwy punkt w środku.

Moglibyśmy zrobić #2, (dodałem kilka obrazów z serwomechanizmem jako możliwość) i zlecić im przemiatanie, i oczywiście może to pokryć większość obszaru. Jednak chcę jak najdłużej opóźnić użycie serwomechanizmu z co najmniej dwóch powodów:

• Wykorzystamy jeden z kanałów komunikacji PWM na Raspberry Pi. (Można to ulepszyć, ale nadal…)
• Pobór prądu z serwomechanizmem może być znaczny
• Dodaje więcej do sprzętu i oprogramowania

Opcję serwo chciałbym zostawić na później przy dodawaniu ważniejszych sensorów, takich jak Time-of-Flight (ToF), czy może kamera.

Istnieje jeszcze jedna możliwa zaleta wyboru nr 2, która nie jest dostępna w przypadku dwóch pozostałych opcji. Te czujniki podczerwieni mogą się pomylić w zależności od oświetlenia. Może się zdarzyć, że robot odczyta obiekt, który znajduje się tuż obok, podczas gdy w rzeczywistości w pobliżu nie ma żadnego obiektu. Przy wyborze #3, ponieważ ich pola mogą się nakładać, oba czujniki mogą rejestrować ten sam obiekt (pod różnymi kątami).

Więc idziemy z wyborem umiejscowienia #3.

Krok 3: Czas na test

Po wykonaniu wszystkich połączeń między Raspberry Pi, MCP3008 ADC i czujnikami podczerwieni Sharp, nadszedł czas na testy. Wystarczy prosty test, aby upewnić się, że system działa z nowymi czujnikami.

Podobnie jak w poprzednich Instruktażach, w jak największym stopniu korzystam z biblioteki okablowaniaPi C. Ułatwia sprawę. Coś, co nie jest zbyt oczywiste z przeglądu strony okablowaniaPi, to to, że istnieje bezpośrednie wsparcie dla MCP3004/3008.

Nawet bez tego możesz po prostu użyć rozszerzenia SPI. Ale nie ma takiej potrzeby. Jeśli przyjrzysz się bliżej repozytorium git Gordona dla okablowaniaPi, natkniesz się na listę obsługiwanych układów, z których jeden jest przeznaczony dla MCP3004/3008.

Postanowiłem dołączyć kod jako plik, ponieważ nie mogłem go poprawnie wyświetlić na tej stronie.

Krok 4: Czujnik wirtualny - AmpSensor

Im więcej różnych sposobów, w jakie robot może otrzymywać informacje o świecie zewnętrznym, tym lepiej.

Robot ma obecnie osiem akustycznych czujników sonarowych HCSR04 (nie są one przedmiotem tego Instruktażu), a teraz ma dwa czujniki odległości Sharp IR. Jak wspomniano wcześniej, możemy skorzystać z czegoś innego: funkcji wykrywania prądów motorycznych Roboclawa.

Możemy opakować to wywołanie zapytania do kontrolera silnika w klasę C++ i nazwać go AmpSensor.

Dodając do oprogramowania „smarty” możemy monitorować i regulować typowy pobór prądu podczas ruchu prostego (do przodu, do tyłu), a także ruchu obrotowego (w lewo, w prawo). Gdy znamy te zakresy amperów, możemy wybrać wartość krytyczną, tak że jeśli AmpSensor otrzyma odczyt prądu z kontrolera silnika, który przekracza tę wartość, wiemy, że silniki prawdopodobnie się zatrzymały, co zwykle oznacza, że robot wpadł w coś.

Jeśli dodamy trochę elastyczności do oprogramowania (argumenty wiersza poleceń i/lub wprowadzanie danych z klawiatury podczas pracy), możemy zwiększyć/zmniejszyć próg „krytycznych amperów” podczas eksperymentowania, po prostu pozwalając robotowi poruszać się i wpadać na obiekty, zarówno na wprost, jak i podczas obracania.

Ponieważ nasza nawigacyjna część oprogramowania zna kierunek ruchu, możemy wykorzystać wszystkie te informacje, aby być może zatrzymać ruch i spróbować odwrócić ruch na krótki czas, zanim spróbujemy czegoś innego.

Krok 5: Nawigacja

Robot jest obecnie ograniczony w rzeczywistych informacjach zwrotnych. Posiada kilka czujników bliskiej odległości do omijania przeszkód i posiada technikę awaryjnego monitorowania poboru prądu w przypadku, gdy czujniki odległości ominą przeszkodę.

Nie ma silników z enkoderami i nie ma IMU (inertial-pomiar-jednostka), więc trudniej jest stwierdzić, czy rzeczywiście się porusza, czy obraca io ile.

Chociaż można uzyskać pewne wskazanie odległości za pomocą czujników znajdujących się obecnie na robocie, ich pole widzenia jest szerokie i jest nieprzewidywalność. Sonar akustyczny może nie odbijać prawidłowo; podczerwień może być mylona z innym oświetleniem, a nawet wieloma powierzchniami odbijającymi światło. Nie jestem pewien, czy rzeczywiście warto próbować śledzić zmianę odległości jako technikę, aby wiedzieć, czy robot się porusza, o ile i w jakim kierunku.

Celowo zdecydowałem się NIE używać mikrokontrolera takiego jak Arduino, ponieważ a) nie podoba mi się jego środowisko pseudo-C++, b) i że zbyt duży rozwój zużyje pamięć do odczytu i zapisu (?) i że ja potrzebowałby komputera-hosta do rozwoju (?). A może po prostu się zdarzam jak Raspberry Pi.

Jednak Pi z systemem Raspbian nie jest systemem operacyjnym czasu rzeczywistego, więc między niestabilnością tych czujników a nieodczytywaniem systemu operacyjnego za każdym razem, czułem, że cel tych czujników jest lepiej dostosowany do unikania przeszkód, a nie rzeczywisty pomiar odległości.

Podejście to wydawało się skomplikowane i nie przynosiło większych korzyści, gdy możemy do tego celu użyć lepszych czujników ToF (późniejszego przelotu) (SLAM).

Jednym z podejść, które możemy zastosować, jest śledzenie tego, jakie polecenia ruchu zostały wydane w ciągu ostatnich X sekund lub poleceń.

Jako przykład powiedzmy, że robot utknął w kącie po przekątnej. Jeden zestaw czujników mówi mu, że jest za blisko jednej ściany, więc się obraca, ale drugi zestaw czujników mówi mu, że jest za blisko drugiej ściany. Kończy się po prostu powtarzaniem wzoru z boku na bok.

Powyższy przykład to tylko jeden bardzo prosty przypadek. Dodanie kilku sprytów może po prostu podnieść powtarzany wzór na nowy poziom, ale robot pozostaje w kącie.

Przykład, zamiast obracać się tam i z powrotem w miejscu, obraca się w jedną stronę, robi chwilowe cofanie (co następnie usuwa wskazania odległości krytycznej), a nawet jeśli obraca się w przeciwnym kierunku, nadal porusza się do przodu pod pewnym kątem z powrotem w róg, powtarzając bardziej skomplikowany tupot zasadniczo tego samego.

Oznacza to, że naprawdę moglibyśmy wykorzystać historię poleceń i przyjrzeć się, jak wykorzystać i wykorzystać te informacje.

Przychodzą mi do głowy dwa bardzo podstawowe (szczątkowe) sposoby wykorzystania historii ruchu.

• dla ostatniej liczby ruchów X, czy pasują do wzorca Y. Prostym przykładem może być (i tak się stało) „DO PRZODU, DO TYŁU, DO PRZODU, DO TYŁU, …..”. Mamy więc funkcję dopasowującą, która zwraca TRUE (znaleziono wzorzec) lub FALSE (nie znaleziono). Jeśli TRUE, w części nawigacyjnej programu, spróbuj innych sekwencji ruchu.
• dla ostatnich X ruchów, czy istnieje ogólny lub netto ruch do przodu. Jak można określić, czym jest prawdziwy ruch naprzód? Cóż.. jedno proste porównanie jest takie, że dla ostatnich X ruchów, "DO PRZODU" występuje częściej niż "WSTECZ". Ale to nie musi być jedyne. Co powiesz na to: "PRAWO, PRAWO, LEWO, PRAWO". W takim przypadku robot musi skręcić w prawo, aby wyjść z zakrętu lub ponieważ zbliżył się do ściany pod kątem, co można uznać za prawdziwy postęp naprzód. Z drugiej strony „LEWO, PRAWO, LEWO, PRAWO…” może nie być uważane za prawdziwy postęp naprzód. Tak więc, jeśli „PRAWY” występuje częściej niż „LEWO” lub „LEWO występuje częściej niż „PRAWY”, to może to być prawdziwy postęp.

Na początku tego Instructable wspomniałem, że możliwym trzecim celem może być wyrównanie lub wyrównanie do ściany. Do tego jednak potrzebujemy czegoś więcej niż „czy jesteśmy blisko jakiegoś obiektu”. Na przykład, jeśli możemy uzyskać dwa skierowane do przodu czujniki akustyczne (nie jest to przedmiotem tego artykułu), aby dawały dość dobre, stabilne reakcje na odległość, oczywiście jeśli jeden zgłasza znacznie inną wartość niż drugi, robot zbliżył się do ściany pod kątem i mógłby spróbować manewrować, aby sprawdzić, czy te wartości zbliżają się do siebie (stojąc prosto w ścianę).

Krok 6: Ostatnie myśli, następna faza…

Mam nadzieję, że ten Instruktaż podał kilka pomysłów.

Dodanie większej liczby czujników wprowadza pewne zalety i wyzwania.

W powyższym przypadku wszystkie czujniki akustyczne dobrze ze sobą współpracowały i było to dość proste z oprogramowaniem.

Gdy czujniki podczerwieni zostały wprowadzone do miksu, stało się to nieco trudniejsze. Powodem jest to, że niektóre z ich pól widzenia pokrywały się z polami czujników akustycznych. Czujniki podczerwieni wydawały się nieco czułe i nieprzewidywalne przy zmieniających się warunkach oświetlenia otoczenia, podczas gdy oświetlenie nie ma wpływu na czujniki akustyczne.

Tak więc wyzwaniem było to, co zrobić, jeśli czujnik akustyczny mówi nam, że nie ma przeszkody, ale czujnik podczerwieni tak.

Na razie, po próbach i błędach, wszystko skończyło się w tym priorytecie:

1. amp-sensing
2. wykrywanie podczerwieni
3. wyczuwanie akustyczne

A ja tylko zmniejszyłem czułość czujników podczerwieni, aby wykrywały tylko bardzo bliskie obiekty (takie jak zbliżające się nogi krzesła)

Jak dotąd nie było potrzeby tworzenia oprogramowania wielowątkowego lub opartego na przerwaniach, chociaż czasami spotykam się z utratą kontroli między Raspberry Pi a kontrolerem silnika Roboclaw (utrata komunikacji szeregowej).

W tym miejscu zwykle stosuje się obwód E-Stop (patrz poprzednie instrukcje). Ponieważ jednak nie chcę (jeszcze) mieć do czynienia z koniecznością resetowania Roboclawa podczas programowania, a robot nie działa tak szybko, a ja jestem obecny, aby go monitorować i wyłączać, nie podłączony wyłącznik awaryjny.

Ostatecznie najprawdopodobniej konieczne będzie wielowątkowość.

Następne kroki…

Dziękuję, że dotarłeś tak daleko.

Zdobyłem kilka czujników laserowych ToF (time-of-flight) VL53L1X IR, więc najprawdopodobniej jest to temat następnego Instructable, wraz z serwomechanizmem.