Skocz do zawartości

Tablica liderów


Popularna zawartość

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

  1. 15 punktów
    Sprzedaż samodzielnie zbudowanego urządzenia może być kuszącą wizją dla wielu początkujących elektroników. Czy jeśli układ działa, to można go od razu zacząć sprzedawać, np. na Allegro? W tym miejscu warto jednak uświadomić sobie, że każdy producent elektroniki jest zobowiązany do przestrzegania różnych przepisów. [blog]https://forbot.pl/blog/skonstruowalem-sobie-budzik-z-wifi-a-co-z-ce-id41631[/blog]
  2. 15 punktów
    Witam wszystkich! =) Od dłuższego czasu zbieram się do opisu mojej pierwszej "poważniejszej" konstrukcji. Jako że semestr się dopiero zaczyna i jeszcze jest czas na cokolwiek, a na dodatek w ciągu ostatnich dni została otworzona kolejna edycja konkursu z Proxxonem, przyszedł czas na zrealizowanie tego planu. Tym samym z wielką przyjemnością prezentuję robota mobilnego klasy micromouse: Let Me Out 1. Pomysł Podczas zeszłorocznych wakacji moje zainteresowanie zostało skierowane w kierunku dwóch zagadnień: roboty klasy micromouse oraz silniki krokowe. Z tego pierwszego bardzo szybko podjąłem decyzję o budowie takiego robota. Interesując się zaganieniem drugim (silników krokowych), dowiadując się o ich możliwościach i ograniczeniach zacząłem się zastanawiać nad ich wykorzystaniem w robocie klasy micromouse. Niestety, przewalając internet dniami i nocami nie znalazłem żadnego sensownego opisu zrealizowanej i zbadanej konstrukcji napędu robota mobilnego opartego na silnikach krokowych. W ten sposób narodził się pomysł o zaprojektowaniu, zbudowaniu i przetestowaniu takiego rozwiązania. 2. Założenia projektowe • Spełnienie podstawowych warunków konstrukcyjnych oraz programowych zawartych w regulaminie konkurencji micromouse. Robot projektowany był tak, żeby mógł wziąć udział w zawodach w Polsce. • Oparcie projektu o procesor z rodziny AVR W tamtym momencie STM-y dopiero wynurzały mi się zza horyzontu, więc zdecydowałem się na popularnego AVR-a, którego już dobrze znałem i umiałem go programować. • Konstrukcja umożliwiająca poruszanie się po skosie labiryntu Aby móc zastosować bardziej złożone algorytmy przemierzania labiryntu. • Zastosowanie silników krokowych jako napęd główny robota • Umożliwienie bezprzewodowej komunikacji z robotem Głównie w celu odbierania danych o aktualnym stanie zmapowania labiryntu przez robota i możliwości wizualizacji aktualnej sytuacji na komputerze. • Zaprojektowanie płytki PCB w sposób umożliwiający wykonanie jej metodą fototransferu Oczywiście w celu zaoszczędzenia na czasie i funduszach, zdecydowałem się na warsztatową metodę wykonywania płytki. • Implementacja algorytmu pozwalającego na rozwiązywanie algorytmu metodą "floodfill" 3. Konstrukcja Mechaniczna 3.1 Napęd 3.1.1 Silniki Jako napęd zdecydowałem się na użycie silników krokowych. Zalety silników krokowych (+) Sterowanie pozycją - dokładne sterowanie w otwartej pętli sterowania (+) Silnik pracuje z pełnym momentem w stanie spoczynku (+) Żywotność silnika wyznaczona wytrzymałością łożysk i cewek - brak szczotek Wady silników krokowych (-) Przeznaczone do pracy z małymi prędkościami (-) Możliwość wystąpienia zjawiska "gubienia kroków" (-) Duża emisja ciepła (-) Duża masa i rozmiary (-) Skomplikowany sposób sterowania Ze wszystkich silników krokowych dostępnych na polskim rynku, silniki o kodzie producenta S20STH30-0604A firmy Pololu najbardziej nadawały się do projektowanej konstrukcji. Porównanie parametrów wybranych silników krokowych z popularnymi mikrosilnikami Pololu Parametr • Silnik krokowy • Mikrosilnik Pololu 30:1 Waga • 60g • 10g Wymiary • 20 x 20 x 30 mm • 10 x 12 x 24 mm Napięcie zasilania • 3.9 V • 3-9 V Pobór prądu • 600 mA • 120-1600 mA Moment obrotowy • 140 g*cm (0.017 Nm) • 600 g*cm (0.059 Nm) Średnica wału • 4 mm • 3 mm Cena • 100 zł • 70zł Sterowanie • Trudne • Proste Problemy do rozwiązania w projektowaniu napędu opartego o silniki krokowe: Problem: Silniki krokowe przeznaczone są do pracy przy niewielkich prędkościach obrotowych (zazwyczaj 4-10 RPS to ich maksymalne osiągi). Rozwiązanie: Zasilanie silników z dużo wyższego napięcia (w tym wypadku 24 V). Pozwala to na skrócenie czasu narastania prądu na cewkach, prez co można je przełączać częściej, w efekcie uzyskując wyższą prędkość obrotową. (Udało mi się rozkręcić te silniki do 45 RPS - w powietrzu, nie na jadącym robocie) Problem: W robocie potrzebne jest napięcie 24 V Rozwiązanie: Zasilanie silników z przetwornicy step-up, generującej 24 V z napięcia zasilania (7.4 V bądź 15.8 V) Problem: Zasilając silnik z wyższego napięcia, prąd na cewkach będzie proporcjonalnie większy, co po przekroczeniu wartości nominalnej (600 mA) prowadzić będzie do ich spalenia Rozwiązanie: Zastosowanie gotowego modułu sterownika silnika krokowego z ogranicznikiem prądu (funkcja Chopper) 3.1.2 Koła Jako koła wybrano gumowe koła firmy Solarbotics o średnicy 2.8 mm i szerokości 13 mm. Koła mają świetną przyczepność i doskonale nadają się do tego zastosowania. Jedyną jak dotąd zaobserwowaną wadą jest bardzo duża zdolność do zbierania kurzu i drobnych odpadów, przez co jazda po zabrudzonej powierzchni bardzo szybko doprowadza do zmniejszenia przyczepności kół. 3.1.3 Mocowania silników Niestety na rynku nie istnieją mocowania do silników krokowych w tym rozmiarze (Nema 8), więc musiałem takie mocowania wyprodukować sam. Mocowania silników zostały zaprojektowane w programie TinkerCad dostępnym w wersji przeglądarkowej. Zamówienie przyjęło i wykonało techniką druku 3D koło naukowe działające przy Politechnice Wrocławskiej "Rapid Troopers". Mocowania zawierają 4 otwory na śruby mocujące silnik do elementu, oraz 4 otwory na śruby służące do przytwierdzenia silnika wraz z mocowaniem do platformy. 3.1.4 Podwozie Jako podwozie wykorzystałem płytkę PCB z elektroniką, przedstawioną w dalszej części artykułu 4 Elektronika Schemat elektroniczny jak i płytka PCB zostały zaprojektowane w programie CadSoft Eagle. 4.1 Zasilanie Robot może być zasilany z jednego bądź dwóch (połączonych szeregowo) akumulatorów Li-Po 7.4 V o pojemności 250 mAh. Dwa akumulatory stosowane są w celu podwyższenia napięcia na wejściu przetwornicy, co skutkuje obniżeniem poboru prądu z akumulatora i wydłużeniem możliwego czasu działania robota. 4.1.1 Zasilanie silników Silniki zasilane są napięciem 24 V podawanym z przetwornicy step-up opartej o układ XL60098. Przy pracy pobierają 1 - 1.2 A. 4.1.2 Zasilanie logiki Wszystkie układy logiczne zasilane są napięciem 5 V uzyskiwanym z przetwornicy step-down D24V6F5. Powodem zastosowania przetwornicy zamiast stabilizatora liniowego jest różnica napięć na wejściu i wyjściu układu. Występuje tu obniżenie napięcia z ~16 V do 5 V, co przy stabilizatorze liniowym generowałoby bardzo duże ilości ciepła i mogłoby prowadzić do jego uszkodzenia lub poparzenia użytkownika podczas obsługi robota. 4.2 Procesor Jednostką sterująca całego robota jest ośmiobitowy procesor AVR Atmega 128 firmy Atmel, taktowany zewnętrznym kwarcem 16 Mhz. Procesor zasilany jest napięciem 5 V. W celu zmniejszenia rozmiarów robota, zastosowano procesor w obudowie TQFP64. 4.3 Czujniki odległości Jako czujniki odległości zastosowano diodę LED SFH4550 działającą w paśmie podczerwieni. W robocie umieszczono 6 takich zestawów. Dwa skierowane w przód, dwa na boki oraz dwa odchylone od diametralnej robota o 45°. Prąd płynący przez diody IR to 95 mA, co daje wystarczające natężenie światła do dokładnego odczytywania odległości przy jednoczesnym braku konieczności uważania na przepalenie się diody spowodowane długim świeceniem przy zbyt dużym prądzie. 4.4 Sterowniki silników Zastosowano sterowniki firmy Pololu oparte na modula A4988. Sterowniki pozwalają na pracę w trybach: pełnokrokowym, półkrokowym, ćwierćkrokowym, 1/8 oraz 1/16 kroku. Funkcja ograniczania prądu (chopper) pozwala sterować silniki wyższym napięciem bez ryzyka uszkodzenia cewek silnika. Kolejną zaletą zastosowania sterowników silników krokowych jest możliwość sterowania silnika za pomocą tylko jednego pinu (tylko jeden pin mikrokontrolera podaje sygnał częstotliwościowy odpowiedzialny za taktowanie silnika). W celu umożliwienia generowania sygnałów o różnej częstotliwości, każdy ze sterowników obsługiwany jest przez inny timer. Obydwa szesnastobitowe timery sterujące działają w sprzętowym trybie Clear on Compare Match. Pozwala to na automatyczne generowanie sygnału o zadanej częstotliwości bez udziału samej jednostki obliczeniowej. 4.5 Interfejs komunikacyjny Jako interfejs komunikacyjny robota służą dwie diody LED, buzzer, interfejs UART wraz z modułem bluetooth HC-05 oraz dwa przyciski. Programowanie robota realizowane jest poprzez interfejs SPI. 4.6 Płytka PCB Płytka PCB na której zostały umieszczone wszystkie elementy robota została zaprojektowana za pomocą programuy CadSoft Eagle. Długość: 101 mm Szerokość: 94 mm Płytka pełni jednocześnie funkcję podwozia robota. Takie wymiary pozwalają na swobodny obrót robota w miejscu między ścianami, oraz jazdę po skosie w labiryncie. Płytka w swoim kształcie jest symetryczna, lecz główna masa elementów skupiona została przy tylnej części. Powoduje to brak efektu kołysania się robota ze względu na dociśnięcie tyłu do podłoża. Płytka została stworzona metodą fototransferu oraz wytrawiona w warunkach domowych. Otwory wykonano na wiertarce stołowej. Prostokątny otwór na środku płytki jest miejscem na wystające elementy silników, w których znajdują się gniazda przewodów zasilających. Warstwa Top zawiera wszystkie układy scalone, czujniki, silniki, akumulatory i złącza. W przedniej części robota znajdują się czujniki, mikrokontroler, układ ULN2003 (sterowanie diodami LED) oraz jeden z akumulatorów. Z tyłu umieszczono sterowniki silników krokowych, obydwie przetwornice, moduł bluetooth, drugi akumulator oraz buzzer. Silniki znajdują się w osi symetrii robota Na dolnej stronie płytki umieszczono jedynie kilka rezystorów oraz slizgacz, znajdujący się w diametralnej robota, w jego tylnej części. Zdjęcie poniżej pokazuje stopień upakowania elementów i modułów w robocie. 5 Oprogramowanie Główną częścią projektu było rozwinięcie oprogramowania związanego z obsługą peryferii oraz algorytmem rozwiązującym labirynt. Program napisany został w języku C. 5.1 Pomiary odległości Pomiar z każdego z czujników dokonywany jest z częstotliwością 200 Hz. Zastosowano pomiar różnicowy z uśrednianiem wyników. 5.2 Sterowanie prędkością robota Prędkość robota sterowana jest częstotliwością sygnału podawanego na sterowniki silników. 5.3 Algorytm Zaimplementowany algorytm opiera się na algorytmie Dijkstry, służącym do znajdywania najkrótszej drogi w grafie. 6 Podsumowanie Projektowanie, budowa oraz zaprogramowanie robota zostały zrealizowane zgodnie z założeniami. Robot dobrze radzi sobie w labiryncie. 6.1 Sprawność silników krokowych w robocie mobilnym Podczas jazdy kroki są gubione dość rzadko, co pozwala na wystarczająco dokładne wysterowanie robota w otwartej pętli sterowania z kompensacją pozycji od czujników odbiciowych. Osiągane maksymalne prędkości podczas testów (oczywiście poza labiryntem i po prostej) sięgają 2 m/s. Głównymi wadami tych silników w robocie są ich masa, wielkość, konieczność stosowania sterowników silników krokowych oraz wyższego napięcia. Kolejną wadą jest konieczność ograniczania przyspieczeń, w celu zminimalizowania gubionych kroków. Zaletą stosowania silników krokowych jest brak konieczności stosowania sprzężenia zwrotnego w postaci enkoderów obrotowych. Sterowanie robotem klasy (2.0) w otwartej pętli regulacji Sterowanie w otwartej pętli regulacji z wykorzystaniem silników krokowych jest możliwe. Rozwiązanie to jest wygodniejsze i prostsze do zrealizowania, aczkolwiek posiada bardzo dużą wadę, w postaci braku informacji o gubionych ktokach. Cała kalibracja pozycji opierać musi się na odczytach z czujników odbiciowych. Budowa tego robota z pewnością przyczyniła się do znacznego poszerzenia mojej wiedzy na temat budowy robotów mobilnych, projektowaniu schematów elektronicznych oraz płytek PCB, kategorii micromouse oraz silników krokowych. Niestety nie miałem dostępu do pełnowymiarowego labiryntu, dlatego filmiki z testów są tylko na ćwiartce labiryntu. Robot jeździ wolno, bo w momencie kiedy zaczął działać i poprawnie rozwiązywać labirynt, semestr zaczął być tak gorący że musiałem porzucić prace nad jego rozwojem i zająć się studiami. Na pewno może jeździć o wiele szybciej - pozostaje tylko kwestia gubienia kroków. Zeby pokazać w sumie clue sprawy związanej z zastosowaniem silników krokowych, poniżej filmik na którym robot jedzie z wyłączonymi czujnikami, z wgraną na stałe sekwencją (prosto, prawo, lewo, prosto itp.) Widać jak dokładne może być pozycjonowanie się na silnikach krokowych (które i tak dobierane było "na oko"). Jazda bez sprzężenia od czujników A tutaj testy na labiryncie. Robot rozwiązujący labirynt Nie chcę się już bardziej szczegółowo rozpisywać na poszczególne tematy, żeby artykuł nie rozrósł się do rozmiarów nieczytelnych. Jeśli kogoś interesują detale budowy tego robota i używania tego napędu, zapraszam do dołączonej w załącznikach prezentacji oraz raportu z budowy robota. Jeśli jesteś zainteresowany schematami elektronicznymi tego robota - napisz w komentarzu. KoNaR - Bartlomiej Kurosz - Micromouse Let Me Out.pdf Zastosowanie silnikow krokowych w robotach mobilnych.pdf
  3. 14 punktów
    Witam Elektroniką zajmuję się od dwóch miesięcy, kiedy to po raz pierwszy zaświeciłem diodą z kursu: FORBOT - podstawy elektroniki - zestaw elementów + kurs ON-LINE. Kurs tak mi się spodobał że ukończyłem go w dwa dni i kupiłem 4 kolejne: FORBOT - podstawy elektroniki 2 - zestaw elementów + kurs ON-LINE, FORBOT - technika cyfrowa - zestaw elementów + kurs ON-LINE, FORBOT - zestaw do nauki lutowania elementów THT oraz FORBOT - zestaw do kursu podstaw Arduino + gadżety i Box (wersja PLUS). Jak tylko je połknąłem pojawił mi się w głowie pomysł na pierwszy projekt którym chciałbym się Wami podzielić. Projekt został oparty o Arduino Pro Mini i jest to Szachownica która gra za mną w szachy Bardzo zależało mi żeby była to tradycyjna duża drewniana szachownica, którą będę się mógł cieszyć przez lata. Całość prezentuje się tak: Najpierw należało zacząć od wykrywania pozycji bierek. Do tego zdecydowałem się (być może nieco pochopnie) na użycie małego ładnego zgrabnego komponentu o nazwie sg-2bc. SG-2BC to nic innego jak dioda IR i fototranzystor w jednej małej (4mm średnicy) ceramicznej obudowie. Ma jednak jedną wadę w zastosowaniu do którego go potrzebowałem - jego fototranzystor jest bardzo wrażliwy na światło słoneczne. Musiałem więc odróżnić jakoś światło słoneczne od światła odbitego diody IR. Zaprojektowałem w tym celu prosty obwód oparty o ne555, który generuje sygnał PWM o częstotliwości około 32kHz i wypełnieniu 33%. Układ ten daje sygnał na diodę IR oraz sprawdza za pomocą 3 komparatorów (dwa lm393 - 2 komparatory na układ) i filtra RC czy odebrał sygnał o odpowiedniej charakterystyce po stronie fototranzystora (czyli na polu stoi bierka). Na wyjściu wystawia stan wysoki jeśli to mu się udało. W ten sposób powstał mój pierwszy w życiu projekt płytki drukowanej Oczywiście zdarzyło mi się wlutować jeden z komparatorów odwrotnie a potem to poprawiać. I tu uwaga do Forbota: w kursie lutowania brakuje informacji i praktyki w wylutowywaniu układów scalonych - na prawdę by się przydało! Jakoś to jednak poszło i efekt był taki: Z racji uśredniania na filtrze RC który jest częścią obwodu czas odpowiedzi na sygnał to 3ms. Oczywiście nie chciałem takiego obwodu powtarzać dla każdego testowanego pola szachownicy, zastosowałem więc multipleksowanie - obwód załączany jest tranzystorami kolejno do wszystkich czujników, co jak łatwo policzyć daje <200ms na zeskanowanie stanu szachownicy (uwzględniając szybkość I2C i czasy przełączania w praktyce są to 3 pełne skany na sekundę - wystarcza). Skoro już umiałem testować pojedyncze pole, nadszedł czas na zaprojektowanie płytek do samej szachownicy. Tu użyłem ekspandera wyprowadzeń MCP23017 oraz demultiplexera MC74HC154. Skoro i tak nie mogę testować więcej niż jednego pola na raz, demultiplexer zapewnił mi rozsądne wykorzystanie wyprowadzeń MCP23017 - dzięki temu wystarczył jeden ekspander na 16 pól szachownicy (każde ma jedną diodę świecącą i jeden czujnik wspomniany wczesniej SG-2BC). Prototyp tego rozwiązania wyglądał następująco: Projekt płytki pokrywającej 16 pól (przed ułożeniem ścieżek, wizualizacja ze ścieżkami, gotowe płytki): Na całą szachownicę użyłem 4 takich samych równolegle połączonych płytek: Czemu nie dwóch - po jednej na stronę szachownicy? Z tej oto przyczyny że darmowa licencja DIPTrace pozwala na 300 padów na płytkę Po polutowaniu i zmontowaniu całości otrzymałem taki oto efekt: W montażu najtrudniejsze okazało się jednoczesne wcelowanie 32-ma okrągłymi elementami w wywiercone otwory: Aby tego dokonać ułatwić płytki umieściłem na mosiężnych dystansach 1cm przyklejonych klejem na ciepło do wewnętrznej strony szachownicy, przewlokłem diody i czujniki przez płytkę, zakleilłem otwory w szachownicy od jej frontowej strony przezroczystą taśmą klejącą i manewrowałem cierpliwie elementami oraz samą płytkę aż wskoczyły na swoje miejsce. Dopiero wtedy płytkę przykręcałem a nóżki elementów lutowałem. Pozostało to oprogramować Jako że programuję od ponad 20 lat i do tej pory nie pisałem jeszcze enginu szachów, postanowiłem nie używać „cudzego” i napisać własny. Biorąc pod uwagę ograniczenia Arduino było to naprawdę fajnym wyzwaniem i zajęło mi około 2 tygodnie. Zaimplementowałem mini-max z przycinaniem alpha-beta i iteracyjnym pogłębianiem. Engine nie alokuje żadnej pamięci dynamicznie, a ze stosu bierze nie więcej niż 600B, co uważam za swój sukces. Ostatecznie wygrywa nie tylko ze mną (żaden ze mnie wybitny szachista), ale i z Stockfishem na poziomie 3, z czego jestem dumny Ostateczny kształt szachownicy w działaniu wygląda tak: Szachownica rozpoznaje ustawienie początkowe i sygnalizuje to spiralnym zaświeceniem wszystkich diod. Grę rozpoczynamy białymi lub sygnalizujemy szachownicy ze chcemy grać czarnymi poprzez podniesienie na chwile czarnego króla. Po podniesieniu bierki gracza, szachownica pokazuje dostępne pola na które figura ta może się ruszyć umieszczonymi w ich rogach diodami (mój niespełna 6-cio letni syn bardzo to docenia). Ruch szachownicy również sygnalizowany jest diodami i szachownica czeka aż zostanie wykonany. Dodatkowe dwie małe diody na krawędzi szachownicy sygnalizują po czyjej stronie jest ruch. Zdjęcie dwóch własnych bierek z szachownicy jest dla niej gestem do zapisania stanu gry do EEPROMU. Po tym można ją wyłączyć i wznowić grę np. za tydzień. Po włączeniu szachownica czyta stan z EEPROMU i czeka aż jeden ze stanów (początkowy lub zapisany) zostanie ustawiony na szachownicy. Jeśli nie była w tym czasie składana, a bierki nie były ściągane - grę można kontynuować natychmiast po włączeniu. Szachownicę można normalnie składać, niestety nie mieszczą się już do niej szachy Mam nadzieje mój pierwszy projekt się Wam spodobał, ja jeszcze wciąż się nim cieszę jak dziecko. Chciałbym przy tym podziękować Forbotowi za naprawdę świetne kursy które nie tylko dały mi niezbędną w realizacji wiedzę, ale też zainspirowały to zrobienia tejże zabawki. Pozdrawiam, Okjak
  4. 14 punktów
    Ten artykuł jest tłumaczeniem (za zgodą autora) na język polski artykułu napisanego przez Paula Stoffregena, dostępnego pod adresem: https://www.pjrc.com/how-to-get-tech-help-from-strangers-on-the-internet/. Internetowe fora techniczne mogą być bardzo onieśmielające. Trzy proste zasady mogą znacznie ułatwić ci życie i zwiększyć szansę na uzyskanie pomocy, niezależnie od poziomu twoich umiejętności. Dobre Pierwsze Wrażenie — aby ludzie chcieli ci pomóc, Wyjaśnij Kontekst — aby ludzie zrozumieli czego potrzebujesz, Podaj Szczegóły — aby ludzie mogli ci pomóc, Poziom 1: Aby dostrzegli twój problem, Poziom 2: Aby mogli go powtórzyć. Dobre Pierwsze Wrażenie "Nie ma drugiej szansy na zrobienie pierwszego wrażenia" to ponadczasowe powiedzenie. Obcy ludzie błyskawicznie wyrabiają sobie o tobie opinię zaledwie na podstawie słów, obrazów lub nagrania w twoim komunikacie. Niech te słowa zadziałają! Największy wpływ na ludzką chęć do pomocy ma pokazanie, że sam włożyłeś wysiłek w rozwiązanie problemu. Ale jaki to może być wysiłek jeśli dopiero zaczynasz? Łatwo jest skorzystać z wyszukiwarki internetowej używając słów ze swojego pytania. Wielu ekspertów nie zdaje sobie jednak sprawy jak trudno jest znaleźć zrozumiałą i istotną informację gdy nie zna się właściwej terminologii, lub gdy te same słowa używane są także w niezwiązanych z twoim problemem dziedzinach. Zatem napisanie czego próbowałeś szukać i jakie wyniki są dla ciebie niezrozumiałe lub nie na temat może pomóc doświadczonym ekspertom w zrozumieniu twojej sytuacji. To nie wyniki są tutaj istotne, ale twój osobisty wysiłek. Szczera chęć nauki także zazwyczaj sprawia dobre wrażenie. Nawet parę słów pokaże twoje podejście. Bycie zniecierpliwionym, ale zdecydowanym na naukę na błędach robi dobre wrażenie. Inteligentni ludzie, którzy mogą pomóc, często doceniają szczere i uczciwe postawienie sprawy. Oczywiście jeśli już rozpocząłeś swój projekt i pracujesz nad nim, wspomnij o tym. Albo nawet lepiej, pokaż czego już próbowałeś. Zrzuty ekranu, zdjęcia, a nawet krótkie nagranie mogą doskonale zaprezentować co już zrobiłeś i upiec dwie pieczenie na jednym ogniu, jednocześnie komunikując i robiąc dobre wrażenie. Nawet kilka prostych słów dodanych do pytania, pokazujących że szczerze się starasz i chcesz się uczyć będzie mieć duży wpływ na odpowiedź, jaką otrzymasz. Kontekst Umożliwia Zrozumienie Istoty ludzkie mają niesamowitą umiejętność dogłębnego zrozumienia. Eksperci mogą zastosować swoją ogromną wiedzę do wypracowania twórczych pomysłów rozwiązujących twój problem... pod warunkiem, że będą wiedzieć czego tak naprawdę potrzebujesz. Kluczowe jest wyjaśnienie kontekstu pytania. Co chcesz osiągnąć? Jak twoje pytanie jest z tym związane? Jakie rozwiązanie byłoby dla ciebie idealne? Dlaczego? Kiedy zajmujemy się techniczną stroną zagadnienia, łatwo jest skupić się tylko na bezpośrednim problemie. Pamiętaj, że przyjaźni ludzie o ogromnej wiedzy i doświadczeniu regularnie czytają fora tylko dlatego, że lubią pomagać. Kiedy piszesz swoje pytanie, nie zapomnij opisać kontekstu. To może zmienić odpowiedź z technicznie poprawnej ale całkowicie bezużytecznej informacji, na rzeczywiście przydatną radę. Diabeł Tkwi w Szczegółach Współczesne zagadnienia techniczne często zawierają oszałamiającą ilość szczegółów. Ile informacji powinno zwierać twoje pytanie? Zanim je wyślesz, zastanów się nad tymi dwoma kwestiami: Czy czytelnik będzie mógł zrozumieć istotę twojego problemu? Czy będzie mógł go odtworzyć? Łatwo jest sobie zakpić "był jakiś błąd, ale zamknąłem go bez czytania", ale bądźmy poważni, minimalny poziom detali pozwoli czytelnikom zrozumieć problem. Zrzut ekranu lub dokładna kopia tekstu błędu, plus dokładna informacja o użytym oprogramowaniu, wersjach, sprzęcie oraz przedsięwziętych kroków to absolutna podstawa umożliwiająca czytelnikowi w ogóle dostrzec problem tak, jak ty go widzisz. W idealnej sytuacji ludzie czytający twoje pytanie powinni móc powtórzyć twój problem. Taki poziom szczegółowości nie zawsze jest praktyczny, ale jeśli dostarczysz wystarczająco dużo informacji, to szanse na rozwiązanie problemu znacznie się zwiększają. Pytania na temat programowania powinny zawsze zawierać cały kod źródłowy, a nie tylko wycięte fragmenty. Często problem ukrywa się w subtelnych szczegółach w definicjach zmiennych daleko od właściwego kodu. Doświadczeni programiści wiedzą czego szukać i potrafią dostrzec takie błędy natychmiast, jeśli tylko pokażesz cały swój kod. Nie zapomnij także poinformować jakich dokładnie bibliotek używasz. Zagadnienia dotyczące sprzętu elektronicznego często nie obejdą się bez zdjęć albo szczegółowych schematów połączeń, oraz linków do użytych części, lub ich symboli katalogowych. Nieśmiałość i niechęć do opisywania szczegółów swojego projektu na forum są powszechne. Nie wstydź się! Eksperci czytający forum naprawdę chcą pomóc. Pokaż dość szczegółów, wyjaśnij kontekst i pokaż, że się starasz, a oni z pewnością pomogą. Częste Błędy Fora nie zawsze działają idealnie. Powyższe trzy kroki najczęściej zadziałają, ale należy też pamiętać o kilku powtarzających się błędach: Zbyt Wiele Zgadywania Rozwiązywanie technicznych problemów polega na obserwacji i dedukowaniu przyczyn. Całkowicie normalne jest, że kiedy jesteśmy na tym skupieniu, to piszemy w zasadzie tylko na podejrzewanych przez nas przyczynach, a zapominamy opisać zaobserwowane efekty. Krótka przerwa przed napisaniem pytania często tutaj pomaga. Kiedy piszesz, staraj się myśleć z punktu widzenia czytelnika. Czy na pewno prosisz o pomoc w problemie, czy tylko chcesz, aby potwierdzili to co sam już odgadłeś? Z drugiej strony, opisanie jak doszedłeś do swoich wniosków może pomóc uniknąć niepotrzebnego powtarzania tego samego toku rozumowania. Nie ma idealnej metody. Po prostu pamiętaj, że zbytnie skupianie się na wnioskach może powstrzymać ludzi od pomocy. Dawanie Upustu Frustracji Szczerze mówiąc niektóre problemy są bardzo trudne i niesłychanie irytujące. Kiedy jesteś zły, dawanie upustu emocjom jest całkowicie naturalne. Zanim wyślesz wiadomość na forum, robiąc tak istotne pierwsze wrażenie, przeczytaj ją przynajmniej raz. Pewien poziom emocji jest normalny i może nawet pomocny. Pokazuje, że naprawdę się starasz. Ale strzeż się częstego błędu, gdy twoja wiadomość jest odbierana jako narzekanie a nie prośba o pomoc. Brak Odpowiedzi Nawet w idealnej sytuacji czasem nie dostaniesz odpowiedzi. To może rozczarować i przygnębić. Postaraj nie dać się ponieść tym emocjom i nie domagać się odpowiedzi. Jest lepszy sposób. Wysiłek jest istotny. Jeśli minęły całe dnie lub tygodnie od wysłania pierwszej wiadomości, to zapewne w tym czasie włożyłeś w swój projekt trochę więcej pracy? Nawet jeśli bezowocny, ten wysiłek jest czymś, czym warto się podzielić, aby przyciągnąć ludzi. Zdjęcia lub kod, albo inne efekty twojej pracy mogą bardzo pomóc. Czasem bardzo trudne i szczegółowe pytania pozostają bez odpowiedzi, bo po prostu nikt jej nie zna. Albo nikt nie jest pewien. W tej sytuacji dobrze jest zapytać o opinie albo sugestie w którym kierunku szukać odpowiedzi, aby usprawnić rozmowę. Ponownie, pokazanie wysiłku jest kluczowym czynnikiem zachęcającym ludzi do pomocy. Większość forów zniechęca lub nawet zabrania wysyłania wielokrotnie tej samej wiadomości czy "krospostowania". To prawie nigdy nie działa. Eksperci, którzy regularnie czytają fora — ludzie najbardziej skłonni do pomocy — na pewno to zauważą. Masz tylko jedną szansę na zrobienie dobrego wrażenia. Natomiast po dłuższym czasie bez odpowiedzi, ponowienie pytania, najlepiej z linkiem do poprzedniej wiadomości i dodatkowym wyjaśnieniem, nie musi być źle odebrane. Nierzetelni Uczniowie Na każdym forum zdarzają się leniwi uczniowie domagający się odrobienie za nich pracy domowej. Eksperci czytający fora regularnie są zalewani takimi marnymi pytaniami. Nie chcesz, aby twoje pytanie zostało potraktowane jak spam i zignorowane. Jeśli twój projekt jest robiony w ramach zajęć, to najlepiej jest szczerze się do tego przyznać (oraz do terminów) i upewnić się, że widać jednak twój własny wkład. Rzetelny wysiłek i szczera chęć nauki wyróżniają dobrych uczniów. Zastrzeżone Projekty Kiedy nie możesz podzielić się kodem źródłowym albo innymi szczegółami technicznymi, pomoc na forum rzadko będzie dobra. Zazwyczaj musisz poświęcić dodatkową pracę aby wydzielić problematyczny fragment z reszty projektu, aby móc go opublikować. Jeśli tego nie zrobisz i po prosty spytasz "czy ktoś spotkał się kiedyś z takim problemem", to traktujesz ludzi jak wyszukiwarkę internetową. Czasem może się udać, ale naprawdę trudno jest zgadywać na ślepo rozwiązania trudnych technicznych problemów. Jeśli twój pracodawca lub organizacja kategorycznie nie zgadza się na publikowanie kodu lub szczegółów, niezależnie jak drobnych, być może zamiast szukać darmowej pomocy na forum powinieneś użyć komercyjnych produktów, które zapewniają kontraktowo wsparcie, albo zatrudnić eksperta z firmy konsultingowej. Kiedy Otrzymasz Odpowiedź Najlepszym sposobem na wyrażenie wdzięczności jest wskazanie osoby, która udzieliła poprawnej odpowiedzi. Wielu ekspertów poświęca niezliczone darmowe godziny swojego czasu pomagając obcym na forach tylko dlatego, że lubią pomagać. Bycie docenionym jest miłą nagrodą. Kiedy twój problem jest rozwiązany, pamiętaj, że wielu innych ludzi trafi do tego wątku szukając rozwiązania podobnego problemu jeszcze wiele lat później. Najlepiej więc jest napisać na koniec krótką wiadomość podsumowującą poprawne rozwiązanie. Jeśli pytałeś w wielu miejscach, to wypada teraz odwiedzić każde z nich i podlinkować do wiadomości z odpowiedzią. O Tym Artykule (i Autorze) Przez ostatnie 6 lat odpowiedziałem 18620 razy na forum PJRC i nawet więcej na innych forach. Udało nam się w tym czasie stworzyć całkiem dobrą społeczność i pomóc w projektach wielu tysiącom ludzi. Obserwowałem i próbowałem się nauczyć co działa i jak możemy dokonać ulepszeń. Oczywiste stało się, że wielu ludzi potrzebuje nieco wsparcia w zadawaniu dobrych pytań. Najbardziej liczą się tu nie technikalia, ale subtelne czynniki ludzkie. Mam nadzieję, że wszystkie fora techniczne się poprawią. Proszę podzielcie się tym artykułem. — Paul Stoffregen
  5. 13 punktów
    Po kursie Arduino chcesz nauczyć się czegoś jeszcze? Albo chcesz zrobić inteligenty dom? A może Arduino po prostu ci nie wystarcza - na to wszystko jest rozwiązanie! ESP8266 to wydajny i tani mikrokontroler. Znajdziemy go na wielu płytkach, od małego 01 na NodeMCU kończąc. Dzisiaj zobaczymy jakie są rodzaje płytek, co w sobie ukrywa kostka mikrokontrolera, oraz spróbujemy przygotować środowisko i wgrać Blinka. Niestety, tak nie robimy - tylko zewrzemy piny. Spis treści serii artykułów: 1. Omówienie, i przygotowanie środowiska 2. Zapoznanie z nowym środowiskiem, praca jako Arduino, prosty serwer WWW 3. Przyspieszony kurs na webmastera 4. Wykresy, zapis do SPIFFS, mini smart-dom 5. Odbiór danych z przeglądarki, stałe IP, łączenie modułów ESP Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac » Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay. Możliwości ESP8266 Uznałem, że najlepiej będzie zestawić NodeMCU v3 z Arduino UNO. Najważniejsze informacje podałem w tabeli. Pamiętamy, że ESP pracuje na napięciu 3.3v. Kiedy podłączałem do 5V (nie róbcie tego w domu) się tylko grzał, ale lepiej tego nie róbcie. ESP ma także pamięć FLASH w oddzielnej kostce - co pozwala na dużą jej pojemność (zależy to od wersji modułu). Co więcej, interfejsy możemy zdefiniować na (prawie) każdym pinie. ESP pracuje o wiele szybciej od Arduino - bo aż na 80MHz (z możliwością do 160!), i przede wszystkim ESP jest 32 bitowe. No, i ESP się lekko grzeje, ale to nic złego. Warianty ESP8266 Ten mały mikrokontroler możemy znaleźć na równie małych płytkach, lub znacznie większych i rozbudowanych modułach. Jednym z mniejszych, samodzielnych modułów jest ESP12. Posiada wiele wyprowadzeń, lecz nie jest (nawet z przejściówką) zbyt przyjazny dla płytki stykowej. Posiada natomiast aż 4MB pamięci FLASH (wersja ESP12F). Będzie to optymalny wybór dla rozwiązań wbudowanych (np. własnych płytek). ESP12 Jeżeli natomiast szukamy czegoś równie małego, ale bardziej przyjaznego dla nas, tutaj nadchodzi ESP01. Ten mały modulik ma niestety mniej pamięci (niebieska wersja 512kB, czarna 1MB), oraz tylko 8 wyprowadzonych pinów - lecz do konkretnego zastosowania, np. gniazdka z przekaźnikiem, wystarczy. ESP01 (niebieski) ESP03 i ESP07 to uboższe wersje ESP12, ale posiadają ceramiczną antenę - a ESP07 nawet złącze do zewnętrznej anteny. ESP07 Pozostałe moduły rzadko się spotyka, różnią się jedynie ilością wyprowadzeń, rozmiarem, i sposobem montażu. Przygotowanie ESP do programowania W zależności od tego, jaki moduł wybrałeś, będziesz musiał albo przylutować przewody do jego wyprowadzeń, lub podłączyć się przewodami do płytki stykowej. Dlatego na początek nauki, najlepiej zakupić NodeMCU (płytkę deweloperską z ESP12 na pokładzie), Wemos (troszkę mniejsze płytki z ESP12) - mają wszystko wbudowane. Jeżeli taką płytkę wybrałeś, możesz pominąć ten krok. Mając "surowe" ESP12 lub 01, musisz je odpowiednio podłączyć. Połączenie ESP01 z konwerterem USB ↔ UART. Rozpiska pinów dla ESP01. Do tego będziemy potrzebować dwóch przycisków tact switch, kondensatora elektrolitycznego (z zakresu 100-1000µF), dwóch rezystorów 10kΩ, przewodów, oraz oczywiście ESP i konwertera. Pokazałem to na przykładzie ESP01, ale każdy ESP też ma takie wyprowadzenia: pin CH_PD łączymy na stałe do napięcia zasilania przez rezystor 10kΩ pin RST podciągamy do VCC rezystorem 10kΩ, oraz podpinamy przycisk zwierający do masy pin GPIO0 podpinamy do przycisku zwierającego z masą między VCC a GND dajemy kondensator pin RX konwertera łączymy z pinem TX ESP, a pin TX konwertera z pinem RX ESP piny VCC i GND ESP łączymy z pinami VCC i GND konwertera napięcie na konwerterze ustawiamy na 3.3V! Na NodeMCU także znajdziemy dwa przyciski. Przycisk RST odpowiada ze reset mikrokontrolera - tak samo jak w Arduino. Ale co robi przycisk PRG? Otóż, jeżeli na pin GPIO0 podamy logiczne 0 podczas startu mikrokontrolera, wprowadzimy go w tryb programowania. Dzięki temu będziemy mogli wgrać do niego nasz kod. Jeżeli nie mamy zainstalowanych sterowników dla konwertera (np. CH340), powinniśmy je pobrać i zainstalować. Przygotowanie środowiska ESP możemy programować na dwa sposoby, w języku lua - oraz klasycznie, jak arduino, w c++. Opiszę wam sposób jak programować ESP jako Arduino - a do tego potrzebne będzie Arduino IDE. Jeżeli jeszcze takowego nie mamy, pobieramy najnowszą wersję stąd, po czym instalujemy. Dokładny proces instalacji został opisany na kursie Arduino - jeżeli mamy już zainstalowane środowisko, uruchamiamy je, a następnie przechodzimy do zakładki Plik → Preferencje. Powinno nam się otworzyć nowe okno. Szukamy okienka "Dodatkowe adresy URL do menedżera płytek", i wklejamy ten adres: https://arduino.esp8266.com/stable/package_esp8266com_index.json Całość powinna teraz wyglądać tak: Klikamy OK - następnie przechodzimy do zakładki Narzędzia → Płytka → Menedżer płytek Szukamy "esp8266", i klikamy Instaluj. Pobrane zostanie ok. 100MB danych. Od teraz możemy wybrać płytkę ESP jak zwykłą płytkę Arduino. ALE! Jeżeli już kiedyś programowałeś, w innym IDE, zapewne wiesz, że Arduino IDE jest troszkę przestarzałe. Brak autouzupełniania, podpowiedzi, rozbudowanego systemu plików, GIT, i innych funkcji. Jest na to sposób! Dlatego w tym poradniku także opiszę instalację i konfigurację Microsoft Visual Studio Code do pracy z Arduino. Dzięki temu będzie o wiele prościej i wygodniej pisać programy. Pobieramy zatem najnowsze VS Studio Code z tej strony. Jak widać jest ono dostępne na Windowsa, Linuxa, i MacOS. Po pobraniu i zainstalowaniu, powinniśmy zobaczyć taki widok: Jeżeli ciemny motyw nam nie odpowiada, możemy to zmienić naciskając koło zębate (lewy, dolny róg) i "Color Theme" - jasny motyw to Light+. Problemem dla niektórych może być język angielski - lecz w informatyce jest on niezbędny do funkcjonowania. Nie ma problemu aby wrócić do spolszczonego Arduino IDE. Jeżeli jednak chcesz zostać przy VS Code, musimy zainstalować rozszerzenie Platform.io. Dokładniej masz to opisane w tym forbotowym artykule. Po zainstalowaniu Platformio, klikamy magiczny przycisk F1 (musimy go zapamiętać!), i ukazuje nam się to okno: Znajdziemy tam wszystkie funkcje znane z Arduino IDE! Teraz możemy podpiąć nasz konwerter lub NodeMCU do komputera. Tworzymy nowy projekt, i szukamy po lewej pliku platformio.ini. Tam możemy wybrać inną płytkę niż ta, którą wybraliśmy podczas tworzenia projektu. Możemy także ustalić inne rzeczy - więcej w dokumentacji. Otwieramy podfolder src, i szukamy pliku main.cpp. Otworzyło nam się nowe okno - pierwsze co widzimy, to biblioteka Arduino. Dołączy ona wszystkie funkcje z starego IDE. Wklejamy poniższy kod. Największą różnicą ESP w stosunku do Arduino, jest tutaj zapalenie poprzez ustawienie LOW na pinie. #include <Arduino.h> void setup() { pinMode(LED_BUILTIN, OUTPUT); //pin drugi jako wyjście } void loop() { digitalWrite(LED_BUILTIN, LOW); //zapalamy diodę delay(1000); //czekamy sekundę digitalWrite(LED_BUILTIN, HIGH); //gasimy diodę delay(1000); //czekamy sekundę } Teraz przyszedł moment na wgranie szkicu. Klikamy przycisk PRG (gdzieniegdzie opisywany jako FLASH), trzymamy, a następnie RESET, i puszczamy. Dioda powinna raz mrugnąć - oznacza to, że ESP jest gotowe do zaprogramowania. Klikamy zatem znowu F1, a następnie "Platformio: Upload". Cierpliwie czekamy, aż program się wgra. Kiedy zobaczymy ten komunikat: Przyciskamy przycisk reset na naszej płytce - i dioda powinna zacząć mrugać. Na dole, po lewej, na niebieskim pasku są także małe ikonki pozwalające wgrać szkic. Gratulacje, udało Ci się zaprogramować ESP! Możesz je teraz wykorzystać jako moduł Wifi, samodzielne urządzenie, zastosowań jest tyle ile dla Arduino, a nawet i więcej. Udało Ci się także skonfigurować poprawnie VS Code do pracy z płytkami Arduino (i nie tylko!). W następnym odcinku zobaczymy co tak naprawdę oferuje przesiadka na VS Code, oraz spróbujemy połączyć się przez Wifi. Liźniemy nawet trochę HTMLa z CSSem, aby postawić stronę WWW! W przypadku jakichkolwiek problemów, nie bójcie się pisać komentarzy. Spis treści serii artykułów: 1. Omówienie, i przygotowanie środowiska 2. Zapoznanie z nowym środowiskiem, praca jako Arduino, prosty serwer WWW 3. Przyspieszony kurs na webmastera 4. Wykresy, zapis do SPIFFS, mini smart-dom 5. Odbiór danych z przeglądarki, stałe IP, łączenie modułów ESP
  6. 13 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:
  7. 13 punktów
    W poprzednich odcinkach zobaczyliśmy jak działa program, który przesyła do wyświetlacza dane dla każdego piksela osobno, następnie przetestowaliśmy wersję z buforem dla całej pamięci obrazu. Pierwsza wersja działała bardzo wolno, ale zużywała mało pamięci RAM. Druga działała bardzo szybko, ale bufor zajmował ogromną jak na mikrokontroler ilość pamięci. Teraz spróbujemy przygotować wersję pośrednią - tym razem użyjemy mniej pamięci, ale więcej czasu procesora. Spis treści: Sterowanie wyświetlaczem TFT - część 1 - wstęp, podstawowe informacje Sterowanie wyświetlaczem TFT - część 2 - analiza problemu Sterowanie wyświetlaczem TFT - część 3 - testy prędkości na STM32 Sterowanie wyświetlaczem TFT - część 4 - własny program Sterowanie wyświetlaczem TFT - część 5 - optymalizacja programu Obliczanie danych obrazu Pełny bufor obrazu jak pamiętamy zajmuje 160 x 128 x 2 = 40960 bajtów pamięci. Takie rozwiązanie zapewniło nam możliwość szybkiego tworzenia grafiki w pełnej rozdzielczości oraz 65 tysiącach kolorów. Jednak w wielu zastosowaniach wystarczyłaby nieco mniejsze możliwości, przykładowo gdybyśmy zamiast 16-bitów zastosowali 8, uzyskalibyśmy 256 kolorów, a jednocześnie zmniejszyli zużycie pamięci o połowę. W wielu przypadkach nawet 16 kolorów, czyli 4 bity mogłyby wystarczyć, a jak łatwo policzyć bufor zajmowałby wówczas 10240 bajtów. Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac » Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay. Podobnie z rozdzielczością, jeśli tworzymy np. mini konsolę do grania, tryb 80x64 mógłby nam wystarczyć, nadałby nawet nieco stylu "retro". Ogólna idea jest więc taka, że spróbujemy przechowywać mniejszą ilość danych, a następnie przeliczać je na reprezentację oczekiwaną przez wyświetlacz dopiero przed wysłaniem. Tryb z paletą kolorów Metod generowania obrazu jest mnóstwo, ja spróbuję przedstawić bardzo prosty, czyli użycie 8-bitowej palety. Bufor obrazu będzie wyglądał podobnie jak wcześniej, ale zamiast typu uint16_t użyjemy uint8_t: uint8_t lcd_framebuffer[LCD_WIDTH * LCD_HEIGHT]; Jak łatwo policzyć zajmuje on teraz 160 x 128 = 20480 bajtów, czyli nadal sporo, ale zawsze można zastosować kolejne optymalizacje. Wyświetlacz oczekuje danych w postaci RGB565, czyli 16-bitowych wartości gdzie 5-bitów określa składową czerwoną, 6-zieloną, a 5-niebieską. Paleta to po prostu 256-elementowa tablica, która zawiera wartości opisujące dany kolor: uint16_t palette[256]; W docelowym programie moglibyśmy dobrać idealną paletę do naszego zastosowania i zapisać ją w pamięci flash (albo w samym programie). Jak wspomniałem tutaj prezentuję jedynie demo, więc paletę będę obliczać: Prawdę mówiąc takie rozwiązanie nie wyglądało najładniej, bo nie można w nim reprezentować bieli, więc zamiast uzupełniać zerami, uzupełniłem jedynkami - jak napisałem, to tylko demo. Bardzo prosty kod przeliczający 8-bitową paletę, na 16-bitowy kolor dla wyświetlacza wygląda następująco: static inline uint16_t palette2rgb(uint8_t color) { uint16_t r = ((uint16_t)color & 0xe0) << 8; uint16_t g = ((uint16_t)color & 0x1c) << 6; uint16_t b = ((uint16_t)color & 0x03) << 3; return __REV16(0x18e7 | r | g | b); } Ta magiczna wartość 0x18e7 to właśnie uzupełnienie jedynkami - wiem że to brzydki kod, z góry za niego przepraszam, ale to mało istotny fragment, zachęcam oczywiście do zastosowania o wiele lepszych rozwiązań. Teraz przechodzimy do najważniejszego, czyli przeliczania 8-bitowych danych w buforze, na docelowe 16-bitowe przeznaczone dla wyświetlacza. Przesyłanie po jednym bajcie nie działa wydajnie, więc utworzymy nieduży bufor tymczasowy, ja ustaliłem jego wielkość na 512 pikseli: #define TX_BUF_SIZE 512 static uint16_t tx_buf[TX_BUF_SIZE]; Skoro wyświetlacz ma rozdzielczość 160 x 128, więc jak łatwo policzyć będziemy ten bufor wypełniać i wysyłać 40 razy, aby przesłać cały obraz. Funkcja do wypełniania bufora wygląda następująco: static void fill_tx_buf(uint32_t part) { uint16_t *dest = tx_buf; uint8_t *src = lcd_framebuffer + part * TX_BUF_SIZE; for (uint32_t i = 0; i < TX_BUF_SIZE; i++) *dest++ = palette2rgb(*src++); } Jako parametr podajemy indeks bufora, czyli wartość 0..39, po jej wykonaniu bufor tx_buf będzie zawierał dane do przesłania. Teraz możemy napisać funkcję rysującą zawartość naszego ekranu: void lcd_copy(void) { lcd_cmd(ST7735S_RAMWR); HAL_GPIO_WritePin(LCD_DC_GPIO_Port, LCD_DC_Pin, GPIO_PIN_SET); HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_RESET); for (uint32_t i = 0; i < LCD_WIDTH * LCD_HEIGHT / TX_BUF_SIZE; i++) { fill_tx_buf(i); HAL_SPI_Transmit(&hspi2, (uint8_t*)tx_buf, 2 * TX_BUF_SIZE, HAL_MAX_DELAY); } HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_SET); } Musimy jeszcze zmodyfikować naszą bibliotekę graficzną, tak żeby pracowała z 8-bitowymi kolorami, ale to właściwie kosmetyczna zmiana. Czas skompilować program: Zgodnie z oczekiwaniami zużycie pamięci RAM znacznie spadło i wynosi niecałe 23KB. Przetestujmy wydajność naszego programu: Jak widzimy rysowanie w lokalnym buforze zajmuje tyle samo czasu, czyli 7ms, natomiast kopiowanie trochę więcej niż poprzednio, bo 37ms zamiast 33ms. Warto przy okazji przetestować wydajność funkcji wypełniającej bufor, czyli fill_tx_buf: void lcd_test(void) { uint32_t start = HAL_GetTick(); for (uint32_t i = 0; i < 1000; i++) fill_tx_buf(i % (LCD_WIDTH * LCD_HEIGHT / TX_BUF_SIZE)); uint32_t end = HAL_GetTick(); printf("lcd_test: %ld us\r\n", end - start); } Wywołanie 1000 razy fill_tx_buf zajmuje 110ms, czyli jedno jej wywołanie ok. 110us. Jak pamiętamy używamy jej 40 razy, co zgadza się z pozostałymi pomiarami - trochę ponad 4ms zużyliśmy na obliczenia, ale zaoszczędziliśmy prawie 20KB pamięci. Użycie tablicy zamiast obliczeń pewnie pozwoliłoby skrócić ten czas, ale jak wspominałem, to tylko przykład. Nie będę wstawiał kolejnego filmu, bo już tyle razy widzieliśmy ekran testowy, że chyba każdy ma go dosyć. Czas udoskonalić nasz program. Użycie DMA W poprzedniej części korzystaliśmy z DMA, więc nowy program jest pod wieloma względami "gorszy". Użyjmy więc HAL_SPI_Transmit_DMA zamiast, HAL_SPI_Transmit. Procedura wysyłania będzie wyglądała następująco: void lcd_copy(void) { lcd_wait_ready(); lcd_busy = true; lcd_cmd(ST7735S_RAMWR); HAL_GPIO_WritePin(LCD_DC_GPIO_Port, LCD_DC_Pin, GPIO_PIN_SET); HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_RESET); tx_part = 0; fill_tx_buf(tx_part++); HAL_SPI_Transmit_DMA(&hspi2, (uint8_t*)tx_buf, 2 * TX_BUF_SIZE); } Wypełniamy w niej bufor pierwszym fragmentem obrazu i rozpoczynamy wysyłanie. W zmiennej tx_part przechowujemy informację o numerze kolejnego fragmentu do wysłania. Musimy teraz obsłużyć przerwanie informujące o zakończeniu transmisji i w nim przygotować dane dla następnego fragmentu, albo zakończyć całą operację: void lcd_copy_done(void) { if (tx_part < LCD_WIDTH * LCD_HEIGHT / TX_BUF_SIZE) { fill_tx_buf(tx_part++); HAL_SPI_Transmit_DMA(&hspi2, (uint8_t*)tx_buf, 2 * TX_BUF_SIZE); } else { HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_SET); lcd_busy = false; } } Po uruchomieniu zobaczymy, że program działa tak samo jak poprzednio. Różnica jest jednak taka, że podczas transmisji przez DMA procesor może wykonywać inne zadania. Jednak czas kopiowania obrazu nadal wynosi 37ms. Jeszcze jedna ważna uwaga - w przerwaniu generujemy dane dla kolejnego bufora, więc na 110us blokujemy przerwanie. Długie procedury obsługi przerwań to nic dobrego, ale STM32 pozwala na szczęście na ustawienie priorytetów przerwań. Możemy więc przerwaniu od DMA nadać niski priorytet i dzięki temu nasze obliczenia nie będą opóźniały innych, pilniejszych zadań: Użycie podwójnego bufora Jeśli podłączymy analizator logiczny to zobaczymy, że komunikacja z wyświetlaczem ma "przerwy". Wynika to stąd, że gdy obliczamy dane dla kolejnego fragmentu ekranu komunikacja jest zatrzymywana. Możemy trochę skomplikować nasz program, ale jednocześnie przyspieszyć działanie. Tym razem użyjemy dwóch buforów, albo raczej jednego większego. Gdy DMA będzie wysyłało jedną część danych, będziemy mieli czas na przygotowanie następnej. Deklarujemy więc większy bufor: #define TX_BUF_SIZE 512 static uint16_t tx_buf[TX_BUF_SIZE * 2]; Funkcja wypełniania bufora będzie teraz zapisywać parzyste fragmenty w pierwszej części tx_buf, a nie nieparzyste w drugiej: static void fill_tx_buf(uint32_t part) { uint16_t *dest = (part % 2 == 0) ? tx_buf : tx_buf + TX_BUF_SIZE; uint8_t *src = lcd_framebuffer + part * TX_BUF_SIZE; for (uint32_t i = 0; i < TX_BUF_SIZE; i++) *dest++ = palette2rgb(*src++); } Przed rozpoczęciem transmisji wypełnimy nie jeden, ale dwa bufory: void lcd_copy(void) { lcd_wait_ready(); lcd_busy = true; lcd_cmd(ST7735S_RAMWR); HAL_GPIO_WritePin(LCD_DC_GPIO_Port, LCD_DC_Pin, GPIO_PIN_SET); HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_RESET); tx_part = 0; fill_tx_buf(tx_part++); fill_tx_buf(tx_part++); HAL_SPI_Transmit_DMA(&hspi2, (uint8_t*)tx_buf, 4 * TX_BUF_SIZE); } Ostatnia zmiana to obsługa nowego przerwania, które będzie wywoływane po przesłaniu połowy danych: void HAL_SPI_TxHalfCpltCallback(SPI_HandleTypeDef *hspi) { lcd_copy_halfdone(); } Gdy otrzymamy to przerwanie, będziemy po prostu wypełniać następny bufor: void lcd_copy_halfdone(void) { fill_tx_buf(tx_part++); } Natomiast procedura obsługi końca transmisji prawie się nie zmieniła, jedyna różnica to wielkość bufora: void lcd_copy_done(void) { if (tx_part < LCD_WIDTH * LCD_HEIGHT / TX_BUF_SIZE) { HAL_SPI_Transmit_DMA(&hspi2, (uint8_t*)tx_buf, 4 * TX_BUF_SIZE); fill_tx_buf(tx_part++); } else { HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_SET); lcd_busy = false; } } Program jest nieco bardziej skomplikowany, ale w nagrodę otrzymaliśmy czas kopiowania identyczny jak w wersji z poprzedniego odcinka, ale zużyliśmy mniej pamięci: Na zakończenie jeszcze mały przykład wykorzystania naszego nowego programu. Program demonstracyjny Jakiś czas temu na forum pojawił się wątek z pytaniem o sposób wyświetlania kołowego progres baru. Pytanie sprowokowało ciekawą dyskusję na temat możliwości wydajnej realizacji takiego zadania. Skoro mamy opanowane sterowanie wyświetlacza TFT, możemy spróbować narysować nieco podobny element, a przy okazji sprawdzić jak nasza "biblioteka" sprawdzi się w realnym przykładzie. Zacznijmy od małej powtórki z matematyki oraz pewnego uproszczenia. Dla ułatwienia rysujmy tylko połowę progres-bara, zawsze możemy później rozbudować program. Rysowanie pionowych linii jest na ogół dość szybką operacją, więc zastanówmy się jak narysować wykres pionowymi (albo poziomymi) liniami. Kąt alfa oraz promienie r1 i r2 to nasze dane. Ja wybrałem rysowanie pionowych linii, więc x będzie zmienną. Wszyscy pamiętamy z matematyki wzór okręgu: x2 + y2 = r2. Po karkołomnych przejściach matematycznych uzyskujemy więc: y1 = sqrt(r1 - x2) y3 = sqrt(r2 - x2) Funkcja sqrt to pierwiastek. Jeśli ktoś jest miłośnikiem optymalizacji to wartości y1 i y2 może raz policzyć i trzymać w tablicy (najlepiej w pamięci Flash). Jak wspominałem program to demo, więc na razie nie będzie aż tak optymalny. Zostaje jeszcze obliczenie y2. Jest to odrobinę trudniejsze, może wymagać szybkiej powtórki z trygonometrii, a jak pamiętamy tg(alpha) = y/x, więc: y2 = x * tg(alpha) Tutaj znowu możemy tablicować wartości, ale na początek zostawmy prostą wersję. Mamy więc dla każdego x obliczone y1, y2 i y3. Teraz wystarczy sprawdzić jak y2 ma się do pozostałych i są możliwe 3 przypadki: jeśli y2 <= y1 to nic nie rysujemy jeśli y2 >= y3 to rysujemy "pełną" linię od y1 do y3 a jeśli y1 < y2 < y3 to linię od y1 do y2 Rysowanie możemy więc wykonać następującym programem: void draw_bar(uint32_t r1, uint32_t r2, uint32_t alpha) { float t = tan(alpha * M_PI / 180.0); bar_circle(0, 0, r1, WHITE); bar_circle(0, 0, r2, WHITE); bar_line(0, 0, r1 * cos(alpha * M_PI / 180.0) * 0.8f, r1 * sin(alpha * M_PI / 180.0) * 0.8f, WHITE); for (uint32_t x = 0; x <= r2; x++) { uint32_t y1 = (x < r1) ? sqrt(r1 * r1 - x * x) : 0; uint32_t y2 = sqrt(r2 * r2 - x * x); uint32_t y3 = x * t; if (y3 > y2) bar_line(x, y1, x, y2, WHITE); else if (y3 > y1) bar_line(x, y1, x, y3, WHITE); } } Funkcje bar_circle i bar_line są dodane aby "przenieść" nasz początek współrzędnych w odpowiednie miejsce: static void bar_circle(uint32_t x, uint32_t y, uint16_t r, uint8_t color) { lcd_circle(LCD_WIDTH - 1 - x, LCD_HEIGHT - 1 - y, r, color); } static void bar_line(uint32_t x1, uint32_t y1, uint32_t x2, uint32_t y2, uint8_t color) { lcd_line(LCD_WIDTH - 1 - x1, LCD_HEIGHT - 1 - y1, LCD_WIDTH - 1 - x2, LCD_HEIGHT - 1 - y2, color); } Dodajmy jeszcze "wskazówkę", pomiar czasu działania oraz wyświetlanie wartości: void draw_test_screen(uint32_t value) { char buf[32]; uint32_t start = HAL_GetTick(); lcd_clear(BLUE); draw_bar(117, 127, value); sprintf(buf, "%ld", value); lcd_fill_rect(110, 90, 150, 120, BLACK); lcd_draw_string(120, 100, buf, &Font16, WHITE, BLACK); lcd_copy(); uint32_t time = HAL_GetTick() - start; printf("drawing: %lu ms\r\n", time); } Teraz program jest gotowy: Nawet bez tablicowania wartości i z arytmetyką zmiennopozycyjną rysowanie zajmuje ok 22ms. Kopiowanie to 33ms, mamy więc prawie 20 klatek na sekundę, ale pewnie dałoby się więcej. Podsumowanie Początkowo planowałem napisanie jednego, może dwóch artykułów odnośnie sterowania wyświetlaczem TFT. Okazało się jednak, że temat jest o wiele obszerniejszy i ciekawszy, a 5 części to właściwie dopiero wstęp. Mam nadzieję, że udało mi się pokazać jak można sterować wyświetlaczem kolorowym oraz zachęcić do własnych eksperymentów i udoskonalania zaprezentowanych rozwiązań. Spis treści: Sterowanie wyświetlaczem TFT - część 1 - wstęp, podstawowe informacje Sterowanie wyświetlaczem TFT - część 2 - analiza problemu Sterowanie wyświetlaczem TFT - część 3 - testy prędkości na STM32 Sterowanie wyświetlaczem TFT - część 4 - własny program Sterowanie wyświetlaczem TFT - część 5 - optymalizacja programu
  8. 13 punktów
    Większość osób myśląc o cyfrowej telekomunikacji, myśli o współczesne mikroelektronice: smartfonach, komputerach i Internecie. Nie każdy zdaje sobie sprawę z tego, że idea przesylania informacji zakodowanej w ciągach zer i jedynek jest dużo, dużo starsza. Pierwszym urządzeniem tego rodzaju był telegraf skonstruowany przez Emille'a Baudot w latach siedemdziesiątych XIX wieku. Urządzenie po stronie nadajnika posiadało klawiaturę złożoną z pięciu przycisków, które operator musiał wciskać w różnych kombinacjach. Urządzenie wysyłało na linię ciąg impulsów, odpowiadających wciśniętej kombinacji. Odbiornik interpretował ten sygnał drukując na papierowej taśmie odpowiednią literę lub cyfrę, w jej naturalnej formie. Na początku XX wieku idea to została udoskonalona. Nadajnik został wyposażony w klawiaturę podobną do tych stosowanych w maszynach do pisania. Tak narodził się dalekopis. Transmisja danych pomiędzy tymi urządzeniami przypominała standardowy interfejs szeregowy. Z tą różnicą, że z przeciwieństwie do TTL UART-a czy RS323 poszczególne stany logiczne nie były kodowane przez wartości napięć, ale przez fakt przepływu (bądź nie) prądu w obwodzie. Normalnie przez linię płynął prąd o ustalonej wartości (zazwyczaj 60, 40 lub 20 mA). To był stan domyślny. Rozpoczęcie nadawania kolejnego znaku wymagało nadania bitu startu, czyli chwilowego przerwania obwodu. Potem nadajnik oczekiwał na pięć bitów z kodem znaku w alfabecie Baudot (zwanym także międzynarodowym alfabetem telegraficznym). Na końcu pojawiały się bity stopu w trakcie których odebrany znak był drukowany na papierze. Ktoś zapewne zauważył już, że używając pięciu bitów można było zakodować maksymalnie 32 znaki - zdecydowanie za mało, aby pomieścić wszystkie litery alfabetu, cyfry i znaki interpunkcyjne. To prawda. Stosowano pewną sztuczkę - dwie kombinacje bitów były zarezerwowane do przełączania pomiędzy dwoma rejestrami zawierającymi litery oraz cyfry i inne znaki. Ne stosowano także rozróżnienia na male i duże litery. Dalekopis chociaż w pełni cyfrowy, był urządzeniem elektromechanicznym, radzącym sobie bez pojedynczego tranzystora (chociaż oczywiście w latach osiemdziesiątych i dziewięćdziesiątych produkowano nowoczesne, elektroniczne wersje). Dalekopisy były powszechnie używane do przesyłania wiadomości przez wojsko i państwowe służby. Poczta wykorzystywała je do transmisji telegramów. Stosowano je także w roli terminali komputerowych, przed pojawieniem się monitorów CRT. Ślad tej zaszłości historycznej zachował się w nomenklaturze stosowanej w systemach uniksowych, gdzie terminal jest oznaczany skrótem TTY - od angielskiego słowa "teletype", czyli właśnie dalekopis. Przepraszam za ten przydługi wstęp, nie byłem jednak pewien, czy wszyscy będą jeszcze kojarzyć o jakie urządzenie chodzi... Przechodząc do sedna sprawy. Na co dzień pracuję w krakowskim Muzeum Inżynierii Miejskiej. Jakiś czas temu został nam przekazany dalekopis T100, wyprodukowany w latach siedemdziesiątych w Czechoslowacji, na licencji Siemensa. Ponieważ posiadaliśmy już taki eksponat, zostałem poproszony o sprawdzenie możliwości uruchomienia go i wykorzystywania w roli interaktywnej instalacji, zamiast "martwego" eksponatu ukrytego w muzealnej gablocie. Tak rozpoczęły się moje eksperymenty. Najpierw skonstruowałem prosty interfejs USB, oparty na starym mikrokontrolerze AT89C2051 i układzie FTDI. Do generowania pętli prądowej 40 mA używałem zestawu kilku baterii 9V oraz rezystorów o dużej mocy. Komunikacja z dalekopisem ruszyła bez problemu - pojawiła się jednak inna trudność. Okazało się, że uszkodzony jest moduł wzywaka - urządzenia odpowiedzialnego m.in. za zdalne włączanie silnika dalekopisu przy połączeniu przychodzącym, sygnalizowanym odwróceniem kierunku przepływu prądu w linii. Naprawa tego modułu okazała się bardziej skomplikowana niż początkowo sądziłem, ostatecznie postanowiłem więc wymontować wadliwą część i sterować silnikiem za pomocą przekaźnika, zamontowanego w moim interfejsie. Finalna wersja interfejsu zawiera mikrokontroler PIC32MX270F256B oraz moduł GSM SIM800L. Wykorzystałem także 2MB pamięć SPI flash, do wykonywania elektronicznej kopii przychodzących wiadomości. W osobnej obudowie znajduje się generator pętli prądowej, złożony z zasilacza transformatorowego oraz zestawu kondensatorów. Całość można obecnie oglądać na wystawie "Uwaga! Nieprzyjaciel podsłuchuje." w Muzeum Inżynierii Miejskiej w Krakowie. Po wysłaniu SMS-a na podany numer można oglądać dalekopis podczas pracy.
  9. 13 punktów
    Witam po dłuższej przerwie, z tego co kojarzę to mój pierwszy post na Forbocie - wcześniej pisałem jeszcze na dioda.com.pl. Przedstawiam projekt inteligentnej kawalerki oparty o Raspberry Pi i kilku modułów pracujących w magistrali I2C i 1wire. Umożliwia on na automatyzację instalacji elektrycznej mieszkania poprzez m.in. sterowanie oświetleniem przez dedykowaną aplikację www, rozszerzenie funkcji przycisków światła w mieszkaniu poprzez niezależne przypisywanie funkcji np.gaszenie wszystkich świateł włącznikiem przy łóżku, a zapalanie tylko oświetlenia dodatkowego. Monitorowanie temperatury w pomieszczeniu i na zewnątrz, oraz informowanie komunikatami głosowymi o zdarzeniach. System jest elastyczny i modyfikowany w zależności od zachcianek użytkownika, dzięki czujce ruchu, możemy np. w zaprogramowanych nocnych godzinach delikatnie rozjaśniać światła dekoracyjne, nie oślepiając zaspanego nocnego marka. Innym przykładem który pojawił się podczas używania systemu, było wysłanie diodą IR sygnału do włączenia się telewizora po wejściu do mieszkania, lub w przypadku braku użytkowników w mieszkaniu i zwiększonym zużyciu prądu (np zostawione żelazko) - poinformowanie i wyłączenie sprzętów. Ilość możliwych funkcji do zrealizowania jest ogromna niestety każda kolejna powoduje dodatkowe koszty. O ile część modyfikacji można wykonać małym kosztem - jak wspomniane sterowanie ir, to już realizacja pomysłu zabezpieczenia łazienki przed zalaniem poprzez sensor wody i elektrozawór na głównym przyłączu wodociągowym wiąże się z dodatkowym nakładem pracy. W projekcie użyłem popularnych i wspieranych przez społeczności użytkowników części oraz oprogramowania. W krótkim wstępie nie sposób wymienić wszystkich funkcjonalności i drobnych smaczków o których sam dopiero sobie przypominam. W dalszej cześci opiszę działanie całego systemu od strony programowej i sprzętowej oraz udostępnię kody źródłowe strony www i skryptów odpowiedzialnych za automatykę wraz z obrazowym poradnikiem jak to wszystko uruchomić. Mam nadzieje że dam radę bo trochę tego się uzbierało, na początek film z działania: Część sprzętowa. Pierwszym etapem prac było przerobienie instalacji elektrycznej w mieszkaniu. Tutaj głównym założeniem było wykorzystanie standardowych pojedynczych bistabilnych przycisków i pociągniecie wszystkich przewodów włączników i punktów oświetleniowych do jednego punktu. Gniazda zasilające zostały podzielone na 3 sekcje - kuchnia, sprzety rtv, łazienka. Punktów oświetleniowych jest 5, włączników razem z dzwonkiem na zewnątrz również 5. Do włączników został pociągniety przewód 2 x 1.5mm2, tak aby w przypadku demontażu systemu, można było podłączyć wszystko na stałe. Przewody do punktów oświetleniowych 3x1.5mm2, 3 linie gniazd zasilających 3x2.5m + dodatkowy przewód 5x2.5mm2 do trójfazowego zasilania kuchni. Do centralnego punktu zostało doprowadzone 5 sztuk skrętki cat.5 i wyprowadzone odpowiednio do: łazienki, kuchni, routera, oraz dwóch rogów pomieszczenia. Skrętka umożliwia podłączanie do całego systemu np. czujników w magistrali 1-wire, czy sterowanie sygnałem PWM układami mocy oświetlenia ledowego. Łacznie wykorzystałem około 150metrów przewodów. W skrzynce rozdzielczej zamontowane zostały zabezpieczenia oraz listwy rozdzielcze umożlwiające podłączanie urządzeń do układów wejść - wyjść. Poniżej zdjęcia z procesu wymiany instalacji elektrycznej. Cześć sprzętowa - elektronika. Tutaj zastosowane zostały: - Raspberry Pi - jako główny mózg całego systemu - Moduł 8 wejść - wyjść firmy Kamami. - Moduł przetwornika A/C firmy Adafruit. - Moduł 16 wyjść PWM firmy Adafruit. - 2 Czujniki temperatury DS18B20 - Konwerter napięć 3.3 <> 5V - Moduł 4 przekaźników. - 2 Moduły transystorów mosfet do sterowania ledami. - Głośniki komputerowe zasilane z USB Wszystkie podłączenia wykonane zgodnie ze standardowymi przykładami danych modułów czy czujników nie ma tu jakiś skomplikowanych połączeń - wszystkie moduły pracują na magistrali I2C przy zasilaniu 5V - dlatego potrzebny był dodatkowy konwerter napięć tak aby można było podłączyć magistralę do 3.3 woltowego Raspberry Pi. Czujniki na magistrali 1wire spokojnie dają radę przy 15 metrowej skrętce podłączone bezpośrednio pod RPI. Wykorzystane oprogramowanie. - Framework WebIOPi. Głównym frameworkiem użytym w projekcie jest WebIOPi. Jest to gotowa aplikacja dedykowana dla komputera RaspberryPi pozwalająca na sterowanie podłączonymi do niego urządzeniami za pomocą strony internetowej lub skryptów działających w tle. Framework dostępny jest w postaci gotowej paczki instalacyjnej dla systemu linux. Aplikacja uruchamia na komputerze serwer www, na którym możemy uruchomić stronę internetową, a z jej poziomu sterować poszczególnymi urządzeniami. WebIOPi pozwala na sterowanie i monitoring ponad 30 urządzeń pracujących zarówno na magistrali I2C jak i 1-Wire. Framework rozdziela układ sterowania na dwa podstawowe elementy – część sterowania i monitoringu dostępną z poziomu przeglądarki dla użytkownika oraz część komputera, pracującą niezależnie. Skrypty wykonywane na komputerze napisane są w języku Python. Framework pozwala na pracę wielu skryptów jednocześnie. Od strony przeglądarki wykorzystana jest technologia jQuery. Użyłem wersji 0.7 webiopi. Więcej na temat samego farameworka znajdziecie tutaj: http://webiopi.trouch.com/ -Framework Bootstrap - strona www w PHP Bootstrap to środowisko służące do budowania responsywnynych stron internetowych, pozwala na bardzo dokładne dopasowanie do stron własnych potrzeb. Zawiera 12-kolumnową siatkę, zarówno w wersji ze stałą jak i z automatyczną szerokością. Posiada bogaty pakiet UI - począwszy od typografii,poprzez formularze, tabele, po nawigacje i ikonki. Całość dopełnia kolekcja skryptów JS pozwalająca na obsługę animacji ekranu. System operacyjny: Komputer Raspberry Pi działa pod kontrolą systemu operacyjnego Raspbian. Baza danych: Baza danych wykorzystana w projekcie to MySQL w wersji 5.5.41. Baza ta służy do rejestracji wszystkich zdarzeń. Pozwala na długoterminową rejestrację temperatury, napięć i prądów w całym systemie. Zapis danych realizowany jest za pomocą skryptów powłoki systemu (Bash) uruchamianych w określonym czasie za pomocą systemowego narzędzia Cron. Dane z bazy pozwalają na późniejsze tworzenie wykresów poszczególnych parametrów na stronie www. Sporą częścia projektu jest strona www - aplikacja internetowa, stąd wykorzystanie bazy MySQL i frameworka PHP, nie chciałbym się rozpisywać na temat samego pisania i uruchamiania strony www bo ta może mieć dowolną formę. Z poziomu systemu wbudowanego chodzi o to, że strona www wywołuje funkcję javascriptową frameworka webiopi, np. po wciśnięciu przycisku wywoływana jest funkcja zmiany stanu wejścia z "0" na "1" lub funkcja okresowo sprawdzająca dane z czujnika temperatury. Dzięki wykorzystaniu frameworka korzystamy praktycznie z gotowego rozwiązania które realizuje dwukierunkową komunikację www - raspberry. Uruchomienie systemu - nie jest to poradnik krok po kroku jednak przedstawia gotowy przepis. - Instalacja i podstawowa konfiguracja raspbian - tutaj odsyłam do poradników w internecie - Instalacja fail2ban Ten etap nie jest konieczny jednak ze względu na mnóstwo botów próbujących dostać się do raspberry podłączonego do internetu polecam użycie tego programu. Pozwala on na dodawanie reguł blokujących połączenia z Internetu po ustalonej liczbie nieudanych logowań. Zapobiega to atakom typu brute-force. W pliku konfiguracyjnym pakietu, dostępne są m.in. ustawienia monitorowanego portu, maksymalna liczba nieudanych prób połączenia, czas blokowania danego adresu IP . Ze względu na powtarzające się przypadki uzyskania próby dostępu do komputera ilość możliwych prób dostępu to 3, a czas blokady 30 dni. Ponieżej zrzut ekranu pokazujący adresy IP zablokowane w ciągu zaledwie jednego dnia. Potwierdza to tylko konieczność stosowania tego typu zabezpieczeń, oraz nie używania prostych haseł do tego typu systemów. Oczywiście nie raz zdarzyło się mi zablokować samego siebie - jednak w przypadku fizycznego dostępu do RPI nie stanowi to większego problemu. Po zabezpieczeniu dostępu do komputera, kolejnym krokiem jest instalacja pakietu i2ctool. Jest to pakiet dzięki któremu możliwa jest obsługa i diagnostyka magistrali I2C. Po zainstalowaniu pakietu możemy sprawdzić podłączone urządzenia za pomocą polecenia i2cdetect –y 1. Wyświetli nam ono listę podłączonych urządzeń w formie matrycy adresowej. Adresy wyświetlane są w formie szesnastkowej. Adresy poszczególnych urządzeń konfigurowane są za pomocą odpowiednich połączeń wyprowadzeń na danych modułach. W prezentowanym rozwiązaniu pod adresem 20 znajduje się moduł 8 wejść – wyjść. Adres 40, to układ 16 wyjść PWM. Adres 48 zajmuje przetwornik analogowo – cyfrowy. W celu umożliwienia sterowania magistralą niezbędne jest też dodanie użytkownika do grupy i2c. Po poprawnym zainstalowaniu I2C widoczny jest taki wynik polecenia i2cdetect: Obsługa magistrali 1-wire, nie wymaga instalacji dodatkowego oprogramowania w systemie. Lista podłączonych urządzeń wraz z ich adresami dostępna jest po sprawdzeniu zawartości katalogu systemowego /sys/bus/w1/devices/, wynik polecenia ls dla tego katalogu został przedstawiony na zdjęciu poniżej. Do magistrali zostały podłączone dwa czujniki temperatury DS18B20. Dla najnowszego raspbiana powyższy opis może być trochę przekłamany, ja korzystałem z dystrybucji pobranej w styczniu 2015 roku, ostatnio przy zabawie z raspberry i uzyciu najnowszego systemu konieczne jest dopisanie linijki w pliku konfiguracyjnym. Opisane jest to m.in tutaj: http://osworld.pl/raspberry-pi-obsluga- termomertrow-ds18b20/ Głównym etapem jest instalacja najważniejszego frameworka, pakietu WebIOPi. Instalacja polega na pobraniu spakowanej paczki ze strony autora i uruchomieniu skryptu instalacyjnego. Tutaj żeby nie kopiować internetu również odsyłam na stronę gdzie opisana jest cała instalacja: http://webiopi.trouch.com/INSTALL.html Dostępne sa tam również przykłady dla konkretnych urządzeń oraz dokumentacja pozwalająca zrozumieć zasadę działania. W dalszej części przedstawie fragmenty swoich skryptów, dla konkretnego rozwiązania. Początek etapu instalacji: Po zainstalowaniu pakietu. I wydaniu polecenia startowego /etc/int.d/webiopi start, możemy za pomocą przeglądarki internetowej otworzyć domyślną stronę internetową frameworka WebIOPi. Adres strony to numer IP komputera oraz domyślnie port :8000. Po wpisaniu adresu, strona będzie wymagała uwierzytelnienia w postaci domyślnego hasła. Widok domyślnie hostowanej strony został przedstawiony na zdjęciu poniżej. Są to podstawowe elementy frameworka umożliwiające sprawdzenie jego działania w tym przypadku działania układów wejść -wyjść. Po sprawdzeniu działania podstawowych funkcji frameworka, należy za pomocą pliku konfiguracyjnego określić sposób jego działania. Polega to na dopisaniu wszystkich adresów urządzeń które mają być obsługiwane. W projekcie będą to 3 urządzenia w magistrali i2c, opisane jako adc, mcp oraz pwm. A także 2 urządzenia magistrali 1-wire opisane jako temp1 oraz temp2. Każde ze zdefiniowanych urządzeń prezentuje na stronie diagnostycznej rejestrowane parametry oraz jeżeli jest to możliwe, przyciski do sterowania testowania i zadawania wartości. Na tym etapie możliwe jest dokładne sprawdzenie działania wszystkich podzespołów. Po zakończeniu testów, w pliku konfiguracyjnym należy podać ścieżkę docelowej strony sterującej, oraz dodać aplikację do skryptów startowych systemu. Dokładny opis: http://webiopi.trouch.com/Tutorial_Basis.html Kolejnym krokiem jest instalacja serwera apache wraz z modułami bazy danych mysql potrzebnymi do jej obsługi. Po instalacji wymagane jest stworzenie bazy danych, potrzebnej do rejestracji parametrów z czujników. Instalacja serwera FTP, znacznie ułatwia wymianę plików z komputerem, oraz późniejsze edytowanie skryptów odpowiedzialnych za działanie systemu. W prezentowanym rozwiązaniu został zainstalowany pakiet proftpd. Współpracuje on z programem fail2ban zabezpieczając dodatkowo zawartość przed niepowołanym dostępem. Wszystkie niezbędne pakiety zostały zainstalowane. Za pomocą protkołu FTP została wgrana strona www oraz skrypty sterujące do ścieżki wcześniej ustawionej w pliku konfiguracyjnym WebIOPi. Aplikacja internetowa: Aplikacja internetowa. Aplikacja internetowa w formie strony www została napisana wykorzystując języki HTML, CSS i JavaScript. Wykorzystanie skryptów JavaScript pozwoliło na wyświetlanie i sterowanie parametrami sterownika na stronie bez konieczności jej przeładowywania. Jednym z założeń było stworzenie strony działającej na urządzeniach mobilnych. Zostało to zrealizowane przy pomocy frameworka Bootstrap, który automatycznie dopasowuje jej zawartość do szerokości i proporcji ekranu. Interfejs aplikacji został zaprojektowany w formie prostokątnych kafli, z których każdy odpowiada za inną funkcję. Poniżej został przedstawiony widok strony startowej na komputerze z monitorem o rozdzielczości 1920x1080, oraz telefonu komórkowego o takiej samej rozdzielczości. Pomimo takiej samej rozdzielczości ekranu, strona została odpowiednio powiększona i dopasowana do komfortowego przeglądania jej na telefonie komórkowym. Poszczególne zakładki zostały ukryte w formie rozwijanego menu dostępnego pod jednym przyciskiem (prawy górny róg). Strona składa się z 4 głównych zakładek: monitoring, oświetlenie, diagnostyka oraz ustawienia. Pierwsza zakładka to jednocześnie strona startowa. Wyświetla ona najważniejsze rejestrowane parametry takie jak temperatura w pokoju dziennym, temperatura na zewnątrz, prąd pobierany przez cały obiekt, stan poszczególnych punktów oświetlenia, napięcie zasilania sterownika, oraz stan elementów nadzorujących bezpieczeństwo w obiekcie. Poszczególne kafelki wyświetlają informacje o tych parametrach oraz pozwalają na interakcję w postaci uruchamiania określonych funkcji. W przypadku przekroczenia nominalnej wartości danego parametru, np. temperatury w pokoju dziennym wyższej niż 22 stopnie Celsjusza, kafelek wyświetlający ten parametr zmienia kolor na pomarańczowy. Użytkownik zostaje również powiadomiony o tym fakcie, odtworzeniem informacji „Temperatura w pomieszczeniu jest za wysoka”, za pomocą podłączonych do komputera głośników. Odtwarzaniem dźwięku zajmują się niezależnie pracujące skrypty. Analogiczna sytuacja ma miejsce w przypadku zbyt niskiej wartości temperatury. Kafelek zmienia kolor na niebieski, a użytkownikowi zostaje odtworzony komunikat „Temperatura w pomieszczeniu jest za niska”. Aplikacja internetowa spełnia tylko rolę interfejsu komunikacyjnego z użytkownikiem, nie jest niezbędna do działania całego systemu, jednak pozwala na sterowanie systemem oraz podgląd zarejestrowanych parametrów. Kafelek odpowiedzialny za wyświetlanie temperatury, jest jednocześnie przyciskiem otwierającym okno wykresu, który generowany jest na podstawie ostatnich 200 pomiarów temperatury, rejestrowanych co 15 minut.: Wykres generowany jest za pomocą biblioteki Google Chart API, pozwalającą na dowolną konfigurację wyświetlanych elementów. Po kliknięciu na dany punkt wykresu, w prawym górnym rogu wyświetlana jest szczegółowa informacja o zarejestrowanym parametrze. Wykres jest animowany, pozwala na powiększenie danego fragmentu w celu dokładniejszej analizy, co w przypadku np. pomiaru prądu, umożliwia zlokalizowanie źródła zużycia energii elektrycznej. Poszczególne elementy kodu potrzebne do zrealizowania wykresu to skrypt rejestrujący temperaturę i datę wykonania pomiaru do bazy danych, oraz skrypt generujący wykres, korzystający z biblioteki Google Chart API. Aktualne parametry pobrane ze sterownika wyświetlane są na stronie www za pomocą java skryptu korzystającego z możliwości frameworka WebIOPi. Jako przykład zostanie przedstawiona funkcja odświeżająca wszystkie parametry na stronie startowej z interwałem 500ms. Jej kod jest zaprezentowany poniżej: Kolejną główna kartą aplikacji internetowej jest oświetlenie. Za pomocą tej podstrony możemy sterować wszystkimi punktami oświetleniowymi, oraz monitorować ich stan. W zależności od sprzętowej konfiguracji systemu wyświetlane są tu kafelki odpowiedzialne za włączanie lub wyłącznie oświetlenia, a także sterowanie jego jasnością. Kafelek w prawym dolnym rogu pozwala na włączanie lub wyłączanie wszystkich lamp w pomieszczeniu. Ikona żarówki podświetlona na żółto informuje o zapalonej danej lampie. Wyświetlany stan jest zależny od rzeczywistego stanu wyjścia przypisanego do sterowania danej lampy. Sterowanie fizycznymi przyciskami może odbywać się niezależnie od działania aplikacji internetowej. W przypadku włączenia światła przez użytkownika w pomieszczeniu przy wykorzystaniu fizycznego przełącznika, stan przycisku w aplikacji internetowej również ulegnie zmianie. Ostatnim elementem na stronie jest sterowanie jasnością oświetlenia LED. Odbywa się ono poprzez przesuwany pasek, który zadaje wartość z przedziału 0-100 w zależności od swojej pozycji. Jednocześnie wartość ustawiana jest na przypisanym wyjściu cyfrowym w module PWM, który generuje przebieg prostokątny o wypełnieniu procentowym z przedziału 0-100. Karta „diagnostyka” jest bardzo przydatna w procesie montażu i serwisowania całego systemu. Umożliwia wykonywanie niektórych komend systemu, bezpośrednio z poziomu przeglądarki, pozwala na sprawdzanie stanu i adresów podłączonych do magistral urządzeń, posiada opcje restartu lub wyłączenia systemu, oraz wykonuje testowe odtwarzanie komendy głosowej konieczne w przypadku regulacji nagłośnienia. Ostatnią zakładką jest zakładka „Ustawienia”, która docelowo ma służyć do ustawień wyglądu poszczególnych ekranów, wartości krytycznych dla danych parametrów, oraz włączania i wyłączania poszczególnych funkcji systemu. Programami nadzorującymi pracę systemu są skrypty wykonywane cyklicznie lub na żądanie użytkownika. Skrypty wykonywane cyklicznie w systemie, zostały napisane w jezyku powłoki Bash, zaś skrypty odpowiedzialne za działanie systemu w zależności od stanu poszczególnych urządzeń napisane są w języku Python. Skrypty te wykonują większość zadań całego systemu inteligentnego budynku i są podstawą jego działania. Cykliczne wykonywanie programów zrealizowane jest za pomocą systemowego narzędzia CRON, uruchamia on co 15 minut skrypt odpowiedzialny za pomiar temperatury z czujnika temperatury i zapis jego stanu do bazy danych. Dzięki temu możliwe jest generowanie przebiegów temperatury w aplikacji internetowej. Dla każdego czujnika istnieje osobny skrypt. Kod skryptu przedstawia się następująco: Programy realizujące poszczególne funkcje systemu to skrypty pracujące pod kontrolą frameworka WebIOPi. Pozwalają one na nadzorowanie np. stanu przycisków i w przypadku jego zmiany wykonanie określonej funkcji. Ze względu na możliwość sterowania oświetleniem zarówno z aplikacji internetowej, jak i fizycznych przycisków, pojawił się problem zmienionej pozycji przełącznika światła, w przypadku zgaszenia lampy z poziomu aplikacji internetowej. Przypisanie funkcji światła na stałe do przycisku, uniemożliwiło by sterowanie nim z innych źródeł. Rozwiązaniem tego problemu jest poniższy kod, reagujący tylko na zmianę stanu przycisku i zmieniający stan lampy w zależności od tego czy jest zapalona czy zgaszona. Innym przykładem funkcji systemu są funkcje realizowane poprzez wywołanie danego makra przez użytkownika. Po wciśnięciu przycisku z poziomu przeglądarki wywoływana jest funkcja frameworka, wykonująca dane makro napisane w języku Python. I tak makro „shutdown” wykonuje polecenie systemowe „reboot” po czym zwraca do funkcji wartość „Sterownik: system zostanie wyłączony”, dzięki czemu aplikacja może wyświetlić odpowiedni komunikat. Przykładowe funkcje przedstawia poniższy fragment kodu. Za pomocą opisanych skryptów możliwa jest realizacja dowolnej funkcji żądanej przez użytkownika. W prezentowanym rozwiązaniu zostały zaimplementowane m.in. takie funkcje jak gaszenie światła w całym mieszkaniu za pomocą włącznika przy łóżku, który jednocześnie zapala tylko lampkę nocną. Szybkie przełączenie przycisku przy drzwiach wejściowych wyłączające wszystkie światła, bez konieczności wyłączania wszystkich po kolei. Skrypty powiadamiające użytkownika za pomocą odtwarzanych komunikatów, realizują swoją funkcje tylko w przypadku odpowiedniej pory dnia. Czujnik ruchu niezbędny w skrypcie alarmowym, w przypadku rozbrojonego alarmu załącza z minimalną jasnością oświetlanie LED, umożliwiając dojście do łazienki bez konieczności zapalania świateł. Podwyższony pobór prądu, który w przypadku dłuższego braku ruchu w pomieszczeniu, pozwala na poinformowanie właściciela o włączonym odbiorniku energii elektrycznej. Nie jestem w stanie opisać całego kodu aplikacji - bo jest go sporo, zamieszczam źródła do przejrzenia - które raczej nie pozwolą na bezpośrednie uruchomienie systemu ale dla kogoś korzystającego z opisanych frameworków mogą być przydatne. Na koniec jeszcze film z testów czujnika temperatury. Inteligentna kawalerka.zip
  10. 12 punktów
    Witam chce wam przedstawić mojego pierwszego robota o nazwie LEM Od dłuższego czasu w moim domu leżały nieużywane moduły zdalnego sterowania do bram wjazdowych. Stwierdziłem, że jest to marnowanie ich potencjału, w mojej szkole miał odbyć się cykliczny konkurs mam talent gdzie uczniowie z całej szkoły pokazywali co potrafią. Ten projekt był pierwszym tego typu ''talentem'' w mojej szkole i wywołał nie małe zainteresowanie. Więc tak jak napisałem wyżej za rozum robota odpowiadał moduł 12 kanałowy z wbudowanymi przekaźnikami. Nie było to najlepsze rozwiązanie, ale chciałem wykorzystać to co mam. Planując możliwości robota uparłem się na gąsienice, nie chciałem montować kół, bardziej fascynowały mnie właśnie gąsienice. Te napędzane były przez dwie niezależne głowice od wkrętarek 12v dzięki czemu lem miał możliwość skręcania. Głowice zakończone zębatkami od przerzutek rowerowych zdawały się nie najlepiej ale wystarczająco dobrze dużo lepiej zdałyby egzamin np. takie silniki z przekładnią. Ramię robota zginane jest też za pomocą silników od wkrętarek z zamontowaną śrubą trapezową. Tak działały dwa zgięcia ''ręki'' natomiast sam chwytak działał przy pomocy osi z napędu dvd. Napęd ten był nietypowy ponieważ wykorzystywał silnik dc a nie silnik krokowy jak można to spotkać w większości napędów. Nie ukrywam, ułatwiło mi to zadanie. Najwięcej czasu zajęło mi zrobienie gąsienic skradają się one z 5 łańcuchów rowerowych. co drugi nit w łańcuchu musiałem wybić i zastąpić prętem m3 ręcznie dociętym na 6cm łącząc tym samym dwa łańcuchy równolegle. Pomiędzy nimi wsunąłem dystanse zrobione z rurek od namiotu, nadały się idealne! Następnie ze starej opony rowerowej powycinałem małe elementy które zostały przewiercone i przyczepione na trytytki. Pod spód mojej maszyny doczepiłem ledy wydobyte kosztem lampki nocnej ale można je kupić również oddzielnie w formie pasków LED. Jednak to nie jedyne oświetlenie lema z przodu posiada on dwa reflektory 10W. Są to nieco zmodyfikowane lampki rowerowe, rozebrałem obudowę lampki i włożyłem tam własne ogniwo led. Te grzało się tak bardzo, że niezbędne okazało się zamontowanie z tyłu radiatory chłodzące. na powyższym zdjęciu można zaobserwować rurę u dołu robota jest to niedopracowany odkurzacz działający na wentylatorze komputerowym, jednakże działało to dość słabo dlatego traktuje to bardziej jako ciekawostkę. Ciekawy może też być tył robota. Lem nosi na swoich barkach odznakę ZSRR i znak wysokiego napięcia. Kontroler to przerobiony pad do gier z wymienionymi przyciskami i doklejonym pilotem do ledów. Robot działał na 9 akumulatorach 18650 które działały znakomicie. Jeszcze parę bajeranckich przełączników dźwigniowych tego typu lub takich i robot gotowy! film z działania okazał się zbyt duży i nie mogłem go tutaj przesłać wiec wrzuciłem na yt i proszę bardzo wszystko działa! Dziękuje wszystkim za uwagę i chcę was zachęcić tym samym do budowy odważniejszych projektów. Ten robot był prosty w podłączaniu teraz uczę się języka Arduino mam nadzieję że przeczytacie tu jeszcze nie jeden artykuł mojego autorstwa!
  11. 12 punktów
    Ech, prezenty, prezenty... Taki byłem zadowolony, że prezent dla synka skończę przez święta i będę mógł zająć się swoimi robocikami. A tu guzik: okazało się, że siostra weszła w posiadanie kota (czy odwrotnie, z kotami to różnie bywa) i jakiś prezent trzeba zrobić. Wyszło mi na to, że najszybciej będzie zrobić taką laserową latawicę za którą lata kot - bo i na instructables są kompletne projekty, i na thingiverse gotowe STL-e, a i na naszym Forbocie ktoś coś ostatnio publikował... niewiele myśląc obiecałem, że taką zabawkę zrobię i kończąc świąteczną wizytę udałem się do domu (drugi koniec Polski). Po przyjeździe okazało się, że: Forbotowy projekt (LaserCat) jest mi absolutnie do niczego nie przydatny - zero konkretów, nawet kawałka kodu nie ma żeby sobie zerżnąć Projekty z instructables są jakieś takie uproszczone i nie pasują mi do niczego (oprócz podpatrzenia na filmikach na YT jak lata mucha) Jedyne na czym mogę się wzorować (ale tylko wzorować) to zawieszenie lasera z thingiverse. Postanowiłem więc opracować sobie jakieś wstępne założenia (jak zwykle w maksymalnym stopniu używając części z szuflady). Wyszło mi coś takiego: Mikrokontroler - moduł Arduino Pro Mini; Sterowanie - żadnych błękitnych ząbków, super wypasionych aplikacji na komórkę, serwerów http i wifi, ma być najprostszy pilot na podczerwień plus klawisz START na obudowie; Zasilanie z akumulatora; Dwa tanie serwa SG90 jako napęd; Możliwość łatwego zaprogramowania obszaru, po którym ma latać mucha. Obudowę chciałem początkowo wydrukować w całości, ale okazało się, że leży mi i zawala miejsce nówka Kradex Z-5 - oczywiste było więc jej wykorzystanie. Zacząłem od mechanizmu pan-tilt. Ten z thingiverse nie podobał mi się z dwóch powodów: po pierwsze oba serwa były w nim ruchome, podczas gdy wystarczałoby tylko jedno, po drugie wydruk wymagał za dużo wysokich podpór. Ponieważ i tak musiałem czekać na zamówione kilka części (nie miałem np. diody laserowej ani niepotrzebnego pilota), postanowiłem przeznaczyć ten czas na zaprojektowanie i sprawdzenie mechanizmu. Przede wszystkim postanowiłem wydrukować oddzielnie obejmę diody i mocowanie do serwa. Pozwoliło mi to na pozbycie się niepotrzebnych podpór przy druku, a jednocześnie dało większą możliwość jakichś manipulacji przy ewentualnym błędzie (jak się okazało - sprawdziło się to, ale o tym później). Dodatkowo chciałem tam zrobić jakieś miejsce na przewody (do diody i serwa), a przy okazji zrobić ten element nieco bardziej uniwersalnym - czyli z możliwością poprowadzenia przewodów z jednej lub drugiej strony. Dodatkowo niepotrzebny okazał się główny element mocujący - ponieważ serwo poziomu jest nieruchome, przymocowane zostało bezpośrednio do obudowy. Tak więc mechanizm działa w ten sposób: Oto zestaw elementów potrzebnych do złożenia całości (bez wkrętów i serw) oraz zmontowany mechanizm: Jak widać, orczyk musiał być przycięty tak, aby zmieścił się w przygotowanym rowku w uchwycie. Jeden z wkrętów mocujących orczyk do uchwytu (użyłem oryginalnych wkrętów dołączonych do serwa) - ten na krótszym ramieniu - musiał być również lekko przycięty, inaczej zawadzałby o obudowę serwa. Najlepiej po prostu skrócić oba wkręty i wkręcić je od wewnątrz (od strony orczyka) tak, aby nie wystawały poza obejmę. Oczywiście otwory w orczyku należy rozwiercić tak, aby wkręt się zmieścił! W załączniku STL-e i plik OpenSCAD-a: LaserFly.zip UWAGA! Co prawda oficjalna stabilna wersja OpenSCAD-a wystarcza do otwarcia pliku i wygenerowania STL-i, ale do działania customizera wymagana jest wersja co najmniej 2019.05! Teraz przyszła kolej na stworzenie schematu zabawki (co w rzeczywistości sprowdzało się do rozstrzygnięcia, które biblioteki gryzą się ze sobą i co podłączyć do którego pinu). Jako że biblioteki Servo i IRremote używają timerów (uniemożliwiając działanie PWM na niektórych pinach) a chciałem jednak mieć możliwość regulacji świecenia diody - wyszło mi coś takiego: I tu od razu uwaga: kondensator C1 został dodany w czasie eksperymentów z ustaleniem przyczyny niedziałania serwa. Najprawdopodobniej nie jest potrzebny - ale nie chciało mi się go już wyciągać Jako że w międzyczasie doszły zamówione brakujące części, mogłem zabrać się za zmontowanie całego urządzenia i pisanie programu. Przede wszystkim stwierdziłem, że obudowa Z-5 to jakiś wynalazek diabła; sterczący pośrodku jakiś szpindel ze śrubką wielce skutecznie blokuje możliwość zamontowania tam czegokolwiek, co jest większe od pudełka po zapałkach i nie ma dziury w środku. Na szczęście największy element (koszyk na akumulator) udało mi się tam upchnąć, reszta była już prosta. Dwa uchwyty mocowane do spodu obudowy śrubami od nóżek służą do utrzymania przetwornicy oraz modułu ładowarki (trzeci element niewidoczny na zdjęciu to podkładka pod ładowarkę, utrzymująca ją na właściwej wysokości koniecznej dla prawidłowego dostępu do gniazda USB): I tu kolejna uwaga: Moduły ładowarki różnych producentów mają różne wymiary (a nawet kształty płytki) - warto to sprawdzić i ew. poprawić moduł rholder w pliku OpenSCAD-a! Arduino i gniazda połączeniowe umieściłem po prostu na kawałku płytki uniwersalnej przykręconej do jednego z uchwytów. Koszyk akumulatora jest przykręcony do podstawki tak, aby możliwe było przeprowadzenie przewodów między koszykiem a podstawką, a ta z kolei skręcona jest z uchwytami. Zmontowana całość wygląda tak: Jak widać, mikroswitche są przylutowane znów do kawałka płytki uniwersalnej a ta przykręcona do ściany obudowy - to chyba najszybszy, a jednocześnie niezawodny sposób na w miarę estetyczne klawisze... Po złożeniu wszystkiego całość przedstawia się następująco: Jak widać, akumulator zamocowany jest dodatkowo opaską zaciskową. Nie jest to absolutnie niezbędne (koszyk tego typu z blaszkami zapewnia zarówno niezły styk, jak i pewne zamocowanie akumulatora) ale urządzenie miało przed sobą podróż w paczce - a wolałem nie sprawdzać, czy akumulator przypadkiem nie wypadnie w transporcie (czort jeden wie co oni tam z tymi paczkami robią, na pewno nic przyjemnego). W międzyczasie oczywiście powstawał program (w załączniku). W tym przypadku jest on dość prosty - pozwala na zaprogramowanie za pomocą pilota obszaru ruchu "muchy", punktu zerowego oraz regulację sygnału PWM diody laserowej. Jedna tylko uwaga: kod funkcji getKey dostosowany jest do konkretnego pilota z kodowaniem NEC, w razie użycia innego fragment funkcji odpowiedzialny za odczyt pilota musi byc przerobiony! Na tylnej ścianie urządzenia umieszczone są kolejno: dioda sygnalizująca i przycisk AUTO (włączający program ruchu) dioda sygnalizująca i przycisk PROG (włączający tryb programowania) dioda kontrolna, wyłącznik urządzenia oraz gniazdo USB ładowarki Odbiornik IR umieściłem w czymś w rodzaju obrotowej wieżyczki - nie wiedziałem w jakiej pozycji będzie używana zabawka a znając prawa Murphy'ego gdzie bym go nie umieścił to by akurat patrzył w odwrotną stronę Jako że nie mam możliwości umieszczenia filmiku z interakcją z kotem: krótka demonstracja działania urządzenia (ruch muchy po podłodze) oraz zapewnienie siostry, że kotu się spodobało - muszą wystarczyć I to by było na tyle. Tym razem nie liczę na mnóstwo komentarzy, ale byłoby mi miło, gdyby ktoś wykorzystał mój projekt choćby częściowo.
  12. 12 punktów
    Interaktywna zabawka dla kotów gwarantująca zabawę w każdej chwili, żaden kot nie oprze się uciekającej czerwonej kropce. Jest to niewielkie pudełeczko z wbudowanym modułem wifi i banalnie prostą obsługą. Główne funkcje: sterowanie dowolnym urządzeniem z przeglądarką internetową. losowe ruchy lasera o zmiennej prędkości. ustawianie czasu jak długo ma działać. ustawianie harmonogramów automatycznego włączenia. regulacja jasności lasera. regulacja zakresu ruchu i prędkości lasera. możliwość sterowania z dowolnego miejsca na świecie przez internet. sterowanie za pomocą google asystenta. prosta konfiguracja. Zabawka może być zasilana dowolną ładowarką od telefonu, może to być również powerbank. Przy pierwszym uruchomieniu zabawki, zostanie uruchomiona nowa sieć wifi ..::LASERCAT::.. wystarczy połączyć się z nią i wskazać naszą sieć domową, a po zrestartowaniu urządzenie automatycznie podłączy się do niej i już możemy korzystać z zabawki. Z tyłu znajduje się wejście zasilania micro USB, jak w telefonie oraz przycisk. Krótkie wciśnięcie to włączenie/wyłączenie lasera, przytrzymanie przez 3 sek. powoduje rozłączenie obecnej sieci wifi i uruchomienie ponownej konfiguracji. Gdy urządzenie jest już podłączone do naszej sieci wifi to po wpisaniu adresu zabawki w przeglądarce internetowej zobaczymy panel sterujący: Zastosowany laser jest małej mocy, taki sam jak w innych tego typu zabawkach czy bazarkowych wskaźnikach. Dodatkowo dla bezpieczeństwa jest możliwość ustawienia mocy świecenia lasera od 0% do 100%. Pozostałe ustawienia pozwolą dostosować zakres ruchów do miejsca w którym znajduje się zabawka i określić czy kropka ma się poruszać tylko po podłodze, czy częściowo wchodzić na ścianę co może dostarczyć dodatkowej frajdy dla kota. Schemat jest bardzo prosty: Widok płytki PCB: Jak zwykle w garażowym zaciszu metodą "żelazkową" - elektronicy używają żelazka zdecydowanie częściej jak ich partnerki - powstaje mała płytka. Płytka została zabezpieczona przed utlenianiem lakierem PVB16. Całą robotę wykonuje tutaj tani i lubiany układ ESP8266, który posiada moduł WiFi. Dioda laserowa jest zasilana źródłem prądowym dodatkowo kluczowanym z PWM-a co pozwala płynnie regulować jasność od 0% do 100%. Skoro już bebechy mam, to teraz trzeba to wszystko złożyć w całość. Obudowę wykonałem ze sklejki wyciętej laserowo, składanej na wczepy palcowe. No to składamy: Dodanie serwomechanizmów do których przyczepiony jest laser. Oczywiście bez trytytki projekt by się nie udał No i sprzęt jest gotowy, ale co nam po sprzęcie jak on zupełnie nie wie co ma robić? Nie wie, że teraz trzeba machać tym laserkiem tak żeby kot ganiał w tę i we w tę Trzeba to wszystko zaprogramować. Uruchamiamy nasze ulubione IDE czyli Visual Studio Code z wtyczką PlatformIO i zaczynamy pisać program. Soft został napisany z wykorzystaniem Arduino Core, a na całość składa się kilka części: główny program sterujący silniczkami, wyznaczanie losowych ścieżek. serwer www, który udostępnia ładny panel sterowania. konfiguracja sieci WiFi z wykorzystaniem Captive Portal. multicast DNS. stworzenie strony www (html + css + javascript). obsługa komunikacji po websockecie. zdalne wgrywanie plików przez stronę www, np. zmiana wyglądu głównej strony. zdalna aktualizacja oprogramowania bez zbędnych kabli. W oczekiwaniu na gotowe oprogramowanie tester cierpliwie czeka. Panel sterujący dostępny z poziomu przeglądarki internetowej nie jest hostowany nigdzie na zewnątrz, całość znajduje się w zabawce, wykorzystałem bootstrapa plus kilka dodatkowych komponentów. Zastosowany mDNS pozwala połączyć się z urządzeniem wpisując w przeglądarce adres "lasercat.local" zamiast adresu IP. Niestety na chwilę obecną android nie wspiera tego typu rozwiązań, ale na iPhonach działa to bardzo dobrze. Na filmie mała prezentacja z trochę już wybawionym głównym testerem Elroyem a poniżej pokazano jak można włączyć zabawkę po prostu mówiąc do telefonu "Ok Google, włącz laser"
  13. 12 punktów
    KTR-X1 8x8 To pojazd zdalnie sterowany do wykonywania zadań w bardzo trudnym terenie, charakteryzuje się prostotą konstrukcji, niskim środkiem ciężkości oraz uniwersalnością. KTR-X1 8x8 zbudowany jest z dwóch sekcji połączonych przegubem, dzięki temu każda sekcja jest niezależna, dodatkowo ruchome wahacze dają ogromne możliwości w pokonywaniu przeszkód w terenie. Pojazd obojętnie w jakim terenie się porusza,oraz jak stoi, zawsze ma doskonałą przyczepność na wszystkie 8 kół. Dzięki temu że KTR-X1 jest hybrydą można bez obaw wybrać się na dalekie wyprawy gdyż prądu nam nie zabraknie. Specyfikacja: Podwozie: rama stalowa z profila zamkniętego 30x30x1,5 spawana Wahacze: profil zamknięty 40x80x2 wspawane bloki łożyskowe Osie: stal utwardzana Poszycie: blacha aluminiowa 0.8mm wzmacniania kątownikami Przegub: blacha stalowa 10mm plus łożyska Przeniesienie napędu: przekładna łańcuchowa przełożenie1,5:1 Napęd: 4 silniki 24V / 450W każdy (moc znamionowa) 123 RPM Układ skrętu: pompa hydrauliczna 120 bar plus dwa siłowniki Sterownik silnika: Sabertooth 4x32A Sterownik pompy: Sabertooth 2x32A Zasilanie: Akumulatory kwasowe 12V 40Ah 2x Układ ładowania: silnik spalinowy 200c OHV plus alternator 28V 55A Koła: 145/70/6 Pilot sterowania: HK-T6 Oświetlenie: led 2x9W przód, 2x2W tył Układ chłodzenia: 2x wentylator 4800 RPM Przyłącza: szybkozłącze montażowe plus gniazdo zasilania Spalanie: 0,5-1,2l/mth Masa: 140Kg Prędkość max: 8km/h Wymiary: szer 90cm, dłu 192cm, wys 68cm, prześwit 27cm Dalsze plany: Pług do śniegu obrotowy (zrobiony) Zamiatarka (dalszy etap) Kosiarka (dalszy etap)
  14. 11 punktów
    Trochę gorącego kleju i jazda! Takim stwierdzeniem kierowałem się podczas budowy tej drukarki. Pewnie sporo drukarzy 3D zbije mnie za to, ale już lecę z wyjaśnieniem . Od paru lat marzyła mi się drukarka 3D, chociażby do drukowania obudów do przyszłych projektów, ale również jako produkcja użytecznych rzeczy "na już" - no prawie, ponieważ drukowanie nie jest natychmiastowe. Niestety ze względu na to, że mam dość mały budżet i rodzice niezbyt byli przychylni do kolejnego sprzętu w domu oraz wierzyli w moją "twórczość", nie mogłem kupić firmowej sztuki. Dopiero jak po kilku miesiącach na discordzie znalazłem grupkę osób zajmująca się właśnie drukiem jak i samą elektroniką, postanowiłem się zabrać do roboty. Po kilku dniach przemyślania i projektowania wziąłem trzy napędy DVD i za pomocą kleju na gorąco złożyłem "coś co wytłaczało plastik i wiecznie się psuło". Szczątkowe zdjęcie "tego czegoś" wygrzebane z odmętów mojego dysku twardego. Jak w końcu się zepsuło w taki sposób, że straciłem chęci do dalszych zabaw w tym kierunku, dałem sobie spokój, ale nie na długo. Po dwóch tygodniach znowu zajrzałem i natknąłem się na technologię RepRap. Dla nie wiedzących polega to na tym, że części do nowej drukarki drukuje się na pierwotnej. Poszedłem więc do lokalnego sklepu budowlanego kupić części do budowy ramy. Dokładnie to: 3 Profile aluminiowe o przekroju kwadratowym 15mm dużo kątowników (sam już nie wiem ile ich nakupiłem) 3 profile aluminiowe o przekroju okrągłym 10mm (jako prowadnice) WIEM, WIEM budowanie drukarki na takich profilach i prowadnicach to grzech, ale DZIAŁA! Nie mając warsztatu, udałem się do dziadka, z pomocą którego udało mi się złożyć dolną część ramy. Naprawdę PRZEPRASZAM, ale to są zdjęcia archiwalne, więc stąd taka jakość. Przez całą budowę drukarki posługiwałem się tylko brzeszczotem, wiertarką no i gwintownikiem, choć tego ostatniego odradzam przy profilach aluminiowych, bo sam się na tym przejechałem i zerwałem dwa gwinty. Tak czy siak z pomocą kleju na gorąco i taśmy klejącej jakoś się udało. Tydzień później znowu przyszedłem do dziadka dokończyć budowę. Po kilku godzinach składania wyszła rama, która wymagała tylko zamontowania elementów i powinno działać. Silniki kupiłem na na popularnym serwisie aukcyjnym za skromne 8zł za sztukę. Działają, nie mam zarzutów, poza tym, że musiałem zdjąć oryginalne koła zębate i zeszlifować wał, aby zamontować koła GT2. Gdy tylko przyniosłem ramę do domu, zabrałem się za dalszą część montażu. Zamontowałem hotend, ekstruder, paski i wiele innych mniej lub bardziej przydatnych elementów. Gotowy sprzęt, który już działał i wymagał tylko kalibracji Na płytę główną Creality3D v1.1.4 (dokładnie ta co występuje w Enderze 3 lub CR-10) wgrałem oprogramowanie marlin, które wspiera dowolną zmianę sprzętową m.in. Serwomechanizmy, czujniki i wiele więcej. Niestety nie zamontowałem wyświetlacza ze względu na problemy sprzętowe, lecz jak będę wymieniać płytę główną zapewne go zamontuję, bo go posiadam. Po istotnych kalibracjach ze względu na kończące się próbki filamentu zakupione do starej drukarki, zakupiłem jednokilogramową szpulę filamentu. Parę dni później, gdy paczka do mnie dotarła, zacząłem drukować części, które zastąpią gorący klej. Były to głównie mocowania na łożyska, nowa karetka oraz nóżki. Zauważyłem dość sporą różnicę w jakości wydruków, co mnie jeszcze bardziej zmotywowało do dalszych ulepszeń. Po lewej spoiwo z kleju/Po prawej jego wydrukowany odpowiednik Na dzień dzisiejszy drukarka pracuje, postawiłem serwer druku na Raspberry Pi, nadal trwają nad nią prace, głównie konserwacyjne i drobne ulepszenia, lecz projekt uważam za zakończony. Bez problemu można drukować obudowy do projektów, ale też jakieś figurki. Obudowa do wzmacniacza gitarowego (nie będę opisywać, bo uważam go za zbyt niski poziom) Jak na powyższym zdjęciu widać, jedna szpula poszła na zepsute wydruki, wydruki kalibracyjne oraz jakieś zabawki. Dlatego warto zaopatrzyć się w 1kg filamentu jak buduje się tego typu drukarkę. W przyszłości mam zamiar zmienić malinkę prawdopodobnie na ESP8266. Zauważyłem też, że dzięki zbudowaniu takiego sprzętu nauczyłem się baardzo dużo w tym temacie. Morał z tego projektu jest taki: Staraj się nie robić gwintów w profilach aluminiowych - są mało wytrzymałe. jak kupujesz rurki aluminiowe na prowadnice w sklepie budowlanym to idź z suwmiarką, bo u mnie powodem luzów na karetce była zbyt mała średnica jednej z prowadnic. Nie kupuj najtańszej głowicy, bo jej jakość może być bardzo dyskusyjna. Gorący klej nie nadaje się do wszystkiego Warto robić projekty DIY Specjalne podziękowania kieruję do: Staszka, matika i wiele innych osób z discorda :3 Dziadka, który mi pomógł od strony planowania Leoneq'a, który mnie namówił, aby wstawić tu ten projekt ;3 Tak to wygląda na chwilę obecną Z góry przepraszam za ewentualne błędy językowe czy literówki, ale orłem z Polskiego nie jestem, więc proszę o wybaczenie. Naturalnie zapraszam do dyskusji w komentarzach pod postem. Pozdrawiam.
  15. 11 punktów
    No wreszcie - po jakimś szale na prezenty, naprawy różnych domowych urządzeń i inne przyziemne sprawy mogłem zabrać się za następnego z rodziny Konserwatorów Płaskich Powierzchni - czyli małego Kopłapowa. Miał on w założeniu służyć do wycierania podłogo w trudniej dostępnych miejscach (np. pod kabiną prysznicową) więc siłą rzeczy musiał byc jak najmniejszy. Założenia były proste: zasilanie 1 x 18650; dwa silniczki N20 do napędu z driverem DRV8825; z przodu pojedyncza gąbka kuchenna; wysokość taka, aby się zmieścił pod brodzikiem; z czujników: zderzak, żyroskop i kilka czujników odbiciowych; Arduino Pro Mini jako "mózg" urządzenia; żadnego skomplikowanego algorytmu - ma się przejechać po podłodze i tyle, z możliwością zdalnego sterowania. Z takimi założeniami zabrałem się do roboty. Sterownik już miałem - kiedyś zrobiłem sobie coś w rodzaju uniwersalnego nadajnika, sprawdził się już w trzech konstrukcjach a więc tę część miałem gotową. Tym razem postanowiłem w maksymalnym stopniu wykorzystać drukarkę. Ponieważ miałem felgi z kół Pololu (opony zostały użyte w innym projekcie) wystarczyło dodrukować jakieś ładne oponki z TPU. Również dolna płyta podwozia wraz z koszykiem na 18650 oraz mocowaniami na ładowarkę, przetwornicę i inne drobiazgi typu wyłącznik została wydrukowana w jednym kawałku. Zadowolony z siebie zmontowałem podwozie, podłączyłem prowizorycznie silniczki pod 5V... i w tym momencie szczęście się skończyło. Okazało się, że robot nawet po lekkim dociążeniu jest jeszcze za lekki i nie da rady przepchnąć gąbki nawet po śliskich kafelkach. Zmartwiony odstawiłem konstrukcję na skraj biurka i zająłem się swoimi sprawami. Na szczęście był to skraj biurka przy którym pracuję i co chwila chcąc nie chcąc spoglądałem na biednego robocika. Jak go wykorzystać... Pomysł przyszedł sam, gdy nastąpiłem bosą nogą na jakąś śrubkę. A gdyby tak wyposażyć go w magnes i kazać zbierać śrubki z podłogi? Wywaliłem uchwyt gąbki, w to miejsce zamontowałem obrotowe kółko (o nim więcej w dalszej części), uchwyt na magnesy i również podłączając bezpośrednio do przetwornicy silniczki puściłem go po podłodze. Okazało się, że śrubki i podobne niewielkie metalowe farfocle zbiera doskonale! Tak więc robocik zmienił swoje przeznaczenie, miałem już gotowe podwozie i mogłem zabrać się za dalsze projektowanie. Oczywiście - potrzebne były nowe założenia. Przede wszystkim - wysokość nie była już krytyczna (robot miał zbierać śrubki porozrzucane po podłodze i nie wjeżdżać do łazienki). Z uwagi na to zrezygnowałem z czujników odbiciowych, w ich miejsce postanowiłem zamontować obrotowy laserowy czujnik TOF o kącie 180°. Pozostał oczywiście żyroskop. Z uwagi na przykre doświadczenia z MPU6050 przy okazji zakupów w Botlandzie zamówiłem moduł L3G, czujnik VL53L0X kupiłem już wcześniej, tak więc zabrałem się za dalsze projektowanie. I tu mała dygresja: odrzuciłem MPU6050 z uwagi na to, że potrafił zawiesić Arduino po kilkudziesięciu sekundach od włączenia (a z tego co wyczytałem w sieci nie tylko ja miałem z tym problemy). Oczywiście: nie doczytałem, że dotyczy to wyłącznie odczytu danych z DMP, odczyt surowych danych z żyroskopu i akcelerometru był prawidłowy. Dopiero po zmontowniu całości przypadkiem natknąłem się na nową wersję biblioteki która (podobno) nie sprawia takich problemów... a szkoda, bo niepotrzebnie wydałem trzy dychy na nowy żyroskop Ale wróćmy do robocika. Ponieważ laser na serwie i tak musiał dość mocno wystawać nie było konieczności zachowania wysokości reszty konstrukcji. Postanowiłem zrobić więc coś podobnego jak w poprzednim robocie - podłoga ze spienionego PVC (idealna do eksperymentów z uwagi na łatwość obróbki), do niej mocowane serwo i płytka z elektroniką. Z tamtej konstrukcji skopiowałem również zawieszenie zderzaka i przekładnię do serwa obracającego laser. Płytka z elektroniką miała początkowo być wykonana na frezarce - niestety, wskutek pandemii zostałem odcięty od warsztatu kolegi i musiałem zadowolić się płytką uniwersalną. Przyszedł więc czas na najprzyjemniejszą część pracy programowanie. Na zdjęciu wyżej widać przytwierdzony do robota najnowszy model SMARDZ-a. Tym razem SMARDZ ma własne zasilanie (akumulatorek Li-Ion 1000 mAh, ładowarka i przetwornica) co uniezależnia go od akumulatorów robota i - co ważniejsze - przy większych wstrząsach (np. uderzenie w przeszkodę) nie ma możliwości, że zrobi sobie reset. Większych niespodzianek nie miałem z wyjątkiem jednej - ale za to bardzo śmiesznej... Otóż po zmontowaniu wszystkiego na płytce uniwersalnej jak zwykle przedzwoniłem wszystkie połączenia. Po stwierdzeniu że wszystko jest w porządku rozpocząłem testowanie. Wszystko działało - oprócz serwa. Zdjąłem płytkę, wyjąłem Arduino, sprawdziłem połączenia - wszystko było w porządku. Ki diabeł? Zacząłem szukać w programie czy coś mi nie blokuje timera - nie, najprostszy program ruszający serwem z przykładów też nie chciał działać. Co prawda serwo było sprawdzone (przed zamontowaniem musiałem ustawić środkowe położenie, a do tego używałem testera serw) - ale wiadomo, popsuć się mogło. Niestety - inny egzemplarz zachował się tak samo. Co ciekawsze - mały HD-1370A zaczął kręcić się w kółko... Nie bardzo mi się chciało podpinać sondę, ale jakoś chęć zbadania przyczyny owego dziwacznego działania przeważyła nad lenistwem. No i co się okazało? Otóż na nóżce 8 do której podłączone było serwo radośnie trwało 5V. Wtedy sobie przypomniałem, że płytkę Arduino wziąłem z pudełka gdzie leżą wszystkie podejrzane moduły (jako że miał wszystkie piny polutowane) - po prostu wyjście 8 było najprawdopodobniej uszkodzone i zwarte na stałe z Vcc Na szczęście połączenia robione Kynarem mają to do siebie że szybko można je zmodyfikować - podłączenie serwa do wolnego pinu obok pomogło! Ech, znowu się okazało, że elementy sprawne działają z reguły lepiej od uszkodzonych! I jeszcze drobiazg - w pewnym momencie jeden z silniczków uległ uszkodzeniu (mechanicznemu). Chciałem kupić dwa w Botlandzie na wypadek gdyby drugi też miał jakieś skłonności samobójcze - niestety, już nie było (tzn. był jeden ale trochę się bałem). Kupiłem więc podobne - działają chyba nawet lepiej. W sumie mam na płytce: Arduino Pro Mini cztery mikroswitche zderzaków (połączone parami, czyli wykrywane jako dwa oddzielne) podpięte do jednego pinu analogowego moduł radiowy nRF24L01 (zasilany z wyjścia VDD żyroskopu) żyroskop L3GD20H driver DRV8835 buzzer służący do wygrywania różnych krzepiących melodyjek związanych z wykonywaną funkcją wyjścia na silniki, serwo i diody WS2812 (wskaźnik wykonywanej funkcji oraz wskaźnik poziomu naładowania akumulatora). Wszystko zasilane z jednego napięcia 5V z przetwornicy MT3608, do pinu analogowego podpięte wejście przetwornicy (kontrola napięcia akumulatora). O dziwo działa bez żadnych dodatkowych kondensatorów z wyjątkiem jednego 100nF przy module radiowym i dwóch przy silnikach. W efekcie robot wygląda tak: Tak więc robot w tej chwili potrafi realizować następujące programy: Sterowanie zdalne (ot, wielki mi program). Jedyne co go różni od samochodzika wnuczka na bateryjkę to fakt, że używa żyroskopu do jazdy prosto (podobnie jak reszta programów). Wałęsak - Bradiaga - najprostszy z możliwych - przejeżdża kawałek i skręca sobie w losowym kierunku. Po spotkaniu z przeszkodą po prostu cofa i zakręca. Wałęsak - Moocher - taki włóczęga bardziej inteligentny. Używa lasera do stwierdzenia czy nie dojeżdża do przeszkody oraz do wyszukania najlepszej (w jego rozumieniu najdłuższej) trasy do dalszej jazdy po spotkaniu z przeszkodą lub gdy mu się zamami zmiana kierunku. Odplamiacz - jedzie sobie po spirali. W przypadku napotkania na przeszkodę wykonuje wcześniej zaplanowany skręt, poprzedzając lekkim cofnięciem jeśli sygnał pochodzi od zderzaków a nie lasera.. Przerywa pracę, gdy nie może skręcić (tzn. w czasie skrętu dostanie sygnał od zderzaków). Polowiec - obrabia prostokątny kawałek podłogi - przejeżdża kawałek, zawraca, znowu przejeżdża, zawraca... jakby orał pole. Również używa oprócz zderzaków lasera jako czujnika przeszkody. Ponieważ zawraca zawsze na zasadzie zastopowania jednego koła (wewnętrznego) przesuwa się nieco za każdym nawrotem. Podobnie jak Odplamiacz przerywa pracę, gdy nie może zawrócić. Patrol - robot stara się ustawić jak najbliżej ściany równolegle do niej, a następnie jeździ od ściany do ściany aż do momentu, kiedy nie może zawrócić. Kod jest w sumie bardzo prosty, jednak chciałbym zwrócić uwagę na dwie rzeczy: Używam funkcji printf do wyświetlania różnych informacji o tym, co robi robot. Ponieważ wszystkie funkcję dotyczące żyroskopu działają na liczbach float, musiałem zmusić Arduino do wyświetlania ich właśnie przez printf. Niestety - nie ma możliwości ustawienia tego dla pojedynczego szkicu, ale globalne ustawienie jest bardzo proste: otóż w katalogu, gdzie znajduje się plik platform.txt dla naszego Arduino (czyli w tym przypadku ARDUINO_HOME/hardware/arduino/avr) trzeba założyć nowy plik o nazwie platform.local.txt, a w nim umieścić skopiowaną z platform.txt linię rozpoczynającą się od ciągu "recipe.c.combine.pattern=" z jedną drobną modyfikacją: na końcu linii należy (po spacji) dodać: -Wl,-u,vfprintf -lprintf_flt W przypadku wersji 1.8.12 (a podejrzewam, że wielu innych) będzie to wyglądać tak: recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mmcu={build.mcu} {compiler.c.elf.extra_flags} -o {build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -l m -Wl,-u,vfprintf -lprintf_flt Druga sprawa to laser. Na potrzeby programu zmodyfikowałem nieco bibliotekę Pololu dodając możliwość nieblokującego odczytu danych. Mimo to czujnik zachowywał się dość dziwnie: czasami zwracał bardzo pięknie prawidłowe odległości, a czasami kompletnie wariował. Bliższe przyjrzenie się problemowi poskutkowało stwierdzeniem, że czujnik zwraca nieprawidłowe dane po wgraniu kolejnej wersji programu (ściślej po programowym resecie Arduino). Ponieważ w bibliotece zabrakło funkcji resetowania lasera postanowiłem wypróbować najprostszą możliwość - w funkcji setup przed init() wstawiłem następujący kod: lidar.writeReg(VL53L0X::SOFT_RESET_GO2_SOFT_RESET_N, 0); delay(100); lidar.writeReg(VL53L0X::SOFT_RESET_GO2_SOFT_RESET_N, 1); delay(100); Od tej pory laser przestał mieć fochy i grzecznie zwraca odczytane odległości. I jeszcze jedna uwaga dla kogoś, kto na tej podstawie chciałby zbudować własną wersję robota. Otóż funkcja "Patrol" w teorii działa, w praktyce jednak robot nie jest w stanie ustawić się dokładnie równolegle do ściany. Co najmniej w czasie pierwszego przejazdu powinno się dokonać korekty... niestety, o ile laserowy czujnik jest wystarczająco precyzyjny, o tyle brak enkoderów nie pozwala na pomiar przebytej odległości. Prawdopodobnie i tak dałoby się to zrobić oceniając mniej więcej prędkość robota, i dokonując korekty zanim robot dojedzie do ściany z przodu... ale prawdę mówiąc już mi się nie chciało Natomiast uważam zadanie za całkiem ciekawe i pozostawiam sobie na przyszłość - na razie muszę niestety przerwać pracę nad robocikiem i zająć się bardziej przyziemnymi sprawami Aha, obiecałem jeszcze o kółku. No więc początkowo chciałem wyposażyć robota w kulkę podporową. Bliższa analiza zawartości szuflady wykazała, że mam dwa rozmiary: mianowicie za dużą i za małą. Drukowanie kulki raczej nie wchodziło w grę, natomiast obrotowe kółko można wydrukować na dowolej taniej drukarce. Wygląda to tak: Oprócz trzech drukowanych elementów do zrobienia kółka potrzebne są: 1 x śrubka M3x8 1 x śrubka M3x16 2 x nakrętka M3 2 x łożysko kulkowe 3x10x4 Kółko mocowane jest dwiema śrubkami M2x10 do podwozia. Załączam plik OpenSCAD (gdyby ktoś chciał sobie takie kółko zmodyfikować do własnych potrzeb) oraz pliki STL (gdyby ktoś chciał tylko wydrukować bez modyfikacji). Kółko dopasowane jest wysokością do silników Pololu Micro (lub tańszych N20) mocowanych bezpośrednio pod dolną płytą podwozia oraz kół o średnicy 42mm. Łożyska trzeba wcisnąć we właściwe otwory (ja użyłem zwykłego małego imadełka), gdyby okazały się za luźne należy po prostu w OpenSCADzie zmniejszyć nieco ich średnicę. Nie załączam schematu ani programu sterownika - nie jest specjalnie udany, używam go przede wszystkim dlatego, że nie chce mi się robić innego. Lepiej zastosować np. bezprzewodowy gamepad (w sumie cenowo wyjdzie na jedno). No i na koniec filmik demonstrujący działanie robota - niestety nie we wszystkich programach (Moocher i Patrol wymagają więcej miejsca, a na dziś nie bardzo dysponuję takim które się nadaje do kamery). A - oczywiście winien jestem jeszcze wyjaśnienie, skąd takie dziwne imię Zbignaś. To po prostu skrót od Zbieracz Gwoździków, Nakrętek i Śrubek Pora na podsumowanie i wnioski. A więc: Robot powinien być okrągły - konstruktorzy Roomby nieprzypadkowo tak go zaprojektowali. Zderzak powinien obejmować cały obrys robota (nie tylko przód jak w Roombie) oraz całą wysokość (robot nie może wjechać pod mebel jeśli jest za mało miejsca). Nic nie może wystawać ponad zderzak Laser musi obejmować 360°, oś obrotu (niekoniecznie sam laser) powinna być w środku robota (jak to połączyć z poprzednim punktem?) Enkodery nie muszą być super dokładne kwadraturowe, wystarczą zwykłe niewielkiej rozdzielczości, ale powinny być. W załączniku: program robota, zmodyfikowana biblioteka do czujnika, pliki do kółka oraz (może się komuś przydadzą) opona i felga (STL i SCAD, do opony/felgi potrzebny openscad w wersji nightly).Zbignas.zip W razie pytań i pretensji jestem do dyspozycji. Gdyby coś z moich STL-i było potrzebne proszę o informację (tylko nie na priv, błagam).
  16. 11 punktów
    Jakoś tak przed dwoma miesiącami mój kochany synuś przy okazji wizyty w domu stwierdził, że jest mu niesłychanie potrzebny theremin i to szybko. Jako że oryginalne instrumenty są conieco przydrogie postanowiłem po konsultacji zrobić odpowiednik instrumentu samodzielnie. Początkowo myślałem, że mam czas do Gwiazdki - okazało się że zamiast dwóch miesięcy mam na zrobienie wszystkiego dwa tygodnie. W tej sytuacji nie było szans na jakąś bardziej skomplikowaną konstrukcję - postanowiłem jak zwykle wykorzystać w większości elementy które miałem w domu i postawić na czysto cyfrową wersję. Z uwagi na krótki termin musiałem pracować praktycznie bez planu, metodą "kolejnych przybliżeń", stąd trochę nietypowa kolejność prac. Jako "serce" instrumentu postanowiłem wykorzystać ESP32 (płytka DevKit miała zawiadywać konstruowanym właśnie robotem, który na razie został odłożony na półkę). DAC ze wzmacniaczem został na razie wyjęty z "Ciapka". Przede wszystkim musiałem sprawdzić, jaki dźwięk mogę uzyskać z tego zestawu. Po prowizorycznym podłączeniu okazało sie, że mój pecet na gnieździe USB ma ok. 4.3 V, a po podłączeniu ośmioomowego głośniczka próba wyemitowania jakiegokolwiek sensownego dźwięku kończy się brownoutem ESP. Cóż - lutownica w dłoń, znalazłem jakieś luźne gniazdko 5.5/2.5, porządny zasilaczyk 5V, diodę dla bezpieczeństwa... no i zagrało. Nawet całkiem nieźle. Teraz przyszła kolej na sensory. Wypróbowałem kilka różnych, począwszy od zwykłego zestawu dioda/fototranzystor, poprzez HC-SR04, laserowe TOF aż po czujniki odległości Sharpa. O ile lasery sprawdziłyby się pewnie bardzo dobrze - o tyle ESP ma poważne problemy z jednoczesnym generowaniem dźwięku i gadaniem po I2C (niestety, nie doszedłem do tego skąd się tak naprawdę biorą ale nie miałem czasu sprawdzać), pozostałem więc przy Sharpach. W tym momencie mogłem już założyć, że coś mi wyjdzie. Jeszcze nie bardzo wiedziałem co, ale ważne, aby wyszło - mogłem się więc zająć czymś, co szumnie nazwałem "projektowaniem". Przede wszystkim, po policzeniu nóżek w ESP32 oraz przejrzeniu zawartości szuflad doszedłem do wniosku, że instrument będzie miał: klawiaturę matrycową 4x4 (do czego miałaby służyć miałem wymyślić pisząc program) cztery potencjometry regulujące różne ciekawe rzeczy (jakie - to miałem rozstrzygnąć później) cztery dodatkowe klawisze (dwa do przełączania oktaw i po jednym do zakresu sensora PITCH i trybu DUAL) pięć diod LED sygnalizujących różne mądre rzeczy mały wyświetlacz OLED 128 x 64 Dodatkowo docelowo miałem wykorzystać inny przetwornik DAC, ale to już musiałem dodatkowo zamówić; ponieważ ten przetwornik już znałem i miałem go w radyjku internetowym postanowiłem, że zamówię go później (być może coś jeszcze będzie potrzebne), a w razie konieczności (np. skończą sie w magazynie w Botlandzie) jakoś przeżyję jakiś czas bez radyjka. Na szczęście nic to na tym etapie nie zmieniało, więc pozostałem na razie przy podłączonym moim przetworniko-wzmacniaczykiem od Ciapka i głośnikiem (chyba) od jakiegoś taniego gramofonu. Tak więc pod względem elektroniki całość przedstawiałaby się następująco: A więc Eagle, projekt, laminat, termotransfer... i tu zonk: moja nowiutka drukarka nie nadaje się do tych celów, a wysłużona Kyocera właśnie się wyprowadziła do nowego właściciela Nie ma problemu. Telefon do kumpla od frezarki, zrobisz mi... A tak, zrobi. Za dwa tygodnie bo akurat swoją frezarkę przerabia (co u niego jest normalne). Dlatego właśnie na zdjęciu widzimy płytkę uniwersalną. Wyprzedzę trochę bieg wydarzeń: co prawda sprawę zasilania rozwiązałem na samym końcu (chciałem koniecznie mieć akumulator ale gdyby mi nie starczyło czasu podłączyłbym zwykły zasilacz), ale jako że pokazuję urządzenie praktycznie przed ostatnim zamknięciem obudowy - pokażę również jak mam to zrobione: Ponieważ zarówno przetwornicę, jak i ładowarkę miałem nie było sensu wysilać się na jakieś poważniejsze rozwiązania. Jeśli ktoś mi podpowie jak to zrobić lepiej (najchętniej bez przełącznika zasilacz/akumulator) będę bardzo wdzięczny. Skoro sprawę kabelków miałem już rozwiązaną, przyszedł czas na zaprojektowanie jakiejś obudowy. Oczywiście mógłbym całą obudowę wydrukować, ale z uwagi na termin i na to, że pewnie będzie fafnaście poprawek postanowiłem zrobić to inaczej: dolna i górna płyta wycięte ze spienionego PCW 4mm,a wydrukowane tylko ramka i boki. Ponieważ obróbka PCW jest prosta i zajmuje niewiele czasu (w sumie kwestia przycięcia ostrym nożem) mogłem pozwolić sobie na wydrukowanie jedynie szkieletu, mocując doń obie płyty. Powiem szczerze że był to dobry pomysł; co prawda górna płyta wyszła "nieco" krzywo (tak to jest, jak się tnie i wierci w ręku), ale nie traciłem czasu na wielokrotne próby. Dzięki temu jedyne co mnie ograniczało to wielkość stołu mojej Anetki (ramka musiała być wydrukowana w całości). Co prawda ktoś może twierdzić że mógłbym wydrukować jakąś wersję finalną - ale na to naprawdę nie było już czasu (całość skończyłem na kilka godzin przed oddaniem maszynki w ręce użytkownika, w związku z tym nawet drukarka by się nie wyrobiła w czasie). Wyszło jak wyszło - wygląda to tak: Z przodu instrument nie wygląda za ciekawie, ale chciałem pozostawić dostęp do przycisków RESET i BOOT na płytce. I mała dygresja: program pisałem na komputerze z zainstalowanym Ubuntu 18.04, od paru dni robiłem ostatnie poprawki używając lapka z Debianem Stretch. Ta sama wersja Arduino IDE, ta sama wersja definicji ESP32. Na Ubuntu wymagane było wciśnięcie BOOT do zaprogramowania płytki - na Debianie nie trzeba. Ktoś wie może o co chodzi? Bo chciałbym, aby moje Ubuntu zachowywało sie tak samo I to by było na tyle jeśli chodzi o kabelki, śrubki i plastiki - warto sobie przypomnieć, że cały czas równolegle powstawała część najważniejsza, czyli PROGRAM. Ponieważ napisanie w ciągu dwóch tygodni od zera programu na płytkę, którą pierwszy raz trzymam w ręku i to z dziedziny, w której akurat mistrzem wcale nie jestem to bardzo ryzykowny pomysł - postanowiłem nie wygłupiać się i użyć sprawdzonych rozwiązań. Jako że grałem kiedyś na małym Moogu (Rouge) naturalne dla mnie było zasymulowanie właśnie analogowego syntezatora. Program symuluje działanie dwóch generatorów (VCO), z których jeden może być lekko odstrojony. Do wyboru są: sinus, prostokąt, piła oraz sześć dodatkowych fal składanych z 32 harmonicznych oraz szumu. Szum przepuszczany jest przez filtr o częstotliwości środkowej odpowiadającej wysokości dźwięku generatora A. Oba generatory mogą pracować z różnymi kształtami fal, dodatkowo zamiast filtrów VCF zastosowałem podwójne fale: fala pomocnicza miksowana jest z podstawową, a stosunek amplitudy obu fal regulowany jest albo poprzez sensor PITCH (najniższy dźwięk to fala podstawowa, najwyższy to pomocnicza, pośrednie wysokości to odpowiednio zmieszane obie fale) albo przez sensor VOLUME (wtedy do połowy odległości od sensora głosność wzrasta do 100%, w miarę dalszego zbliżania się następuje przejście z fali podstawowej na pomocniczą). Daje to dużo większe możliwości niż klasyczne filtry. Oczywiście - ten tryb (czyli Dual Mode) można wyłączyć - wtedy oba generatory pracują z falą podstawową. Generatory zrealizowane są poprzez przemiatanie z odpowiednim krokiem tablic fal. Każda z 4 tablic składa się z 4096 próbek float. Początkowo zastosowałem typ double do obliczeń - niestety okazało się, że ESP32 po prostu się nie wyrabia w czasie. Szkoda, bo różnica jest w niektórych przypadkach wyraźnie słyszalna; przy pewnych kształtach fal (szczególnie zawierających wysokie harmoniczne) przy odstrojeniu generatorów powstają artefakty, których nie było w wersji double (prawdopodobnie były, ale poniżej granicy słyszalności). Zakres instrumentu to 7 oktaw, przy czym sensor PITCH reguluje wysokość w zakresie max. dwóch oktaw, przełącznik OCTAVE UP/DOWN zmienia ton podstawowy. Dodatkowo przełącznik transpozycji pozwala na podniesienie skali od zera do 11 półtonów, a precyzer płynnie dostraja skalę o +/- jeden półton z rozdzielczością 5 centów. Najwięcej kłopotu sprawiły mi te nieszczęsne Sharpy. Generatory są skonstruowane tak, że wysokość dźwięku jest proporcjonalna do wartości sterującej (korzystam z wstępnie przeliczonych tablic dla interwału 5 centów, czyli praktycznie poza zakresem czułości ludzkiego ucha). Niestety - poziom napięcia na wyjściu czujnika jest proporcjonalny do odwrotności odległości (w pewnych granicach), do tego sygnał jest dość mocno zaszumiony. Okazało się jednak, że zastosowanie filtrów Kalmana poskutkowało praktycznie całkowitym usunięciem szumów, a 12-bitowe przetworniki wejściowe ESP32 pozwoliły mi uzyskać na wejściu wystarczającą rozdzielczość. Ponieważ zabawa z 32 harmonicznymi przy pomocy 16-klawiszowej klawiatury i zabawkowego OLED-a to absolutnie chybiony pomysł - do ustalania fal służy dość prosta aplikacja napisana w Pythonie. Aplikacja łączy się poprzez port Serial z instrumentem oraz uruchamia serwer HTTP na adresie localhosta. Działa bez problemu na Linuksie (Firefox, Chrome, Chromium), na Windows mogłem sprawdzić tylko Chrome i Edge. O dziwo - Edge poradził sobie prawie bez problemu (prawie robi wielką różnicę - okazało się że do odczytu wartości selecta musiałem użyć jQuery zamiat po prostu selectedIndex), natomiast Chrome nie potrafił nawet wyświetlić prawidłowo interfejsu... który wygląda mniej więcej tak: Oczywiście - konieczność zastosowania tej aplikacji nie oznacza konieczności ciągania za sobą komputera. Ponieważ użytkownik ma do dyspozycji 9 zestawów po 6 fal w każdym i może zapisać je w pamięci Flash urządzenia - powinno wystarczyć na koncert Minęło kilka dni... jako że w międzyczasie przyszedł z Botlandu DAC mogłem już zabrać Ciapkowy wzmacniaczyk. Ponieważ ta wersja nie posiada własnego wzmacniacza, a podłączenie jakiegoś prostego odsłuchu bywa konieczne - po prostu podłączyłem tam mały moduł wzmacniacza PAM8403 z potencjometrem (widać go na zdjęciu wnętrza urządzenia). W efekcie tylna ściana instrumentu wygląda tak: I to by było na tyle... A nie, wyjaśniam, że: Klawiatura służy do obsługi generatorów (przyciski A i B), zmiany transpozycji (przycisk C) i presetu/zestawu fal (przycisk D) LED-y sygnalizują tryb działania klawiatury (A, B, C i D) oraz włączenie stroju temperowanego Potencjometry regulują odstrojenie generatora B, balans generatorów, precyzyjne strojenie oraz czas portamento Wyświetlacz pokazuje: Fale generatora A (podstawowa 1, pomocnicza 2), tryb synchronizacji (LFO), fale generatora B (1 i 2), strój generatora B (Prima) Transpozycja (tonacja C, oktawa 2) tryb Double Mode (Vl - volume) Zakres sensora PITCH (1 oktawa) Numer presetu (Pg - zero) Numer zestawu fal (W - zero) Numer pasma głównego filtra dolnoprzepustowego (F - 8 ) A skąd nazwa InfraWave? Bo theremin (na falach eteru) produkcji Mooga nazywa się Etherwave, a mój jest a podczerwień Mam nadzieję że Moog nie opatentował jeszcze słowa Wave... I kilka słów o możliwej przyszłości. O ile powstanie następna wersja instrumentu (zależnie od zamówienia i widzimisię synka) należałoby poprawić kilka rzeczy. Przede wszystkim - trzeba by było zająć się generatorami. Może udałoby się zmusić je do pracy w arytmetyce double (potrzebne cztery mnożenia i trzy dodawania), a resztę (filtry, szumy itp.) robić na floatach. Prawdopodobnie jest to możliwe - ale na razie nie miałem czasu a eksperymenty. Ilość przeróżnych manipuladeł jest stanowczo za mała. Bezwzględnie konieczne są potencjometry do regulacji częstotliwości LFO, głośności ogólnej oraz dobroci głównego filtra szumów. Licząc potrzebne klawisze na razie wychodzi mi 22 (mam cztery) i 26 sztuk LED (mam pięć)... Warto by było pozbyć się pecetowej aplikacji - do tego potrzebny jest co najmniej enkoder obrotowy z przyciskiem i większy ekran (jakiś TFT, przynajmniej 320x240 albo i więcej). O ile czujnik Sharpa bardzo dobrze nadaje się na sensor VOLUME, o tyle sensor PITCH mógłby być nieco lepszy. Wymaga trochę eksperymentowania... Ogólnie jestem otwarty na propozycje - może ktoś ma jakieś lepsze pomysły Natomiast świetnie się sprawdza DAC od Adafruit, a więcej czasu pomogłoby mi w lepszym opanowaniu ESP32 (to on ma słuchać mnie, a nie ja jego!) Kody programów w załączniku: infrawave.zip. Nie jest potrzebna żadna dodatkowa biblioteka (drivery wyświetlacza i audio są zawarte w programie). Jak zwykle pozostaję do dyspozycji w razie pytań.
  17. 11 punktów
    Wyświetlacze stosowane w urządzeniach elektronicznych przeszły ogromną ewolucję. Można ją łatwo prześledzić chociażby na przykładzie telefonów komórkowych. Pierwsze modele miały monochromatyczne, często tekstowe wyświetlacze. W latach 90. ubiegłego wieku popularne były już wyświetlacze graficzne (oraz gra w węża). W kolejnych latach wyświetlacze monochromatyczne zostały prawie zupełnie wyparte przez modele z kolorową, aktywną matrycą, czyli popularne TFT. Spis treści: Sterowanie wyświetlaczem TFT - część 1 - wstęp, podstawowe informacje Sterowanie wyświetlaczem TFT - część 2 - analiza problemu Sterowanie wyświetlaczem TFT - część 3 - testy prędkości na STM32 Sterowanie wyświetlaczem TFT - część 4 - własny program Sterowanie wyświetlaczem TFT - część 5 - optymalizacja programu W przypadku urządzeń wbudowanych, wiele nowości dociera ze znacznym opóźnieniem. Podczas kursu Arduino wykorzystany został alfanumeryczny wyświetlacz 2x16 znaków, kursy STM32 F1 oraz STM32 F4 wykorzystywały graficzne, ale nadal monochromatyczne wyświetlacze (chociaż F4 o wiele nowocześniejszy OLED). Celem niniejszego artykułu jest pokazanie jak można we własnym projekcie wykorzystać kolorowy wyświetlacz TFT. Będzie to okazja do pokazania zarówno wad, jaki i zalet tego typu wyświetlaczy oraz podstawowych technik optymalizacji. Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac » Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay. Wybór wyświetlacza Jednym z dość istotnych powodów powolnego wzrostu zainteresowania wyświetlaczami TFT była ich dość wysoka cena (w szczególności w porównaniu ze starszymi modelami monochromatycznymi). Obecnie ceny wyświetlaczy TFT bardzo spadły i model o niewielkiej przekątnej można kupić za podobną cenę do starszych urządzeń. Jako przykład użyję wyświetlacza o przekątnej 1.8 cala i rozdzielczości 160 na 128 pikseli firmy WaveShare. Dokumentację wyświetlacza, użytego sterownika oraz przykładowe programy znajdziemy na stronie producenta: https://www.waveshare.com/wiki/1.8inch_LCD_Module Również z tej strony pochodzi zdjęcie modułu wyświetlacza: Jak widzimy na zdjęciu jest to kompletny moduł. Na stronie producenta znajdziemy zarówno instrukcję obsługi, jak i schemat, jednak jest on tak prosty, że raczej niezbyt interesujący. To na co powinniśmy zwrócić uwagę to opis wyprowadzeń: Kolejny ważny parametr to model kontrolera, czyli ST7735S oraz jego dokumentacja. Wszystkie wspomniane dokumenty warto oczywiście przeczytać. Ale jeśli nie mamy akurat czasu na czytanie nieco ponad 200 stron, powinniśmy chociaż pamiętać gdzie szukać informacji. Podłączenie wyświetlacza Czas wybrać mikrokontroler i podłączyć do niego wyświetlacz. Przykłady dostarczone przez WaveShare są przeznaczone dla Arduino UNO, STM32F103, Raspberry Pi oraz Jetson Nano. Sensowność podłączania tak małego wyświetlacza do potężnego komputera jakim jest Raspberry Pi (o Jetson Nano nawet nie wspominając) jest mocno dyskusyjna więc ograniczę się do Arduino oraz STM32. Na początek Arduino UNO, bo to chyba najlepiej znana wszystkim platforma. Oczywiście wiele osób pewnie stwierdzi, że układ atmega328 jest o wiele za słaby na sterowanie kolorowych wyświetlaczem, ale skoro producent dostarczył gotowe przykłady warto chociaż spróbować. Sam interfejs jest opisywany jako SPI, ale szybkie spojrzenie na listę wyprowadzeń może nieco zaskoczyć. Po pierwsze używane są nieco inne nazwy, po drugie komunikacja jest jednokierunkowa (można tylko wysyłać dane do wyświetlacza), a po trzecie wreszcie jest sporo linii, które nie są obecne w standardowym interfejsie SPI. Musimy również zadbać o zasilanie układu z napięcia 3.3V oraz konwersję napięć sterujących - Arduino UNO używa sygnałów o napięciu 5V, co może uszkodzić wyświetlacz TFT. Do podłączenia użyłem modułu opartego o układ 74LVC245, można to zrobić taniej, lepiej itd. ale akurat miałem taki moduł pod ręką. Krótki opis wyprowadzeń wyświetlacza: 3V3, GND - zasilanie DIN - linia danych, podłączamy do MOSI interfejsu SPI CLK - zegar interfejsu SPI CS - odpowiada linii CS interfejsu SPI DC - informuje o rodzaju przesyłanych danych, stan niski oznacza komendę sterującą, a wysoki dane RST - stan niski resetuje sterownik wyświetlacza BL - sterowanie podświetlaniem Podłączenie do Arduino UNO jest dość proste, linie interfejsu SPI, czyli DIN i CLK należy podłączyć do pinów zapewniających dostęp do sprzętowego modułu SPI, pozostałe linie są sterowane programowo (chociaż BL można podłączyć do wyjścia PWM, aby uzyskać sterowanie jasnością podświetlenia). W programie przykładowym użyte wyprowadzenia są zdefiniowane w pliku o nazwie DEV_config.h, powinniśmy więc ustawić je odpowiednio do wybranego sposobu podłączenia. U mnie ten kod wygląda następująco: //GPIO config //LCD #define LCD_CS 7 #define LCD_CS_0 digitalWrite(LCD_CS, LOW) #define LCD_CS_1 digitalWrite(LCD_CS, HIGH) #define LCD_RST 5 #define LCD_RST_0 digitalWrite(LCD_RST, LOW) #define LCD_RST_1 digitalWrite(LCD_RST, HIGH) #define LCD_DC 6 #define LCD_DC_0 digitalWrite(LCD_DC, LOW) #define LCD_DC_1 digitalWrite(LCD_DC, HIGH) #define LCD_BL 4 #define LCD_BL_0 digitalWrite(LCD_DC, LOW) #define LCD_BL_1 digitalWrite(LCD_DC, HIGH) #define SPI_Write_Byte(__DATA) SPI.transfer(__DATA) Pierwsze uruchomienie Czas skompilować i uruchomić program przykładowy. Po drobnych poprawkach oraz ustawieniu wybranych pinów powinno udać się program skompilować. Warto zwrócić uwagę na ilość użytej pamięci: Jak widzimy wykorzystane zostało raptem 9348 bajtów pamięci Flash (28%) oraz 453 bajtów pamięci RAM (22%). To bardzo mało i jak później się przekonamy to jeden z powodów "niedoskonałości" tego rozwiązania. Ale na razie czas zaprogramować Arduino i podłączyć zasilanie: Dobra wiadomość jest taka że działa - i to w wysokiej rozdzielczości (160x128) oraz w kolorze... Zła jest taka, że może "niezbyt szybko" działa. Zanim stwierdzimy, że wyświetlacz do niczego się nie nadaje, warto nieco dokładniej przyjrzeć się przyczynom takich, a nie innych osiągów. Dzięki temu może uda się działanie programu nieco poprawić. Czas rysowania zawartości ekranu Pomiary "na oko" to niezbyt doskonała metoda, nieco lepiej dodać wywołanie millis() przed rozpoczęciem i po zakończeniu rysowania ekranu. Różnica między zwróconymi czasami pozwoli nam oszacować jak szybko (albo wolno) działa pierwszy program. Przy okazji możemy jeszcze sprawdzić ile zajmuje skasowanie zawartości ekranu. Nowy program w pętli rysuje i kasuje zawartość ekranu: Wyniki pomiarów to ok. 1240 ms dla rysowania oraz 96 ms dla kasowania zawartości. "Not great, not terrible" chciałoby się powiedzieć... Prosta animacja Wyświetlanie ekranu demonstracyjnego jest oczywiście interesujące, ale może warto sprawdzić jak ekran zachowa się w nieco bardziej pasjonującym zastosowaniu. Zacznijmy od odbijającej się piłeczki, taki wstęp do napisania gry w "ponga". Pierwsze podejście jest mocno uproszczone - w pętli głównej kasujemy zawartość ekranu, obliczamy pozycję piłki i rysujemy: Jak widzimy tempo gry jest raczej spokojne, a miganie irytujące. Warto jeszcze przetestować ile czasu zajmuje naszemu programowi rysowanie: Wyszło trochę ponad 100ms, to nieco więcej niż czas samego kasowania ekranu, więc jak łatwo się domyślić właśnie ta czynność zajmuje najwięcej czasu. Optymalizacja Skoro już wiemy, że najwięcej czasu zajmuje kasowanie ekranu, to może zamiast kasować wszystko warto usuwać jedynie poprzednią pozycję "piłki" i rysować nową. Taki program działa już znacznie lepiej: Porównajmy jeszcze czasy rysowania: Jak widzimy skasowanie i narysowanie piłeczki zajmuje o wiele mniej czasu. Nieco jednak uprzedzając dalsze części, spróbujmy jeszcze zamiast okrągłej piłki użyć kwadratowej. Może nie brzmi to zachęcająco, ale efekt robi wrażenie: Podsumowanie To co zobaczyliśmy to pierwsze możliwości optymalizacji. Nawet jeśli odrysowanie całego ekranu zajmuje mnóstwo czasu, możemy uzyskać o wiele lepsze efekty zmieniając sposób rysowania. To jedna z metod optymalizacji - nie jedyna i w kolejnej części postaram się opisać dlaczego rysowanie działa tak wolno i o ile możemy poprawić wydajność. Spis treści: Sterowanie wyświetlaczem TFT - część 1 - wstęp, podstawowe informacje Sterowanie wyświetlaczem TFT - część 2 - analiza problemu Sterowanie wyświetlaczem TFT - część 3 - testy prędkości na STM32 Sterowanie wyświetlaczem TFT - część 4 - własny program Sterowanie wyświetlaczem TFT - część 5 - optymalizacja programu
  18. 11 punktów
    Już słyszę głosy: O, staremu ethanakowi coś się chyba pokręciło... Post jest o jakimś Kedrigernie w dziale DIY - a na zdjęciu mamy coś przypominającego robota z dumnym napisem "Ciapek"... Spieszę z wyjaśnieniami. To nie pomyłka. Post jest na temat serwera mowy Kedrigern, a Ciapek to żaden robot. Po prostu dość trudno zrobić zdjęcie programu, poza tym wypadałoby raczej pokazać ów program w działaniu - a ten wymaga jednak czegoś co będzie gadać (czyli jakiejś bardziej fikuśnej obudowy na głośnik). A ponieważ ostatnio zapatrzyłem się w rysunki Daniela Mroza... cóż, Ciapek z ludzkimi dłońmi, stopami i uszkami wyszedł tak jak wyszedł Zacznę możę od opisu elektroniki (jako że jest to najprostsze, a użytkownik może sobie ją skomponować z zupełnie innych elementów). Sercem całego układu jest Raspberry Pi. Można zastosować dowolny model (chociaż ze starymi, krótkimi GPIO mogą być lekkie problemy), ja użyłem w swoim egzemplarzu Raspberry Pi Zero W. Oprócz tego potzebny jest jakikolwiek układ odtwarzania dźwięku. "Duże" (pełnpowymiarowe) malinki jak popularny 3B+ mają już wyprowadzone wyjście audio, potrzebny jest tylko jakiś niewielki wzmacniacz. Dla wersji Zero potrzebny jest jednak układ zewnętrzny. Prawdopodobnie doskonale spisałby się opisywany ostatnio moduł z wyjściem audio do Raspberry Pi Zero, ja zastosowałem jednak moduł i2s. Jest on dość wygodny w użyciu jako że zawiera w sobie wzmacniacz mono o całkiem sporej (do 3 W) mocy, poza tym początkujący elektronicy nie muszą się martwić o jakieś dziwne masy audio, filtrowane zasilania i tym podobne dziwactwa interesujące tylko "analogowców" - moduł podłącza się pięcioma przewodami do malinki, z drugiej strony dwoma do głośnika i już gra Ponieważ nasz "robocik" musi potrafić poruszać ustami, zastosowałem najprostsze (i najprawdopodobniej najtańsze) rozwiązanie - czyli matrycę LED 8x8 ze sterownikiem, na której rysowane będą kształty ust. Od razu uprzedzę pytanie: owszem, próbowałem zrobić bardziej skomplikowany mechanizm używający serw. Niestety - oprócz trudności mechanicznych (te są do przezwyciężenia) natrafiłem na rzecz, której nie da się przeskoczyć: prędkość serwa. Typowe serwo potrzebuje 0.1 sekundy na przekręcenie orczyka o 60° - a nawet zakładając, że owe 60° wystarczy (w co osobiście wątpię), jest to co najmniej dwa razy za wolno (przy czym owe "dwa" mogłoby się w rzeczywistych układach rozrosnąć do trzech czy czterech). Będę jeszcze próbować rozwiązania z solenoidami - jeśli mi się uda to opublikuję wyniki. Ale może w międzyczasie ktoś inny napisze moduł "solenoid"? Zresztą - chciałem, aby każdy mógł sobie w domu wypróbować Kedrigerna ponosząc jak najmniejsze koszty, a opisywany układ można (mając RPi z wyjściem audio) zmontować kosztem klikunastu złotych (matryca) bez żadnych płytek - po prostu łącząc matrycę przewodami z GPIO malinki. Jako głośnika użyłem leżącego gdzieś w szufladzie zakurzonego głośniczka od starego telefonu z sekretarką, pasować jednak będzie dowolny pod warunkiem dopasowania mocy głośnika do posiadanego wzmacniacza. I to cała wielce skomplikowana elektronika. Jak widać na zdjęciu - nie ma tam nic skomplikowanego. Przejdę więc do opisu programu. Kilka lat temu udało mi się zmusić Mbrolę do w miarę prawidłowego gadania po polsku (do tego stopnia, że można ją było wykorzystać np. do tworzenia audiobooków). System TTS Milena (tak się nazywa ten "zmuszacz" do Mbroli - czyli bardziej fachowo NLP) bardzo dobrze sprawdził się na pecetowym Linuksie, wersja na Windows była raczej ciekawostką ale również działała - postanowiłem więc przystosować ją do malinki. Po przezwyciężeniu pewnych trudności z kompilacją (np. "char" dla architerktury Intel to w GCC domyślnie signed, w ARM z jakichś przyczyn unsigned) okazało się, że co prawda Milena działa, ale "rozruch" ma straszliwie powolny. Nic dziwnego - pliki tekstowe słowników wymowy i translacji fonetycznej muszą być kompilowane przy załadowaniu programu, a malinka ze swoją wolniutką kartą pamięci i nieszczególnie silnym procesorkiem potrzebuje zbyt dużo czasu, zanim wydobędzie z siebie jakieś zdanie. Postanowiłem więc zrobić inaczej: serwer wczytuje wszystkie pliki raz przy starcie systemu, a prosty program klienta przekazuje mu tylko treść komunikatów. Takie rozwiązanie ma również inne zalety: uruchomiony na sockecie TCP serwer może być na zupełnie innej fizycznej maszynie niż klient. I w ten sposób powstał program Kedrigern (nazwany na cześć pewnego czarodzieja, który postanowił odczarować księżniczkę z zaklęcia odbierającego głos). Jak mi to wyszło - oceńcie sami. Oto filmik ukazujący Kedrigerna w działaniu: Nie będę tu rozpisywał się o wszystkich zasadach działania i możliwościach Kedrigerna i Mileny (to w końcu ma byc post na forum a nie książka z dokumentacją), zacznę więc od instalacji Kedrigerna na malince. Wszystkie konieczne komponenty (z wyjątkiem głosu pl1) są w załączonym pliku tgz. Rozpakujmy go w dowolnym katalogu (np. w głównym katalogu użytkownika malinki) i instalujemy mbrolę wraz z polskim głosem: sudo dpkg -i mbrola3.0.1h_armhf.deb sudo apt install mbrola-pl1 Teraz możemy zainstalować Milenę. I tu uwaga: jeśli ktoś miał starszą wersję Mileny niż 0.2.92 musi ją przeinstalować na tę właśnie wersję - inaczej nie będzie działać moduł ruchu ust Kedrigerna! sudo dpkg -i milena*.deb Po zainstalowaniu wszystkiego powinno działać już polecenie milena_say, czyli musimy wypróbować: milena_say dzień dobry kolego I znów uwaga: jeśli wyjściem audio jest HDMI, polecenie może nie działać prawidłowo! Należy spróbować dodać parametr -d opóżniający generację mowy do czasu "załapania" HDMI, czyli najprościej: milena_say -d 2000 dzień dobry kolego Niestety, przy użyciu wyjścia HDMI mogą pojawić się problemy z późniejszym działaniem Kedrigerna, ale po pierwsze nie jest to miejsce na omawianie problemów z audio, po drugie wcale nie czuję się mistrzem w tym zakresie i prawdopodobnie ktoś tu wie lepiej ode mnie jak tym problemom zaradzić. W każdym razie mając uruchomiona Milenę i Mbrolę możemy przystąpić do instalacji Kedrigerna. Zaczynamy od instalacji serwera, czyli sudo dpkg -i kedrigern_0.2.0-1_armhf.deb Jeśli mamy podłąćzoną matrycę LED (8x8, MAX7219) możemy użyć jej jako wyświetlacz ust: sudo dpkg -i kedrigern-matrix_0.2.0-1_armhf.deb No i oczywiście coś co pozwoli nam korzystać z serwera, czyli: sudo dpkg -i libkedrigern_0.1.2-1_armhf.deb Teraz możemy sprawdzić, co potrafi nasz serwer: kedrigern -h lub (jeśli mamy zainstalowany moduł matrix) kedrigern -M matrix -h W odpowiedzi dostaniemy wykaz opcji, z którymi możemy uruchomić serwer. Aby je przetestować, należy otworzyć drugi terminal; w pierwszym uruchamiamy serwer poleceniem "kedrigern" z różnymi opcjami, w drugim testujemy poleceniem kdr-say. Po ustaleniu opcji należy zedytować plik /etc/default/kedrigern i w nim ustawić domyślne parametry. Po przetestowaniu poleceniem kedrigern -C /etc/default/kedrigern możemy już uruchomić nasz serwer w tle: sudo systemctl start kedrigern Jeśli chcemy, aby serwer startował od razu przy starcie systemu, należy wydać polecenie: sudo systemctl enable kedrigern Do komunikacji z serwerem służą polecenia kdr-say, kdr-stop i kdr-speaking. Moduł matrix pozwala na wyświetlanie ust zsynchronizowane z głosem syntezatora. Oto przykładowe obrazy ust dla różnych fonemów: Fonem A Fonem I Fonem O Fonem U Fonemy M, P i B Wybrałem do pokazania kilka najbardziej charakterystycznych kształtów. Jeśli komuś nie odpowiadają stworzone przeze mnie kształty może w prosty sposób dorobić własne lub poprawić moje na bazie pliku /usr/share/kedrigern/demo.shape i podłączyć go do Kedrigerna, np. za pomocą opcji "-m matrix:shape" lub wprowadzając odpowiednie zmiany w pliku konfiguracyjnym. Protokół komunikacyjny jest bardzo prosty. Nie wnikając w szczegóły - załączony moduł w Pythonie (działa w wersji 2 i 3 Pythona) pozwala na sterowanie serwerem, a jednocześnie stanowi przykład sposobu komunikacji. I to wszystko... A nie, nie wszystko. Bo zaraz ktoś powie że to tylko zabawka, że komu potrzebne gadające roboty... Przede wszystkim: Kedrigern może generować komunikaty diagnostyczne w czasie testowania/programowania robota. Jakie to ma znacze nie nie muszę chyba mówić nikomu, kto choć raz ustawiał np. regulatory silników czy zakres ruchu serw w warunkach polowych. Poza robotyką może być bardzo dobrym rozwiązaniem do urządzeń typu headless - ja np. stosuję podobne (poprzednika Kedrigerna) rozwiązanie do obsługi sterownika pieca CO (podanie np. godzin nieobecności w mieszkaniu) czy jako wygodnego interfejsu do wpisywania wyników pomiaru ciśnienia krwi i poziomu cukru z małej przenośnej klawiaturki. A to już nie są zabawki A w ogóle przypominam, że Roomba też gada (tyle że Ciapek ładniej) Zdaję sobie sprawę z tego, że opis jest bardzo pobieżny. Z chęcią odpowiem na wszystkie pytania - o ile kogoś to będzie interesować... W każdym razie wypróbowanie Kedrigerna nawet bez modułu ust posiadacza RPi z wyjściem audio nic nie kosztuje, a może się przyda? Kody źródłowe Mileny i Kedrigerna są dostępne na stronie http://milena.polip.com A, i ostatnie wyjaśnienie: Ciapek to mały troll, wychowanek czarodzieja Kedrigerna w książce Johna Morressy'ego "Głos dla księżniczki". Nawet trochę podobny Przy okazji: @Treker, czemu pliki zip są cacy a tgz są be? kedrigern.zip pykedrigern.zip
  19. 11 punktów
    Witam serdecznie Pragnę zaprezentować mój zdalnie sterowany pojazd o wdzięcznej nazwie Przebiegły Tyran Podstępności Konstrukcja powstawała przez 5 miesięcy. Zbudowana jest głównie ze stali i aluminium. Pojazd waży 24 kg i ma 60 cm długości. Prędkość maksymalna to około 15-20 km/h. Konstrukcja nie posiada skrętnej osi, skręcanie odbywa się jak w czołgu Każde koło jest napędzane własnym silnikiem z przekładnią z chińskiej wkrętarki. Każdy silnik pobiera bodajże 26A maksymalnie i działa na 12V. Za zasilanie odpowiadają dwa żelowe akumulatory 12V po 10Ah każdy, a także 8 litowo-jonowych akumulatorów 3,7V - 2200 mAh. Silniki są sterowane z Arduino Pro Mini przez mostki zbudowane z tranzystorów mosfet. Na pokładzie znajduje się także drugie Arduino gdyż zabrakło mi pinów na wszystkie podzespoły Komunikacje z trzecim Arduino będącym pilotem zapewniają moduły radiowe HC-11 433MHz. Oświetlenie przednie zapewniają 2 LEDY 1-watowe, 2 LEDY 3-watowe i 2 halogeny po 35W. Tylne oświetlenie to cztery 1-watowe czerwone LEDY. Na dachu znajduję się odsuwana klapa zasłaniająca wyrzutnie rakiet. Otwiera się dzięki gwintowanemu prętowi zamocowanemu na osi silnika i nakrętce przytwierdzonej do ruchomej części. Wyrzutnia rakiet zmienia kąt strzału dzięki serwu. Mieści 6 pocisków. Odpalanie działa tak że każda rakieta ma wokół lontu owinięty cienki drucik, dwa końce drucika są połączone z akumulatorem poprzez przekaźnik. Gdy przełącze przekaźnik, prąd przepala drucik i następuje zapłon. Każda rakieta ma swój własny przekaźnik więc mogą być odpalane niezależnie.
  20. 10 punktów
    Jakiś czas temu zakupiłem sobie ESP32 CAM, niestety nie umiałem dla niej znaleźć jakiegoś sensownego zastosowania. Przeleżała z pół roku a może i więcej, aż wpadłem na pomysł zrobienia foto-pułapki. I tak oto powstała: Po mojej posiadłości często biegają dzikie zwierzęta takie jak: sarny, bażanty, dziki i zające. Te ostatnie to raczej szkodniki ale lecimy z tematem dalej. Założenia: Zapis zdjęć na karcie SD Wysyłka zdjęć na FTP Wysyłka zdjęć na maila jakiś czujnik temperatury praca możliwie jak najdłużej z jednej baterii wspomaganej panelem PV Po ogarnięciu softu na biurku podłączeniu czujnika PIR wszystko ładnie działało. Za zasilanie odpowiada jedno ogniwo 18650, przetwornica podnosząca napięcie do 5V i mały panel PV 6V 167mA. Jak widać powyżej kamera jest przylepiona klejem dwuskładnikowym, tak by uniknąć uszkodzenia tasiemki. Wszystko zostało umieszczone w obudowie po NanoStation Loco M5. Która została dostosowana do zamontowania panelu PV, czujnika PIR oraz kamery. Poniżej etap pasowania elementów. Został również wydrukowany daszek oraz uchwyty dla szyby która osłania kamerę od deszczu. Obudowa Została dodatkowo pomalowana na czarno - ale chyba będę jej robić jakieś malowanie taktyczne, lub pójdzie w ruch “termoglut” i trzcina żeby się lepiej wtapiała w otoczenie. Pierwsze wyjście w teren i klapa, wszystkie zdjęcia były przejaśnione. Po kilku próbach okazało się że kamera potrzebuje 2s! aby dostosować czas ekspozycji, (lekka tragedia bo przy zajączkach to już go może dawno nie być w kadrze) oczywiście w warsztacie wszystko działało jak należy. Następnym nietrafionym pomysłem okazało się wysyłanie zdjęć na maila, trwa to stosunkowo długo a co za tym idzie zużycie energii jest większe, co doprowadziło do rozładowania baterii po 2 dniach. Konieczne było zrezygnowanie z wysyłki zdjęć na maila. W tej chwili kamera działa bez ładowania już 5 dni. Przykładowe zdjęcia z kamery poniżej: Trapi mnie jeszcze jeden problem mianowicie jeśli na zdjęciu jest więcej szczegółów np: cały kadr trzciny lub trawy, to obraz jest obcinany tak około 100-200px z dołu. Nie jest to chyba problem buforu w ESP bo przy kompresji ustawionej w sofcie na 10 zdjęcia zajmują 384KB jeśli zwiększę kompresje zdjęcia zajmują mniej a obraz i tak jest obcinany. Oprócz zdjęć wyzwalanych czujnikiem ruchu, procesor budzi się co 30 min wykonuje zdjęcie i wysyła je na FTP. To aby mieć pewność że bateria nie uległa rozładowaniu. A i jest jeszcze nieszczęsny czujnik temperatury DS18B20, nie było łatwo go tam upchać bo okazało się że wszystkie piny na płytce są wykorzystywane i jedyny wolny pin który mogę wykorzystać to pin serial RX, co niesie za sobą konieczność wypięcia czujnika w razie chęci przeprogramowania układu. Lista wykorzystanych elementów: ESP32-CAM AI-Thinker Przetwornica step-up 5V wraz z modułem ładowania ogniw 18650 Koszyk na ogniwo 18650 Czujnik PIR Mini panel PV 6V 167mA Antena 2.4 Ghz Podsumowując, działa aczkolwiek widać pewne ograniczenia tego układu chociażby czas jaki kamera potrzebuje na uruchomienie się. Z ciekawostek do ESP32 została podłączona zewnętrzna antena, gdzie przetestowany zasięg to około 200 m :), ale pewnie to też zasługa tego że łącze się do AP który mam wystawiony na dworze. Kodu programu pozwolę sobie w tej chwili nie udostępnić bo mam tam niezły bałagan, a jeszcze staram się uporać z obcinaniem fotek, za jakiś czas na pewno go zamieszczę.
  21. 10 punktów
    Stacja meteorologiczna służy do przeprowadza dokładnych pomiarów pogody oraz sprawdzania jakości powietrza. Urządzenie pobiera dane z czujników, następnie zapisuje je do bazy danych po czym zostają wyświetlone na stronie internetowej. Całe urządzenie zostało zamknięte w obudowie wydrukowanej w drukarce 3D. Czujniki zainstalowane w urządzeniu pobierają dokładne dane pogodowe. Stacja posiada zaawansowaną metodę pomiaru prędkości wiatru przy użyciu ultradźwiękowych czujników ruchu. Stacja działa na Raspberry PI 3+, obsługuje również starsze modele (z wbudowanym wifi) oraz na Raspberry PI ZERO (W). System operacyjny to Linux wersja Raspbian STRETCH LITE bez interfejsu graficznego. Kod źródłowy czujników został napisany w Python’ie. Dane z czujników zapisywane są przy użyciu Raspberry PI do bazy danych MySQL. Następnie zostają wyświetlone w aplikacji internetowej, która napisana została w PHP. Urządzenie wymaga połączenia z Internetem. Aktualnie wykorzystywane jest połączenie poprzez WIFI. Komunikacja pomiędzy urządzeniem a administratorem przeprowadzana jest poprzez protokół SSH i FTP. Stacja jest zbudowana w taki sposób, żeby użytkownik mógł w łatwy sposób ją obsługiwać. Aby włączyć stację należy podłączyć ją do prądu. Działanie urządzenia zostanie zasygnalizowane świeceniem diody (czerwonej) oraz miganiem diody zielonej, która świeci przy wysyłaniu danych do bazy. Oprócz graficznego przedstawienia danych aplikacja posiada skrypty do obliczenia m. in. wschodu i zachodu słońca w danej lokalizacji. Oprogramowania posiada opcje, w których m. in. możemy ustawić czas pomiaru pogody i zapisu do bazy danych. Jest to ważne ponieważ możemy sami ustalać jak często stacja ma sprawdzać stan pogody Projekt obudowy Obudowa została zaprojektowana w programie FreeCAD. Składa się ona z 9 elementów. Została wydrukowana w drukarce 3D – Anet A8 (moja własna drukarka). Materiał wykorzystany podczas druku to PLA, temperatura druku 205°C. Łączny czas druku wynosi 19 godzin, zużywa 174 gram materiału przy wysokości warstwy 0.2mm. Projekt obudowy został wykonany w taki sposób, aby urządzenie było odporne na deszcz i wiatr. Opływowość stacji pozwala na wykonywania dokładnych pomiarów prędkości wiatru. Na samej górze stacji zamontowany został czujnik opadów deszczu oraz czujnik natężenia światła. Następnie pod nimi umieszczone są ultradźwiękowe czujniki prędkości wiatru. Kolejny element to obudowa chroniąca RB PI i elektronikę. Obudowa posiada specjalne mocowanie na RP PI, które sztywno trzyma urządzenie. Następnym elementem jest rdzeń, do którego przymocowane są pozostałe czujniki. Obudowę zamyka podstawka, w której znajduję się główny przewód zasilający oraz diody sygnalizujące działanie. Czujniki Urządzenie w czasie rzeczywistym pobiera dane z 7 czujników, następnie są one w odpowiedni sposób przekazywane do modułu detektorów i mikrokontrolerów, które zwracają dane do Raspberry PI. Lista czujników: Czujnik opadów Czujnik pomiaru opadów atmosferycznych składa się z dwóch części: sondy pomiarowej „YL-83” oraz modułu detektora „LM393”, który posiada wyjście analogowe umożliwiające pomiar deszczu. Moduł zasilany jest napięciem 5V. Czujnik natężenia światła Czujnik światła bazuje na fotorezystorze „GL5537-1”. Jest to opornik fotoelektryczny, który zmienia swoją rezystancję pod wpływem padającego światła. Prędkość wiatru Pomiar prędkości wiatru bazuje na ultradźwiękowym czujniku odległości „HC-SR04”. Ultradźwiękowy pomiar prędkości polega na zmierzeniu różnicy czasu przejścia impulsów ultradźwiękowych propagujących w kierunku przeciwnym do kierunku przepływu. Temperatura i wilgotność Do wykonywania pomiaru temperatury i wilgotności powietrza został wykorzystany popularny moduł „DHT11”. Moduł składa się z czujnika oraz niezbędnego do poprawnego działania układu: rezystora i kondensatora filtrującego napięcie zasilania. Ciśnienie Moduł z cyfrowym barometrem „BMP180” wykonuje pomiar ciśnienia w zakresie od 200hPa do 1100hPa. Układ komunikuje się przy użyciu interfejsu IC2, co zapewnia wysoką dokładność i stabilność wykonywanych pomiarów. Jakoś powietrza Moduł jakości powietrza „MQ-135” wykrywa w atmosferze: benzen, amoniak (NH3) oraz dwutlenek węgla (CO2). Inne: Przetwornik A/C i C/A 8-bitowy I2C Głównym układem przetwarzania danych w tej pracy jest przetwornik PCF8591. Moduł posiada czterokanałowy przetwornik analogowo-cyfrowy działający w oparciu o 8-bitowy systemem akwizycji danych. Komunikacja opiera się na szeregowej wysyłce danych za pomocą dwukierunkowej magistrali I2C.
  22. 10 punktów
    Mam zaszczyt przedstawić: Roko Kopłapow - czyli Robot Koncepcyjny, Konserwator Płaskich Powierzchni. Co mniej więcej ma oznaczać: mopopodobny twór samojezdny, którego zadaniem jest sprawdzenie wszelkich koncepcji przed zaprojektowaniem i skonstruowaniem prototypu robota do czyszczenia podłogi na mokro. Niestety - nie wszystko poszło po mojej myśli. Niektóre koncepcje okazały się absolutnie nietrafione, inne wymagają dopracowania i ponownego sprawdzenia. Sam robot jednak doskonale się sprawdził pokazując mi, w którą stronę mają iść dalsze prace. Jakie były założenia: robot ma służyć do przetarcia podłogi na mokro; ma być sterowany pojedynczym Arduino Pro Mini; miło by było aby realizował wszystkie funkcje, ale równie dobrze może pracować jako "inteligentne podwozie ze szczotkami", czyli jako nośnik różnej maści przystawek; Robot powinien umieć poruszać się po podłodze bez jej zmywania (czyli podnieść mechanizm szczotek choćby w celu przejechania przez próg); Robot powinien umieć znaleźć stację dokującą lub miejsce parkingowe. Co się nie sprawdziło: Podnoszone szczotki Założenie całkiem fajne, ale zbyt duża siła jest potrzebna do podniesienia całego mechanizmu. W dodatku podniesiony mechanizm zajmuje zbyt dużo miejsca. Teoretycznie dało by się to obejść ale robot musiałby być dużo większy, a tego nie chciałem. Podwozie gąsienicowe O ile na normalnym podłożu zachowywało się bez zarzutu - o tyle na mokrej, śliskiej podłodze to absolutna porażka, gąsienice po prostu nie łapią przyczepności. Podwozie Pololu (testowo z pojedynczą nieruchomą gąbką) w ogóle nie chciało skręcać, jeśli napędzana była tylko jedna gąsienica jechał sobie dalej prosto, przy napędzanych dwóch przeciwbieżnie robił jakieś dziwaczne ewolucje nie mające nic wspólnego ze skręcaniem. Podwozie Tamiya (maksymalna długość gąsienic, szerokość zwiększona do 15 cm) - niewiele lepiej. Co prawda przy podniesionych szczotkach dało się tym manewrować, ale jako że podnoszone szczotki też nie zdały egzaminu - zrezygnowałem z gąsienic i zrobiłem kołowe. Żyroskop Teoretycznie wszystko było w porządku, robot bardzo ładnie jechał prawie po prostej mimo wirujących szczotek które rzucały nim na boki, skręcał dokładnie o tyle ile chciałem... przez pierwsze 30 sekund. Tyle czasu udało mi się utrzymać mojego MPU6050 przy życiu. Niestety - po bardziej wnikliwych poszukiwaniach okazało się, że nie tylko ja mam takie problemy, niektóre egzemplarze działają bezbłędnie, inne się wieszają (zawieszając przy okazji Arduino). Tak więc na razie robot obywa się bez żyroskopu, chociaż w przyszłości na pewno się na niego zdecyduję (może taki? Poradzicie?). Stacja dokująca W związku z brakiem podnoszonych szczotek musiałem z niej zrezygnować - robot nie przejedzie przez próg, a stacja dokująca powinna być w innym pomieszczeniu. Szkoda... Na razie zamiast dokowania robot powinien wjechać w wyznaczony kąt pomieszczenia i się wyłączyć, ale do tego muszę wymyśleć jakiś inteligentny wyłącznik (to już w oddzielnym wątku). Wąska wiązka czujnika laserowego Chciałem przy "rozglądaniu się" robota ograniczyć szerokość matrycy. Niestety - tu już nie pozwoliło mi na to oprogramowanie. Mamy do dyspozycji dwie biblioteki do czujnika VL53L1X: jedną uproszczoną (która nie pozwala na ustawienie regionu) i drugą pełną (adaptacja ST, pozwala na wszystko tyle że zajmuje 20 kB, jak na małe Arduinko to nieco za wiele). Być może któregoś pięknego dnia uda mi się dopisać tę możliwość do tej mniejszej biblioteki, ale na razie niespecjalnie mam na to czas, a z szerokością wiązki 27° muszę nauczyć się żyć... Inna możliwość to postawienie drugiego procesorka tylko do obsługi lasera, mógłbym wtedy zmienić serwo na mały silnik krokowy (nawet taki mi w szufladzie leży), tylko czy jest sens? A co się sprawdziło: Przede wszystkim - napęd szczotek. Obie szczotki to po prostu kuchenne gąbki włożone w uchwyty, napędzane są pojedynczym silnikiem z dwustronnym wałem. Szczotki są obrócone wobec siebie o kąt 90°, aby zmniejszyć szerokość robota i pozbyć się martwego pola pomiędzy szczotkami, obracają się przeciwbieżnie. Gąbki można w każdej chwili wyjąć i wymienić na czyste, w dodatku mogą być włożone zarówno miękką, jak i szorstką stroną do podłogi. Druga rzecz bez której dalsza praca nie miałaby sensu to przedni zderzak. Musi być bardzo lekki, znajdować się dość nisko nad podłogą (progi) a jednocześnie mieć wysokość wystarczającą, aby robot nie usiłował wleźć pod jakąś kuchenną czy łazienkową szafkę. Jednoczęściowy zderzak zapewnia wykrycie przeszkody w promieniu 180°, jest na tyle lekki że nie mam nawet żadnych sprężyn - cztery krańcówki wystarczają. Krańcówki są połączone po dwie równolegle z każdej strony, zwierają przez rezystor do masy co umożliwia bezproblemowy odczyt zderzaków przez pojedyncze wejście analogowe Arduino. Z drobiazgów: materiał. Oprócz elementów drukowanych z PLA mam tu: płytę główną podwozia z 3mm PCW. Łatwe w obróbce, w miarę elastyczne i wystarczająco wytrzymałe. podłogę piętra ze spienionego PCW 4mm. Nie musi wytrzymywać dużych obciążeń, jest bardzo lekkie i możliwe do cięcia zwykłym ostrym nożem. koszyki na akumulatory wydrukowane z PET-G z integralną sprężyną. Początkowo obawiałem się że nie będą kontaktować - okazało się, że sprawują się dużo lepiej niż kupowane podwójne (już nie mówię o porażce pod tytułem "koszyk na jeden akumulator"), a przy okazji mam tu porządny przewód (ucięty od pecetowego zasilacza) a nie jakiś chiński włosek. Dla zainteresowanych podaję link na thingiverse. A z rozwiązań: Enkodery na kołach. No - powiedzmy częściowo, trochę za mała rozdzielczość ale działają. Do bardziej precyzyjnych rzeczy pewnie by się nie nadały, ale tu zdają egzamin. Ponieważ nie wyszedł mi napęd gąsienicowy, zacząłem szukać jakichś fajnych kółek. Kiedyś znalazłem na Allegro za jakieś śmieszne pieniądze silniczki z kątową przekładnią (odpowiedniki Pololu), dokupiłem do tego koła Pololu 42x19, zmontowałem jakieś prowizoryczne podwozie... i na tym się skończyło bo jakoś straciłem zainteresowanie projektem. Czyli silniki z kołami już miałem. W pierwszej wersji robot miał się orientować w przestrzeni za pomocą żyroskopu i laserowego czujnika odległości, ale z braku żyroskopu zostałem skazany na enkodery. Co prawda oficjalnie te silniki nie miały możliwości zamontowania enkoderów, ale na szczęście w to nie uwierzyłem Postanowiłem umieścić enkodery wewnątrz kół. Co prawda miejsca jest dość mało, musiałem wydrukować nowe felgi, ale jakoś cała konstrukcja się zmieściła. Użyłem popularnego TCRT5000L (zawsze mi kilka w szufladzie leży), dokleiłem uchwyty do silników... i ruszyło! Co prawda enkodery czasami fałszują, ale uczciwa bramka Schmitta powinna im w przyszłości pomóc. Na razie podłączenie wygląda tak: Dla zainteresowanych - zdjęcia i pliki STL/SCAD. Czujnik odległości 360° Niedawno ktoś pytał o coś takiego - o ile pamiętam chodziło o ultradźwiękowy czujnik odległości o zakresie ruchu 360°. Ponieważ moje rozwiązanie działa całkiem nieźle (należałoby tylko maksymalnie zmniejszyć luzy, ale to już zależy od możliwości drukarki) mam tu prostą przekładnię, zakładaną bezpośrednio na serwo i mocowaną tymi samymi śrubami co serwo, z tarczą pozwalającą na zamocowanie czujnika (w moim przypadku laser, ale może to być równie dobrze czujnik ultradźwiękowy). Dwie wersje: większa i kompaktowa (jeśli nie starcza miejsca). Jako osi użyłem śruby z podwozia Tamiya oryginalnie służącej do mocowania kół jezdnych z uwagi na fagment bez gwintu, ale w ostateczności można spróbować ze zwykłą śrubą M3. Tym razem nie ma STL-i jako że każdy ma inne potrzeby, zamiast tego plik dla OpenSCAD-a. Potrzebne będą biblioteki: spur_generator oraz parametric_involute_gear_v5.0. Co do programu: Program jest dość prosty, nie ma sensu publikowanie bo pewnie jutro jak mi się coś przyśni to będzie inny (możliwe że lepszy, ale niekoniecznie). Zresztą tak jak wspominałem - to jest egzemplarz koncepcyjny, wystarczy mi stwierdzenie że "da się to zrobić". Mój SMARDZ niesamowicie ułatwia programowanie, musiałem go tylko trochę inaczej zamocować (dodatkowy uchwyt i przedłużacz) bo przy gwałtowniejszych manewrach zsuwał się z pinów - prawdopodobnie bez czegoś takiego rzuciłbym to po paru godzinach. Robot ma cztery tryby pracy: Zdalne sterowanie - wiadomo o co chodzi. Zrobiłem kiedyś takiego uniwersalnego radiopilota, to już czwarte urządzenie które nim steruję; Jazda losowa - taki typowy wszędołaz, potrafi omijać przeszkody, stara się nie jechać prosto za długo aby się poszwendać w ciekawszych miejscach; Plama - analogicznie jak w Roombach, wyciera podłogę w promieniu do ok. 70 cm od miejsca startu i zatrzymuje się po skończeniu pracy; Sprzątanie - tu program nie jest dopracowany, ale w wersji koncepcyjnej nie ma to większego sensu. Ogólnie robot powinien podjechać do najbliższej ściany (to potrafi), ustawić się do niej równolegle (to też potrafi) i krążyć po pomieszczeniu coraz bliżej środka (tu ma problemy związane z niedokładnością enkoderów). Tak wygląda robot w trybie "plama": Ktoś za chwilę powie: zaraz, przecież to robot do sprzątania na mokro, a gdzie woda? Na razie nie ma. Po prostu: ponieważ nie ma stacji dokującej, przed uruchomieniem robota należałoby ręcznie uzupełnić wodę w zbiorniku. Dużo wygodniejsze jest po prostu spryskanie wodą podłogi w pomieszczeniu przed uruchomieniem robota. A czemu "na razie"? Bo jak wspomniałem na początku, ten robot powinien mieć możliwość współpracy z przystawkami, a taką przystawką może być np. urządzenie do spryskiwania płynem do mycia paneli. Ale taka przystawka powinna mieć swój procesor, robot w tym momencie powinien przestawić się w tryb "inteligentnego podwozia", a to wszystko jest kwestią przyszłości Na razie robot spełnił swoje zadanie, popracuję jeszcze trochę nad programem (dopóki się da), i zaczynam zbierać kasę na wersję finalną Obiecane pliki STL i SCAD w załączniku:koplapow.zip Jak zwykle jestem gotów odpowiedzieć na pytania - choć tym razem chyba ich nie będzie...
  23. 10 punktów
    Kolejna ciekawostka - mało widowiskowa, ale dla mnie bardzo ważna! Po 11 miesiącach udało się uzyskać 2 poniższe dokumenty od Urzędu Patentowego RP. Oznaczają one, że od tego roku logo FORBOT oraz słowo FORBOT są zastrzeżonymi znakami towarowymi (m.in. w kontekście produktów związanych z nauką elektroniki i programowania). W praktyce chroni to FORBOTa przed wieloma nieprzyjemnymi sytuacjami. Od teraz mogę też zgodnie z prawem dodawać obok logo to słynne R w kółeczku FORBOT®
  24. 10 punktów
    Witam wszystkich, od mojego ostatniego postu tutaj minęło sporo czasu ale wcale nie porzuciłem robotyki. Jak wszyscy wiemy życie po studiach zaczyna zjadać coraz więcej czasu. Prawie 4 lata temu wrzuciłem tutaj post z moją konstrukcją robota typu delta (Delta Robot). Mam wrażenie, że bardzo fajnie się przyjął i tamta konstrukcja (jak wspominałem 4 lata temu) była prototypem, na którym zaczynałem się uczyć. Cztery lata rozwoju nie tylko mnie ale też dostępnej technologii jak np. druk 3D i mocniejsze mikrokontrolery niż poczciwa Atmega pozwoliły mi rozwinąć skrzydła. Ale przechodząc do meritum, przedstawiam moją następną wersję robota typu delta: Robot składa się w tym momencie z: ramienia, taśmociągu, systemu wizyjnego. systemu generującego podciśnienie 1.Mechanika Do zrobienia tego robota wykorzystałem tyle części z poprzedniej konstrukcji ile się dało. Ale ze względu na postęp techniki i moje większe możliwości finansowe większość przeprojektowałem w SolidWorksie i wydrukowałem na własnej drukarce 3D. Ramiona zamontowane są na podwójnie łożyskowanym wale, który napędzany jest poprzez pasek zębaty, a ten z kolei przez silnik krokowy z zamontowanym 12bitowym enkoderem. Taśmociąg także sam zrobiłem z profilu aluminiowego z Allegro oraz silnika DC z przekładnią. Pas kupiłem z profesjonalnej firmy na zamówienie. Może to brzmi groźnie i drogo ale tak nie jest. Pas kosztował 110 zł brutto. robot posiada 4 osie, dokładnie tak jak poprzednia konstrukcja. 2. Elektronika Najważniejszym układem scalonym jest mikrokontroler TEENSY 3.6 (link) zajmuje się: sterowaniem silnikami krokowymi, obsługą enkoderów silników jak i taśmociągu, komunikacją z komputerem, zapisem programów, punktów oraz wszelkich ustawień na karcie SD Jest to kontroler kompatybilny z bibliotekami Arduino i szczerze dla całego projektu zbawienne było to, że miałem gotowe biblioteki dla wielu rzeczy i nie musiałem się uczyć tego procka wraz z wszystkimi rejestrami, algorytmami zapisu na kartę SD, protokołu SPI oraz obsługi wielu peryferii jak sterowniki silników krokowych (o tym za chwilę) oraz np. ekranu LCD. Mogłem się skupić na moim celu czyli aplikacji, która ma spełniać moje założenia. Dodatkowo w kontrolerze, a także w ramieniu znajdują się: Teensy 3.2 - obsługa ESTOP, IO (wejść/wyjść), obsługa LCD oraz pomost w komunikacji pomiędzy głównym prockiem, a Arduino w ramieniu, Arduino Nano - obsługa PID taśmociągu, sterowanie serwochwytakiem ( kontroler Pololu Maestro), sterowanie pompą podciśnienia oraz elektrozaworem, Arduino Nano - komunikacja z komputerem poprzez zTCP/IP Silniki wyposażone są w enkodery absolutne AMS AS5045, które dostałem za darmo. Robot wyposażony jest w 4 wejścia oraz 4 wyjścia 24V (standard przemysłowy). W celu testowania czy wszystko dobrze działa zrobiłem dodatkowo prosty panel z 4 diodami oraz 4 przyciskami do testowania czy wszystko dobrze działa. Silniki sterowane są poprzez sterownik silników krokowych AMIS-30543 (link), który pozwala na konfiguracje poprzez magistralę SPI, a także na sterowanie z mikrokrokiem x32, które to sterowanie tutaj wykorzystuję. Dodatkowo jak widać na zdjęciach zaprojektowałem oraz zmontowałem (po dostaniu od Satlandu) płytki, które pozwoliły wszystko spiąć ze sobą. Nie będę wrzucał schematu PCB, bo nie jest to nic interesującego. 3. System wizyjny Robot skalibrowany został z systemem wizyjnym OpenMV (link). Kamera została zaprogramowa w języku Python i jej zadaniem jest w zadanym czasie (komunikat wysłany po uart) zrobić zdjecie i zliczyć bloby o odpowiedniej wielkości. Kamera wurzyca po porcie uart dane do mikrokontrolera głównego w postaci NUMER/X/Y/KĄT/ już we współrzędnych robota. Po dostaniu danych do tablicy punktu dodawana jest aktualna pozycja taśmociągu. Dzięki temu robot jest w stanie trafić w detal podczas ruchu taśmy. 4. System sterowania Całość oparta jest na matematyce, mikrokontroler oblicza zadanie proste oraz odwrotne kinematyki (dla pozycji oraz prędkości). W przeciwieństwie do starej konstrukcji układ sterowania naprawdę bierze pod uwagę pozycję oraz prędkość, dzięki temu robot porusza się bardzo płynnie oraz może zachować określoną prędkość liniową punktu TCP (Tool Central Point). Algorytmy pozwalając na poruszanie się w trybach: JOINT - ruch obliczany jest tak, aby każda oś zakończyła pracę w tym samym czasie, LINEAR - ruch lionowy punktu TCP z określoną prędkością liniową, TOOL - ruch liniowy ale zgodny z układem współrzędnych narzędzia CONV - tryb ruchu liniowego z załączonym śledzeniem taśmy, Cały program posiada w tym momencie jakieś 6 tys linijek kodu i pozwala na pracę w trybie automatycznym jak i ręcznym robota. Całość jest napisana w języku C/C++. 5.Program na PC Program napisany w C# w środowisku VisualStudio. Pozwala na: załączenie silników (przekaźnik odcinający na linii 24V), Zwolnienie napędów (enable na sterowniku krokowców) ułatwia ręczne uczenie punktów, Resetowanie błędów, Sterowanie robotem w trybie ręcznym, Uczenie punktów, Edycję ręczną zapisanym punktów na robocie, ustawienie układu TOOL oraz pozycji domowej robota, pisanie prostych programów w skryptowym języku podobnym do BASICA (jestem w trakcie prac) uruchamianie programów w trybie automatycznym, deklarowanie konkretnych działań pod wejścia oraz wyjścia np. cykl start na wejściu 1 podgląd pozycji robota, podgląd IO robota, sterowanie taśmociągiem, zapisywanie oraz sczytywanie ustawień robota oraz punktów z/do pliku na PC po połączeniu z robotem automatyczne sczytanie ustawień oraz punktów z karty SD w kontrolerze. 6.Filmiki Wiem, że to tylko krótki post na temat tego robota i w temacie dla zainteresowanych jest znacznie więcej do opowiedzenia dlatego jak ktoś ma jakieś pytania to zapraszam do komentarzy oraz wiadomości
  25. 10 punktów
    Jakiś czas temu w moje ręce trafił dość specyficzny zabytek techniki - układ MCY7880, będący jedynym mikroprocesorem produkowanym seryjnie w Polsce. Element ten był klonem intelowskiego procesora 8080, wytwarzanym przez nieistniejące już przedsiębiorstwo CEMI. Początkowo potraktowałem go jako kolejną elektroniczną ciekawostkę do kolekcji, po jakimś czasie zacząłem się jednak zastanawiać, czy nie będę w stanie wykorzystać go w bardziej konstruktywny sposób. Zacząłem więc gromadzić pozostałe elementy potrzebne do zbudowania prostego systemu mikroprocesorowego, jednocześnie wczytując się w dokumentację i literaturę komputerową z epoki. Właściwa konstrukcja zaczęła powstawać niewiele później. Z uwagi na mocno eksperymentalny charakter przedsięwzięcia zdecydowałem się pominąć etap projektowania PCB i od razu przystąpić do montażu komputera na płytce prototypowej. Najpierw wlutowane zostały podstawki pod układy scalone, potem grubszą srebrzanką poprowadziłem masę i linie zasilające. Należy tutaj nadmienić, że MCY7880 jest dość kłopotliwym procesorem, jeśli chodzi o zasilanie. Nie tylko pobór prądu jest duży jak na obecne standardy, ale także konieczne jest dotarczenie trzech różnych napięć: +12, +5 oraz -5V. Dodatkowo muszą być one podane w odpowiedniej kolejności, niedopełnienie tego obowiązku grozi uszkodzeniem procesora. Oryginalnie systemy mikroprocesorowe na MCY7880 były zasilane z dużych zasilaczy transformatorowych. Była to pierwsza z kilku kwestii, co do których zdecydowałem się na drobny kompromis i zastosowałem nieco uwspółcześnione podejście. I tak napięcie 12V jest generowane przez przetwornicę boost na MC34063A, a -5V jest pobierane z pompy ICL7660. Głowna linia zasilająca o napięciu 5V jest zasilana bezpośrednio ze współczesnego, stabilizowanego zasilacza impulsowego. Po poprowadzeniu masy i zasilania, a także wlutowaniu wszystkich elementów pasywnych, przyszedł czas na najbardziej mozolny etap projektu. Łączenie linii sygnałowych przy pomocy kynaru. Bardzo dużej ilości kynaru. Zajęło mi to kilka wieczorów. O dziwo pomyliłem się tylko raz, zapominając o podciągnięciu jednego z wyprowadzeń EPROM-u do 5V. Po przebadaniu magistrali oscyloskopem i analizatorem stanów logicznych stwierdziłem, że procesor zachowuje się prawidłowo pracując "na luzie" (szyna danych pociągnięta w sposób wymuszający ciągłe wykonywanie instrukcji NOP i zwiększanie licznika instrukcji). Przyszedł więc czas na zaprogramowanie pamięci EPROM. Na potrzeby tego projektu zaopatrzyłem się w chiński programator oraz urządzenie do kasowania tych zabytkowych pamięci. Zapoznałem się także z podstawami asemblera 8080. Pierwszy napisany program służył rzecz jasna do migania diodą podłączoną do znajdującego się na płytce układu 8255. Potem zabrałem się za portowanie TinyBASIC-a, który po jakimś czasie udało mi się odpalić na tym komputerze. Obecnie POLON 7880 może komunikować się ze światem jedynie przez port szeregowy RS232, zrealizowany za pomocą układu 8251 oraz konwertera MAX232. W planach na bliżej nieokreśloną przyszłość jest budowa dodatkowej płytki z interfejsem monitora CRT i klawiatury, a być może także i sterownikiem stacji dyskietek. Pozwoliłoby mi to na uruchomienie systemu operacyjnego CP/M - organizacja pamięci komputera jest do tego przystosowana. Oczywiście najprostszym rozwiązaniem byłoby symulowanie układów I/O za pomocą jakiegoś współczesnego mikrokontrolera, wolałbym jednak wykorzystać w tym celu oryginalne układy scalone z epoki.
  26. 10 punktów
    Cześć, chciałbym przedstawić Wam mojego robota Celem pracy było wykonanie zdalnie sterowanego robota dobrze radzącego sobie w terenie, który wysyła obraz i dane z czujników do operatora. Budowa: Pierwszy etap budowy to projekt CAD w programie Autodesk Inventor 2015. Zawieszenie to uproszczona wersja systemu jezdnego rocker - bogie. (Link do wiki z zasadą działania wikipedia ) Zawieszenie: Praca zawieszenia: Silniki to Pololu 37Dx57L mm z przełożeniem 100:1, do tego adaptery na hex 12mm, i koła z Wild thumpera. Na maszcie znajduje się dedykowany moduł kamery do Raspberry Pi, wraz z reflektorami + dwa serwa Tower Pro do sterowania ruchem masztu. Oprócz tego z boku jest mała skrzyneczka w której znajduje się buzzer oraz czujnik wilgotności i temperatury DHT22: Całość projektu wygląda następująco, z tyłu widać zamontowaną antenę: Konstrukcja została wykonana tak jak przewidywał projekt, oprócz tego robot został oklejony folią moro, co dodało mu powagi ;D Praca zawieszenia: Elektronika: - Raspberry Pi - główny komputer sterujący, - Moduł rozszerzeń podłączany do portów GPIO (zawiera przetwornik ADC MCP3008, zegar RTC, cyfrowy kompas HMC588L i układ Darlingtona ULN2803A) - Silnikami sterują elektroniczne regulatory prędkości używane w samochodach RC, - Generator PWM Adafruit - generuje sygnał do serwomechanizmów i ESC, - Nano router TP-Link TL-WR703N do zapewnienia łączności WiFi, został lekko zmodyfikowany - przylutowałem złącze RPSMA do podłączenia zewnętrznej anteny. - Akumulatory to pakiety ogniw 18650, zostały stworzone dwa - jeden 2S do zasilana elektroniki, drugi 3S do zasilania serwomechanizmów i silników. Półka elektroniki: Pozostałe elementy: Oprogramowanie: Aplikacja sterująca na PC wykorzystuje bibliotekę QT, i SFML (obsługa pada Xbox), na robocie całość została napisana w Pythonie Okno wygląda następująco, jak widać znajdują się tam wszystkie odczyty z czujników, sterowanie światłami, buzzerem, oraz przycisk uruchamiający kamerę: Strumieniowanie video: Aby zapewnić jak najmniejsze opóźnienie i obraz HD został użyty Gstreammer. Starałem się wszystko opisać w dużym skrócie, jak macie jakieś pytania to piszcie
  27. 10 punktów
    The way I see it, if you're gonna build a line follower, why not do it with some style? W ten oto wyjątkowy dzień OCT 21 2015, chciałbym zaprezentować swoją najnowszą konstrukcję, na początek jednak please excuse the crudity of this model. I didn't have time to build it to scale or paint it - a tak na poważnie brak czasu i masa obowiązków a zostało trochę rzeczy do dopieszczenia m.in wydruki 3d. Tak więc dokumentacja, porządne zdjęcia, i filmy pokazujące pełne możliwości tej konstrukcji zostaną opublikowane w późniejszym terminie - a robot na bank pojawi się na Robotic Arenie we Wrocławiu (możliwe że gdzieś wcześniej). ELEKTRONIKA Projekt składa się z czterech płytek PCB zaprojektowanych w CadSoft EAGLE. Płyta główna - grubość 1mm, pokrycie HASL bezołowiowy (plated gold), grubość miedzi 35um. Sercem robota jest 32 bitowy PIC32MX270F512H, do jego dyspozycji jest również osobny 1mb pamięci NVSRAM z podtrzymaniem bateryjnym Microchip 23LCV1024 (np. zapamiętanie trasy w trakcie zmiany głównej baterii). Napięcie 5.9V zapewnia przetwornica ST1S10PHR, natomiast za 3.3V odpowiada Microchip MCP1826S. Do sterowania silnikami - Toshiba 6612FNG. Na płytce znajdują się również trzy rejestry przesuwne NXP 74HC595 do sterowania efektami świetlnymi. 3 przyciski w tym dwa maleństwa do obsługi tablicy. Możliwość odbioru IR przez Vishay TSOP34836. P-MOSFET IRLML6401 do ochrony wejścia przed odwrotną polaryzacją. Większość drobnicy w obudowach 0603 Płytka czujników - grubość 0.8mm, pokrycie HASL bezołowiowy (plated gold), grubość miedzi 35um. KTIR0711S oraz miejsce pod SHARP GP2Y0D340K. Płytka enkodera i płytka silnika - grubość 0.8mm, pokrycie HASL bezołowiowy (plated gold), grubość miedzi 35um. Płytka przeznaczona do podłączenia enkoderów AS5040 - z prawie lustrzanym odbiciem z obu stron w celu obsługi dwóch kół robota z wykorzystaniem jednego wykonania PCB dla obydwóch stron. Razem z płytką silników imituje "kominy" filmowego De Loreana. FLUX CAPACITOR - 12 białych diod LED (wlutowanych do góry padami) odpowiada za efekt pracy kondensatora strumienia. RADIATION METER - dzielnik rezystorowy + ADC -> pomarańczowa dioda 0603 zaczyna migać w momencie spadku napięcia baterii. TIME CIRCUITS - tablica z niezależnym podświetleniem każdej daty - dwoma przyciskami ustawiamy na niej przed jazdą tryb w jakim ma robot pracować. NEONY - 3 wytrawione na głównej płytce + cztery 3mm diody do podświetlenia rurek wychodzących od płyty głównej do płytki enkoderów. OUTATIME - element obowiązkowy MR FUSION - na spodzie - bateria, góra skrywa w sobie malutki włącznik. ŚWIATŁA niezależne sterowanie światłami: przednimi (osobno wewnętrzne osobno zewnętrzne) oraz tylnymi (stopy, migacze, wsteczny). LICZNIK - when this baby hits 88cm/s you gona see some serious shit - wskazuje prędkość, przy 88cm/s odpalają się neony. MECHANIKA CDN... __________ Komentarz dodany przez: Treker Ale kolega punktów w regulaminie działu złamał... Ciężko wyliczyć wszystkie... Jednak w związku z oryginalnością konstrukcji poprawiłem niezbędne minimum i opublikowałem
  28. 9 punktów
    Witam! To mój pierwszy wpis w dziale DIY. Projektem jest (a właściwie dopiero będzie) mini konsolka do gier na STM32F1. Robię ten projekt dla mojego 3-letniego synka. Docelowo będę mu wgrywać na nią różne napisane przeze mnie gry, ale na początek zacznę od klasyki, czyli gra w węża Robiłem już podobny projekt przy okazji kursu SMT32 na Forbocie, więc szybko powinienem napisać niezbędny kod. Tym razem ma to być gotowe urządzenie które bez problemu będzie mógł obsłużyć 3-latek. Założenia projektu: 1. Mikrokontroler STM32F1 2. Ekran TFT kolorowy 240x320 3. Zasilanie bateryjne LiPo z ładowaniem przez gniazdo USB (więcej szczegółów w moim wątku w dziale Zasilanie - szczególnie ostatni mój post) 4. Obudowa w całości drukowana w 3D 5. Żadnych gotowych modułów. Własny projekt PCB i własny montaż. 6. Klawiatura: Krzyżyk, przycisk A, przycisk B oraz przycisk POWER, jak w starych Game - Boy'ach 7. Dzwięk: Nad tym jeszcze nie myślałem, brak I2S oraz DACa na mojej płytce Nucleo trochę utrudnia sprawę. Może będzie coś na Timerach i PWM. Zobaczymy. Teraz po kolei. Pierwsze co musiałem zrobić to ogarnąć wyświetlanie na TFT. Zakupiłem trochę w ciemno kilka wyświetlaczy 2,8" na ILI9341. Mój brak doświadczenia z TFT natychmiast się zemścił. Po odbiorze przesyłki okazało się że obsługa SPI wcale nie jest oczywista i jestem skazany na 16-bitową magistralę. Nie znalazłem nigdzie driverów na STM32 do sterowania tym kontrolerem przy takim połączeniu, ale znalazłem kilka projektów na GitHub'ie gdzie było sterowanie przez magistralę 8-bitową. Postanowiłem więc na podstawie tych projektów napisać własne drivery i procedury wyświetlania podstawowych kształtów. W trakcie prac nad optymalizacją wyświetlania okazało się że jednak 16-bitowa magistrala to doskonały pomysł i jest 4-krotnie szybsza od 8-bitowej. Dlaczego? Już tłumaczę: Gdy używa się 8-bitowej szyny danych to wysłanie piksela wygląda następująco (już po ustawieniu adresu): - Ustawiamy pierwsze 8 bitów koloru - WR strobe - czyli szybka zmiana linii WR na 0 i powrót 1 - Ustawiamy kolejne 8 bitów koloru - WR strobe - czyli szybka zmiana linii WR na 0 i powrót 1 I powtarzamy do czasu wypełnienia zaadresowanego okienka. Czyli na każdy piksel przypadają 4 kroki. Gdy używamy 16-bitowej magistrali - wygląda to następująco: - Ustawiamy 16 bitów koloru - WR strobe - czyli szybka zmiana linii WR na 0 i powrót 1 I powtarzamy do czasu wypełnienia zaadresowanego okienka. Czyli na każdy piksel przypadają 2 kroki. Ale przecież pisałem że jest 4 razy szybciej, a tu wychodzi że 2 razy No więc łatwo można zauważyć, że przy 16 bitach raz ustawiony kolor na linii danych możemy zostawić do czasu aż będziemy musieli użyć innego koloru. Więc jeżeli mamy kilkaset pikseli do wypełnienia jednym kolorem to raz go ustawiamy, a później już tylko WR strobe tak długo jak potrzebujemy Czyli realnie wykonujemy tylko jeden krok. Zaimplementowałem to w moich driverach i rezultaty były doskonałe. Na tyle dobre że odpadła mi konieczność posiadania pamięci pod bufor klatki. Wszystko wyświetla się błyskawicznie: Aktualnie mogę wyświetlać do 8Mpix/s, co teoretycznie pozwala odświeżyć ekran 240x320 ponad 100 razy na sekundę na STM32F1 taktowanym 64MHz. Czyli mogę jeszcze podnieść tą częstotliwość do 72 MHz i jeszcze zwiększyć transfery. Niestety chwilowo mam odcięty programator od płytki Nucleo i muszę kożystać z wewnetrznego oscylatora który pozwala rozkręcić mikroprocesor do 64MHz. Kolejnym problemem z którym musiałem się zmierzyć to mała ilość flash na grafiki do gier. Jak łatwo policzyć jedna pełnoekranowa grafika to 153600 bajty, a mam tylko 128k do dyspozycji. A jeszcze musi się zmieścić program. Rozwiązaniem problemu jest kompresja. Tu znów musiałem od zera napisać program do kompresji grafiki który spełniałby moje wymagania. Kompresor został napisany w Pythonie. A szybki dekoder zaimplementowany w C w driverach na STM32. Pisałem program praktycznie od zera wg mojego pomysłu. Otóż dzieli on grafikę na bloki o jednolitych kolorach, a ich metadane zapisuje w binarnym pliku wyjściowym, albo w pliku C. Bloki są następujące: pozioma linia, pionowa linia, prostokąt. Pojedynczy piksel to pozioma linia o długości 1. Kompresja odbywa się przez rozkład grafiki na takie bloki, a następnie zapisaniu ich parametrów do pliku wyjściowego. Procedurę dekompresji zaimplementowałem w driverach do wyświetlacza, a każdy blok łatwo można wysłać bezpośrednio do pamięci ekranu, gdzie obraz zostaje odtworzony. Kolejną funkcją którą zaimplementowałem w kompresorze jest możliwość kodowania różnicy pomiędzy dwoma grafikami. Tzn jeżeli robię animację to program kompresuje tylko piksele które różnią dwie klatki. Poniżej proces odtwarzania obrazka na wyświetlaczu w zwolnionym tempie: Skoro miałem już ograne wyświetlanie grafiki, przyszedł czas na prototypowanie konsoli i pisanie samego kodu gry Aktualnie moje stanowisko pracy wygląda następująco: Sama gra jest na etapie tworzenia grafiki. Na razie mam animacje na intro: To tyle na dzisiaj. Wraz z postępami będę aktualizował ten wątek. Pozdrawiam, Marek
  29. 9 punktów
    Cześć, pewnego razu na spotkaniu ze znajomymi okazało się, że na hasło „polej” nikt nie zareagował. Wtedy zrodził się pomysł, aby zaradzić takim przykrym sytuacjom w przyszłości postanowiłem stworzyć robota do nalewania alkoholi wysokoprocentowych. Z założenia robot miał nalewać alkohol do każdego kieliszka jaki się postawi oraz miał być zasilany przy pomocy baterii. Pierwsze prototypy zawierały prostą elektronikę opartą na czujnikach i przekaźnikach – jestem laikiem oraz samoukiem w kwestiach elektroniki. Projekty nie spełniały oczekiwań, ponieważ w normalnym użytkowaniu zawodziły. Około rok temu natknąłem się na Arduino i zacząłem pogłębiać swoją wiedzę w tym kierunku. Wydruki 3D wykonałem na swojej drukarce. Robot spełnił założenia. Poprzez zastosowanie czujnika ultradźwiękowego jest w stanie nalać do każdego kieliszka, a potencjometrem można ustawić ilość nalewanej wódki w zakresie około 10 - 50ml. Do zasilania użyłem 8 akumulatorów AA. Wykonałem obudowę z kilku elementów żeby mieć lepszy dostęp do podzespołów. Rynienka na pompce została stworzona po zalaniu układu... z wyciekiem sobie poradziłem ale dla pewności została Części których użyłem do budowy: Płytka stykowa 170 pól - 1 szt Stabilizator L7805CV 5V 1,5A – 1 szt Ultradźwiękowy czujnik odległości HC-SR04 2-200cm – 1szt Potencjometr liniowy 1K – 1 szt Wtyk DC 2,1/5,5mm z zaciskami skręcanymi – 1 szt Pompa membranowa - silnik R385+ - 12V - 3W - mini pompa wodna – 1szt Moduł sterownika L298N do silników DC – 1 szt Przełącznik kołyskowy 15x10mm – 1 szt Koszyk na baterie 8xAA (R6) – 1 szt Arduino Nano – 1 szt Uniwersalny Proto Shield do Arduino Nano – 1 szt Serwo TowerPro MG-995 – 1szt. Zawór zwrotny – 2szt. Moduł dioda LED RGB 5050 wspólna katoda – 1 szt. Magnesy neodymowe 10x5 – 8 szt Przycisk monostabilny – 1 szt. Rurka sylikonowa – 0,5m Rezystory Przewody połączeniowe Aby "polewacz" był mobilny jego elementy zaprojektowałem tak, aby zmieściły się w drewnianej skrzyni 30x20x15cm.
  30. 9 punktów
    Jakiś rok temu pomyślałem, ze może spróbuję swoich sił w tematyce robotów typu "delta". Zainspirowała mnie również konstrukcje Kolegów, @Eukaryota Delta Robot V3.0 oraz @deshipu Deltabot; którym serdecznie dziękuję za opisanie rezultatów swoich prac Zacząłem nieco od tyłu, bo od zakupu 3 silników krokowych NEMA17 z przekładnią planetarną (przełożenie ~5-krotne) i związku ztym robot wyszedł dość duży - teraz zastanawiam się, czy istnieje możliwość jest transportu np. pociągiem... Ale przechodząc już do konkretów, zamieszczam poniżej krótki film ( z góry przepraszam za jakość, ale w związku z obecną sytuacją, zmuszony byłem nagrywać telefonem): Założenia Celem projektu było zbudowanie robota typu delta, 3-osiowego (to jest bez dodatkowych osi obrotowych w efektorze) i długości ramion rzędu kilkunastu centymetrów. Koniecznie chciałem wykorzystać w tym projekcie RaspberryPi 3B+ (o czym za chwilę), coś związanego z pneumatyką (gdyż posiadam cały kartonik pneumatycznych przyda-mi-się), dodać jakiś prosty panel operatora, a samo demonstracyjne zadanie miało być w miarę efektowne, ale jednocześnie możliwe przy luzie na poziomie kilku milimetrów - wybór padł na sortowanie krążków według kolorów. Konstrukcja mechaniczna Sam stelaż składa się z profili V-slot 20x20mm, bardzo lubianych w środowisku "konstruktorów - DIY". Jest on przykręcony do podstawy-płyty spienionego PCV. Jak łatwo zauważyć, profile oprócz konstrukcji nośnej pełnią również rolę mocowanie elektrozaworów, kilku elementów elektronicznych itd... Do stelażu przykręcona jest płyta a'la trójkąt ramienny z rezokartu, a do niego trzy główne silniki. Od silników odchodzą drukowane 3D (wszystkie drukowane w tym robocie elementy to ABS). Od pomarańczowych ramion, przez przeguby kulowe firmy Igus® (której w tym miejscu serdecznie dziękuję , gdyż otrzymałem je bezpłatnie w ramach sponsoringu) i odcinki gwintowanego prętu M6 całość "schodzi się" do wspólnego efektora, na koncu którego zamontowana jest ssawka podciśnieniowa. Peryferia - szufladka pneumatyczna i podajnik rewolwerowy Będąc przy sprawach mechaniki, wspomnę o dodatkach zamieszczonych w robocie celem wyznaczonego zadania - podajniku rewolwerowym (stole obrotowym), który składa się z silnika krokowego, drukowanej 3D przekładni planetarnej oraz talerza (plexi + drukowana 3D obwódka) z 9 gniazdami, każde umożliwiające umieszczenie obiektu krążka. Sama szufladka natomiast to siłownik pneumatyczny SMC (nietypowy, gdyż tłok został zastąpiony magnesem, który sprzężony jest z wózkiem na nim umieszczonym, zatem w czasie pracy siłownik nie zmienia swojej długości) oraz 2 prowadnice o średnicy 10mm, na których umieszczony jest również 9-gniazdowa płytka, ale już nie okrągła, a kwadratowa). Po zakończonym cyklu układania może się ona wysunąć "na zewnątrz", co pozwala zabrać krążki i ponownie ułożyć je na talerzu. Elektronika "Mózgiem" robota jest płytka Nucleo F401RE, programowana w środowisku mBED. Ponadto w "sterowniku" (żółta płyta z plexi) umieszczony jest układ dystrybuujący zasilanie, przetwornica step-down (12V -> 5V) oraz moduł 2x przekaźnik, celem sterowania elektrozaworem eżektora i siłownika 5/2. Na zewnątrz sterownika "wychodzą" przewody sygnałowe dla łącznie 4 sterowników silników krokowych (czwarty, dla stołu obrotowego, jest znacznie mniejszy (TB6560) i umieszczony jest z tyłu, na profilu ). Warto dodać, że płytka rozdzielająca zasilanie została wyposażona w 3 transoptory, które pośredniczą między czujnikami krańcowymi umieszczonymi u góry, a samym STM32. Zasilanie Zasilanie robota jest dość złożoną sprawą, gdyż dla trzech głównych silników wykorzystałem zasilacz 36V 10A - tak duże napięcie pozwala na osiągnięcie dość dużych prędkości obrotowych, natomiast czwarty, "mały sterownik", nie może być takim napięcie zasilany - konieczne było użycie przetwornicy step-down (36V -> 24V). Logika/elektrozawory są natomiast czerpią energię z osobnego zasilacza, 12V 5A, które do logicznego 5V obniżane jest wymienioną w podpunkcie "Elektronika" wspomnianą przetwornicą. Ostatecznie, napięcie 3,3V wymagane przez Nucleo jest uzyskane z jego wewnętrznego stablizatora. Mamy więc linię napięcia stałego 36V, 24V, 12V, 5V, 3V3 "Panel operatora" U góry konstrukcji umieszczono przycisk bezpieczeństwa, który po naciśnięciu zwiera pin RESET Nucleo z masą - nie jest to może rozwiązanie profesjonalne (nie zadziała, jeśli np. naderwałby się kabel łączący sterownik z "grzybkiem"), ale stosunkowo proste i skuteczne. Poniżej znajduje się właściwy "panel", składający się z wyświetlacza 2,8" opartego o sterownik ILI9341. Wyświetla on na początku "menu", a po rozpoczęciu pracy robota - informacje o kolorach krążków oraz koordynaty XYZ. Poniżej znajdują się przyciski z podświetleniem, pozwalają one na rozpoczęcie cyklu (właściwej pracy), wsunięcie/wysunięcie siłownika, wyzerowanie osi oraz odłączenie silników tak, aby można było nimi ręcznie poruszać (to ostatnie muszę jeszcze dopracować). Warto zaznaczyć, że samą obsługą modułu "HMI" zajmuje się NodeMCU, a z samym sterownikiem komunikuje się po UART'cie. System wizyjny - RapsberryPi 3B+ Wspomniane RPi posłużyło jako prosty system wizyjny. Wiem, że można było zrobić rozpoznawanie barw znacznie prościej, ale za pomocą kamerki jest to znacznie skuteczniejsze i ponadto stanowiło łagodny wstęp do OpenCV - wycinam odpowiednie fragmenty obrazu, obliczam składowe średnie RGB i porównuję. kamerka jest na małej prowadnicy, ponownie od firmy Igus®, możliwa jest jej regulacja. Tutaj również komnikacja RPi <-> STM32 zachodzi po UART'cie. Układ pneumatyki Pneumatyka w robocie jest stosunkowo prosta, składa się na wejściu z osuszacza powietrza i regulatora ciśnienia wraz z manometrem (robot wymaga ciśnienia 4 barów). Następnie, przez elektrozawory, sprzężone powietrze doprowadzone jest do eżektora (generowanie podciśnienia dla ssawki) oraz siłownik SMC (ruch szufladki). Kilka zdjęć Podziękowania Projekt ten nie powstałby bez pomocy kilku firm, którym chciałbym serdecznie podziękować: wspomniany już wyżej Igus®, Mondi Polska, ST oraz ENEA (Akademia Talentów), a także mojej Szkole, Zespołowi Szkół Łączności im. M. Kopernika w Poznaniu Pozdrawiam, zapraszam do zadawania pytań
  31. 9 punktów
    Artykuł przeznaczony do wszystkich zapaleńców druku 3D. Można nie kupować dość drogi filament do swojej drukarki 3D, a produkować w domu własny filament z zużytych butelek PET od napojów. Przy tym nieważne, jeżeli butelka jest pognieciona, ona również się nadaje do domowej produkcji filamentu. Filament z butelek ma sporo zalet w porównaniu z firmowym filamentem kupowanym – ABS albo PLA. Przede wszystkim, że produkowany filament nic nie kosztuje, jest po prostu darmowy Produkowany pręt filamentu Jest bardzo sztywny i absolutnie nie łamliwy, wytrzymuje sporo ostrych przegięć. Filament własnej produkcji jest sporo mocniejszy i twardszy, jak na rozciąganie tak i o wiele bardziej odporny na uderzenie. Absolutnie nie pochłania wody, czyli nie trzeba go ani suszyć, ani chronić w zamkniętym zabezpieczonym od nawilżania się opakowaniu. Praktycznie nie skurcze się przy ochłodzeniu w trakcie druku. Nie wymaga chłodzenia drukowanej warstwy. Nie wymaga stołu podgrzewanego. Dla przyczepności wystarczy miejsce na stole posmarować cienką warstwą kleju w sztyfcie na przykład typu „Glue Stick” Wydrukowane detal można obklejać od razu po skończeniu wydruku. Taki filament jest bardzo odporny na działanie rozpuszczalników i środków chemicznych. Jak widać filament produkcji własnej ma sporo zalet w porównaniu z filamentami kupowanymi, a najważniejsze – że jest darmowy. Niżej przedstawiono zdjęcia maszynki do produkcji filamentu: Do domowej produkcji filamentu wykorzystywane zużyte butelki od napojów. Ale butelki muszą być czyste, resztki kleju do nalepki powinni być usuwane. Technologia produkcji jest bardzo prosta i składa się z trzech następujących operacji: Poprawa zgniecionych butelek i butelek z ryflowaną powierzchnią tak, żeby ścianka boczna butelki była gładka. Nacinanie butelek na paski o określonej szerokości, od 5mm do 12mm w zależności od grubości ścianki butelki. Produkcja pręta filamentu z nacinanych pasków na specjalnej maszynce z nawijaniem na bębenek odbiorczy. Na tych wideo można obejrzeć prace maszynki i przyrządu do nacinania pasków z butelek: Zębatka drukowanie:
  32. 9 punktów
    Cześć! Jako że już po sezonie to postanowiłem opisać tu moją i mateuszm konstrukcję. Robot powstał w ramach rekrutacji do koła naukowego robotyków KoNaR i debiutował na Robotic Arenie 2015. Był to nasz debiut w konstruowaniu robotów, ponieważ wcześniej żaden z nas tego nie robił. Mechanika Głównym założeniem mechaniki robota było wykorzystanie w pełni maksymalnej dopuszczalnej masy oraz skupienie jej w podstawie. W osiągnięciu tego celu pomógł nam projekt Autodesk Inventor, w którym to został wykonany szczegółowy projekt robota uwzględniający wszystkie drobne elementy mechaniczne. Podstawa robota została wykonana z trzech elementów: - ostrze z węglika spiekanego - płytka stalowa 3mm - płytka górna, 2mm, która łączyła dwa elementy wymienione wyżej W płytkach zostały wycięte otwory, w których następnie umieszczone były małe, okrągłe płytki z czujnikami białej linii. Stal była cięta laserowo oraz później frezowana. Napęd robota stanowiły znane i lubiane silniczki Pololu HP z przekładnią 50:1 przykręcone bezpośrednio do podstawy za pomocą dedykowanych mocowań. Podpięte do elektroniki były przy pomocy złączy ARK co umożliwiło ich łatwy demontaż w celach serwisowych. Obudowa robota została wykonana z laminatu 1mm. Na obudowie znajduje się nazwa robota oraz nasze imiona i nazwiska. Obudowa mocowana jest do podstawy za pomocą śrub, a jej elementy są do siebie lutowane. Dach robota wykonaliśmy z 2 mm przeźroczystego szkła akrylowego. Finalnie robot mierzy w najwyzszym miejscu 33,7 milimetra od podstawy do dachu, a od podłoza do dachu 37,2. Jego podstawa ma wymiary 98,9 mm na 99,6 mm. Masa waha się od 490 do 499g w zależności jak bardzo nakarmimy robota przed zawodami Elektronika Priorytetem projektu robota była jego dobra konstrukcja mechaniczna, w wyniku czego wymiary płytki z elektroniką były z góry narzucone. Elektronika została zaprojektowana w programie KiCad po zaimportowaniu wymiarów przeznaczonych na nią z programu Inventor. Elektronika robota dzieli się na dwie płytki: główną, która znajduje się tuż nad podstawą robota oraz dodatkowej, na której umieściliśmy włącznik zasilania, interfejs komunikacyjny oraz złącze na moduł startowy. Płytki połączone zostały ze sobą taśmą FFC. Mała płytka widoczna na zdjęciu nad płytką główną służy nam jako podstawka pod akumulator LiPo 7.4V, którym zasilamy robota. Sercem naszego robota został mikroprocesor STM32F1. Wybór tej rodziny wynikał z łatwości ich programowania przez początkujących. Czujniki odległości wykorzystane w robocie to znane i lubiane cyfrowe Sharpy 40cm. Umieściliśmy je 4, dwa z przodu oraz po jednym na bokach. Na czujniki białej linii użyliśmy dwa KTIRy 0711S. Jak wcześniej wspomniałem zostały one umieszczone na małych płytkach, które umieściliśmy w wycięciach w podstawie. Na sterowniki silników wybraliśmy dwa, podwójne mostki H TB6612. Zostały one dobrane ze względu na ich dobrą wydajność prądową, co umożliwiło nam skuteczne wysterowanie silników Pololu bez obawy o to, że przy pełnym zwarciu mostki ulegną uszkodzeniu. Płytki zostały wykonane metodą termotransferu oraz wyfrezowane za pomocą Dremela i pilników ręcznych. Software Kod robota został napisany w środowisku System Workbench for STM32 (SW4STM32) z użyciem generatora kodu konfiguracyjnego STM32CubeMX. Program podzielony był na dwie sekwencje: startową i walki. W pierwszej ustawiana była konfiguracja algorytmu robota oraz dostępne były funkcje testu czujników (widoczny na zdjęciu poniżej - cztery czerwone diody, które odpowiadały za pokazanie aktualnego stanu czujników) oraz czyszczenia kół (drobna funkcja pomocnicza ustawiająca małą prędkość na kołach). Sekwencja walki załączała się po otrzymaniu przez robota sygnału startowego z modułu. Większa część algorytmu walki opierała się na prostych if-ach z odpowiednio dobranymi nastawami silników w każdym przypadku, co okazało się wystarczające w większości starć. Następnie zostały dodane pewne udoskonalenia, o których już rozpisywać się nie będę Osiągnięcia - II miejsce Robomaticon 2016 - I miejsce Robotic Tournament 2016 - III miejsce Festiwal Robotyki Cyberbot 2016 - II miejsce [Minisumo] oraz I miejsce [Minisumo Deathmatch] Trójmiejski Turniej Robotów 2016 - II miejsce Opolski Festiwal Robotów 2016 - I miejsce Robotic Day 2016 [Praga] A poniżej kilka filmów z udziałem robota: 2Weak4U vs Hellfire 2Weak4U w Wiedniu 2Weak4U vs Dzik 2Weak4U vs Shevron (chyba) 2Weak4U w Deatmatchu [Rzeszów] 2Weak4U vs Szwagier Pozdrawiam i do zobaczenia w następnym sezonie, Aleksander
  33. 9 punktów
    Researcher jest robotem badawczym przeznaczonym do badania składu gleby oraz powietrza. Robot jest wyposażony w łamane ramię z łyżką przeznaczoną do pobierania próbek gleby oraz umieszczania próbek w specjalnych pojemniczkach wyposażonych w czujniki składu gleby (np. wilgotności, ph). Próbki mogą być pobierane z głębokości 10 cm dzięki zastosowaniu wiertła zamontowanego na siłowniku liniowym o wysuwie 10cm. Za obroty wiertłem jest odpowiedzialny silnik DC. Element wiertniczy jest zamontowany na zawiesie i mocowany na jedną śrubę, ułatwia to transport robota. Za działanie ramienia odpowiedzialne są 4 serwa, ramię jest wykonane z aluminium, dzięki czemu jest wytrzymałe i lekkie. Aby odciążyć serwo odpowiedzialne za obracanie ramieniem zastosowaliśmy płytę przymocowaną do podwozia, poruszają się po niej kułeczka zamocowane do części ruchomej. Konstrukcja robota jest wykonana w całości z aluminium i stali. Obudowa i podstawka pod elektronikę są wykonane z polisterynu. Robot jest w stanie poruszać się po trudnym terenie i wjeżdżać na krawężniki, umożliwia mu to zastosowanie zawieszenia biegunowego dla dwóch przednich osi. Tylna oś jest zamocowana na amortyzatorach. Za ruch silników odpowiedzialnych jest 6 silników DC zamontowanych do płaskowników aluminiowych za pomocą obejm i śrub. W tylnej części zamontowany wspornik mocujący do czujników wiatru. Robot waży około 13 kilogramów i ma 70 cm długości i ok 40 cm szerokości. Za pracę odpowiada moduł Arduino MEGA 2560, w robocie zastosowaliśmy 4 sterowniki silników jednokanałowych po jednym na każdą stronę robota (po 3 silniki do jednego) 2 pozostałem odpowiadają za ruch siłownikiem oraz silnikiem w module wiertniczym. Zastosowaliśmy czujniki temperatury powietrza i gleby, składu powietrza i gleby. Aby nie uszkodzić robota zastosowaliśmy czujniki odległości dzięki którym robot nie wjeżdża w ściany i większe przeszkody. Do komunikacja pomiędzy robotem a aparaturą używamy modułu radiowego. Do sterowania używamy przerobionej aparatury. Znajduje się w niej Arduino UNO, 3 gałki analogowe, wyświetlacz i płytka dotykowa z przyciskami oraz da przełączniki dźwigniowe do zmiany trybu sterowania. Całego robota budowaliśmy około 10 miesięcy w 3 osobowym zespole, uczestniczyliśmy w licznych zawodach m in East Robo, Mikrobot, Explory. Do sukcesów można zaliczyć 4 miejsce w Konkursie El Robo Mech dzięki któremu zdobyliśmy indeksy na studia. Zastosowaniem robota ma być wykorzystywany do badania gleb w miejscach trudno dostępnych oraz jako robot ratunkowy w wypadku skażeń chemicznych i biologicznych. Robot mógłby zbadać glebę i powietrze na terenie skażonym, a dzięki czujnikom kierunku i prędkości wiatru można będzie oszacować przemieszczanie się chmur z zanieczyszczeniem. Operator robota może odczytywać dane z czujników z wyświetlacza na kontrolerze oraz mieć podgląd z kamery umieszczonej na robocie.
  34. 9 punktów
    Witam całego Forbota. Chciałbym przedstawić tu mój autorski projekt, który stworzyłem w sumie w technikum, później go udoskonalałem, aż do wersji mikroprocesorowej. Dzisiaj chciałbym wam pokazać jego jedną z pierwszych wersji (to nie znaczy gorszą tylko ciekawszą). Zapraszam do lektury. Wprowadzenie Niniejsze urządzenie powstało jako unowocześnienie i ulepszenie tanich popularnych na rynku tzw. „klaskaczy”. Jako że te opierają się wbrew temu co mówi nazwa na pomiarze głośnych dźwięków, a nie klaśnięcia to ich niezawodność pozostawia wiele do życzenia. Główną ich wadą jest działanie na wszelkie głośniejsze dźwięki co uniemożliwia np. słuchanie głośniejszej muzyki, ponadto czasem nawet upadający przedmiot jest w stanie aktywować taki „klaskacz”. Projekt włącznika akustycznego jest wysoce efektywnym i niezawodnym zamiennikiem wcześniej wspomnianego rozwiązania, duża czułość powoduje iż nawet najsłabszy gwizd będzie efektywnie interpretowany, jedynym chyba mankamentem jest fakt, że trzeba potrafić gwizdać. Zasada działania jest prosta. Należy gwizdnąć zmieniając w odpowiedni sposób ton gwizdu aby włączyć lub wyłączyć podłączone urządzenie (np światło w pokoju). Włącznik akustyczny w wersji v 1.0 jest układem niemalże całkowicie analogowym. Elektroniczny: Blokowy: Ogólny opis zasady działania Sygnał akustyczny z mikrofonu elektretowego o małej amplitudzie musi zostać najpierw wzmocniony aby mogła zostać przeprowadzona jego analiza, dlatego też trafia najpierw na wzmacniacz oparty na tranzystorach T5,T4 Następnie wzmocniony sygnał podawany jest przez kondensator separujące na wejścia dwóch układów detekcji tonu LM567 gdzie jest porównywany do częstotliwości wzorcowej ustawionej przez zewnętrzne elementy RC. Układy te posiadają wyjście typu open colector, dlatego konieczne stało się zastosowanie rezystorów pull up. Wykrycie takiej samej częstotliwości podawanej na wejście jak częstotliwość referencyjna objawia się pojawieniem stanu niskiego na wyjściu LM567. Dalej sygnał trafia na układy czasowe NE555 pracujące w trybie monostabilnym, których zadaniem jest powiązanie czasowe wystąpienia obu sygnałów z detektorów tonu. Zwiększa to niezawodność całego układu dlatego, że wykrycie drugiej częstotliwości w odpowiednim przedziale czasowym zapoczątkowanym wykryciem pierwszej częstotliwości umożliwia przełączenia układu wykonawczego. Czas trwania sygnału aktywnej częstotliwości można płynnie regulować zmieniając stałą czasową RC układów NE555. Następnie sygnały z generatorów monostabilnych trafiają na bramkę AND zbudowaną w oparciu o 3 tranzystory T2, T3, Q1. Sygnał z bramki jest podawany na wejście zegarowe aktywowane zboczem narastającym przerzutnika T (ang. Toggle) zrobionego z przerzutnika D zawartego w układzie CD4013. Pod wyjście przerzutnika podłączony jest tranzystor wykonawczy w roli klucza T1. Obciążalność tego tranzystora reguluje nam jakim urządzeniem możemy sterować. Na płytce została umieszczona dioda włączona w kierunku zaporowym na wypadek indukcyjnego obciążenia tegoż tranzystora np. cewką przekaźnika. Szczegółowy opis zasady działania Układ wejściowy i wzmacniacz Na układ wejściowy składa się taki mikrofon podłączony przez rezystor 3,3k który polaryzuje wewnętrzny tranzystor polowy. Następnie sygnał trafia przez kondensator separujący składową stałą na wzmacniacz zbudowany na tranzystorze T5 BC547B . Jest to bardzo prosty wzmacniacz, którego baza polaryzowana jest jednym rezystorem. Punkt pracy został dobrany na podstawie charakterystyk tranzystora BC547B, prąd bazy wynosi około 3,3uA, a współczynnik wzmocnienia prądowego β wynosi około 310 daje to prąd kolektora na poziomie 1[mA], zakładając spadek napięcia na rezystorze równy połowie napięcia zasilania, a więc 4V można przyjąć, że wartość rezystora powinna wynosić ok. 4000Ω. W projekcie została użyta wartość znormalizowana 3,3k. Co przesunęło nieco charakterystykę pracy w kierunku wyższego potencjału. Następnie sygnał trafia przez rezystor - w celu zwiększenia impedancji wejściowej i kondensator - aby wyeliminować składową stałą na układ dzielnika napięcia wstępnie polaryzującego bazę tranzystora bipolarnego NPN BC547B. Tranzystor ten pracuje w układzie wspólny emiter. Pomiar współczynnika wzmocnienia prądowego tranzystora β wykazał wzmocnienie na poziomie 310. Zakładając niewielką rezystancję emiterową rzędu 220 Ohm oraz przyjmując na niej spadek napięcia 1V możemy wyliczyć prąd emitera, który wynosi Ie = 1/220 = 4,5[mA]. Upraszczając, że prądy emitera i kolektora są sobie równe jesteśmy w stanie policzyć przy spadku napięcia zasilania 9V o połowę wartość rezystora R1 która będzie równa R1 = 4,5/0,0045 = 1k. Prąd bazy wynosi Ic/Beta = 4,5/310 = 14,5[µA] Należy zatem przyjąć dzielnik napięcia w którym prąd płynący będzie wielokrotnością prądu bazy. Ponieważ wcześniej przyjęte zostało, że spadek napięcia na rezystancji emiterowej R4 wynosi 1[V] to napięcie jakie się odłoży na rezystorze R3 będzie wynosiło 1 + 0,7V =1,7[V], a na rezystorze R5 odpowiednio 9 - 1,7 = 7,3V. Przyjmując wartość rezystora R5 = 22k prąd płynący przez ten rezystor wyniesie 7,3/22000 = 330[µA] , natomiast przez rezystor R3 popłynie ten sam prąd pomniejszony o prąd bazy, więc będzie on wynosił 315,5[µA]. Znając spadek napięcia oraz prąd obliczamy rezystancję i przyjmujemy najbliższą znormalizowaną jej wartość – w tym przypadku 4,7k. Poniżej znajduje się wykres oscyloskopowy sygnału wejściowego i wyjściowego wzmacniacza na samy tranzystorze T1: Do pomiarów sygnału posłużyła karta dźwiękowa i program SoundCard Osciloscope v1.41. Wzmacniacz został przetestowany na sygnale 1kHz. Jak widać cechują go bardzo małe zniekształcenia oraz wzmocnienie napięciowe na poziomie = 3.37. Oprócz tego sygnał jest przesunięty w fazie o 180ᵒ co jest cechą charakterystyczną wzmacniacza w układzie OE. Jeśli jeszcze chodzi o realizację praktyczną to pierwszy stopień wzmacniacza został zrealizowany na osobnej płytce. Układ detekcji tonu LM567 Następnie sygnał akustyczny z wzmacniacza trafia na układ detekcji tonu oparty na popularnym LM567, zawiera on w swojej strukturze wewnętrzny wysokostabilny generator (źródło częstotliwości wzorcowej) oraz wejście do którego podaje się sygnał badany. Częstotliwości obu przebiegów są porównywane w układzie fazowej pętli synchronizacji (PLL) i – o ile są one z zadaną dokładnością sobie równe – następuje uaktywnienie wyjścia układu. Wejściem sygnału jest nóżka nr 3. Do wyprowadzeń nr 5 i 6 dołączone są zewnętrzne elementy generatora decydujące o częstotliwości jego pracy. Kondensator podłączony do nóżki nr 2 służy do ustalenia głównego parametru wewnętrznej pętli PLL: tzw. zakresu trzymania. Jest to największa dopuszczalna wartość o jaką mogą różnić się porównywane częstotliwości, by układ uznał je za równe. Kondensator podłączony pod nóżkę nr 1 jest elementem wyjściowym filtra dolnoprzepustowego eliminującego ewentualne przypadkowe krótkotrwałe przełączenia wyjścia. Wejście układu jest spolaryzowane wewnętrznie i wymaga jedynie doprowadzenia sygnału wejściowego, wyjście natomiast jest typu open colector, dlatego konieczne jest zastosowanie rezystorów podciągających. Dokładna zasada działania układów LM567 jest długa do opisania. Generalnie cały układ opiera się na detektorze I-fazowym (In-phase detector) i Q-fazowym (quadrature-phase detektor). Sygnały I/Q są sygnałami wartości składowych zespolonych sygnału, a otrzymuje się je przez mnożenie sygnału wejściowego przez sygnał referencyjny i przez sygnał referencyjny przesunięty w fazie o 90*. Następnie wartość zespolona sygnału wejściowego przechodzi przez filtr dolnoprzepustowy gdzie regulowana jest maksymalna wartość o jaką mogą różnić się sygnał referencyjny i wejściowy aby układ mógł uznać je za równe sobie. Sygnał z filtru przestraja odpowiednio generator sterowany napięciowo (VCO), którego sygnał porównywany jest z sygnałem wejściowym w detektorze fazy (I chase detector) składowej rzeczywistej sygnału wejściowego. Na wyjściu pojawia się różnica tych dwóch sygnałów, więc jeśli są sobie równe wyjście układu przyjmuje stan niski. Częstotliwość detekcji wylicza się ze wzoru podanego przez producenta: Fo=1/(1.1*R1*C1), w naszym przypadku R1=R10+R9, C1=C8 Układ czasowy NE 555 NE555 zawiera komparatory mające swe wyprowadzenia na nóżki 2 i 6. Napięcia na tych nóżkach są porównywane z napięciami panującymi na wewnętrznym dzielniku napięcia. I tak jeśli napięcie na nóżce 6 przekroczy 2/3 napięcia zasilania to wyjście układu przyjmuje stan niski, a wewnętrzny tranzystor przewodzi. W przypadku spadku napięcia poniżej poziomu 1/3 Ucc sytuacja jest analogicznie odwrotna czyli na wyjściu jest stan wysoki, a wewnętrzny tranzystor nie przewodzi. W zależności od podłączenia zewnętrznych elementów można uzyskać 3 rodzaje pracy: układ astabilny, monostabilny oraz przerzutnik RS. W projekcie został zastosowany tryb monostabilny w przypadku którego sygnał wyzwalający podawany jest na nóżkę 2 układu. Sygnałem wyzwalającym jest sygnał o wartości mniejszej niż 1/3 Ucc, a więc w naszym przypadku mniejszym niż 3V(ponieważ cały układ zasilany jest z 9V). Sygnał ten pobierany jest z wyjść układów LM567. Pojawienie się go na nóżce 2 powoduje iż na wyjściu pojawia się stan wysoki, a kondensator wcześniej non stop rozładowywany przez wewnętrzny tranzystor zaczyna się ładować. Stan wysoki na wyjściu trwa dopóty dopóki napięcie na zewnętrznym kondensatorze ładowanym przez potencjometr osiągnie wartość większą niż 2/3 Ucc. Gdy to nastąpi stan na wyjściu układu zmienia się na niski, a wewnętrzny tranzystor zaczyna rozładowywać kondensator do zera. Powtórne aktywowanie stanu wysokiego na wyjściu wymaga podania stanu niskiego na nóżkę 2. Jak podaje datasheet układu NE555 czas trwania impulsu na wyjściu opisuje zależność: T=1.1*R*C, w naszym przypadku R= Bramka AND Aby mogło nastąpić przełączenie układu wykonawczego w stan przeciwny sygnał z układów czasowych NE555 musi zostać podany na bramkę AND, innymi słowy aktywacja urządzenia wyjściowego następuję wówczas gdy oba sygnały wyjściowe z przerzutników monostabilnych, są aktywne jednocześnie. Bramka AND została zrealizowana na 3 tranzystorach. Schemat bramki został przedstawiony niżej: Gdy nie ma żadnego sygnału na wejściach podpisanych channel A channel B tranzystor Q1 nie przewodzi, rezystor R20 podciąga do dodatniej szyny zasilania jego bazę dzięki czemu nie ma możliwości aby jakikolwiek potencjał zgromadzony w okolicy nóżki bazy tranzystora Q1 przez przypadek go aktywował natomiast wyjście bramki jest podciągnięte rezystorem pull down R25 do ujemnej szyny zasilania. W momencie podania sygnału na bazy tranzystorów T3 i T4 te zaczynają przewodzić. Przez rezystory R20, R19 oraz bazę tranzystora Q1 zaczyna płynąć prąd w skutek czego na wyjściu bramki pojawia się stan wysoki. Rezystory zostały dobrane tak żeby bez problemu każdy tranzystor pracował w stanie nasycenia, a jednocześnie nie zostały przekroczone dopuszczalne parametry pracy. Maksymalny prąd płynący przez tranzystory T2,T3 wyniesie uwzględniając napięcia Ucesat na obu tranzystorach ok. 1,3 [mA] Przerzutnik T Aby móc zrealizować przerzutnik typu T na przerzutniku typu D należy sygnał z jego zanegowanego wyjścia podać na wejście. Sygnał wyjściowy będzie pobierany z jego niezanegowanego wyjścia. Zmiany stanu wyjścia na przeciwny idą w takt zbocza narastającego sygnału podawanego na wejście zegarowe. Sygnał podawany jest na wejście zegarowe przez rezystor zabezpieczający prosto z bramki AND. Przerzutnik T został zrealizowany na jednym przerzutniku typu D zawartym w układzie CD4013BP. Drugi przerzutnik zostaje niewykorzystany dlatego jego nóżki wejściowe (CLOCK2, RESET2, SET2,D2) są wg zasady podłączone na stałe do masy aby ograniczyć straty mocy. Stopień wyjściowy Stopień wyjściowy został zaprojektowany tak aby był możliwie jak najbardziej uniwersalny. Jako element przełączający posłużył tranzystor BC237 o maksymalnym prądzie kolektora Ic = 100mA , co w zupełności wystarcza do zasilenia cewki przekaźnika, oraz maksymalnym napięciu kolektor emiter Uce wynoszącym 45V. Mimo iż układ zasilany może być maksymalnie z 9V bo na tyle pozwalają układy LM567 to napięcia panujące na złączu tegoż tranzystora mogą być znacznie większe np. z racji indukcyjnego obciążenia przez cewkę przekaźnika, która w momencie odłączenia zasilania indukuje wysokie napięcie, o polaryzacji przeciwnej do wcześniejszego zasilania cewki. Aby zniwelować wpływ tego napięcia na tranzystor T4 została wprowadzona dodatkowo dioda podłączona równolegle do obciążenia, której zadaniem jest ograniczenie wyindukowanego się wysokiego napięcia do napięcia spadku na diodzie 0,6-0,7V. Rezystor R24 ogranicza prąd bazy tranzystora T7 i został tak dobrany aby tranzystor w momencie aktywacji znalazł się w stanie nasycenia przy jednocześnie dopuszczalnym prądzie bazy. Przy zasilaniu układu z 9V spadek napięcia na rezystorze wyniesie: 9V-0,7V=8,3V Rezystancja wynosi 4,7k co po podstawieniu do wzoru daje nam prąd I=1,7[mA], który wystarcza do pełnego otwarcia się tranzystora. Testy praktyczne Na podstawie testów przeprowadzonych w laboratorium można stwierdzić bardzo małą awaryjność urządzenia. Dzięki wysokiej selektywności układów LM567 układ reagował nawet przy dużym hałasie z mnóstwem innych składowych np. przy słuchaniu muzyki, znacząco deklasując tradycyjne „klaskacze”. Zdarzały się jednak sporadyczne aktywacje jednej z nastawionych częstotliwości co oczywiście nie zmieniało stanu wyjścia układu. Dzięki podwójnemu wzmacniaczowi urządzenie wychwytuje określone częstotliwości już przy najcichszym sygnale akustycznym. Testy wykazały, że reaguje na słaby gwizd do 2.5m, natomiast największa odległość z jakiej udało się aktywować urządzenie wynosiła nieco ponad 10 m. Parametry te są w zupełności wystarczające biorąc pod uwagę metraż przeciętnego pokoju. Układ powinien być zasilany napięciem z przedziału 5-9V. Dolną granicę zasilania determinują głównie układy NE555, ponieważ poniżej tej wartości zaczynają się same wzbudzać, natomiast górną komparatory częstotliwości LM567. Najlepsze efekty (czułość) uzyskuje się zasilając układ z 8-9 V. I to już koniec tego mam nadzieję wyczerpującego opisu. Troszkę może to przypomina powtórkę z podstaw elektroniki, ale mimo wszystko mam nadzieję że komuś taka analiza się przyda w przyszłości aby łatwiej rozpocząć przygodę z elektroniką. Dodam tylko, że całość została zaprojektowana w programie Eagle i wykonana metodą termotransferu na laminacie jednostronnym oraz starannie pocynowana i zabezpieczona kalafonią (stąd ten może brzydki wygląd). Wzięło się to stąd, że układ robiłem koledze do zamontowania w ścianie z kartongipsu, dlatego też cała elektronika nie ma stosownej obudowy oraz trzeba było jakoś ścieżki zabezpieczyć przed ewentualną wilgocią w ścianach ;D Na zakończenie filmik przedstawiający działające urządzenie oraz zdjęcia. W załączniku płytka w Eaglu. Eagle.rar
  35. 9 punktów
    Zaczynając przygodę z elektroniką, prawdopodobnie każdy z nas jako jedno pierwszych narzędzi jakie kupił to sprzęt lutowniczy. Zazwyczaj zaczynamy od taniej "transformatorówki" lub zwykłej lutownicy kolbowej. Z czasem do coraz bardziej zaawansowanych projektów/napraw zaczyna brakować nam wielu funkcji w takim sprzęcie lub zwyczajnie chcemy czegoś lepszego i zastanawiamy się nad zakupem stacji lutowniczej. Tak wyglądał też mój początek z lutownicami.Pierwsze stacje które miałem, to popularne chińczyki które szybko się psuły lub zużywały. Po przepaleniu którejś kolby z rzędu, powiedziałem basta! Po dość długich poszukiwaniach, stwierdziłem że sprzęt który mnie zaspokoi jest dość drogi i zostaje DIY, tak właśnie stworzyłem idealną stację lutowniczą dla siebie, wzorując się na ciekawych i gotowych już pomysłach z sieci. Uwaga! W niektórych miejscach na płycie występują napięcia 230V! Niezachowanie ostrożności może grozić śmiercią! Założenia jakie miałem: Możliwość podłączenia różnych kolb lutowniczych( 24V z termoparą) Funkcja uśpienia(stacja przechodzi w tryb 180 stopni) Pamięć 3 najczęściej używanych temperatur Sterowanie pochłaniaczem dymu z poziomu stacji Wyświetlanie wszystkich informacji w czytelny sposób na LCD Niska awaryjność(pisze ten artykuł po kilku latach użytkowania stacji i póki co zero problemów) Niewielkie koszty Myślę że założenia udało mi się spełnić idealnie. Do stacji można podłączyć dowolną kolbę z grzałką na 24V. Posiada pamięć 3 zaprogramowanych wcześniej temperatur. Po 15 minutach od odłożenia kolby przechodzi w tryb uśpienia, co za tym idzie temperatura spada do 180 stopni i jest podtrzymywana, tak aby po podniesieniu kolby szybko się rozgrzać do poprzedniej temperatury, dodatkowo w trybie uśpienia wyświetlacz się wygasza. Po 30 minutach bezczynności stacja wyłącza się. Na tyle obudowy jest dodatkowe wyjście 230V pod które możemy podłączyć wyciąg powietrza, załączamy je odpowiednią kombinacją klawiszy. Dwie diody służą do sygnalizacji nagrzewania grzałki i załączenia wyjścia 230V. Obecnie pracuję na taniej kolbie firmy Zhaoxin ze względu na fakt, że posiadam bardzo duży zapas grotów i chcę je wykorzystać. Jednak gorąco polecam Solomon SL-30, którą używam w pracy i zdecydowanie dużo lepiej się nią lutuje. Układ załączania grzałki oparty jest na triaku i optotriaku który dodatkowo wykrywa przejście sieci przez zero. Jako ciekawe rozwiązanie warto tu wspomnieć o układzie włącznika. Podając impuls przyciskiem włączającym układ, tak naprawdę zawieramy styki przekaźnika na chwilę, procesor w ułamku sekundy wystawia stan wysoki na tranzystor który steruje przekaźnikiem załączającym zasilanie na całej płycie. Wyłączenie polega na wystawieniu stanu niskiego na tranzystor i odłączenie zasilania przez przekaźnik. Dodatkowe wyjście 230V również zbudowane zostało na popularnym układzie triak+optotriak. Wyświetlacz LCD w czytelny sposób prezentuje interesujące nas informacje takie jak stan podniesionej kolby, temperatura grota jak i żądaną, tryb pracy czy stan wyjścia 230V. Program do stacji został zaczerpnięty z innego projektu stacji który znalazłem w sieci, wspólnie z autorem dokonaliśmy kilku poprawek i modyfikacji. Po dopracowaniu całości i długich testach urządzenia prezentuje wam moim zdaniem najlepsza stacje lutownicza DIY. Poniżej zdjęcia i link ze szczegółowymi informacjami oraz plikami do konstrukcji Szczegółowy opis i materiały do pobrania
  36. 9 punktów
    Dawno, dawno temu, kiedy Internet jeszcze raczkował... Miałem niesamowite szczęście — zostaliśmy zaproszeni do zwiedzenia Studia Hensona. My — to znaczy cały zespół pewnego teatru. Łazilismy po tym studio, nasi artyści rozmawiali z ichniejszymi artystami... a ja się nudziłem jak mops. Na szczęście Cheryl Henson to zauważyła, i po mojej informacji że jestem technikiem a nie aktorem — zaprowadziła mnie do pracowni. Dużo mógłbym na tem temat mówić (nie wiem czy mi wolno, ale technologie chyba nie są już tajemnicą), w każdym razie szczękę z podłogi zbierałem jakiś tydzień. Kermit na selsynach (kto pamięta co to?), kostium misia (tego z reklamy Coli) nafaszerowany elektroniką chyba bardziej niż skafander Armstronga, tajemniczy proces tworzenia skóry Piggy czy czterdziestocalowy kineskopowy monitor w montażowni... Wtedy postanowiłem sobie, że też muszę zrobić lalkę. Może nie jestem mistrzem w konstrukcji lalek, ale coś na ten temat wiem... Problem był prosty: o ile lalki Hensona przeznaczone są do filmu (czyli trzy osoby animujące Kermita, akumulatory wystarczające na kilka minut i zasada "czego nie widzi kamera tego nie ma") — o tyle ja chciałem zrobić lalkę teatralną. Dla niezorientowanych mam proste porównanie. Lalka Hensona jest jak wyścigowy bolid, który zasuwa najszybciej jak może (ale co okrążenie trzeba mu wymienić opony razem z kołami, zatankować, najlepiej zrobić pełny przegląd a do jazdy potrzebna jest kilkuosobowa ekipa). Lalka teatralna przypomina bardziej terenówkę — wjedzie wszędzie, tankuje się raz na jakiś czas jeśli gdzieś w pobliżu jest stacja benzynowa, przegląd się robi raz przed wyjazdem, a do prowadzenia jest potrzebny kierowca sztuk jeden. A jednak postanowiłem, że coś tam podpatrzę z Hensona, coś z typowych teatralnych lalek, i może coś wyjdzie. Wybór padł na jawajkę z dwóch powodów: po pierwsze jest stosunkowo prosta w konstrukcji, po drugie osoba która miała ową lalkę animować specjalizuje się właśnie w jawajce. Od razu uprzedzam ewentualne pretensje i aluzje do worklogów: moim celem było zrobienie pełnej konstrukcji i sprawdzenie, czy animacja jest w ogóle możliwa. Ubranie i makijaż to inna sprawa, muszę wybrać czy będę płacić, czy nauczę się szyć (to drugie chyba bardziej mi odpowiada) czy w ogóle zostawię lalkę taką jaka jest na pamiątkę i wezmę się za następną; w każdym razie projekt jest z mojej strony skończony. Zacząłem od założeń. Przede wszystkim postanowiłem trochę zmienić zasady ruchu głowy. W najprostszej jawajce głowa jest nieruchoma. Dodatkowe możliwości to ruch obrotowy, ew. możliwość skłonu. O ile z ruchem obrotowym nie ma problemu, o tyle różne mechanizmy przenoszące napęd na głowę bywają chimeryczne i awaryjne (a to zerwie się gumka prostująca głowę, a to coś stanie się z linką). Dodatkowo aby zmusić lalkę do skłonu głowy potrzebna jest stosunkowo duża siła. Tak więc naturalne mi się wydało zastąpienie takiego mechanizmu elektronicznym. Chciałem również wyposażyć lalkę w możliwości w jawajkach rzadko spotykane: możliwość poruszania oczami oraz przynajmniej jedna chwytna ręka. Tu też z uwagi na samą konstrukcję jawajki i sposób animacji nie jest możliwe zrobienie tego poprzez czysto mechaniczne rozwiązania. I tak mam zaszczyt przedstawić: Maestro Zittaurus, mistrza obojga magii, dla znajomych Ziutek (dla dalszych znajomych pan Ziutek). "Kręgosłup" lalki (zastępujący tradycyjny kij) został wykonany z dwóch rurek: wewnętrzna grubościenna rurka wodociągowa PCW 17mm przenosi ruch obrotowy na głowę, a jej sztywność wystarczy aby się nie uginała w czasie poruszania lalką. Zewnętrzna to zwykła cienkościenna rurka instalacyjna, na której spoczywa ciężar głowy i do której mocowane są ramiona. Głowę zaprojektowałem w programie FaceGen 3d Print (bardzo dobrze działa pod Wine) jako solid model i OpenSCAD-em wyciąłem w niej miejsca na oczy oraz mechanizmy napędowe.Przewody do serw biegną wewnątrz rurki. Użyłem tu zwykłych serw micro TowerPro SG90 przede wszystkim ze względu na ich popularność (a poza tym kilka ich miałem). Niestety — z kilku przyczyn nie było to dobry wybór, ale o tym później. Trochę problemu sprawił mi mechanizm dłoni. Nawet najmniejsze dostępne serwa są za wielkie, aby umieścić je wewnątrz dłoni. Tym samym umieszczając serwo w przedramieniu musiałem zmienić tradycyjny sposób mocowania dłoni (sznurek) na jakiś sztywny. Myślałem na początku o czymś w rodzaju bowdena, ale w mońcu wpadłem na pomysł zastosowania podwójnego przegubu kulowego. Kule zostały wydrukowane, łączący je pręt to ucięty kawałek śruby M4 przewiercony wzdłuż wiertłem 1.8 mm. Przycisk wyzwalający zamknięcie dłoni został umieszczony w rękojeści czempuritu. Początkowo projektowałem sterowanie proporcjonalne — ale szybko zdałem sobie sprawę, że nie ma to żadnego sensu: układ dłoni animatora na rękojeściach nie pozwala na tego typu sterowanie, dużo lepszym rozwiązaniem jest po prostu przycisk, po którego naciśnięciu zmienia się stan dłoni (zamknięta/otwarta). W rękojeści została umieszczona cała elektronika: akumulator 18650 2600 mAh, ładowarka z zabezpieczeniem, przetwornica MT 3608 oraz Arduino Pro Mini. Do sterowania ruchami głowy i oczu służy płaski joystick oraz pierścień (żółty na zdjęciu) do obracania głową na boki. Joystick został umieszczony zgodnie z życzeniem animatorki — tak jest jej najwygodniej operować. Do kontroli stanu akumulatora słuzy dioda — jeśli zaczyna migać, warto rozejrzeć się za jakąś ładowarką. Nie zamieszczam schematu — w końcu to trywialne podłączenie joysticka, przycisku i trzech serw do małego Arduino. Kod jest bardzo prosty, od typowego różni się wyłącznie klasą MyServo automatycznie odłączającą serwomechanizm jeśli nie jest używany przez co najmniej sekundę: #include <Servo.h> class MyServo: public Servo { public: MyServo(int pin); void writePos(int pos); void heartbeat(void); private: bool rlyAttached; int lastPosition; int servoPin; uint32_t lastMillis; }; MyServo::MyServo(int pin) { servoPin = pin; rlyAttached = 0; lastPosition = -1; } void MyServo:: writePos(int pos) { pos = constrain(pos, 0, 180); if (pos != lastPosition) { if (!rlyAttached) { rlyAttached = true; attach(servoPin); } write(pos); lastPosition = pos; lastMillis = millis(); return; } heartbeat(); } void MyServo:: heartbeat(void) { if (rlyAttached && millis() - lastMillis > 1000UL) { detach(); rlyAttached = 0; } } #define OCZY_PIN A1 #define GLOWA_PIN A0 #define REKA_PIN A2 #define VOLT_PIN A3 #define OCZY_SRV 11 #define GLOWA_SRV 10 #define REKA_SRV 12 #define LED_PIN 13 MyServo reka(REKA_SRV), glowa(GLOWA_SRV), oczy(OCZY_SRV); #define MINVOLT 675 #define MAXVOLT 775 void setup() { reka.writePos(90); oczy.writePos(90); glowa.writePos(180); pinMode(LED_PIN, OUTPUT); pinMode(REKA_PIN, INPUT_PULLUP); } uint32_t handStateChanged; bool handState; int handLevel = 180; int headLevel = 180; int eyesLevel = 90; #define OKO_BL 500 #define OKO_BU 550 #define OKO_LL 250 #define OKO_LU 810 void getInput(void) { int v_oko = analogRead(OCZY_PIN); int v_glowa = analogRead(GLOWA_PIN); int v_volt = analogRead(VOLT_PIN); bool v_reka = digitalRead(REKA_PIN); v_volt = constrain(v_volt, MINVOLT, MAXVOLT); v_volt = map(v_volt, MINVOLT, MAXVOLT, 100, 1000); digitalWrite(LED_PIN, (millis() % 1000) < v_volt); v_glowa = constrain(v_glowa, 220,490); v_glowa = map(v_glowa, 490,220,180,0); if (v_glowa == 180 || v_glowa == 0 || abs(v_glowa - headLevel) >10) { headLevel=v_glowa; } v_oko = constrain(v_oko, OKO_LL, OKO_LU); if (v_oko < OKO_BL) v_oko = map(v_oko,OKO_LL, OKO_BL,0,90); else if (v_oko > OKO_BU) v_oko = map(v_oko,OKO_BU, OKO_LU,90,180); else v_oko = 90; if (v_oko == 0 || v_oko == 180 || v_oko == 90 || abs(v_oko - eyesLevel) >= 6) { eyesLevel = v_oko; } if (v_reka == handState) return; if (millis() - handStateChanged < 200UL) return; handState = v_reka; handStateChanged = millis(); if (!handState) { handLevel=handLevel?0:180; } } void loop() { getInput(); reka.writePos(map(handLevel,0,180,0,90)); glowa.writePos(headLevel); oczy.writePos(180-eyesLevel); } Ziutek wyszedł mi całkiem nieźle (tzn. realizuje wszystko co założyłem), a teraz kolej na możliwe poprawki: W rękojeści powinien się znaleźć wyłącznie stosunkowo ciężki akumulator wraz z ładowarką. Arduino i przetwornicę należałoby podwiesić do rurki na wysokości tułowia lalki. W tym przypadku nie wchodzi już w grę przeprowadzenie przewodów wewnątrz rurki, ale rozwiązanie tego nie powinno być problemem. Dodatkowo należałoby wyprowadzić na jakimś gnieździe interfejs UART. Przycisk sterujący otwarciem/zamknięciem dłoni powinien być zdublowany na rękojeści. Sterowanie ruchami głowy powinno być możliwe za pomocą jednego palca. W ten sposób uzyskam pewniejszy chwyt rękojeści i możliwość łatwiejszego operowania manipulatorami oczu i dłoni. Sama rękojeść powinna być dopasowana do dłoni konkretnego animatora. No i oczywiście należy zastosować inne serwa; jakie — o to już będę pytał we właściwym dziale. W razie pytań jestem do dyspozycji.
  37. 9 punktów
    Od momentu poznania ESP8266 bardzo spodobał mi się ten układ. Gdy skończyłem robić pierwszy projekt oparty na tym układzie od razu zacząłem wymyślać kolejny. Dzisiaj chciałbym Wam przedstawić sterownik oświetlenia. Współpracuje on ze zwykłym włącznikiem świecznikowym i mieści się w puszce fi60, dzięki czemu (nad każdym włącznikiem światła mam puszkę fi70) w puszcze fi70 zostaje jeszcze sporo miejsca na kable. Po zaprojektowaniu płytki w programie Eagle zleciłem wyprodukowanie jej firmie jlcpcb. Wszystko trwało tydzień (zamawiałem również inne płytki dlatego tyle to trwało ). Płytki wysłali w piątek po południu czasu lokalnego a w poniedziałek płaciłem już vat u kuriera z DHL . Płytki wyglądają bardzo dobrze (sami możecie ocenić jakość produktu ) Po odebraniu płytek zacząłem wszystko składać w całość. ESP8266 12F zostało wykorzystane jako "mózg" płytki. Jako zasilacz służy Hi-Link HLK-PM01 230V na 5V. Za załączenie napięcia odpowiedzialne są dwa przekaźniki z cewką na 5V. Dodatkowo do każdego przekaźnika dołożyłem diodę prostowniczą. ESP jest zasilane napięciem 3.3v przez co musiałem zastosować LDO. Dodatkowo na wejściu fazy do układu zamontowałem bezpiecznik firmy bel fuse. Żeby esp mogło załączać przekaźnik musiałem wykorzystać tranzystor bc817 w wersji smd. Do tego potrzebowałem jedno złącze ark raster 5mm podwójne, oraz dwa złącza ark raster 5mm potrójne. Całość po zlutowaniu i umieszczeniu w puszcze fi60 wygląda następująco: Teraz przyszła kolej na oprogramowanie. Zdecydowałem się zrobić prostą stronę konfiguracyjną na której możemy: zmienić hasło do urządzenia zmienić dane serwera mqtt (sterowanie z każdego miejsca na świecie ) zmienić przyłączenie do sieci wi-fi zobaczyć jak długo pracuje nasz układ wybrać ilość podpiętych włączników (jedno albo dwa) Całość jest również sterowana z telefonu z systemem android. Teraz przymierzam się do zrobienia wersji v2 tego sterownika, chcę by był oparty na triakach i optotriakach (z tego co wyliczyłem to żarówka led o mocy 15W pobiera tylko 60mA a świeci jak zwykła żarówka 120W) oraz będzie posiadała wsparcie dla dotykowych podświetlanych włączników (moduły httm oraz panele marki weilak, wszystko mam tylko projekt został ) Jestem bardzo ciekaw Waszych opinii, dajcie znać w komentarzach co myślicie mo jej konstrukcji
  38. 9 punktów
    Aktualizacja: poniższy post został opublikowany przed wydzieleniem części wiadomości do kosza. Już na samym początku prosiłem o to, aby darować sobie zgryźliwości. Jeszcze raz ponawiam moją prośbę i obiecuję od teraz usuwać wszelkie posty, które będą miały nawet jedno złośliwe zdanie. Niezależnie od tego czy autorem będzie nowa osoba, czy użytkownik, który ma na koncie 100 tysięcy postów - każdego obowiązują takie same zasady. To, że opisywany projekt jest częściowo reklamą tego projektu jest chyba oczywiste - wystarczy poświęcić kilka sekund i obejrzeć filmy, które są w pierwszym poście. Nie przypominam sobie, aby gdzieś był zakaz publikacji tego typu opisów. Nie jest to produkcja masowa, nie widzę więc powodu, aby od razu "rzucać" się na autora i krytykować za wszystko co możliwe. Czym taki projekt różni się od innych DIY, w których autorzy nie podają dokładnej instrukcji budowy i nie dzielą się projektami? Moim zdaniem niczym. Ten projekt wypada nawet lepiej, bo jak ktoś będzie bardzo chciał to sobie chociaż może kupić takie urządzenie. Prawie nikt nie zadał konkretnych pytań technicznych, pojawiały się tylko różne uwagi "byle udowodnić, że projekt jest zły". Autor próbował Wam wszystko wyjaśnić, wstawiał zdjęcia i filmy, a dla Was nadal jest źle. Rozumiem, że komuś projekt może się nie podobać, wystarczy raz wyrazić swoje zdanie lub zignorować temat. Jak widać po głosach czytelników, raportach oraz otrzymanych przeze mnie wiadomościach jest sporo osób, którym ten projekt się zwyczajnie podoba. Proszę więc wszystkich krytyków, aby wzięli pod uwagę, że nie każdy musi się z Wami zgadzać, niektórym taki projekt się podoba i tyle. Nie musicie na siłę wszystkich przekonywać, że jest źle i atakować ciągle autora. Projekt ten zaakceptowałem świadomie i widziałem, że jest to częściowo reklama. Uznałem jednak, że projekt jest ciekawy, nie było u nas opisu takiej maszynki. Liczyłem więc, że takie DIY może być dla wielu osób ciekawą inspiracją. Autor nie jest pierwszą osobą na świecie, która zrobiła takie urządzenie. W Internecie jest sporo maszynek do ręcznej produkcji filamentu. Jak ktoś będzie chciał to wykona urządzenie samodzielnie. To czy jest sens sprzedawać taka maszynkę to już zweryfikuje rynek - jak będą klienci to będzie sens, a jak nie będzie zainteresowanych to trudno, przynajmniej ktoś próbował. Dziwie się osobom, które poświęcają tyle czasu na pisanie krytyki i szukanie zaczepek. Ciężko mi uwierzyć, że liczą one na merytoryczną dyskusje. Nie macie ciekawszych zajęć od krytykowania projektów? Jeśli macie gorszy dzień lub nadmiar energii to proponuje skupić się na chwaleniu DIY, które według Was są ciekawe. Sprawdźcie listę opisanych projektów, znajdźcie coś ciekawego i napiszcie autorowi, że robi dobrą robotę. Nie widzę wielu postów, które chwaliłyby ciekawe DIY - tak ciężko napisać komuś dobre słowo? Jeszcze raz apeluję o ograniczenia zgryźliwość, a wszystkim będzie przyjemniej czytać posty i więcej osób będzie chętnie brało udział w dyskusjach. Zachęcam również osoby, które nie zgadzają się z takimi złośliwościami, aby wyrażały to jakoś publicznie (np. przez posty lub reakcje). Oczywiście doceniam raporty i PW kierowane do mnie, ale może jednak byłoby dobrze, aby autorzy takich wiadomości widzieli, że to "nie są tylko moje wymysły", a jest wiele osób, którym taki ton dyskusji zwyczajnie nie odpowiada.
  39. 9 punktów
    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.
  40. 9 punktów
    Przedstawiam mój projekt który zrealizowałem w ostatnim czasie, jest to prosty manipulator osadzony na platformie mobilnej. Założeniem tego projektu było maksymalne uproszczenie konstrukcji i sterowanie jej za pomocą kontrolera od Playstation 3. Całość miała też po naciśnięciu przycisku wykonywać określone funkcje automatycznie. Konstrukcja jest rozwojowa, będzie wyposażona w kamerkę bezprzewodową i dodatkowe czujniki. Konstrukcja to zmaterializowane pomysły z głowy. Przebieg budowy był improwizacją, aczkolwiek niektóre elementy były projektowane. Podwozie zostało zaprojektowane od podstaw, manipulator to zmodyfikowany projekt dostępny w sieci. Podwozie: Manipulator: BUDOWA MECHANICZNA Większość elementów konstrukcyjnych to wydruki 3D. Gąsienice i koła to produkcja LEGO, koła zostały odpowiednio zmodyfikowane przez wklejenie w nie łożysk tocznych. Naciąg gąsienic zrealizowany jest za pomocą podwójnego mimośrodu w tylnych kołach. Wszystkie śruby, nakrętki i podkładki są oczywiście nierdzewne. W każdym połączeniu ruchomym ramienia znajduje się tulejka mosiężna. Nakrętki samochamowalne. ELEKTRONIKA Podwozie napędzane jest przerobionymi serowomechanizmami TowerPro MG995, manipulator wyposażony w TowerPro MG90, tryby metalowe. Do zasilania zastosowano pakiet Litowo-polimerowy 7,4V 1300mAh, na pokładzie znajduje się przetwornica obniżająca odpowiednio napięcie do pracy serw. Mózgiem Jest Arduino UNO z USB host shieldem + Bluetooth. Użytkownik informowany jest o napięciu pakietu i w odpowiednim momencie też ostrzegany sygnałem dźwiękowym za pomocą testera. Na przodzie umieszczono dwie diody led. Podsumowując: - 2x TowerPro MG995 - 3x TowerPro MG90 - Pakiet LiPo 7,4V 1300mAh - Przewornica 3/5A - Arduino UNO - USB Host Shield 2.0 - USB Bluetooth - LiPo tester - 2x LED STEROWANIE Zgodnie z założeniami całość sterowana jest za pomocą Kontrolera od PS3. Lewy analog odpowiada za jazdę, prawy analog obsługuje ramię główne i ramię manipulatora. Przycisk analogowy R2 odpowiedzialny jest za uchwyt. Przycisk R1 powoduje zapamiętanie uścisku, czyli trzyma przedmiot beż konieczności trzymania przycisku R2. Kolejno, przycisk L1 pozwala włączyć oświetlenie LED na przodzie. START uruchamia pętle z programikiem który ma za zadanie podnieść przedmiot oddalony o 15cm przed obrócić się o 180 stopni, położyć przedmiot przed sobą, ponowne naciśnięcie tego przycisku wychodzi z pętli. Czas obrotu dobrany empirycznie. Powtarzalność miejsca uzyskana na poziomie 0,5cm (zadowalająca) SELECT służy do włączenia testu wszystkich serw, ustala określone pozycje, wyjście z pętli po ponownym naciśnięciu przycisku. Podsumowując: - LEWY ANALOG -> jazda - PRAWY ANALOG -> manipulator - R2 -> uchwyt manipulatora - R1 -> zapamiętanie uchwytu - L1 -> włączenie oświetlenia - START -> program wykonujący przenoszenie obiektu (w pętli) - SELECT -> Program testujący pracę serw (w pętli) OPROGRAMOWANIE Program dla płytki mikrokontrolera napisany został w środowisku Arduino IDE, zmodyfikowano w dużym stopniu przykład PS3BT. EFEKTY Zdjęcia: Aktualizacja 29.02 Platforma posiada kamerkę bezprzewodową przekazującą kolorowy obraz i dzwięk. Film: Pierwsze testy sterowania padem: https://www.youtube.com/watch?v=ACa2hxboEXs
  41. 9 punktów
    Cześć! Jako że ostatnio na Forbocie jest opisywanych coraz mniej robotów biorących udział w zawodach postanowiłem opisać swojego robota nanosumo. Sam robot powstał już jakiś czas temu (ok 1,5 roku temu), ale do dzisiaj nieźle mu szło na zawodach i ogólnie jestem całkiem zadowolony z konstrukcji. Wyciągnąłem z niej wiele wniosków i mam nadzieję że kolejna będzie jeszcze lepsza Mechanika : Rama robocika zbudowana jest z malutkich kawałków laminatu, na których ściankach są umieszczone od środka zębatki. Wszystkie koła zebate jak i silniki pochodzą ze znanych 9 gramowych serw. Największym wyzwaniem było upchnięcie dwóch silników na sobie tak by nie podnosiły za mocno całej konstrukcji oraz były dobrze spasowane z zębatkami. Same silniki są przyklejone do siebie oraz do podstawy robota. Koła to przerobione nakrętki mosiężne, w tym momencie nie umiem powiedzieć skąd pochodziły. Wywierciłem w nich otworki i odlałem małe silikonowe oponki. Z przodu robota widoczny jest pług przymocowany na stałe jak i opadający. W sumie nie jestem pewien czy kiedykolwiek pomógł mi podważyć przeciwnika, a czasami sprawiał kłopot z postawieniem bez opadnięcia przed rozpoczęciem walki. Elektronika: Robotem steruje atmega8 taktowana 8mhz z zewnętrznego kwarcu. Ma wgrany bootloader, by oszczędzić pinów na płytce. Oczami są 4 czujniki, z czego jeden jest nieaktywny, gdyż nie miałem miejsca na moduł startowy i musiałem pozbyć się diod ir. Czujniki to, jak w każdej mojej konstrukcji, tsopy i diodki ir smd. Są naprawdę fajne pod względem zasięgu (który da się regulować), jednak zajmują sporo miejsca na pcb. Diodki są sterowane tranzystorami, jednym na parę diod. Mostek to malutki 24 pinowy qfn od freescale - MPC17531. Czujniki linii to ktiry0711s zamocowane na samym dole robota. Moduł startowy postanowiłem umieścić w całości w robocie. Chciałem mieć pewność, że moduł za każdym razem się poprawnie zaprogramuje, a następnie bez problemu wystartuje. Oprócz tego jest trochę drobnicy, nie ma regulatora, wszystko zasilane jest bezpośrednio z li-pola 140 mAh. Program: Zawsze staram się pisać jak najprostsze programy do walczących robotów i tak też było w tym przypadku. W sumie tradycyjnie "wyifowane" warunki na czujniki i poszczególne reakcje silników - nic szczególnego. Pora na osiągnięcia: - 1 miejsce Robomaticon 2015 - 1 miejsce TTR 2015 - 1 miejsce Roboxy 2015 - 2 miejsce Sumochallenge 2015 - 1 miejsce RoboticArena 2015 - 3 miejsce Robomaticon 2016 W tym roku nanoHaker2 dostał się także do ćwierćfinałów Robotchallenge 2016. Robot jest już stary i szykuję powoli nową konstrukcję, w nadziei że w końcu uda się zdobyć podium w Wiedniu I jeszcze na koniec parę zdjęć : Jak znajdę jakieś filmiki z udziałem nanoHakera wrzucę linki. Mam nadzieję, że się podobało i czekam na pytania Pozdrawiam, Piotrek
  42. 8 punktów
    Autonomiczny robot mobilny z nawigacją GSP W życiu każdego studenta przychodzi monet, kiedy musi się spiąć i zrobić pracę inżynierską. Jako, że większość proponowanych tematów przez uczelnię nie wpadło w obszar moich zainteresowań, a już od jakiegoś czasu chciałem „pobawić się” w budowę robota z GPS to właśnie taki temat zaproponowałem promotorowi i bez problemów został zaakceptowany (kierunek – AiR). Potem jak się okazało nie był to do końca dobry pomysł z uwagi na problemu w testowaniu GPS – testy przypadły głównie na styczeń – a więc w tym roku deszcze itp. a nawigację trzeba jednak testować na dworze. To tyle tytułem wstępu a teraz do bardziej praktycznych zagadnień. Robot z założenie miał być 2 kołowy + jedno koło wleczone, posiadać moduł bluetooth do wstępnej kalibracji i wpisywaniu współrzędnych, sterowany za pomocą Arduino Nano (w tym przypadku klon), a jego zmysłami poznawania świata miał być: moduł GPS Neo-6m, magnetometr oraz 3 czujniki ultradźwiekowe z przodu do wykrywania przeszkód. Przeszukałem pełno gotowych platform mobilnych ale żadna mi do końca nie pasowała, a że od niedawna byłem właścicielem drukarki 3D to postanowiłem zaprojektować własną i wydrukować z PLA. Projekt owej platformy zrobiłem w środowisku CAD w programie Solid Edge i wyglądał tak jak poniżej. Składa się z 2 platform oraz miejsca na czujniki ultradźwiękowe: dolna na arduino, sterownik i akumulator, a górna na pozostałe podzespoły. Jak widać pokusiłem się o zamodelowanie również felg do już gotowych kół – okazało się że mają efekt „ósemkowania” co uniemożliwiało prostą jazdę. Koło wleczone zastąpiłem jednak Ball Caster'em, ponieważ te które użyłem miało straszne luzy i również powodowało samoczynną jazdę po łuku. A tak prezentuje się już wydrukowana i złożona platforma: Jako że wszystko było zamodelowane w CAD’zie to mogłem porobić rysunki złożeniowe rodem jak z sklepów meblowych (może projektowanie mechaniczne to dobry pomysł na artykuł ) Kolejnym krokiem było zrobienie elektroniki. Aby wyglądało to w miarę estetyczniej to pokusiłem się o zrobienie płytki PCB – projekt w KiCad'zie a potem termotransferem na laminat (tam gdzie Arduino to płytka dwustronna, a tam gdzie moduły jedno) Jeszcze tylko zasilanie – Li-Pol 2s firmy Redox (pomocny w ogarnięciu tego tematu był artykuł na Forbocie – wielkie dzięki za kompendium wiedzy w pigułce) i możemy zaczynać programować – a to dla mnie było największym wyzwaniem. Wrzuciłbym kod ale to jest 700 linijek napisanych raczej łopatologicznie więc tylko ja się w nim odnajduję Jak byście mieli jakieś pytania odnośnie działania jakiejś części to podrzucę i postaram się wyjaśnić. Jako, że byłem na AiR no to fajnie by było wrzucić jakiś nawet prosty regulator – zdecydowałem się na Proporcjonalny a układ regulacji wygląda następująco: (KSN – kompensacja strefy nieczułości) Działał on dosyć dobrze, im robot "był dalej" od zadanego kontu tym szybciej obracał się a im bliżej tym zwalniał, zaś przeregulowanie było znikome. Gotowy robot prezentuje się tak: Niestety wszystko nie było takie piękne i proste, a to niektóre napotkane problemy Magnetometr praktycznie nie działał. Wskazywał azymut w przedziale może z 0-15o. Powodem było pole magnetyczne wytwarzane przez magnesy silników. Google jednak nie znały odpowiedzi co zrobić z tym faktem więc testowałem po kolei różne warianty i tak o to idealnym rozwiązaniem okazało się umieszczenie silników w stalowe rurki. Z powody złych warunków na dworze testowanie robota nie było zawsze możliwe. Arduino też nie wyrabiał jak dostawał tyle danych (GPS okazał się bardzo obciążający – w momencie kiedy dostawał pakiet danych to Ardu zaczęło wariować). GPS i bluetooth nie mogły działać w tym samym momencie więc nie miałem możliwości zdalnie dowiedzenia się co robot w danej chwili „miał na myśli”. Generalnie to wszystko działało ale osobno: jak testowałem unikanie przeszkód i ustawianie się na dany kąt to była gitara. Dołożyłem do tego GPS to raz działało a raz nie – jak wspomniałem po dostaniu pakietu danych zaczynał wariować przez chwilę. W planach mam zamianę Ardu na STM32 i spróbowanie ponownie ruszyć temat. Dodatkowo napisałem prostą aplikację w C#, która komunikowała się z robotem przez bluetooth i można było łatwiej testować podzespoły i wprowadzać współrzędne. Praca została obroniona na 5 więc było warto poświęcić nad tym dużo czasu. Zapraszam do komentowania
  43. 8 punktów
    Witam serdecznie wszystkich czytelników. Chciałbym wam dziś przedstawić mój projekt jaki wykonałem na zakończenie technikum. Mianowicie zaprojektowałem i zbudowałem router sieciowy wyposażony w 5 portów ethernet oraz WIFI 2,4Ghz i 2x2 MIMO. Projekt zacząłem od wybrania jednostki sterującej , znajomy elektronik polecił mi SKW92a. Jest to mały moduł idealny do tego typu zastosowań. Można na nim uruchomić OpenWRT, bardzo ekonomiczna w zajmowane miejsce na dysku( tylko około 8 MB) wersja Linuxa. Tak więc użyłem tego modułu do budowy tego urządzenia. Następną rzeczą do zrobienia było dobranie zasilania. Chciałem aby router mógł być zasilany z np.takiej oto ładowarki , gdyż wejście microUSB i 5V jest dość popularne w dzisiejszych czasach. SKW92a działa jednak na zasilaniu 3,3V, konieczne więc było dodanie przetwornicy z 5V na 3,3V. Postanowiłem dodać jeszcze LEDy , aby służyły jako wskaźniki oraz port USB który będzię mógł posłużyć do podłączenia pamięci zewnętrznej w razie potrzeby przywrócenia systemu. Na końcu oczywiście też filtry dopasowujące transmisje ethernet i porty szeregowe do debuggowania. Projekt PCB routera Zaprojektowałem płytkę w Ki-Cadzie, dodałem swoje logo i wysłałem do produkcji ( sam proces projektowania PCB , rysowania footprintów itp. zajął około 30 h). Po polutowaniu wszystkiego router zaczął nabierać kształtu. Wszystko na miejscu Niestety pierwsze uruchomienie nie poszło zbyt kolorowo, gdyż mimo poboru prądu nie dało się wejść przez UART do SKW , po dogłębnej diagnostyce okazało się że nie jest to błąd portu szeregowego ale przetwornicy która była wadliwa.Musiałem umieścić tam osobną przetwornice step-down na osobnej płytce. Po tym zabiegu router zaczął działać wyśmienicie. Działający router Zainstalowanie OpenWRT nie było większym problemem, a także późniejsza konfiguracja była dość prosta. Z pomocą znajomego odkryliśmy że bez problemu można także przełączyć router w tryp switcha i można nawet tworzyć VLANy. Ostatnią rzeczą do zrobienia zostało zrobić ładną obudowę, którą zaprojektowałem w programie Designspark mechanical i wydrukowałem w drukarce 3D. Obudowa A tak wygląda w pełni działający router Dziękuję za uwagę i zapraszam do zadawania pytań w komentarzach
  44. 8 punktów
    Skoro forum powoli zmienia profil i przestajemy się skupiać na robotach, to postanowiłem, że zrobię sobie tutaj trochę bezczelnej reklamy i napiszę o projekcie, nad którym pracowałem od jakiegoś roku, który choć związany z mikrokontrolerami i programowaniem, robotem stanowczo nie jest. Zaczęło się mniej więcej rok temu, kiedy wpadłem na pomysł jak można sprawić, żeby nauka języka Python była znacznie łatwiejsza, mniej problematyczna oraz przede wszystkim fascynująca. Micro:bit i Raspberry Pi pokazały, że programowanie dedykowanego urządzenia daje bardzo dużo radości oraz poczucie kontroli nad techniką — moim zdaniem bardzo ważne rzeczy przy uczeniu jakichkolwiek technicznych tematów. Niestety, moje doświadczenia z przeróżnych szkoleń i warsztatów pokazały także achillesową piętę takiego podejścia: zawsze coś nie działa. Ludzie przychodzą z własnymi laptopami, niektórzy mają na nich poinstalowane jakieś Windowsy czy inne Makoesiksy, połowa z nich nie potrafi zainstalować sterownika, druga połowa akurat miała system update i sterownik im przestał chodzić, trzecia połowa dopiero ściąga prze konferencyjne WiFi środowisko uruchomieniowe i kompilator, a czwartej połowie nie chcą zainstalować się biblioteki. W efekcie ponad połowa czasu zawsze jest tracona na ustawianie wszystkiego. Do tego kiedy już uczniowie napiszą te swoje gry i będą chcieć się nimi pochwalić, to nie będą mogli — bo działają tylko na ich komputerze gdzie jest wszystko zainstalowane, a uruchomienie na komputerze kolegi wymaga przechodzenia całego procesu ponownie. Koszmar. Zatem postanowiłem zrobić urządzenie dedykowane do pisania gier, usuwając przy tym z drogi jak najwięcej przeszkód tak, aby można się było skoncentrować na celu — czyli samym programowaniu — bez wszystkich dodatkowych problemów. Początkowo stworzyłem shield dla płytek sprzedawanych przez Adafruit, zawierający przyciski i prosty kolorowy wyświetlacz LED 8x8, aby dało się pisać gry w rodzaju snake-a czy tetris-a. Jednak nie było to jeszcze rozwiązanie idealne, choć pozwoliło mi zbadać co działa, a co nie, oraz doszlifować moje umiejętności. Dzisiaj udostępniam szerszej publiczności moje najnowsze dzieło, czyli "prawdziwą" przenośną konsolę do gier. Zawiera ona kolorowy ekran 128x128, głośniczek, 6 przycisków i mikrokontroler programowany w CircuitPythonie. Urządzenie po podłączeniu do komputera widoczne jest jako dysk USB, nie wymagając przy tym żadnych sterowników (chyba, że ktoś ma Windows 7, wtedy niestety konieczne jest zainstalowanie sterownika aby mieć dostęp do konsoli na porcie szeregowym), a programujemy je po prostu edytując widoczne na nim pliki (lub kopiując je z komputera, oczywiście). Wbudowana w firmware prosta biblioteka do obsługi duszków i kafelków ułatwia zadanie. Grafika jest trzymana w plikach BMP, dźwięki w plikach WAV, kod w plikach tekstowych — zatem można użyć dowolnego programu jaki akurat się ma dostępny i jaki umie się już obsługiwać. Więcej informacji o projekcie, wraz z logami z jego konstruowania można znaleźć na https://hackaday.io/project/27629 Tylko, że co daje taki projekt zrobiony dla siebie do szuflady? Oczywiście wszystko jest opisane i opublikowane na otwartych licencjach, ale szanse na to, że ktoś inny zbuduje takie urządzenie są w zasadzie znikome. Aby było ono rzeczywiście przydatne, ludzie muszą go używać, a zatem musi być ono dostępne w sprzedaży. Dlatego kolejnym moim krokiem było zlecenie wyprodukowanie małej serii tych urządzeń. Dzisiaj właśnie przyszła paczka z fabryki i rozpoczynam ich sprzedaż na Tindie. Jest ich tylko 50, nie liczę na zbicie na tym kokosów, ale być może uda się zbudować społeczność zainteresowaną programowaniem tych urządzeń. Oczywiście jak na polskie warunki cena jest wysoka — niestety tak to jest z produkowaniem małych serii niestandardowych urządzeń. Ale być może kogoś jednak to zainteresuje: https://www.tindie.com/products/deshipu/game-10-game-console-kit/ Wreszcie, żeby nie było, że to tylko taka reklama i komercja, bardzo chętnie pomogę ludziom chcącym zbudować swoją własną wersję tej konsoli. Nie trzeba do tego wytrawiać płytek i lutować elementów montowanych powierzchniowo — wystarczy dowolna płytka rozwojowa z mikrokontrolerem SAMD21, moduł wyświetlacza, kilka przycisków, trochę kabelków, kostka pamięci flash i opcjonalnie głośniczek lub słuchawki.
  45. 8 punktów
    Algorytmy związane z szeroko pojętą sztuczną inteligencją (AI, Artificial Intelligence) są ostatnio bardzo popularnym tematem. Na ogół AI kojarzy się z ogromnym zapotrzebowaniem na moc obliczeniową, wykorzystaniem GPU (Graphics Processing Unit) oraz obliczeniami w chmurze. Okazuje się jednak, że sztuczna inteligencja znajduje również zastosowanie w świecie mikrokontrolerów. Powstał nawet termin na określenie takich zastosowań - Edge AI. O tym jak popularny jest temat AI świadczy chociażby pojawienie się sprzętowych akceleratorów przeznaczone dla urządzeń wbudowanych, tzw. TPU (Tensor Processing Unit), przykładowo Google Coral, albo Intel Neural Compute Stick. Dostępne są również mikrokontrolery z wbudowanym TPU, np. Kendryte K210 . Spis treści serii artykułów: Sztuczna inteligencja na STM32, czyli przykład użycia X-CUBE-AI cz.1 Sztuczna inteligencja na STM32, czyli przykład użycia X-CUBE-AI cz.2 Sztuczna inteligencja na STM32, czyli przykład użycia X-CUBE-AI cz.3 Firma STMicroelectronics, czyli producent popularnych również na naszym forum układów STM32 postanowiła dostarczyć produkt związany z AI. Na razie nie oferuje sprzętowej akceleracji, ale możemy za darmo pobrać pakiet oprogramowania o nazwie X-CUBE-AI, który pozwala na łatwe wykorzystanie możliwości jakie daje sztuczna inteligencja. W niniejszym artykule postaram się opisać bardzo prosty przykład wykorzystania biblioteki X-CUBE-AI na płytce ewaluacyjnej z układem STM32L475. Planowałem napisać dłuższy artykuł na zakończony niedawno konkurs, ale w trakcie przygotowywania projektu odkryłem jak dużo muszę się jeszcze sam nauczyć, zanim będę w stanie dzielić się wiedzą. Jednak to co udało mi się poznać i zrobić postaram się opisać w tym temacie. Proszę jednak o wyrozumiałość, tematem sztucznej inteligencji zajmuję się wyłącznie hobbistycznie i cały czas się uczę, więc z góry przepraszam za niedoskonałości opisywanego rozwiązania. Wybór platformy sprzętowej Sztuczna inteligencja nie bez powodu kojarzy się z ogromnym zapotrzebowaniem na pamięć i moc obliczeniową, rozpoznawanie mowy lub obrazu jest chyba dobrym przykładem, gdzie moc chmury wydaje się niezbędna. Okazuje się jednak, że AI można również zastosować w znacznie mniej wymagających obszarach. Jakiś czas temu na forum pojawił się opis projektu czujnika HRV: Wykrywanie bicia serca na podstawie sygnału jest jednym z przykładów, gdzie algorytmy sztucznej inteligencji mogą znaleźć zastosowanie. Ja co prawda nie jestem entuzjastą projektowania urządzeń medycznych metodami mocno hobbistycznymi, ale wspomniany artykuł zachęcił mnie do wypróbowania X-CUBE-AI do wykrywania wzroca w pewnym sygnale. Jako platformę testową wybrałem płytkę B-L475E-IOT01A, wyposażoną w mikrokontroler STM32L475 oraz całkiem sporo interesujących modułów peryferyjnych, a co najważniejsze w akcelerometr LSM6DSL. Płytka posiada ogromny potencjał, ja wykorzystam tylko mały jej fragment: port UART do komunikacji z PC, przede wszystkim do wysyłania danych akcelerometr posłuży jako źródło sygnału przycisk wykorzystam do uczenia sieci dioda LED będzie sygnalizowała wykrycie gestu Zbieranie danych treningowych Danymi źródłowymi będą pomiary z akcelerometru. Podczas uczenia, po wykonaniu gestu, który chcę nauczyć sieć będę naciskał przycisk na płytce. Dane treningowe mają więc postać 4 liczb: odczytu z akcelerometru dla osi XYZ oraz stanu przycisku. Ponieważ obraz jest wart tysiąca słów poniżej filmik z uczenia sieci: Moim celem było nauczenie sieci wykrywania dwukrotnego machnięcia płytką. W sumie nie wyszło mi to trenowanie do końca, bo wcale nie łatwo jest taki gest wielokrotnie wykonywać i się nie pomylić. Więc ostatecznie sieć ma wykrywać dwu- lub więcej- krotne pobujanie płytką. Jednokrotne, albo dwukrotne wykonane z odstępem gesty mają być ignorowane. Oczywiście można sieć nauczyć właściwie dowolnego gestu, pod warunkiem oczywiście, że sami jesteśmy w stanie ten gest wielokrotnie wykonać (i nie stracimy cierpliwości). Dane z akcelerometru odczytuję co 20ms. Z moich obliczeń wyszło, że 128 wyników, czyli 2.56s w zupełności wystarcza na wykonanie interesującego mnie gestu. Wyniki pomiarów wysyłane są przez port szeregowy Uczenie polegało na włączeniu zapisu danych do pliku oraz cierpliwym machaniu płytką oraz naciskaniu przycisku po wykonaniu uczonego gestu. W wyniku powstał plik data1.csv data1.zip Program do zbierania danych został napisany w środowisku STM32CubeIDE, dzięki temu jego kod będzie można później wykorzystać od testowania wytrenowanej sieci. Sam program jest właściwie banalny, do jego napisania wystarczy w zupełności materiał kursu STM32F4. Skoro mamy już dane treningowe, czas przystąpić do najważniejszego, czyli uczenia sieci. W następnej części postaram się opisać jak możemy wykorzystać zebrane dane. Spis treści serii artykułów: Sztuczna inteligencja na STM32, czyli przykład użycia X-CUBE-AI cz.1 Sztuczna inteligencja na STM32, czyli przykład użycia X-CUBE-AI cz.2 Sztuczna inteligencja na STM32, czyli przykład użycia X-CUBE-AI cz.3
  46. 8 punktów
    Wstęp Jeśli sięgnąłeś po ten artykuł, to prawdopodobnie jesteś programistą, a co więcej, chcesz być lepszym programistą! To bardzo dobrze, ponieważ rynek IT potrzebuje lepszych programistów, a wytwarzanie czystego kodu według przyjętych standardów programowania jest zdecydowanym krokiem w tę stronę. Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac » Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay. Czym właściwie jest czysty i dobry kod? Na to pytanie nie ma jednoznacznej odpowiedzi. Istnieje jednak zbiór pewnych reguł i narzędzi, które skutecznie wspomogą pracę programisty, a stosowane w całym zespole, polepszą jego efektywność i skuteczność. Spis treści serii artykułów: Czysty kod w praktyce - część 1 Czysty kod w praktyce - część 2 Jak więc tworzyć oprogramowanie pozbawione błędów? Podstawową regułą jest stosowanie właściwie dobranych nazw opisujących zmienne, funkcje czy struktury – jeśli kwestia ta nie jest spełniona, to żadna konwencja nie zda egzaminu. Nazwa taka powinna być odpowiedzią na wszystkie ważne pytania – w jakim celu istnieje, co robi, jakiego jest typu i jak jest używana. Jeżeli nazwa zmiennej wymaga komentarza, to znaczy, że nie ilustruje swojej intencji (dobry kod jest samokomentujący!). Przedrostki określające typy zmiennych Przykładowe przedrostki określające typy zmiennych: diGripperOpen – cyfrowy sygnał wejściowy mówiący, że chwytak jest otwarty; doGripperOpen – cyfrowy sygnał wyjściowy mówiący, aby chwytak został otwarty; aiTemperatureSensor – analogowy sygnał wejściowy czujnika temperatury; giTemperatureSensor – grupowy sygnał wejściowy czujnika temperatury (cyfrowy sygnał zakodowany na przykład na 16 bitach); nIndex – zmienna typu int zawierająca dane licznikowe; rRadius – zmienna typu real zawierająca promień; bMP3Module_On – zmienna typu bool informująca o załączeniu modułu mp3; Nie bądźmy dowcipni (ale tylko w kodzie ;d) Jeżeli nazwy są dowcipnymi określeniami, mogą być zapamiętane wyłącznie przez osoby z identycznym co autor poczuciem humoru i tylko dopóki dane określenie nie wyjdzie z mody. Nazwa zmiennych i funkcji powinny odzwierciedlać ich znaczenie. Dowcipne hasła z najnowszego standupu Rafała Paczesia zostawmy na integrację po pracy. Jedno słowo na pojęcie Należy stosować zasadę jedno słowo na jedno abstrakcyjne pojęcie i trzymać się jej w całym swoim programie. Na przykład diHumiditySensor. Nie twórzmy zgadywanek! Należy unikać używania różnych określeń do jednego celu. Powoduje to brak jednoznaczności. Czujnik zmierzchu oprogramowany w kodzie musi mieć jedną nazwę – używanie zamiennej terminologii jak czujnik optyczny, czujnik zmierzchu czy czujnik zmierzchowy powodują tylko bałagan w kodzie. Jeśli w systemie, który programujemy mamy kilka czujników, dla ich rozróżnienia nazwijmy je zgodnie z ich rolą i lokalizacją – nie stosujmy na przykład: aiHumiditySensor, aiMoistureSensor, aiWetnessSensor a na przykład aiHumiditySensor_Room, aiHumiditySensor_Kitchen, aiHumiditySensor_Bathroom. Dodajmy znaczący kontekst Jeśli mamy grupę danych, możemy posłużyć się różnymi zabiegami (w zależności od możliwości języka w jakim programujemy), aby panował w nich ład i porządek, grupując np. dane adresowe jako addrFirstName, addrLastName, addrState i tak dalej. Dzięki temu inni programiści będą wiedzieli, że zmienne te są częścią większej grupy danych. Możemy również użyć struktury, klasy – wszystko w zależności od języka programowania. Stosujmy terminologię klienta Jeśli tylko to możliwe, to do nazewnictwa zmiennych stosujemy terminologie klienta – jeśli istnieją dwa lub więcej terminów klienta na jedno pojęcie, wybieramy jedno i konsekwentnie się do tego stosujemy. Na przykład jeśli programujemy system do zarządzania produkcją u klienta, który wytwarza pakiety baterii z ogniw, używajmy zmiennych nBatteryIndex, bBatteryPresent itd. Podsumujmy dobre nazwy w kodzie przedstawiają intencje; bez mylących i fałszywych wskazówek; bez zbyt subtelnych różnic; są spójne; można je wymówić; łatwo je wyszukać; nazwy zmiennych mają rzeczowniki; nazwy funkcji mają czasowniki; dowcipne nazwy mogą nie być zrozumiane; dodajemy znaczący kontekst; nazwy zmiennych, funkcji, podprogramów w języku angielskim; zmiana nazwy na czytelniejszą to nic złego. Stosujmy dobry, konsekwentny styl Jak zapewnić tę czytelność? Po pierwsze: nazwy - zmiennych, stałych, funkcji, klas, metod, struktur itd. Każda nazwa powinna być znacząca, chyba że ma marginalne znaczenie. Jednoliterowe nazwy mogą się nadawać do zmiennych tymczasowych, takich jak np. zmienne pętli, ale tylko i wyłącznie wtedy. Nazwy powinny odzwierciedlać zastosowanie – zmienna przechowująca indeks tablicy może nazywać się „index”, a funkcja dodająca do siebie dwie liczby – „add”. Trudno się nie zgodzić, że są to o wiele czytelniejsze nazwy niż np. „dupadupacycki” czy „qwert”. Jeśli chodzi o dokumentację i komentarze, to lepiej jest używać długich nazw zmiennych (o ile dany język programowania na to pozwala), procedur, programów i funkcji, które dobrze określają ich znaczenie, zamiast używać krótkich nazw i zaopatrywać ich długim komentarzem. Poza tym długie nazwy pomagają w przypomnieniu sobie działania programu jeśli zaglądamy do niego po długiej przerwie. Jaki sens mają szczegółowe komentarze? Nie powinno się pisać kodu wyłącznie czytelnego, bądź wyłącznie optymalnego. Kod powinien być zrównoważony i wypośrodkowany – na tyle zoptymalizowany na ile nie straci na czytelności. Argument czytelności można w ogóle pominąć dopiero wtedy gdy wydajność kodu jest niewystarczająca, jednak wtedy należy taki kod opatrzyć stosownym komentarzem. Komentarze – kiedy nie mają sensu? Niewiele jest rzeczy tak pomocnych, jak dobrze umieszczony komentarz. Jednocześnie nic tak nie zaciemnia modułu, jak kilka zbyt dogmatycznych komentarzy. Nic nie jest tak szkodliwe, jak stary komentarz szerzący kłamstwa i dezinformację. Komentarze nie są szminką dla złego kodu! Jednym z często spotykanych powodów pisania komentarzy jest nieudany kod. Napisaliśmy funkcję i zauważamy, że jest źle zorganizowana. Wiemy, że jest chaotyczny. Mówimy wówczas: „Hm, będzie lepiej, jak go skomentuję”. Nie! Lepiej go poprawić! Precyzyjny i czytelny kod z małą liczbą komentarzy jest o wiele lepszy niż zabałaganiony i złożony kod z mnóstwem komentarzy. Zamiast spędzać czas na pisaniu komentarza wyjaśniającego bałagan, jaki zrobiliśmy, warto poświęcić czas na posprzątanie tego bałaganu i poprawić nasz kod - czytelny kod nie wymaga komentarza. Komentarze – kiedy mają sens? W wielu przypadkach stosowanie komentarza jest jak najbardziej słuszne. Często musimy zastosować komentarz prawny z powodu korporacyjnych standardów klienta. Czasami przydatne jest umieszczenie w komentarzu podstawowych informacji – na przykład typu czy informacji o wartości zwracanej zmiennej i wtedy warto zawrzeć taką informację w komentarzu informacyjnym. Na etapie projektowania często praktyką są komentarze TODO jako notatki zagadnień, które pozostały jeszcze „do zrobienia”. Formatowanie kodu Pamiętajmy, że kod powinien być ładnie sformatowany. Należy wybrać zbiór prostych zasad, które rządzą formatowaniem kodu, a następnie w konsekwentny sposób je stosować. Jeżeli pracujemy w zespole kilku programistów, to wszyscy jego członkowie powinni przyjąć zbiór zasad formatowania i stosować się do nich. Bardzo dobrą praktyką jest stosowanie pionowych odstępów pomiędzy segmentami kodu oraz wcięć – do poszczególnych programów w pliku, do funkcji i bloków funkcji. Z naszego programu należy również usunąć cały martwy kod – to znaczy taki, który nigdy nie jest wykorzystany (na przykład kontrolują go nigdy niespełniane warunki) lub taki, który mógł służyć jedynie do testów. Zamiast stosować magiczne liczby, użyjmy stałych nazywanych – na przykład liczba 86 400 powinna być ukryta w stałej SECONDS_PER_DAY. Jeżeli wyświetlamy 70 wierszy na stronę, to liczba 70 powinna być ukryta w stałej LINES_PER_PAGE. Spis treści serii artykułów: Czysty kod w praktyce - część 1 Czysty kod w praktyce - część 2
  47. 8 punktów
    Arduino jest taką fajną platformą, że chyba podoba się tylko osobom zainteresowanym. Dlatego też moja żona zawsze skacze z radości, gdy dokupuje sobie nowe przekaźniki, czujniki czy też „cholerne kable walające się po szafkach”. Ja natomiast uwielbiam wykonywania przedmiotów użytkowych, mających zastosowanie w życiu codziennym. Wiem, że system podlewający zioła nie jest niczym nowym i skomplikowanym, jednakże wbrew pozorom dla człowieka nie mającego wiele wspólnego z programowaniem i elektroniką, może być kłopotliwe. Tym bardziej, że informacje ułatwiające złożenie takiego zestawu są rozproszone w sieci i nie znalazłem jeszcze dobrego tutorial -a po polsku. Dlatego postaram się opisać to jak najdokładniej, aby ktoś taki jak ja mógł to zrozumieć Projekt na początku miał kilka założeń: Znalezienie doniczki, która będzie dobrze wyglądała (nie zostanie skazana na banicję przez innego mieszkańca) Doniczka musi mieć zbiorniki na wodę na tyle duże, żebym nie musiał martwić się podlewaniem ziół w kuchni, które umierały mi bardzo szybko – albo za mało wody albo odwrotnie. System podlewania ma być indywidualny dla każdego rodzaju z ziół i działać raz lub dwa dziennie. Wszystko musi być najtańsze jak się da. Projekt musi dobrze wyglądać. Znalezienie odpowiedniej doniczki, która zmieści się na szafce (i będzie dobrze wyglądać) okazał się niemożliwy do zrealizowania. Nic takiego na rynku nie ma, dlatego też musiałem zrobić ją sam. Najkorzystniejszym cenowo materiałem okazało się PCV o grubości 3 mm. Występuje w kolorze białym i czarnym, są sklepy internetowe gdzie możemy zamówić już przycięte formatki. Poniżej pokazuję projekt doniczki i rozpisane wielkości formatek. Formatki z PCV potrzebne do wykonania doniczki ze zbiornikiem wody (wymiary w mm, grubość 3 mm): 183 x 200 mm – 2 szt 400 x 180 mm – 2 szt 400 x 200 mm – 1 szt 392 x 120 mm – 3 szt Zdjęcia i projekt: Elementy kleimy najpierw kropelką/super glue lub innym klejem kontaktowym. Później uszczelniamy połączenia poprzez nakładanie kleju do rur PCV (z atestem dla instalacji wodnej) za pomocą strzykawki. Po prostu nabieramy klej i grubą warstwę wciskamy w szczeliny. Klej schnie 24h, a każdy z elementów trzeba zabezpieczyć oddzielnie, co więcej nie ma możliwości aby zrobić to już po złożeniu doniczki – nie będziemy mieć dostępu do niektórych krawędzi. Dlatego uszczelniać klejem do PCV należy etapami. Na końcu warto zrobić test szczelności, w moim przypadku robiłem 3 poprawki. Również warto przed wklejeniem tylnej ściany doniczki zamontować do niej pompki wody oraz wyprowadzić okablowanie na zewnątrz. W moim przypadku po prostu wywierciłem dziurę, którą uszczelniłem klejem do PCV. Pompki mogą być dowolne, pracujące z odpowiednim napięciem dla naszego źródła zasilania (u mnie 5V) Ponieważ doniczka z PCV nie spełnia przynajmniej dwóch punktów z założeń projektu. Musiałem wykombinować osłonkę, która będzie wodoodporna i umożliwi dolewanie wody od góry pojemnika. Padło na hexagonalną sklejkę, akurat najdroższy z elementów tego projektu. Formatki, osłonka drewniana (wymiary w mm, grubość 15 mm): 220 x 215 – 2 szt 415 x 215 – 1 szt 415 x 40 – 1 szt 415 x 190 – 1 szt 50 x 415 – 1 szt 35 x 415 – 1 szt Wszystko jest połączone na konfirmaty bo tak mi pasowało wizualnie. Można zastosować też wkręty lub po prostu ją skleić na kołki. Elementy elektroniczne: Wemos D1 mini (lub inna płytka oparta na ESP8266, np. NodeMCU) Czujnik wilgotności gleby Przekaźnik z logiką 3,3V Moduł z zasilaniem 5v i 3,3V Pompki akwarystyczne zasilane z 5V Przetwornik ADC - ADS1115 Tylna ściana doniczki specjalnie ma niepełne plecy, aby łatwo było zamontować całą elektronikę. Do sterowania wykorzystałem D1 Mini oparty na ESP8266 ze względu na wbudowane wifi. Ponieważ wykorzystuje 3 sztuki czujników wilgotności gleby, niezbędny był przetwornik ADS1115, który może odczytywać sygnał ADC dla czterech urządzeń. To ma znaczenie bo D1 Mini mógłby obsługiwać tylko jeden z nich, więc musiałbym w projekcie wykorzystać aż 4 takie urządzenia. Dodatkowo wprowadziłem zewnętrzny układ zasilania (pompki nie dawały rady przy natężeniu prądu z D1) oraz przekaźniki uruchamiające pompki w zależności od wilgotności. Sterowanie oparłem na gotowym rozwiązaniu ESP Easy z którego korzystam już przy innych czujnikach i które trochę już znam. Tak jak pisałem wcześniej, nie potrafię programować i nie to mnie kręci w tej platformie. Natomiast ESP Easy posiada web UI i ogólnie jest łatwo konfigurowalne bez znajomości języka programowania. W tym projekcie jedyne czego trzeba się nauczyć to reguły, banalnie proste do zrozumienia. Instalacja i konfiguracja jest dobrze opisana na stronie głównej projektu: https://www.letscontrolit.com/wiki/index.php/ESPEasy Tak wygląda strona z urządzeniami w ESP po odpowiedniej konfiguracji. Pierwsze trzy to czujniki wilgotności, kolejne trzy to przełączniki do sterowania przekaźnikami uruchamiającymi pompki. Jest jedna rzecz, której nie znalazłem w żadnym poradniku dotyczącym przygotowania systemu do podlewania kwiatków. Jest to kalibracja czujników. Powinno to być oczywiste i logiczne, jednak dla mnie nie było. Na początku przyjąłem, że wartości maksymalne przetwornika należy przyjąć jako referencyjne i na podstawie tego określać procent wilgotności gleby. Mój błąd był większy niż moje samozadowolenie. Dopiero po ciemnej stornie anglojęzycznego internetu znalazłem informacje o kalibracji i jej sposobie. Należy sprawdzić jego wskazania w suchej ziemi oraz w mokrej. Więc najlepszym sposobem jest wysuszenie odpowiedniej ilości w piekarniku: Zanotowaniu wskazań dla wysuszonej i ostygniętej ziemi ( przesypałem ją do słoika żeby odpowiednio wsadzić czujnik). A później powtórzeniu pomiarów dla ziemi mokrej ale bez stojącej gleby. Później wystarczy wpisać nasze wskazania w webUI ESP Easy, która ma już dwupunktową kalibrację dla przetwornika ADS1115 i wskazaniu naszych pomiarów. Przy pomiarze gdzie była sucha ziemia wpisujemy 0, przy mokrej 100. Dzięki temu mamy od razu podany wynik w procentach. Ostatnim etapem jest napisanie reguł sterujących podlewaniem. W moim przypadku codziennie o 7.00 rano dokonywany jest pomiar wilgotności gleby, jeśli wilgotność jest niższa niż 55% (lub 45% w przypadku jednego z nich) uruchamiana jest pompka na czas kilku sekund. Później odczekuje 30 sek i znowu dokonuje pomiaru. Jeśli wilgotność jest niższa, znowu dostarczana jest woda. Algorytm powtarza się łącznie 3 razy dla każdego z czujników. Wystarcza to spokojnie aby utrzymać odpowiednią wilgotność gleby. Oczywiście można było się pokusić o wprowadzenie zmiennych zależnych od odchylenia od normy. Nawet nie byłoby to bardzo trudne, jednakże całość miała być prosta. Reguły: On Clock#Time=All,07:00 do // codziennie o 7.00 rano wykoanć taskrun,1 // pomiar z zadania nr 1 if [Z1#Analog]<55 // sprawdzić czy jest niższy niż 55 pulse,14,0,20000 // jeśli jest to uruchomić pompkę na 20 sek, jeśli nie nie podejmuje zadań endif timerSet,1,30 // timer uruchominy na 30 sek aby woda mogła wsiąknąć taskrun,1 // pomiar z zadania nr 1 if [Z1#Analog]<55 // itd... pulse,14,0,10000 endif timerSet,2,30 taskrun,1 if [Z1#Analog]<55 pulse,14,0,8000 endif endon taskrun,2 if [Z2#Analog]<55 pulse,13,0,10000 endif timerSet,3,30 taskrun,2 if [Z2#Analog]<55 pulse,13,0,5000 endif timerSet,4,30 taskrun,2 if [Z2#Analog]<55 pulse,13,0,5000 endif endon taskrun,3 if [Z3#Analog]<45 pulse,12,0,10000 endif timerSet,5,30 taskrun,3 if [Z3#Analog]<45 pulse,12,0,5000 endif timerSet,6,30 taskrun,3 if [Z3#Analog]<45 pulse,12,0,5000 endif endon Pewnie kilka rzeczy zrobiłem w sposób trudniejszy niż można było to zrobić albo niezgodnie ze sztuką ale chyba to w tej całej zabawie jest najfajniejszego.
  48. 8 punktów
    Po zbudowaniu robota czworonożnego w układzie ssaka (robot "Garfield") chciałem spróbować zbudować coś w układzie gada. Zdecydowałem wykorzystać jako bazę wyjściową robota MiniKame, którego pliki STL i instrukcja złożenia dostępne są na Thingiverse. Jak łatwo zauważyć wyżej wymienione układy cechuje różnica w płaszczyźnie obrotu drugiego stopnia swobody względem pierwszego - dla ssaka jest to jedna, dwuwymiarowa płaszczyzna XY, dla gada ułożenie tych płaszczyzn jest prostopadłe - aby lepiej je zilustrować, zacznę od zdjęć: Mechanika Jak wspomniałem, wyszedłem z gotowego projektu, ale nie chciałem bezmyślnie wydrukować części, zmontować, wgrać wsadu i cieszyć się gotowym robotem. Zacząłem od zmodyfikowania głównego korpusu, ponieważ oryginał jako zasilania używa dwóch akumulatorów litowo-jonowych 18650 oraz gotowej płytki - kontrolera serwomechanizmów, a całość zamykana jest w dwuczęściowej obudowie. Zachowałem pierwotne wymiary (rozstaw otworów), dodałem szczelinę, do której wsuwany jest akumulator LiPol 2S 800mAh i otwory mocujące tradycyjnie już płytkę uniwersalną 5x7cm. Elementów nóg nie zmieniałem, dodam tylko, że są nieco trudne w drukowaniu, potrzebne są liczne podpory. Drukowane 3D są również pomarańczowe dystanse mocujące płytkę rozpoznającą głos, ale o niej za chwilę. Jeśli chodzi o napędy, ku zaskoczeniu wszystkich są to serwomechanizmy SG-90 Elektronika Jeśli ktoś czytał mój poprzedni wpis, również nie będzie zaskoczony - wykonałem własny sterownik serw, klasycznie Arduino Nano + stabilizator LM7805 - wiem, że nie jest to idealne i najlepsze rozwiązanie, ale działa Akumulator z płytką łączy JST-BEC - z przodu płytki wyprowadziłem złącze UART do płytki-modułu rozpoznającego dźwięk (jeżeli ktoś jest zainteresowany szczegółami, wiele informacji znajdzie pod hasłem "Arduino voice recognition", a sam moduł funkcjonalnością podobny jest do produktu SparkFun'a - identycznego należy szukać na chińskich portalach aukcyjnych ). Podstawową zaletą płytki jest jej prostota obsługi i działanie off-line, wadą zaś konieczność powtórzenia polecenia niekiedy kilkukrotnie. Moduł działa na zasadzie "nagrania" wzorców (maksymalnie 7, wystarczy zrobić to raz) w trybie nauki, a następnie, w trybie czuwania, po wykryciu dźwięku (moduł porównuje to, co otrzymuje mikrofon, z tym, co zapisał w pamięci, zatem rozpoznaje jedynie głos właściciela) przesyła przez UART informację typu "wykryto komunikat 1". Robot obsługuje komendy: naprzód, do tyłu, w lewo, w prawo, skacz, tańcz, pompki. Aha, jeszcze jedna sprawa - skuteczność rozpoznawania spada drastycznie przy nawet minimalnym szumie, stąd konieczność uciszenia widowni i wyłączenia wentylatora czy klimatyzacji. Niemniej moduł, który był głównym elementem mojej modyfikacji, okazał się bardzo udanym i efektownym pomysłem jak na swoją cenę (około 200PLN). Zastosowałem jeszcze jedną sztuczkę - kiedy robot chodzi, niemożliwe jest rozpoznanie komunikatu typu "stop", dlatego z przodu zamontowałem czujnik Sharp'a 4-30cm - kiedy przyłożę rękę, robot zatrzymuje się i mogę wydać kolejne polecenie Oprogramowanie W kwestii oprogramowania ponownie nie ma nic odkrywczego, moja praca polegała głównie na skomunikowaniu Arduino-moduł Voice Recognition przez UART (software'owy), autorzy udostępnili gotowe schematy i bibliotekę, która zawiera gotowe sekwencje chodu i innych ruchów (wspomniane skoki, pompki i taniec) - poniżej film Pozdrawiam, wn2001
  49. 8 punktów
    Posiadając dwa futrzaki pojawiła się potrzeba zapewnienia im odpowiedniej ilości jedzenia, szczególnie podczas weekendowych wyjazdów. Przeglądając gotowe rozwiązania stwierdziłem, że najlepiej zbudować samemu mając przy tym sporo frajdy i satysfakcji. Urządzenie zostało zbudowane w oparciu o: Raspberry Pi Zero W Kamera do Raspberry Pi Serwo L360 Uchwyt na kamerę Czujnik odległości Główne cechy urządzenia Zdalna możliwość karmienia z dowolnego miejsca na świecie podgląd z ruchomej kamery ultradźwiękowy czujnik wykrywający kota oświetlenie IR pozwalające na podgląd w nocy możliwość wgrywania i odtwarzania dowolnych plików audio opcja "Text To Speach" duży 10 litrowy zbiornik na karę detekcja pustego zbiornika harmonogram automatycznego podawania karmy Pierwszym etapem i najtrudniejszym było wykonanie niezawodnego mechanizmu podającego karmę. Przetestowałem kilka rozwiązań: podajnik ślimakowy mechanizm koszykowy zasuwa podajnik tłokowy - to rozwiązanie sprawdziło się świetnie Układ podający powstał z ogólnodostępnych elementów PCV Niżej widok od tyłu pokazujący montaż tłoka Na filmie pokazana jest idea pracy mechanizmu, były to pierwsze próby ze słabszym serwomechanizmem. Ostatecznie został wymieniony na L360, a ruch obrotowy samego serwa zastąpiony ruchem "po łuku - przód, tył" co pozwoliło zapobiec ewentualnemu zakleszczeniu się karmy. Mechanizm - film Kolejnym etapem było wykonanie dodatkowej elektroniki obsługującej: 2 serwa do kamery 1 serwo podające karmę wzmacniacz audio czujnik odbiciowy IR czujnik zbliżeniowy Dodatkową wyzwaniem było przerobienie zwykłej kamery na kamerę NoIR, w tym celu zdemontowałem układ optyczny i delikatnie usunąłem filtr podczerwony. Poniżej wygląd matrycy po zdemontowaniu tych elementów. Po ponownym zamontowaniu soczewki, kamera działała już prawidłowo przy oświetleniu podczerwonym. Poniżej widok od spodu: Główne oprogramowanie sterujące sprzętem zostało napisane w pythonie, a interfejs użytkownika w PHP, na raspberry pi jest postawiony serwer www razem z mysql, tak więc jest to mały potworek do karmienia kotów. Sterowanie odbywa się przez stronę www, co wyeliminowało pisanie dedykowanej aplikacji na każdy z systemów osobno. Na koniec kilka dodatkowych zdjęć
  50. 8 punktów
    Pojawiło się zapotrzebowanie na zegar cyfrowy, który będzie miał duże cyfry, przynajmniej 8-10cm wysokości. Dodatkowym wymaganiem było to, że cyfry nie mogą być czerwone. Wykluczyło to praktycznie wszystkie wyświetlacze 7-segmentowe. Dodatkowo cena wyświetlaczy tej wielkości jest już znaczna, koszt 4 sztuk to wydatek mniej więcej 200zł. Z tego powodu powstał pomysł realizacji takiego zegara na diodach WS2812. Po wykonaniu wstępnych projektów, zegar miał mieć cyfry wysokości ok 14cm, po dwie diody na segment, a obudowa miała zostać wykonana na drukarce 3D. Cały układ sterujący miał się znaleźć pomiędzy cyframi godzin i minut, co znacznie ograniczyło miejsce na podzespoły. Na początku układ miał bazować na Atmedze 8, jednak po dłuższych poszukiwaniach zdecydowałem się na Attiny814. W sieci nie ma zbyt wielu materiałów na temat tego procesora, jednak jego dokumentacja jest chyba jedną z najlepszych, z jakich miałem okazję do tej pory korzystać. Ponieważ nie jestem fanem ustawiania godziny poprzez przyciski, to zegar miał mieć możliwość zdalnego sterowania. Ostatecznie wybór padł na moduł Bluetooth HM-10. Do odmierzania czasu użyty został zegar DS1307 wraz z baterią CR2032. Dodatkową funkcjonalnością jest pomiar temperatury poprzez ADC i czujnik LM35. Konieczny był także pomiar jasności otoczenia, aby umożliwić automatyczne dostosowywanie się jasności diod. Wykorzystany został do tego zwykły fotorezystor. Jak się okazało, kompilowanie programów na Attiny81x przez gcc i Makefile nie jest proste i oczywiste. Przede wszystkim konieczne jest wykorzystanie gcc w wersji 8.x, oraz trzeba pobrać odpowiednie pliki nagłówkowe ze strony atmela, ponieważ avr-libc ich (jeszcze) nie dostarcza. Kolejnym wyzwaniem był programator, ponieważ Attiny814 korzysta z interfejsu UPDI, nie da się go zaprogramować poprzez USBasp. Programatory UPDI są kilkadziesiąt razy droższe od Attiny814, dlatego mocno wskazane było znalezienie jakiejś alternatywy. Okazało się nią jtag2updi, pozwalające na programowanie poprzez konwerter USB-UART oraz dowolny procesor, przy czym autor dostarcza gotowe wsady do atmegi328p (arduino). Sporą wadą takiego rozwiązania jest brak możliwości korzystania z debuggera, ale z odrobiną cierpliwości i oscyloskopem dało radę i bez niego. Diody led połączone są w dwa łańcuchy, było to konieczne ze względu na budowę zegara, a także pozwoliło zoptymalizować czas pełnego odświeżenia wyświetlacza. Ważne było, aby przeładowywać wszystkie diody w czasie mniejszym niż czas trwania jednego bajtu wysyłanego poprzez UART z prędkością 9600 baud. Wynikało to z faktu, że diody mają bardzo niewielki czas trwania jednego bitu, wynoszący ok 1.25us, przez co konieczne było wyłączenie przerwań na czas przeładowywania diod. Diody WS2812 działają na tej zasadzie, że pierwsza dioda w łańcuchu odbiera 3 bajty (24 bity) danych, a każde kolejne ignoruje i przesyła dalej. W przypadku przerwy w transmisji dłuższej niż 50us stan transmisji jest resetowany i pierwsza dioda zaczyna ponownie odbierać 3 bajty dla siebie. Aby zapewnić czasy możliwie najbardziej zbliżone do tych w dokumentacji, funkcja odświeżająca diody została napisana w assemblerze. Ponieważ nie posiadam drukarki, która umiałaby drukować dwoma kolorami jednocześnie, to cyfry składają się z czarnego szkieletu oraz białych wkładek, wydrukowanych oddzielnie. Efekt jest całkiem dobry. Aby jeszcze nieco poprawić równomierność świecenia segmentów cyfry zostały od środka pomalowane farbą akrylową na biało. Z racji tego że każdy segment składa się z dwóch diód, to możliwe jest wyświetlanie dwukolorowe, dające całkiem ciekawy efekt, jednak z braku czasu na razie zegar jest w stanie świecić tylko na jeden wybrany kolor. Na zdjęciu powyżej niektóre segmenty są pomalowane farbą od środka, stąd te ciemniejsze ramki, ostatecznie wszystkie wkładki zostały wymienione na takie bez farby. Do sterowania zegarem napisana została aplikacja w React Native, pozwalająca na ustawianie czasu, koloru oraz dodatkowych efektów. Komunikacja odbywa się poprzez wspomniany wyżej Bluetooth. Wskaźniki jasności były przydatne głównie w fazie rozwoju zegara, między innymi do testowania korekcji gamma. W aktualnej wersji zegar nie wysyła już pomiarów, ale w razie czego możliwe jest ich przywrócenie. Ostatecznie pomiar temperatury okazał się dość nieskuteczny, ponieważ termometr jest w środku obudowy, to pokazuje temperaturę wyższą niż jest w rzeczywistości. Wynika to między innymi z faktu, że podzespoły w środku nie są idealne i wydzielają trochę ciepła, na tyle dużo że temperatura zawyżona jest o 2-3°.
Tablica liderów jest ustawiona na Warszawa/GMT+02:00
×
×
  • Utwórz nowe...