Line follower Cukiereczek

[mice.co]

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:

 

Edytowano Marzec 11, 2019 przez mice.co
linki

[Treker (Damian Szymański)]

@mice.co, właśnie zaakceptowałem Twój opis, możesz go teraz zgłosić do akcji rabatowej umieszczając link w temacie zbiorczym.

Świetny projekt, szczere gratulacje! Po miniaturce myślałem, że to wspomniany już Fuzzy 😉 Cieszę się, że moja konstrukcja była inspiracją. Swojego robota opisywałem, gdy przechodziłem na moją "robotyczną emeryturę", cieszę się, że ktoś pociągnął dalej temat i to w takim stylu. Mam nadzieje, że inni skorzystają również na Twoim opisie i temat ruszy do przodu. Może Twój przykład zachęci też innych zawodników do opisywania swoich konstrukcji.

Ode mnie trzy pytania:

1. Płytka wielowarstwowa, bo miałeś taką możliwość, czy faktycznie była już niezbędna przy tym projekcie?
2. Jak oceniasz teraz wykorzystanie żyroskopu? Dużo pomógł, czy tylko przysporzył więcej problemów?
3. Robiłeś próby z mapowaniem trasy?

Jeszcze raz dzięki za świetny opis!

[Alvedro]

Bardzo fajna konstrukcja. Kilka pytań:
1. Dlaczego przełożenie w silniku 10:1, odcinki proste często są krótkie, więc chyba rzadko jesteś w stanie rozpędzić go do maksymalnej prędkości, nie lepiej mieć większe przyspieszenie kosztem niższej maksymalnej prędkości?
2. I2C nie lubi za bardzo zmiennego pola magnetycznego, możliwe, że to powodowało problemy z VL53L1X. Jak przez BLDC przepuszczałem sygnały I2C to przewody zasilające silnik przepuszczałem kilkukrotnie przez koralik ferrytowy. 🙂
3. Gdzie dorwałeś enkodery AS5047P? 😛 Ostatnio miałem problem, żeby dostać coś z enkoderów mangetycznych od AMS.
4. Jak omijasz przeszkodę? Na sztywno, metodą prób i błędów w przypadku niepowodzenia, czy coś bardziej zaawansowanego?
5. Wykorzystujesz zapamiętaną trasę? Co dokładnie zapisujesz? Obliczasz np. maksymalne prędkości, które pozwolą nie pokonanie zakrętu bez uślizgu itp.?
6. Myślałeś o czujniku optycznym z myszki? Może to zniwelować ewentualne poślizgi kół, tylko pytanie czy aż taka dokładność jest potrzebna.
7. Dlaczego nie ułożyłeś KTIR'ów jeszcze bliżej, tak by stykały się nawet obudowami obracając je o 90 stopni.

[Sabre]

8 godzin temu, Alvedro napisał:

7. Dlaczego nie ułożyłeś KTIR'ów jeszcze bliżej, tak by stykały się nawet obudowami obracając je o 90 stopni.

Osobiście nie rozumiem sensu tego pytania. KTIRy mają to do siebie, że ułożone katalogowe 2mm od powierzchni toru (do powierzchni czujnika), widzą trochę szerzej niż ich pole powierzchni. I te trochę to wcale nie jest takie trochę, stożek  podczerwieni ma 4mm drogi w tą i z powrotem. Po co więc ustawiać KTIRy tak, aby dotykały się obudowami?

Mateusz, jeszcze raz gratuluję Ci wygranej i dziękuję za opisanie Cukiereczka.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[mice.co]

Dzięki za pozytywny odzew!

10 godzin temu, Treker napisał:

Ode mnie trzy pytania:

1. Płytka wielowarstwowa, bo miałeś taką możliwość, czy faktycznie była już niezbędna przy tym projekcie?
2. Jak oceniasz teraz wykorzystanie żyroskopu? Dużo pomógł, czy tylko przysporzył więcej problemów?
3. Robiłeś próby z mapowaniem trasy?

