Skocz do zawartości

Tablica liderów


Popularna zawartość

Pokazuje zawartość z najwyższą reputacją 11.03.2019 we wszystkich miejscach

  1. 5 punktów
    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:
  2. 2 punkty
    Witam mam na imię Wiktor. Interesuje się elektroniką tworzę różne projekty. Jak każdemu majsterkowiczowi który zajmuje się elektroniką przydał by się zasilacz. Dlatego dzisiaj opiszę jak zrobiłem zasilacz 12v o dużym prądzie. opisywałem już mój projekt zasilacza regulowanego o prądzie do 3a. Ale czasami się zdarza przy różnych większych projektach że przydał by się zasilacz o większym prądzie niż 3a dlatego zbudowałem zasilacz o prądzie do 16,5a. Podczas przeglądanie internetu za zasilaczem stwierdziłem że zasilacz montażowy jest najtańszym zasilaczem o dużym prądzie. Dodatkowo taki zasilacz posiada moc 200W oraz zabezpieczenia: Przeciw zwarciowe Przeciw przeciążeniowe Przeciw wzrostowi napięcia 1. DODATKOWE ZAŁOŻENIA Miał posiadać dodatkowe zabezpieczenia, miał mieć dwa kanały zdalnie sterowane oraz wentylator działający po przekroczeniu zadanej temperatury. 2. BUDOWA Tak wygląda zasilacz z przodu. Ponieważ zasilacz budowałem kilka miesięcy temu nie mam zdjęć z jego budowy. Widok zasilacza z tyłu po prawej są bezpieczniki na dwóch kanałach oraz wentylator. Zasilacz montażowy przymocowałem do płaskownika dzięki czemu zasilacz nie jest bezpośrednio przymocowany do obudowy oraz przykręciłem zestawem śrubek do obudowy. Do regulacji wentylatora zastosowałem termostat który po przekroczeniu 40 oC włącza wentylator na pełną moc. Zastosowałem termostat ponieważ był znacznie tańszy od regulatora obrotów wentylatora. Ustawiłem też alarm na 50 oC. Jednym problemem było że przy małym obciążeniu zasilacz osiągał 40 oC problem usunąłem stosując regulator napięcia, który 12v zmniejsza na 3,3v. Dodatkowo oprócz wentylatora świecącego na niebiesko zamontowałem pasek ledów, który podświetla otwory wentylacyjne oczywiście w tedy gdy termostat się załączy. Czujnik temperatury przykleiłem klejem na gorąco do zasilacza i dodatkowo przykręciłem go metalową blaszką. Oczywiście dołączam też schemat całego zasilacza. 3. OGÓLNE PARAMETRY Napięcie 12v Prąd 16,5a Dwa kanały zdalnie sterowane Regulator obrotów wentylatora sterowany termostatem Zabezpieczenie przeciw zwarciowe zabezpieczenie przeciw przeciążeniowe Zabezpieczenie przeciw wzrostowi napięcia Dziękuję za przeczytanie mojego projektu i proszę o komentarz
  3. 2 punkty
    W moim poprzednim projekcie niektórzy przeczytali zapewne wzmiankę o tym , że powstała jego oddzielna wersja z modułem GSM , który całkiem nieźle sobie radził. Pomyślałem więc , że czemu by go tutaj nie opisać w końcu sam projekt został ukończony. tutaj początki czyli zlutowany moduł neoway a w tle genuine arduino uno , które w początkowej fazie zostało wykorzystane do przetestowania coś na zasadzie "czy to będzie działać". Okazało się , że tak aczkolwiek trzeba było dokonać zmiany baud rate na 9600 bit/s. Pod arduino jest bateria ze smartfona z , której zasilany jest moduł. Natomiast na arduino nakładka , która dała łatwiejszy dostęp (powielony) do pinów zasilania i masy. Na płytce stykowej widać konwerter poziomów logicznych przez który odbywa się komunikacja (SoftwareSerial). Piny IO modułu neoway pracują z napięciem 2,85V ale tolerują napięcie do 3,3V. Dobrze jest sprawdzić napięcie na pinie 3,3V przed podaniem go na konverter (w orginalnym uno nie będzie raczej problemu ale jeśli to będzie klon to możecie się zaskoczyć). Po kilku testach postanowiłem całość nieco zmniejszyć. to w zasadzie dalej jest to samo tyle , że model arduino uno zastąpiłem nano jeszcze z ATMega 168. Tact switch nad modemem to przycisk on/off , który uruchamia modem po dłuższym przytrzymaniu. tutaj już prawie wszystko było gotowe. Nad modemem przetwornica step-up regulowana. Wyjście z przetwornicy ustawione na 4,89V. Pewnie zastanawiacie się czemu na nie na 5V a to dlatego, że w tym modelu na pinie 3,3V jest 3,4V to wolałem nie ryzykować i lekko obniżyłem napięcie zasilania co dało pożądany rezultat w postaci spadku napięcia na pinie 3,3V nawet lekko poniżej 3,3V. ogniwo 18650 które widzicie pojawiło się tylko tymczasowo jako źródło zasilania aczkolwiek gdyby obudowa była większa to pewnie bym je zostawił. Na płytce znajdują się 4 DIP switch'e i tak pierwszy od góry włącza/wyłącza przetwornicę i tym samym doprowadza napięcie do wszystkich modułów poza modemem gsm (modem jest zasilany bezpośrednio z ogniwa). Następnie dwa DIP switch'e obok siebie wlączają/wyłączają piny TX i RX arduino od bluetooth. Ostatni DIP switch odcina napięcie do arduino. W ten sposób można wgrywać skecze do arduino po usb bez rozłączania kabli. Po prawej stronie mamy czujnik ruchu a po lewej to ten "stary telefon" w , którym nie działa dotyk ale można do niego podłączyć mysz. tutaj widać kolejno, start modemu, sprawdzenie rejestracji do sieci , siłę i jakość sygnału, a na koniec napięcie ogniwa. void skalaAku() { int aku2 = analogRead(A6); if ((aku2 == 860) && (charging == 0)) { digitalWrite(4, HIGH); //wyłączamy przekaźnik zasilania tp4056 Serial.println("Ogniwo max"); skala = 0; charging++; } else if ((aku2 == 790) && (skala == 0)) { m590.write("AT+CMGS=\"111222333\"\r"); // podajemy nr telefonu delay(300); getm590(); m590.write("Ogniwo 3,9V"); //podajemy treśc wiadomości m590.write(26); // Kod 26 = CTRL+Z delay(2000); // czekamy na wysłanie getm590(); // sprawdzamy czy poszło czy error skala++; } else if ((aku2 == 720) && (skala == 1)) { //740 OK m590.write("AT+CMGS=\"111222333\"\r"); // podajemy nr telefonu delay(300); getm590(); m590.write("Ogniwo 3,5V"); //podajemy treśc wiadomości m590.write(26); // Kod 26 = CTRL+Z delay(2000); // czekamy na wysłanie getm590(); // sprawdzamy czy poszło czy error digitalWrite(4, LOW); //włączamy przekaźnik zasilania tp4046 charging = 0; skala++; delay(300); } else if ((aku2 == 705) && (skala == 2)) { m590.write("AT+CPWROFF\r"); } } Tutaj mamy funkcję, która była wykonywana przez około tydzień czasu no i raz nie dostałem sms'a. Czas pracy na jednym cyklu ładowania to było jakieś 17h jak dobrze pamiętam więc wychodziło 2 smsy na dobę. Jeżeli ktoś chciał by z tej funkcji skorzystać to trzeba... void getm590() { if (m590.available() > 0) { Serial.print(m590.readString()); } } najpierw wpisać tą funkcję albo przynajmniej wcześniej zadeklarować , że funkcja getm590() wystąpi oraz zadeklarować dwie zmienne typu int , które występują w funkcji skalaAku() a to "świeże zdjęcie" dzisiaj zrobione na potrzeby opisu ale sam projekt tak wyglądał już w lipcu 2018 i tak jak wyżej pisałem bateria ze smartfona wróciła pod płytkę a zaoszczędzone miejsce zostało przeznaczone na moduł z dwoma przekaźnikami i od góry ładowarka tp 4056. Jeden przekaźnik może trochę dziwnie wykorzystany ale chciałem żeby ładowarka była wyłączana przed przekroczeniem napięcia 4,2V na baterii co widać w kodzie. tak to wyglądało po zamknięciu i jedynym problemem było to , że PIR sam się wzbudzał co kilka godzin pracy nawet po próbie przeniesienia go poza obudowę. Przyczyn dalszych nie szukałem bo tak jak napisałem na początku projekt powstał aby przetestować sam modem a ten nawet całkiem dobrze radził sobie z raportowaniem stanu naładowania baterii.
  4. 2 punkty
    Kolejny projekt złożony jakiś czas temu, jeśli mnie pamięć nie myli gdzieś około 2014-2015 roku. Wszelkie swoje projekty budowałem wówczas na AVR-ach, jednocześnie na wszelkie możliwe sposoby broniąc się przed wykorzystywaniem Arduino. Musiałem jednak przyznać, że użytkownicy tych płytek mieli do swojej dyspozycji całkiem fajne zabawki, jak na przykład Ethernet Shield. Przyszło mi więc do głowy wykonanie czegoś podobnego. Tak powstała prezentowana płytka. Jej sercem jest mikrokontroler Atmega644PA. Był to wtedy jeden z moich ulubionych układów, z uwagi na relatywnie sporą (jak na ośmiobitowce) pamięć oraz dwa moduły UART. Jeden interfejs szeregowy jest wyprowadzony w formie USB, za pomocą popularnego układu FT232, co znacząco ułatwia debugowanie, a w pewnym momencie eksperymentowałem także z programowaniem układu poprzez bootloader. Woląc zabezpieczyć się przed potencjalnymi problemami, interfejs USB został odizolowany od reszty konstrukcji układem ISO7221A. Najciekawszym elementem tej płytki jest chyba jednak układ Wiznet W5100 - dokładnie ten sam, który znalazł zastosowanie w Ethernet Shieldach Arduino. Muszę przyznać, że przylutowanie niewielkiego scalaka w obudowie LQFP było dla mnie wtedy sporą trudnością, jednak jak widać udało się. Z perspektywy czasu muszę jednak przyznać, że projekt PCB posiada kilka błędów i niedopatrzeń. Przede wszystkim dzisiaj bezwzględnie zastosowałbym dwustronny laminat. Zadbałbym też o to, żeby ścieżki interfejsu Ethernet tworzyły prawidłowe linie różnicowe. Wersja poprawiona nigdy nie powstała, bo niedługo potem przerzuciłem się na mikrokontrolery PIC32. Nie wspominając już o pojawieniu się modułów ESP8266, na których znacznie prościej realizuje się rozmaite konstrukcje sieciowe... Pomimo wszystkich tych niedociągnięć konstrukcyjnych płytka działa poprawnie. Od strony programowej moduł wykorzystywał bibliotekę Ethernet, pożyczoną z Arduino. Musiałem ją delikatnie przeportować, pozbywając się z kodu wszelkich odwołań do bibliotek Arduino, jednak ciągle pozostała ona całkiem używalna. Kod pod ten moduł pisałem w Atmel Studio, rzecz jasna generując projekt w C++. Uprzedzając pytania o gniazdko jack: niestety, muszę rozczarować tych, którzy sądzą, że ma ono coś wspólnego z dźwiękiem. Początkowo sądziłem, że płytka finalnie stanie się częścią pewnego projektu, który przewidywał podłączenie klucza telegraficznego i wysyłanie "tweetów" za pomocą alfabetu Morse'a. Do tego miało właśnie służyć gniazdko. Projekt został ostatecznie zarzucony a płytka była jedynie używana w celach edukacyjnych i do testowania fragmentów kodu, pod inne projekty na wczesnym etapie rozwoju.
  5. 2 punkty
    Cześć, błędy konfiguracji projektu w Eclipse. Pozdrawiam
  6. 2 punkty
    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
  7. 2 punkty
    Cześć, potwierdzam opinię @Alvedro jako zawodniczka MiniSumo. Myślę, że ze wszystkich kategorii właśnie MiniSumo najciężej na takich zawodach przeprowadzić i jest potrzebne bardzo duże doświadczenie. Niestety Robomaticon co roku organizują w dużej mierze nowe osoby, stąd ciężko mówić o ciągłości edycji, co by na pewno dużo dało. W xSumo było bardzo duże opóźnienie jak co roku, ale tym razem spowodowane dużym skupieniem na kategorii LegoSumo, które jako zawodnicy wiemy jak bardzo potrzebuje uwagi, które często rozwiązuje się poprzez wyznaczenie osobnego stanowiska tylko dla tej kategorii. Według mnie 95% problemu w tej konkurencji rozwiązałaby komunikacja z górą w jakiejkolwiek postaci oraz jak wspomina Alvedro umieszczanie informacji na stronie na temat grup. Brak komunikacji najbardziej widoczny był gdy mniej więcej 2h po rozpoczęciu xSumo przyszli zawodnicy z Sumo i LegoSumo, którzy byli zdziwieni, że byli wywoływani, bo siedzieli na górze i nie mieli żadnej informacji. Nie zapominajmy, że strefa jest dwa piętra wyżej i niestety na niej nie było nic słychać z tego, co było mówione na głównej sali. Też myślę, przydałoby się więcej informacji o drugiej sali z LineFollowerami. Pierwszy raz organizatorzy postawili na takie rozwiązanie i uważam, że było to bardzo dobre posunięcie, gdyż umożliwiło jakikolwiek ruch na głównej sali, który w poprzednich edycjach był praktycznie niemożliwy. Sama zazdroszczę zawodnikom Linefollower braku konieczności biegania na dół co chwilę Byłam na zawodach trzeci raz i uważam, że ze wszystkich te były najlepiej zrobione. Nagrody były ciekawe, chociaż mi nadal brakuje choćby malutkich statuetek. Widać było, że organizatorzy starają się bieżąco naprawiać problemy, brakuje jednak doświadczenia, które by te problemy niwelowały zanim się pojawiły. Nie mogę jednak pozostawić bez komentarza uwagi Atomowy o "Nieprzyjemna pani, której nie pasowała waga robota 502g na minus.". Nie spotkałam się z żadnymi zawodami, na których dopuszczalna była waga większa niż 500g. Nie raz widziałam zawodników, którzy dopiłowywali elementy, by zbić masę robotów, gdy ważyły nawet gram więcej niż regulaminowe 500g. Na innych zawodach by robota także nie zatwierdzili. Dziękuję za gratulację od @Sabre. Bardzo się cieszę, że miałam okazję poznać i za rok (a może i wcześniej, na przykład na zawodach Robotic Arena we Wrocławiu ) widzimy się jako zawodnicy! Tutaj filmik z mojego występu: https://www.youtube.com/watch?v=BcKX9AVf7aU
  8. 2 punkty
    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.
  9. 2 punkty
    Cześć, chciałbym przedstawić projekt, który wykonałem jako pracę inżynierską. Jej celem było skonstruowanie inklinometru (miernika służącego do pomiaru kąta przechyłu), w którym kąt wyznaczany był przy pomocy akcelerometru typu MEMS. Uzyskane wartości przyspieszenia i kąt przechyłu wyświetlane są na wyświetlaczu LCD. Jednym z założeń było wykorzystanie czujnika z wyjściem analogowym oraz czujnika z wyjściem cyfrowym. Dlatego do projektu wybrałem model MMA7361 oraz ADXL345. Innymi czynnikami wyboru tych elementów była m.in. dostępność, cena, nieduży zakres pomiarowy (aby uzyskać jak największą czułość) ale przynajmniej 1g (co odpowiada kątowi przechyłu 90°). Spis treści: Założenia Projekt struktury sprzętowej Projekt obwodu drukowanego Wykonanie i uruchomienie miernika przechyłu Wyznaczenie kąta, algorytm działania miernika i oprogramowanie Wyniki testów miernika ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 1. Założenia Koncepcja modułu inklinometru zakładała użycie mikrokontrolera, do którego podłączone zostały akcelerometry. Czujnik cyfrowy ADXL345 komunikuje się za pomocą magistrali I2C lub SPI, natomiast czujnik MMA7361 posiada wyłącznie wyjścia analogowe, dlatego konieczne było wykorzystanie przetwornika analogowo-cyfrowego. Dodatkowo mikrokontroler odpowiadał za obsługę przycisków, portu szeregowego i sterowanie wyświetlaczem. Działanie układu inklinometru oparto na popularnym mikrokontrolerze ATmega328 zaimplementowanym w module Uno Plus firmy WaveShare, który jest w pełni kompatybilny z Arduino Uno R3. Zdecydowałem się na wykorzystanie klonu Arduino z powodu zdecydowanie niższej ceny układu (w promocji zapłaciłem ok. 45 zł) i jednocześnie pewnych przydatnych rozwiązań w nim zastosowanych, m.in. popularniejsze złącze micro USB, przycisk reset naciskany z boku, przetwornik ADC, itd. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 2. Projekt struktury sprzętowej Na rysunkach poniżej przedstawiono wykorzystane wyprowadzenia platformy Uno Plus wraz ze złączami służącymi do podłączenia zaprojektowanych modułów. Do podłączenia wyświetlacza LCD ze sterownikiem HD44780 wykorzystano wyprowadzenia na listwę typu goldpin (złącza JP3 i JP4). W celu regulacji kontrastu użyto potencjometr o wartości 10kΩ (R2). Wyświetlacz zasilany jest napięciem 5V. Przyciski – podłączone do złącza JP5 zostały programowo „podciągnięte” do stanu wysokiego poprzez wyprowadzenia I/O mikrokontrolera. Rozpoznanie wciśnięcia przycisku występuje w chwili wykrycia stanu niskiego na linii portu, który występuje po zwarciu do masy. Czujnik ADXL345 zasilany jest napięciem 3,3V. Napięcie zasilające jest filtrowane przez kondensator tantalowy o wartości 10µF i dwa kondensatory 0,1µF. W celu uruchomienia komunikacji za pomocą magistrali I2C należało wybrać układ przez podanie stanu wysokiego na wejście CS oraz zapewnić stan wysoki na liniach SCL i SDA, co zrealizowano przez zastosowanie rezystorów podciągających o wartości 10kΩ. Podłączając pin SDO do masy (stan logiczny niski) wskazano, że układ posiada na magistrali I2C adres o wartości 0x53 (alternatywnie podając stan wysoki adres miałby wartość 0x1D). W układzie połączeń czujnika MMA7361 wejście Sleep jest wewnętrznie ustawione w stan niski, co wprowadza płytkę w stan uśpienia i niski pobór energii. Aby uruchomić czujnik należy do tego wejścia podać stan wysoki, np. za pomocą podłączenia do napięcia zasilania 3,3V, jak zostało zrobione to w projekcie. W przypadku potrzeby kontroli nad trybem Sleep należałoby podłączyć to wejście do mikrokontrolera za pomocą wyprowadzeń I/O i odpowiednio sterować (pamiętając o poziomach napięć, gdyż UNO PLUS pracuje z napięciem +5V). Podłączenie wejść g-Select i 0g-Detect jest opcjonalnie. Wejście g-Select jest wewnętrznie ustawione w stan niski, który odpowiada ustawieniu czułości na zakres ±1.5g (800 mV/g). Wejście 0g-Detect wystawia napięcie na poziom wysoki gdy wszystkie osie wskazują przyspieszenie równe 0g. Dzieje się tak kiedy płytka znajduje się w stanie spadku swobodnego. Z powodu braku potrzeby użycia tych funkcji (jak najmniejszy zakres pomiarowy jest bardziej odpowiedni w projekcie inklinometru) wejścia te pozostawiono niepodłączone. Wyjścia X, Y i Z akcelerometru zostały podłączone odpowiednio przez złącze JP2, do wejść A0, A1 i A2 mikrokontrolera, które są wejściami przetwornika A/C. Uwzględniając napięcie zasilania akcelerometrów (3,3V) oraz zakres analogowych sygnałów wyjściowych, dla przetwornika analogowo – cyfrowego wybrano zewnętrzne napięcie referencyjne o wartości 3,3 V (wejście AREF podłączono do napięcia 3,3V), a w oprogramowaniu mikrokontrolera wybrano zewnętrzne napięcie referencyjne. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 3. Projekt obwodu drukowanego Dla wybranych czujników przyspieszenia zaprojektowano i wykonano dwie osobne płytki PCB, o jednakowych wymiarach 40x30 mm. Wymiary płytek wynikały z potrzeby ich dopasowania do stanowiska testowego w laboratorium. Oba układy przetworników posiadają 14 wyprowadzeń i zamknięte są w obudowie LGA-14.W projekcie zastosowano elementy pasywne SMD. Z uwagi na małe rozmiary układów scalonych minimalna odległość między ścieżkami wynosi 10 mils. Ścieżki zasilające mają szerokość 24 mils, a ścieżki sygnałowe 20 mils. Na niewykorzystanej powierzchni płytka została wypełniona masą. Z płytki czujnika ADXL wyprowadzone są 4 sygnały: VCC (zasilanie układu), GND (masa układu), SCL (linia zegarowa) i SDA (linia danych). Z płytki czujnika MMA wyprowadzonych jest 5 sygnałów: VCC (zasilanie układu), GND (masa układu), A0 (wyjście napięciowe osi X), A1 (wyjście napięciowe osi Y) i A2 (wyjście napięciowe osi Z). ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 4. Wykonanie i uruchomienie miernika przechyłu Płytki PCB z czujnikami wykonano metodą termotransferu. Dodatkowo zostały umieszczone napisy na warstwie ścieżek w postaci nazwy wykorzystanego czujnika na danej płytce. Montaż elementów wykonano wykorzystując stację lutowniczą typu HotAir. Z powodu projektu płytki jednowarstwowej, dodatkowo dokonano potrzebne połączenia za pomocą przewodów. Do połączenia płytek czujników z układem mikrokontrolera zastosowano przewody ze złączami 6-pinowymi i gniazdami kątowymi typu goldpin przymocowanymi do nakładki prototypowej. Na nakładce prototypowej znalazły się również klawiatura, listwy służące do montażu wyświetlacza LCD i badania napięć wyjściowych czujnika analogowego oraz potencjometr do regulacji kontrastu wyświetlacza LCD. Rysunek poniżej przedstawia zmontowany i uruchomiony miernik przechyłu z podłączonymi czujnikami zasilany poprzez port micro USB. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 5. Wyznaczenie kąta, algorytm działania miernika i oprogramowanie Funkcja wyboru odczytu danych wykorzystuje trzy przyciski. Algorytm jest trochę ubogi ale do projektu wystarczył. Pomiar przyspieszenia z wykorzystaniem czujnika analogowego MMA7361 polega na wyznaczeniu wartości napięcia na wyjściach osi akcelerometru za pomocą 10-bitowego przetwornika analogowo-cyfrowego, a następnie wykonywane są obliczenia realizujące skalowanie czujnika. Wyznaczenie napięcia polega na pomnożeniu wyniku bitowego i napięcia referencyjnego, a następnie podzielenie przez 1023 (10-bitowy przetwornik, 210) xV_analog=(float(xADC)*3.3/1023); yV_analog=(float(yADC)*3.3/1023); zV_analog=(float(zADC)*3.3/1023); W celu otrzymania wartości przyspieszenia w jednostkach „g” dokonano odpowiedniego skalowania. Od zmierzonej wartości napięcia odjęto wartość 1,65 V, która jest połową wartości napięcia zasilania czujnika i odpowiada wartości napięcia przy przyspieszeniu wynoszącym zero. W następnym kroku uwzględniono czułość czujnika (800mV/g). Wartość przyspieszenia wyliczono posługując się wzorami: xG_analog=(xV_analog-1.65)/0.800; yG_analog=(yV_analog-1.65)/0.800; zG_analog=(zV_analog-1.65)/0.800; Czujnik cyfrowy ADXL345 do poprawnego działania, przed bezpośrednim odczytem danych, wymaga pewnych ustawień, które realizowane są na podstawie dostępnych w dokumentacji technicznej mapie i definicji rejestrów. Ustawienie to odbywa się poprzez zapis do rejestrów czujnika odpowiednich wartości bitowych i w programie przyjmował następujący format: ustawI2C(adres_czujnika, adres_rejestru, wartość); Adres akcelerometru ADXL345 to 0x53 i może dzielić magistralę z innymi urządzeniami dopóki ma unikalny adres. Wszystkie wartości liczbowe podawane są w systemie szesnastkowym: ustawI2C(0x53, 0x2D, 0x08); // do rejestru POWER_CTL, o adresie 0x2D, wpisano wartość 0x08, która inicjalizuje tryb gotowości do pomiaru, ustawI2C(0x53, 0x31, 0x08); // do rejestru DATA_FORMAT (adres 0x31) wpisano wartość 0x08 ustawiając wybrane parametry takie jak rozdzielczość i czułość czujnika, ustawI2C(0x53, 0x2C, 0x08); // do rejestru BW_RATE (adres 0x2C) wpisano wartość 0x08 ustawiając częstotliwość pomiaru na 50Hz. Dane wyjściowe z czujnika odczytywane są z sześciu 8-bitowych rejestrów, po dwa dla każdej osi. Każdy wynik jest reprezentowany za pomocą dwóch bajtów. Funkcja odczytu danych przez magistralę I2C ma postać: odczytI2C(0x53, 0x32, buffer, 6); - odczyt danych z czujnika zaczynając od rejestru DATAX0 (adres 0x32) i kończąc na rejestrze DATAZ1 (adres 0x37). Następnie za pomocą odpowiednich funkcji, dwa odczytane bajty dla danej osi czujnika łączone są w jedną zmienną. Uzyskana w ten sposób wartość bitowa mnożona jest przez współczynnik skali, wynoszący w tym przypadku 3,9 mg/LSB, i otrzymywana jest wartość przyspieszenia w jednostkach „g”. xG_digital = xBit_digital * 0.0039; // -256=-1g, 0=0g, 256=1g yG_digital = yBit_digital * 0.0039; zG_digital = zBit_digital * 0.0039; Na podstawie otrzymanych wartości przyspieszeń z czujników wyliczany jest kąt przechyłu wykorzystując odpowiednie wzory. Dokładny kąt nachylenia może być mierzony tylko wtedy, gdy na przyspieszeniomierz działa wyłączenie siła grawitacji. Działanie innych sił, np. ruchu, powoduje dodatkowe przeciążenia, uniemożliwiając prawidłowe ustalenie nachylenia. Pomiar przechyłu można dokonać wykorzystując nawet jedną oś, lecz wyniki naznaczone są pewnymi ograniczeniami, których opis może pominę. Wykorzystując trzy osie, do ustalenia orientacji czujnika względem ziemi, kąt nachylenia wektora siły grawitacji może być w pełni określony. Czułość jest stała dlatego kąty mogą być dokładnie zmierzone bez względu na położenie czujnika. Dane przesyłane pomiędzy interfejsem UART i USB przyjmują format opisany w tabeli. Wybierając polecenie uruchomienia transmisji pomiędzy urządzeniami aktualne wartości z czujników wysyłane są na bieżąco do momentu przerwania transmisji przez użytkownika. Wysyłane dane są w postaci znakowej i posiadają 4- znakowy nagłówek i pole danych. ASTY (ASensorTYpe) – oznaczający typ czujnika, BACC (BACCeleration) – oznaczający przyspieszenie, CANG (CANGle) – oznaczający kąt przechyłu. Po nagłówku wysyłany jest separator w postaci znaku „ ; ”, a następnie pole danych zakończone znakiem „ ; ”. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 6. Wyniki testów miernika Badania przeprowadzono na stanowisku przeznaczonym do badania czujników przechyłu – bazując na równi pochyłej. Wartości kąta przechyłu wyznaczone zostały na podstawie zależności trygonometrycznych w trójkącie prostokątnym. W skrócie. Dwie deski połączone zawiasem. Na jednej desce przyklejona miarka. Na drugiej desce na nitce o stałej długości zawieszony pion murarski. Podnosząc jedną deskę pion dzięki sile grawitacji tworzył kąt prosty, a z miarki odczytywano wartość wyznaczoną przez nić. Z otrzymanych proporcji wyliczano dokładny kąt. Z racji już długiego tekstu może pominę szczegółowy fragment kalibracji. Więc tak w skrócie: Akcelerometry MEMS w swojej strukturze zawierają elementy, które mogą swobodnie się poruszać, dlatego są o wiele bardziej wrażliwe na powstałe naprężenia mechaniczne niż inne elementy półprzewodnikowe. Naprężenia mogą powstawać m.in. podczas montażu czujnika i komponentów na obwodzie drukowanym. W celu wyeliminowania błędów w pomiarze należy wykonać kalibrację czujników. Dzięki rejestrom OFSX, OFSY i OFSZ możliwe jest wprowadzenie korekty wyników w czujniku cyfrowym ADXL345. Wartość przechowywana w tych rejestrach jest automatycznie dodawana do mierzonego przyspieszenia i kompensuje błędy pomiaru. Kalibracja czujnika analogowego polega na wyznaczeniu maksymalnych i minimalnych napięć pojawiających się na wyjściach osi pomiarowych poprzez obrót wokół ich płaszczyzn. Wartość maksymalna pojawi się gdy na oś będzie działać przyspieszenie +1g, natomiast wartość minimalna w przypadku działania przyspieszenia wynoszącego -1g. Zakładając, że czułość zmienia się symetrycznie, od 0 do +1g oraz od 0 do -1g, można wyznaczyć jej dokładną wartość dodając do siebie wartości napięcia maksymalnego i minimalnego, a następnie dzieląc je przez 2. Pomiary wykonano laboratoryjnym multimetrem cyfrowym. Wykonane badania wykazały, że maksymalna różnica pomiędzy kątami rzeczywistymi, a kątami wskazanymi przez inklinometr wynoszą maksymalnie 1°. Błąd pomiędzy wskazaniami miernika może wynikać m.in. z braku wykonania urządzenia w pełni profesjonalnych warunkach, a otrzymany wynik błędu jest satysfakcjonującym rezultatem. Dodatkowo do pełnego, stabilnego badania położenia i wyeliminowania błędów pomiaru należy zastosować połączenie akcelerometru, żyroskopu i magnetometru. Ostatnie zdjęcia prezentują działanie inklinometru. Na pierwszym zdjęciu pomiar dokonywany jest za pomocą czujnika MMA7361. Można zauważyć, że płytka leży prawie poziomo - kąt 6,8°. Z kolei na drugim zdjęciu płytka z czujnikiem ADXL345 ustawiona jest prawie pod kątem 45°. Dzięki za doczytanie do końca. Pozdrawiam :)
  10. 1 punkt
    Opisz trochę dokładnie co się dzieje, nie mamy płytki przed sobą, więc ciężko debugować. Miga dioda, nie miga, powinna migać, nie powinna itd. Napisz co się dzieje, a co powinno się według Ciebie dziać
  11. 1 punkt
    Package on package (PoP) jest powszechna metoda upychania komponentów w dzisiejszych czasach, nawet rpi było tak budowane do modelu 3, gdzie stwierdzono że chyba z powodów odprowadzania ciepła układ pamięci zostanie przeniesiony na drugą stronę płytki. Konkretnie chodzi o lutowanie pamięci nad SoC-iem ma to na celu zminimalizowanie opóźnień i wpływów innych układów do poziomu bliskiego temu który występował by w zintegrowanym układzie z jednoczesnym zachowaniem elastyczności związanej z wykonaniem i wykorzystaniem osobnych układów. To o czym ja piszę to dwie płytki PCB ułudzie jedna na drugiej. Nie jestem pewien czy ten typ konstrukcji jest gdzieś indziej powszechnie wykorzystany. https://www.techinsights.com/about-techinsights/overview/blog/apple-iphone-x-teardown/ Jedna metoda oczywiście nie wyklucza drugiej.
  12. 1 punkt
    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.
  13. 1 punkt
    Okay, zamówiłem płytkę z JLCPCB, poczekałem miesiąc, i przyszła. Muszę powiedzieć, że jestem BARDZO zadowolony z roboty którą odwalili. Są idealnej jakości, przyszłali ich dziesięć, a zapłaciłem tylko 20 zł! (bez dostawy 6 zł!!) Płytka działa bez zarzutu, oprócz migającej diody i buzzera. To usterka w kodzie, ale nie mogę jej znaleźć. Pomożecie? #include <SPI.h> #include <MFRC522.h> #include "Keyboard.h" #define RST_PIN 9 // Configurable #define SS_PIN 10 // Configurable uint8_t successRead; // Variable integer to keep if we have Successful Read from Reader byte storedCard[4]; // Stores an ID read from EEPROM byte readCard[4]; // Stores scanned ID read from RFID Module int x = 1; String readid; MFRC522 mfrc522(SS_PIN, RST_PIN); // Create MFRC522 instance void setup() { Serial.begin(9600); // Initialize serial communications with the PC // Do nothing if no serial port is opened (added for Arduinos based on ATMEGA32U4) SPI.begin();// Init SPI bus Keyboard.begin(); pinMode(2, OUTPUT); mfrc522.PCD_Init(); // Init MFRC522 mfrc522.PCD_DumpVersionToSerial(); // Show details of PCD - MFRC522 Card Reader details Serial.println(F("Scan PICC to see UID, SAK, type, and data blocks...")); } void temp(byte *buffer, byte bufferSize)//function to store card uid as a string datatype. { readid=""; for(byte i = 0;i<bufferSize; i++) { readid=readid+String(buffer[i], HEX); } } void loop() { successRead = getID(); if (successRead == 1) { temp(mfrc522.uid.uidByte, mfrc522.uid.size); if (readid == "6a6b1f7") { if (x == 1) { Keyboard.press(KEY_ESC); delay(100); Keyboard.releaseAll(); delay(500); Keyboard.print("8659"); Serial.print(readid); blk; x = 2; return; } if (x == 2){ Keyboard.press(KEY_LEFT_GUI); Keyboard.press('l'); delay(100); Keyboard.releaseAll(); x = 1; return; } } successRead = 0; } else { blke; } } ///////////////////////////////////////// Get PICC's UID /////////////////////////////////// uint8_t getID() { // Getting ready for Reading PICCs if ( ! mfrc522.PICC_IsNewCardPresent()) { //If a new PICC placed to RFID reader continue return 0; } if ( ! mfrc522.PICC_ReadCardSerial()) { //Since a PICC placed get Serial and continue return 0; } // There are Mifare PICCs which have 4 byte or 7 byte UID care if you use 7 byte PICC // I think we should assume every PICC as they have 4 byte UID // Until we support 7 byte PICCs //Serial.println(F("Scanned PICC's UID:")); for ( uint8_t i = 0; i < 4; i++) { // readCard[i] = mfrc522.uid.uidByte[i]; Serial.print(readCard[i], HEX); } Serial.println(""); mfrc522.PICC_HaltA(); // Stop reading return 1; } uint8_t blk() { digitalWrite(2, HIGH); delay(200); digitalWrite(2, LOW); } uint8_t blke() { digitalWrite(2, HIGH); delay(1000); digitalWrite(2, LOW); }
  14. 1 punkt
  15. 1 punkt
    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.
  16. 1 punkt
    Właśnie ja jestem zdania, że albo koszulka jest czysta i zawiera jedynie logotypy samych zawodów i wtedy za nią płacę lub zawiera dodatkowo logotypy sponsorów, jest jednocześnie reklamą i wtedy zawodnicy dostają ją gratis. Tutaj było tak pomiędzy, bo był chyba tylko jeden logotyp sponsora, ale jednak.
  17. 1 punkt
    Ja także jak @Alvedro startowałem w kategorii minisumo. Niestety także twierdzę że organizacja zostawiała wiele do życzenia. Rozumiem że każdy jest człowiekiem i popełnia błędy, ale jeżeli zawodnik musi uczyć sędziego jak posługiwać moduły startowe to powoli przestaje być śmieszne. Gdyby nie dobra wola innych graczy, którzy osobiście mnie szukali żeby powalczyć nawet nie wiedziałbym że walka nastąpiła. Oprócz rzeczy wymienionych wyżej uderzyło mnie to że zawodnicy mimo opłat za wystawienie robota i sponsorów nie otrzymali pamiątkowych koszulek... Trochę przykro, ale cieszę się że zabrałem udział i tak
  18. 1 punkt
    Moim zdaniem to taka sztuka dla sztuki. Można było takie zabawy robić jak chciało się mieć płytkę więcej niż 2 warstwową, a nie zależało na grubości.
  19. 1 punkt
    Nie dość że utrudnia życie serwisantom to jeszcze się będzie grzała w środku..
  20. 1 punkt
    Co do Linefllower-ów to słyszałem komunikat, że zawody odbywają się w sali 206 obok małej auli. Chyba w tym roku starty niektórych konkurencji odbywały się później niż w zeszłym roku. W tym roku też nie widziałem przedstawicieli z drukarkami 3d. Za to na duży + były zajęcia dla dzieci, w tym z Python-a. W kategorii PuckCollect tylko 2 zawodników i nawet nie zorientowałam się kiedy te zawody zostały rozegrane, w zeszłym chyba nie było ich więcej. W konkurencji HumanoidSprint w mojej ocenie tylko jeden uczestnik (niebieski robot) spełniał kryteria regulaminu tj. szedł (wyraźnie miał podniesiona jedną nogę nad matą, nawet balansował "ciałem") a nie szorował obiema nogami po macie - ale jakoś sędziowe łaskawie podchodzili do zapisów regulaminu.
  21. 1 punkt
    Do licznych zalet TinkerCAD'a dodał bym informację o tym, że program można pisać w "bloczkach" podobnych do Scretch'a czy S4A, a system zwykle potrafi dokonać translacji tak przygotowanego kodu na dialekt C stosowany przez Arduino. Jeżeli zauważycie Państwo, że w gimnazjach na informatyce uczy się programowania w Scretch to generator kodu przygotowany przez Autodesk może być ciekawym narzędziem do łagodnego przejścia od "bloczków" do C. Jeszcze raz polecam ten system do nauczania elementów elektroniki, informatyki, automatyki i ... podobnych przedmiotów.
  22. 1 punkt
    Szybkie pytanko, więc szybka odpowiedź: nie
  23. 1 punkt
    Moja relacja z zawodów ROBOTICON w gmachu głównym PW: Mam nadzieję, że się podoba
  24. 1 punkt
    Bodajże w iPhone x i wyższych modelach zastosowano konstrukcje złożoną z dwóch płytek połączonych razem, tam oczywiście rozdzielone były 'powietrzem'. Nie jest też ten pomysł nowością robiło się tak płytki w technikum kiedy to ciężko było o jednostkowe profesjonalnie wykonane płytki o wielu warstwach. Czy jest to przyszłość branży? Raczej nie, bo taniej i łatwiej jest zrobić klasyczne pcb z wielu warstw. Być może metoda znajdzie swoje zastosowanie gdy warstwę pomiędzy dwoma płytkami wypełni się czymś innym niż trzecia. Dla hobbystów jest to jakaś metoda na zmniejszenie powierzchni płytki kosztem jej wysokości, bądź właśnie wykonanie w taki sposób 'obudowy'.
  25. 1 punkt
    Cześć, jestem na etapie projektowania line followera i naszła mnie taka refleksja dotycząca jednego z podpunktów regulaminu dla kategorii Line Follower Enhanced. Niedługo jest Robomaticon, więc za przykład dam podpunkt z ich regulaminu, ale wydaję mi się, że regulamin w tej kwestii jest spójny dla większości turniejów. Przechodząc do meritum, jest w regulaminie taki zapis: Co sądzicie o podawaniu wcześniej wymiarów przeszkody? Równie dobrze mogłyby zostać podane dokładne długości odcinków trasy, kąty pomiędzy nimi itd. Tylko czy o to w tym chodzi. Zapis ten powoduje to, że większość (generalizuję, piszę to jedynie na podstawie moich obserwacji przejazdów robotów w tej kategorii podczas różnych zawodów) uczestnik ma przygotowany kod, który można uprościć do wykonania pewnej sekwencji ominięcia przeszkody, na sztywno zapisanej w pamięci, w przypadku wykrycia przez czujnik odległości przeszkody. Gdyby chociażby przesunąć tę przeszkodę kilka centymetrów w jedną, bądź w drugą stronę względem środka linii to jestem pewien, że podczas pierwszego przejazdu roboty by sobie nie poradziły z nią, a przed kolejnym przejazdem zostałaby dodana sztywna poprawka uwzględniająca sztywne położenie przeszkody. Działa to, roboty sobie radzą z ominięciem przeszkody, czasem można się uśmiechnąć jak robot wykryje przeszkodę, która nie jest tą właściwą przeszkodą i wtedy wykonuje swoją sekwencję ominięcia przeszkody. Nie ma nic w tym złego, tylko jeżeli mówimy o autonomicznym robocie, który potrafi zareagować na różne konfiguracje trasy, to czy nie powinien również móc zareagować na niezdefiniowaną wcześniej przeszkodę? Zapraszam do dyskusji.
  26. 1 punkt
    Może jednak ktoś jeszcze dołączy do dyskusji, może któryś z organizatorów zawodów?
  27. 1 punkt
    ArduinoDroid też powinno ci działać tylko trzeba dokonać jednej zmiany. Settings---->App settings, przewiń na sam dół i ustaw reset delay na 700ms (może być między 500-1000). Standardowo w tym polu jest 0 ms (tak było w mojej wersji tego programu i u ciebie też pewnie tak jest) i przy takiej wartości żaden skecz się nie wgrywa. Po tej zmianie działa ok chociaż przyznam, że bluinoloader działa szybciej i jest bardziej stabilny bynajmniej na moim smartfonie. ArduinoDroid obsługuje inne płytki arduino np: arduino Mega czy Yun ma też kilka ciekawych opcji których brakuje w BL np: szybki dostęp do funkcji i zmiennych w kodzie (zakładka Navigator).
  28. 1 punkt
    Ciekawy pomysł, już chyba niewiele bardziej da się utrudnić życie serwisantom.
  29. 1 punkt
    Ekranowanie całych układów jest obecne? Też może mieć wpływ na występowanie błędów i na resety urządzeń. RS485 powinno załatwić sprawę, przynajmniej w większości przypadków. Ekrany podłączone z jednej strony, a z drugiej "wiszą"? Swego czasu widziałem, jak duża firma na polskim rynku zmagała się z problemem ekranowania przewodów - było za dużo zakłóceń, nie przechodziło testów itp. Problem rozwiązało wstawienie kondensatora w szeregu między ekranem modułu odbiorczego a masą tego modułu (ekran połączony z masą przez kondensator 100nF) + zwiększenie prądów transmisyjnych (o ile dobrze pamiętam to coś około 5 razy zwiększyli prąd). Oczywiście z drugiej strony było normalne połączenie do masy. Niestety nie wiem czy to rozwiąże problem, kiedyś widziałem takie rozwiązanie które się sprawdziło
  30. 1 punkt
    Wreszcie dotarł czysty ATtiny85 i przeniosłem zestaw na wersję dla malutkiej płytki prototypowej (170 styków). Rozmieszenie jest dość nietypowe, ale dzięki takiemu upchnięciu większości połączeń w lewym górnym rogu możliwe było maksymalne zsunięcie ekranu w dół i nie wystaje on ponad płytkę, w wyniku czego jeszcze bardziej miniaturyzuje układ: Dzięki temu rozmieszczeniu dodatkowo żadne izolowane przewody nie przeszkadzają głośnikowi piezo i może być on maksymalnie dociśnięty do płytki. Na schemacie ekran nieznacznie wystaje, ale w rzeczywistości jest mniejszy, co można zobaczyć na zdjęciach. Zestaw zasilam okrągłą 3V baterią CR2032 lub 3.7V lipo. Poniżej schemat dla płytki 170-stykowej:
  31. 1 punkt
    Cześć, 1) Rozwiązanie prostsze: konwerter UART-RS485 (lub RS422) - pętla prądowa na prawidłowym kablu niweluje indukowane zakłócenia. 2) Trudniejsze: magistrala CAN - ma bardzo dobrą korekcję błędów sprzętową. Rozwiązań programowych jest sporo: od liczenia prostych sum kontrolnych po kody korekcyjne. Pozdrawiam
  32. 1 punkt
  33. 1 punkt
    Taki poradnik to fajna rzecz. Szczególnie jak ktoś zaczyna przygodę z Linuxem od Raspbiana.
  34. 1 punkt
    Chciałbym przedstawić projekt modułu akcelerometru opartego na MMA7361 firmy Freescale, który to układ był dostępny jako darmowe próbki. Obecnie są dostępne (spośród kompatybilnych) jedynie układy: 7331, 6361, 6341 i 6331, różniące się czułościami i niektórymi opcjami. Moduł został zaprojektowany na potrzeby pisanej przeze mnie pracy magisterskiej, ale miał być na tyle uniwersalny, aby dało się wykorzystać wszystkie możliwości układu. Jest przydatny we wszelkich robotach kroczących. Nóżki odpowiedzialne za dodatkowe opcje są domyślnie podciągnięte tak, aby płytka działała tylko przy samym podłączeniu zasilania i wyprowadzeniu sygnałów. Domyślna ustawiona czułość wynosi -+1.5g (800mg/V). W wymienionych układach zastępczych różnice dotyczą tylko obecności (lub nie) nóżek Self-test bądź 0g-detect. Projekt PCB zakładał montaż układu poprzez podkładki amortyzujące mające tłumić drgania mechaniczne, oraz możliwość dociążenia płytki za pomocą śrubek M3. Połączenie jest realizowane przez taśmę IDC10. Z modułu można również pobrać zasilanie do układów na 3.3V. Jak można zauważyć na schemacie brakuje dławika wygładzającego prąd. W takim wypadku występują zakłócenia wysokiej częstotliwości: które przenoszą się na wyjscie: Są to zakłócenia wysokiej częstotliwości (zakłóceń niższej częstotliwości nie ma), dlatego też próbowałem je wygładzić dławikiem 10uH podłączonym między wyjście LF33 a kondensatorem 22u. W efekcie zakłócenia na zasilaniu: Warto zwrócić uwagę na skalę - mimo 10x większej czułości, zakłócenia wysokiej częstotliwości były znikome (zakłócenia niskiej częstotliwości się nie pojawiły). W efekcie zakłócenia które się przenosiły na wyjście: Wygląda świetnie? Niestety tylko w skali mikro. Otóż w skali ms tak wygląda porównanie: W obu przypadkach należy zmierzone wartości jeszcze przefiltrować - jednakże w przypadku układu bez dławika sygnał ma mniejszą wartość międzyszczytową i mniejszą wariancję, a tym samym jest lepszy. Jeśli w układzie dysponujemy innym źródłem zasilania 3.3V, stabilizatora na tej płytce możemy nie lutować a zakłóceń pozbyć się w inny sposób. Ze swojej strony mogę jeszcze dodać, że bardzo dobrze do usuwania zakłóceń akcelerometru nadaje się filtr medianowy, w celu zwiększenia dokładności można wykorzystać filtr uśredniający (np. ze średnią kroczącą). Mogę powiedzieć, że po zastosowaniu tychże filtrów udało mi się uzyskać bardzo dobrą stabilność pomiaru: przy podwójnym całkowaniu tak uzyskanego przyspieszenia (w celu uzyskania przesunięcia) dla układu, który jest nieruchomy, nie dochodzi do zmian przesunięcia, tym samym pomiar można powiedzieć, że "nie pływa". Załączam projekt pcb aby każdy mógł wykonać płytkę. Projekt utworzony pod Protelem 99se, będzie również działał pod Altiumem. akcelerometr.rar
Tablica liderów jest ustawiona na Warszawa/GMT+02:00
×
×
  • Utwórz nowe...