Skocz do zawartości

mice.co

Użytkownicy
  • Zawartość

    28
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    2

mice.co zajął 1. miejsce w rankingu.
Data osiągnięcia: 15 lutego 2020.

Treści użytkownika mice.co zdobyły tego dnia najwięcej polubień!

2 obserwujących

Informacje

  • Płeć
    Mężczyzna

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

Osiągnięcia użytkownika mice.co

Entuzjasta

Entuzjasta (7/19)

  • Za 5 postów
  • Za 25 postów
  • Wschodząca gwiazda
  • Lokalna gwiazda
  • Młodszy roboty

Odznaki

45

Reputacja

  1. 1. Tak jest, korzystam tylko z SPI. Z tego co pamiętam, te enkodery miały 14-bit rozdzielczości po SPI, 12-bit przy ABI. 2. Prędkość wyznaczam dość standardowo - podobnie jak przy enkoderze inkrementalnym, z różnicy wartości kąta/licznika. Żeby nie było problemu z kierunkiem, rzutuję sobie wartość kąta i różnicy na inta ze znakiem tak, żeby przepełnienie "rozwiązywało się same": // (...) static int16_t old_angle; int16_t current_angle = enc_u14_angle << 2; int16_t diff = current_angle - old_angle; old_angle = current_angle; // (...) a odczytu z enkodera należy wykonywać odpowiednio często, tj. co najmniej raz na pół obrotu (aby w jednym cyklu nie przybyło więcej niż ½ rozdzielczości enkodera).
  2. W swoim robocie zastosowałem sposób a - symetrycznie dla obu kół. Prędkość mam rozłożoną na translacyjną i rotacyjną. Rotacyjna pochodzi z regulatora linii, a translacyjną dobieram nastawami i dodatkowo zmieniam (robot zmienia autonomicznie 😉 ) w trakcie np. prostej czy zakrętu. W takim wypadku, dopóki na "szybszym" kole prędkość nie próbuje przekroczyć wartości maksymalnej, lub nie występuje znaczna różnica w poślizgu na obu kołach, robot utrzymuje średnią prędkość (translacyjną) postępową. Wątpię, czy można określić najlepszą strategię, bo jeżeli ktoś posiada inne algorytmy, profilery prędkości, unika poślizgów, posiada cięższego robota lub inaczej ułożony środek ciężkości czy inną bezwładność, to na pewno jego doświadczenia będą inne. Całość też inaczej wygląda przy różnych prędkościach postępowych... Ja w swoich poczatkach zaczynałem od b), gdyż z a) miałem problemy ze strojeniem. Później przeszedłem do a) z ograniczeniami (brak zmiany kierunku obrotu kół) gdyż znacznie poprawiło to dynamikę robota w zakrętach. Dalej a) symetrycznie ze zmianą kierunku obrotu kół.
  3. Przetestowałem już wcześniej rozwiązanie bez rezystorów i takie tutaj zastosowałem. Może jest niepoprawne i powinien być rezystor 1-5R, ale nie miałem problemów z takim układem i w praktyce Vf oraz If diody wychodzą książkowo bez żadnego dobierania KTIR'ów. Niestety nie mam porównania z układem z rezystorami i nie zachęcam do powielania tego niepodręcznikowego rozwiązania, i jeśli ktoś próbuje minimalizować ilość elementów na PCB - nie gwarantuję, że zawsze zadziała 🙂
  4. Te elementy nie znajdują się nawet w projekcie PCB 😅, ale są to dodatkowe kondensatory do zasilania pierwszego czujnika w danym szeregu z diodami IR. Widocznie wpadłem na ten pomysł przy montażu (nie wynikał z żadnych kłopotów z działaniem listewki) i dokładnych pojemności nie potrafię sobie przypomnieć 🤔 W tym momencie wydają mi się zbędne i jak bym myślał o dodatkowej filtracji, to prędzej na linii 3.3V. Do płytki z czujnikami doprowadzone jest również dedykowane zasilanie analogowe 3.3V i tranzystor każdego czujnika podłączony jest przez rezystor do tej sekcji, więc sygnał wyjściowy będzie z zakresu 0-3.3V.
  5. Przejście do wbudowanego bootload'era odbywało się wyłącznie software'owo. W momencie uruchamiania całego programu sprawdzana jest pamięć w konkretnej komórce BKPSRAM i ewentualnie zerowana. Jeśli przed restartem uC było tam wpisane żądanie wejścia w bootloader, stos MSP ustawiam na 0x1FF0 0000 i przechodzę wskaźnikiem do *(0x1FF0 0000 + 4). Do programowania używałem programów zewnętrznych bazujących na dfu-util - po zaprogramowaniu uC jest restartowany. Debugowanie odbywało się w sposób uproszczony poprzez konsolkę - wyświetlając komunikaty, wartości zmiennych itd. Pełny, prawdziwy, debugger SWD był mi potrzebny w momencie problemów z hardfault'ami (głównie przez TCM-RAM, dcache i dma ...typowe początki z F7). Nie korzystałem, gdyż chciałem uniknąć dodatkowego złącza w robocie oraz operować sporą ilością kabli i płytką programatora - wystarczy zwykły przewód microUSB-USB. Jednocześnie po zaprogramowaniu, przez COM można natychmiast wysyłać statusy o poprawnych inicjalizacjach itd itp. Przez USB jest też możliwość zgrywania logów z karty uSD poprzez tryb MSC (nie trzeba wyciągać karty ze slotu, upychać w adapter i wpychać do czytnika komputerowego), ale nie zdążyłem tego zaimplementować 🙂
  6. 1. Ten STM to budżetowy H7. Bardzo szybki, jednak przy dzisiejszych bibliotekach 128KB Flasha może Ci nie wystarczyć. Zazwyczaj podłącza się pod niego zewnętrzny flash po QSPI. Jeśli nie planujesz stosowania skomplikowanej matematyki, to uznałbym ten procesor za niepotrzebne utrudnienie sobie życia 🙂 2. Czujniki OK. 3. Przy niedużych kołach robot może osiągać zbyt niską prędkość przy wersji 9V na baterii 2S. Jeszcze kwestia czy z turbiną czy bez. Dla LFa bez turbiny momentu obrotowego Ci nie zabraknie przy wersji 6V. (Ten parametr to napięcie nominalne i spokojnie mógłbyś taki silnik wysterować nawet z baterii 4S - ważne, żeby silnika nie przegrzać i nie "zedrzeć" szczotek). 4. Drivery powinny wystarczyć. Kojarzę jeszcze DRV8838, ale są jednokanałowe i pozwalają na odrobinę mniejszy pobór prądu niż zmostkowany DRV8833 😕 5, 6. Trzeba pamiętać, że cały spadek napięcia na LDO będzie skutkował wydzieleniem dość sporej ilości ciepła. Ogólnie OK, jeśli określisz dopilnujesz poboru prądu. 7. Z bateriami warto dzisiaj poszperać w kierunku mikro-dronów FPV. Mają coraz lepsze parametry i lepszą cenę/dostępność. Te nanotech'y wydają się trochę niedzisiejsze. Zasilanie silników zdecydowanie bezpośrednio z baterii poprzez sterownik (mostek H). A jeżeli chodzi o najlepsze części do LF, to powiedziałbym, że: - lekka konstrukcja o niewielkich bezwładnościach (koniecznie - znacznie przedłuża czas życia projektu, większe możliwości, większa sterowalność, można więcej wycisnąć) - bardzo przyczepne koła (koniecznie) - enkodery (zalecane, ale można sobie bez nich poradzić) - "ułatwiacze" (łączność, zdalny start, interfejsy - żeby obsługa robota, poprawki, strojenie były jak najwygodniejsze) - bezawaryjność i "prawidłowa" elektronika (żeby skupić się na programowaniu, nie na szukaniu błędów w schemacie podczas zawodów) - oprogramowanie To są moim zdaniem kluczowe czynniki , które warto brać pod uwagę, a na resztę nie ma jednoznacznego przepisu i nie sposób ich określić bez wcześniejszych prób i przekonania się na własnej skórze - wszystko jedno jaki symbol ma przetwornica czy dioda. Część z nich na pewno dyktuje dostępność i cena. Sam styl/metoda programowania (sterowania LFem) może sprawić, że istotniejsze będą dla Ciebie inne podzespoły niż u drugiego zawodnika. Dodatkowo, często trasa płata nam figle 🙂
  7. 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.
  8. Dziękuję za głosy na Cukiereczka oraz za przesłany zestaw gadżetów! 😍
  9. mice.co

    STM32 F042K6 kontrola PWM

    Z arduino silniki ruszają? Może kwestia błędu w schemacie. Standby jest podłączony do stanu wysokiego?
  10. mice.co

    STM32 F042K6 kontrola PWM

    Tak, zgadza się. Wyszedł Ci Period. Żeby maksymalnie uprościć, a jednocześnie nie wprowadzać zbyt dużej karykatury sprowadzając temat do "Arduinów"... Wzór FREQ = TIM_CLK/(ARR+1)(PSC+1)(CKD+1) na częstotliwość sygnału PWM jest dobry (dla standardowego trybu edge-alligned, który zapewne Cię interesuje). Zakładam, że ustaliłeś TIM_CLK na 48MHz. ARR, czyli Period będzie rozdzielczością sygnału PWM. PSC, czyli Prescaler pozwala przeskalować częstotliwość inkrementacji licznika (PSC=1 -> 48MHZ/2 = 24MHz). CKD pomijam. Dla 31250Hz dobrze Ci wyszło: 1536 ( 1535+1) - teraz zauważ, że 1535 mieści się w zakresie rejestru 16-bitowego. Więc PSC możesz spokojnie zostawić na 0, a wartość 1535 wpisać do rejestru ARR - uzyskasz w ten sposób maksymalną rozdzielczość sygnału PWM. Makrem _HAL_TIM_SET_COMPARE ustawiasz rejestr CCRx, czyli Pulse dla danego kanału (z zakresu 0 do ARR). CCRx/ARR będzie wypełnieniem sygnału PWM. Pamiętaj, że gdy ustawisz CCR na wartość większa niż ARR, wypełnienie będzie wynosić 100%. Skoro do tej pory nie udało Ci się rozwiązać problemu, zakładam, że technika mikroprocesorowa, czy bardziej co się dzieje w środku mikrokontrolera, Cię nie interesuje i rozumiem - nie wszystko na raz. Jeśli to Twoje początku radzę więcej grzebać, próbować, testować i szukać. Jest pełno poradników, kursów i na pewno, jeśli pojawia się problem, to ktoś już się z tym spotkał. Dla podobnych problemów forum ST może być dobrą alternatywą dla forbota 🙂 Jeśli chcesz popróbować z licznikami to warto pod sygnał PWM podłączyć diodę (z opornikiem oczywiście) i tak jak tutaj, wyliczyłeś ARR dla 31250Hz. Zmieniasz PSC z 0 na 31250-1 i patrzysz, czy dioda będzie zapalać się co 1 sekundę na długość ustawionego Pulse (_HAL_TIM_SET_COMPARE ). Łatwo wówczas wyłapać błędy, jeśli dioda zapala się co 0.5s, lub 2s, to znaczy, że np. TIM_CLK nie jest 48Mhz. 🙂
  11. 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.
  12. 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)
  13. Dziękuję za gratulacje. Liczę że ruszysz w temacie, bo odstawiłeś do szuflady na prawdę ciekawe pomysły i zdecydowanie brakuje świeżego podejścia w konkurencji 😀 Startując w konkurencji LF sam na początku musiałem chwilę poszukać odpowiedniej sali, ale było to ok. godz. 9. Później zauważyłem porozwieszane kartki kierujące zawodników/widzów we własciwe miejsce. Faktycznie z powodu przeniesienia konkurencji, odczułem mniejsze zainteresowanie konkurencją, ale z drugiej strony w poprzednich latach miałem problem poruszać się z salki technicznej na dół, a następnie przedzierać się przez tłumy widzów upchane pomiędzy barierkami - było ciasno. Samą konkurencję uważam za dobrze zorganizowaną. Wydaje mi się, że nie było opóźnień ze startem konkurencji i wszystko przebiegło dość gładko. Później ze względu na opóźnienia xsumo, finały lf i lf enhanced musiały troszkę zaczekać. Na duży plus zasługuje fakt, że trasy względem poprzednich lat zostały ~dwukrotnie powiększone. W ostatnich latach średni czas przejazdu szybkiego robota bez turbiny wynosił 6s, w tym roku trasa liczyła co najmniej 20m długości i czas przejazdu sięgał 11-18 sekund (w eliminacjach krótsze, finały trudniejsze-wolniejsze). Ekipa od LF spisała się bardzo dobrze, sędziowie trzymali się regulaminu, trasy były wyklejane bardzo sprawnie. Problem z komunikacją również mnie dotknął - przegapiłem rozdanie nagród w swojej konkurencji będąc w strefie technicznej - informację dostaliśmy od znajomych, którzy oglądali transmisję w TVPW 😅 Na szczęście nagrody nie przepadły i nawet daliśmy radę zrobić sobie zdjęcie pamiątkowe na podium 🙂 Jeżeli chodzi o nagrody - subiektywnie zabrakło statuetki na pamiątkę (osobiście wolę statuetki od nagród materialnych). Ogólnie zawody pod wieloma względami uważam za lepiej zorganizowane niż rok wcześniej.
  14. Dzięki za pozytywny odzew! 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... 😆 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.
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.