Cześć!
Korzystając z okazji (i konkursu) chciałem Wam opisać konstrukcję robota, nad którym pracuję od 2 lat (w chwilach wolnych).
Założenia projektu są proste:
Robot, który będzie w stanie samodzielnie przejechać z punktu A do B na podstawie obrazu z kamery (lub kamery 3d).
Jest to "duchowy spadkobierca" mojego projektu inżynierskiego- robota który podążał za tagami 2d na podstawie obrazu z kamery telefonu z Androidem.
Przez ostatnie 2 lata powstały 3 konstrukcje:
Proof of concept- robot wyposażony w raspbery pi, kamerkę zasilany z baterii AAA. Jak widać, nie wygląda najładniej, ale spełnił założenia.
Dało się sterować robotem z telefonu z Androidem z zainstalowaną aplikacją mobilną. No i przede wszystkim była to moja pierwsza konstrukcja wykonana w technice druku 3d.
Aplikacja napisana na telefon wysyłała komendy poprzed ZeroMQ. W robocie, na Raspberry-pi zainstalowany był skrypt napisany w pythonie odbierający komendy i przesyłający je poprzez port szeregowy do kompatybilnego z Arduino Trinket-PRO od Adafruit.
Druga wersja robota odziedziczyła po pierwszym większość elektroniki, tj: mostki H oraz jedną z dwóch raspberrek.
Czemu dwie?
Koncepcja ewoluowała i polegała na wykorzystaniu dwóch par raspberry-pi+dedykowana kamera i wyciąganiu głębi ze stereoskopowego obrazu.
Chciałem także obraz przetwarzać bezpośrednio na robocie. Do tego chciałem, aby raspberrki w tamdemie były repeaterem wifi, tj jedna z nich łączyłaby się do access pointa, przekazywała połączenie przez ethernet do drugiej, która wystawiała własną sieć.
O ile udało stworzyć rzeczoną sieć, o tyle samo przetwarzanie stereoskopowego obrazu (w dobrej jakości) tylko na mikrokomputerkach była zbyt trudna.
Próbowałem także przesyłać obraz do odpowiednio mocno komputera, ale dopiero po zrezygnowaniu z łączenia komputerków w sieć, udało mi się zniwelować różnice opóźnień spowodowane niesymetryczną ilością komputerów w obu połączeniach (początkowo obraz z lewej kamery przechodził przez jedno raspberry pi, obraz z prawej przechodził przez dwie).
Zaimplementowałem dwie różne metody wyciągania głębi z obrazu:
Po skalibrowaniu obrazów z kamer, tak aby zniwelować różnice w geometrii kamer, szukałem par feature-pointów o tych samych współrzędnych Y. Różnica osi X pozwalała dość dokładnie określić odległość kamer od punktu w przestrzeni.
Problemem jednak okazała się regularność występowania feature pointów, oraz zależność ilości feature pointów od 'ciekawości obrazu' (na białej ścianie nie dało się znaleźć praktycznie żadnego, a na obrazie wypełnionym załóżmy trawą, było ich aż nadto).
(przykład z google'a- niestety nie mam zdjęcia)
Drugie podejście zakładało wykorzystanie mechanizmów wbudowanych w OpenCV- tak zwanej disparity-map. Ale i to podejście okazało się zawodne. Nakład mocy obliczeniowej był (względnie) duży, a jakość nadal pozostawiała wiele do życzenia. Nie ma także dobrego sposobu, żeby odczytać dokładną odległość w dobrej rozdzielczości.
Sam układ zasilania nie wykorzystywał już 6 paluszków, ale akumulator 2s 7.2v.
Trzecia (aktualna) wersja powstała po zaprezentowaniu w pracy drugiej. Mikrosilniczki pololu, mimo że wystarczające do poruszania konstrukcją nie dość, że strasznie się grzały, do tego hałasowały. Przez to wszystko czołg brzmiał bardziej jak tania chińska zabawka, niż jak poważna konstrukcja, którą chciałbym się chwalić w internecie.
Z tego powodu "poszedłem" na (największe jak do tej pory) zakupy do Botland'u. 16V/9A podwójny mostek H, para silników 37Dx70L 12V 1,19Nm każdy, do tego zasilanie z jednego z największych pakietów 3s 11,1V dostępnych wtedy w sklepie.
W międzyczasie także pracowałem nad nową ramą do robota, której proces drukowania także został mocno poprawiony.
Po zebraniu wszystkiego do kupy i zrezygnowaniu z stereoskopowej kamery, rozwiązaniu problemów z wyważeniem robota, powtała taka konstrukcja:
Filmik na instagramie z działającym robotem
W miejsce kamer wstawiony został sensor Kinect (który jak się okazało kosztuje tyle co jedna dedykowana raspberry pi kamerka). Okazało się także, że Kinecta można bardzo bardzo odchudzić- pozbawiłem go mikrofonów kierunkowych, obudowy, aktywnego chłodzenia, diody, silnika sterującego pochyleniem.
Sam obraz odczytywany jest przez (jedno) raspberry pi i wystawiany przez skrypt napisany w pythonie z wykorzystaniem frameworku o nazwie flask. Zrezygnowałem także z ZeroMQ na rzecz prostego RESTowego API. Nie ma także żadnej aplikacji na telefon z Androidem- napisałem prosty frontend w java-scripcie, który pozwala na sterowanie robotem.
Trinket został zastąpiony przez Arduino PRO mega mający o wiele więcej wyjść. Robot został wyposażony w moduł IMU, oraz moduł GPS.
Do konfiguracji linuksa wykorzystuję Ansible, które jest odpowiedzialne za instalacje zależności, serwisów, update'owanie kodu arduino oraz pilnowanie, żeby wszystko było w porządku.
Praca nad konstrukcją ciągle jeszcze nie jest zakończona, ale źródła ciągle są aktualizowane. Od czasu do czasu zdarza mi się przecholować z dokładaniem ficzerów do konstrukcji, albo po prostu zatnę się w jakimś momencie z powodu jakiegoś problemu i odechciewa mi się rozbudowywać konstrukcję na tydzień lub 2 (aktualnie tak mam).
Główne repozytorium znajduje się na moim githubie: https://github.com/szymonrychu/kinect_tank
Konstrukcji ciąle brakuje:
* czytania enkoderów- ich ogromna rozdzielczość powoduje, że przerwania w Arduino występują o wiele za szybko. Chcę użyć przerzudników D, żeby sobie nieco ułatwić (odchudzić procedury przerwań, podzielić ich ilość w czasie przez 4).
* Zaimplementowanie PID'a na podstawie zliczonych przerwań
* Zaimplementowanie PID'a do sterowania pochyleniem kinecta
* Implementacja vSLAM'a - robot ma być "świadomy" swojej pozycji w przestrzeni
* Implementacja omijania przeszkód, dodanie sterowania siecią neuronową
Z chęcią odpowiem na pytania apropos robota.
Pozdrawiam!
PS. wiem wiem- elektroda jest forum o elektronice, a ja moją składam z brzydko połączonych modułów. Praca ciągle trwa..
Korzystając z okazji (i konkursu) chciałem Wam opisać konstrukcję robota, nad którym pracuję od 2 lat (w chwilach wolnych).
Założenia projektu są proste:
Robot, który będzie w stanie samodzielnie przejechać z punktu A do B na podstawie obrazu z kamery (lub kamery 3d).
Jest to "duchowy spadkobierca" mojego projektu inżynierskiego- robota który podążał za tagami 2d na podstawie obrazu z kamery telefonu z Androidem.
Przez ostatnie 2 lata powstały 3 konstrukcje:
Proof of concept- robot wyposażony w raspbery pi, kamerkę zasilany z baterii AAA. Jak widać, nie wygląda najładniej, ale spełnił założenia.
Dało się sterować robotem z telefonu z Androidem z zainstalowaną aplikacją mobilną. No i przede wszystkim była to moja pierwsza konstrukcja wykonana w technice druku 3d.
Aplikacja napisana na telefon wysyłała komendy poprzed ZeroMQ. W robocie, na Raspberry-pi zainstalowany był skrypt napisany w pythonie odbierający komendy i przesyłający je poprzez port szeregowy do kompatybilnego z Arduino Trinket-PRO od Adafruit.
Druga wersja robota odziedziczyła po pierwszym większość elektroniki, tj: mostki H oraz jedną z dwóch raspberrek.
Czemu dwie?
Koncepcja ewoluowała i polegała na wykorzystaniu dwóch par raspberry-pi+dedykowana kamera i wyciąganiu głębi ze stereoskopowego obrazu.
Chciałem także obraz przetwarzać bezpośrednio na robocie. Do tego chciałem, aby raspberrki w tamdemie były repeaterem wifi, tj jedna z nich łączyłaby się do access pointa, przekazywała połączenie przez ethernet do drugiej, która wystawiała własną sieć.
O ile udało stworzyć rzeczoną sieć, o tyle samo przetwarzanie stereoskopowego obrazu (w dobrej jakości) tylko na mikrokomputerkach była zbyt trudna.
Próbowałem także przesyłać obraz do odpowiednio mocno komputera, ale dopiero po zrezygnowaniu z łączenia komputerków w sieć, udało mi się zniwelować różnice opóźnień spowodowane niesymetryczną ilością komputerów w obu połączeniach (początkowo obraz z lewej kamery przechodził przez jedno raspberry pi, obraz z prawej przechodził przez dwie).
Zaimplementowałem dwie różne metody wyciągania głębi z obrazu:
Po skalibrowaniu obrazów z kamer, tak aby zniwelować różnice w geometrii kamer, szukałem par feature-pointów o tych samych współrzędnych Y. Różnica osi X pozwalała dość dokładnie określić odległość kamer od punktu w przestrzeni.
Problemem jednak okazała się regularność występowania feature pointów, oraz zależność ilości feature pointów od 'ciekawości obrazu' (na białej ścianie nie dało się znaleźć praktycznie żadnego, a na obrazie wypełnionym załóżmy trawą, było ich aż nadto).
(przykład z google'a- niestety nie mam zdjęcia)
Drugie podejście zakładało wykorzystanie mechanizmów wbudowanych w OpenCV- tak zwanej disparity-map. Ale i to podejście okazało się zawodne. Nakład mocy obliczeniowej był (względnie) duży, a jakość nadal pozostawiała wiele do życzenia. Nie ma także dobrego sposobu, żeby odczytać dokładną odległość w dobrej rozdzielczości.
Sam układ zasilania nie wykorzystywał już 6 paluszków, ale akumulator 2s 7.2v.
Trzecia (aktualna) wersja powstała po zaprezentowaniu w pracy drugiej. Mikrosilniczki pololu, mimo że wystarczające do poruszania konstrukcją nie dość, że strasznie się grzały, do tego hałasowały. Przez to wszystko czołg brzmiał bardziej jak tania chińska zabawka, niż jak poważna konstrukcja, którą chciałbym się chwalić w internecie.
Z tego powodu "poszedłem" na (największe jak do tej pory) zakupy do Botland'u. 16V/9A podwójny mostek H, para silników 37Dx70L 12V 1,19Nm każdy, do tego zasilanie z jednego z największych pakietów 3s 11,1V dostępnych wtedy w sklepie.
W międzyczasie także pracowałem nad nową ramą do robota, której proces drukowania także został mocno poprawiony.
Po zebraniu wszystkiego do kupy i zrezygnowaniu z stereoskopowej kamery, rozwiązaniu problemów z wyważeniem robota, powtała taka konstrukcja:
Filmik na instagramie z działającym robotem
W miejsce kamer wstawiony został sensor Kinect (który jak się okazało kosztuje tyle co jedna dedykowana raspberry pi kamerka). Okazało się także, że Kinecta można bardzo bardzo odchudzić- pozbawiłem go mikrofonów kierunkowych, obudowy, aktywnego chłodzenia, diody, silnika sterującego pochyleniem.
Sam obraz odczytywany jest przez (jedno) raspberry pi i wystawiany przez skrypt napisany w pythonie z wykorzystaniem frameworku o nazwie flask. Zrezygnowałem także z ZeroMQ na rzecz prostego RESTowego API. Nie ma także żadnej aplikacji na telefon z Androidem- napisałem prosty frontend w java-scripcie, który pozwala na sterowanie robotem.
Trinket został zastąpiony przez Arduino PRO mega mający o wiele więcej wyjść. Robot został wyposażony w moduł IMU, oraz moduł GPS.
Do konfiguracji linuksa wykorzystuję Ansible, które jest odpowiedzialne za instalacje zależności, serwisów, update'owanie kodu arduino oraz pilnowanie, żeby wszystko było w porządku.
Praca nad konstrukcją ciągle jeszcze nie jest zakończona, ale źródła ciągle są aktualizowane. Od czasu do czasu zdarza mi się przecholować z dokładaniem ficzerów do konstrukcji, albo po prostu zatnę się w jakimś momencie z powodu jakiegoś problemu i odechciewa mi się rozbudowywać konstrukcję na tydzień lub 2 (aktualnie tak mam).
Główne repozytorium znajduje się na moim githubie: https://github.com/szymonrychu/kinect_tank
Konstrukcji ciąle brakuje:
* czytania enkoderów- ich ogromna rozdzielczość powoduje, że przerwania w Arduino występują o wiele za szybko. Chcę użyć przerzudników D, żeby sobie nieco ułatwić (odchudzić procedury przerwań, podzielić ich ilość w czasie przez 4).
* Zaimplementowanie PID'a na podstawie zliczonych przerwań
* Zaimplementowanie PID'a do sterowania pochyleniem kinecta
* Implementacja vSLAM'a - robot ma być "świadomy" swojej pozycji w przestrzeni
* Implementacja omijania przeszkód, dodanie sterowania siecią neuronową
Z chęcią odpowiem na pytania apropos robota.
Pozdrawiam!
PS. wiem wiem- elektroda jest forum o elektronice, a ja moją składam z brzydko połączonych modułów. Praca ciągle trwa..
Cool? Ranking DIY