Ad. 1. 4-warstwowa płytka ma swoje zalety. Możliwe, że dla płytki z czujnikami była troszkę przesadą, ale miałem wizję schować sygnały analogowe pomiędzy ekran (pomijając tasiemkę).
Przede wszystkim znacznie wygodniej projektuje się taką płytkę, nie musiałem się martwić o nieoptymalnie poprowadzone zasilanie - w tym przypadku zasilania umieściłem na wewnętrznych warstwach i zadbałem, aby zbiegały się w odpowiednich miejscach. Obecnie zasilanie jest "czyściutkie" przy zastosowaniu po jednym 33uF na silnik. Przy 4 warstwach możliwe jest również pilnowanie impedancji dla sygnałów różnicowych USB, choć często przy takich długościach jak u mnie, można to olać. Na koniec wydaje mi się, że bez 4 warstw mógłbym nie zmieścić się w takich wymiarach pcb.

Ad. 2. Miałem większy plan z tym  żyroskopem, jednak zdziwiony, że robot idealnie śmiga po linii bez niego, używam go w trakcie jazdy tylko do omijania przeszkód. Zabrakło czasu na dalszy rozwój. Był zamiar eliminowania wpływu poślizgu na zakrętach, a nawet oparcie całego poruszania robota na danych z odometrii i zastąpienie pełnego regulatora PD linii, jedynie członem proporcjonalnym.
Dorzucam wykres, jak wygląda trasa wg. robota przy bezpośredniej zamianie kąta z enkoderów na kąt z żyroskopu.

Ad. 3. Większość prób z mapowaniem wykonałem na logach w Matlabie. Wyszacowałem dość spory zysk z mapowania dla tras z dużą ilością prostych odcinków. Przygotowałem prosty algorytm, który nadawałby się do przejazdu z jedynie 1 przejazdem mapującym i faktycznie zdawało to egzamin w warunkach domowych, na małej trasie. Znowu, zabrakło czasu doimplementować interfejs, który wymagałby kilku przeróbek w programie i zmian w aplikacji na smartfon i cały czas odsuwam wykorzystanie mapowania na zawodach. Po każdym przejeździe zostają mi "suche" informacje na temat trasy o długości, zakrętach i odcinkach prostych. Być może na kolejnych ostatnich zawodach... 😆

8 godzin temu, Alvedro napisał:

Bardzo fajna konstrukcja. Kilka pytań:
1. Dlaczego przełożenie w silniku 10:1, odcinki proste często są krótkie, więc chyba rzadko jesteś w stanie rozpędzić go do maksymalnej prędkości, nie lepiej mieć większe przyspieszenie kosztem niższej maksymalnej prędkości?
2. I2C nie lubi za bardzo zmiennego pola magnetycznego, możliwe, że to powodowało problemy z VL53L1X. Jak przez BLDC przepuszczałem sygnały I2C to przewody zasilające silnik przepuszczałem kilkukrotnie przez koralik ferrytowy. 🙂
3. Gdzie dorwałeś enkodery AS5047P? 😛 Ostatnio miałem problem, żeby dostać coś z enkoderów mangetycznych od AMS.
4. Jak omijasz przeszkodę? Na sztywno, metodą prób i błędów w przypadku niepowodzenia, czy coś bardziej zaawansowanego?
5. Wykorzystujesz zapamiętaną trasę? Co dokładnie zapisujesz? Obliczasz np. maksymalne prędkości, które pozwolą nie pokonanie zakrętu bez uślizgu itp.?
6. Myślałeś o czujniku optycznym z myszki? Może to zniwelować ewentualne poślizgi kół, tylko pytanie czy aż taka dokładność jest potrzebna.
7. Dlaczego nie ułożyłeś KTIR'ów jeszcze bliżej, tak by stykały się nawet obudowami obracając je o 90 stopni.

Ad. 1. Przekładnię w Pololu uważam za idealnie dobraną, kolejna z szeregu - 30:1 nie pozwoli na uzyskanie wymaganej prędkości przy li-po 2S. Bardziej poszedłbym w zmniejszenie średnicy kół z ~25 do 20mm. Dodatkowy moment obrotowy i tak pójdzie w poślizg. Nawet teraz przy ruszaniu z miejsca 0-2.5m/s słychać pisk opon (przy idealnie wyczyszczonych kołach). Kolejny poślizg widać już od pierwszego zakrętu. Przy takiej masie konstrukcji bez turbiny, momentu nie brakuje.

Ad. 2. Nie tylko I2C ma problemy z zakłóceniami. Jak widać ze zdjęć, próbowałem skręcania przewodów, nic nie dawało również zmniejszanie prędkości z 400kHz do 100kHz. Przestałem grzebać przy i2c, gdy zorientowałem się, że sam czujnik po wysypce wymaga odłączenia zasilania, nie odpowiada na dalszą komunikację. Co drugi przejazd czujnik działa bez zarzutu i tak zostało.

Ad. 3. Enkodery zamówiłem chyba w 2016 roku, gdy pojawił się pierwszy pomysł na nowego robota. Czekały w pudełku na tę konstrukcję 🙃. Również stwierdzam, że obecnie ciężko je zdobyć i wymagają zakupów np. z mousera, z magnesami pewnie jeszcze gorzej.

Ad. 4. Przeszkodę omijam łukiem złożonym z dwóch sinusoid. Parametry łuku dobieram przed przejazdem i takie podejście również wymaga prób i błędów aby dograć parametry pod warunki na torze.

Ad. 5. Do tej pory nie wykonałem na zawodach żadnego przejazdu odtwarzanego z mapy. Obecnie próbowałem najprostszego podejścia z nałożeniem maksymalnej prędkości jedynie na odcinki proste, tak aby nie wystąpił poślizg.

Ad. 6. Czujnik z myszy musiałby mieć wysoką prędkość maksymalną (z 5m/s) i sprawdzić sie w warunkach drgań, nierówności, podskoków itd. Swego czasu poddałem się z takim czujnikiem, przy próbie kupna, nawet uszkodzonej myszki.

Ad. 7. Chciałem zostać przy ułożeniu pary nadajnik-odbiornik w pionowej linii i mieć pewność, gdzie znajduje się środek czujnika. Dodatkowo ustawiłem sobie limit 12 czujników i dalsze zmniejszanie odstępów mogłoby sprawić, że robotowi zabraknie pola widzenia.

Edytowano Marzec 11, 2019 przez mice.co
ozdyw->odzew

[Sabre]

Jeden z finałowych przejazdów Cukiereczka na Robomaticonie. Przepraszam za jakość, ale przy takim oświetleniu w sali (zasłonięte zasłony) to mój smartfon zbyt ładnie na nagra.

 

[Treker (Damian Szymański)]

6 godzin temu, mice.co napisał:

Ad. 3. Większość prób z mapowaniem wykonałem na logach w Matlabie. Wyszacowałem dość spory zysk z mapowania dla tras z dużą ilością prostych odcinków. Przygotowałem prosty algorytm, który nadawałby się do przejazdu z jedynie 1 przejazdem mapującym i faktycznie zdawało to egzamin w warunkach domowych, na małej trasie. Znowu, zabrakło czasu doimplementować interfejs, który wymagałby kilku przeróbek w programie i zmian w aplikacji na smartfon i cały czas odsuwam wykorzystanie mapowania na zawodach. Po każdym przejeździe zostają mi "suche" informacje na temat trasy o długości, zakrętach i odcinkach prostych. Być może na kolejnych ostatnich zawodach... 😆

Kibicuję, aby się udało. Byłem na podobnym etapie, czyli testowanie w domu, a później przestałem startować w zawodach. Moje testy 6 lat temu wyglądały tak (przejazd mapujący + przejazd z przyspieszaniem na prostej):

Jeśli chodzi o czujniki linii to miałem w planach jeszcze testy czegoś innego. Nie pamiętam już dokładnie symboli, ale chyba były to poniższe symbole

• https://www.digikey.pl/product-detail/en/sharp-socle-technology/GP2S60B/1855-1048-1-ND/1642454
• https://www.digikey.pl/product-detail/en/sharp-socle-technology/GP2S700HCP/1855-1020-1-ND/696159

[Mr_Wind]

Konstrukcja robi ogromne wrażenie, gratulacje! Mam pytanie dlaczego zdecydowałeś się na trzy oddzielne układy LDO 3.3V?

[mice.co]

2 godziny temu, Mr_Wind napisał:

Konstrukcja robi ogromne wrażenie, gratulacje! Mam pytanie dlaczego zdecydowałeś się na trzy oddzielne układy LDO 3.3V?

