Skocz do zawartości

mice.co

Użytkownicy
  • Zawartość

    21
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    1

Wszystko napisane przez mice.co

  1. Dziękuję za głosy na Cukiereczka oraz za przesłany zestaw gadżetów!
  2. Z arduino silniki ruszają? Może kwestia błędu w schemacie. Standby jest podłączony do stanu wysokiego?
  3. 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.
  4. 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.
  5. 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)
  6. 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.
  7. 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.
  8. 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:
  9. Mam dokładnie ten sam problem co Marcinas. Pod każdym portem SW4STM32 nie śmiga Co innego z Atollic'iem i IARem - żadnych problemów. Program z Workbencha można wgrać przez ST-Utility - też śmiga.
  10. Potwierdzam - soft start się nie sprawdzi. Robot może kicać na zakrętach. A w przypadku "analogowego" zczytywania z czujników linii pewnie trzeba podnieść listwę troszkę w górę, dobrać odstępy, prąd diody.. Dodatkowo może to być problematyczne w przypadku zmiennego oświetlenia. Nie wiem jak to jest w najszybszych LFach, ale może i warto się tym zająć. Dzisiaj liczy się najmniejszy szczegół, żeby przodować w tej konkurencji.
  11. Jest sporo zdjęć w relacji z trójmiejskich zawodów. Robot ciekawie zrobiony, ale niestety jeszcze niewyregulowany.
  12. Jaką wagę udało się osiągnać? Jakiś filmik ukazujący większe możliwości le'mua?
  13. Świetne zawody, najlepsze na jakich byłem - a byłem już na 3 Organizacja i przygotowanie 9.5/10 (zawsze można coś poprawić ) Doceniam poświęcony czas, siły i że komuś się chciało. Wysoko podnieśliście poprzeczkę, na pewno wyróżniacie się na tle innych i mam nadzieję, że organizatorzy innych zawodów będą starać się wam dorównać. Jedynie mogłoby być troszkę więcej zawodników.
  14. Płytkę czujników już zaprojektowałem. Cały czas przeglądam tę notę katalogową i nadal nie rozumiem. Vo z KTIR przekracza 0-5V? Znalazłem także, że pull-upy w Atmedze8 to 20-50k, znajomy mi powiedział, że prawdopodobnie mogę je zastosować zamiast tych "fizycznych", w nocie jest przykład z 15k, znaczna różnica? Niestety trochę śpieszę się z płytką, bo chcę by była skończona zanim wyjadę z domu, a później zajmę się najgorszą dla mnie przeszkodą czyli programowaniem. Jeśli nie będzie się do tego nadawała to nic się nie nauczę i pewnie odstawie projekt na kolejne święta. Muszę też godzić to wszystko z innymi obowiązkami.
  15. Przyznaję, marny ze mnie elektronik. Sposób podłączenia czujników z tym komparatorem podpatrzyłem z innych projektów (Macliner 2 bodajże). Z opornikiem wyliczyłem, że będzie to 470 Ohm, tamte też podpatrzyłem z innych projektów. To mój pierwszy projekt i ciężko mi wszystko projektować od podstaw.. Aktualnie będę podłączał czujniki w ten sposób: Może to nie jest dział dla zielonych, ale czy mógłbyś powiedzieć mi jakie są zagrożenia, co do poprawy i czy muszę całą płytkę od nowa tworzyć..? :/ O kurcze, w Maclinerze chyba są wewnętrzne rezystory pull-up z uC, niestesty nie mam o tym żadnego pojęcia. Czy da się to tutaj zastosować bez większych ingerencji?
  16. Dzięki, właśnie takiej odpowiedzi oczekiwałem. Miał być piękny LF na jednym PCB, ale postanowiłem, że utnę część z czujnikami, i podczepię nową z dobrze połączonymi. Teraz zastanawiam się tylko czy potencjometr z rezystorami pod komparator mają dobre wartości, i czy właśnie dać 10k zamiast 20k na "podciągniki"?
  17. Oczywiście, że nie chcę. Po prostu jak mówię, mam już wytrawioną i polutowaną płytkę. Nie uruchamiałem jej jeszcze, zauważyłem po prostu błąd połączenia. A pytam, gdyż wyczuwam choć cień szansy po przejrzeniu datasheetu: i znalezieniu takiego tematu na elektrodzie:
  18. Wiem jak należało podłączyć, ale chciałem się zapytać czy można podłączyć odwrotnie. Bo jak w eagle'u łatwo sobie kliknąć i zamienić wyprowadzenia, tak na wytrawionej i polutowanej płytce już nie bardzo..
  19. Witam, Przy projektowaniu robota użyłem czujników KTIR0711S, żeby sprawdzić jak należy je podłączyć zajrzałem na google'a i nieświadomie trafiłem na schemacik do CNY70 i tak podłączyłem, czyli: (Potencjometr jest 1kOhm.) Zamieniłem kolektor z emiterem. Czy takie coś ma prawo działać? Czy muszę od nowa projektować płytkę? I czy moglby ktos sprawdzic poprawnosc reszty schematu? (Plik w załączniku) line follower.pdf
×
×
  • Utwórz nowe...