Przeszukaj forum

Cześć wszystkim Zauważyłem że ostatnio nie pojawia się zbyt dużo nowych konstrukcji jeśli chodzi o linefollowery, dlatego chciałbym opisać swoją 😉 Nie jest to raczej nic odkrywczego – podobne projekty pojawiały się w przeszłości na tym forum, jednak mimo to podzielę się swoim i może zachęcę osoby które chciałby wykonać podobną konstrukcję i zacząć swoją przygodę z elektroniką, programowaniem bądź robotyką. Cały projekt udostępniłem publicznie na GitHubie, więc jeśli ktoś jest zainteresowany, zachęcam do zapoznania się z nim. Nie przedłużając, Linefollower Kwark jest moją drugą konstrukcją. Pierwszą, jakiś czas temu (sam nie pamiętam 6-7lat?) wykonałem jeszcze na 8bitowcu - Atmega32. Obecny projekt jest dosyć świeży, w zasadzie kilkanaście dni temu robot zaczął poruszać się po linii. Pracę nad nim zacząłem końcem sierpnia tego roku i wszystko znajduję się w fazie testów. Linefollower jeszcze nie brał udziału w żadnych zawodach. Krótki filmik pokazowy, wraz z przejazdem udostępniłem na YouTubie. KONSTRUKCJA MECHANICZNA Podwozie Podwozie robota składa się z dwóch płytek PCB połączonych za pomocą dwóch wąskich listew węglowych oraz taśmy FFC. Na końcu głównej płytki zamontowana jest metalowa blaszka, wygięta w sposób zapobiegający podnoszeniu się robota podczas gwałtownego przyspieszania. Jako ślizgacze zastosowałem materiał przypominający filc, choć nie jest to rozwiązanie idealne, materiał odkleja się podczas jazdy oraz wprowadza dodatkowy opór. Planuję zastąpić go czymś twardszym, np. przymocować lub wlutować rezystory THT. Akumulator litowo-polimerowy 2S 7.4V (o pojemnościach od 120 mAh do 220 mAh) montowany jest do płytki PCB za pomocą gumek recepturek - nie miałem jeszcze problemów z takim rozwiązaniem. Najczęściej używam akumulatora 220 mAh podczas testów, a pozostałe akumulatory służą głównie jako zapas podczas ładowania. Do tej pory nie sprawdziłem, czy masa akumulatora wpływa na czas przejazdu robota, nie chciałem zajmować się tym na obecnym etapie projektu. Napęd Napęd robota stanowią dwa szczotkowe silniki HPCB 10:1 z obustronnym wałem, do montażu wykorzystałem mocowania Pololu wydrukowane na drukarce 3d. Do wałów silników zamontowałem magnesy neodymowe (⌀6 mm, wysokość 2,5 mm), namagnesowane wzdłuż średnicy. Zostały one przymocowane za pomocą uchwytów również wydrukowanych na drukarce 3D. Koła wykonano z poliamidu, a opony pochodzą z modelu Mini-Z. Opony są jednak mocno zużyte (pozostałość po wcześniejszej konstrukcji), co negatywnie wpływa na trzymanie trasy. Planuję zakup nowych opon, prawdopodobnie również z modelu Mini-Z. ELEKTRONIKA Komponenty Poniżej załączam ogólny schemat blokowy, opisujący sposób komunikacji poszczególnych elementów robota: Mikrokontroler STM32F722 Wybrałem mikrokontroler STM32 oparty na rdzeniu ARM Cortex M7, taktowany zegarem 216 MHz. Jest wystarczająco wydajny, aby obsługiwać wszystkie obliczenia w rozsądnym czasie. W wyborze procesora nie ma się co ograniczać, projekt budujemy zazwyczaj w maksymalnie kilku sztukach więc cena nie gra tutaj roli. W przyszłości planuję zwiększyć częstotliwość wykonywanych pomiarów. Cortex-M7 umożliwia wykorzystanie pamięci cache oraz pamięci o niskiej latencji, ITCM i DTCM, co zapewnia spory zapas wydajności. 12 x Transoptory KTIR0711S Chyba najbardziej popularna i sprawdzona opcja. Czujniki są rozmieszczone w szeregu, tworząc delikatny łuk. Wyjścia podłączono bezpośrednio do przetwornika ADC mikrokontrolera. Każdemu czujnikowi odpowiada przypisana dioda LED. 2 x Enkodery AMS AS5040 Enkodery magnetyczne pozwalają na precyzyjne pomiary prędkości silników. Informacje te są wykorzystywane w algorytmie PID, zapewniając zamkniętą pętlę sterowania. Dokonują pomiaru kąta z rozdzielczością 10 bitową. Do pomiaru impulsów wykorzystałem wyjście kwadraturowe. 2 x Mostek H Pololu TB6612FNG Jeden mostek odpowiedzialny jest za sterowanie jednym silnikiem. Kanały mostka zostały scalone w celu zapewnienia większej wydajności prądowej. Zastosowałem je w poprzedniej konstrukcji i nie miałem z nimi problemu. Moduł Bluetooth JDY-31 Tutaj mógłby być w zasadzie każdy moduł, który komunikuje się za pomocą magistrali UART. Moduł JDY-31 miałem pod ręką, ale mógłby być również popularny HC-05. PCB Wszystkie płytki PCB zaprojektowałem w programie KiCad w wersji 8. Mogę polecić ten program początkującym – sam nie jestem ekspertem w projektowaniu PCB, a mimo to udało się stworzyć płytki w stosunkowo prosty sposób. Podczas projektowania popełniłem dwa błędy. Pierwszym było błędne przypisanie sygnału z enkodera do pinu mikrokontrolera, co udało się naprawić za pomocą wlutowanego kynara. Drugi błąd to nieprawidłowa kolejności pinów w złączu Bluetooth - sposób naprawy jest widoczny na zdjęciach wyżej 😄. PCB zamawiałem w JLCPCB i byłem zaskoczony szybkością realizacji oraz wysyłki do Polski. Główna płytka jest czterowarstwowa. Początkowo płytka z sensorami również była czterowarstwowa. Podczas sprawdzania cen różnica między płytkami dwu- i czterowarstwowymi wydawała się niewielka. Niestety, przy składaniu zamówienia okazało się, że dla płytek przekraczających 10 cm różnica w cenie jest większa. W rezultacie zdecydowałem się przerobić płytkę z sensorami na dwuwarstwową, natomiast główną płytkę pozostawiłem w wersji czterowarstwowej. Druga i trzecia warstwa głównej płytki stanowią masę, pierwsza to warstwa sygnałowa, a czwarta służy do sygnałów i zasilania. Jeśli chodzi o elementy pasywne, zdecydowałem się na rozmiar 0603 – są stosunkowo łatwe do lutowania i nie zajmują zbyt wiele miejsca na płytce. Sensory ułożone są w delikatny łuk, kształt płytki skopiowałem z poprzedniego robota. Dopełnieniem są dwie małe płytki, na których wlutowany jest sensor AMS AS5040. OPROGRAMOWANIE Kod na mikrokontroler został napisany w całości w języku C. Standardowo, do konfiguracji driverów użyłem programu STM32CubeMX. Do debuggowania kodu korzystałem z programu SEGGER Ozone. Oprócz standardowej aplikacji, przygotowałem projekt bootloadera oraz aplikację na PC, która została napisana w QT. Główny algorytm Sposób działania głównego kodu opiera się na sterowanej zdarzeniami maszynie stanów (ang. event driven state machine). Przetwarzanie zabranych danych oraz aktualizacja sygnału wyjściowego następuje w przypadku zakończenia konwersji ADC. Na ten moment jest to co 5ms. Oprócz standardowego algorytmu PID, dodałem między innymi wykrywanie kątów prostych, zwalnianie w przypadku niestabilności sensorów. Do zapisu danych kalibracyjnych wykorzystałem jedną stronę pamięci FLASH, wszystkie istotne parametry można modyfikować za pomocą aplikacji. Dane są zabezpieczone za pomocą CRC, a w przypadku błędnej sumy kontrolnej wczytywane są dane domyślne. Całość kodu starałem się ładnie podzielić na moduły, których opis jest dostępny tutaj. Bootloader Dzięki bootloaderowi nie musimy nawet podpinać programatora, gdy jest potrzeba aby coś szybko zaktualizować. Przesyłanie aplikacji następuje przez Bluetooth z wykorzystaniem mojego protokołu SCP. Do bootloadera możemy wejść dwiema metodami: 1. Poprzez wysłanie odpowiedniej komendy. 2. Poprzez backdoor tj. wysłanie odpowiedniej komendy podczas włączenia zasilania. Dzięki temu możemy zawsze zaktualizować oprogramowanie (możliwość wejścia do bootloadera, nawet jeżeli w aplikacji jest błąd przez który jednostka cały czas się resetuje). Organizację pamięci FLASH przedstawiłem na zdjęciu poniżej: Aplikacja QT (C++) Aplikacja dostarcza graficzny interfejs, umożliwiający sterowanie, konfigurację oraz monitorowanie linefollowera. Główne funkcjonalności to: Panel połączenia: Kontrola komunikacji przez Bluetooth. Panel sterowania: Funkcje uruchamiania, zatrzymywania, resetowania i kalibracji robota. Oraz opcje takie jak: włączenie trybu debugowania, odczyt/zapis NVM, wyświetlanie danych w czasie rzeczywistym. Panel sensorów: Aktualne wartości, wartości kalibracyjne oraz wagi przypisane do poszczególnych sensorów. Panel konfiguracji: Ustawienie pozostałych parametrów znajdujących się w pamięci nieulotnej mikrkontrolera. Wykresy prezentujące prędkości silników, błędy z sensorów. Bootloader: Obsługa aktualizacji oprogramowania. Logi PODSUMOWANIE Zbudowanie robota zajęło mi około 3 miesiące wykorzystując głównie wieczory po swojej pracy zawodowej. Aby zwiększyć docelową prędkość poruszania się linefollowera wciąż potrzebne jest jeszcze sporo testów i być może zmian w algorytmie. Mam nadzieję tylko że motywacji nie zabraknie 😄

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:

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: