Skocz do zawartości

Przeszukaj forum

Pokazywanie wyników dla tagów 'esp'.

  • Szukaj wg tagów

    Wpisz tagi, oddzielając przecinkami.
  • Szukaj wg autora

Typ zawartości


Kategorie forum

  • Elektronika i programowanie
    • Elektronika
    • Arduino, ESP
    • Mikrokontrolery
    • Raspberry Pi
    • Inne komputery jednopłytkowe
    • Układy programowalne
    • Programowanie
    • Zasilanie
  • Artykuły, projekty, DIY
    • Artykuły redakcji (blog)
    • Artykuły użytkowników
    • Projekty - roboty
    • Projekty - DIY
    • Projekty - DIY (początkujący)
    • Projekty - w budowie (worklogi)
    • Wiadomości
  • Pozostałe
    • Oprogramowanie CAD
    • Druk 3D
    • Napędy
    • Mechanika
    • Zawody/Konkursy/Wydarzenia
    • Sprzedam/Kupię/Zamienię/Praca
    • Inne
  • Ogólne
    • Ogłoszenia organizacyjne
    • Dyskusje o FORBOT.pl
    • Na luzie
    • Kosz

Szukaj wyników w...

Znajdź wyniki, które zawierają...


Data utworzenia

  • Rozpocznij

    Koniec


Ostatnia aktualizacja

  • Rozpocznij

    Koniec


Filtruj po ilości...

Data dołączenia

  • Rozpocznij

    Koniec


Grupa