Osobno wydzieliłem zasilanie części analogowej pod czujniki linii - ma wpływ na dokładność pomiarów adc. Podobnie z imu. Część cyfrową projektu mam bardzo rozbudowaną i na pewno pojawia się sporo zakłóceń. Izolacja zasilań częściowo eliminuje wpływ tych zakłóceń.

Pod STM32 użyłem ldo spełniające kryterium zużycia prądu, układ 500mA. Pod analog oraz imu kryterium był poziom szumów i tłumienie zakłóceń. Czynnikiem była również przetwornica 5V, która pulsuje - ldo z wyższym pssr lepiej tłumi takie pulsacje (o ile przy 2MHz przetwornicy da się to zauważyć, każde może tłumic praktycznie tak samo)

[Pojemnik]

Robot jest niesamowicie szybki, robi duże wrażenie na żywo. Zdarzyło mi się oglądać go już kilka razy, zawsze z nadzieją, że uda się go dogonić, do czego jednak nigdy nie doszło😅

Również mam kilka pytań dotyczących konstrukcji:

• Piszesz, że mostki TB6612 wymagają dodatkowych opóźnień. Szczerze mówiąc nigdy nie musiałem stosować takich rozwiązań, nie widziałem również szczególnego narzekania na to na forum. Problemy z ich stosowaniem zaczynają się przy dużych prędkościach i bardzo nagłych zmianach PWM?
• Co do zastosowanego bluetootha czy to jest ten element U5 nie wlutowany w płytkę na drugim zdjęciu? A jeśli tak, to co to za układ? Jest lepszy od HC-05 w czymś poza bardziej kompaktowymi rozmiarami?

[mice.co]

13 godzin temu, Pojemnik napisał:

• Piszesz, że mostki TB6612 wymagają dodatkowych opóźnień. Szczerze mówiąc nigdy nie musiałem stosować takich rozwiązań, nie widziałem również szczególnego narzekania na to na forum. Problemy z ich stosowaniem zaczynają się przy dużych prędkościach i bardzo nagłych zmianach PWM?
• Co do zastosowanego bluetootha czy to jest ten element U5 nie wlutowany w płytkę na drugim zdjęciu? A jeśli tak, to co to za układ? Jest lepszy od HC-05 w czymś poza bardziej kompaktowymi rozmiarami?

 

1. W poprzedniej konstrukcji postanowiłem w pewnym momencie umożliwić robotowi zmianę kierunku obrotu kół w trakcie jazdy - bez żadnych dodatkowych modyfikacji. Mostek spalił się w pierwszym przejeździe. Jakiś czas później wróciłem do tematu z podwójnym mostkiem i dodatkowym opóźnieniem - nie spalił się do dnia dzisiejszego, a zmiana poprawiła pokonywanie zakrętów prostych.
Wiadomo, że wchodzi tu wiele czynników, w tym prawdopodobnie nieoptymalne sterowanie tym silnikiem, możliwe oscylacje regulatora itd. Ale chodziło głównie o to, że miałem potrzebę móc zrobić z silnikiem dowolnie wszystko, bez późniejszego awaryjnego lutowania w stresie, na zawodach. W tym momencie, jeżeli silnik potrzebuje do zmiany prędkości, z 3m/s do 0m/s, zmiany PWMa z +70% na - 80%, by za chwilę zadać +50%, a całość wykonuje się z częstotliwością 8kHz, to ja nie muszę się tym martwić i nakładać ograniczenia. Liczę się z tym, że silnik ulegnie znacznie szybszemu zużyciu.
Mostek TB6612 odpadał z miejsca, gdyż moim zdaniem jest mocno przestarzały. DRV8837 odpadł ze względu na ograniczone napięcia zasilania do 11V. Postawiłem na przesadzony mostek ze względu na brak czasu na testy potrzebne by dobrać  bardziej optymalny. Tranzystory w obudowach 5x6mm widuje się w mostkach +300W. 😅 Chyba uznałem, że łatwiej takie lutować niż 3x3mm.

