Skocz do zawartości

Tablica liderów


Popularna zawartość

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

  1. 9 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. 7 punktów
    Cześć. Chciałbym przedstawić wam mój projekt robota samobalansującego. Jest to mój najbardziej zaawansowany jak dotąd projekt, który pochłonął najwięcej pracy. Pomysł na zbudowanie takiego robota zrodził się w mojej głowie w wakacje po obejrzeniu filmiku przedstawiającego podobną konstrukcję. Pracę nad nim rozpocząłem jeszcze w wakacje, a z przerwami zakończyłem w lutym. Działanie robota jest podobne do dostępnych na rynku Hoverboardów, czyli robot ma za zadanie poruszać się w taki sposób, aby utrzymać się w pionie, oczywiście bez podpierania. Konstrukcję robota zaprojektowałem sam i wykonałem z pręta gwintowanego i plexi. Uznałem że taka konstrukcja zapewni robotowi wymaganą sztywność i niską masę, jednocześnie nie rujnując budżetu. Najpierw wykonałem jej model w Fusion 360, a później przystąpiłem do pracy. Roboty z tym trochę było, bo obróbka plexi do łatwych nie należy. Sporo czasu zajęło przycięcie prostokątów, a jeszcze więcej wywiercenie otworów, które musiały być idealnie rozmieszczone, aby później dało się przełożyć przez nie pręt gwintowany. Po zbudowaniu ramy przyszła pora na elektronikę. Ponieważ robot nie zapewnia dużo miejsca, a jednocześnie środek ciężkości powinien być możliwie wysoko, dla ułatwienia balansu, musiałem się postarać ścisnąć wszystko jak to tylko możliwe. Baterię zasilającą robota (ogniwe Li-Po odzyskane z powerbanka o pojemności 3000 mAh) umieściłem na najwyższej półce. Tam również trafiła przetwornica step-up podnosząca napięcie do 7,4 V. Wiem że lepiej byłoby dać dwie baterie połączone szeregowo, ale w momencie budowania budżet na to nie pozwolił. Szybko okazało się że jedna przetwornica to za mało - Arduino restartowało się przy każdym uruchomieniu silnika, nawet jeśli do układu przyłączyłem bardzo duży kondensator. Dodałem więc drugą - teraz silniki były zasilanie niezależnie od elektroniki sterującej. Pozwoliło to stanąć robotowi po raz pierwszy, jednak wciąż jedna przetwornica zasilająca silniki ograniczała ich moc. Dodałem drugą, co nieco poprawiło sytuację, jednak wciąż nieco ogranicza silniki. Póki co szukam lepszego rozwiązania. Schodząc na niższą półkę. Tam trafiła płytka ze sterownikiem i druga z mostkiem H. Pierwszą płytkę lutowałem sam na płytce uniwersalnej - zajęło to kilka godzin i mnóstwo cyny, ale satysfakcja była nie do opisania, zwłaszcza że wszystkie połączenia wykonałem cyną. Po spędzeniu kolejnej godziny na pozbywaniu się zwarć układ był gotowy do testów Robot aby ustalić swoją pozycję korzysta z modułu żyroskopu i akcelerometru MPU6050 oraz wbudowanych w silniki enkoderów. Dane z tych czujników trafiają do Arduino Nano które poprzez układ L298N steruje dwoma silnikami. Dzięki akcelerometrowi i żyroskopowi robot zna swój kąt przechylenia. W pierwszych wersjach kodu szybko okazało się, że to nie wystarczająco, ponieważ o ile robot stał, to cały czas przesuwał się w jedną stronę. Wynika to z tego że konstrukcja nie jest idealnie wyważona, a robot nie zna swojej pozycji, jedynie kąt nachylenia, więc jeżeli ustawiony na sztywno kąt odbiegał od kąta balansu, robot "dryfował". Aby temu zapobiec dodałem drugie sprzężenie zwrotne, tym razem oparte o enkodery przy silnikach. Enkodery zliczają ilość impulsów które silniki wykonały w każdą ze stron, a oprogramowanie dąży, aby ich różnica była równa 0. Pierwsze próby nie były zbyt udane. Kiedy doprowadziłem kod do stanu w którym robot chociaż próbował się utrzymać, udawało mu się to przez maksymalnie kilkanaście sekund. Jednak wraz z poprawianiem kodu robot stał dłużej i dłużej. Obecnie już się nie wywala, jednak mostek H po dłuższym staniu się przegrzewa, więc czas pracy ograniczony jest do kilku minut. Mimo to robot robi duże wrażenie, chociaż z pewnością nie jest idealny. Zastosowałem tanie chińskie silniki, i jak się okazało, jeden obraca się szybciej niż drugi, więc robot obraca się w jedną stronę. Do tego jak wspomniałem przegrzewa się, a silnikom brakuje momentu, więc robot się trzęsie zamiast stać idealnie prosto. Są to jednak problemy które mam w planach poprawić. Planuję dodać również możliwość sterowania po BT (już nawet na płytce jest miejsce na moduł HC-06), ale na razie nie miałem czasu. Oto filmik prezentujący działanie robota:
  3. 7 punktów
    Witajcie. Chciałbym Wam przedstawić prosty sposób wykorzystania modułu ESP-32, który użyłem do stworzenia urządzenia, za pomocą którego możecie śledzić poziom zainteresowania wybranym repozytorium GitHub. Dzięki wbudowanym dwóm wyświetlaczom, będziecie na bieżąco informowani o: aktualnej liczbie gwiazdek dziennej liczbie gwiazdek aktualnej liczbie obserwujących aktualnej liczbie forków Początkowo chciałem skorzystać ze starszego modułu ESP8266 12-F, jednak napotkałem problem który objawiał się przy wykonywaniu requesta do api GitHub. Podczas oczekiwania na odpowiedź z serwera, na wyświetlaczach zanikały wszystkie cyfry i wyglądało to jakby coś było nie tak z urządzeniem. Z pomocą przyszedł układ ESP-32, który oparty jest na dwóch rdzeniach. Była to świetna okazja aby zapoznać się z tym modułem, ponieważ wcześniejsze projekty wykonywałem na ESP8266. Użycie nowszej odsłony ESP, pozwoliło mi wysyłać requesty asynchronicznie. Do działania ramki wymagane jest połączenie z siecią poprzez WiFi. Tutaj świetnie sprawdziła się biblioteka "WiFi Manager", która umożliwiła mi szybkie podłączenie ramki do dowolnej sieci. Jeżeli chodzi o zasilanie to jest to napięcie 5V, które podaje poprzez wtyki USB. W obudowie ramki znajdują się trzy przyciski. Pierwszy służy jako włącznik. Pozostałe dwa to włączniki chwilowe. Po wciśnięciu pierwszego na wyświetlaczu prezentowany jest adres IP, który wykorzystujemy przy konfiguracji. Natomiast drugi przycisk resetuje liczbę gwiazdek z dnia. Do układu podłączona jest 3 kolorowa dioda LED, która informuje nas o stanie połączenia: CZERWONY – brak sieci, błąd podczas pobierania danych ZIELONY – połączenie sieciowe ustanowione, dane pobrane poprawnie NIEBIESKI – tryb access pointu ( zanik sieci ) Domyślnie odświeżanie danych odbywa się co 90 sekund. Oczywiście interwał można zmienić. Ale należy uważać, aby nie wykonywać do api GitHub więcej niż 60 requestów na godzinę, ponieważ serwer ma ustawiony RateLimit. Po przekroczeniu ilości zapytań zostaniemy zablokowani na godzinę. Jak już wspomniałem wyżej, pod adresem IP jaki przydzielony został do urządzenia działa prosty web server, który serwuje nam stronę z konfiguracją, gdzie musimy wprowadzić nazwę użytkownika repozytorium oraz nazwę repozytorium które chcemy obserwować. Po zapisaniu konfiguracji w pamięci EEPROM urządzenie jest restartowane i gotowe do użycia. Dodatkowym atutem urządzenia jest automatyczna aktualizacja oprogramowania poprzez HTTPS OTA. Sprawdzanie wersji następuje podczas uruchomienia oraz po północy. Urządzenie jest w pełni bezobsługowe. Gdy wystąpi zanik sieci, ESP cały czas będzie próbowało nawiązać połączenie za pośrednictwem zapamiętanych poświadczeń. Jeśli sieć nie będzie dostępna, przełączy się w tryb access pointu ( ssid: "GITHUB-FRAME"). Jeśli nie zostanie wybrana nowa sieć w menadżerze sieci, to po czasie 3 minut, nastąpi restart i proces się powtórzy. Tak pokrótce, wygląda zasada działania całego układu. Poniżej przedstawię Wam główne etapy budowy całej ramki. A więc zaczynamy. LISTA ELEMENTÓW: ESP-32 WROOM DevKit 1.0 – 1 szt. Wyświetlacz LED 4-Cyfrowy TM1637 – 0.56" – 1 szt. Wyświetlacz LED 4-Cyfrowy TM1637 - 0.36" – 1 szt. 4-pinowy przewód, żeński – żeński – raster 2.54 – 4 szt. Gniazdo + wtyk, JST – JST – 2 szt. Gniazdo + wtyk, mikro JST – mikro JST – 2 szt. Płytka uniwersalna PCB 50x70mm PI-01 – 1 szt. Rezystor węglowy – 220 ohm – 5 szt. Rezystor węglowy – 2,2k ohm – 3 szt. Zworki do płytek stykowych - 1 zestaw Wtyk goldpin kątowy 4 pinowy, raster 2,54mm – 4 szt. Dioda LED 5mm RGB wsp. Anoda – 1 szt. Dioda LED 3mm biała – 3 szt. Przełącznik chwilowy okrągły – 10mm – 2 szt. Przełącznik kołyskowy ON-OFF – 1 szt. Kabel USB A – USB micro – 1 szt. Zasilacz 5V z gniazdem USB A – 1 szt. Rurki termokurczliwe - 1 szt. Ramka IKEA RIBBA – 21x30cm ( ważne żeby była dość głęboka, aby zmieścić elektronkę ) – 1 szt. Papier samoprzylepny do drukarki – 1 szt. Rura elektroinstalacyjna RLM 16 – 1 szt. NARZĘDZIA: Lutownica Cyna Obcążki Wiertarka lub wkrętarka Wiertła: 7, 10, 13 Pistolet do kleju na gorąco Nóż Drukarka ZAŁOŻENIA: Stabilność działania Intuicyjna obsługa Szybka adaptacja w miejscu instalacji Estetyka Plan Początkowo ramka miała powstać pod konkretnie wybrane repozytorium i wyświetlać tylko liczbę gwiazdek. Ale stwierdziłem, że i tak pobieram inne dane z endpointa api to czemu miałbym ich nie wyświetlić. Postanowiłem, że dodam dwa nowe klucze: "forks" oraz "watchers" i wyświetlać je kolejno w 5 sekundowym odstępie czasowym. Jeżeli chodzi o repozytorium, to dając możliwość wprowadzenia własnych ustawień url-a, zwiększyłem tym samym skalowalność przedsięwzięcia. Do tego doszły automatycznie aktualizacje software-u. Więc taką ramkę może stworzyć każda osoba, która chociaż trochę ma pojęcie o informatyce i niekoniecznie zna się na programowaniu. BUDOWA Prace nad ramką rozpocząłem od budowy prototypu metodą na "pająka". W tym celu skorzystałem z płytki prototypowej, przycisków typu "tact switch", paru zworek oraz kilkunastu przewodów do połączenia wszystkiego w całość. Całe oprogramowanie zostało napisane za pośrednictwem Arduino IDE czyli w języku C. Gdy miałem już działający prototyp, rozpocząłem prace nad przeniesieniem całości na uniwersalną płytkę PCB. Zadanie wydawałoby się proste ale wymagało procesu planowania. W tym celu wykorzystałem oprogramowanie Fritzing. Oprogramowanie to umożliwia stworzenie całej dokumentacji projektu. Na tę chwilę wykorzystałem tylko narzędzie do stworzenia szkicu płytki prototypowej. Mając gotowy już projekt z rozlokowaniem wszystkich elementów i połączeń. Mogłem przystąpić do lutowania. Jak widać na zdjęciach, podczas montażu elementów używałem uchwytu, który stabilnie trzyma płytkę w miejscu. Bardzo ułatwił mi pracę. Po przylutowaniu wszystkich elementów elektronicznych, wlutowałem przewody z gniazdami, dzięki którym będę mógł odłączyć układ od samej konstrukcji ramki Teraz przyszedł czas na najtrudniejszy etap jakim było dostosowanie drewnianej ramki do potrzeb projektu. W programie Photoshop stworzyłem szablon do wiercenia i wycinania potrzebnych otworów. Szablony te znajdziecie również w repozytorium projektu. Po wydrukowaniu szablonu przykleiłem kartkę do “pleców ramki” i wyciąłem wszystkie otwory. Trochę trzeba się do tego przyłożyć i mieć sporo cierpliwości. Cięcie, pasowanie, cięcie, pasowanie aż do skutku. Ufff. W końcu mogłem przystąpić do zamontowania wyświetlaczy oraz diod LED. Z pomocą przyszedł mi klej na gorąco. Trzyma mocno i pewnie, wystarczająco do tego typu prac. Trzy diody LED umieściłem w przyciętych krążkach z białej rury pcv ( tych do prowadzenia przewodów po ścianach ) a górę zaślepiłem kawałkiem plastiku w którym zamocowałem diody. A tak całość prezentuje się od frontu Za pomocą 4 żyłowych przewodów zakończonych wtykami żeńskimi, połączyłem wszystkie elementy z główną płytką. W celu szybszej identyfikacji przewodów, oznaczyłem każde połączenie za pomocą lakierów do paznokci ( pozdrawiam swoją żonę Magdalenę ). Główny układ przykleiłem do pleców ramki również za pomocą kleju na gorąco. Na koniec pomalowałem cały front na biało farbą emulsyjną, ponieważ papier który używa się w drukarkach ma małą gramaturę co sprawia, że jest półprzezroczysty. Dzięki podbiciu koloru tła biel będzie intensywniejsza. W ostatecznej wersji grafikę wydrukowałem na papierze fotograficznym, który jest na tyle gruby, że malowanie okazało się być zbędne. SOFTWARE Cały program opiera się na dwóch pętlach. Pierwsza pętla Task1, sprawdza czy użytkownik wprowadził url repozytorium z którego mają zostać pobrane dane. Jeżeli konfiguracja została wprowadzona, program wywołuje funkcję getData(), która odpowiedzialna jest za pobranie danych z API. Interwał tej pętli definiuje zmienna requestInterval, która domyślnie posiada wartość 90 ( czyli 90 sekund). Druga pętla Task2, służy do wyświetlania odpowiednich danych na wyświetlaczach oraz podświetlania ikon. Tutaj również sprawdzany jest stan na pinach 27 i 15 ( przyciski BUTTON_IP oraz BUTTON_RESET_TODAY). Interwał tej pętli to około 15 sekund. Po północy następuje sprawdzenie dostępności nowszej wersji oprogramowania oraz resetowany jest licznik gwiazdek otrzymanych w ciągu całego dnia. Poniżej znajdziecie link do repozytorium z projektem: OPROGRAMOWANIE + SZABLONY DO DRUKU PODSUMOWANIE Przyznam się szczerze, że prototyp urządzenia miałem już gotowy rok temu. Ale ze względu na gruntowny remont mieszkania musiałem odsunąć hobby na dalszy plan. Rozciągnięcie projektu w czasie sprawiło, że przy każdym powrocie zawsze coś zmieniałem, rozbudowywałem. Wszystko wtedy można przemyśleć kilka razy i na spokojnie zastanowić się nad rozwiązaniem jakiegoś problemu. Na co dzień zajmuję się programowaniem front-endu, ale dzięki takim projektom mogę połączyć moje główne zainteresowania: majsterkowanie, elektronikę, grafikę i jak już wcześniej wspomniałem, programowanie i stworzyć coś namacalnego i cieszącego oko. Zachęcam wszystkich do twórczego działania i poszerzania swojej wiedzy. Tego typu projekty dadzą Wam satysfakcję, świetną zabawę oraz sporo nauczą. Także klawiatury, lutownice, piły, śrubokręty, wiertarki w dłoń i do działania! Instrukcję już macie Do następnego projektu! Pozdrawiam.
  4. 6 punktów
    Cześć! Skończyłem budowę mojego pierwszego robota. Jest to też mój pierwszy większy projekt, więc proszę o wyrozumiałość, komentarze, porady mile widziane. Z racji tego, że posiadam jeszcze dwa komplety lego, postanowiłem je wykorzystać do budowy pojazdu. Początkowo miały być silniki lego, ale stwierdziłem, że lepiej będzie zrobić to na zwykłych, uniwersalnych częściach. Konstrukcja miała być mała, zwinna, sterowana przez WIFI. Przednia oś, jak widać, sterowana za pomocą micro serwa. Nie było większych oporów, serwo bez problemów sobie radziło ze sterowaniem. Zacząłem szukać jakiegoś ciekawego i małego silnika DC. Postanowiłem wybrać silnik z podwójnym wałem. Kolejnym zadaniem było przebudowanie konstrukcji tak, żeby silnik się zmieścił i nie wadził w poruszaniu się robota. Z racji tego, że wolałem zaoszczędzić kilkanaście złotych na przejściówkę lego-wał, rozwierciłem otwory w częściach które miałem. Zacząłem myśleć jak wyglądałoby połączenie iPhone - ESP, ale w międzyczasie na uczelni dziekan zapowiedział nam dodatkowy projekt na zajęciach z mikrokontrolerów ( pierwsze takie zajęcia na drugim roku studiów ) - dowolny robot na platformie Arduino lub STM. Chłopaki na Facebookowej grupie Arduino uświadomili mi, że nie ma sensu robić projektu na ESP, bo musiałbym się łączyć tylko przez sieć i lepszym wyborem byłby bluetooth. Tak też się stało, zakupiłem moduł HM-10, który współpracuje z używanym przeze mnie iOS. Do tego całość przeniosłem na klona płytki Arduino. Jako aplikacji sterującej użyłem ArduinoBlue, wraz z biblioteką. Inne aplikacje nie chciały działać. W dodatku albo na iOS nie ma żadnych popularnych aplikacji do sterowania przez BLE albo nie udało mi się znaleźć. Możecie polecić ciekawe aplikacje na iOS, na pewno sprawdzę! Można zauważyć, że na breadbordzie zainstalowałem jakąś płytkę. Jest to sterownik silników DC, polecany, łatwy w użyciu. Dobra, silnik jest, działa, serwo jest, łączność przez BLE również. Wypadało by odpiąć wszystko od zasilania z gniazdka i zastosować akumulatory, baterie. Z początku była to dla mnie czarna magia, większe napięcie, jakieś ampery, przetwornice. Czytałem różne artykuły, oglądałem poradniki, pytałem na Facebookowej grupie. Ostatecznie, zgodnie z zasadami: Arduino + sekcja logiczna zasilana z powerbanka + wyprowadzenie zasilania bezpośrednio do serwa, silnik DC zasilany przez dwa ogniwa litowo-jonowe połączone szeregowo z BMS, napięcie zmniejszane przez przetwornicę Żeby szybko podpinać ogniwa do robota albo ładować, przylutowałem wtyki/gniazda DC 5.5mm. BTW. Bardzo długo męczyłem się z lutowaniem ogniw na 30-watowej lutownicy kolbowej. Metodą prób i błędów wszystko się złączyło. Przed podłączeniem każdego elementu lutowanego, sprawdzałem miernikiem czy nie ma zwarcia! Dodatkowo pokusiłem się o popularny czujnik odległości oraz mała prowizorka - dwie diody z opornikami schowane w obudowie po serwie (spaliło się), informujące o przeszkodzie w danej odległości. Wersja finalna, kilkukrotnie większa i cięższa niż pierwotna wersja. Wzmocniony układ kierowniczy. Jeździ, skręca, hamuje, cofa. Trzymany pod kocem Wszelkie komentarze mile widziane! A tutaj krótki filmik (musiałem zdemontować czujnik odległości, ponieważ powodował zakłócenia całego układu: Tak wygląda sterowanie za pomocą joysticka:
  5. 5 punktów
    Dostępne na rynku oczyszczacze powietrza nie kosztują mało. Sam filtr, który wydaje się najważniejszym elementem kosztuje najczęściej nie więcej niż 1/3 oczyszczacza. Postanowiłem więc zbudować własny oczyszczacz. Oczywiście czas poświęcony na budowę też ma wartość, ale nie traktuje tego jako roboczogodziny a po prostu zabawę . W moim przypadku, koszt całości wyniósł około 300zł. Dla porównania, gotowy oczyszczacz Xiaomi to wydatek około 500zł, jesienią było to minimum ~650zł . Kupiłem filtr Xiaomi z wkładem węglowym, który jest nieco droższy niż zwykły, który montowany w fabrycznych oczyszczaczach. Użyty przeze mnie wentylator posiada według producenta wydajność 150m³/h co jest wartością 2x mniejszą niż fabryczny oczyszczacz. Jest to jednak w zupełności wystarczające. Mechanika Oczyszczacz składa się z filtra powietrza, wentylatora 200mm, łącznika filtra z wentylatorem i sterownika. Łącznik został wydrukowany na drukarce 3D. Wentylator to najtańszy wentylator 200mm jaki znalazłem w sklepie komputerowym. Elektronika Całość bazuje na płytce z ESP32. Na niej znajduje się shield prototypowy Arduino, a do niego są zamontowane kolejne elementy. Używałem głównie gotowych modułów. Starałem się w miarę możliwości nie lutować ich bezpośrednio do PCB tylko umieszczać na listwach kołkowych. Schematu niestety nie mam. Wszystko było lutowane na bieżąco w przypływach weny Planuje jeszcze wyprowadzić drugą szynę I2C i podłączyć do niej drugi barometr który będzie umieszczony w wewnętrznej części filtra. Będę mógł w ten sposób zbadać zależność różnicy ciśnień od obrotów wentylatora. Czujniki Jako czujnik pyłu zastosowałem GP2Y1010AU0F. Kluczem była niska cena. Niestety wymaga on dość dokładnego synchronizowania w czasie załączania diody LED i pomiaru napięcia wyjściowego. Z czym miałem duże problemy o czym napiszę niżej. Dodatkowo, jako że jest to czujnik analogowy, jego wyjście skaluje się względem napięcia zasilania. A tak się składa że o ile ESP32 jest zasilane ze stabilnych 3.3V, to czujnik jest zasilany z szyny 5V. Tutaj występuje wyraźny rozstrzał między zasilaniem z zasilacza (wtedy szyna 5V jest zasilana przez diodę która powoduje spadek napięcia) a zasilaniem przez USB. Staram się to kompensować dodatkowym pomiarem napięcia szyny 5V. Nie jest to idealnie, choć daje dużo. Prawdopodobnie czujnik nie skaluje swojego wyjścia idealnie liniowo z napięciem zasilania, stąd ten problem. Oprócz tego na płytce znajduje się czujnik wilgotności HDC1080 oraz ciśnienia BMP280. Oba mają wbudowane termometry, więc nie potrzeba dodatkowego. Teraz prawdopodobnie użyłbym BME280. Interfejs W sterowniku użyłem wyświetlacza OLED. Wyświetlane są na nim aktualne parametry, takie jak: temperatura, wilgotność, poziom zanieczyszczeń, moc wentylatora i inne. Wyświetlacz jest sterowany za pomocą interfejsu I2C. Obok wyświetlacz znajduje się enkoder. Użyłem gotowego modułu bo akurat nie miałem pod ręką tego typu enkodera z przyciskiem. Można nim regulować moc oczyszczacza oraz przełączać między trybami: "auto" i "manual". Oczywiście jak na 2019 rok przystało, oczyszczaczem można sterować też po WiFi :) Na ESP32 jest uruchomiony webserver. Panel webowy wygląda tak: W kodzie znajdują się funkcje które utrzymują stałą łączność WiFi z routerem. Dane dostępowe do znanych nam WiFi należy umieścić w pliku "wifi_credentials.json" i wgrać wraz z innymi plikami. Niestety hasła należy umieścić w formie tekstowej. Biblioteka micropythona do obsługi WiFi nie obsługuje haseł w wersji zahashowanej (PSK). W przyszłości może dopiszę bardziej ludzką formie wprowadzania haseł Sterowanie wentylatorem Z racji tego że użyłem najtańszego wentylatora o tej średnicy, posiada on tylko 3 pinową wtyczkę. Taki wentylator można sterować jedynie napięciowo. Wymyśliłem więc sposób na regulację PWMem napięcia wyjściowego przetwornicy impulsowej. Polega to na podkradaniu lub wprowadzaniu dodatkowego prądu do wyjściowego dzielnika napięcia. Schemat tego wygląda następująco: Zauważyłem że im mniejsza częstotliwość sygnału PWM, tym bardziej nieliniowa jest zależność Vout=f(PWM). Dlatego częstotliwość PWM została ustawiona na 312kHz. Aproksymacje tej funkcji stworzyłem robiąc pomiary Vout w zależności od danego wypełnienia PWM, a następnie w arkuszu kalkulacyjnym wyznaczyłem współczynniki funkcji liniowej. Współczynniki te są na sztywno zapisane w kodzie. Micropython Zdecydowałem się użyć micropythona ze względu na chęć nauki czegoś nowego. Niestety, jak okazało się w trakcie, posiada on wiele ograniczeń. Największą wadą jest używanie blokującego dostępu do interfejsów komunikacyjnych. Przez co np.: w trakcie odświeżania wyświetlacza nie można dokonywać pomiarów czujnika pyłu czy obsługiwać żądań serwera. Ne można też używać drugiego rdzenia ESP32. Przez co interfejs użytkownika chodzi wyraźnie wolno, i nie wygląda na uruchomiony na czymś tak mocnym Cały kod jest dostępny na GitHubie: https://github.com/Harnas/ESP32_Airpurifier
  6. 5 punktów
    O mnie Witam, Jestem Maciej - pracuje jako software architect (nie mam wykształcenia elektronicznego dlatego proszę o wyrozumiałość jeżeli chodzi o połączenia i rozwiązania - z tego też powodu w projekcie nie daje gotowego przepisu na zasilanie ) i żeby do końca nie zgnuśnieć po godzinach tworzę platformę RemoteMe. W platformie chodzi głównie o ułatwienie sterowaniem urządzeniami IoT poprzez internet - bez konieczności posiadania VPNa, publicznego IP. Po stronie RemoteMe tworzycie strony internetowe ( RemoteMe posiada hosting na Wasze pliki ) + zestaw bilbiotek (Javascript, RasbeprryPi (python), Arduino ESP ) które w łatwy sposób pozwolą na komunikowanie się z Waszymi urządzeniami. Co do protokołu to opracowałem własny (bardziej jest to konwencja przesyłu paczek niż protokół jako taki ) (działa przez sockety, websockety, wywoływania RESTowe) - umożliwia on przesył wiadomości do określonego urządzenia, i coś w rodzaju topic- subscribera ( u mnie się to nazwa"variables" zmienne ) Wasze urządzenia rejestrują się w RemoteMe po zarejestrowaniu, możecie do nich wysyłać komendy przez stronę internetową albo z innych urządzeń. Jednym z ostatnich featerów są "Out of the box projects" - polega to na tym, że jednym kliknięciem importujecie projekt na Wasze konto - oczywiście możecie potem wszytko zmieniać wedle własnych pomysłów - właśnie ostatnim takim projektem jest Samochód RaspberryPi z kamerką o którym w tym kursie. Projekt jest częściowo openSourcowy - bilbioteki Javascript, Python, api Restowe są openSource - sam kod serwera i program na RasbeprryPi jest zamknięty. Platformę tworzę sam - po godzinach i udostępniam za darmo O kursie Ten kurs – przedstawia budowę samochodu sterowanego przez przeglądarkę z wyświetlaniem obrazu z kamerki. Jest to dość specyficzny kurs (jak pisałem wyżej ) – całość oprogramowanie jest już zrobiona, a dodanie plików do własnego konta w RemoteMe sprowadza się do paru kliknięć. Po tak dodanym projekcie można własnoręcznie i dowolnie edytować wszystkie pliki źródłowe (strona WWW skrypt pythonowy) – zwłaszcza, że same pliki projektu nie są skomplikowane, a kod jest dość czytelny i samo opisujący się (mam przynajmniej taką nadzieję ) Na dole kursu opisana jest bardziej szczegółowo zasada działania samochodu. Jeżeli nie jesteście zainteresowani samą platformą RemoteMe to i tak myślę, że w kursie znajdziecie garść pomysłów na podobny projekt Kurs właściwy Na filmie działanie + krok po kroku wszystko z tego kursu. W poprzednim kursie pokazałem jak sterować pozycją kamerki i przechwytywać obraz na przeglądarkę tutaj i sterowanie kamerką tutaj . Teraz rozbudujemy ten projekt i zbudujemy samochód z napędem na 4 koła ( sterowany podobnie jak czołg – żeby skręcić prawa para kół musi się kręcić z inną prędkością niż lewa). Taki efekt otrzymamy na wideo też całość kursu – można zaglądnąć, gdy gdzieś utkniecie Części RaspberryPi z wifi ( np zeroW) link Podwozie z silnikami link Sterownik serwomechanizmów na I2C link Kamera do Rpi + taśma jeżeli potrzebna link Dwa SerwoMechanizmy kompatybilne z uchwytem kamerki kamery link Uchwyt na kamerkę z serwami link Mostek H TB6612FNG link Zasialnie – np akumlatory podłączone do przetwornicy – żeby uzyskać odpowiednie napięcie link Połączenia RaspberryPI steruje serwami poprzez moduł PWM i napędem przez ustawianie stanu pinów na mostku oraz dostarczając sygnału PWM poprzez ten sam moduł, który wysyła sygnał do serwomechanizmów. (Dzięki modułowi do generowanie sygnału PWM nie musimy tych sygnałów generować przez samo RaspberryPi – co jest dość problematyczne, poprostu przez I2C przesyłamy odpowiednie instrukcje do sterownika serw (poprzez bibliotekę pythonową dostarczoną przez adafruit), a ten generuje odpowiedni sygnał PWM dla serwo mechanizmów i do mostka H) Schemat połączeń: Poprzez magistrale I2C RPi steruje kontrolerem serwo mechanizmów, dwa ostanie wyprowadzenia kontrolera są podłączone do mostka H, gdzie wykorzystując sygnał PWM ustawiamy prędkość silników. Do mostka H są również podłączone piny RPi które stanami wysokim i niskim będą określać kierunek obrotu silników napędowych – po szczegóły odsyłam do dokumentacji układu TB6612FNG, równie dobrze można użyć mostka L298N lub podobnego. Zaprojektowałem płytkę PCB, którą możecie użyć pliki eagle,gerber itd tutaj plik pcb.zip Schemat płytki pokrywa się ze schematem powyżej. Wyprowadzenia płytki: Wejście sygnału PWM z kanałów 15 i 14 modułu PWM Wejście zasilania silników do poruszania się Zasilanie układów (PWM, RPi) koniecznie dokładne +5V Wyjście silników napędu, pierwsze dwa wyjścia do jednej pary silników kolejne dwa do drugiej Zasilanie serw i w tym przypadku silników napędu w moim przypadku ~6V (należy sprawdzić w specyfikacji serw i silników, jakie maksymalne napięcie można podłączyć) ZWORKA gdy zepniemy dwa piny napięcie z 5 będzie podawane też do zasilania silników napędu ZWORKA gdy jest podłączona zasilane jest RaspberryPI z połączenia 3 przed podłączeniem zworki należy dokładnie sprawdzić napięcia, żeby nie uszkodzić Najdroższego komponentu czyli właśnie malinki Wlutowujemy kabelki, bo nie będziemy korzystali z konwertera stanów Wlutowujemy kabelki, bo nie będziemy korzystali z konwertera stanów Oczywiście jest jeszcze potrzebne odpowiednie zasilanie, w moim przypadku 6v jako napięcie silników napędu i serw, oraz 5v dla RasbeprryPi i kontrolerów. Poniżej kilka zdjęć poglądowych całości samochodu: Programowanie Przed utworzeniem projektu skonfigurujcie kamerkę i komunikacje I2C używając raspi-config opisane tutaj. Ten projekt jest jednym z gotowych projektów, które możecie prosto zaimplementować kilkoma kliknięciami: KLIK - po zalogowaniu otworzy się projekt. Przejdźcie do zakładki “Build It” i podążajcie krokami, na końcu klik w “Build Project” i otrzymacie: Po kliknięciu “Get QR” pokaże się kod QR, który możecie zeskanować smartfonem, lub po prostu otworzyć stronę przyciskiem “Open” w przeglądarce na komputerze. Narazie nie radzę zmieniać pozycji kamery dopóki nie ustawimy pozycji serw – w niektórych przypadkach możecie uszkodzić swoje serwomechanizmy. Samochód powinien jeździć jak na filmie – może się zdarzyć, że skręca w złą stronę albo serwa są źle skalibrowane, poniżej w omawianiu kodu napisałem jak to naprawić. Omówienie tego, co się stało Jak zauważyliście, tworzenie projektu było mocno zautomatyzowane. Dlatego omówię teraz, co się dokładnie wydarzyło i jak modyfikować Wasz projekt. Przede wszystkim utworzyły się dwie zmienne (zakładka variables): Zmienna cameraPos przesyła pozycje kamery, drive pozycje joysticka. Obie są typem “Small int x2” oznacza to, że wartoscią zmiennej są dwie liczby integer. Strona internetowa zmienia nasze zmienne, a skrypt pythonowy te zmiany rejestruje i odpowiednio reaguje (jak rozwiniemy zmienne zobaczymy, że urządzeniem nasłuchującym na zmiany jest właśnie skrypt pythonowy). Zobaczmy jak wygląda kod Pythonowy (więcej o zmiennych tutaj) Python Skrypt pythonowy został automatycznie wgrany. Oczywiście możemy go podejrzeć i modyfikować ( żeby stworzyć nowy skrypt pythonowy np dla innych projektów zobacz tutaj) . Z informacji jakie teraz są Ci potrzebne to skrypt pythonowy to kolejne urządzenie w remoteMe jest zarządzalne przez skrypt (uruchomiony przez ./runme.sh) , do tego urządzenia możemy wysłać wiadomości, urządzenie reaguje też na zmiany zmiennych, które obserwuje i może te zmienne zmieniać. Żeby otworzyć skrypt pythonowy kliknij python.py i wybierz Edit : Wygląda on następująco. Poniżej omówię ciekawsze fragmenty import logging import socket import math import struct import sys import os os.chdir(sys.argv[1]) sys.path.append('../base') import remoteme import Adafruit_PCA9685 import time import RPi.GPIO as GPIO motorAIn1 = 25 # GPIO25 motorAIn2 = 8 # GPIO8 motorBIn1 = 24 # 24 motorBIn2 = 23 # 23 motors = [[motorAIn1, motorAIn2], [motorBIn1, motorBIn2]] motorsPWM = [14, 15] pwm = None; def motorForward(motorId): GPIO.output(motors[motorId][0], GPIO.LOW) GPIO.output(motors[motorId][1], GPIO.HIGH) def motorBackward(motorId): GPIO.output(motors[motorId][0], GPIO.HIGH) GPIO.output(motors[motorId][1], GPIO.LOW) def motorSoftStop(motorId): GPIO.output(motors[motorId][0], GPIO.LOW) GPIO.output(motors[motorId][1], GPIO.LOW) def setMotor(motorId, speed): if speed == 0: motorSoftStop(motorId) elif speed > 0: motorForward(motorId) elif speed < 0: motorBackward(motorId) speed=-speed logger.info("set speed {} for motor {} ".format(speed,motorId)) pwm.set_pwm(motorsPWM[motorId], 0, int(speed)) def onCameraPosChange(i1, i2): global pwm logger.info("on camera change {} , {}".format(i1, i2)) pwm.set_pwm(1, 0, i1) pwm.set_pwm(0, 0, i2) pass def onDriveChange(x, y): logger.info("on drive change x {} , y {}".format(x, y)) global pwm left=y right=y left+=x right-=x delta=(left+right)/2 left+=delta right+=delta # when your car doesnt drive as suppose try to swich right and left variable below # or remove add minuses next to 2 # another way is to switch cables conencted to motors setMotor(0, 2*left) setMotor(1, 2*right) pass def setupPWM(): global pwm pwm = Adafruit_PCA9685.PCA9685() pwm.set_pwm_freq(80) def setupPins(): global GPIO GPIO.setmode(GPIO.BCM) # Broadcom pin-numbering scheme for motor in motors: for pinId in motor: GPIO.setup(pinId, GPIO.OUT) try: logging.basicConfig(level=logging.DEBUG, format='%(asctime)s %(name)-12s %(levelname)-8s %(message)s', datefmt='%d.%m %H:%M', filename="logs.log") logger = logging.getLogger('application') setupPWM() setupPins() remoteMe = remoteme.RemoteMe() remoteMe.startRemoteMe(sys.argv) remoteMe.getVariables().observeSmallInteger2("cameraPos" ,onCameraPosChange); remoteMe.getVariables().observeSmallInteger2("drive" ,onDriveChange); remoteMe.wait() finally: pass Sterowanie silnikami: def motorForward(motorId): GPIO.output(motors[motorId][0], GPIO.LOW) GPIO.output(motors[motorId][1], GPIO.HIGH) def motorBackward(motorId): GPIO.output(motors[motorId][0], GPIO.HIGH) GPIO.output(motors[motorId][1], GPIO.LOW) def motorSoftStop(motorId): GPIO.output(motors[motorId][0], GPIO.LOW) GPIO.output(motors[motorId][1], GPIO.LOW) def setMotor(motorId, speed): if speed == 0: motorSoftStop(motorId) elif speed > 0: motorForward(motorId) elif speed < 0: motorBackward(motorId) speed=-speed logger.info("set speed {} for motor {} ".format(speed,motorId)) pwm.set_pwm(motorsPWM[motorId], 0, int(speed)) Funkcja setMotor dla motorId 1 lub 2 ustawia prędkość speed (może być ujemna). poprostu najperw na odpowiednich pinach ustawiamy odpowiednio stany (ruch do przodu do tyłu, hamowanie), a następnie w zależności od prędkości ustawiamy odpowiednio wypełnienie PWM korzystając ze sterownika serw. def onCameraPosChange(x, y): global pwm logger.info("on camera change {} , {}".format(x, y)) pwm.set_pwm(1, 0, x) pwm.set_pwm(0, 0, y) pass Funkcja setMotor dla motorId 1 lub 2 ustawia prędkość speed (może być ujemna). poprostu najperw na odpowiednich pinach ustawiamy odpowiednio stany (ruch do przodu do tyłu, hamowanie), a następnie w zależności od prędkości ustawiamy odpowiednio wypełnienie PWM korzystając ze sterownika serw. def onDriveChange(x, y): logger.info("on drive change x {} , y {}".format(x, y)) global pwm left=y right=y left+=x right-=x delta=(left+right)/2 left+=delta right+=delta # when your car doesnt drive as suppose try to swich right and left variable below # or remove add minuses next to 2 # another way is to switch cables conencted to motors setMotor(0, 2*left) setMotor(1, 2*right) pass Powyższa funkcja zostanie wywołana jak zmieni się zmienna drive – np po zmianie joysticka na stronie. x,y to po prostu współrzędne wychylenia joysticka (1024,1024) oznacza wychylenie maksymalnie do góry i w prawo. Na podstawie tych zmiennych wyliczamy prędkość lewej i prawej strony samochodu. Jeżeli samochód skręca, zamiast jechać do przodu, jedzie do tyłu zamiast do przodu: setMotor(0, Y2*left) setMotor(1, X2*right) Dajcie minusy w różnych kombinacjach (w miejsca X i Y) do czasu, aż samochód jedzie do przodu – gdy joystick jest wychylony do góry. (będzie to odpowiadać zamianą miejscami przewodów lewej strony dla miejsca Y i prawej strony dla miejsca X). Następnie, jeżeli prawa i lewa strony są zamienione (samochód skręca w złą stronę ), w funkcji powyżej zamieńcie left i right miejscami. def setupPWM(): global pwm pwm = Adafruit_PCA9685.PCA9685() pwm.set_pwm_freq(80) def setupPins(): global GPIO GPIO.setmode(GPIO.BCM) # Broadcom pin-numbering scheme for motor in motors: for pinId in motor: GPIO.setup(pinId, GPIO.OUT) Po prostu ustawiamy odpowiednie piny (te do sterowania mostkiem H) na wyjścia. I tworzymy obiekt do kontrolowania sterowania serw. (Uwaga żeby sterownik serw działał prawidłowo musimy włączyć komunikacje I2C używając raspi-config więcej tutaj ) remoteMe.startRemoteMe(sys.argv) remoteMe.getVariables().observeSmallInteger2("cameraPos" ,onCameraPosChange); remoteMe.getVariables().observeSmallInteger2("drive" ,onDriveChange); remoteMe.wait() Ustawienie RemoteMe i ustawienie jakie funkcję mają zostać wywołane, gdy zmienne do sterowania kamery i napędu zostaną zmienione. To tyle w samym skrypcie pythonowym, jak widzicie, nie jest on zbyt skomplikowany, po więcej informacji zapraszam tutaj Strona WWW Tak naprawdę zostały stworzone dwie strony WWW — jedna do kalibracji druga — strona do sterowania samochodem i wyświetlania obrazu z kamerki. Otwórzmy stronę do kalibracji: Otworzy się strona internetowa z dwoma suwakami. Ustawmy górny i dolny na środkową pozycję – kamera się poruszy- górny suwak powinien poruszać kamerę w osi x, dolny y. Jeżeli się tak nie dzieje – zamieńcie miejscami przewody serwomechanizmu. Następnie za pomocą suwaków ustalcie maksymalne wychylenie osi x i osi y dla mnie jest to: x : 298 – 830 i centralna pozycja. Ważne, żeby centralna pozycja byłą dokładnie pomiędzy przedziałem u mnie ((298+830) /2 = 564) y: 223 – 723 i podobnie centralna pozycja kamery w osi y powinna być w środku przedziału Zapiszmy liczby gdzieś w notatniku i otwórzmy do edycji stronę do sterowania samochodem: <camera autoConnect="true" showInfo="true" class="cameraView"></camera> <connectionstatus webSocket="true" directConnection="false" camera="true"></connectionstatus> <variable component="cameraMouseTrack" type="SMALL_INTEGER_2" style="display:block" name="cameraPos" xMin="298" xMax="830" invertX="true" yMin="223" yMax="723" invertY="true" requiredMouseDown="true" reset="true" onlyDirect="true"></variable> <div class="joystickButtons"> <div class="buttons"> <variable class="gyroscope" component="gyroscope" type="SMALL_INTEGER_2" name="cameraPos" label="Gyroscope Camera" orientationSupport="true" xMin="298" xMax="830" xRange="19" invertX="true" yMin="223" yMax="723" yRange="20" invertY="false" onlyDirect="true"></variable> <variable class="gyroscope" component="gyroscope" type="SMALL_INTEGER_2" name="drive" label="Gyroscope Drive" xMin="-512" xMax="512" xRange="19" invertX="false" yMin="-512" yMax="512" yRange="20" invertY="false" onlyDirect="true"></variable> <button class="mdl-button mdl-js-button mdl-button--raised mdl-js-ripple-effect gyroscope" onClick="toggleFullScreen()">fullscreen </button> </div> <div class="joystickParent"> <variable class="joystick" component="joystick_simple" type="SMALL_INTEGER_2" name="drive" xRange="1024" yRange="1024" onlyDirect="true"></variable> </div> <div style="clear: both;"/> </div> Są to automatyczne komponenty do sterowania samochodem i wyświetlaniem obrazu wideo. Strona, którą otworzyliście zawiera już wszystkie komponenty potrzebne do sterowania waszym samochodem. Jedyne co trzeba zrobić to zmienić zakres ruchów serwo mechanizmów. xMin,xMax,yMin,yMax, zamieńcie na wartości jakie otrzymaliście na poprzedniej stronie z suwakami. Jeżeli chcecie stworzyć własną stronę ze swoimi komponentami najlepiej utworzyć ją od początku pokazane tutaj – pozwoli Wam to dodawać komponenty w przy pomocy kreatora, gdzie ustalicie potrzebne parametry, albo po prostu edytować źródła tej już utworzonej strony – wcześniej warto utworzyć kopię, gdyby coś poszło nie tak (albo skasować pliki i utworzyć projekt jeszcze raz – wtedy nie zapomnijcie wcześniej wykasować też zmienne) Po zmianie wartości x/y/Min/Max możemy otworzyć naszą stronę np w smartfonie, klikamy na index.html, ale tym razem wybieramy opcje get anymous link Następnie, klikamy ikonkę kodu QR, a kod, który się pojawi skanujemy smarfonem. Oczywiście sterowanie działa również poprzez internet – nie tylko w sieci lokalnej, jednak w niektórych przypadkach jest potrzebna dodatkowa konfiguracja więcej o niej tutaj Trochę szczegółów technicznych ( nie obowiązkowe ) RemoteMe serwuję stronę WWW do sterowania Waszym samochodem ( a dodatkowo Was loguje na Wasze konto – stąd token w linku otwieranym przez smartfon ) i uczestniczy w negocjowaniu tworzenia połączenia WebRTC. Połączenie webRTC jest to połączenie bezpośrednie (RaspberryPi – przeglądarka ( w niektórych przypadkach np za NATem jest potrzebny dodatkowo stun sewer)). Po stworzeniu połączenia webRTC stan zmiennych nie jest w ogóle wysyłany do remoteMe (bo pole “onlyDirect” w komponentach jest ustawione na true). Protokołem webRTC przesyłany jest też obraz, a że webRTC tworzy połaczenie point to point opóźnienie jest znikome. Program na RaspberryPi który odpalacie poleceniem ./runme.sh tworzy połączenie websocketowe z platformą RemoteMe oraz zarządza skryptem pythonowym (wysyła do niego wiadomości, przesyła wiadomości ze skryptu dalej do platformy etc ). Działanie skryptu pythonowego jest możliwe dzięki dodatkowym bilbiotekom RemoteMe (znajdują sie w folderze leafDevices/base/ ). Sama strona internetowa po websocketach łączy się do platformy RemoteMe (pozwalają na to skrypty javascriptowe zaimportowane w headerze pliku index.html ze ścieżek /libs/). Ułatwiają i ustanawiają komunikacje z platformą RemoteMe. Same komponenty wstawione w index.html typu : <variable component="**" W funkcjach pliku remoteMeComponents.js są zastępowane na “standardowe” i “bootstrapowe” komponenty htmlowe, dodatkowo do komponentów przypinane są eventy reagujące na akcje użytkownika i wysyłające odpowiednie komunikaty do skryptu pythonowego. Można podejrzeć jak remoteMeComponents.js zamienia i tworzy nowe komponenty – może to być interesujące gdy macie potrzebę stworzenia własnych komponentów, które RemoteMe nie pozwala dodać z kreatora. W większości przypadków akcje Waszych komponentów będą wykonywać zapis zmiennych w postaci RemoteMe.getInstance().getVariables() .setSmallInteger2("cameraPos",123,456,true); która wyśle do skryptu pythonowego informacje o zmianie zmiennej, podobnie sterujemy silnikami ustawiając odpowiednią zmienną. Podsumowanie Tworząc tej projekt chciałem pokazać Wam jak w łatwy sposób sterować Waszym samochodem z widokiem FPV. Projekt można rozbudowywać, lub zmieniać np, gdy korzystanie z innego mostka H niż ja. Zachęcam zatem do eksperymentowania ze źródłami projektu . Gdy jest to Wasz pierwszy projekt, zachęcam do zrobienia na początek projektu z mrugającą diodą i poczytanie dokumentacji na www.remoteme.org Pozdrawiam, Maciej
  7. 5 punktów
    Witam, od kiedy kupiłem swoje arduino (było to ze trzy lata temu) to chciałem zbudować frezerkę do płytek pcb. Obejrzałem w Internecie wiele projektów i w końcu postanowiłem zbudować swoją własną frezarkę :). Pochłonęła ona dużo pieniędzy i jeszcze więcej czasu. Swoje prace zacząłem od kupienia profili 25mmx 1.5mm x 2000mm (dwie sztuki) i kilkanaście kątowników. Wymierzyłem całą konstrukcję i zacząłem składać stelarz stołu a następnie go pomalowałem podkładem i czarną farbą matową. Gdy farba schła zamówiłem wsporniki wałków, wałki fi 12, łożyska oraz kupiłem skleję 10mm na stół. następnym krokiem było położenie blachy na stół żeby nie zniszczyć sklejki potem zacząłem składać oś Z z wałków fi 8 Kilkanaście dni później kontrukcja wyglądała następująco została postawiona brama, została ona wzmocniona zastrzałami z tyły oraz lewa i prawa strona bramy została połączona płaskownikiem stalowym 4mm x 20mm. Cała konstrukcja była bardzo solidna. Pozostało pomalowanie bramy na kolor czarny mat ale to dopiero w wakacje jak zrobi się ciepło Dzisiaj odbyły się pierwsze testy bezpieczeństwo przede wszystkim Całość wymaga oczywiście kalibracji oraz muszę kupić nakrętki bezluzowe na śruby trapezowe. Całość jest sterowana a pomocą GCode. Obszar roboczy to 40cm x 40cm. Elementy potrzebne do budowy to: 4 wałki fi12 (dwa na oś X i dwa na oś Y) 2 wałki fi8 8 wsporników wałków fi 12 4 wsporniki wałków fi 8 profile na stelarz blacha aluminiowa na oś Z trzy zestawy składające się z śruby trapezowej wraz z nakrętką, uchwytem nakrętki, łożyskami samonastawnymi, sprzęgła elastycznego (po komplecie na każdą oś) 3 silniki krokowe 3 mocowania silników arduino 3 sterowniki silnków krokowych CNC shield zasilacz 12V 4A frezy V 20 stopni komplet wierteł od 0.6mm do 1.5mm Potrzebujemy jeszcze silnik do wrzeciona, ja użyłem "pisaka" i dremela. Kosztów nie liczę gdyż nie chcę się załamać ale frajda z budowy była ogromna. Płytki pcb projektuje w Eaglu następnie tworzę gerbery które ląduję do programu flatcam. W tym programie ustawiam wymiary frezu, wierteł i generuje gcode który przesyłam do Arduino za pomocą programu source rabbit gcode sender. Ważna rzecz, przed zaladaowanie pliku drill do flatcamu musimy się upewnić ze każda współrzędna składa się z takiej samej ilości znaków jeśli nie to musimy dopisać odpowiednią ilość zer na początku (tzn po X lub Y ) następnie gdy załamujemy plik drill do flatcamu musimy zmniejszyć skalę tego pliku. Wchodzimy właściwości> scale i ustawiamy na 0.1
  8. 5 punktów
    Witam, jest to mój pierwszy projekt, na którym uczyłem się nieco programowania ... a że w piwnicy leżał mi popsuty odkurzacz to postanowiłem go ożywić po swojemu. Odkurzacz który notabene dostałem jako gratis działał dosłownie 10 minut po czym nie dawał oznak życia. 1.Podwozie jest wykorzystane w 100% z oryginału, nie zmieniałem nic oprócz zrobienia miejsca na elektronikę. 2. Z oryginału wykorzystałem również zasilanie (czyli ogniwa Li-lon) wraz z ładowarką. Zasilanie było oryginalne 7.2 V 3. Elektronika - wykorzystałem Arduino UNO wraz z shield sterownika L293D do 4x silników DC lub 2x krokowych w sumie wykorzystałem taki bo taki miałem, trochę nad wyrost bo zostają nie wykorzystane (a może jeszcze nie wykorzystane) dwa wejścia pod silniki DC. Jako że zaczynałem od podstaw programowanie, przysporzyło mi to trochę problemów. Ale od czego jest forum Na początku udało mi się zrobić aby pojazd sam się poruszał i odbijając od przeszkód (za pomocą dwóch umieszczonych wyłączników krańcowych umieszczonych z przodu odkurzacza) zmieniał kierunek jazdy, nie działało to w 100% tak jak sobie to na początku założyłem, ze względu na ogromny brak wiedzy w programowaniu, ale jednak pierwsze efekty pracy zainspirowały mnie do dalszej pracy nad robotem. #include <AFMotor.h> AF_DCMotor motorP(1); // silnik prawy AF_DCMotor motorL(2); // silnik lewy #define zdL 9 #define zdP 10 void setup() { motorP.setSpeed(255); motorL.setSpeed(255); pinMode(zdP, INPUT_PULLUP); pinMode(zdL, INPUT_PULLUP); } void loop() { bool zderzakL = digitalRead(zdL) == HIGH; bool zderzakP = digitalRead(zdP) == HIGH; // jazda do tyłu if (zderzakL == LOW && zderzakP == LOW) { motorP.run(BACKWARD); motorL.run(BACKWARD); } // // skręt w prawo else if (zderzakL == LOW) { motorP.run(BACKWARD); motorL.run(FORWARD); } // skręt w lewo else if (zderzakP == LOW) { // delay(200); motorP.run(FORWARD); motorL.run(BACKWARD); } // jazda do przodu else { motorP.run(FORWARD); motorL.run(FORWARD); } } Z shelda wykorzystałem piny 9 oraz 10 do serwa jako sterowanie do krańcówek. Kolejną rzecz jaką chciałem zrobić i pobawić się było stworzenie możliwości sterowania odkurzaczem za pomocą bluetooth oraz telefonu z androidem. A więc jak tylko paczuszka ze sklepu pojawiła się w moim domu wraz z modułem bluetooth (2.1 XM-15B 3,3V/5V) postanowiłem działać dalej. Pierwszy problem to połączenie modułu bluetooth z płytką, musiałem dolutować w odpowiednie miejsca przewody aby móc komunikować się z arduino (Rx, Tx) jak również doprowadzenie zasilania. Jednak nie stanowiło to większego wyzwania, udało się za pierwszym razem. Następnie przyszedł czas na połączenie bluetooth z telefonem. Udało mi się to zrealizować również w dość szybkim czasie (wcześniej oczywiście przeglądałem różnego rodzaju poradniki, czy posty kolegów z forum). Przyszedł czas na aplikację do telefonu, jako że gotowe rozwiązania nie podobały się (a może bardziej ambicja wzięła górę) postanowiłem stworzyć coś własnego. Z pomocą przyszła stronka http://ai2.appinventor.mit.edu. Gdzie w sposób prawie że obrazkowy udało mi się zrobił własny interfejs z własna logiką. Przyszedł czas na oprogramowanie w Arduino wszystkich funkcji które chciałem uzyskać tj: możliwość ręcznego sterowania przełączania na tryb automatyczny sterowania prędkością silniczków Udało mi się to za pomocą kodu: #include <AFMotor.h> AF_DCMotor motorP(1); // silnik prawy AF_DCMotor motorL(2); // silnik lewy #define zdL 9 #define zdP 10 String data; void setup() { Serial.begin(9600); Serial.println("Test portu"); pinMode(zdP, INPUT_PULLUP); pinMode(zdL, INPUT_PULLUP); bool zderzakL = digitalRead(zdL) == HIGH; bool zderzakP = digitalRead(zdP) == HIGH; } uint8_t oP = 255; uint8_t oL = 255; int pierwszyStart = 1; void loop() { if (Serial.available() > 0) { delay(1); char znak = Serial.read(); data += znak; pierwszyStart = 2; ///////////// Prędkość silników ///////////// if (data == "X") { oP = oP + 1; } if (data == "x") { oP = oP - 1; } if (data == "Y") { oL = oL + 1; } if (data == "y") { oL = oL - 1; } ///////////// Prędkość silników ///////////// Serial.print("Prędkość silnika prawego: "); Serial.println(oL); Serial.print("Prędkość silnika lewego: "); Serial.println(oP); if (data == "G") { motorP.setSpeed(oP); motorL.setSpeed(oL); motorP.run(FORWARD); motorL.run(FORWARD); } if (data == "B") { motorP.setSpeed(oP); motorL.setSpeed(oL); motorP.run(BACKWARD); motorL.run(BACKWARD); } if (data == "L") { motorP.setSpeed(oP); motorL.setSpeed(oL); motorP.run(BACKWARD); motorL.run(FORWARD); } if (data == "R") { motorP.setSpeed(oP); motorL.setSpeed(oL); motorP.run(FORWARD); motorL.run(BACKWARD); } if (data == "S") { motorP.setSpeed(0); motorL.setSpeed(0); } if (data == "A") { bool zderzakL = digitalRead(zdL) == HIGH; bool zderzakP = digitalRead(zdP) == HIGH; motorP.setSpeed(oP); motorL.setSpeed(oL); // jeżeli oba zderzaki if (zderzakL == LOW && zderzakP == LOW) { motorP.run(BACKWARD); motorL.run(BACKWARD); delay(250); motorP.run(FORWARD); motorL.run(BACKWARD); delay(1150); } // skręt w prawo else if (zderzakL == LOW) { motorP.run(BACKWARD); motorL.run(BACKWARD); delay(100); motorP.run(FORWARD); motorL.run(BACKWARD); delay(100); } // skręt w lewo else if (zderzakP == LOW) { motorP.run(BACKWARD); motorL.run(BACKWARD); delay(100); motorP.run(BACKWARD); motorL.run(FORWARD); delay(100); } // jazda do przodu else { motorP.run(FORWARD); motorL.run(FORWARD); } } data = ""; } else { if (pierwszyStart == 1) { bool zderzakL = digitalRead(zdL) == HIGH; bool zderzakP = digitalRead(zdP) == HIGH; motorP.setSpeed(oP); motorL.setSpeed(oL); // jeżeli oba zderzaki if (zderzakL == LOW && zderzakP == LOW) { motorP.run(BACKWARD); motorL.run(BACKWARD); delay(250); motorP.run(FORWARD); motorL.run(BACKWARD); delay(1150); } // skręt w prawo else if (zderzakL == LOW) { motorP.run(BACKWARD); motorL.run(BACKWARD); delay(100); motorP.run(FORWARD); motorL.run(BACKWARD); delay(100); } // skręt w lewo else if (zderzakP == LOW) { motorP.run(BACKWARD); motorL.run(BACKWARD); delay(100); motorP.run(BACKWARD); motorL.run(FORWARD); delay(100); } // jazda do przodu else { motorP.run(FORWARD); motorL.run(FORWARD); } } } delay(50); } Na pewno nie jest on w 100% zgodny ze sztuką, ale nic dziwnego bo programowania się nie uczyłem. Jest to zlepek funkcji odnalezionych w internecie i przystosowanych do moich potrzeb. Szczerze chciałbym zobaczyć prawidłowy wygląd kodu Na tym chyba zakończę podsumowując że obiekt spełnił moje oczekiwania, a to jest chyba najważniejsze: mogę sterować robotem/odkurzaczem z telefonu przy włączeniu uruchamia się tryb automatyczny bez potrzeby uruchamiania aplikacji w telefonie możliwość włączania/wyłączania na tryb automatyczny z telefonu sterowanie robotem w trybie automatycznym (w przypadku chęci korekty kierunku jazdy) i poza nim odbijanie od przedmiotów Filmik prezentujący funkcjonalność automatycznej jazdy.
  9. 5 punktów
    O czymś podobnym myślałem praktycznie od chwili kupna drukarki. I pewnie dalej bym myślał, gdyby nie projekt na Majsterkowie, opisujący podobną (prostszą) konstrukcję. A i tak przymierzałem się do tego jak pies do jeża, zawsze cos mi przeszkadzało (a to nie potrafiłem rozwiązać problemu zasilania, a to miałem coś pilniejszego do roboty, a to nie miałem jakiegoś tam elementu...). Ale po zrobieniu mojej przystawki do OctoPrinta i (całkiem udanych) próbach druku w wielu kolorach - a co się z tym wiąże koniecznością ręcznej zmiany filamentu w odpowiednim momencie - potrzeba stała się raczej pilna. Zacząłem więc od sprecyzowania założeń. Monitorek miał przede wszystkim wyświetlać aktualne dane na temat wydruku (temperatury, stan drukarki, postęp). Jako że główną jego funkcją miało być zwrócenie uwagi na coś ważnego (np. konieczność zmiany filamentu czy wychłodzenie stołu wystarczające do zdjęcia wydruku) w czasie, kiedy byłem zajęty innymi Wielce Ważnymi Rzeczami (np. oglądaniem najnowszego odcinka przygód bohaterskiego Hannibala Smitha czy innego McGyvera) sygnalizacja powinna być głosowa. Jednocześnie najważniejsze parametry (temperatura i postęp) powinny być wyświetlane w czytelny sposób nawet dla krótkowidza bez okularów - czyli żadne nawet największe cyferki, jakiś pasek postępu w kontrastowych kolorach albo jakiś inny czytelny glif. Zasilanie akumulatorowe (na stoliku przy telewizorze nie mam jak podłączyć zasilacza), z możliwością podłączenia ładowarki. Nadałem więc urządzeniu roboczą nazwę OctoMon, wymęczyłem na forum że ktoś mi wreszcie wyoślił temat ładowarki (dzięki @marek1707!) i zabrałem się do konkretnego projektowania. Miałem już wyświetlacz, moduł ESP8266E i parę innych potrzebnych drobiazgów. Początkowo chciałem ESP umieścić na płytce podłączanej bezpośrednio do pinów wyświetlacza - niestety, jakbym ścieżek nie prowadził i tak jednostronna płytka wychodziła mi za duża. Postanowiłem więc dać sobie spokój, zastosować adapter i użyć po prostu płytki uniwersalnej. Ponieważ tego modelu wyświetlacza już uzywałem, eksperymenty z dźwiękiem też się powiodły (przynajmniej w zakresie wystarczającym do uruchomienia gadacza) - mogłem mieć pewność, że od strony programu nie będę już miał żadnych niespodzianek. Postanowiłem więc zaprojektować całą (niezbyt skomplikowaną zresztą) elektronikę. Jako że akurat w Botlandzie pojawił się moduł MAX9837A postanowiłem go wykorzystać jako DAC i wzmacniacz dźwięku. Niestety nie zdał egzaminu... ale o tym później. Zasilanie rozwiązałem w najprostszy chyba z możliwych sposób. Akumulator połączony z ładowarką, do tego przetwornica MT3608 ustawiona na 5V. Wyświetlacz i DAC zasilane bezpośrednio z 5V, ESP przez stabilizator LM1117, połączony z resztą świata jak na schemacie poniżej. Teoretycznie powinno to działać... ...No i już na wstępie pojawił się problem. Podłączony bezpośrednio (znaczy się kabelkami) do ESP i zasilany z USB moduł dźwiękowy pokazał co potrafi - czyli jak mi zepsuć dobry humor. Z powodów niewiadomych raz działał raz nie... a do tego owo niedziałanie powodowane było chyba fanaberiami motylków w Brazylii albo aktualna pogodą na Marsie. Doszedłem do wniosku, że USB to niespecjalnie dobry sposób zasilania, po prowizorycznym podłączeniu jakichś uczciwych 5V wydawało mi się, że działa. Postanowiłem więc sprawdzić wszystko później już na gotowym układzie. Może się to komuś wydać dziwaczne i ryzykowne... ale miałem w odwodzie sprawdzone rozwiązanie które co prawda dawało niższą jakość dźwięku, ale za to nie okazywało żadnych fanaberii Reszta elektroniki to praktycznie tylko połączenie tego wszystkiego do kupy - mogłem się więc zabrać za projekt obudowy. Nie chciałem się bawić w wymyślanie jakichś skomplikowanych kształtów, a więc obudowa została wydrukowana w kilku częściach i skręcona śrubkami M2. Początkowo urządzenie miało mieć jeden klawisz, ale okazało się, że mam wolne dwa piny GPIO, mogłem więc połączyć dwa. Płytę czołową postanowiłem umieścić pod kątem ze względu na wyświetlacz (który nie lubi jak patrzy się na niego lekko z boku, masz się gapić prosto i już!). Oprócz wyświetlacza miały tam się znaleźć głośnik i klawisze. W sumie więc górna część obudowy wygląda na projekcie tak: Otwory obok głośnika są przelotowe - od zewnątrz jest do nich przykręcona kratka mocująca i osłaniająca głośnik. Mocowanie klawiszy jest dopasowane do ratra płytki uniwersalnej (podobnie zresztą, jak mocowania płytki pod ESP8266). Cała reszta elektroniki oprócz DAC-a została umieszczona w dolnej części obudowy: Oprócz koszyka na akumulator są tam mocowania dla ładowarki, przetwornicy i małej płytki pod ESP. Po złożeniu cały układ wygląda tak: Niestety - po złożeniu wszystkiego w całość okazało się, że DAC nie bardzo chce ze mną współpracować. Co prawda wyczyniał swoje hece to dużo rzadziej, ale jednak. Postanowiłem więc wypróbować inny układ: wzmacniacz (wykorzystana połowa układu) oraz prosty filtr: Okazało się, że działa to całkiem znośnie - prawdopodobnie potrzebna by była jeszcze dodatkowa filtracja na zasilaniu (w głośniku słychać czasem ciche trzaski) ale bez tego już mogłem się obejść. Po złożeniu całość wygląda tak: I tu uwaga: ponieważ wątpię, aby ktoś kto chciałby zrobić to urządzonko miał dokładnie takie same elementy jak ja i identycznie spaczone poczucie estetyki - nie zamieszczam STL-i tylko plik dla OpenSCAD-a. Są w nim zawarte wymiary poszczególnych elementów i może być przydatny. No i kilka słów o programie. Program łączy się z serwerem OctoPrint i okresowo odpytuje o stan drukarki i (w przypadku gdy jest to drukowanie) o postęp. Oprócz podstawowych stanów sygnalizowanych przez serwer odróżniane są: Offline - drukarka jest wyłączona lub serwer nie odpowiada Rozgrzewanie stołu Rozgrzewanie dyszy Studzenie stołu - gdy po zakończeniu drukowania temperatura jest nie niższa niż 30°. Wciśnięcie pierwszego klawisza w trybie pauzy powoduje, że monitorek przestanie się odzywać. Bez tego co chwila będzie krzyczał że masz zmienić filament. W trybie studzenia powoduje przejście w tryb bezczynności. Wciśnięcie drugiego klawisza spowoduje podanie głosowo godziny. Dłuższe wciśnięcie pozwala na zmianę gadatliwości programu. Serwer WWW pozwala na zmianę wszystkich ważnych parametrów w dowolnej chwili. W trybie "drukowanie" wyświetlane są informacje o temperaturze dyszy i stołu, postępie w procentach oraz czasu dotychczasowanego i prognozowanego. Dodatkowo wyświetlane są: Adres IP monitora Bieżąca godzina Stan naładowania akumulatora Poziom gadatliwości (tylko wydarzenia/postęp/postęp i pozostały czas) Włączenie OTA Siła sygnału WiFi W trybie Offline monitor zachowuje się jak zegarek - wyświetla bieżące godzinę i datę Jeśli w czasie resetu urządzenia przytrzymamy pierwszy klawisz, startuje ono w trybie AccessPoint. Pod podanym adresem zgłasza się serwer WWW, gdzie można zapisać wszystkie potrzebne parametry. Jeśli w czasie resetu urządzenia przytrzymany drugi klawisz, startuje ono w trybie awaryjnym. W tym trybie nie będzie działać nic oprócz OTA. Przydatne, jeśli coś tak naknocimy w programie że nie będziemy mieli dostępu do OTA w normalnym trybie. Program został napisany z pomocą Arduino IDE. Biblioteka syntezy mowy jest na githubie. Pozostałe biblioteki instalowane były "po bożemu" poprzez managera bibliotek. Syntezator mowy to zwykły syntezator formantowy (użyłem w większości oryginalnego kodu D. Klatta z początku lat 80-tych), dostosowany kiedyś przeze mnie do języka polskiego. Dostosowanie nie jest może najlepsze - ale i syntezator Klatta nie jest mistrzem dykcji Kalibrację miernika poziomu akululatora należy przeprowadzić włączając opcję DEBUG w Octomon.h i podając w pliku wifi.cpp adres i port , na którym będziemy odbierać komunikaty UDP. Należy do wejścia przetwornicy podłączyć woltomierz, odczytać komunikat "Volts=..." i w pliku "display.cpp" w funkcji displayBattery() w linijce: ivolt = ivolt * 413 / 753; podstawić właściwe wartości (czyli napięcie akumulatora w setnych wolta oraz wartość odczytaną a przetwornika A/C). W moim przypadku jak widać woltomierz podał 4.13V a przetwornik zinterpretował to jako wartość 753 Aby program działał, należy w Arduino IDE ustawić zegar 160 MHz, tryb pamięci QIO oraz częstotliwość Flash 80 MHz. Dołączony programik bmconvert.py pozwala na zapisanie jako tablicę w C obrazka PNG. Obrazek powinien być zapisany w trybie indeksowanej palety kolorów bez przezroczystości, będzie przetworzony na skompresowaną w RLE tablicę, a do jego wyświetlenia należy użyć funkcji drawBitMap() z pliku display.cpp (lub analogicznej). Sprawdzony na Linuksie, ale powinien działać na wszystkim gdzie się da zainstalować Pythona 2.7 i PIL. Urządzenia używam od jakichś dwóch tygodni, na razie jest bardzo przydatne. octomon.zip
  10. 5 punktów
    Miniaturowy Tetris z pięcioma przyciskami, głośniczkiem Piezo i ekranem Oled 128×64. To wszystko przy zaledwie sześciu dostępnych GPIO jednodolarowego Digisparka/ATtiny85. Moja wersja kodu dodaje kilka ulepszeń, które znacząco zmieniają odbiór całej gry (opisane niżej), a koszt budowy całego zestawu wynosi około 15 zł. ATtiny Tetris Gold Multi Button obsługuje narastający poziom trudności (przyspieszanie opadania wraz z usuwaniem kolejnych linii), informację o klocku pojawiającym się w kolejnej turze, podpowiedź o pozycji klocka w dolnej partii planszy, pełną pseudo-losowość doboru klocków, dźwięki i temat muzyczny z oryginalnej gry. Poniżej mój filmik prezentujący ten układ w działaniu: W filmie można zobaczyć krótkie urywki z rozgrywki, proces instalacji szkicu w urządzeniu oraz pełny, pięciominutowy gameplay. Sprzęt Jakiś czas temu zainteresowały mnie klasyczne gry retro dla ATtiny85, ale w repo Attiny-Arduino-Games wszystkie były zaledwie dwu-przyciskowe. Tetris wymagał nieco więcej logiki, ale i tak obsługiwało się go przez naciskanie lub przytrzymywanie jednego z tylko dwóch przycisków, co generowało błędy i nie było zbyt wygodne. Z czasem jednak pojawiła się w repo wersja Tetris Multi Button, w której rozwiązano ten problem wykorzystując odpowiednią kombinację rezystorów i przycisków, dzięki czemu podłączono trzy przyciski pod jeden pin mikrokontrolera. Nie posiadam czystego ATtiny85, ale miałem na stanie Digisparka z tym chipem i postanowiłem złożyć to urządzenie. To chyba pierwsze nagranie wideo takiego zestawu - w sieci brak w sieci brak filmów i opisów wykonania pełnej, pięcio-przyciskowej wersji. Żeby się nie pogubić podczas montażu , korzystając z rozpiski pinów Digisparka i ATtiny85 przeniosłem dostarczony ze sketchem poniższy schemat: na lekko chaotyczną wersję graficzną dla stykowej płytki prototypowej i Digisparka zasilanego baterią 9V: a przy okazji też dla czystego ATtiny85 zasilanego baterią 3V: Poszczególne przyciski odpowiadają za: start nowej gry lub restart aktualnie rozgrywanej, włączenie/wyłączenie układu, obrót, przyspieszenie opadania, przesunięcie w lewo, przesunięcie w prawo. Przytrzymanie przycisku opadania i włączenie restartu gry aktywuje tryb ducha, a przytrzymanie przycisku opadania razem z przyciskiem obrotu podczas restartu ustawia trudny poziom gry, wypełniając dodatkowo błędnie klockami część planszy. Po aktywacji tych opcji grę należy uruchomić przyciskiem przyspieszonego opadania. Wersja na czystym ATtiny85 potrzebuje tylko 3V, bo sketch jest pisany dla obniżonego do 8MHz taktowania zegara. Wersję dla Digisparka zasilam poprzez pin VIN 9V baterią i przy takim poborze wystarczy jej na baaardzo długo. Wymagane do działania 5V przenoszę dodatkowym, pustym goldpinem na lewą stronę płytki prototypowej za pomocą dziesięciocentymetrowego przewodu połączeniowego żeńsko-męskiego. Po zlutowaniu powyższego układu w połączeniu z gołym ATtiny85 i po ubraniu go w miniaturowy brelok do kluczy, koszt (bez baterii) zamknąłby się poniżej 15 złotych. Na Aliexpress ATtiny85 kosztuje 0,80$, ekran Oled 128×64 1.80$, mały piezo buzzer 0,17$, a reszta części to już koszty groszowe. Tym sposobem otrzymujemy pełną grę sterowaną w identyczny sposób, jak w wielkich automatach Arcade lata temu, a do tego zasilaną malutką baterią 3V. Do zestawu zamiast białego ekranu można wybrać ekran niebieski lub żółto-niebieski, ale ponieważ ten ostatni jest dzielony na dwie różne części z odstępem, to nie prezentuje się zbyt atrakcyjnie (co widać na powyższym filmie) i polecam jednokolorowy odpowiednik. Potencjalny brelok mógłby wyglądać tak, jak na obrazku poniżej: Kod Zmiany w kodzie, których dokonałem, nie są duże, ale znaczące w odbiorze gry. Poniżej różnice między moją wersją, dostępną na GitHubie, a oryginałem gry dla ATtiny85: Dodałem losowość doboru klocków – domyślnie ATtiny Tetris generuje tę samą sekwencję klocków w każdej nowej grze, bo użyta funkcja random korzysta w kółko z tej samej tablicy liczb losowych. Programiści nie aktywowali randomSeed, ponieważ wszystkie piny w układzie są już podłączone. Moja wersja przesuwa tablicę liczb pseudo-losowych po każdym rozpoczęciu gry inkrementując seed do EEPROMu i aktywując w ten sposób pełną pseudolosowość doboru klocków (powtarzają się tylko pierwsze dwa). Grając w oryginalną wersję, do piątej linii miałem już ustalony optymalny schemat położenia klocków, przez co gra stawała się nudna. Teraz jest już poprawnie i mam świadomość, że wykorzystanie EEPROMu w randomSeedowaniu ograniczy liczbę rozgrywek do zaledwie 99000 (podana liczba uwzględnia już obecny w kodzie zapis najlepszych wyników również do EEPROMu). Na starcie gry dodałem fragment tematu muzycznego z oryginalnej gry Tetris z 1986 roku – domyślnie brak jakiejkolwiek muzyki w grze. Po wybraniu trybu ducha temat muzyczny jest nieco dłuższy. Dodałem dźwięk opadającego klocka (tylko podczas swobodnego spadania) oraz inny dźwięk dla klocka, który kończy opadanie. Domyślnie dźwięki w tej grze pojawiają się sporadycznie – tylko podczas usunięcia pełnej linii klocków oraz na zakończenie gry. Naprawiłem część błędnie wyświetlanych fontów na ekranie startowym Domyślnie wyłączyłem tryb ducha, który wyświetla podpowiedź o docelowej pozycji klocka. Tryb ducha można aktywować sposobem opisanym powyżej pod konfiguracją przycisków. Ze swoimi zmianami musiałem się zmieścić w sześciu procentach wolnej pamięci. Obecnie pozostaje już tylko 1% wolnego Projekcik jest dość interesujący i co najważniejsze, w pełni użyteczny, więc możliwe, że znajdą się osoby chcące zbudować taki układzik. Jako dodatek zamieszczam więc proces instalacji. Instalacja Kod zabiera blisko 100% pamięci ATtiny85, więc na Digisparku nie mieści się bootloader i nie można uploadować sketcha poprzez USB – należy więc skompilować hexa i wgrać go za pomocą programatora ISP. Jako programatora użyłem Arduino wg poniższego schematu: Na Arduino trzeba wgrać dostępny w przykładach Arduino IDE sketch ArduinoISP. Aby poprawnie skompilować tę wersję dla Digisparka należy w Arduino IDE zastąpić dodatkowy adres URL dla menadżera płytek od Digistump JSONem dla czystego ATtiny85, a następnie wybrać płytkę ATtiny25/45/85, procesor ATtiny85, zegar Internal 8MHz. Następnie z menu szkic eksportować skompilowany program, który zostanie wtedy umieszczony w katalogu źródła sketcha. Na koniec zostaje już tylko wgranie hexa na Digisparka poprzez Arduino programem avrdude. Poniżej przykładowe polecenie kopiujące (z fusami) wykonane na macOS, ale w innych systemach wygląda podobnie: /Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avrdude -C/Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf -v -pattiny85 -cstk500v1 -P/dev/cu.usbmodem14101 -b19200 -Uflash:w:/Users/username/Documents/ATtiny-Tetris-Gold/ATtiny-Tetris-Gold.ino.tiny8.hex -U lfuse:w:0xF1:m -U hfuse:w:0xD5:m -U efuse:w:0xFE:m Jak przebiega taki proces można obejrzeć na końcu powyższego filmiku. Poniżej też zdjęcie "programatora" i układu obok siebie. W filmie i na zdjęciach do włączania układu korzystam z przełącznika suwakowego SS22T25, ale lepiej sprawdził się przełącznik prosty ESP1010. Napięcia na przyciskach są istotne i podczas gry trzeba uważać aby nie dotykać rezystorów Ten problem wyeliminuje się po zlutowaniu układu. Najlepszy wynik gry jest również zapisywany w EEPROMie. Ponieważ głośniczek jest podłączony do pierwszego pinu Digisparka, to dodatkowo otrzymujemy LEDowe sygnały świetlne w momencie odtwarzania dźwięków. Po zakończeniu gry Tetris natychmiast przechodzi w tryb uśpienia z minimalnym poborem prądu, jednak do Digisparka dodałem przełącznik włączający/wyłączający zasilanie dla układu – wersja opierająca się wyłącznie na ATtiny85 nie wymaga wykonania tego kroku. Gra chodzi bardzo płynnie, co widać na powyższym filmie, gdy przytrzymuję przycisk przyspieszonego opadania dla kilku klocków pod rząd. Miniaturowy ATtiny Tetris Gold jest bardzo regrywalny (nie nudzi się) i to niesamowite, że udało się go upchnąć na tanim ATtiny85 przy zachowaniu tak dużej funkcjonalności. Serdecznie polecam montaż tego prostego układu. Powiększenia układów i trochę więcej informacji można znaleźć na moim blogu: http://jm.iq.pl/tetris
  11. 4 punkty
    Cześć wszystkim. To mój pierwszy temat na tym forum, Więc przy okazji witam wszystkich Pokaże wam dzisiaj bardzo prosty sposób wykorzystania Raspberry Pi jako konsoli do gier, ja osobiście dzięki temu projektowi zacząłem interesować się elektroniką. O ile sama elektronika nie jest tutaj zbyt zaawansowana to będziemy potrzebować minimalnych umiejętności posługiwania się elektronarzędziami. Zaczynamy. Na początku potrzebujemy Raspberry Pi, Ja osobiście użyłem Raspberry Pi 3 B+ ponieważ pozwala nam zagrać w gry z lepszą grafiką, nawet niektóre tytuły z PSP, jak i w miarę wygodnie korzystać z przeglądarki internetowej. Możecie jednak bez problemu korzystać ze słabszych wersji. Oprogramowanie naszej konsoli znajdziecie w tym linku Retropie możecie też użyć podobnej wersji oferującej praktycznie to samo z tego linku Recalbox Jednak w tym poradniku skupię się na tej pierwszej. Porównanie obu znajdziecie na Youtube. Na temat instalacji samego oprogramowania nie będę pisał bo jest to dość proste i wszystko znajdziecie w tym linku instalacja Powiem jedynie żeby oprócz konsoli nie zapomnieć o możliwości przejścia do Rasbiana, znajdziecie też filmy jak uruchomić dodatkowe konsole i wgrać kodi. O ile tutaj wszystko jest jasne, to trudniejsza częścią jest zabudowa naszej konsoli. Osobiście użyłem Starego automatu który znalazłem na śmietnisku .Nie była to maszyna do gier arcade, a tak zwany jednoręki bandyta, taki jak jak na zdjęciu numer 2 (niestety nie mam zdjęcia jak wyglądał przed). Jednak nie każdy ma do takiego dostęp dlatego wrzucam wymiary mojej, byście mogli wyciąć taką np ze sklejki i poskładać samemu. Jeśli jest to dla was za duży kawał mebla to znajdziecie w na Youtube czy w Google projekty trochę bardziej poręcznych, ale już nie robiących takiego wrażenia. Jako że ja swoją przerabiałem musiałem najpierw zrobić w naklejce na szybie wycięcie na monitor (17cali od starego komputera) i pozbyć się pozostałych w środku resztek starego systemu. Później musimy zamontować przyciski i joystick, są w pełni kompatybilne z konsolą. W moim przypadku zostawiłem 2 działające przyciski Start i Payout z oryginału. Mała rada by przedni panel zrobić otwierany, w przypadku drobnych modyfikacji nie musimy odsuwać szafy od ściany. Trzeba zadbać teraz o audio, u mnie sprawę załatwia mała wieża podłączona pod Raspberry, z oddzielnym wyjściem aux by podłączyć telefon. Otwory na głośniki należy wyciąć w płycie. Nie zapomnij o wnetylatorach i otworach wentylacyjnych. Ponieważ w zamkniętej obudowie potrafi się zrobić gorąco. Ładnie pochowaj, wyprowadź kable i zamontuj raspberry. W przednim panelu zamontowałem atrapę komputera dla wyglądu. Wyprowadź też kable usb by można było podłączyć pady. Ja schowałem je w miejscu na wypłatę monet. W schowku na dole jest szuflada na różne rzeczy jak i mała schładzarka do napojów. Do tego użyłem podobnego zestawu zestawu chłodzącego. Daję radę, ale bardziej do podtrzymywania zimnej temperatury, max udało mi się osiągnąć 13 stopni dlatego polecam użyć większego, trochę droższego zestawu. Schładzarkę należy czymś wyłożyć by zapewnić izolację i w miarę szczelnie zamknąć by nie uciekała nam temperatura. Ja użyłem starej karimaty ale są na pewno lepsze sposoby. Naszą szafę dobrze jest wyłożyć matami głuszącymi dla cichej pracy. Na końcu montujemy Ledy. Projekt można rozwijać o np. licznik monet, panel dotykowy i co tylko przyjdzie do głowy. W przyszłości mam zamiar poprawić lodówkę by działała lepiej, zmienić monitor i dodać trochę więcej przycisków. Mam nadzieję że projekt wam się podoba. Czekam na wasze sprzęty grające.
  12. 4 punkty
    Co to jest timelapse? W razie, gdyby ktoś nie wiedział, co mało prawdopodobne, ale jednak - jest to przeciwieństwo slow-motion, czyli film, który jest kilka albo kilkanaście razy przyspieszony. Filmy takie pozwalają obejrzeć zjawiska, które ze swojej natury są bardzo wolne, na przykład wyrastanie ciasta, płynięcie chmur na niebie, rośnięcie roślin i tak dalej. Nagranie timelapse nie jest jakimś wielkim wyczynem, bo większość aparatów i kamerek sportowych ma taki tryb wbudowany, a na telefony komórkowe istnieją tysiące aplikacji realizujących takie właśnie nagranie. Do czego więc może służyć maszyna do timelapse? Najbardziej podstawową wersją timelapse jest oczywiście nieruchomy kadr - ustawiamy kamerę na statywie, uruchamiamy proces nagrywania i zostawiamy wszystko na odpowiedni czas. Filmy takie same w sobie robią już wrażenie, ale znacznie ciekawiej jest, gdy kadr jest zmienny, na przykład gdy zastosujemy panoramowanie (czyli powolny obrót) albo liniowe przesunięcie. Kłopot polega na tym, że obrót taki musi być realizowany bardzo wolno - w tempie dopasowanym do tempa robienia zdjęć. 45 stopni to być może dużo, ale jeżeli kamera ma zarejestrować, powiedzmy, 40 minut materiału przy 30 klatkach na sekundę, to mamy prędkość obrotu rzędu 45/(40*60) = 0,01875 stopnia na sekundę. Żeby było trudniej, kamera musi obracać się płynnie, bo timelapse będzie wyraźnie poszarpany. Do czegoś takiego trzeba już dedykowanego urządzenia: kupionego albo - co znacznie ciekawsze - zrobionego samodzielnie. Komponenty Tym razem kontrolerem stało się Arduino Uno, między innymi dlatego, że razem z shieldem z wyświetlaczem i klawiaturą zapewniło dosyć niskim kosztem interfejs użytkownika. Płynny i w pełni kontrolowany obrót zapewni silnik krokowy, a ten konkretny, czyli SY35ST26-0284A wybrałem w dużej mierze dlatego, że można go zasilić bezpośrednio dwucelowym akumulatorem LiPo. Do silnika należało oczywiście również kupić odpowiedni sterownik. Oprócz tego wyposażyłem się też w obudowę - być może efekt końcowy nie powala estetyką, ale bardzo nie lubię kończyć projektów z gmatwaniną sterczących przewodów i po ukończeniu jeżdżącego robota stwierdziłem, że będę dbał również o wygląd moich projektów. To nie był koniec zakupów - silnik krokowy oferuje 200 kroków na obrót, co daje 1,8 stopnia na krok. Tymczasem ja potrzebowałem stukrotnie większej dokładności, dlatego konieczne było zbudowanie przekładni zębatej. Zębatki Z przekonaniem, że w Internecie można znaleźć wszystko zacząłem szukać zębatek i okazało się, że wcale nie tak łatwo jest znaleźć zębatki do takiego projektu. Byłem ograniczony ich rozmiarem oraz sposobem montażu - nie posiadając wtedy drukarki 3D (na której pewnie sam wydrukowałbym potrzebne koła), miałem też ograniczone możliwości związane z montażem komponentów. W akcie desperacji napisałem email z zapytaniem ofertowym do krakowskiej firmy, która specjalizuje się w produkcji kół zębatych, ale koszty rzędu (o ile dobrze pamiętam) 800 PLN za cztery koła zębate przekraczały wielokrotnie mój budżet na ten projekt. Wróciłem więc do poszukiwań i w końcu znalazłem odpowiednie koła zębate w sklepie conrad.pl. Kupiłem dwa czterdziestozębowe i dwa trzydziestozębowe - w przypadku, gdyby te pierwsze nie zmieściły się wewnątrz obudowy. Oprócz tego kupiłem jedną piętnastkę oraz dwunastkę - ta ostatnia miała otwór na oś pasujący do kupionego przeze mnie silnika krokowego. Przekładnia Teraz musiałem zaprojektować przekładnię - skorzystałem w tym celu z darmowego Solid Edge Drafting - świetnego dwuwymiarowego cada. Pomierzyłem wszystkie przestrzenie suwmiarką i wyszło na to, że przekładnia zmieści się w całości w przedniej, podwyższonej części obudowy. Nie dysponuję żadną maszyną CNC, ale otwory w aluminiowych płytkach musiałem zrobić bardzo dokładnie, bo inaczej zębatki nie zazębiłyby się (w jedną albo drugą stronę) albo obracały ze zbyt dużym oporem. Wpadłem więc na pomysł - wydrukowałem układ otworków w obu płytkach przygotowany wcześniej w cadzie na papierze samoprzylepnym i przykleiłem go na obrabianym aluminium. Potem dociąłem płytki zgodnie z ramkami i wywierciłem otwory w oznaczonych miejscach - okazało się, że taka dokładność była wystarczająca i wszystko ładnie wskoczyło na swoje miejsca. Montaż Po zbudowaniu przekładni nie zostało już zbyt dużo do roboty - zamontowałem wewnątrz obudowy Uno z shieldem LCD, podłączyłem do przygotowanej wcześniej płytki prototypowej ze sterownikiem silnika, a do niej sam silnik. Potem skręciłem wszystko i dostałem (w miarę) zgrabne urządzenie. Programowanie Na potrzeby tego projektu napisałem specjalnie własny zestaw bibliotek, które ułatwiają budowanie wielopoziomowych menu na shieldzie LCD. Programik jest stosunkowo prosty - należy obrócić silnik w położenie źródłowe i docelowe, ustalić czas obrotu - i uruchomić. Program oblicza o jaki kąt obrócić silnik w jakim czasie i powolutku obraca oś z jednego położenia do drugiego. Ponieważ program z bibliotekami jest dosyć duży, nie będę go tu zamieszczał, ale można go ściągnąć z mojego repozytorium na gitlabie. Efekty Czy cel został osiągnięty? Definitywnie tak - nagrane filmy poddaję niewielkiej obróbce w VirtualDub (korzystam z plugina o nazwie deshaker), żeby odrobinę poprawić ich jakość, ale nawet i bez tej obróbki filmiki wyglądają całkiem przyzwoicie. Przykładowy poniżej: Wnioski Po pierwsze, maszyna jest niestety przeraźliwie głośna. Obracanie (przynajmniej na początku, podczas ustawiania zakresów) osi generuje dźwięk przypominający skrzyżowanie kosiarki do trawy i piły łańcuchowej. Winne są najprawdopodobniej pancerne zębatki oraz luzy na osiach - teraz, mając już drukarkę 3D, wydrukowałbym sobie wszystko z PLA spasowane do dziesiątych milimetra, podczas budowy tego urządzenia skazany byłem jednak tylko na własne ręce i montaż przekładni na pewno nie jest tak dokładny jaki mógłby być. Poza tym warto byłoby rozważyć również zastosowanie mniejszych, plastikowych zębatek, tylko obawiałem się trochę, czy będę w stanie zamontować je pewnie do osi - tak, by nie wyrobiły się i nie zaczęły obracać w miejscu. Plusem tej przekładni jest natomiast fakt, że jest po prostu pancerna - myślę, że spokojnie mógłbym zamontować na niej lustrzankę z solidnym obiektywem i ani przekładnia ani silnik nawet by nie sapnęły. Zdecydowanie warto było zainwestować w obudowę - kosztowała mnie raptem 15 złotych, a znacząco podniosła estetykę projektu (i przynajmniej w pewnym stopniu chroni elektronikę przed warunkami atmosferycznymi i kurzem. Wbrew pozorom dosyć wygodne okazało się zasilenie urządzenia z zewnątrz - wyprowadziłem sobie ze środka kabelek zakończony wtyczką T-Dean i gdy chcę uruchomić narzędzie, po prostu łapię jeden z dwucelowych akumulatorów LiPo walających się gdzieś po domu i maszyna może na nim działać naprawdę długo. Choć urządzenie powstało już jakiś czas temu, nie użyłem go jeszcze zbyt wiele razy; tak naprawdę zbudowałem je pod kątem filmowego projektu, który mam zamiar nakręcić, ale wymaga on dosyć dużo czasu w plenerze, a tego zasobu od jakiegoś czasu niestety trochę mi brakuje. Ale też nie tracę nadziei - być może za kilka lat zrealizujemy go razem z córką? Czas pokaże...
  13. 4 punkty
    Trudne początki Tak naprawdę to jest chyba mój pierwszy projekt w świecie Arduino! Zamarzyłem sobie zbudowanie własnego, terenowego pojazdu zdalnie sterowanego - takiego, na którym można potem zamontować jakiś chwytak, ramię albo kamerkę z przekaźnikiem FPV. Kontroler Tu akurat nie miałem większego wyboru, bo wtedy pod ręką miałem akurat Arduino Leonardo. Zaletą tej płytki jest kompatybilność z popularnymi shieldami do Uno a także złącze microUSB typu B (zamiast mało popularnego złącza "drukarkowego" w Uno). Na potrzeby tego niezbyt skomplikowanego projektu moc obliczeniowa tej płytki jest również całkowicie wystarczająca. Podwozie Moim planem było zbudowanie definitywnego i niepokonanego łazika marsjańskiego, więc zwykłe podwozie nie wchodziło w grę - koniecznie musiało być terenowe. Przegrzebałem naprawdę połowę Internetu w poszukiwaniu tego idealnego podwozia (ale - nie ukrywajmy - mieszczącego się również w moim budżecie) i w końcu mój wybór padł na podwozie Dagu DG012-ATV z napędem na cztery koła. Nieco podwyższony prześwit w stosunku do innych podwozi (dający nadzieję na pokonywanie niewielkich przeszkód), napęd na cztery koła - wszystko to brzmiało bardzo zachęcająco. Czterema silnikami coś oczywiście musi obracać, razem z podwoziem nabyłem więc również czterokanałowy sterownik silników DFRobota (w postaci shieldu dla Arduino). Serwo i czujnik Żeby urozmaicić nieco projekt, dodałem do niego serwo modelarskie, na którym zamontowałem ultradźwiękowy czujnik odległości z założeniem, że spróbuję kiedyś napisać program do autonomicznego poruszania się. RC Od długiego czasu używam do zdalnego sterowania aparatury FrSky Taranis, więc oczywiście musiałem skorzystać z kompatybilnego odbiornika - w tym przypadku X8R. Zasilanie Projekt oczywiście musiał być mobilny, więc zdecydowałem się na zasilenie go dwucelowym akumulatorem Lipo; konieczne okazało się też zastosowanie układu BEC, który obniżył napięcie akumulatora do 5V. Teraz pozostało już tylko zmontować wszystko w całość. Montaż podwozia Tu obyło się bez niespodzianek i problemów, po prostu skręciłem wszystko zgodnie z instrukcją i wyprowadziłem na zewnątrz przewody, którymi zasilane miały być silniki. Potem sprawy nieco się skomplikowały. Wszystko rozbiło się generalnie o to, że jak bym nie ułożył elementów na podwoziu, po prostu nie było takiego ułożenia, żeby wszystko się zmieściło. Sprawy utrudniał również fakt zastosowania Leonardo, które - umówmy się - jest raczej kobylaste i znacznie lepiej sprawdziłoby się tu kompatybilne z tą płytką Arduino Micro. Do tego dochodził BEC, odbiornik, serwo (którego nota bene nie miałem jak zamocować, bo w wersji 4WD podwozia miejsce na serwo zajmowane było przez dwa dodatkowe silniki) no i oczywiście akumulator. Dlatego zdecydowałem się na umieszczenie wszystkiego ponad podwoziem, pozostawiając na dole sam akumulator. Przykleiłem więc na dolnym pokładzie rzep, na którym mocowany jest akumulator - przeciążenia podczas poruszania robota są tak znikome, że jest to naprawdę pewny i sprawdzony sposób montażu (pozwalający też szybko zamontować albo zdemontować akumulator w razie potrzeby). Oprócz tego przykręciłem w narożnikach podwozia długie dystanse (kupione kiedyś w Chinach na potrzeby projektu quadrokoptera) i zabrałem się za przygotowywanie górnej części pojazdu. Górne podwozie wykonałem z fragmentu płytki aluminiowej, którą dociąłem tak, by znalazła się dokładnie ponad górną częścią podwozia - i jednocześnie dzięki temu przykryła koła, z których pył mógł się dostawać do elektroniki. W płytce wyciąłem otwór na serwo; ponieważ nie dysponuję żadnym sprzętem CNC, który pomógłby mi wyciąć równy, parametryczny otwór, rad nierad wziąłem do ręki wiertarkę, najpierw nawierciłem otwory, potem zamontowałem w niej frez i zacząłem ręcznie wycinać aluminium, a na końcu doszlifowałem wszystko pilnikami o zmniejszającej się ziarnistości. Cały proces poniżej: Teraz można było powoli przystąpić do montażu. Na pierwszy ogień poszło serwo, które na szczęście wpasowało się w wycięty przeze mnie otwór po prostu idealnie. Następnym krokiem było zamontowanie BECa, którego umieściłem pod górnym pokładem. Przewód zasilający (zakończony złączem T-Dean) musiałem rozgałęzić, ponieważ jedna para przewodów musiała zostać połączona z BECem, który obniży napięcie do 5V dla części elektroniki, zaś druga para - do sterownika silników, który będzie potem je zasilał. Szczęśliwie silniki akceptują napięcie dwucelowego akumulatora LiPo - trzeba to koniecznie sprawdzić przed zakupem/montażem! Arduino Leonardo można zasilić bezpośrednio z akumulatora, natomiast konieczne było przylutowanie odpowiedniej wtyczki (na zdjęciu po prawej stronie). Na koniec pozostało podłączenie wszystkich komponentów i otrzymujemy następujący efekt: Programowanie Pierwszym programikiem, który napisałem, był tester silników, który uruchamiał każdy z nich na pół sekundy. Kod wygląda następująco: const int E1 = 3; // Motor1 Speed const int E2 = 11; // Motor2 Speed const int E3 = 5; // Motor3 Speed const int E4 = 6; // Motor4 Speed const int M1 = 4; // Motor1 Direction const int M2 = 12; // Motor2 Direction const int M3 = 8; // Motor3 Direction const int M4 = 7; // Motor4 Direction void M1_advance(char Speed) { digitalWrite(M1, HIGH); analogWrite(E1, Speed); } void M2_advance(char Speed) { digitalWrite(M2, LOW); analogWrite(E2, Speed); } void M3_advance(char Speed) { digitalWrite(M3, LOW); analogWrite(E3, Speed); } void M4_advance(char Speed) { digitalWrite(M4, HIGH); analogWrite(E4, Speed); } void M1_back(char Speed) { digitalWrite(M1, LOW); analogWrite(E1, Speed); } void M2_back(char Speed) { digitalWrite(M2, HIGH); analogWrite(E2, Speed); } void M3_back(char Speed) { digitalWrite(M3, HIGH); analogWrite(E3, Speed); } void M4_back(char Speed) { digitalWrite(M4, LOW); analogWrite(E4, Speed); } void setup() { for (int i = 3; i < 9; i++) pinMode(i, OUTPUT); for (int i = 11; i < 13; i++) pinMode(i, OUTPUT); pinMode(LED_BUILTIN, OUTPUT); } void loop() { digitalWrite(LED_BUILTIN, HIGH); M1_advance(100); delay(500); M1_advance(0); M2_advance(100); delay(500); M2_advance(0); M3_advance(100); delay(500); M3_advance(0); M4_advance(100); delay(500); M4_advance(0); digitalWrite(LED_BUILTIN, LOW); delay(2000); // Delay 2S } Jak widać, sterowanie silnikami odbywa się poprzez podawanie kierunku poprzez piny cyfrowe i prędkości poprzez piny analogowe - proste, jak konstrukcja cepa. Teraz przyszła kolej na odbiornik RC i tu zaczęły się schody. Odbiorniki klasycznie podają stan każdego kanału poprzez sygnał PWM. W praktyce jest to seria naprzemiennych zer i jedynek, z których każda para 1+0 trwa 1/55 sekundy. Wartość możemy odczytać mierząc czas trwania sygnału 1: jeżeli jest to 1 milisekunda, przyjmujemy wartość minimalną ("-1"), jeżeli 1.5 milisekundy, to wartość środkową ("0"), zaś jeśli 2 milisekundy, to wartość maksymalną ("1"). Niektóre odbiorniki pozwalają na nieco szerszy zakres - od 0.5ms do 2.5ms, X8R domyślnie podaje wartości z tego pierwszego zakresu. Ponieważ musiałem mierzyć wartości na dwóch różnych kanałach, zdecydowałem się skorzystać z mechanizmu przerwań. Działa on mniej więcej następująco: gdy zajdzie wybrane zdarzenie (na przykład zmiana stanu danego pinu z niskiego na wysoki), wykonanie programu jest przerywane, zostaje wykonana funkcja oznaczona jako tzw. handler przerwania, a po jej zakończeniu program wznawia wykonanie w miejscu, w którym został przerwany. Na Arduino można znaleźć bardzo wygodną bibliotekę EnableInterrupt, która uogólnia sposób dodawania i usuwania handlerów przerwań pomiędzy różnymi wersjami Arduino, a korzysta się z niej w następujący sposób: #include "EnableInterrupt.h" volatile int microsStart = 0; void pin0Rising() { microsStart = micros(); disableInterrupt(0); enableInterrupt(0, pin0Falling, FALLING); } void pin0Falling() { int microsEnd = micros(); int diff = microsEnd - microsStart; if (diff > 1500) { digitalWrite(LED_BUILTIN, HIGH); } else { digitalWrite(LED_BUILTIN, LOW); } disableInterrupt(0); enableInterrupt(0, pin0Rising, RISING); } void setup() { enableInterrupt(0, pin0Rising, RISING); pinMode(LED_BUILTIN, OUTPUT); } void loop() { } Po wpięciu przewodu sygnałowego do pinu 0 i uruchomieniu programiku na kontrolerze, wbudowana dioda powinna się zapalić w momencie, gdy ustawimy drążek w położeniu większym niż połowa. Zwrócę jeszcze uwagę na magiczne słówko "volatile" przy deklaracji zmiennej - informuje ono kompilator, że zmienna ta nie może zostać zoptymalizowana (kompilator, a dokładniej optymalizator w niektórych przypadkach może w locie usunąć zmienną, na przykład jeżeli nie jest ona używana lub przez cały czas trwania programu ma zawsze tę samą wartość). Dodam tu jeszcze jedną ważną informację: program obsługi przerwania powinien być tak krótki, jak to tylko możliwe! Ma to sporo sensu jeżeli się nad tym nieco dłużej zastanowić, ale ja na to nie wpadłem i w pierwotnej wersji programu cała obsługa silników umieszczona była właśnie w programie obsługi przerwania. I ku mojemu zdziwieniu, po uruchomieniu programu, pomimo tego, że drążki były w położeniu zerowym, dwa silniki zaczęły się obracać. Okazało się, że obsługa przerwania obliczającego czas trwania PWM na pierwszym kanale trwała tak długo, że sztucznie opóźniała wywołanie drugiego przerwania wykonującego te same obliczenia dla drugiego kanału, przez co podawało ono zawyżone wartości. Wystarczyło przebudować program w taki sposób, by obsługa silników znalazła się poza programami obsługi przerwań i wszystko wróciło do normy. Pamiętajmy - to może oczywiste, ale mimo wszystko warto to powiedzieć - że mikrokontrolery nie są wielowątkowe, a przerwania nie są wątkami: wykonują się tylko jedno na raz. Drugie przerwanie musi czekać, aż pierwsze zostanie do końca obsłużone. Przed napisaniem końcowego programu pozostało mi już tylko przetestować obsługę czujnika ruchu, programik wygląda następująco: #include <NewPing.h> #define ULTRASONIC_TRIGGER_PIN 9 #define ULTRASONIC_ECHO_PIN 10 #define MAX_DISTANCE 400 NewPing sonar(ULTRASONIC_TRIGGER_PIN, ULTRASONIC_ECHO_PIN, MAX_DISTANCE); void setup() { pinMode(LED_BUILTIN, OUTPUT); } void loop() { digitalWrite(LED_BUILTIN, HIGH); delay(50); digitalWrite(LED_BUILTIN, LOW); delay(50); int ping = sonar.ping_cm(); if (ping < 30) digitalWrite(LED_BUILTIN, HIGH); else digitalWrite(LED_BUILTIN, LOW); delay(200); } Również i tu korzystam z wbudowanej diody, która powinna zapalić się, gdy zmierzona przez czujnik odległość będzie mniejsza niż 30 cm. Wreszcie program obsługujący całego robota: #include <NewPing.h> #include "EnableInterrupt.h" #include "NewPing.h" // Motor constants // Motor1 Speed #define MOTOR_1_SPEED_PIN 3 // Motor2 Speed #define MOTOR_2_SPEED_PIN 11 // Motor3 Speed #define MOTOR_3_SPEED_PIN 5 // Motor4 Speed #define MOTOR_4_SPEED_PIN 6 // Motor1 Direction #define MOTOR_1_DIR_PIN 4 // Motor2 Direction #define MOTOR_2_DIR_PIN 12 // Motor3 Direction #define MOTOR_3_DIR_PIN 8 // Motor4 Direction #define MOTOR_4_DIR_PIN 7 // Ultrasonic constants #define ULTRASONIC_TRIGGER_PIN 9 #define ULTRASONIC_ECHO_PIN 10 #define MAX_DISTANCE 400 // Servo constants #define SERVO_PIN 13 // AI constants #define DISTANCE_THRESHOLD_2 80 #define DISTANCE_THRESHOLD_1 40 // Ultrasonic control NewPing sonar(ULTRASONIC_TRIGGER_PIN, ULTRASONIC_ECHO_PIN, MAX_DISTANCE); // Motor control functions void M1_advance(byte Speed) ///<Motor1 Advance { digitalWrite(MOTOR_1_DIR_PIN, HIGH); analogWrite(MOTOR_1_SPEED_PIN, Speed); } void M2_advance(byte Speed) ///<Motor2 Advance { digitalWrite(MOTOR_2_DIR_PIN, LOW); analogWrite(MOTOR_2_SPEED_PIN, Speed); } void M3_advance(byte Speed) ///<Motor3 Advance { digitalWrite(MOTOR_3_DIR_PIN, LOW); analogWrite(MOTOR_3_SPEED_PIN, Speed); } void M4_advance(byte Speed) ///<Motor4 Advance { digitalWrite(MOTOR_4_DIR_PIN, HIGH); analogWrite(MOTOR_4_SPEED_PIN, Speed); } void M1_back(byte Speed) ///<Motor1 Back off { digitalWrite(MOTOR_1_DIR_PIN, LOW); analogWrite(MOTOR_1_SPEED_PIN, Speed); } void M2_back(byte Speed) ///<Motor2 Back off { digitalWrite(MOTOR_2_DIR_PIN, HIGH); analogWrite(MOTOR_2_SPEED_PIN, Speed); } void M3_back(byte Speed) ///<Motor3 Back off { digitalWrite(MOTOR_3_DIR_PIN, HIGH); analogWrite(MOTOR_3_SPEED_PIN, Speed); } void M4_back(byte Speed) ///<Motor4 Back off { digitalWrite(MOTOR_4_DIR_PIN, LOW); analogWrite(MOTOR_4_SPEED_PIN, Speed); } // PWM control volatile int microsYStart = 0; volatile int microsXStart = 0; volatile int microsZStart = 0; volatile int yMicros = 0; volatile int xMicros = 0; volatile int zMicros = 0; int UScounter = 0; int USlock = 0; // Pin 0 interrupt handling void pin0Rising() { microsYStart = micros(); disableInterrupt(0); enableInterrupt(0, pin0Falling, FALLING); } void pin0Falling() { yMicros = micros() - microsYStart; disableInterrupt(0); enableInterrupt(0, pin0Rising, RISING); } // Pin 1 interrupt handling void pin1Rising() { microsXStart = micros(); disableInterrupt(1); enableInterrupt(1, pin1Falling, FALLING); } void pin1Falling() { xMicros = micros() - microsXStart; disableInterrupt(1); enableInterrupt(1, pin1Rising, RISING); } // Pin2 interrupt handling void pin2Rising() { microsZStart = micros(); disableInterrupt(2); enableInterrupt(2, pin2Falling, FALLING); } void pin2Falling() { zMicros = micros() - microsZStart; disableInterrupt(2); enableInterrupt(2, pin2Rising, RISING); } void setup() { for (int i = 3; i < 9; i++) pinMode(i, OUTPUT); for (int i = 11; i < 13; i++) pinMode(i, OUTPUT); pinMode(ULTRASONIC_TRIGGER_PIN, OUTPUT); pinMode(ULTRASONIC_ECHO_PIN, INPUT); pinMode(SERVO_PIN, OUTPUT); enableInterrupt(0, pin0Rising, RISING); enableInterrupt(1, pin1Rising, RISING); enableInterrupt(2, pin2Rising, RISING); } void loop() { // Eval motor signals int yValue = (yMicros - 1500) / 2; int xValue = (xMicros - 1500) / 2; if (yValue > 260 || yValue < -260) yValue = 0; if (xValue > 260 || xValue < -260) xValue = 0; int leftEngines = constrain(xValue + yValue, -250, 250); int rightEngines = constrain(yValue - xValue, -250, 250); // Check for obstacles every 10th iteration UScounter++; if (UScounter >= 10) { UScounter = 0; int frontDistance = sonar.convert_cm(sonar.ping_median(5)); if (frontDistance != 0 && frontDistance < DISTANCE_THRESHOLD_2) { if (frontDistance > DISTANCE_THRESHOLD_1) USlock = 1; else USlock = 2; } else USlock = 0; } if (USlock == 1) { leftEngines = constrain(leftEngines, -250, 128); rightEngines = constrain(rightEngines, -250, 128); } if (USlock == 2) { leftEngines = constrain(leftEngines, -250, 0); rightEngines = constrain(rightEngines, -250, 0); } if (abs(leftEngines) < 20) { M3_advance(0); M4_advance(0); } else if (leftEngines > 0) { M3_advance(leftEngines); M4_advance(leftEngines); } else { M3_back(-leftEngines); M4_back(-leftEngines); } if (abs(rightEngines) < 20) { M1_advance(0); M2_advance(0); } else if (rightEngines > 0) { M1_advance(rightEngines); M2_advance(rightEngines); } else { M1_back(-rightEngines); M2_back(-rightEngines); } } Pozwala on na kontrolowanie robota przy pomocy jednego drążka aparatury (dwóch kanałów). Oprócz tego program cyklicznie sprawdza odległość przed robotem i zabezpiecza przed wjechaniem w ścianę: w przypadku przeszkody znajdującej się bliżej niż 80 cm od robota, zostanie ograniczona jego maksymalna prędkość, natomiast jeżeli odległość ta będzie mniejsza niż 40cm, robot zatrzyma się całkowicie i niemożliwe będzie ruszenie nim do przodu. Wnioski To była prawdziwa frajda zobaczyć, jak robot rusza i jeździ zgodnie z instrukcjami z aparatury! Pierwszy skończony projekt. Nauczyłem się na nim dużo, bo okazało się, że w trakcie pracy podjąłem bardzo dużo nietrafnych decyzji. Robot tak naprawdę nigdy nie wyjechał z domu, ma bardzo otwartą konstrukcję, która sprzyja dostawaniu się do obudowy pyłu i piachu. W domowych warunkach wystarczyłby natomiast napęd na dwa koła - w ten sposób miałbym też trochę miejsca wewnątrz obudowy. Arduino Leonardo jest świetne, ale wielkie. Znacznie lepiej sprawdziłoby się Arduino Micro albo Teensy. To drugie nawet bardziej, bo shield do sterowania silnikami pożera dużo pinów i niewiele zostaje na odbiór sygnału z odbiornika RC. Udało mi się jeszcze podłączyć czujnik odległości, ale serwo wpiąłem już bezpośrednio w odbiornik, bo po prostu zabrakło mi pinów. Nie ma większego sensu robić żadnych projektów (innych niż wstępne prototypy) na przewodzikach połączeniowych. Lepiej kupić sobie płytkę prototypową, złącza goldpinowe, przewodziki kydexowe i polutować wszystko na płytce - układ zajmuje znacznie mniej miejsce i jest znacznie mniej podatny np. na przypadkowe wyjęcie przewodu. Chodzi mi po głowie wskrzeszenie projektu - właśnie przy pomocy Teensy oraz drukarki 3D, przy pomocy której mogę wydrukować całe nadwozie szyte na miarę. Ale podejrzewam, że zajmę się tym dopiero za jakiś czas...
  14. 4 punkty
    RozZuBeN – Robot z Zupełnie Bezsensowną Nazwą Jest to robot klasy nanosumo, który został stworzony na wiosnę 2018 roku przez Pojemnika i mnie - wtedy uczniów pierwszej klasy VIII LO w Poznaniu. Zainteresowaliśmy się tą kategorią na Robomaticonie 2018, gdzie nie było żadnego sumo w tej skali. Pomyśleliśmy, że gdybyśmy mieli akumulator z silnikiem, to byśmy łatwo zgarnęli nagrodę za ostatnie (pierwsze!) miejsce. Tak powstał ten robot. Przestudiowaliśmy regulaminy różnych zawodów i wyodrębniliśmy minimalne założenia które musi spełniać nasz robot podczas zawodów: Poruszanie się Nieporuszanie się (przed startem) Po starcie nie może się zatrzymać na dłużej niż 30 sekund Czekanie 5 sekund po starcie Fajnie by było, gdyby sam z siebie nie wypadał z ringu Udało nam się spełnić wszystkie 5 punktów. Płytka: O ile 1, 2 i 3 punkt założeń projektowych można rozwiązać jednym przełącznikiem, to do czwartego potrzebne by było jakieś opóźnienie (układ RC lub popularny NE555 z tranzystorem). 5 punkt przekonał nas do użycia mikrokontolera. Zastosowaliśmy attiny84, które ilością pinów cyfrowych zapewniło nam dużą elastyczność w projektowaniu płytki. Taktowany jest wewnętrznym oscylatorem (miał być zewnętrzny generator kwarcowy ale nie mogliśmy go polutować). Umieściliśmy sterownik silników A3901 z którego wykorzystujemy tylko jeden z dwóch kanałów, dwa czujniki KTIR0711s jako czujniki krawędzi ringu podłączone bezpośrednio do ADC mikrokontrolera, dwa ledy sygnalizacyjne (zielony i bursztynowy, który jest w praktyce pomarańczowy ), przełącznik do startowania robota, dzielnik rezystorowy do mierzenia napięcia akumulatora (chyba nawet niewykorzystany), złącze do programowania (2x3 żeńskie goldpiny precyzyjne) i stabilizator napięcia na 3,3V w obudowie SOT23 (nie pamiętamy oznaczenia). W Eaglu zrobiliśmy kwadrat 25x25mm, rozmieściliśmy elementy „na oko”, połączyliśmy ścieżkami, i wysłaliśmy do OSH Parku. Zajęło nam to dwie godziny. Był to koniec marca, płytka przyszła w połowie maja. Wcześniej zamówiliśmy wszystkie elementy, ale oczywiście pomyliliśmy attiny84 z attiny88, więc złożenie potrwało trochę dłużej niż przewidywaliśmy. Płytkę lutowało się całkiem dobrze, choć do drobnych elementów chyba jednak lepsze są płytki cynowane zamiast złoconych (niby złoto lepiej przewodzi prąd ale cynę najlepiej się lutuje do innej cyny). Praktycznie od razu płytka dogadała się z programatorem (co nie było takie oczywiste w naszych poprzednich robotach). Konstrukcja mechaniczna: Mieliśmy kilka pomysłów na spełnienie pierwszego założenia projektu: silniczek wibracyjny z jakiegoś telefonu, żeby robot tylko drgał (przecież ruch to ruch) albo umieszczenie dwóch silników tak by stykały się wałami z podłożem, aby nie była potrzebna przekładnia, mechanizmy sprężynowe chyba też były... Porządna przekładnia z zębatek odpadała, bo nie wiedzieliśmy jak ją zrobić. Ostatecznie wykorzystaliśmy przekładnię cierną. Wał silnika z nałożoną rurką termokurczliwą (dla lepszego tarcia) jest przyciśnięty do opony jedynego w robocie kółka wyciągniętego z jakiejś zabawki. Brzmi to okropnie i tak też zostało to zmontowane. „Felga” kółka trze o korpus silnika, więc to miejsce musi być często smarowane wazeliną techniczną, żeby robot nie zaciął się podczas walki. Wszystko jest zalane gorącym klejem z drucikami z goldpinów tworzącymi swego rodzaju usztywnienie. Czasem gorący klej sprawiał problemy czujnikom przeciwników (nie wiemy dlaczego). Robot o jednym kółku nie przewraca się, ponieważ na całej podstawie ma przyklejony kawałek styropianowej tektury znaleziony w szufladzie. Przed i za kołem znalazło się też trochę miejsca na ktiry. Wszystko połączyliśmy kabelkami, przykleiliśmy akumulator (Li-Po 1S 150 mAh) (oczywiście też na gorący klej) i włączyliśmy. Okazało się, że silnik jest za mocny i wywraca robota tuż po starcie, ale i tak byliśmy dumni, że robot porusza się całkiem skutecznie. Zrezygnowaliśmy też z przełącznika, który był bardzo niewygodny i zastąpiliśmy go odbiornikiem IR. Nie chcieliśmy się bawić z dekodowaniem sygnałów, więc sygnał połączyliśmy dużym kondensatorem do masy zmieniającym dane na jedną dłuuugą jedynkę odczytywaną przez procesor. Program: Po wielu próbach doszliśmy do wniosku, że najlepiej jest poruszać się metodą krótkich „skoków” polegających na szybkim włączeniu i wyłączeniu silnika (wtedy robot nigdy się nie przewracał). Po każdym „skoku” robot sprawdza czy jest na krawędzi. Jeśli tak to zaczyna poruszać się w drugą stronę i zapala bursztynowego leda. Po 10 sekundach ruchu robot zatrzymuje się na równe 10 sekund aby to przeciwnik zużywał akumulator. Całość powtarzana jest aż do utraty zasilania. Ta technika działa zaskakująco dobrze w przypadku konfrontacji z robotem, który też jest „ślepy”. Podczas ruchu może niechcący wypchnąć przeciwnika, a kiedy stoi bardzo ciężko jest go ruszyć (chyba, że przeciwnik jest rozpędzony lub ma dobre silniki). Akumulator starcza na bardzo dużo często remisowych walk. Zwykle ładujemy go przed zawodami do 4,20V a po walkach nadal ma ponad 4,10V. Osiągnięcia: 2018: 3. miejsce Bałtyckie Bitwy Robotów 3. miejsce Robocomp 2. miejsce Sumo Challenge 2019: 4. miejsce Robotic Arena 1. miejsce Robomaticon Robot tylko na Robotic Arena zajął ostatnie miejsce. Na każdych zawodach miał 3 przeciwników, więc na Robomaticonie wygrał ze wszystkimi! (z czego z jednym walkowerem) Wnioski: Robot spisuje się niespodziewanie dobrze, co obrazuje niestety poziom konkurencji w Polsce. Aktualnie kończymy prace nad kolejną konstrukcją, która tym razem będzie miała dwa kółka i będzie widzieć przeciwnika, co pozwoli liczyć na walkę a nie tylko łut szczęścia. Mamy nadzieję, że aktywnie zawalczy o pierwsze miejsca. Kilka filmów z zawodów: Chętnie odpowiemy na wszystkie pytania dotyczące robota.
  15. 4 punkty
    Elektroniczny Multitool Jak się zaczęło? Ano zaczęło się od tego, że zanabyłem sobie hulajnogę elektryczną. Długo i sumiennie przeglądałem różne recenzje, opisy, wertowałem informacje, aż w końcu zdecydowałem się na Airwheel Z5 Strong, którą na marginesie polecam. Pomimo wielu zalet - w tym kilku rozwiązań unikalnych w tym segmencie urządzeń, jak na przykład wygodne podesty albo łatwo wymienny akumulator - ma jednak pewną niewielką wadę: brak wyświetlacza informującego na przykład o bieżącej prędkości czy o przejechanej drodze. Ponieważ od jakiegoś czasu bawię się Arduino, stwierdziłem, że stosunkowo łatwo powinno dać się skonstruować taki licznik samodzielnie - wystarczy przecież zastosować GPS, który uniezależnia mnie od rozwiązań zastosowanych w hulajnodze. Zacząłem więc powoli kolekcjonować wszystkie niezbędne komponenty. Wyświetlacz Zacząłem trochę nietypowo, bo od wyświetlacza. Zrobiłem już kilka projektów na wyświetlaczach znakowych, ale - oczywiście - nie dają one takich możliwości, jak solidny, kolorowy, a najlepiej dotykowy wyświetlacz. Mój wybór padł na dotykowy wyświetlacz 2.4", pracujący z rozdzielczością 320x240 i komunikujący się przez popularny protokół SPI. Mój wygląda nieco inaczej niż ten w sklepie, ale różnią się płytką z kontrolerem, wyświetlacz jest ten sam. Kontroler Obejrzałem sobie sporo filmików dotyczących podłączania wyświetlaczy do Arduino i uderzyło mnie to, że w większości przypadków liczba klatek na sekundę osiągała bardzo często wartości jednocyfrowe. Jest to zrozumiałe - wszelkie Uno, Leonardo, Micro i tak dalej są taktowane ze stosunkowo małymi częstotliwościami, a przynajmniej zbyt małymi, by osiągnąć zadowalające rezultaty graficzne. Dlatego tym razem porzuciłem całę rodzinę *ino na rzecz chyba nieco mniej znanego kontrolera, Teensy 3.5. Kosztuje swoje, ale dostajemy naprawdę ciężką artylerię: 120 Mhz, 512 kB Flash, 192 kB RAMu, 62 piny, zintegrowany zegar czasu rzeczywistego (trzeba go tylko zasilić bateryjką CR2032), czytnik kart microSD i oczywiście możliwość programowania przez micro USB, bez konieczności stosowania programatorów. Polecam, korzystanie z takiego kombajnu to naprawdę czysta przyjemność. GPS Ta decyzja była stosunkowo prosta, zdecydowałem się na rozwiązanie ekonomiczne i kupiłem prosty GPS komunikujący się przez UART (szeregowo). Przyznam szczerze, że po zakupie Teensy trochę szkoda było mi poświęcić taki świetny kontroler li tylko na licznik do hulajnogi. Dlatego zanabyłem jeszcze popularny czujnik pogodowy BME280 i stwierdziłem, że w czasie, gdy nie będę korzystał z urządzenia jako licznika, zrobię z niego małą stację pogodową. Na wyposażeniu urządzenia znalazł się również czujnik położenia MPU9250, bo zamierzałem napisać rejestrator pochyłości podłoża (i ewentualnie również jego jakości), ale w końcu z tego pomysłu zrezygnowałem. Być może za jakiś czas dopiszę sobie do urządzenia cyfrową poziomicę. Konstrukcja Zacząłem od płytki prototypowej, która błyskawicznie zamieniła się na totalnie zagmatwaną pajęczą sieć przewodów kydexowych. Myślałem na początku, że poprzestanę na niej, ale plątanina ta wyglądała tak dramatycznie, że z pomysłu w końcu zrezygnowałem, traktując go tylko jako prototyp. Sprawdziłem, czy wszystkie urządzenia będą pracowały prawidłowo i generalnie każdy moduł udało mi się uruchomić i pobrać z niego dane, z tym wyjątkiem, że BME280 i MPU9250 odmawiały współpracy podłączone do jednej szyny I2C. Szczęśliwie Teensy oferuje tych szyn chyba z pięć, więc przepiąłem BME na inną i wszystko wstało bez problemu. Kiedy wszystko działało, siadłem do Eagle'a i zaprojektowałem PCB, który miał zastąpić tę nieszczęsną płytkę prototypową. W Polsce jest kilka firm, które wykonują nawet pojedyncze sztuki takich płytek, a moją zamówiłem w firmie Satland Prototype. Musiałem poczekać dwa tygodnie, ale w końcu płytka doszła pocztą i mogłem zacząć lutować. Jakiś czas temu wyposażyłem się w drukarkę 3D, więc po zlutowaniu (i uruchomieniu) wszystkiego siadłem do Fusion 360 i zaprojektowałem obudowę na całe urządzenie. Zadbałem o to, żeby BME został odseparowany wewnętrzną ścianką od reszty urządzenia, bo ekran LCD potrafi się grzać i zafałszowuje odczyty. GPS zamocowałem w osobnym miejscu, wsunięty w odpowiedni slot i zabezpieczony ścianką z drugiej strony, ponieważ niestety wersja, którą kupiłem, nie posiadała żadnych otworów montażowych. Płytka z komponentami siedzi w przygotowanym na jej wymiary wgłębieniu i jest ściśnięta pomiędzy dwiema częściami obudowy, więc nie ma możliwości się przesunąć. Do tego otwór na wyświetlacz, siateczka w przedniej ściance przepuszczająca powietrze do czujnika pogodowego i tyle. Słowo komentarza, bo pewnie padnie takie pytanie: schemat dotyczy nowej wersji płytki z usuniętym radyjkiem NRF, na zdjęciu jest starsza wersja - szczegóły na końcu artykułu. Programowanie Proces programowania musiałem rozłożyć w czasie, ale projekt szedł powoli do przodu. Zacząłem od części pogodowej, ogrom miejsca w programowalnej pamięci kontrolera pozwolił mi poszaleć, więc przygotowałem sobie w C++ klasy odpowiedzialne za obsługę interfejsu użytkownika, spięcie różnych modułów w jedną całość, wyświetlanie grafiki i tak dalej. Również i tym razem dałem się ponieść - nie mogłem znaleźć w Internecie dobrego programu do generowania czcionek w formacie zrozumiałym dla biblioteki ILI9341_t3 przygotowanej przez twórcę Teensy (działa ona szybciej od regularnej biblioteki), a zależało mi na czcionce siedmiosegmentowej - takiej trochę "retro" (widać na screenach). Zapytałem więc Paula o kilka rzeczy, siadłem któregoś wieczoru i wyrzeźbiłem edytor czcionek dla ILI9341_t3. Mój prosty programik może się podobać lub nie, ale najlepszą alternatywą jaką znalazłem jest gigantyczne makro w Excelu, więc sami rozumiecie... Dużym odkryciem było dla mnie, że na platformę Arduino można już programować w Visual Studio Code - Arduino Studio jest wciąż wymagane (bo zawiera wszystkie narzędzia potrzebne do zbudowania programu dla kontrolerka), ale tak naprawdę wszystkie operacje - budowanie, wrzucanie na płytkę, monitor portu szeregowego - można już obsłużyć bezpośrednio w tym świetnym środowisku. Tylko że... niestety Teensy nie jest całkowicie zgodne z Arduino i do budowania na tę platformę potrzebny jest dodatkowy programik, Teensyduino, który nieco modyfikuje Arduino Studio i nie jest kompatybilny z VS Code. Tym niemniej, większość developmentu zrealizowałem w tym ostatnim, jedynie budując i wrzucając aplikację na urządzenie przy pomocy AS. Zastosowałem też własny mechanizm podwójnego buforowania: cały obraz buduję w RAMie i wyświetlam go hurtem w jednym kroku. Ogranicza to trochę lag związany z wyświetlaniem poszczególnych elementów, opóźnienie wciąż jest, ale jest znacznie mniej zauważalne. Kosztowało mnie to prawie połowę pamięci RAM, ale z uwagi na to, że pozostałe komponenty aplikacji prawie go nie zużywają, mogłem sobie na to pozwolić. Źródła trzymam na Gitlabie, chcecie obejrzeć - sklonujcie sobie repo. Efekt W chwili obecnej płytka w trybie stacji pogodowej wyświetla klasycznie: temperaturę, ciśnienie i wilgotność, a także wykresy: bieżący (jasna linia - jeden piksel to 15 sekund) i historia - 1h, 8h lub 24h wstecz.Tryby można przełączać po dotknięciu ekranu - pojawia się wtedy proste menu. Aplikacja wyposażona jest w wygaszacz ekranu, który zapobiega wypaleniu pikseli - szczególnie, że w trybie stacji pogodowej bardzo dużo z nich mogłoby być na to narażone. Po 30 sekundach ekran się wyłącza (wygasza), a włącza ponownie po dotknięciu. Niestety nie udało mi się wyłączyć jego podświetlenia - doczytałem, że w tym ekranie programowo nie da się tego zrobić. Szkoda. W trybie GPS wyświetlane są na razie podstawowe informacje wczytane z odbiornika: prędkość, wysokość n.p.m., kierunek jazdy, liczba satelit, z których odczytywane są dane oraz położenie geograficzne - długość i szerokość. Za jakiś czas dopiszę pewnie tryb "rowerowy", czyli przebyta droga, średnia i maksymalna prędkość i tak dalej. Aplikację mam napisaną na tyle modularnie, że teraz taki moduł mogę już sobie praktycznie niewielkim kosztem poskładać "z klocków". Problemy Człowiek uczy się na błędach, a mądry człowiek na błędach innych. Podczas rozwijania tego projektu nadziałem się na mnóstwo problemów, więc podzielę się moimi rozwiązaniami - być może komuś oszczędzi to czasu i nerwów. Po pierwsze, zasilanie - w dwóch odsłonach. Pierwsza odsłona - pierwotnie na płytce znajdowało się jeszcze radyjko NRF24, ponieważ jakiś czas temu zbudowałem sobie "satelitę" - małą płytkę z czujnikiem temperatury i wilgotności zasilaną z bateryjki CR2032: miałem nadzieję, że w trybie stacji pogodowej urządzenie będzie również ściągało informacje z tego źródła. Testy bez GPSu wypadły pozytywnie - to widać na zdjęciach - ale po podłączeniu wszystkiego i włączeniu zasilania, ekran rozbłysł na chwilę, a potem powolutku przygasł i zgasł całkowicie. Podejrzewałem od razu NRF, chciałem go rozlutować, ale w trakcie tego procesu oderwałem jeden pad na płytce, więc nie miałem już możliwości łatwego sprawdzenia, czy to on jest winien. Żeby uniknąć dalszych uszkodzeń, podrzuciłem płytkę ojcu, który w pracy ma wysokiej klasy rozlutownicę, a ja zaprojektowałem w międzyczasie drugą, tym razem już bez NRFa. Warto zawsze sprawdzić, czy uda się zasilić wszystkie komponenty - ja leniwie pociągnąłem zasilanie wszystkiego z płytki, a mogłem przecież wstawić na płytkę port microSD i pociągnąć dodatkowe ścieżki bezpośrednio z niego - wtedy obciążyłbym zasilacz (który pewnie nawet by nie sapnął), a nie samą płytkę. Druga kwestia - hulajnoga, którą kupiłem, ma w baterii wyjście USB - można (według instrukcji) doładowywać sobie na przykład komórkę (traktować akumulator jako powerbank). Również do tego portu podłączana jest latareczka, którą można sobie włączyć podczas jazdy. Niestety podczas prób terenowych okazało się, że przysiad napięcia podczas rozpędzania jest tak duży, że płytka gaśnie albo się zawiesza. Musiałem więc zasilić ją z osobnego powerbanku, w przyszłości pomyślę nad zasileniem płytki z osobnego akumulatora albo po prostu baterii. Teraz BME280 - małe ostrzeżenie. Układzik jest rewelacyjny, malutki i stosunkowo dokładny... ale się grzeje! Potrafi rozgrzać się na tyle, że zafałszowuje informacje o temperaturze o 1.5-2 stopnie. Rozwiązanie (proponowane nawet przez Boscha) polega na zmniejszeniu dokładności pomiaru (urządzenie może działać w trybie oversampling, czyli robi np. 8 pomiarów i uśrednia - należy to wyłączyć), wyłączeniu filtrowania (które również poprawia jakość pomiarów), przełączyć się w tryb "forced" - wtedy płytka robi pomiar tylko na życzenie - i ograniczyć pomiary do jednego na minutę (!). Ja nie ograniczyłem się tak bardzo, pomiary mam co 15 sekund, ale mimo wszystko układ się grzeje i na początku na wykresie widać delikatny skok temperatury, który po chwili się stabilizuje. Jest również prawdopodobne, że grzeje się nie tyle BME, co wyświetlacz - podobny problem miałem w innej stacji pogodowej z wyświetlaczem znakowym. Tam temperatura skakała do góry o kilka stopniu po uruchomieniu. Kwestia estetyki - nie zadbałem o to, żeby schować obramowanie ekranu z widocznymi ścieżkami panelu dotykowego. W innych projektach nie popełniam już tego błędu, widoczny jest sam ekran (wygląda to o niebo lepiej). Ogólnie jednak jestem zadowolony, płytka jest rozwojowa, a nowe funkcjonalności mogę dodawać programowo, więc podejrzewam, że wzbogacę ją jeszcze o kilka dodatkowych trybów pracy.
  16. 4 punkty
    Cześć, od kiedy opisałem swojego robota Pika na forum, minęło już troszkę. W tym czasie zdążyło powstać kilka kolejnych konstrukcji, zarówno bez turbiny jak i z turbiną. W tym poście chciałbym przybliżyć Wam moją najnowszą konstrukcję - robota klasy Linefollower Turbo o nazwie Spark. Głównym założeniem, jakie przyświecało mi podczas projektowania była chęć nauczenia się wektorowego sterowania silnikami BLDC oraz wykorzystanie właśnie takich silników jako napęd bezpośredni w robocie. Podczas opisu założeń konstrukcyjnych posłużę się modelem 3D robota. Jak można zauważyć na powyższym zdjęciu, ogólna konstrukcja nie różni się od znanego wszystkim standardu. Na przedzie delikatna i lekka listewka z 14 czujnikami linii KTIR0711S. Centralnie umieszczona turbina QX-Motor 14000 kv o średnicy 30 mm. Dwa silniki hexTronik 1300KV umieszczone w tylnej części w taki sposób, aby możliwe było uniesienie przodu celem wjazdu na pochylnię/rampę w kategorii Linefollower Enchanced. Sercem robota jest mikrokontroler STM32H743VIT6. Jest on oparty na rdzeniu Cortex M7 oraz taktowany z prędkością 400 MHz. Wybór tak potężnej jednostki sterującej podyktowany był chęcią wydajnego obliczania komutacji sterowania wektorowego dla każdego z silników jezdnych oraz realizacji algorytmu jazdy przy pomocy tylko jednej jednostki. Dodatkowo tak szybki mikrokontroler pozwolił na zatuszowanie moich niedoskonałości w optymalizacji kodu Głównym elementem konstrukcyjnym jest 4-warstwowy obwód drukowany. W trakcie projektowania falowników do sterowania silnikami powstały dwa prototypy, w których miałem problem z przegrzewającymi się tranzystorami dlatego w docelowym PCB zastosowałem aż 4 warstwy. Dodatkową zaletą takiego obwodu jest jego większa odporność na zakłócenia elektromagnetyczne. Podświetlony obszar to miedź na wszystkich czterech warstwach połączonych setkami przelotek chłodząca tranzystory. Do sterowania każdym z silników wykorzystałem 6 tranzystorów w układzie pełnego mostka 3-fazowego. Posłużyły mi do tego półmostkowe układy BSG0813NDI za których udostępnienie serdecznie dziękuję firmie Infineon (oraz za tranzystory i drivery, które spaliłem w prototypach - ok 60 sztuk, nie od razu Rzym zbudowano ) Ostatecznie jako drivery wykorzystane zostały układy MIC4607-2 ze względu na możliwość sterowania całym mostkiem przy pomocy tylko jednego układu. Do odczytywania pozycji wirnika służy enkoder magnetyczny AMS5045B. Całość zasila akumulator Li-Po Tattu 450mAh 7.4V 75C. Za komunikację bezprzewodową odpowiada stary dobry moduł HC05. W celu zapewnienia pod robotem podciśnienia wywoływanego turbiną, zwiększającego nacisk kół na podłoże obrys uszczelniony został wydrukowaną w 3D ścianą. Do usztywnienia konstrukcji tak, aby opierała się ona o podłoże tylko kołami i ślizgaczami z przodu, posłużyły wałki węglowe o średnicy 4 mm. Do połączenia ze sobą poszczególnych elementów konstrukcyjnych wykorzystane zostały aluminiowe mocowania wykonane w technologii WEDM. Poniżej kilka fotek. Prototyp 1: Ratowanie prototypu 1 (rezystory bramkowe? A na co to potrzebne ) : Prototyp 2: Elementy konstrukcyjne: Pierwsze ruchy silnika: Poszukiwanie granic: Opona wykonana z poliuretanu 20': Aluminiowa felga wciśnięta na wirnik (Pololki dla skali): Zamontowana felga wraz z oponami (Mini-Z 20'): Turbina po dezintegracji (podczas jazdy eksplodowała): Przejazd w konkurencji Linefollower Drag podczas Bałtyckich Bitw Robotów 2018: Próby podczas RobotChallenge 2018 w Pekinie: Wnioski: Konstrukcja waży 250 g. To zdecydowanie za dużo, gdyż opony nie są w stanie zapewnić wystarczającej przyczepności na zakrętach i robot wpada w poślizg na zakrętach przez co osiągnięcie prędkości średniej na krętej trasie powyżej 3 m/s jest bardzo trudne. Zastosowanie silników BLDC jako direct-drive umożliwia rozpędzenie robota do ogromnych prędkości liniowych (15 m/s+) lecz aby posiadały one zadowalający moment przy niskich obrotach konieczny do gwałtownych zwrotów muszą być duże i ciężkie. Lepiej zastosować małe silniki z przekładnią. Nowa konstrukcja już się tworzy! Dziękuję za przejrzenie albumu, który utworzyłem i zapraszam do zadawania pytań w komentarzach
  17. 4 punkty
    Jakiś czas temu na portalu z ogłoszeniami natknąłem się na ofertę sprzedaży zabytkowego układu scalonego AY-3-8500. Jest to dość specyficzny element, wykorzystywany na przełomie lat siedemdziesiątych i osiemdziesiątych do budowy konsol do gier pierwszej generacji. Układ scalony zawiera w swojej strukturze kompletną logikę, niezbędną do generowania kilku prostych gier, m.in. kultowego "Ponga". Wykorzystywany był m.in. w kultowym ELWRO/Ameprod TVG-10 - jedynej polskiej konsoli do gier, jaka trafiła do masowej sprzedaży. Oczywiście nie byłbym sobą, gdybym go wtedy nie kupił i nie spróbował odpalić. Zacząłem więc szukać w Sieci informacji na temat tego układu. Efekty tych poszukiwań przeszły moje oczekiwania - natknąłem się na stronę, której autor zajął się podobnym projektem. Była tam cała niezbędna dokumentacja, karty katalogowe, a także projekt płytki drukowanej konsoli wykorzystującej posiadany przeze mnie układ scalony. No cóż... Postanowiłem nie wyważać otwartych drzwi i wykorzystałem ten wzór, prowadzając jednakże pewne modyfikacje w swojej implementacji tego projektu. Największa z nich dotyczyła kontrolerów , które zbudowałem w oparciu o niewielkie, plastikowe obudowy. Musze przyznać, że tworzą one całkiem poręczne "pady". Każdy z kontrolerów jest wyposażony w potencjometr służący do kontrolowania położenia paletki oraz przycisk do serwowania. Sama konsola została umieszczona w typowej plastikowej skrzynce. Na przednim panelu znajdują się przełączniki dźwigniowe dwu i trzypozycyjne służące do konfiguracji trybu rozgrywki, a także przełącznik obrotowy, do wyboru właściwej gry. Układ AY-3-8500 pozwala na korzystanie z pistoletu świetlnego. Dwie z generowanych przez niego gier wymagają posiadania takiego sterownika. Zdecydowałem się jednak zrezygnować z jego budowy. Na płytce są wyprowadzone odpowiednie piny, więc w przyszłości będzie możliwa taka rozbudowa. Niestety strona na której znalazłem oryginalny projekt niedługo później przestała działać, jednak wciąż można się do niej dostać przez Wayback Machine. Konsola przez jakiś czas była dostępna na wystawie "Game start/game over" w krakowskim Muzeum Inżynierii Miejskiej. Przetrwała - grupy gimnazjalistów nie były w stanie jej zniszczyć. W ramach ciekawostki mogę dodać, że mojemu sześcioletniemu siostrzeńcowi spodobała się ta gra sprzed kilku dekad.
  18. 4 punkty
    Przedstawiam Wam Lernka. Lernek to zabawka edukacyjna stworzona przeze mnie jako projekt na zaliczenie jednego z przedmiotów w ramach studiów. Zabawka posiada pięć głównych trybów: trzy do nauki kolorów w języku angielskim (powtarzania sekwencji, coraz szybciej oraz do nauki nazw), do nauki słówek w języku angielskim oraz do nauki podstawowych działań matematycznych. Tak wyglądał po zakończeniu wszystkich prac: Teraz parę słów o każdym trybie. Potem garść informacji o konstrukcji i oprogramowaniu. Tryby Coraz szybciej: W tym trybie wyświetlacz pokazuje kolejne nazwy kolorów w języku angielskim stopniowo zwiększając tempo. Dziecko musi coraz szybciej zaznaczać przycisk w odpowiadającym mu kolorze. W każdym trybie prawidłowemu naciśnięciu klawisza towarzyszy sygnał dźwiękowy. Początkowo czas na wybór to 5 sekund. Czas zmniejsza się o 0,1 sekundy, aż nie pozostanie 1,5 sekundy. W każdym trybie gra toczy się do pierwszej „skuchy”. Sekwencja: W tym trybie na wyświetlaczu pokazywane są kolejne nazwy kolorów w języku angielskim. Następnie użytkownik powtarza przedstawioną sekwencję wciskając kolejne przyciski. Na wybranie kolejnego elementu ma czas 3 sekundy. Nauka: Po wybraniu tego trybu na wyświetlaczu pojawia się nazwa koloru po angielsku i polsku oraz numer odpowiadającego mu klawisza. Użytkownik potwierdza zrozumienie i zapamiętanie komunikatu wciskając odpowiedni przycisk. Prawidłowy wybór sygnalizuje komunikat oraz sygnał dźwiękowy. Wyświetlony zostaje kolejny kolor (kolejność kolorów jest stała – od lewej do prawej). Po wciśnięciu ostatniego przycisku następuje zakończenie trybu i możliwość powrotu do menu. Matematyka: Czwarty z zaproponowanych trybów ma na celu wspomóc naukę czterech podstawowych działań matematycznych, tj. dodawania, odejmowania, mnożenia i dzielenia. Oprogramowanie działa w ten sposób, że do każdego działania jest odpowiednio dobrany zakres, czas na rozwiązanie, zabezpieczenia przed błędami, itd. Wyświetlane są trzy odpowiedzi, z których należy wybrać prawidłową. Słówka: Ostatni tryb zabawki wspiera dziecko w nauce słówek w języku angielskim. Zgodnie z ograniczeniami pojemności pamięci Arduino Pro Mini (Atmega 328p) zaprogramowałem ponad 140 słówek maksymalnie wykorzystując wbudowaną pamięć Flash. Konstrukcja Najpierw zdjęcie od środka przedstawiające jak wyglądała całość po złożeniu. Mózgiem całego projektu jest Arduino Pro Mini (u mnie klon). Potrzebny też był większy wyświetlacz LCD (4x20, z konwerterem I2C), niż standarodwe LCD 2x16. Do zasilania wykorzystałem koszyk na 4 baterie typu AA z wyłącznikiem i pokrywką. Absolutnie niezbędne były też różnokolorowe, kwadratowe TactSwitche. Oprócz tego kilka LEDów, buzzer, przyciski i inne drobne elementy. Aby cały projekt był względnie trwały w kontakcie z dziećmi () postanowiłem zamknąć go w specjalnie zaprojektowanej obudowie, którą wydrukowałem na drukarce 3D. Poniżej zdjęcia z modelu w oprogramowaniu CAD. W obudowie uwzględniłem wgłębienia na TactSwitche, buzzer i koszyk na baterie oraz wycięcia na wyświetlacz, diody i wyłącznik. Dzięki temu uniknąłem czasochłonnego przycinania. Zadbałem też o uszy pozostałych domowników podłączając wyłącznik, który mechanicznie wycisza buzzer przez odcięcie mu zasilania. Kto przypatrzy się uważnie zobaczy, że większość przycisków jest białych. Zostały do nich przyklejone paginatory do książek (ze względu na dużą trwałość) za pomocą taśmy dwustronnej. Schematy elektryczne Schemat elektryczny przygotowałem w KiCADzie. Zamieszczam go poniżej. Znaczne ułatwienie uzyskałem dzięki zastosowaniu konwertera I2C przy wyświetlaczu. Od razu założyłem, że do podłączenia niezbędna będzie płytka PCB. Płytka była jednostronna, ale na górze zrobiłem warstwę opisową (schematy widać na zdjęciu niżej). To była moja pierwsza płytka PCV, dlatego musiałem skorzystać z wielu poradników. Oprócz rad kolegów najbardziej pomógł mi ten poradnik. Tak wyglądała po wytrawieniu, nawierceniu otworów i umieszczeniu w obudowie. Oprogramowanie Tutaj było bardzo dużo pracy. Kod liczy kilka tysięcy linii, dlatego streszczę tylko jego działanie od strony widocznej dla użytkownika. Zatem na początku mamy krótki ekran powitalny z migającymi diodami i dźwiękiem. Następnie pojawia się menu wyboru – naciśnięcie odpowiedniego klawisza włącza wybrany tryb. Po zakończeniu rozgrywki wyświetla się wynik, a następnie zapytanie, czy chcemy zagrać ponownie. Jeśli tak – gra uruchamia się jeszcze raz. Jeśli nie – wychodzimy do głównego menu. Wygląd po montażu już wam pokazałem, dlatego teraz krótki filmik jak wygląda ekran powitalny.
  19. 4 punkty
    Dzień dobry Nie będę zupełnie oryginalny i zrobiłem dwie stacje meteo. Chciałem poduczyć się trochę arduino i szukałem pomysłu na projekt przeglądając Botland znalazłem czujniki pyłu PM 2,5 i PM 10. Przez to, że temat smogu jest na czasie uznałem to za dobry pomysł by zweryfikować czy miejscowość w której mieszkam (wieś) jest od niego wolna. Zacząłem od kursów na Forbocie (vel wyświetlacz lcd) by załapać podstawy arduino i elektroniki. Były bardzo pomocne. Następnie chciałem przetestować niektóre czujniki i tak sprawdziłem Temperatura DS18B20 MCP9808 SHT 15 SHT 31 Wilgotność DHT 11 DHT 22 SHT 15 SHT 31 Przy wyborze też między innymi kierowałem się dokładnością pomiaru najlepiej ok 5% oraz możliwością pracy przy ujemnych temperaturach im mniej tym lepiej gdyż mrozy tu mogą sięgać -20C. Przy testowaniu tylko miałem problem z DHT11 i DHT22 - mianowicie nie podawał mi poprawnych danych (miałem obok kupny wilgotnościomierz i dane zupełnie nie pasowały do siebie ale opisałem to w innym poście na forum). Wybrałem MCP9808 gdyż uznałem, na czujnik temperatury gdyż wg moich obserwacji najlepiej się sprawdzał w różnych warunkach i wahaniach temperatury. Osobno tak samo wybrałem czujniki wilgotności tylko do tego celu tj. SHT31. Barometr widziałem, że polecany jest BMP180 więc na nim zostałem. Z programowaniem nie było problemu ze względu na biblioteki. Czujniki pyłu były małym wyzwaniem. Brak bibliotek. I śmigają na UART Trzeba operować na przykładowych kodach i rozumieć jak lecą bity. Ponadto trzeb zwracać uwagę na to że różne modele mogą mieć różny formę ramki danych przesyłanych. Przetestowałem 3 czujniki pyłu PMS5003 PMS5003 z detekcją formaldehydu Gravity Każdy z nich miał inaczej ramkę ukształtowaną. Ponadto czujniki zasilane są napięciem 5V a linia danych 3,3V Do tego należy dokupić konwerter poziomów logicznych by zadziałało to sprawnie. Do tego zestawu dokupiłem stacje meteo z wiatromierzem. Następnie chciałem aby stacja mogła być na zewnątrz i komunikować się z odbiornikiem w środku przez nRF24L01+. Warto brać moduł z zewnętrzną anteną oraz adapterem poprawia działanie modułu. Mając już na płytce w miarę temat ogarnięty chciałem najpierw testowo zrobić mobilny czujnik pyłu aby zrobić pierwsze przymiarki do lutowania i montażu. Lutowałem na płytkach prototypowych z cienkimi kablami. Nie był to dobry pomysł ale na daną chwilę dało się. Zamiast przylutowywać moduły na stałe lutowałem sloty do nich. Wolałem trochę poświęcić jakość wykonania na rzecz sytuacji w której mógłbym się pomylić. Nie mam rozlutotwnicy a standardowa lutownica i odsysacz słabo mi się sprawdzały. Specyfikacja mobilnego czujnika pyłu (główne moduły) Arduino Pro Mini 328 - 5V/16MHz SHT 15 (wilgotność i temperatura) PMS5003 (czujnik pyłu) Konwerter USB-UART FTDI FT232RL - gniazdo miniUSB (programator ew zasilanie poza bateryjne) Wyświetlacz LCD 4x20 znaków zielony Efekt był zadowalający wiec uznałem, że warto będzie spróbować wysyłać dane na stronę www. Do tego zadania zaprzęgłem malinkę z modułem nRF24L01+. Idea była taka aby: ->pomiar stacji ->wysłanie danych drogą radiową ->odebranie przez Ras Pi ->wysłanie danych na zewnętrzny bazę danych MySQL ->pobranie danych z bazy i wyświetlenie jej na stronie bazującej na wordpresie Główny problem był z liczbami zmiennoprzecinkowymi. Gdyż malinka odbiera surowe bity i nie chce ich prze konwertować na liczbę zmiennoprzecinkową. W każdym bądź razie wszelkie próby konwersji i operacji na bitach skończyły się komunikatem ze Python nie obsługuje przesunięć bitowych dla liczb zmiennoprzecinkowych. Do zastosowań domowych wystarczy mi pomiar do drugiego miejsca po przecinku (temperatura) więc po prostu każdą zmienna która miała część ułamkową mnożę na Arduino razy 100 i jak odbiorę na malince dzielę przez 100. O ile odbiór między arduino to linijka kodu to tu przy odbiorze suchej transmisji (już przy użyciu biblioteki ...... ) trzeba było bity ręcznie składać bo Arduino wysyła jedną zmienną w dwóch bajtach trzeba było używać operatorów bitowych by te bajty złączyć w jeden. Przed montażem należało wyznaczyć miejsce dla stacji. Z tego względu do stacji mobilnej dorzuciłem adapter NRF na który mogłem po prostu zamiennie testować wersje z zewnętrzną i wewnętrzną anteną. Syngał nadawał do malinki kolejne cyfry a obok miałem telefon z teamviwerem na którym patrzałem się co na konsoli wyświetliło. Jeśli był cykl 1 2 3 .... 11 12, tzn., że w miejscu w którym stałem jak nadawano cyfry 4 5 6 7 8 9 10 sygnał nie doszedł i nie należało go brać pod uwagę do montażu docelowej stacji meteo. Wiatromierz montowałem na chwycie antenowym. Średnica rur od stacji była mniejsza więc wkładając ją uzupełniłem całość pianką montażową by nie latało. Rezultat był taki, że moduł z wbudowaną anteną za oknem 3m tracił zasięg drugi miał sygnał spokojnie do ok 10m (nawet przez ściany). Po teście wysłania danych i odebrania jednej danej na wordpresie przytępiono do montażu stacji. Jej finalna konfiguracja to Arduino Pro Mini 328 - 5V/16MHz Konwerter USB-UART FTDI FT232RL - gniazdo miniUSB (programator i zasilanie) nRF24L01+ Stacja meteo dfrobot PMS5003 (czujnik pyłu) Gravity (czujnik pyłu) MCP9808 (temperatura) SHT 31 (wigotność) BMP180 (ciśnienie) Dorzuciłem dwa czujniki pyły by porównać ich działanie. Jako końcowy element została mi kwestia wyświetlenia danych na stronie www. Dzięki wtyczce do pisania skryptów php w wordpresie udało napisać moduł pobierania danych z bazy i jego wyświetlania. Wykresy były większym problemem. Darmowe wtyczki do wordpressa nie chcą pobierać danych z sql i są ciężko edytowalne preferują prace na .csv i najlepiej jakby je ręcznie przeładowywać. Finalnie użyłem do tego celu Google Charts (nota bene na których wiele darmowych wtyczek do wordpresa bazuje). Z racji, że nie jestem web-developerem było to moje pierwsze spotkanie z php oraz javascriptem na którym Google Charsty operują. Zmuszenie tego pracy odbyło się metodą prób i błędów ale efekt jest zadowalający. Mam wykresy z 24h, tygodnia i miesiąca. Problemy Kodowanie int w arduino i malince Ze względu za na sposób kodowania liczny int w pythonie ujemne wartości temperatury np -5C na arduino pokazywały na malince wartość 65531 C. Trzeba było dopisać fragment który usuwał ten błąd. Komunikacja L01+ Moduły te są bardzo wrażliwe na zmiany napięcia. Można do nich dokupić adapter do wpięcia który głównie ma stabilizator napięcia. Nawet nie zawsze on pomaga jeśli do niego pójdzie nie wystarczające napięcie. Widać to np. jak się rusza kable to migocze LED lub jest "ciut" jaśniejszy. Wtedy anteny nie mogą się dogadać. Potrafi się zdarzyć takie kuriozum, że w takiej sytuacji antena straci własny adres. Jeśli anteny nie są w stanie się dogadać należy bezwzględnie sprawdzić pewność zasilania. Błąd wysłania danych SQL Czasami kod w malince się zawiesi w oczekiwaniu na wysłanie danych do serwera SQL. Trudno mi powiedzieć jak dobrze temu zaradzić. Występuję to przy dłuższej pracy (tydzień, miesiąc) aczkolwiek jedyne co mi przychodzi do głowy to ustawić na Raspianie auto-restart systemu co 24h. Wycinanie dziur w plastikowej obudowie Próbowałem wycinać szlifierką modelarską ale zawsze plastik się topił. Po szperaniu w necie rozwiązaniem są albo nożyki do plastiku albo wycinarka włosowa do plastiku ale nie udało mi się tego przetestować. Niestety wycięcia wyglądają mało estetycznie ale trudno. Google Charts Przesyłanie danych z PHP do JavaScript tak aby Google bylo problemem. Wykresy nie łykną dowolnego formatu danych i nie wyświetlą błędy jeśli uznają, że format im nie pasuje. Co mógłbym zrobić inaczej? Gdybym miał robić update to zamiast komunikacji radiowej do malinki wydaje mi się bardziej rozsądne pójście w wyposażenie arduino w WIFI i wysyłanie bezpośrednio na serwer. Nie uczyniłem tak ze względu na to pisanie kodu komunikacji Arduino WIFI nie jest to pare linijek. Plus też kod do wysyłania do SQL który znalazłem też pewnie by zawierał trochę kodu. Więcej dłubania ale efekt powinien być bardziej zadowalający. Plany na przyszłość Jedyne co chce na dniach zrobić to poduczyć się Eagla i przenieść całość na płytkę drukowaną i zamówić ją np. JLCPCB. Wtedy wypnę moduły z tamtych płytek i przypnę je do zamówionej. Reasumując Stacja działa już ok 6 miesięcy. Bez problemowo. Jak widać na wykresie z ostatniego miesiąca (tj. 26.12.2018 - 25.12.2019), że normy dla smogu w mojej wsi były w paru dniach przekroczone (a mieszkam w centrum pomorskiego bez kopalni, ciężkiego przemysłu wokół). Gdyby dobrze opisać każdy etap pracy można by z tego zrobić osobny kurs Poniżej kody źródłowe Arduino Ras PI Wordpress pobieranie suchych danych Wordpress pobieranie danych i osadzenie ich na Google Charts //Autor Bartosz Jakusz. Można wykorzystywać komercyjnie. Proszę tylko podać autora kodu #include <math.h> #include <Wire.h> #include <Arduino.h> #include <Adafruit_BMP085.h> #include <SoftwareSerial.h> #include <SPI.h> #include <nRF24L01.h> #include <RF24.h> #include "Adafruit_SHT31.h" #include "Adafruit_MCP9808.h"7 #define dataSize 16 #define PMS5003BufferSize 40 #define dustGravityBufferSize 32 Adafruit_BMP085 bmp; Adafruit_MCP9808 tempsensor = Adafruit_MCP9808(); Adafruit_SHT31 sht31 = Adafruit_SHT31(); // software serial #2: RX = digital pin 8, TX = digital pin 9 SoftwareSerial Serial1(4, 5); SoftwareSerial Serial3(8, 9); SoftwareSerial Serial2(3, 2); RF24 radio(10, 14); // CE, CSN const byte address[6] = "00001"; char col; unsigned int dustSensor25 = 0,dustSensor10 = 0; unsigned int PMS = 0,PM10 = 0, formalin = 0,CR1 = 0,CR2 = 0; float PMSTemp = 0, PMSHigro = 0; bool readErr = false, readErr25 = false; int dustSensorReadError = 0; unsigned int higherBit = 0, LowerBit = 0; unsigned char buffer_RTT[40]={}; //Serial buffer; Received Data char meteoDatabuffer[35]; int measurments [dataSize]; void readPMS(); void readPM25(); void readDustSensorUARTData(SoftwareSerial S, unsigned char *bufferData, int bufferSize); unsigned int mergeBitsToInt(unsigned char *bufferData, int startBit, int stopBit); void clearBuffer(unsigned char *bufferData); void calculateControlSum(unsigned int &CR1Var, unsigned int &CR2Var, unsigned char *bufferData, int bufferSize); void encageDustSensorReadError(); void printUARTRecievedData(); void readMeteoStation(); int transCharToInt(char *_buffer,int _start,int _stop); //char to int) void sendData(); void printSendedData(); void printDataBySensor(); void setup() { Serial.begin(115000); Serial.println("start"); Serial1.begin(9600); Serial1.setTimeout(1500); delay(2000); Serial2.begin(9600); Serial2.setTimeout(1500); delay(1000); Serial3.begin(9600); Serial3.setTimeout(1500); radio.begin(); radio.setPALevel(RF24_PA_MAX); radio.setDataRate(RF24_1MBPS); radio.setChannel(0x76); radio.openWritingPipe(0xF0F0F0F0E1LL); radio.enableDynamicPayloads(); radio.stopListening(); if (!bmp.begin()) { while (1) {} } if (!tempsensor.begin()) { while (1); } if (! sht31.begin(0x44)) { // Set to 0x45 for alternate i2c addr while (1) delay(1); } Serial.println("Zakończony Init"); delay(2000); } void loop() { readPMS(); readPM25(); readMeteoStation(); printDataBySensor(); if(readErr == false && readErr25 == false) { //Serial.println("Wysyłam dane"); sendData(); //Serial.print("Wysłano dane: "); } delay(1000); } void readPMS() { Serial.println("Czujnik pm5003"); readDustSensorUARTData(Serial1, buffer_RTT, PMS5003BufferSize); calculateControlSum(CR1, CR2, buffer_RTT, PMS5003BufferSize); if(CR1 == CR2 && CR1 != 0) //Check { PMS = mergeBitsToInt(buffer_RTT, 12, 13); PM10 = mergeBitsToInt(buffer_RTT, 14, 15); formalin = mergeBitsToInt(buffer_RTT, 28, 29); PMSTemp = mergeBitsToInt(buffer_RTT, 30, 31) / 10; PMSHigro = mergeBitsToInt(buffer_RTT, 32, 33) / 10; readErr = false; } else { PMS = 4321; PM10 = 4321; formalin = 4321; encageDustSensorReadError(); } clearBuffer(buffer_RTT); } void readPM25() { Serial.println("Czujnik p, 25"); readDustSensorUARTData(Serial3, buffer_RTT, dustGravityBufferSize); calculateControlSum(CR1, CR2, buffer_RTT, dustGravityBufferSize); if(CR1 == CR2 && CR1 != 0) //Check { dustSensor25 = mergeBitsToInt(buffer_RTT, 6, 7); dustSensor10 = mergeBitsToInt(buffer_RTT, 8, 9); readErr25 = false; } else { dustSensor25 = 4321; dustSensor10 = 4321; encageDustSensorReadError(); } clearBuffer(buffer_RTT); } void readDustSensorUARTData(SoftwareSerial S, unsigned char *bufferData, int bufferSize) { S.listen(); while(!S.available()); while(S.available()>0) //Data check: weather there is any Data in Serial1 { col =S.read(); delay(2); if (col == 0x42) { bufferData[0]=(char)col; col =S.read(); delay(2); if (col == 0x4d) { bufferData[1]=(char)col; for(int i = 2; i < bufferSize; i++) { col =S.read(); bufferData[i]=(char)col; delay(2); } break; } } S.flush(); } } unsigned int mergeBitsToInt(unsigned char *bufferData, int startBit, int stopBit) { higherBit = buffer_RTT[startBit]; //Read PM2.5 High 8-bit LowerBit = buffer_RTT[stopBit]; //Read PM2.5 Low 8-bit return (higherBit << 8) + LowerBit; } void clearBuffer(unsigned char *bufferData) { for(int i = 0; i < 40; i++) { bufferData[i] = 0; } delay(100); } void calculateControlSum(unsigned int &CR1Var, unsigned int &CR2Var, unsigned char *bufferData, int bufferSize) { CR1Var = 0; CR2Var = 0; CR1Var =(buffer_RTT[bufferSize - 2]<<8) + buffer_RTT[bufferSize - 1]; for(int i = 0; i < bufferSize - 2; i++) { CR2Var += bufferData[i]; } } void encageDustSensorReadError() { dustSensorReadError = dustSensorReadError + 1; readErr = true; readErr25 = true; Serial.print("Błąd odczytu: "); Serial.println(dustSensorReadError); //printUARTRecievedData(); } void readMeteoStation() { Serial.println("Stacja meteo nasłuchuje"); Serial2.listen(); while(!Serial2.available()); while(Serial2.available()>0) //Data check: weather there is any Data in Serial1 { Serial.println("Start meteo"); for (int index = 0;index < 35;index ++) { if(Serial2.available()) { meteoDatabuffer[index] = Serial2.read(); if (meteoDatabuffer[0] != 'c') { //Serial.println("Transmisja w toku meteo"); index = -1; } } else { index --; } } } Serial.println("Koniec"); } int transCharToInt(char *_buffer,int _start,int _stop) { //char to int) int result = 0; int num = _stop - _start + 1; int tempArr[num]; for (int indx = _start; indx <= _stop; indx++) { tempArr[indx - _start] = _buffer[indx] - '0'; result = 10 * result + tempArr[indx - _start]; } return result; } void sendData(){ for(int z = 0; z < dataSize; z++) { measurments[z] = -1000; } //Meteo station measurments[0] = (int)(transCharToInt(meteoDatabuffer,1,3)); //wind directoin measurments[1] = (int)(transCharToInt(meteoDatabuffer,28,32) / 10.00); //pressure //measurments[2] = (int)(((transCharToInt(meteoDatabuffer,13,15) - 32.00) * 5.00 / 9.00) * 100); //temp *C //measurments[3] = (int)((transCharToInt(meteoDatabuffer,25,26)) * 100); //higro %RH measurments[2] = (int)((transCharToInt(meteoDatabuffer,5,7) / 0.44704) * 100); //avg wind speed 1 min (m/s) measurments[3] = (int)((transCharToInt(meteoDatabuffer,9,11) / 0.44704) * 100); //max wind speed 5min (m/s) measurments[4] = (int)((transCharToInt(meteoDatabuffer, 17, 19) * 25.40 * 0.01) * 100); // rain 1 hour (mm) measurments[5] = (int)((transCharToInt(meteoDatabuffer, 21, 23) * 25.40 * 0.01) * 100); // rain 24 hour (mm) //MCP9008 measurments[6] = (int)(tempsensor.readTempC() * 100); //SHT31 measurments[7] = (int)(sht31.readHumidity() * 100); measurments[8] = (int) (sht31.readTemperature()* 100); //PMS5003 //measurments[11] = PMSTemp * 100; //measurments[12] = PMSHigro * 100; measurments[9] = PMS; measurments[10] = PM10; measurments[11] = formalin; //PM2,5 Gravity measurments[12] = dustSensor25; measurments[13] = dustSensor10; //BMP180 measurments[14] = bmp.readPressure() / 100; //measurments[19] = (int) (bmp.readTemperature() * 100); measurments[15] = 666; int testMe = 0; for(int k = 0; k < 15; k++) { testMe += measurments[k]; } Serial.print("PRZYKLADOWA CHECK SUMA: "); Serial.println(testMe); radio.write(&measurments, sizeof(measurments)); printSendedData(); } void printSendedData() { Serial.println("Wysłano następujące dane:"); for (int i = 0; i < dataSize; i++) { Serial.print(measurments[i]); Serial.print(" "); } Serial.println(); } void printUARTRecievedData() { byte b; for(int i=0;i<32;i++) { b = (byte)buffer_RTT[i]; //buffer_RTT[i] = 0; Serial.print(b, HEX); Serial.print(" "); } Serial.print("CR1: "); Serial.print(CR1); Serial.print(" = "); Serial.println(CR2); } void printDataBySensor() { Serial.println(); Serial.println("MCP9808: "); Serial.print("Temperatura: "); float c = tempsensor.readTempC(); Serial.print(c); Serial.println("*C"); Serial.println(); Serial.println("SHT31: "); Serial.print("Wilgotność: "); Serial.print(sht31.readHumidity()); Serial.println("%RH"); Serial.print("Temperatura: "); Serial.print(sht31.readTemperature()); Serial.println("*C"); Serial.println(); Serial.println("BMP180: "); Serial.print("Temperatura: "); float bmpTemp = bmp.readTemperature(); Serial.print(bmpTemp); Serial.println("*C"); Serial.print("Ciśnienie: "); Serial.print(bmp.readPressure() / 100); Serial.println("hPa"); Serial.print("Teoretyczna wysokość: "); Serial.print(bmp.readAltitude(101100)); Serial.println("m.n.p.m"); Serial.println(); Serial.println("PMS5003:"); Serial.print("PM 2,5: "); Serial.print(PMS); Serial.println(" /25 ug/m3 "); Serial.print("PM 10 : "); Serial.print(PM10); Serial.println(" /50 ug/m3 "); Serial.print("Formaldehyd : "); Serial.print(formalin); Serial.println(" ug/m3 "); Serial.print("Temperatura: "); Serial.print(PMSTemp); Serial.println("*C"); Serial.print("Wilgotność: "); Serial.print(PMSHigro); Serial.println("%RH"); Serial.println(); Serial.println("PM 2,5 GRAVITY:"); Serial.print("PM 2,5: "); Serial.print(dustSensor25); Serial.println(" /25 ug/m3 "); Serial.print("PM 10 : "); Serial.print(dustSensor10); Serial.println(" /50 ug/m3 "); Serial.println(); Serial.println("STACJA METEO: "); Serial.print("Temperatura: "); c = (transCharToInt(meteoDatabuffer,13,15) - 32.00) * 5.00 / 9.00; Serial.print(c); Serial.println("*C"); Serial.print("Wilgotnosc: "); float metHigro = transCharToInt(meteoDatabuffer,25,26); Serial.print(metHigro); Serial.println("%RH"); Serial.print("Cisnienie: "); float pp = transCharToInt(meteoDatabuffer,28,32) / 10.00; Serial.print(pp); Serial.println("hPa"); Serial.print("Predkośc wiatru: "); float w = transCharToInt(meteoDatabuffer,5,7) / 0.44704; Serial.print(w); Serial.println("m/s"); Serial.print(" "); w = w * 3.6; Serial.print(w); Serial.println("km/h"); Serial.print("Max Predkośc wiatru: "); float m = transCharToInt(meteoDatabuffer,9,11) / 0.44704; Serial.print(m); Serial.println("m/s (ostatnie 5 minut)"); Serial.print(" "); m = m * 3.6; Serial.print(m); Serial.println("km/h (ostatnie 5 minut)"); Serial.print("Kierunek wiatru: "); Serial.print(transCharToInt(meteoDatabuffer,1,3)); Serial.println("C"); Serial.print("Opad (1h): "); float rain1 = transCharToInt(meteoDatabuffer, 17, 19) * 25.40 * 0.01; Serial.print(rain1); Serial.println("mm"); Serial.print("Opad (24h): "); float rain24 = transCharToInt(meteoDatabuffer, 21, 23) * 25.40 * 0.01; Serial.print(rain24); Serial.println("mm"); Serial.println(); } #Autor Bartosz Jakusz. Można replikować nawet w celach komercyjnych. Tylko umieścić autora kodu. import RPi.GPIO as GPIO from lib_nrf24 import NRF24 import time import spidev import struct import os import mysql.connector from mysql.connector import errorcode from datetime import date, datetime, timedelta GPIO.setmode(GPIO.BCM) pipes = [[0xE8, 0xE8, 0xF0, 0xF0, 0xE1], [0xF0, 0xF0, 0xF0, 0xF0, 0xE1]] radio = NRF24(GPIO, spidev.SpiDev()) radio.begin(0, 17) radio.setPayloadSize(32) radio.setChannel(0x76) radio.setDataRate(NRF24.BR_1MBPS) radio.setPALevel(NRF24.PA_MAX) radio.setAutoAck(True) radio.enableDynamicPayloads() radio.enableAckPayload() i = 0 j = 0 sucRate = 0 errRate = 0 totalRec = 0 try: while True: radio.openReadingPipe(1, pipes[1]) #radio.printDetails() radio.startListening() print(" ") print(datetime.now()) radio.print_address_register("RX_ADDR_P0-1", NRF24.RX_ADDR_P0, 2) radio.print_address_register("TX_ADDR", NRF24.TX_ADDR) j = 0 while not radio.available(0): j = j + 1 receivedMessage = [] radio.read(receivedMessage, radio.getDynamicPayloadSize()) radio.stopListening() print("Received: {}".format(receivedMessage)) string = "" floatBytes = [] indx = 0 while indx < 4: floatBytes.append(0) indx = indx + 1 measurments = [] indx = 0 mIndx = 0 tmpStr= "" tmpIndx = 0 crc = 0 if not receivedMessage: print("pusto wywalam sie") else: for n in receivedMessage: #print(tmpIndx) tmpIndx = tmpIndx + 1 floatBytes.insert(indx, n) if(indx >= 1): b1 = floatBytes[0] b2 = floatBytes[1] host = 0 host = b2 host = host << 8 host = host | b1 if(mIndx == 6): print("trt {}".format(host)) if(host > 65536 / 2): host = (65536 - host) * (-1) print("trti {}".format(host)) tmpVar = host / 100 print("trtf {}".format(tmpVar)) elif(mIndx >= 2 and mIndx < 5 or mIndx >= 7 and mIndx <= 8): tmpVar = host / 100 else: tmpVar = host indx = 0 measurments.append(tmpVar) mIndx = mIndx + 1 else: indx = indx + 1 totalRec = totalRec + 1 print(" ") if(host == 666): sucRate = sucRate + 1 print("Odebrano z sukcesem {}/{} transmisji".format(sucRate, totalRec)) try: print("Zaczynamy łacznie z baza") cnx = mysql.connector.connect(host='00.00.00.00',database='db') cursor = cnx.cursor() print("Połączono z baza") #zapytania SQL add_probeTime = ("INSERT INTO MeasrumentDateTime" "(time, date)" "VALUES (%s, %s)") add_MCP8006 = ("INSERT INTO MCP8006 " "(temperature, MeasrumentDateTime_ID) " "VALUES (%(temperature)s, %(timeID)s)") add_SHT31 = ("INSERT INTO SHT31 " "(humidity, temperature, MeasrumentDateTime_ID) " "VALUES (%(humidity)s ,%(temperature)s, %(timeID)s)") add_BMP180 = ("INSERT INTO BMP180" "(pressure, MeasrumentDateTime_ID) " "VALUES (%(pressure)s, %(timeID)s)") add_PMS5003 = ("INSERT INTO PMS5003" "(pm25, pm10, formaldehyd, MeasrumentDateTime_ID) " "VALUES (%(pm25)s, %(pm10)s, %(formaldehyd)s,%(timeID)s)") add_PMGravity = ("INSERT INTO PM25" "(PM25, PM10, MeasrumentDateTime_ID) " "VALUES (%(pm25)s, %(pm10)s, %(timeID)s)") add_meteoSation = ("INSERT INTO MeteoStation" "(windDirection, avgWindSpeedPerMinute, avgWindSpeedPerFiveMinutes, rainfallOneHour, rainfal24Hours, pressure, MeasrumentDateTime_ID) " "VALUES (%(windDir)s, %(avgWind)s, %(maxWind)s, %(rain1h)s, %(rain24h)s, %(pressure)s, %(timeID)s)") #Dodaj obecna godzine currentTimeAndDate = datetime.now() formatted_time = currentTimeAndDate.strftime('%H:%M:%S') currentDate = datetime.now().date() toSendSampleDate = (formatted_time, currentDate) cursor.execute(add_probeTime, toSendSampleDate) sampleTimeID = cursor.lastrowid #Wyslij do bazy MySql dane czujnik temp MCP8006Data = { 'timeID' : sampleTimeID, 'temperature' : measurments[6], } cursor.execute(add_MCP8006, MCP8006Data) #Wyslij do bazy MySql dane higrometr SHT 31 SHT31Data = { 'timeID' : sampleTimeID, 'humidity' : measurments[7], 'temperature' : measurments[8], } cursor.execute(add_SHT31, SHT31Data) #Wyslij do bazy MySql dane barometr BMP180 BMP180Data = { 'timeID' : sampleTimeID, 'pressure' : measurments[14], } cursor.execute(add_BMP180, BMP180Data) #Wyslij do bazy MySql dane czujnik pylu PMS5003 PMS5003Data = { 'timeID' : sampleTimeID, 'pm25' : measurments[9], 'pm10' : measurments[10], 'formaldehyd' : measurments[11], } cursor.execute(add_PMS5003, PMS5003Data) #Wyslij do bazy MySql dane czujnik pylu PM 2,5 Gravity PMGravityData = { 'timeID' : sampleTimeID, 'pm25' : measurments[12], 'pm10' : measurments[13], } cursor.execute(add_PMGravity, PMGravityData) #Wyslij do bazy MySql dane stacja meteo metStationData = { 'timeID' : sampleTimeID, 'windDir' : measurments[0], 'avgWind' : measurments[2], 'maxWind' : measurments[3], 'rain1h' : measurments[4], 'rain24h' : measurments[5], 'pressure' : measurments[1], } cursor.execute(add_meteoSation, metStationData) print("Wysylanie danych na serwer") cnx.commit() cursor.close() print("Wyslano do bazy pomyslnie dane") except mysql.connector.Error as err: if err.errno == errorcode.ER_ACCESS_DENIED_ERROR: print("Something is wrong with your user name or password") elif err.errno == errorcode.ER_BAD_DB_ERROR: print("Database does not exist") else: print(err) else: cnx.close() time.sleep(14) else: print("BLAD TRANSMISJI: nie zgadza sie suma kontrolna") #errRate = errRate + 1 #print("Żle odebrano {}/{} transmisji".format(errRate, totalRec)) print(" ") print("------------------------------------------") #radio.closeReadingPipe(pipes[1]) #radio.stopListening() time.sleep(1) except KeyboardInterrupt: print(i) except: # this catches ALL other exceptions including errors. # You won't get any error messages for debugging # so only use it once your code is working print ("Other error or exception occurred!") finally: GPIO.cleanup() # this ensures a clean exit echo"Autor Bartosz Jakusz. Można wykorzystywać komercyjnie. Wsakazać tylko autora kodu. "; $mydb = new wpdb('usr_db','db','localhost'); $currentTime = $mydb->get_results("SELECT time, date FROM MeasrumentDateTime ORDER BY ID DESC LIMIT 1"); $tempData = $mydb->get_results("SELECT temperature FROM MCP8006, MeasrumentDateTime WHERE MeasrumentDateTime_ID = MeasrumentDateTime.ID ORDER BY MeasrumentDateTime.ID DESC LIMIT 1"); $higroData = $mydb->get_results("SELECT humidity FROM SHT31, MeasrumentDateTime WHERE MeasrumentDateTime_ID = MeasrumentDateTime.ID ORDER BY MeasrumentDateTime.ID DESC LIMIT 1"); $pressureData = $mydb->get_results("SELECT pressure FROM BMP180, MeasrumentDateTime WHERE MeasrumentDateTime_ID = MeasrumentDateTime.ID ORDER BY MeasrumentDateTime.ID DESC LIMIT 1"); $pms5003Data = $mydb->get_results("SELECT pm25, pm10, formaldehyd FROM PMS5003, MeasrumentDateTime WHERE MeasrumentDateTime_ID = MeasrumentDateTime.ID ORDER BY MeasrumentDateTime.ID DESC LIMIT 1"); $gravityData = $mydb->get_results("SELECT PM25, PM10 FROM PM25, MeasrumentDateTime WHERE MeasrumentDateTime_ID = MeasrumentDateTime.ID ORDER BY MeasrumentDateTime.ID DESC LIMIT 1"); $metStationData = $mydb->get_results("SELECT windDirection, avgWindSpeedPerMinute, avgWindSpeedPerFiveMinutes, rainfallOneHour, rainfal24Hours FROM MeteoStation, MeasrumentDateTime WHERE MeasrumentDateTime_ID = MeasrumentDateTime.ID ORDER BY MeasrumentDateTime.ID DESC LIMIT 1"); $avgkmPerHour = $metStationData[0]->avgWindSpeedPerMinute * 3.6; $maxkmPerHour = $metStationData[0]->avgWindSpeedPerFiveMinutes * 3.6; echo "<table>"; echo"<col width=50%>"; echo"<tr>"; echo"<th>Ostatni pomiar z: </th>"; echo"<th></th>"; echo"</tr>"; echo"<tr>"; echo"<th>".$currentTime[0]->time." </th>"; echo"<th>".$currentTime[0]->date." </th>"; echo"</tr>"; echo"</table>"; echo "<br>"; echo "<br>"; $dir = $metStationData[0]->windDirection; $dirName = ""; if ($dir < 45) { $dirName = "Północny"; } elseif ($dir >= 45 or $dir < 90 ) { $dirName = "Północno-Wschodni"; } elseif ($dir >= 90 or $dir < 135 ) { $dirName = "Wschodni"; } elseif ($dir >= 135 or $dir < 180 ) { $dirName = "Południowo-Wschodni"; } elseif ($dir >= 180 or $dir < 225 ) { $dirName = "Południowy"; } elseif ($dir >= 225 or $dir < 270 ) { $dirName = "Południowo-Zachodni"; } elseif ($dir >= 270 or $dir < 315 ) { $dirName = "Zachodni"; } else { $dirName = "Północno-Zachodni"; } echo "<table>"; echo"<col width=50%>"; echo"<tr>"; echo"<th>Temperatura: </th>"; echo"<th>".$tempData[0]->temperature."*C </th>"; echo"</tr>"; echo"<tr>"; echo"<th>Wilgotność: </th>"; echo"<th>".$higroData[0]->humidity."%RH </th>"; echo"</tr>"; echo"<tr>"; echo"<th>Ciśnienie: </th>"; echo"<th>".$pressureData[0]->pressure."hPa </th>"; echo"</tr>"; echo"</table>"; echo "<br>"; echo "<br>"; echo "<table>"; echo"<col width=50%>"; echo"<tr>"; echo"<th>Czystość powietrza: </th>"; echo"<th></th>"; echo"</tr>"; echo"<tr>"; echo"<th>PM 2,5 - norma 25ug/m3: </th>"; echo"<th></th>"; echo"</tr>"; echo"<tr>"; echo"<th>PMS5003: </th>"; echo"<th>".$pms5003Data[0]->pm25."ug/m3</th>"; echo"</tr>"; echo"<tr>"; echo"<th>Gravity: </th>"; echo"<th>".$gravityData[0]->PM25."ug/m3</th>"; echo"</tr>"; echo"</tr>"; echo"<tr>"; echo"<th><br></th>"; echo"<th><br></th>"; echo"</tr>"; echo"</tr>"; echo"<tr>"; echo"<th>PM 10 - norma 50ug/m3</th>"; echo"<th></th>"; echo"</tr>"; echo"<tr>"; echo"<th>PMS5003: </th>"; echo"<th>".$pms5003Data[0]->pm10."ug/m3 </th>"; echo"</tr>"; echo"<tr>"; echo"<th>Gravity: </th>"; echo"<th>".$gravityData[0]->PM10."ug/m3 </th>"; echo"</tr>"; echo"<tr>"; echo"<th><br></th>"; echo"<th><br></th>"; echo"</tr>"; echo"</tr>"; echo"<tr>"; echo"<th>Formaldehyd</th>"; echo"<th></th>"; echo"</tr>"; echo"<tr>"; echo"<th>PMS5003: </th>"; echo"<th>".$pms5003Data[0]->formaldehyd."ug/m3 </th>"; echo"</tr>"; echo"</table>"; echo "<br>"; echo "<br>"; echo "<table>"; echo"<col width=50%>"; echo"<tr>"; echo"<th>Stacja Meteo: </th>"; echo"<th></th>"; echo"</tr>"; echo"<tr>"; echo"<th>Kierunek Wiatru: </th>"; echo"<th>".$dirName."</th>"; echo"</tr>"; echo"<tr>"; echo"<th><br></th>"; echo"<th><br></th>"; echo"</tr>"; echo"<tr>"; echo"<th>Średnia prędkość wiatru (ostatnia minuta): </th>"; echo"<th></th>"; echo"</tr>"; echo"<tr>"; echo"<th> </th>"; echo"<th>".$metStationData[0]->avgWindSpeedPerMinute."m/s</th>"; echo"</tr>"; echo"<tr>"; echo"<th> </th>"; echo"<th>".$avgkmPerHour."km/h</th>"; echo"</tr>"; echo"</tr>"; echo"<tr>"; echo"<th><br></th>"; echo"<th><br></th>"; echo"</tr>"; echo"</tr>"; echo"<tr>"; echo"<th>Max prędkość wiatru (ostatnie 5 min)</th>"; echo"<th></th>"; echo"</tr>"; echo"<tr>"; echo"<th> </th>"; echo"<th>".$metStationData[0]->avgWindSpeedPerFiveMinutes."m/s</th>"; echo"</tr>"; echo"<tr>"; echo"<th> </th>"; echo"<th>".$maxkmPerHour."km/h</th>"; echo"</tr>"; echo"<tr>"; echo"<th><br></th>"; echo"<th><br></th>"; echo"</tr>"; echo"</tr>"; echo"<tr>"; echo"<th>Opad atmosferyczny</th>"; echo"<th></th>"; echo"</tr>"; echo"<tr>"; echo"<th>Ostatnia godzina: </th>"; echo"<th>".$metStationData[0]->rainfallOneHour."mm</th>"; echo"</tr>"; echo"<tr>"; echo"<th>Ostatnia doba: </th>"; echo"<th>".$metStationData[0]->rainfal24Hours."mm </th>"; echo"</tr>"; echo"</table>"; echo"Autor Bartosz Jakusz. Można wykorzystywać komercyjnie. Wsakazać tylko autora kodu. "; $mydb = new wpdb('usr_db','db','localhost'); $pm25DataPMS5003 = $mydb->get_results("SELECT time, date, round(avg(pm25), 0) as pm25PMSMonth FROM PMS5003, MeasrumentDateTime WHERE TIMESTAMP(date, time) > NOW() - INTERVAL 1 MONTH and MeasrumentDateTime_ID = MeasrumentDateTime.ID group by DAY(TIMESTAMP(date, time)) ORDER BY MeasrumentDateTime.ID"); $pm25DataGravity = $mydb->get_results("SELECT time, date, round(avg(PM25.PM25),0) as pm25GravMonth FROM PM25, MeasrumentDateTime WHERE TIMESTAMP(date, time) > NOW() - INTERVAL 1 MONTH and MeasrumentDateTime_ID = MeasrumentDateTime.ID group by DAY(TIMESTAMP(date, time)) ORDER BY MeasrumentDateTime.ID"); $tmpPM25 = []; $i = 0; $someRandData = 25; foreach ($pm25DataGravity as $obj) : array_push($tmpPM25, array(substr((string)$obj->date,5)." ".substr((string)$obj->time,0,-9), (float)$obj->pm25GravMonth, (float)$pm25DataPMS5003[$i]->pm25PMSMonth, (float)$someRandData )); $i++; endforeach; echo"<div id='pm25ChartMonth'></div>"; ?> <script type="text/javascript" src="https://www.gstatic.com/charts/loader.js"></script> <script type="text/javascript"> var pm25 = <?php echo json_encode($tmpPM25); ?>; google.charts.load('current', {packages: ['corechart', 'line']}); google.charts.setOnLoadCallback(drawBasic); function drawBasic() { var data = new google.visualization.DataTable(); data.addColumn('string', 'Last Hour'); data.addColumn('number', 'Gravity'); data.addColumn('number', 'PMS5003'); data.addColumn('number', 'Norma'); data.addRows(pm25); var options = { 'title':'Zaniczyszczenie PM 2,5 ostatni miesiąc', 'curveType': 'function', hAxis: { title: 'Godzina' }, vAxis: { title: 'um/m3' }, height: 500 }; var chart = new google.visualization.LineChart(document.getElementById('pm25ChartMonth')); chart.draw(data, options); } </script>
  20. 3 punkty
    Może zamiast się spierać kto ma więcej racji, warto byłoby wyjaśnić całe zamieszanie. Żadna metoda nie jest lepsza, ani jedynie słuszna. W przypadku Raspberry i Raspbiana znajdziemy gotowe narzędzie, czyli raspi-config, które można, a ale wcale nie trzeba używać. Natomiast na pewno warto zrozumieć jako ono działa. Otóż jest to prosty skrypt, kod odpowiedzialny za zmianę hasła (https://github.com/asb/raspi-config/blob/master/raspi-config) wygląda następująco: do_hostname() { if [ "$INTERACTIVE" = True ]; then whiptail --msgbox "\ Please note: RFCs mandate that a hostname's labels \ may contain only the ASCII letters 'a' through 'z' (case-insensitive), the digits '0' through '9', and the hyphen. Hostname labels cannot begin or end with a hyphen. No other symbols, punctuation characters, or blank spaces are permitted.\ " 20 70 1 fi CURRENT_HOSTNAME=`cat /etc/hostname | tr -d " \t\n\r"` if [ "$INTERACTIVE" = True ]; then NEW_HOSTNAME=$(whiptail --inputbox "Please enter a hostname" 20 60 "$CURRENT_HOSTNAME" 3>&1 1>&2 2>&3) else NEW_HOSTNAME=$1 true fi if [ $? -eq 0 ]; then echo $NEW_HOSTNAME > /etc/hostname sed -i "s/127.0.1.1.*$CURRENT_HOSTNAME/127.0.1.1\t$NEW_HOSTNAME/g" /etc/hosts ASK_TO_REBOOT=1 fi } Czyli jak pewnie widać, zmiana nazwy hosta to dwie linijki: echo $NEW_HOSTNAME > /etc/hostname sed -i "s/127.0.1.1.*$CURRENT_HOSTNAME/127.0.1.1\t$NEW_HOSTNAME/g" /etc/hosts A czy wolimy je wykonać z linii poleceń, skryptu czy gotowca, to już chyba bez różnicy.
  21. 3 punkty
  22. 3 punkty
    1) Prolog Cześć, dzisiaj opiszę wam mój projekt inżynierski w którym budowałem model autonomicznego pojazdu. W ramach pracy dyplomowej zaprojektowałem uproszczony model autonomicznego pojazdu. Model przystosowany jest do poruszania się w prostym środowisku testowym, symulującym prawdziwe otoczenie. Mój model wyposażony jest w kamerę, pozwalającą na pozyskiwanie informacji o otoczeniu. Obraz z kamery jest źródłem danych dla zaimplementowanej sieci neuronowej, która odpowiada za podejmowanie decyzji o kierunku przemieszczania się pojazdu. Całość pracy zawiera opis poszczególnych etapów tworzenia modelu, projektowanie architektury, implementacje oraz uczenie jednokierunkowych sieci neuronowych do prawidłowego działania. W projekcie użyłem Raspberry Pi, w którym została zaimplementowana sieć neuronowa stworzona w języku Python oraz Arduino odpowiedzialne za sterowanie podzespołami. Rozwiązanie zaproponowane w pracy opiera się szeregu transformacji obrazu za pomocą biblioteki OpenCV w celu ekstrakcji cech tak, aby sieć neuronowa otrzymywała tylko najistotniejsze informacje na podstawie których podejmie decyzje. 2) Wykorzystane elementy: Raspberry Pi B+ (chociaż lepsza była by Raspberry Pi 3b+) Raspberry Pi Cam 8Mpx Lego 42037 Lego Motor M Serwomechanizm SG90 (wymagało modyfikacji) Arduino UNO Rev3 Konwerter poziomów logicznych 2x18650 z rozbiórki laptopów + koszyk L298N - dwukanałowy sterownik silników - moduł 12V/2A 3) Przebieg Prac Praca nie determinowała typu modelu jaki zostanie opisany w pracy a jej głównym celem miało być czy implementacja w prosty sposób funkcji takich jak jazda na wprost, po łuku, skręt czy poruszanie się po okręgu jest możliwa do implementacji wykorzystując sieci neuronowe i wiedzę wyniesioną z toku studiów. W Pierwszej kolejności zrobiłem małe rozeznanie co do możliwości jakie mogłem wybrać i z grubsza można było je podzielić na 2 rodzaje: a) fizyczne - do których zaliczamy np przerobienie realnie istniejącego samochodu osobowego lub modelu pojazdu zdalnie sterowanego RC lub inne tego typu konstrukcje: b) software-owe - w skład których wchodzą takie propozycje jak: dedykowane symulatory, gry komputerowe (symulujemy wtedy klawisze które normalnie naciska gracz) lub własnoręcznie napisane programy do tego celu, np napisane w matlabie lub specjalna "gra" wykorzystana w tym celu. W moim przypadku realizowałem to w pojedynkę i ograniczały mnie dwa aspekty takie jak czas wykonania, koszt który musiał bym ponieść, oraz zasób wiedzy jaki trzeba było by do tego użyć dlatego musiałem znaleźć swojego rodzaju złoty środek którym był fizyczny model (bardziej namacalny) w pomniejszeniu czyli Model RC, ale ze nie posiadam żadnego modelu RC to wykorzystałem zestaw Lego 40237. 4) Hardware Podstawą pojazdu jest już wcześniej wspomniany zestaw Lego 42037 który posiada pewne braki i w tym rozdziale należało zabawkę z lego dostosować do potrzeb projektu. Głównym problemem był brak napędu oraz zdalnego sterowania, o ile z napędem na tylną oś poradziłem sobie bardzo szybko (były już w modelu półosie, dyferencjał i wał) i wystarczyło wstawić w odpowiednie miejsce kilka klocków i silnik Lego M to z układem kierowniczym trzeba było więcej się nagimnastykować. Aby przenie koła wprawić "w ruch" trzeba było znaleźć miejsce na serwomechanizm + zintegrować go z istniejącym układem kierowniczym, dodatkowym problemem był fakt że standardowe serwo ma "wyjście" na orczyk/ wieloklin) al układ kierowniczy lego był zakończony Axlem. Nie chciałem też ingerować i niszczyć klocków dlatego wykonałem nieinwazyjny adapter i skleiłem klejem na gorąco odpowiednio docięty orczyk z klockami które miały otwór na axle. W ten oto sposób nasza podstawa ma wyprowadzone 2 zestawy przewodów - jeden do Silnika napędowego a drugi do serwomechanizmu połączonego z układem napędowym. 5) Elektronika Teraz czas na elektronikę... która jest bardzo prosta bo w zasadzie sygnały sterujące musimy przesłać do 2 komponentów - silnika oraz serwa. W pierwotnym zamyśle było podłączenie bezpośrednio Raspberry Pi do tych 2 komponentów ale wiedziałem że "nie będzie czasu" na generowanie PWM softwareowo dla serwa + dla silnika napędowego dlatego zostało dołożone Arduino które potrafi to robić sprzętowo i odciąży Raspbery Pi od tego zadania. Zyskałem na tym niewielki wzrost skomplikowania elektroniki i oszczędziłem moc obliczeniową w Raspberry Pi. Z kolei silnik napędowy wymagał zastosowania "jakiegoś" mostka H aby nie upalić Raspberry bo wbrew pozorom Silnki z lego potrafią pobierać znaczącą ilość prądu ( więcej info można znaleźć tutaj ) dlatego wybór padł na wcześniej wymieniony gotowy moduł dwukanałowego (zostały zmostkowane oba kanały) mostka H - wystarczy teraz podać tylko odpowiedni sygnał PWM do mostka H i już mamy możliwość płynnej kontroli nad prędkością modelu. Ostatnim etapem było zestawienie komunikacji po porcie szeregowym Arduino z Raspberry Pi za pomocą portu szeregowego i w tym wypadku. Takie połączenie wymaga zastosowania konwertera poziomów logicznych gdyż Raspberry Pi toleruje tylko 3V3 volta a arduino daje 5V - gdyby tego nie było mogło by dojść do uszkodzenia Rarspberry Pi 6) Software I teraz to co tygryski lubią najbardziej - programowanie i tutaj jest podział na 2 części (ale nie mogę wrzucić tutaj kodów źródłowych) a) Arduino Dla Arduino został napisane proste API (ASCII) sterowane przez raspberry - oferowało zestaw prostych funkcji takich jak: - Ustaw silnik na x PWM (zakres 0-255) - Ustaw serwo na x PWM ( 0 - prawo, 90 - prosto, 180 - lewo) - START - Po tej komendzie można było uruchomić pojazd - STOP - powodowała zatrzymanie silnika i ustawienie serwa na 90 stopni (przygotowanie do jazdy na wprost) b) Raspberry Pi Zasada działania tego modelu wykorzystywała sieci neuronowe i nauczanie pod nadzorem nauczyciela ( w skrócie mamy 2 rodzaje uczenia sieci neuronowych - z wykorzystaniem nauczyciela czyli dajemy jakieś dane uczące, potem sprawdzamy na części danych kontrolnych i korygujemy tak długo aż osiągniemy dobre rezultaty i na koniec testujemy na nigdy nie używanych danych, same dane dzielimy w stosunku 4-1-1. Druga opcja to bez nauczyciela i sieć musi nauczyć się sama i jest to o wiele bardziej skomplikowane). Uproszczony schemat działania programu: Aby to działało musimy zaprojektować sieć ( u mnie rozważyłem kilka przypadków) i jest to zależne od ilości wejść i tego co chcemy uzyskać na wyjściu czyli sygnał sterujący w najprostszej wersji może to wykorzystywać kilka neuronów a najbardziej skomplikowane mogą ich mieć dziesiątki tysięcy ( w różnych warstwach) jednak korzystając z Raspbery Pi mamy ograniczą moc obliczeniową i musiałem ułatwić analizę i pracę sieci. Dlatego dokonałem ekstrakcji danych z obrazu i wstępnego przetworzenia w OpenCV gdzie pozyskuje informacje o położeniu linii drogi którą ma podążać: Idąc od lewej - obraz widziany przez kamerę, dalej sektory które obserwujemy aby dokonać analiz "ucieczki linii", trzeci obrazek to binaryzacja i wykrycie gdzie aktualnie znajduje się linia i jak "ucieka" aby można było określić w którą stronę należy skręcić aby jechać prosto. Dzięki temu na wejściu sieci neuronowej podajemy jedynie 2 parametry (położenie lewej i położenie prawej linii) co znacząco ułatwia obliczenia i projekt sieci. Mając te informacje zbieramy dane z przejazdów i zachowania linii podczas konkretnych manewrów np jazda na wprost, po łuku itp. I zapisujemy do pliku - co ważne w tym momencie sterujemy robotem ręcznie i od naszej precyzji sterowania zależeć będa w dużej mierze efekty jakie uzyskamy. Po zebraniu danych możemy przejść dalej. Uczenie sieci: Realizowałem w matlabie i toolboxie z sieciami neuronowymi i tam testowałem jak wyglądają efekty uczenia a następnie eksprtowałem sieć (sieć to tak naprawdę liczby które decydują o "wadze" neuronu poszczególnego) do własnej implementacji w pythonie i testowałem w realu co było pracochłonne. I tak aż do skutku i poprawiałem błędy aż do uzyskania efektu zadowalającego . Na koniec zostały przeprowadzone eksperymenty jak sieć radzi sobie z poszczególnymi testami. 7) Co bym zrobił inaczej W wersji 2.0 lub po prostu gdybym zaczął robić projekt od nowa zmienił bym niestety dosyć dużo widząc jakie braki / niepotrzebne problemy napotkałem na drodze: Rozwiązanie z modelem było dobre - jednak lepiej było do tego celu wykorzystać nie lego a model RC z uwagi na łatwiejszą integrację i o wiele mniejsze luzy w układzie np kierowniczym co generowało duże odchyłki a także dużo większą sztywność konstrukcji i spasowanie. Zastosowanie wydajniejszego SBC np nVidia Jetson lub nawet przenieść to na jakiś iCore desktopowy co zapewni wielokrotnie większą moc obliczeniową Zastosowanie kilku kamer najlepiej czarno białych + doświetlanie IR co pozwoliło by na działanie np o zmroku Wykorzystanie np biblioteki TensorFlow a nie własnej implementacji SN ( skrócenie czasu pisania i eliminiacja ewentualnych błędów z implementacją sieci) Ps. Ciężko opisać wszystkie zagadnienia związane z budową tego modelu w 1-2 kartkach A4 i tak aby nie zanudzić kogoś szczegółami - mam nadzieje że opis nie jest zbyt lakoniczny ale też nie przesadziłem z dokładnością. Może kiedyś powstanie wersja poprawiona to udostępniona szerszy i dokładniejszy opis.
  23. 3 punkty
    Tylko że boty nie bawią się w skanowanie portów jakichś paszczatych serwerków tylko wbijają się na port 22. Jak długo pracuję jako admin (a to już paręnaście lat) nie widziałem aby ktoś mi się próbował wcinać na port na który stoi mój SSH. Poza tym zmiana portu nie tyle podnosi bezpieczeństwo, co eliminuje niepotrzebne obciążanie systemu przez wszelakie zombiaki z Kazachstanu. Klucze publiczne możesz sobie wsadzić tam gdzie słońce nie dochodzi, jeśli musisz czasem logować się z dowolnych maszyn (np. z każdej z 20 maszyn w biurze) nie udostępniając swojego systemu każdemu, kto posadzi tyłek na krześle. Owszem, są wygodne w domciu bo nie musisz hasełka do swojej malinki bez przerwy wpisywać - i tyle. Zresztą - biorąc po uwagę że malinki zwykle rosną w ogródku za furtką o nazwie NAT, dopóki nikt Ci się do sieci nie włamie to na malince możesz równie dobrze zainstalować serwer telnetu bez hasła, nie wpłynie to w żaden sposób na bezpieczeństwo. A zabezpieczanie routerów to już na pewno nie temat do tego wątku.
  24. 3 punkty
    Skoro już rozmawiamy o językach zamiast o chmurze Arduino to dorzucę swoje 3 grosze. PHP tak jak napisaliście, tylko webdev. Chyba praktycznie nie stawia się obecnie samodzielnych stron bez użycia jakiegoś frameworka np: Symfony. Co innego jakieś pluginy do Wordpressa, sklepy itp. Plus jest taki że jest pełno tanich hostingów xd JS - tutaj jest dużo uniwersalniej, mamy Node,JS, cały frontend, ElectronJS, Ionic, React native, TypeScript no ogólnie wszystko, nawet TensorflowJS xd. Jeden z pierwszych projektów zrobiłem w Angular + Node.JS + TypeScript, używając tego generatora: https://github.com/angular-fullstack/generator-angular-fullstack . Ogólnie fajna sprawa bo generator wymusza porządek w kodzie, mamy od razu trochę reużywalnego dobrze napisanego kodu, użycie narzędzi o których można na początku usłyszeć (np: sequelize, gulp, webpack) i inne fajne usprawnienia. Później takie podejście się spopularyzowało i np: Ionic, Angular mają oficjalne CLI które działają podobnie jak generator wspomniany wyżej. Jeszcze chciałbym zwrócić uwagę że używanie frameworków daje jakieś minimalne bezpieczeństwo. Nie robiłem większych pentestów ale jak testowałem moje apki prostymi XSS czy SQLi to były na nie odporne.
  25. 3 punkty
    Cześć SOYER, są chmury (darmowe), które oferują dodatkowe funkcje. Ja np. korzystałem z chmury ThingSpeak (firmy Mathworks twórców MATLAB) z ESP8266). Tworzysz sobie za darmo "kanały" np. z wartościami pomiarów a czujników i zapisujesz je w nich (max. co 30 sekund w darmowej wersji). Masz dostęp z całego świata do strony wizualizującej twoje pomiary. Największą zaletą jest, że w tej chmurze jest dostępny MATLAB i możesz go użyć do obróbki (bardzo zaawansowanej) twoich danych pomiarowych. Możesz sobie np. liczyć sobie parametry statystyczne pomiarów i robić skomplikowane wizualizacje. Ja w 2012 i 2013 miałem ESP8266 z czujnikiem ciśnienia, temperatury, wilgotności itp. podłączonych do thingspeak.com i robiłem sobie predykcje tych parametrów za jakiś czas (prognozy) za pomocą "naiwnego klasyfikatora Bayesowski'ego" - prognozy były całkiem trafne. Podczas przeprowadzki układ z ESP8266 gdzieś mi zaginał, ale bardzo pozytywnie oceniam działanie tej chmury. Tutaj kilka linków: https://community.thingspeak.com/tutorials/arduino/send-data-to-thingspeak-with-arduino/ https://github.com/mathworks/thingspeak-arduino Pozdrawiam
Tablica liderów jest ustawiona na Warszawa/GMT+02:00
×