Znaleziono 11 wyników

  1. Witam, zlecę projekt PCB dla Raspberry i ESP32 Devkit v1. Całość będzie wzorowana na radiu samochodowym 2 DIN. Może być pod wytrawianie może być projekt PCB do wykonania u majfrendów. Czas realizacji ok 1 miesiąca. Płatność przelewem, kontakt przez PW, hangouts lub mic327 at gmail dot com projekt.pdf
  2. O czymś podobnym myślałem praktycznie od chwili kupna drukarki. I pewnie dalej bym myślał, gdyby nie projekt na Majsterkowie, opisujący podobną (prostszą) konstrukcję. A i tak przymierzałem się do tego jak pies do jeża, zawsze cos mi przeszkadzało (a to nie potrafiłem rozwiązać problemu zasilania, a to miałem coś pilniejszego do roboty, a to nie miałem jakiegoś tam elementu...). Ale po zrobieniu mojej przystawki do OctoPrinta i (całkiem udanych) próbach druku w wielu kolorach - a co się z tym wiąże koniecznością ręcznej zmiany filamentu w odpowiednim momencie - potrzeba stała się raczej pilna. Zacząłem więc od sprecyzowania założeń. Monitorek miał przede wszystkim wyświetlać aktualne dane na temat wydruku (temperatury, stan drukarki, postęp). Jako że główną jego funkcją miało być zwrócenie uwagi na coś ważnego (np. konieczność zmiany filamentu czy wychłodzenie stołu wystarczające do zdjęcia wydruku) w czasie, kiedy byłem zajęty innymi Wielce Ważnymi Rzeczami (np. oglądaniem najnowszego odcinka przygód bohaterskiego Hannibala Smitha czy innego McGyvera) sygnalizacja powinna być głosowa. Jednocześnie najważniejsze parametry (temperatura i postęp) powinny być wyświetlane w czytelny sposób nawet dla krótkowidza bez okularów - czyli żadne nawet największe cyferki, jakiś pasek postępu w kontrastowych kolorach albo jakiś inny czytelny glif. Zasilanie akumulatorowe (na stoliku przy telewizorze nie mam jak podłączyć zasilacza), z możliwością podłączenia ładowarki. Nadałem więc urządzeniu roboczą nazwę OctoMon, wymęczyłem na forum że ktoś mi wreszcie wyoślił temat ładowarki (dzięki @marek1707!) i zabrałem się do konkretnego projektowania. Miałem już wyświetlacz, moduł ESP8266E i parę innych potrzebnych drobiazgów. Początkowo chciałem ESP umieścić na płytce podłączanej bezpośrednio do pinów wyświetlacza - niestety, jakbym ścieżek nie prowadził i tak jednostronna płytka wychodziła mi za duża. Postanowiłem więc dać sobie spokój, zastosować adapter i użyć po prostu płytki uniwersalnej. Ponieważ tego modelu wyświetlacza już uzywałem, eksperymenty z dźwiękiem też się powiodły (przynajmniej w zakresie wystarczającym do uruchomienia gadacza) - mogłem mieć pewność, że od strony programu nie będę już miał żadnych niespodzianek. Postanowiłem więc zaprojektować całą (niezbyt skomplikowaną zresztą) elektronikę. Jako że akurat w Botlandzie pojawił się moduł MAX9837A postanowiłem go wykorzystać jako DAC i wzmacniacz dźwięku. Niestety nie zdał egzaminu... ale o tym później. Zasilanie rozwiązałem w najprostszy chyba z możliwych sposób. Akumulator połączony z ładowarką, do tego przetwornica MT3608 ustawiona na 5V. Wyświetlacz i DAC zasilane bezpośrednio z 5V, ESP przez stabilizator LM1117, połączony z resztą świata jak na schemacie poniżej. Teoretycznie powinno to działać... ...No i już na wstępie pojawił się problem. Podłączony bezpośrednio (znaczy się kabelkami) do ESP i zasilany z USB moduł dźwiękowy pokazał co potrafi - czyli jak mi zepsuć dobry humor. Z powodów niewiadomych raz działał raz nie... a do tego owo niedziałanie powodowane było chyba fanaberiami motylków w Brazylii albo aktualna pogodą na Marsie. Doszedłem do wniosku, że USB to niespecjalnie dobry sposób zasilania, po prowizorycznym podłączeniu jakichś uczciwych 5V wydawało mi się, że działa. Postanowiłem więc sprawdzić wszystko później już na gotowym układzie. Może się to komuś wydać dziwaczne i ryzykowne... ale miałem w odwodzie sprawdzone rozwiązanie które co prawda dawało niższą jakość dźwięku, ale za to nie okazywało żadnych fanaberii Reszta elektroniki to praktycznie tylko połączenie tego wszystkiego do kupy - mogłem się więc zabrać za projekt obudowy. Nie chciałem się bawić w wymyślanie jakichś skomplikowanych kształtów, a więc obudowa została wydrukowana w kilku częściach i skręcona śrubkami M2. Początkowo urządzenie miało mieć jeden klawisz, ale okazało się, że mam wolne dwa piny GPIO, mogłem więc połączyć dwa. Płytę czołową postanowiłem umieścić pod kątem ze względu na wyświetlacz (który nie lubi jak patrzy się na niego lekko z boku, masz się gapić prosto i już!). Oprócz wyświetlacza miały tam się znaleźć głośnik i klawisze. W sumie więc górna część obudowy wygląda na projekcie tak: Otwory obok głośnika są przelotowe - od zewnątrz jest do nich przykręcona kratka mocująca i osłaniająca głośnik. Mocowanie klawiszy jest dopasowane do ratra płytki uniwersalnej (podobnie zresztą, jak mocowania płytki pod ESP8266). Cała reszta elektroniki oprócz DAC-a została umieszczona w dolnej części obudowy: Oprócz koszyka na akumulator są tam mocowania dla ładowarki, przetwornicy i małej płytki pod ESP. Po złożeniu cały układ wygląda tak: Niestety - po złożeniu wszystkiego w całość okazało się, że DAC nie bardzo chce ze mną współpracować. Co prawda wyczyniał swoje hece to dużo rzadziej, ale jednak. Postanowiłem więc wypróbować inny układ: wzmacniacz (wykorzystana połowa układu) oraz prosty filtr: Okazało się, że działa to całkiem znośnie - prawdopodobnie potrzebna by była jeszcze dodatkowa filtracja na zasilaniu (w głośniku słychać czasem ciche trzaski) ale bez tego już mogłem się obejść. Po złożeniu całość wygląda tak: I tu uwaga: ponieważ wątpię, aby ktoś kto chciałby zrobić to urządzonko miał dokładnie takie same elementy jak ja i identycznie spaczone poczucie estetyki - nie zamieszczam STL-i tylko plik dla OpenSCAD-a. Są w nim zawarte wymiary poszczególnych elementów i może być przydatny. No i kilka słów o programie. Program łączy się z serwerem OctoPrint i okresowo odpytuje o stan drukarki i (w przypadku gdy jest to drukowanie) o postęp. Oprócz podstawowych stanów sygnalizowanych przez serwer odróżniane są: Offline - drukarka jest wyłączona lub serwer nie odpowiada Rozgrzewanie stołu Rozgrzewanie dyszy Studzenie stołu - gdy po zakończeniu drukowania temperatura jest nie niższa niż 30°. Wciśnięcie pierwszego klawisza w trybie pauzy powoduje, że monitorek przestanie się odzywać. Bez tego co chwila będzie krzyczał że masz zmienić filament. W trybie studzenia powoduje przejście w tryb bezczynności. Wciśnięcie drugiego klawisza spowoduje podanie głosowo godziny. Dłuższe wciśnięcie pozwala na zmianę gadatliwości programu. Serwer WWW pozwala na zmianę wszystkich ważnych parametrów w dowolnej chwili. W trybie "drukowanie" wyświetlane są informacje o temperaturze dyszy i stołu, postępie w procentach oraz czasu dotychczasowanego i prognozowanego. Dodatkowo wyświetlane są: Adres IP monitora Bieżąca godzina Stan naładowania akumulatora Poziom gadatliwości (tylko wydarzenia/postęp/postęp i pozostały czas) Włączenie OTA Siła sygnału WiFi W trybie Offline monitor zachowuje się jak zegarek - wyświetla bieżące godzinę i datę Jeśli w czasie resetu urządzenia przytrzymamy pierwszy klawisz, startuje ono w trybie AccessPoint. Pod podanym adresem zgłasza się serwer WWW, gdzie można zapisać wszystkie potrzebne parametry. Jeśli w czasie resetu urządzenia przytrzymany drugi klawisz, startuje ono w trybie awaryjnym. W tym trybie nie będzie działać nic oprócz OTA. Przydatne, jeśli coś tak naknocimy w programie że nie będziemy mieli dostępu do OTA w normalnym trybie. Program został napisany z pomocą Arduino IDE. Biblioteka syntezy mowy jest na githubie. Pozostałe biblioteki instalowane były "po bożemu" poprzez managera bibliotek. Syntezator mowy to zwykły syntezator formantowy (użyłem w większości oryginalnego kodu D. Klatta z początku lat 80-tych), dostosowany kiedyś przeze mnie do języka polskiego. Dostosowanie nie jest może najlepsze - ale i syntezator Klatta nie jest mistrzem dykcji Kalibrację miernika poziomu akululatora należy przeprowadzić włączając opcję DEBUG w Octomon.h i podając w pliku wifi.cpp adres i port , na którym będziemy odbierać komunikaty UDP. Należy do wejścia przetwornicy podłączyć woltomierz, odczytać komunikat "Volts=..." i w pliku "display.cpp" w funkcji displayBattery() w linijce: ivolt = ivolt * 413 / 753; podstawić właściwe wartości (czyli napięcie akumulatora w setnych wolta oraz wartość odczytaną a przetwornika A/C). W moim przypadku jak widać woltomierz podał 4.13V a przetwornik zinterpretował to jako wartość 753 Aby program działał, należy w Arduino IDE ustawić zegar 160 MHz, tryb pamięci QIO oraz częstotliwość Flash 80 MHz. Dołączony programik bmconvert.py pozwala na zapisanie jako tablicę w C obrazka PNG. Obrazek powinien być zapisany w trybie indeksowanej palety kolorów bez przezroczystości, będzie przetworzony na skompresowaną w RLE tablicę, a do jego wyświetlenia należy użyć funkcji drawBitMap() z pliku display.cpp (lub analogicznej). Sprawdzony na Linuksie, ale powinien działać na wszystkim gdzie się da zainstalować Pythona 2.7 i PIL. Urządzenia używam od jakichś dwóch tygodni, na razie jest bardzo przydatne. octomon.zip
  3. Proponuję rozpocząć kolejną "luźną" dyskusję. Arduino i Raspberry Pi zdecydowanie zrewolucjonizowały elektronikę w kontekście hobbystów i twórców, ale oczywiście znalazły one również swoje miejsce przy bardziej profesjonalnych zastosowaniach. Następnym przełomem, który się wydarzył (a właściwie trwa teraz) była popularyzacja ESP, czyli taniego, niezwykle wydajnego układu, który pozwala tworzyć urządzenia IoT. Moje pytanie brzmi więc następująco: jakie cechy Waszym zdaniem, będzie miała kolejna platforma, która przebojem wejdzie na rynek? Czego według Was brakuje? Większej wydajności, energooszczędności, a może jeszcze niższej ceny? Jak wiadomo przełomem będą np. komputery kwantowe, ale nie o takie rzeczy mi teraz chodzi. Pytam o realne (na dzisiejsze czasy) platformy, które mogłyby łatwo zagościć w warsztacie każdego majsterkowicza. Czego brakuje Wam w aktualnie popularnych platformach?
  4. dkradke

    IoT - panel sterujący

    Parę lat temu podczas remontu u rodziców postanowiłem usprawnić im parę rzeczy w mieszkaniu. Stworzyłem sterownik, który integrował ze sobą sterowanie oświetleniem i ogrzewaniem. Pomimo prostej obsługi nie przewidziałem tego, że moi rodzice będą bali się tego używać, myśleli że coś zepsują... niestety są na bakier z elektroniką. Tak powstała druga wersja, która jest dla nich absolutnie bezobsługowa w kwestii ustawień czy sterowania ogrzewaniem. Podstawowe cechy komunikacja Wifi integracja z Firebase zdalny dostęp z dowolnego miejsca na świecie Odtwarzanie komunikatów głosowych sterowanie za pomocą asystenta Google pilot radiowy 2,4GHz sterowanie oświetleniem sterowanie ogrzewaniem dwupunktowy pomiar temperatury detekcja otwartego okna automatyczne aktualizowanie czasu z serwera NTP łatwe dokładanie bezprzewodowych czujników, np. zalania duży i czytelny wyświetlacz Tym razem uwzględniłem obawy rodziców i w każdej chwili mam dostęp do wszystkich ustawień. Dla niecierpliwych filmik (polecam włączyć dźwięk) Główny moduł Całe sterowanie oparłem o układ ESP12. Jest to układ o bardzo dużych zasobach z wbudowanym wifi. Niestety ma on bardzo mało wyprowadzeń, dlatego aby obsłużyć wszystkie dodatkowe elementy takie jak: LCD ST7565 DS18B20 Enkoder Trzy przyciski Kilka wyjść Moduł MP3 (JQ8400-FL) RFM73 Wykorzystałem 16 bitowy ekspander na SPI MCP23S17. Wymagało to dostosowania kilku bibliotek np. LCD czy enkodera, aby zamiast pinów ESP używały MCP23S17. To było największym wyzwaniem dla mnie, aby zrealizować obsługę trzech układów SPI, gdzie dwa z nich były częściowo sterowane poprzez pierwszy czyli MCP23S17. Dodatkowo przydzielanie czasu na poszczególny element trzeba było odpowiednio rozdzielić, aby obsługa enkodera nie gubiła kroków. Zdalny dostęp Sterownik działa jako klient w sieci wifi, nie chciałem przekierowywać portów na routerze, ani stawiać dodatkowego VPNa. Wykorzystałam tutaj RealTime Database od Google czyli Firebase. Jest darmowe, względnie proste w obsłudze wprost z układu ESP, a dostęp do Firebase posiada każdy kto ma konto w Google. Wykorzystanie tego mechanizmu daje nam bardzo duże możliwości. Możemy hostować tam własną stronę, która będzie naszym frontendem, możemy wykorzystać “cloud functions”, które są praktycznie zasobami node.js, jest to bardzo fajne, bo możemy mieć własny serwer node.js w chmurze. Mając cloud functions i bazę danych, możemy z łatwością podpiąć pod to inne usługi, np. asystenta Google, który pozwoli sterować urządzeniem naturalną mową a nie nagranymi wcześniej próbkami komend. Pod nasz system możemy podpiąć również IFTTT (if this then that) i jeszcze bardziej zautomatyzować obsługę urządzenia. ESP co kilka sekund odczytuje bazę danych z Firebase i sprawdza czy stan jakiegoś elementu uległ zmianie, jeśli tak to znaczy, że zdalnie zmieniliśmy parametry pracy. W drugą stronę, jeśli to sterownik lokalnie zmieni jakąś wartość to od razu aktualizuje ją w Firebase. Asystent Google i komunikaty głosowe Rodzice swoje lata już mają i pamięć nie ta, dlatego dołożyłem system komunikatów głosowych. Pilot, który będzie zawsze pod ręką tuż obok pilota od TV, będzie (czeka na obudowę) jasno opisany i wystarczy nacisnąć jeden przycisk a sterownik powie jaka jest temperatura w mieszkaniu, jaka jest na zewnątrz, czy ogrzewanie aktualnie pracuje albo ile razy dzisiaj było włączane. Pomyślałem, że fajnym dodatkiem będzie wgranie również instrukcji obsługi, gdzie sterownik powie do czego służą poszczególne przyciski. Ze sterownikiem można rozmawiać w sposób naturalny z wykorzystaniem asystenta Google, nie musimy być nawet w pobliżu sterownika, mówimy do telefonu czy komputera znajdując się w dowolnym miejscu na świecie. Sam Google asystent nie steruje bezpośrednio urządzeniem, z wykorzystaniem mechanizmu Dialogflow, który bazuje na machine learning zmienia parametry pracy w Firebase, a urządzenie docelowe pobiera je i wykonuje. Zależności między komponentami pokazałem na poniższej grafice. Moduł radiowy 2,4GHz W sterowniku znajduje się RFM73, jest to niewielki układ radiowy wykorzystany tutaj jako pilot, we wcześniejszej wersji tradycyjny pilot na podczerwień kiepsko się sprawdzał, nie zawsze było się w polu widzenia odbiornika. Dodatkowe czujniki Posiadając na pokładzie układ RFM73 możemy dowolnie rozbudować system o dodatkowe czujniki, np. czujnik zalania w łazience, czujnik oświetlenia czy dodatkowe czujniki temperatury. Dokładanie dodatkowych czujników nie wiąże się z przeprogramowaniem głównego sterownika, ponieważ wszystkie reguły obsługi możemy umieścić w Firebase, a sterownik je pobierze. Poniżej kilka fotek, a jako trzecią rękę polecam taki stojak:
  5. Dodając krok po kroku trochę automatyki w mieszkaniu powstał projekt i realizacja sterownika rolet zewnętrznych. Główne cechy urządzenia: obsługa 7 rolet zdalny dostęp z dowolnego miejsca na świecie sterowanie przez Wifi sterowanie przez Bluetooth sterowanie przez sieć CAN automatyczny pomiar czasu pracy poszczególnych rolet harmonogram otwierania/zamykania rolet sterowanie grupowe tworzenie scen pobieranie aktualnego czasu z serwera NTP Sterownik został podzielony na dwie części, pierwsza to płytka z przekaźnikami i zasilaniem, druga płytka to układ sterowania wraz z modułami komunikacyjnymi. Główne elementy wykorzystane w sterowniku to: STM32F103C8T6 jako moduł Bluepill Moduł Wifi ESP-12 Bluetooth HC-05 Największym wyzwanie okazało się wykrywanie zakończenia pracy rolety. Było to niezbędne do automatycznego pomiaru czasu pracy, które jest wykorzystywane do określania pozycji pośrednich. Na początku testowałem wykrywanie prądu z wykorzystaniem modułu ACS711, ale niewielki prąd pobierany przez roletę podczas pracy powodował niestabilne pomiary z układu ACS711. Drugim pomysłem było wykorzystanie przekładników prądowych. Pomiary były stabilne, ale to rozwiązanie odpadło ze względu na fizyczne rozmiary takich przekładników, potrzebowałem użyć ich aż siedem sztuk. Ostatecznie zastosowałem rozwiązanie polegające na spadku napięcia na diodach, które aktywuje transoptor PC814. Rolety które posiadam mają wewnętrzne zabezpieczenie przed podaniem napięcia na oba uzwojenia silnika (góra, dół), jednak tak zaprojektowałem układ, aby sprzętowo nie było to możliwe. Pokazane jest to na poniższym rysunku. Program został napisany w C++ z wykorzystanie Arduino Core. ESP-12 pełni rolę konwertera komunikacyjnego, od strony wifi oferuje RestApi, konwertuje otrzymane wiadomości/zapytania na komunikację uart i wysyła do głównego procesora STM32. Na drugim porcie uart w STM32 jest podobna komunikacja z wykorzystaniem modułu bluetooth. Moduł BT aktualnie służy do przeglądania bieżących logów. Ponadto moduł posiada opcję komunikacji z wykorzystaniem sieci CAN, jestem bardziej fanem rozwiązań przewodowych tam gdzie jest to możliwe. Jak w mieszkaniu pojawi się więcej elementów automatyki to będę chciał całość przepiąć na sieć CAN zamiast Wifi. Sterowanie modułem odbywa się jak wspomniałem wyżej zapytaniami REST, na Banana Pro posiadam domowy serwer www, dołożyłem do niego prostą stronę w PHP, która pozwala w wygodny sposób wysyłać zapytania do sterownika. Do połączenia się ze sterownikiem poza domową siecią wykorzystuje OpenVPNa.
  6. Cześć. Dzisiaj chciałbym opisać mój moduł sprawdzania jakości powietrza. Czujnik postanowiłem zbudować z czystej ciekawości, jakim to powietrzem oddychamy w zimie. Wyniki niestety są zatrważające. Ale po kolei. Zastosowałem u w tym urządzeniu następujące elementy: czujnik PMS5003, nodeMCU wraz z podstawką, wyświetlacz LCD 16x2 , przetwornicę zasilającą, moduł przekaźników; czujnik DHT11, gniazdo USB, gniazdo zasilania, wentylator, serwomechanizmy, moduł RTC, i kilka drobiazgów, rurek, przewodów.... Czujnik został zbudowany jako osobne urządzenie ale połączone z moim "systemem" automatyki domowej. Urządzenie aktualnie jest zamontowane na półeczce na ścianie, przez którą są przeprowadzone przewody powietrzne dolotowy z zewnątrz i wylotowy. Takie rozwiązanie jest spowodowane tym, że zastosowany czujnik, zresztą podobnie jak wszystkie tego typu, przekłamuje wyniki w warunkach wysokiej wilgotności powietrza. Zamysł był więc taki, by obudowa z czujnikiem znajdowała się w ogrzewanym pomieszczeniu, a powietrze potrzebne do pomiaru urządzenie pobierało sobie samo z zewnątrz, po czym po samoistnym nagrzaniu w komorze czujnika, został wykonany pomiar i następnie wymiana powietrza w komorze pomiarowej urządzenia. Jak to wygląda w praktyce. Obudowa jest podzielona na dwie komory, w przedniej znajduje się cała elektronika, zasilanie, wyświetlacz, ta część jest wentylowana pprzez otwory w obudowie. Zaś w tylnej szczelnie odgrodzonej komorze znajduje się czujnik PMS i moduł przekaźnika. Do tej tylnej komory, doprowadzone są ww. przewody powietrzne, a w kanale dolotowym zamontowany jest wentylator. Dodatkowo za ścianą na tych kanałach zamontowane są zawory odcinające przepływ powietrza sterowane serwomechanizmami. Zawory te mają na celu uniemożliwienie samoczynnej cyrkulacji powietrza w kanałach, w czasie np. silnych wiatrów, a tym samym również wychładzania i komory czujnika i pomieszczenia w którym zamontowany jest wylot powietrza. Zasada działania. Cały proces zaczyna się od wykonaniu pomiaru przez czujnik DHT11, jeśli wilgotność powietrza jest niższa niż zadana(np.75%), zostaje wybudzony czujnik, pracuje przez 30 sekund, a następnie jest wykonywany pomiar. Po wykonaniu pomiaru czujnik jest usypiany, a do modułu zaworów odcinających zostaje podane napięcie. W następnym kroku serwomechanizmy otwierają dolot, wylot i zostaje włączony wentylator na minutę, by wymienić powietrze w komorze. Po minucie wyłączamy wentylator, zamykamy kanały i odcinamy zasialnie serw. Wszystkie te czynności są anonsowane na wyswietlaczu. Po całym tym etapie, wyświetlacz przechodzi w tryb standardowej pracy, t.j. naprzemiennego wyświetlania parametrów ostatniego odczytu i godziny oraz daty. W tym czasie co dwie minuty czujnik DHT11 dokonuje pomiarów. Jednakże dopiero po 10 minutach od uśpienia czujnika instrukcja warunkowa sprawdza czy wilgotność jest na odpowiednim poziomie i jeśli tak to wybudzamy czujnik i cały cykl zaczyna się od nowa. W urządzeniu jest wgrany szkic dzięki któremu nodeMCU wysyła dane na serwer Blynka, dzięki czemu mogę mieć dostęp do tych danych 24h/allOverThe World Udało mi się też po raz pierwszy zawrzeć w tym szkicu funkcjonalność OTA, czyli mam możliwość wgrywania oprogamowania poprzez wi-fi. Wprawdzie w czasie wstępnych prac zamontowałem z boku urządzenia gniazdo USB służące właśnie programowaniu, to dzięki OTA stało sie ono zbędne(?). Pomimo tego, że cała obudowa jest zamontowana do wspomnianych kanałów powietrznych, sposób przyłączenia (na wtyk), powoduje, że czujnik ten stał się również przenośny i może służyć do badania jakości powietrza w różnych dziwnych miejscach, w pracy, w kotłowni.... Kilka zdjęć: Oczywiście jest też filmik: Dziękuję za uwagę, pozdrawiam wszystkich forumowiczów Forbota którzy przyczynili się do powstania tego czujnika
  7. atlantis86

    Jeszcze jeden zegar nixie

    Lampy nixie to chyba najczęściej powracający temat wśród amatorskich projektów elektronicznych. Myśl o skonstruowaniu zegara z takim wyświetlaczem chodziła mi po głowie już wiele lat temu, w tym celu zaopatrzyłem się w zestaw lamp IN-14. Niestety z powodu braku czasu i dużej ilości projektów o wyższym priorytecie zadanie to ciągle było odkładane na później. Może to i lepiej, bo w międzyczasie miłośnicy amatorskiej elektroniki zyskali dostęp do całkiem ciekawych elementów, które mogłem wykorzystać w projekcie. Prezentowany zegar powstał w 2017 roku. Jego głównym elementem jest mikrokontroler Atmega644, który wykonuje wszystkie operacje związane z odmierzaniem czasu i obsługą multipleksowanego wyświetlacza. Dodatkowo zegar został wyposażony w moduł WiFi z układem ESP8266, pracujący pod kontrolą własnego programu. Zadaniem modułu jest cykliczne sprawdzanie czasu na serwerze NTP i korygowanie ustawień lokalnego RTC. Urządzenie posiada też układ scalony FT232, dodający możliwość konfiguracji przez USB. Stałe napięcie około 180V jest generowane za pomocą przetwornicy boost na układzie MC34063A. Oprogramowanie zegara zostało wyposażone w funkcję automatycznego wykrywania czasu letniego i zimowego. Na płycie czołowej znajduje się przełącznik umożliwiający włączenie trybu, w którym wyświetlany jest czas UTC - funkcja ta została dodana w związku z moimi radioamatorskimi i krótkofalarskimi zainteresowaniami. Konstrukcja została zamontowana wewnątrz obudowy ze sklejki wycinanej laserowo. Fizycznie urządzenie składa się z dwóch osobnych płyt, Jedna z nich mieści zestaw lamp nixie, druga elektronikę sterującą.
  8. Witam, Od dłuższego czasu próbuje rozwiązać problem z modułem ESP-01 podpiętym pod Arduino Mega. Mianowicie kiedy wysyłam dane przez serwer MQTT do ESP np. z telefonu i wyślę tych danych zbyt dużo w czasie od 1 do 5 sekund, to cały program przestaje reagować na kolejne dane przez najbliższe 20-40 sekund lub następuje ponowne uruchomienie Arduino. Program nie jest jakoś super skomplikowany (ponieważ służył mi tylko do testów ESP) więc myślę, że nie będzie on trudny do zrozumienia. Moduł jest podpięty do Arduino przez konwerter poziomów logicznych. Myślę, że problemem nie będzie połączenie, ponieważ wysyłanie danych działa bez problemu, a kiedy dane są wysyłane do ESP w odstępach 1-2 s to wszystko działa bez problemu. Kod: #include <LiquidCrystal.h> #include <WiFiEsp.h> #include <WiFiEspClient.h> #include <WiFiEspUdp.h> #include <PubSubClient.h> #include <SPI.h> char ssid[] = "My-WiFi"; // your network SSID (name) char pass[] = "1234567890"; // your network password char server[] = "broker.hivemq.com"; // your network password int status = WL_IDLE_STATUS; // the Wifi radio's status // Initialize the Ethernet client object WiFiEspClient espClient; PubSubClient client(espClient); LiquidCrystal lcd(7, 6, 5, 4, 3, 2); void setup() { lcd.begin(16, 2); lcd.clear(); lcd.print("Loading: "); delay(1500); lcd.clear(); // initialize serial for debugging Serial.begin(115200); // initialize serial for ESP module Serial1.begin(115200); // initialize ESP module lcd.setCursor(0, 0); lcd.print("ESP initialize "); lcd.setCursor(0, 1); lcd.print("40%"); WiFi.init(&Serial1); lcd.setCursor(0, 0); lcd.print("Connect to WiFi "); lcd.setCursor(0, 1); lcd.print("65%"); // check for the presence of the shield if (WiFi.status() == WL_NO_SHIELD) { Serial.println("WiFi shield not present"); // don't continue while (true); } // attempt to connect to WiFi network while (status != WL_CONNECTED) { Serial.print("Attempting to connect to WPA SSID: "); Serial.println(ssid); // Connect to WPA/WPA2 network status = WiFi.begin(ssid, pass); } lcd.setCursor(0, 0); lcd.print("Connect to MQTT "); lcd.setCursor(0, 1); lcd.print("80%"); Serial.println("You're connected to the network"); //connect to MQTT server client.setServer(server , 1883); client.setCallback(callback); lcd.setCursor(0, 0); lcd.print("Connect to MQTT "); lcd.setCursor(0, 1); lcd.print("100%"); delay(400); lcd.clear(); } //print any message received for subscribed topic void callback(char* topic, byte* payload, unsigned int length) { payload[length] = '\0'; String value = String((char*)payload); Serial.println(value); lcd.clear(); lcd.print(value); if (value == "State" || value == "state") { lcd.clear(); lcd.print("ESP is ready"); client.publish("km/esp/data", "ESP is still ready"); } else { client.publish("km/esp/data", "OK"); } } void loop() { if (!client.connected()) { reconnect(); } client.loop(); delay(250); } void reconnect() { // Loop until we're reconnected while (!client.connected()) { Serial.print("Attempting connection "); // Attempt to connect, just a name to identify the client if (client.connect("AMega")) { Serial.println("connected"); // Once connected, publish an announcement… client.publish("km/esp/data","ESP is ready"); // … and resubscribe client.subscribe("km/esp/input", 0); } else { Serial.print("failed"); Serial.print(client.state()); Serial.println(" try again in 5 seconds"); // Wait 5 seconds before retrying delay(5000); } } } Z góry dziękuje za pomoc.
  9. Hej, Przez przypadek podłączyłem ESP z napięciem 5V z płytki Arduino. Wiem, że powinno to być 3.3V. Wcześniej układ działał, teraz dostaje takie błędy podczas próby wgrania: espcomm_send_command: sending command header espcomm_send_command: sending command payload read 0, requested 1 warning: espcomm_sync failed error: espcomm_open failed error: espcomm_upload_mem failed Po podłączeniu ESP mruga niebieska dioda i działa wchodzenie w tryb upload. Ale to tyle....Czy układ jest zepsuty?
  10. deshipu

    uBob

    Ten robot był eksperymentem w kilku dziedzinach jednocześnie. Po pierwsze, jest to mój pierwszy skończony dwunożny robot kroczący. Po drugie, jako mózgu użyłem nowego wówczas układu ESP8266. Po trzecie, po raz pierwszy użyłem sub-micro-serwa zasilane napięciem 3V. Na koniec, nawet obudowa była eksperymentem, sprawdzającym jak dobrze plastik ze starych opakowań nadaje się do tego celu. Później dla tego własnie robota wytrawiłem swoją pierwszą płytkę drukowaną. Ostatnim eksperymentem, który się niestety już nie powiódł, było użycie optycznego cyfrowego czujnika odległości, który z jakiegoś powodu okazał się nie działać. Ale do rzeczy. Robot ten bardzo mocno bazuje na projekcie znanym ogólnie jako "Bob" (http://www.robotrebels.org/index.php?topic=11.0). W zasadzie jest to moje podejście do zrobienia jego miniaturoej, pomniejszonej wersji. Niestety nie posiadałem dostępu do drukarki 3D, żeby zrobić obudowę i szkielet, zatem podszedłem do tematu tak jak zwykle -- zlepiając ze sobą losowe części i lutując wszystko "na pająka". Wyszło mi coś takiego: Dużym wyzwaniem były gniazdka do serw, bo ich rozstaw nóżek to 1.27mm. Moduł ESP8266, którego użyłem, ma rozstaw padów 2mm, więc już trochę łatwiej. Diody świecące dodałem, żeby widzieć czy robot jest włączony czy nie. Stopy są wycięte ze starej karty kredytowej. Gumka recepturka przytrzymuje baterię. Zadowolony z tej konstrukcji, postanowiłem zrobić do niej obudowę ze starego opakowania (tak zwanego "blistera") po gamepadzie. Wyciąłem z niego kawałek w miarę płaskiego plastiku, narysowałem na nim siatkę pudełka, wyciąłem i skleiłem Kropelką. Po dopasowaniu do robota powycinałem otwory. Potem dokleiłem trochę kawałków starych zabawek do ozdoby... Z czasem wymieniłem stopy na wykonane z takiego samego materiału jak obudowa i dodałem robotowi moduł ładowania baterii (jest to pojedyncze LiPo, więc dość łatwo je ładować). Do programowania wykorzystałem powstający wówczas dopiero firmware NodeMCU dla ESP8266, który pozwolił mi oskryptować wszystko w Lua. Było to bardzo wygodne, gdyż mogłem na żywo testować kod w konsoli, na którą po prostu łączyłem się telnetem. Przy okazji próby używania PWM do kontrolowania serwomechanizmów, znalazłem dwa błędu w NodeMCU, które zostały szybko poprawione (https://github.com/nodemcu/nodemcu-firmware/issues?q=is%3Aissue+author%3Adeshipu+is%3Aclosed). Jest tu zastosowany jeden trik, gdyż NodeMCU obsługuje co najwyżej 3 kanały PWM (zrobili to do kontroli diody RGB), a ten robot ma 4 serwomechanizmy. Otóż dwa z tych serwomechanizmów sterowane są tym samym sygnałem i zawsze mają tę samą pozycję -- to nie przeszkadza przy tym sposobie chodzenia, jaki ma ten robot: W tym stanie robot postał na półce jakiś rok -- zabrałem go na dwie konferencje, żeby się pochwalić. Niestety, po powrocie z ostatniej przestał działać -- urwał się jeden z padów na ESP8266, do których przylutowane były druciki. Niestety nie dało się tego naprawić bez praktycznego przebudowania całego robota, więc robot sobie leżał i czekał na lepsze czasy. Lepsze czasu nadeszły, gdy kupiłem odczynniki do trawienia płytek i postanowiłem spróbować w tym swoich sił. Zrobiłem płytkę dla naszego bohatera: A w zasadzie całą serię płytek, gdyż nie udało mi się jej poprawnie wytrawić za pierwszym razem: W końcu udało się zrobić coś, co miało większość potrzebnych połączeń i wywiercić w tym otwory, łamiąc przy tym tylko trzy wiertła. Po zlutowaniu całości, tak jak wspomniałem wcześniej, czujnik odległości okazał się nie działać, ale robot nadal chodzi i do tego teraz może mrugać oczami: Być może jeszcze kiedyś wrócę do tego projektu i spróbuję uruchomić ten czujnik, albo użyć innego. Mógłbym też znacznie rozszerzyć jego repertuar zachowań, na przykłąd nauczyć go tańczyć. Ogólnie z robota jestem bardzo zadowolony, dostarczył mi naprawdę wiele zabawy przy budowie i nauczył przy tym dużo, choć jest to chyba projekt przy którym jak dotychczas napsułem najwięcej komponentów (w sumie dwie płytki esp8266, jeden sensor optyczny, który zniszczyłem przy lutowaniu, milion nieudanych płytek, wiertełka). __________ Komentarz dodany przez: Treker 1 - Poprawiłem temat, w którym nie działał encja µ. 2 - Typ robota należy wybierać z listy rozwijanej zamiast wpisywać go ręcznie. 3 - Opisy robotów muszą zawierać jedno zdjęcie w załączniku, które jest prezentowane w katalogu robotów oraz na stronie głównej. Tym razem poprawiłem, pamiętaj proszę na przyszłość o tych zasadach. [ Dodano: 14-10-2015, 11:06 ] 1 - Nie lepiej by było naprawić forum tak, żeby działała? 2 - Nie widziałem tam nigdzie listy rozwijanej. UPDATE: Już widzę, jest na szaro po stronie etykiety pola, musiałem jakimś cudem przeoczyć, przepraszam. Jakoś mogę to naprawić? 3 - Jestem pewien, że załączyłem jedno zdjęcie jako załącznik, własnie tak, jak piszesz. Nie mam pojęcia czemu się to nie pojawiło. Poprawiłem teraz.
  11. deshipu

    Deltabot

    Jakiś czas temu obudziłem się rano z przeświadczeniem, że koniecznie muszę zbudować robota w konfiguracji delta. Postanowiłem spróbować spełnić ten kaprys przy pomocy tego, co akurat miałem w domu pod ręką -- czyli serw i spinaczy do papieru: To niestety nie zadziałało za dobrze -- haczyki, które w teorii powinny stanowić przeguby, w praktyce miały tendencję do haczenia się i generalnie ustawiania w pozycjach, w których nie dało się nimi ruszać. Zdecydowałem, że trzeba podejść do sprawy bardziej profesjonalnie i użyć przegubów kulowych. Ruszyłem zatem do ulubionej chińskiej strony zakupowej w poszukiwaniu mosiężnych koralików. Niestety okrągłe koraliki sprzedawane były wyłącznie w ilościach od tysiąca sztuk w górę -- co prawda za grosze, ale co ja mam potem z resztą robić? Natomiast przy szukaniu koralików wpadły mi w oczy popychacze modelarskie z tak zwanymi "snapami" -- czyli tak naprawdę gotowymi przegubami kulowymi. Postanowiłem pójść na łatwiznę i zamówiłem. Kilka dni temu popychacze przyszły. Trochę się zdziwiłem, że są większe niż się spodziewałem, ale nie szkodzi -- zrobię większego robota, użyje większych serw, które leżą już w szufladzie ładnych parę lat. Zacząłem się zastanawiać z czego zrobić pozostałe mechaniczne części robota i oczy moje padły na stertę płytek PCB, które zamówiłem do jednego z prototypów mich robotów -- teraz już zastąpione nowszą wersją. Płytki te stanowią ciało robota, więc mają odpowiednie otwory do przykręcenia orczyków serw -- to, czego potrzebuję. Postanowiłem wykorzystać je jako materiał budulcowy, po uprzednim pocięciu ich na odpowiedniej wielkości kawałki dremelem: Trochę więcej pracy wymagało zrobienie głowicy robota, ale tutaj z pomocą przyszły porzucone uprzednio spinacze do papieru -- okazuje się, że całkiem dobrze dają się lutować do tych kawałków płytek, zatem zlutowałem je w odpowiedni kształt. Podstawę robota zrobiłem z pozostałych płytek PCB, skręcając je razem śrubami. Serwa przymocowałem najpierw po prostu taśmą dwustronną, ale potem przylutowałem do płytek uszka ze spinaczy, do których przykręciłem serwa śrubami. I to tyle, jeśli chodzi o mechanikę. Za mózg posłużyło ciało jednego ze starszych i pozbawionych już nóg prototypów moich kroczących robotów. ESP8266 i sterownik serw PCA9685, do tego bateria LiPo do zasilania -- nic skomplikowanego. Czas zabrać się za programowanie. Dużo słyszałem narzekania na złożoność kinematyki odwrotnej robota w układzie delty, więc zostałem miło zaskoczony kiedy usiadłem do tego z papierem i ołówkiem i okazało się, że jest to prostsze niż przy tradycyjnym ramieniu. Wszystko, co muszę obliczyć to odległości punktu docelowego do poszczególnych serw, a następnie kąty, pod jakimi te serwa muszą się ustawić, żeby ich dźwignie właśnie w takich odległościach się ustawiły. To ostatnie daje się łatwo policzyć z prawa kosinusów, aczkolwiek przy pierwszym podejściu trochę sobie niepotrzebnie utrudniłem zadanie: Otóż uwzględniłem w obliczeniach wielkość głowicy. Potem okazało się jednak, że niepotrzebnie, bo można ją z łatwością usunąć z równania, jeśli tylko przesuniemy o tę wielkość serwa -- w końcu kąt się wówczas nie zmienia. Ostatecznie, dwie krytyczne funkcje w moim programie to: def arm_ik(self, distance): alpha = math.acos( (self.BASE_LENGTH - self.HUB_LENGTH) / (distance) ) beta = math.acos( (distance ** 2 + self.ARM_LENGTH ** 2 - self.ROD_LENGTH ** 2) / (2 * self.ARM_LENGTH * distance) ) return math.pi - alpha - beta def robot_ik(self, x, y, z): return tuple(math.sqrt( (self.BASE_X[arm] - x) ** 2 + (self.BASE_Y[arm] - y) ** 2 + z ** 2 ) for arm in (0, 1, 2)) Na razie testy wypadają pomyślnie -- udało mi się narysować na trzymanej kartce kółko. Co prawda kółko miało mieć promień 5cm, a ma ~2cm -- zapewne gdzieś zrobiłem jakiś błąd przy wymiarowaniu. Będę jeszcze się tym bawił. Niestety, precyzja tego robota pozostawia wiele do życzenia. Stawy kulowe popychadeł modelarskich mają drobne luzy, które powodują chybotanie się głowicy -- nie jest ona idealnie poziomo. Dodatkowo luzy w samych serwach są dość spore i powodują niedokładności w pozycjonowaniu głowicy. Ogólnie, jest to raczej zabawka edukacyjna niż cokolwiek z poważnym zastosowaniem, ale i tak jestem z niego dosyć zadowolony. [ Dodano: 18-03-2017, 21:45 ] No i siedziałem nad tym i siedziałem aż wysiedziałem. Nie da się wyliczyć poprawnie kąta ramienia tylko z odległości punktu docelowego, bo koniec popychacza musi jeszcze dodatkowo wskazywać w kierunku tego punktu -- zatem niezbędna jest jeszcze znajomość wysokości. Nie zauważyłem tego, bo zawsze rysowałem ramię w tej samej pozycji, w której akurat przypadkiem wysokość się zgadzała z kierunkiem. Dodanie do obliczeń kinematyki odwrotnej ramienia wysokości znacząco poprawiło wyniki: def arm_ik(self, distance, z): alpha = math.asin(z / distance) beta = math.acos( (distance ** 2 + self.ARM2ROD2) / (2 * self.ARM_LENGTH * distance) ) return math.pi - alpha - beta def robot_ik(self, x, y, z): return tuple(math.sqrt( (self.BASE_X[arm] - x) ** 2 + (self.BASE_Y[arm] - y) ** 2 + z ** 2 ) for arm in (0, 1, 2)) def move_to(self, x, y, z): for arm, distance in enumerate(self.robot_ik(x, y, z)): self.move(arm, self.arm_ik(distance, z))
×