Przeszukaj forum
Pokazywanie wyników dla tagów 'LF Light'.
Znaleziono 2 wyniki
-
Cześć! Powoli zauważam, że roboty tego typu zaczynają wymierać i odchodząc na lf-ową "emeryturkę" chciałbym zostawić jakiś ślad po swoim projekcie. Choć na zawodach nigdy nie szczędzę informacji na temat swojego robota i chętnie dzielę się wiedzą oraz doświadczeniem w temacie, to mam wrażenie, że ilość lepszych robotów w konkurencji nie zwiększa się, a nawet spada. Na zawodach starzy bywalce ścigają się między sobą, a młodzi pewnie zniechęcają się do konkurencji, ze względu na wysoki próg wejścia do walki o nagrody. Cukiereczek - LineFollower bez turbiny (Nazwa nawiązuje do mojej poprzedniej konstrukcji - Candy). Jest to robot, którego zbudowałem w ramach pracy przejściowej magisterskiej między styczniem a marcem 2018r. Debiutował na zawodach Robomaticon 2018 w Warszawie, gdzie zajął 3 miejsce, zaraz za Candy (zabrakło czasu na napisanie sensownego programu). Później rozwijane było oprogramowanie, które zostało tematem pracy dyplomowej. Wydaje mi się, że jest to obecnie najszybszy robot w swojej kategorii w Polsce, aczkolwiek scena LF od 2018r. mocno się uszczupliła - być może o potencjalnie szybszą konstrukcję. Główne cechy: 12 czujników linii Mikrokontroler STM32 F7 IMU: żyroskop + akcelerometr RGB 🙃 Lidar ToF USB karta µSD Bluetooth 4.2 Własny mostek H Enkodery magnetyczne 1. Konstrukcja mechaniczna Wydaje mi się, że kształtem przypomina robota Fuzzy, którym swego czasu mocno się inspirowałem przy robocie Candy. Mam nadzieję, że nikt tutaj nie uzna robota za bezpośrednią kopię - kształt jest zdecydowanie inny, podyktowany konkretnymi założeniami i doświadczeniami z poprzednich konstrukcji. Podwozie stanowią 2 moduły PCB: płytki głównej oraz płytki z czujnikami linii, połączone ze sobą taśmą FFC i usztywnione węglową listewką modelarską. Ślizg przedniej listewki zapewniają 2 ścięte łby nylonowych śrubek, z doklejoną podkładką teflonową. Z tyłu robota doklejony jest wheelie bar, w postaci kawałka listewki węglowej ze śrubką oraz teflonem. Wielokrotnie przerobiony temat - gdyby nie podpórka, robot wywracałby się do góry dołem oraz podskakiwał na każdym zakręcie. Napęd: 2 silniki szczotkowe Pololu HPCB 10:1 z obustronnym wałem, na który nałożono magnes 6x2.5 do enkodera magnetycznego. Koła to felgi wydrukowane na drukarce 3D z oponami Mini- Z. Nie dają takiej przyczepności jak poliuretan, ale nie udało mi się dobrać lepszych kół przy samodzielnym odlewaniu. Silniki zostały odrobinę podniesione podkładkami z PCB o grubości 1mm oraz kauczukiem tłumiącym wibracje. Do ich montażu wykorzystałem standardowe, plastikowe mocowania Pololu. Waga konstrukcji to 55.5g (66g z akumulatorem). Nie była priorytetem. 2. Elektronika Wszystkie płytki PCB zostały wykonane w firmie Techno Service z Gdańska. Płytka główna oraz płytka z czujnikami to płytki 4-warstwowe, pozostałe: płytki enkoderów oraz płytka IMU, 2-warstwowe. Schemat oraz layout stworzyłem w programie Altium Designer. Robot może być zasilany z akumulatora li-po 2-4S (6-17V) lub bezpośrednio z USB (bez możliwości uruchomienia silników). Oprócz pomiaru napięcia wejściowego, dodatkowo wstawiono układ pomiaru prądu pobieranego przez robota. Robot startuje obecnie z akumulatorami 2S, 180mAh, 50C. Sekcję zasilania (oprócz sekcji silnikowej) stanowi przetwornica 5V 1A, oraz układy LDO na napięcie 3.3V (osobne dla MCU, sekcji analogowej oraz czujnika IMU). Na płytce czujników znalazło się 12 transoptorów KTIR0711S. Są gęsto ułożone w jednakowych odstępach tworząc delikatny łuk. Zdecydowano się na proste rozwiązanie hardware'owe, dające równomierne odczyty z trasy. Przekombinowany układ czujników mógłby powodować dodatkowe komplikacje (różne odczyty na odsuniętych czujnikach, wpływ nierówności trasy - odległości sensorów od podłoża), więc wszelkie wykrywania dziwnych elementów na trasie realizowane są software'owo. Moduł IMU został zamocowany na padzie kauczukowym tłumiącym wibracje. Użyto sensora Invensense ICM-20602. Jak widać na zdj. poniżej, bardzo poważnie potraktowałem kwestię wibracji, które mają spory wpływ na odczyty. Wykorzystany czujnik posiada wysoką czułość i jest wrażliwy na wibracje i naprężenia. Sensor posiada dedykowaną linię zasilania z oddzielnego LDO o wysokim PSRR. Mostki H zbudowano na układach przekształtnikowych TI DRV8703 oraz tranzystorach N-FET: Toshiba TPWR8503NL. Taki układ mimo, że skonstruowany mocno na wyrost, pozwala na dowolne wysterowanie silnika, w tym zmianę kierunku obrotu bez żadnych dodatkowych opóźnień. Poprzednio stosowane mostki, popularne TB6612 wymagały łączenia kanałów i stosowania opóźnień. Wydajność takiego mostka szacuję na ok. 10A ciągłego prądu (z prądem chwilowym sięgającym +100A), sensownie byłoby lepiej dopasować mostek do wykorzystanych silników, jednak ze względu brak czasu na testowanie i chęć zamknięcia projektu w jednej rewizji PCB, postawiłem na "zero kompromisów". Dodatkowym założeniem była chęć ewentualnej zmiany silników na mocniejsze. Enkodery to AS5047P zamontowane na pionowych płytkach PCB. Podłączone zostały magistralą SPI. Dokonują pomiaru kąta absolutnego, z rozdzielczością 14 bitów. Uwzględniając przekładnię mechaniczną, można uzyskać ponad 160 tysięcy jednostek na obrót koła. Mikrokontroler zastosowany w projekcie to STM32F722 w LQFP64. MCU taktowany jest z częstotliwością 216MHz. Wszystkie piny procesora zostały wykorzystane. Posiada bardzo duży zasób obliczeniowy, znacznie większy od F1, dzięki czemu algorytmy sterujące mogą być skomplikowane i nie trzeba rezygnować z obliczeń na floatach. Karta µSD podłączona została pod SDMMC, na 4-bitowej szynie SDIO. Czujnik odległości to ST VL53L1X, laserowy czujnik Time of Flight, podłączony pod magistralę I2C. Został umieszczony na mocowaniu silnika, w celu uniknięcia dodatkowej bezwładności na listewce robota. Posiada spory zasięg, więc utrata długości z listewki nie jest problemem. Niestety czujnik domyślnie posiada spory field of view, który można odrobinę zmniejszyć tracąc również na zasięgu. Mam z tym czujnikiem sporo problemów. Na zawodach w Rzeszowie wyłapywał patyczki znaków drogowych postawionych przy trasie (inni zawodnicy nie mieli z nimi problemu) oraz bardzo często zdarza mi się, że silnik potrafi zawiesić czujnik podczas przejazdu. Rozwiązania w tej formie nie polecam. 3. Oprogramowanie Przy prowadzeniu projektu wspomagałem się programem CubeMX, a kod pisany był w środowisku Atollic TrueStudio. Poza bibliotekami CubeHAL, z których korzystam, całość własnego kodu została napisana w języku C++. Kod został podzielony na klasy, często wykorzystując przy tym mechanizm dziedziczenia. Użycie C++ pozwoliło wygodnie operować kodem, którego fragmenty wykorzystuję również w innych swoich projektach. Zrezygnowano z wykorzystania RTOSa (FreeRTOS w tym przypadku), ze względu na spory koszt samego OS przy pętlach rzędu 10kHz. STM serii F7 posiada wystarczająco dużo timerów, aby poszczególne zadania podzielić w niezależne pętle z własnym priorytetem. Do obsługi czujników linii, wykorzystano "tylko" 1 przetwornik ADC. Łączenie kilku przetworników w celu uzyskania szybszych pomiarów uznałem za bezcelowe, gdyż prawdopodobnie i tak musiałbym wyzwalać pomiary timerem, aby nadążyć z przetwarzaniem pomiarów. Obecnie pomiary wykonują się z częstotliwością ok. 56kHz i każda próbka brana jest pod uwagę podczas przejazdu. Pozycja linii wyznaczana jest w prosty sposób, przy pomocy średniej z wag przypisanych do każdego czujnika. Wagi czujników są u mnie odrobinę nieliniowe. Osobno rozpatrywane są "przypadki specjalne", gdy pod czujnikami brakuje linii itp. Osobny przetwornik wykorzystano do pomiaru napięcia i prądu. Liczona jest także zużyta pojemność baterii. Pętla sterowania silnikami z regulatorami PID wykonuje się z częstotliwością 8kHz. Nastawy zostały dobrane po części w Matlabie, później dostrojone empirycznie. Pętla żyroskopu również wykonuje się z częstotliwością 8kHz, taktowana jest przerwaniem dataready czujnika. Żyroskop wykorzystuję obecnie do omijania przeszkód oraz w odometrii. Główna pętla - podążania za linią wykonuje się z częstotliwością 400Hz. Sterowanie odbywa się poprzez typowy regulator PD, którego nastawy dobrane zostały metodą prób i błędów, bazując również na poprzedniej konstrukcji - przyspieszony proces. 4. Dodatki Sygnalizacja RGB - Zamiast niezależnych diod LED, wykorzystałem 4 diody WS2812B, które mogłem podłączyć do 1 pinu mikrokontrolera (a zużyłem wszystkie). Na diodach sygnalizowany są stany poszczególnych elementów robota, np. kalibracji żyroskopu, stanu baterii, stanu załączenia silników czy błędu regulatora linii. Interfejs USB - Jedyne złącze użytkowe w robocie. Jako, że interfejs SWD programowania wyprowadziłem w postaci padów do lutowania, "codzienne" programowanie robota odbywało się przez interfejs USB w trybie DFU. Napisany został kod umożliwiający przejście mikrokontrolera do wewnętrznego bootloadera, a następnie wgranie nowego programu. USB służył także do debugowania poprzez port COM. Karta µSD do logowania danych podczas przejazdu. Logowanie odbywa się w tle, w czasie wolnym procesora. Dane zbieram z częstotliwością ~1kHz i zapisuję binarnie w pliku (system FAT32). Logi dostarczyły mi sporo informacji "ukrytych" w robocie i przydały się w pracy magisterskiej. Poniżej przykładowe wykresy dla poboru energii, sterowania, czy utworzonej mapy trasy z uwzględnieniem omijania przeszkody. Aplikacja na smartfon pod moduł BT 4.2. Stosując moduł inny niż HC-05, zmuszony byłem stworzyć własną aplikację smartfonową do zmiany nastaw robota oraz zdalnego startu. 5. Osiągnięcia: 1 miejsce, LineFollower bez turbiny, Robomaticon 2019 w Warszawie , 9 marca 2019 1 miejsce, LineFollower Standard, XI Robotic Arena – Wrocław, 12 stycznia 2019 1 miejsce, LineFollower Enhanc3D, XI Robotic Arena – Wrocław, 12 stycznia 2019 1 miejsce, LineFollower Standard, Bałtyckie Bitwy Robotów w Gdańsku, 26-27 maja 2018 3 miejsce, LineFollower 3D, Bałtyckie Bitwy Robotów w Gdańsku, 26-27 maja 2018 1 miejsce, LineFollower Standard, Zawody ROBO~motion w Rzeszowie, 19 maja 2018 3 miejsce, LineFollower bez turbiny, Robomaticon 2018 w Warszawie, 3 marca 2018 Poniżej kilka filmów:
- 22 odpowiedzi
-
- 15
-
- LF Light
- LF Standard
-
(i 1 więcej)
Tagi:
-
RoChN 4 to robot typu linefollower, kolejny z serii Robotów o Chwytliwych Nazwach. Jest to konstrukcja w dużej mierze eksperymentalna, stworzona w celu przetestowania nowych pomysłów i komponentów. Wyniki nie były priorytetem, ale robot radzi sobie całkiem nieźle. Prawdopodobnie należy do kilku najlepszych, startujących na zawodach, linefollowerów w Polsce. Rozwijamy go razem z Pojemnikiem od ponad roku, w czasie wolnym między "przygotowaniami" do matury i jesteśmy zadowoleni z osiągniętych efektów. Historia powstania: Po zajęciu kolejnego czwartego miejsca RoChNem 3 uznaliśmy, że osiągnął on już szczyt swoich możliwości i trzeba zbudować coś nowego, aby wreszcie wskoczyć na podium. Początkowa “lista życzeń” wyglądała następująco: STM32 enkodery IMU Chcieliśmy też lepiej zaprojektować sekcję zasilania, żeby uniknąć losowych resetów procesora które zdarzały się poprzednikowi. W ciągu kilku tygodni stworzyliśmy projekt mocno inspirowany Fuzzym. Już wysyłaliśmy zamówienie, gdy odkryliśmy w projekcie poważny błąd. Jego naprawienie wymagałoby zaprojektowania całej płytki od nowa, więc schemat poszedł do kosza. W tym samym czasie na forum pojawił się opis Cukiereczka, który okazał się kopalnią wiedzy o linefollowerach. Uznaliśmy wtedy, że trzeba się inspirować najlepszymi i od tego czasu pomysł na RoChNa 4 był już inny. Postanowiliśmy w jednym robocie zamontować możliwie dużo “wodotrysków” i sprawdzić, które z nich dają tak dużą przewagę podczas zawodów. Dla upamiętnienia niedokończonego poprzednika oficjalny numer umieszczony na płytce ukończonego robota to 4.1. Jako, że jest to konstrukcja eksperymentalna, postawiliśmy na modułowość. Sterowniki silników, enkodery i moduł bluetooth umieszczone zostały na dodatkowych płytkach przylutowanych w pionie do głównego PCB. Dzięki temu rozwiązaniu byliśmy w stanie wygodnie wymieniać i przeprojektowywać peryferia, co bardzo się przydało podczas usuwania błędów konstrukcyjnych. MECHANIKA Kolory: Jak wiadomo ładne roboty szybciej jeżdżą[potrzebny przypis]. Dlatego od początku planowaliśmy jak będzie wyglądał nasz linefollower. Postanowiliśmy wzorować się na bolidach Formuły 1, w końcu są one dosyć szybkie. Mieliśmy już zamówione pionowe płytki w zielonym kolorze, więc ilość bolidów zawęziła się do malowania Force India z 2011 roku. Zdjęcie Cukiereczka jako robota, na którym się wzorowaliśmy, przemalowaliśmy w Paint-cie, żeby zobaczyć, jak będzie wyglądać. Na (nie)szczęście zielone płytki okazały się grubości 2mm, co dyskwalifikowało je z wykorzystania w robocie, więc mając wolny wybór zdecydowaliśmy się na żółto-czarną kolorystykę Renault. Ostatecznie jesteśmy całkiem zadowoleni z tego jak prezentuje się nasz robot. Podwozie: Robot składa się z dwóch płytek PCB połączonych taśmą FFC (raster 0,5mm, 24 piny) oraz dwiema listewkami. Próbowaliśmy je zrobić z włókna węglowego, ale okazało się, że nie umiemy wywiercić w nim otworów domowymi sposobami. Zamówiliśmy też listewki plastikowe, ale były tak miękkie, że na zakręcie przednia płytka mogłaby uderzać o tylną. Gdybyśmy kupili je z twardszego materiału, może zaoszczędzilibyśmy kilka gram na masie robota, ale aktualnie jesteśmy zadowoleni z aluminiowych. Z tyłu nie mogło zabraknąć listewki ochraniającej robota przed obróceniem podczas ruszania. Całkowita masa wynosi 62 gramy (73 z akumulatorem). Taśma FFC poza obsługą 14 czujników koloru i 3 żył z zasilaniem, posiada 7 żył, na których zależnie od użytych czujników odległości można wyprowadzić 2xI2C, SPI, jeden pin ADC, lub po prostu użyć ich jako GPIO. Napęd: Dwa standardowe silniki Pololu 10:1 z obustronnym wałem i węglowymi szczotkami jak zawsze spisują się bardzo dobrze, choć słychać już powoli ich zużycie (to już drugi komplet). Powoli osiągamy koniec ich możliwości, więc kolejna konstrukcja będzie pewnie używać czegoś innego. Zastosowaliśmy przedłużone mocowania, aby szerokość płytki nie przekraczała 10 cm i zamontowaliśmy od dołu zaślepki osłaniające przekładnie przed kurzem, który czasem w nie wpadał. Koła i opony: Początkowo robot jeździł na felgach toczonych w aluminium. Teraz ma dwa razy lżejsze wydrukowane na drukarce 3D, ale za to lekko bijące (musieliśmy rozwiercić otwór na wał, co nie wyszło idealnie). Kiedyś próbowaliśmy odlewania oponek z silikonu - miały podobną przyczepność, ale zużywały się dużo szybciej od Mini-Z, więc używamy tych drugich. ELEKTRONIKA PCB: Zdecydowaliśmy się na czterowarstwową płytkę, bo już podczas projektowania poprzedniego linefollowera mieliśmy problemy z optymalnym doprowadzeniem zasilania. Na głównej płytce jedna warstwa to wyłącznie masa, jedna zajmuje się zasilaniem, a dwie zewnętrzne wszystkimi sygnałami. Przednia płytka z czujnikami również jest czterowarstwowa, tam sygnały schowaliśmy do środka, aby zmniejszyć szumy na sygnałach analogowych. Mniejsze, żółte płytki są dwuwarstwowe. Zdecydowaliśmy się na elementy pasywne w obudowach 0402 - najmniejszych, które można wygodnie ręcznie polutować. W poprzedniej konstrukcji elementy w 0805 zajmowały dużo miejsca dlatego wybraliśmy mniejszy standard. Mikrokontroler: Pierwsza, porzucona wersja RoChNa 4 wykorzystywała STM32F1. Ostatecznie po przeanalizowaniu opisu Cukiereczka zdecydowaliśmy się na serię F7. W robocie zastosowaliśmy STM32F745VET6 w obudowie LQFP-100. Stu-pinowa obudowa okazała się niezbędna przy tylu elementach zastosowanych w robocie - tylko 5 pinów pozostało wolnych. Układ taktowany jest rezonatorem kwarcowym 8MHz, którego sygnał umożliwia stabilną pracę procesora na 216 MHz. Do programowania korzystamy z interfejsu SWD i odłamanego programatora ST-LINK z płytki Nucleo. Nie planowaliśmy programowania przez USB, choć gdyby udało się je uruchomić, to prawdopodobnie byśmy spróbowali. Zapas mocy obliczeniowej okazał się bardzo przydatny przy testowaniu najdziwniejszych rozwiązań. Czujniki linii: Użyliśmy standardowych elementów KTIR0711S. Rozmieszczone są w dość wąski (8,5 cm szerokości) łuk. Ponieważ nasz STM miał 16 pinów z ADC, a chcieliśmy także mierzyć stan baterii i mieć możliwość zamontowania analogowego czujnika odległości do wykrywania przeszkód, zdecydowaliśmy się na 14 sztuk. Odpowiedni dystans od podłoża zapewniają cztery rezystory w obudowach ¼ watta. Sterowniki silników: Po rozmowach z autorem Cukiereczka doszliśmy do wniosku, że sterowniki TB6612 mogą nie wytrzymać nagłych szarpnięć silnikami, więc wybraliśmy mostek H VNH7013 (40A prądu stałego) oraz układ DRV8703 sterujący takim mostkiem. Zestaw mógł sterować tylko jednym silnikiem, więc musieliśmy zamontować takie dwa w robocie. Jednak intuicja podpowiedziała nam, że coś może nie zadziałać, więc zamontowaliśmy je na osobnych, żółtych, pionowych płytkach, abyśmy mogli ewentualnie wymienić je na TB6612. Podczas testów udało nam się raz zakręcić silnikiem i dwa razy spalić mostek, więc ostatecznie robot jeździ na 4 starych sterownikach. Daje to 4,8A ciągłego poboru prądu przez silnik (12,8 w piku (♠)). Nie stosujemy żadnych opóźnień w celu oszczędzania tych układów i nie zostały one jeszcze uszkodzone (a przeżyły już wiele dziwnych manewrów), więc rozwiązanie choć mało profesjonalne okazało się skuteczne. Enkodery: Wybraliśmy enkodery magnetyczne AS5134 z uwagi na dużą szybkość kolejnych odczytów położenia magnesu, możliwość komunikacji po SPI do 6MHz i łatwą dostępność. Początkowo błędnie zasilaliśmy je napięciem 3,3V (układ potrzebuje co najmniej 4,5V), więc musieliśmy przeprojektować ich płytki (tu znowu pomogła nam modułowość projektu). Na prawej płytce umieściliśmy jedyny w robocie stabilizator na 5V i przewodem doprowadziliśmy zasilanie do lewej. Napięcia sygnałów z enkodera do STM-a (5V->3,3V) są dzielone dwoma rezystorami, a w drugą stronę (3,3V->5V) wzmacniane układem MOSFET-a i dwóch rezystorów. Chcieliśmy zastosować 6-biegunowe magnesy firmy Pololu, jednak enkoder zadziałał dopiero gdy użyliśmy pierścieniowe magnesy neodymowe namagnesowane po średnicy. Ustawienie magnesu i czujnika Halla w idealnej osi znacznie zwiększyło dokładność odczytów. Pomiary wykonujemy z częstotliwością 2 kHz. Zmiana kąta między odczytami wynosi zwykle 20-80 stopni, więc niedokładność pomiarów ±2 stopnie nie wpływa za bardzo na stabilność algorytmu sterującego silnikami. Bluetooth: Tu bez żadnych szaleństw. HC-05 spełnia swoją funkcję zadowalająco. Rozglądaliśmy się za czymś innym, ale nie znaleźliśmy rozsądnej alternatywy. Brakowało nam miejsca na głównej płytce robota, dlatego został on umieszczony na osobnej pionowej. Planowaliśmy wpinanie go na złączach goldpin, aby była możliwość wyjmowania go na przejazdy finałowe (mniejsza masa itd). Mieliśmy problemy z tym złączem. Wstrząsy podczas jazdy powodowały krótkie utraty zasilania podczas jazdy, co skutkowało zerwaniem połączenia i uniemożliwiało zatrzymania robota. Przylutowanie dwóch przewodów rozwiązało problem. Zasilanie: Dalej stosujemy akumulatory li-po Dualsky 2S, 150-250 mAh, te same co w Rochnie 3. Montujemy je do robota na rzep i przytrzymujemy kawałkiem drutu, aby się nie kołysały na boki. Mamy 7 akumulatorów oraz jedną ładowarkę na dwa linefollowery, więc podczas zawodów ledwo nadążamy z ich ładowaniem. Robot pożera naprawdę dużo prądu, dlatego wiele układów usypiamy lub odłączamy od zasilania (usypiając stabilizatory) kiedy robot akurat nie jedzie (patrz tabelka, nie uwzględniono prądu pobieranego przez silniki). IMU: Czujnik przestrzeni miał docelowo pomagać w zapamiętywaniu trasy i niwelowaniu poślizgu podczas pokonywaniu zakrętów. Użyliśmy układu LSM6DSM i przylutowaliśmy go bezpośrednio do głównej płytki. Pomimo tego, że podczas testów statycznych układ działa bez zarzutu (1g pojawia się w odpowiednim kierunku), to podczas jazdy wyłapywane są wszystkie wstrząsy i drgania, co uniemożliwia wykorzystanie danych w jakimkolwiek celu nawet po przefiltrowaniu. Czyszczenie kółek podczas jazdy: Przetestowaliśmy system umożliwiający czyszczenie kółek w trakcie przejazdu w celu minimalizacji wpływu przyklejającego się brudu. Rolkę do zbierania kurzu przymocowaliśmy do stelarzu wydrukowanego na drukarce 3D. System działał, ale stawiał bardzo duży opór, co znacząco zmniejszało osiągi robota, utrudniając nawet ruszenie z miejsca. Niewykorzystane bajery: Karta SD - Docelowo miała być użyta jako magazyn danych na temat trasy oraz aktualnej konfiguracji robota. Niestety nie udało nam się jej uruchomić poza odczytaniem informacji o danej karcie. Ostatecznie jako magazyn danych użyta została część niewykorzystanej pamięci FLASH. USB - Miało służyć do szybkiego wymieniania dużych ilości informacji pomiędzy robotem, a komputerem. Z nieznanych nam przyczyn nie udało nam się skłonić go do działania. Dane z robota wysyłamy albo przez Bluetooth albo zczytujemy całą pamięć FLASH programatorem. EEPROM - Został dodany na osobnej płytce, aby łatwiej zapisywać dane konfiguracyjne. Okazał się jednak nie być niezbędny, i zapisujemy te dane na kilku ostatnich bajtach pamięci. SOFTWARE Program został napisany w C z użyciem bibliotek HAL. Nigdy nie robiliśmy żadnego większego projektu na STM32, więc trzeba było nauczyć się wielu rzeczy. Algorytm podążania za linią składa się z głównego regulatora, który na podstawie odczytów z czujników linii zadaje prędkość obrotową dwóm regulatorom PD, które sterują prędkością kół. Dużą część programu zajmuje kod obsługujący komunikację przez bluetooth. Praktycznie wszystkie istotne zmienne można zmieniać zdalnie, istnieje także możliwość podglądu odczytów z czujników linii i innych danych w czasie rzeczywistym. Robot zapamiętuje cześć swojej konfiguracji w pamięci FLASH. Na potrzeby kalibracji i sprawdzania różnych rzeczy powstało kilka mniejszych programów na komputer. Głównie generują wykresy na podstawie danych z robota. Zapamiętywanie trasy: Od początku planowaliśmy zapamiętywać trasę przejazdu. Po kilku tygodniach prób i błędów udało się zrobić program, który działał na krótkich trasach. Niestety na długich się gubił. Uznaliśmy, że bez doświadczenia, wiedzy teoretycznej i pewnie dokładniejszych czujników nie będziemy w stanie zrobić lepszego algorytmu. Poniżej screenshot z programu wizualizującego zapamiętaną trasę. Usprawnienia sterowania: Robot ma kilka różnych sposobów aktywacji dodatkowego hamowania na zakrętach aby z nich nie wypadać. Uwzględnia też podczas pokonywania trasy różnego rodzaju przypadki szczególne np. kąty ostre ("teoretycznie" niemożliwe) i skrzyżowania. Na każdych zawodach sprawdzamy, jaka kombinacja ustawień zadziała najlepiej, choć mamy kilka optymalnych ustawień. PODSUMOWANIE Robot w pełni spełnił swoje zadanie, czyli przetestowanie nowej rodziny procesorów, enkoderów, IMU i zapamiętywania trasy, a wyniki są lepsze niż się spodziewaliśmy. Niestety z powodu epidemii ilość zawodów, w których mógł wystartować została mocno ograniczona. Projekt dalej jest rozwijany i wdrażamy kolejne ciekawe rozwiązania, które opiszemy, jeżeli sprawdzą się na zawodach. Osiągnięcia: III miejsce Robocomp 2019 IV miejsce Sumo Challenge 2019 II miejsce Robotic Arena 2020 Filmy z zawodów:
- 5 odpowiedzi
-
- 17