2. Puste miejsce bierze się stąd, że miałem problem z dostawą modułu z aliexpress. Około 6 miesięcy czekałem aż przyjdzie, no i oczywiście nie przyszedł - dostałem zwrot. Dlatego robot debiutował z modułem HC-05 na kabelkach i właściwy moduł wstawiłem dopiero później. Jest to moduł, który podpatrzyłem u konstruktora GreenYe (micromouseusa.com), w jego micromousie Green Giant 5.19V - HJ580. Do tej pory nie wiem w jaki sposób zastosował ten moduł, gdyż ja musiałem programować układ DA14580 i męczyć się z custom'ową aplikacją pod nietypowy protokół bt. Typowy Bluetooth Low Energy. Gdy zapytałem GreenYe mail'owo o ten moduł, odpisał że swojego modułu nie musiał programować i używał go jako port COM, przez zwykły terminal. 🙄

Z zalet: baaardzo niewielkie rozmiary, znacznie szybszy od HC-05, pobiera niewiele prądu.
Wady: Krótki zasięg < 10m z obecną anteną, wymagał programowania OTP,  trudna dostępność, brak dokumentacji i footprintu modułu, wymaga znajomości BLE.

Rozważałem jeszcze wykorzystanie modułu SPBTLE-1S od STMicroelectronics. Jest również niewielkich rozmiarów i teraz posiada dość spore wsparcie, ze sporą ilością przykładów do wykorzystania oraz gotowe biblioteki.

[jaceksz73]

Wiem, że wątek jest stary, ale nadal wiele osób inspiruje. Podałeś schemat i wiele wskazówek. Dziękuję.

Do czego wykorzystujesz napięcie 5V?

Czy jeden stabilizator 3V3 jest wystarczający pod względem zakłóceń? Niektórzy rozdzielają na zasilanie MCU i ADC.

[mice.co]

9 godzin temu, jaceksz73 napisał:

Wiem, że wątek jest stary, ale nadal wiele osób inspiruje. Podałeś schemat i wiele wskazówek. Dziękuję.

Do czego wykorzystujesz napięcie 5V?

Czy jeden stabilizator 3V3 jest wystarczający pod względem zakłóceń? Niektórzy rozdzielają na zasilanie MCU i ADC.

5V zasila LEDy RGB (WS2812B), LEDy IR w KTIR'ach (po 4 w szereg) oraz wyjście UART pod ewentualny moduł, np. radiowy. 5V jest też źródłem dla stabilizatorów LDO.

Jeden stabilizator powinien wystarczyć:
- nawet nie troszcząc się szczególnie o zakłócenia, jeśli w danym zastosowaniu nie zależy nam na idealnych pomiarach ADC (do prostego LFa dużo nie trzeba, do japońskiego micromouse'a już tak).
- stosując izolację zasilań za pomocą filtrów LC (czyli np. 600Ohm'owy ferryt + 10uF|100nF z VDD  do VDDA przy procesorze) - zakłócenia części cyfrowych są wtedy częściowo tłumione
- tworząc dobry layout na PCB i nie wprowadzając zakłóceń.

Wiadomo, że każde oddzielne zasilanie wymaga dodatkowej uwagi i miejsca na PCB i czasem warunki sprawiają, że nie warto kombinować z oddzielnym zasilaniem, jeśli np. nie zapewnimy również oddzielnej masy.

[Treker (Damian Szymański)]

Dalszą dyskusją, która nie była związana z opisanym robotem wydzieliłem do nowego tematu:

 

[jaceksz73]

Na listwie z czujnikami KTIR widać na zdjęciu wlutowane elementy między nóżki 1 i 2 czujnika. Tych elementów jest 3. Po jednym na cztery czujniki. Wyglada to na opornik obniżający prąd na diodach. Ale . . . Podłączenie jest rownolegle (nóżki 1 i 2). Jaka stoi na tym idea? Czego nie zrozumiałem?

Druga sprawa. Diody tych czujników są zasilane 5v, natomiast wejścia ADC procesora pracują w zakresie 0-3,3v. 
Na zdjęciach widzę tyko pojedyncze rezystory na każde wyjście. Najprawdopodobniej są to rezystory podciągające. Jaki jest zatem zakres napięć na wyjściu z KTIRa?

Generalnie to projekt tej płytki z czujnikami bardzo mi się podoba. Chciałbym go zrozumieć.