Skocz do zawartości

Przeszukaj forum

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

  • Szukaj wg tagów

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

Typ zawartości


Kategorie forum

  • Elektronika i programowanie
    • Elektronika
    • Arduino i 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 - DIY
    • Projekty - DIY roboty
    • Projekty - DIY (mini)
    • Projekty - DIY (początkujący)
    • Projekty - DIY 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

Kategorie

  • Quizy o elektronice
  • Quizy do kursu elektroniki I
  • Quizy do kursu elektroniki II
  • Quizy do kursów Arduino
  • Quizy do kursu STM32L4
  • Quizy do pozostałych kursów

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


Imię


Strona

Znaleziono 5 wyników

  1. Do kompletu z gadającym miernikiem - tym razem suwmiarka. Na początku uwaga: opisywany projekt przewidziany jest do współpracy z suwmiarką Vorel. Inne suwmiarki mogą działać lub nie. O ile układ pinów w gnieździe jest dla wszystkich urządzeń taki sam, o tyle wtyczka może nie pasować (i raczej nie będzie). Można spróbować oryginalnej wtyczki lub za pomocą OpenSCAD-a przyciąć ją do pożądanych rozmiarów (przykładowy kod zarówno na githubie, jak i w załączniku). Ponieważ istnieje kilka różnych protokołów przesyłania danych z tego typu urządzeń pomiarowych, trzeba się liczyć z tym, że kod programu może nie pasować: o ile funkcja odczytująca pojedynczy bit powinna działać, to zarówno odczyt pakietu jak i funkcja dekodowania pakietu mogą nie działać! I przede wszystkim dobra wiadomość: urządzenie (w obu wersjach) jest przystosowane do obsługi przez niewidomych. Zarówno kod, jak i schemat zostały zamieszczone na githubie, podam więc tylko najważniejsze informacje: Płytka LOLIN32 Lite została wybrana przede wszystkim ze względu na wbudowaną ładowarkę i możliwość pracy bezpośrednio z akumulatora LiPo. Rozwiązanie toru audio jest nienajlepsze (to taki eufemizm), ale działa. Oczywiście zastosowanie lepszego rozwiązania jest mile widziane. Należy tylko pamiętać, że ESP jeśli nie generuje dźwięku ustawia pin audio na zero, i tor audio nie powinien w tym momencie pobierać prądu z akumulatora. Można oczywiście przerobić program tak, aby obsłużyć podłączony dekoder I2S (np. taki) - jeśli ktoś jest zainteresowany a nie potrafi sam tego zrobić proszę dać znać w komentarzu. Aplikacja na telefon - proszę wybaczyć, to mój pierwszy projekt zrobiony w App Inventorze i nie zanosi się na to, aby ich było dużo więcej. Ważne, że działa. Gdyby ktoś chciał napisać swoją lepszą, jej sposób działania (to musi pozostać) jest następujący: Po wczytaniu komunikatu pierwszy znak jest zapamiętywany i ucinany, a do syntezatora wędruje pozostała część tekstu. Po zakończeniu pracy wymagane jest odesłanie zapamiętanego znaku, aby program suwmiarki wiedział kiedy skończyła się mowa. Obsługa suwmiarki realizowana jest jednym przyciskiem. Suwmiarka może pracować w trzech możliwych trybach: odczyt ciągły (co sekundę), odczyt zmian (jeśli zmieniła się wartość lub po naciśnięciu przycisku) oraz odczyt na żądanie (po wciśnięciu przycisku). Zmianę trybu wymusza się poprzez dłuższe (ponad 0.5 sekundy) wciśnięcie przycisku. Program odczytuje wynik w milimetrach lub calach (w tym przypadku tylko trzy cyfry po przecinku) rozpoznając, w jakich jednostkach pracuje suwmiarka. Pierwszy odczyt jest anonsowany (milimetry/cale), w następnych jednostka jest pominięta. Ponieważ wynik w milimetrach ma dwa miejsca po przecinku a wynik w calach trzy - łatwo się zorientować, w jakich jednostkach jest podany. Aby włączyć bluetooth i użyć telefonu jako syntezatora mowy, należy trzymać przycisk przy włączaniu urządzenia. Można uzyć dowolnego syntezatora dostępnego dla Androida, ale w przypadku syntezy Google należy liczyć się z dość dużymi opóźnieniami. Związane jest to z samym procesem syntezy dokonywanym na serwerach Google i program nie ma na to wpływu. Przy użyciu ESpeaka lub Vocalizera opóźnienie jest praktycznie niezauważalne. Dobra, tyle teorii. Pomysł siedział mi w głowie od paru lat - od pewnej (niedokończonej zresztą) dyskusji na Majsterkowie. Pierwsze próby były co prawda całkiem udane, ale użycie ESP8266 wymagało dodania konwerterów na wejściu, wyjście audio było takie sobie, a całość wymagała zasilania 5V i podłączana była kablem do suwmiarki. Nie było to specjalnie wygodne, toteż projekt poszedł w zapomnienie. Aż do chwili, kiedy zgłosił się do mnie ktoś kto znalazł mnie przez tamtą dyskusję z Majsterkowa, z pytaniem, czy jestem w stanie zrobić taką "gadającą suwmiarkę". Co prawda z różnych przyczyn nie chciałem podejmować się wykonania całości, ale pomyślałem, że przynajmniej napiszę działający program. To już poszło szybko. Funkcje odczytu pakietu za pomocą wejść analogowych na ESP32 znalazłem na githubie, syntezator miałem gotowy i przetestowany z poprzedniego projektu, więc tu żadnych problemów nie było - program ruszył właściwie tego samego dnia. "Ktosia" odesłałem na nasze forum (bo pomyślałem, że na pewno znajdzie się ktoś kto takie urządzenie zrobi, szczególnie że nie trzeba się martwić działaniem programu), kod wrzuciłem na githuba i zająłem się czymś innym. Tyle, że po chwili owego zajmowania się stwierdziłem, że taka gadająca suwmiarka bardzo by mi się przydała, i postanowiłem spróbować swoich sił w wykonaniu całości. Po krótkim szukaniu znalazłem kilka elementów które kupiłem z myśla o innym projekcie. Przede wszystkim niewielki akumulatorek (być może trochę za mały, ale się sprawdził) oraz mały głośniczek, wymiarami idealnie pasujący do suwmiarki. Lolina miałem co prawda zamontowanego w innym urządzeniu, ale mogłem go przynajmniej dokładnie zmierzyć, a płytka DevKit posłużyła mi do kolejnych eksperymentów. Szybciutko więc znalazłem Lolina na Allegro, i zająłem się projektowaniem obudowy. Po kilku nieudanych próbach doszedłem wreszcie do czegoś, co było już w miarę używalne. I tu uwaga dla kogoś, kto chciałby zrobić takie urządzenie. Zamieszczam co prawda pliki STL i scad, ale są one przygotowane pod konkretne elementy, i wymagane jest użycie wyłącznika i przycisku dokładnie takiego, jak w moim projekcie! Głośnik i akumulator też muszą być takie same! Wracając do rzeczy: wyłącznik i przycisk wlutowane są do kawałków płytki uniwersalnej dociętych tak, że wchodzą w przygotowane prowadnice (wystają ok. 1.5 mm z obu stron). Wzmacniaczyk (to taka szumna nazwa dla jednego tranzystora) umieściłem również na kawałku płytki uniwersalnej przymocowanej tymi samymi śrubkami, które służą do mocowania elementu przytrzymującego głośnik. Jeśli chodzi o sam druk, obudowa musi być wykonana z PETG ze względu na konieczną sprężystość uchwytów przytrzymujących urządzenie na suwmiarce. Dobranie parametrów druku jest zależne od posiadanej drukarki, ale ważne jest aby chłodzenie było minimalne - inaczej uchwyty mogą się odłamać! Pozostałe elementy mogą być z dowolnego materiału (PLA, ABS) z wyjątkiem wtyczki; ta musi być wydrukowana z TPU z warstwą najlepiej 0.1mm (0.2mm pierwsza). Na szczęście moja poczciwa A8 dała sobie radę doskonale (co utwierdza mnie w przekonaniu iż osoba, która kiedyś na forum twierdziła jakoby Anet A8 się nie nadawała do "poważnych rzeczy" była co najmniej w błędzie). Jak widać, urządzenie trzyma się na suwmiarce za pomocą trzech uchwytów (czwarty służy do zabezpieczenia wtyczki przed przypadkowym wypadnięciem) i nie wymaga żadnych przeróbek suwmiarki (poza oczywiście zdjęciem klapki zabezpieczającej gniazdo danych i schowaniem jej w jakieś bezpieczne miejsce). Niestety, rachityczny głośniczek brzmi trochę niespecjalnie... teoretycznie mógłbym sprzęgnąć układ z komputerem i użyć np. speech-dispatchera - tyle, że nie zawsze mam komputer pod ręką. No, komputer komputerem, ale w dzisiejszych czasach każdy ma przecież telefon! Postanowiłem nieco ulepszyć program i pozwolić mu na użycie telefonu z Androidem jako syntezatora mowy. Niestety, na pisaniu czegokolwiek pod Androida to ja się nie znam absolutnie. Na szczęście MIT App Inventor zawiera wszystkie klocki potrzebne do zbudowania takiej aplikacji. Co prawda nie przepadam za składaniem programów z klocków - no, ale na szybko innej możliwości napisania czegoś na Androida raczej nie miałem. Aplikacja jak wyszła tak wyszła - najważniejsze że działa. Na tym mógłbym skończyć, ale zakiełkował mi nowy pomysł. A co, jeśli ktoś nie przepada za doczepianiem dodatkowych pudełeczek do suwmiarki, a zgadza się na kabelek idący choćby właśnie do telefonu? Wystarczyłoby przecież usunąć z mojego programu wbudowany syntezator, a serial BT zastąpić zwykłym serialem... No tak, tylko że w tym przypadku użycie ESP32 to overkill. Akurat pod ręką miałem RPi Pico, i postanowiłem sprawdzić, czy się nada. Pierwsze próby z Serial Terminalem poszły świetnie; telefon co prawda w czasie podłączania twierdził że to pewnie kamera i chciał uruchomić IP Webcama, ale po wyperswadowaniu mu tego połączył się grzecznie z terminalem. Czyli sukces? Akurat. Serial Terminal bardzo ładnie dogadał się z Pico, ale ani wbudowany w Inventora moduł, ani rozszerzenie które podobno łączy się z wszystkimi możliwymi typami Arduino nie chciały gadać z Pico. A gdyby tak Arduino? Z tego co miałem w grę wchodziły tylko UNO i Nano, ze względu na wbudowane USB. Akurat miałem jeden nadmiarowy egzemplarz Nano więc postanowiłem go użyć. Co prawda ktoś tam kiedyś stwierdził, że Arduino jest za wolne ale jakoś mi się nie chciało wierzyć. Podłączyłem, i... Oczywiście. I nic. Na wejściu dostałem sieczkę. Ale to było do przewidzenia; o ile sam procesor powinien moim zdaniem wystarczyć, o tyle przetwornik A/D na Arduinowych ustawieniach jest faktycznie za wolny. Na szczęście nie potrzeba tu precyzyjnego pomiaru - wystarczy stwierdzenie, czy sygnał na wejściu jest w okolicy zera czy powyżej 1V. Po przestawieniu preskalera z 1:128 na 1:16 Arduino zaczął pięknie odbierać pakiety z suwmiarki. Reszta była już prosta. Przycisk został wlutowany bezpośrednio do GND i D3 Arduino (akurat ładnie tam pasuje). Przewód do suwmiarki również został bezpośrednio przylutowany do Arduino. W ten sposób udało mi się zrobić coś, co nie wymaga żadnych dodatkowych elementów (nawet przycisk można pominąć jeśli nie korzystamy z odczytu "na żądanie" - aplikacja pozwala na zmianę trybu na odczyt ciągły lub odczyt zmian). Sama aplikacja na telefon jest podobna do poprzedniej. Obudowę tym razem wydrukowałem z PLA. Mogłaby być mniejsza - ale nie miałem śrubek mniejszych niż M2. Po złożeniu układ działa bez zarzutu z jednym wyjątkiem: pierwszy odczyt po podłączeniu do telefonu może być zniekształcony. Najprawdopodobniej na początku w buforze serial Androida są jakieś śmieci, ale jako że dotyczy to tylko pierwszego odczytu postanowiłem z tym na razie nie walczyć. W ten sposób powstały dwie wersje urządzenia. I o ile pierwsza wymaga trochę indywidualnego podejścia przy złożeniu tego wszystkiego w całość - o tyle druga jest gotowa do użytku i może być wykonana nawet przez kogoś, kto potrafi tylko lutować i wydrukować wtyczkę do suwmiarki (lub ma kumpla z drukarką). A oto suwmiarka w działaniu: Na koniec - wszystkie potrzebne pliki w zipie.roznosci.zip Czyli: pliki stl i scad dla wersji ESP32 pliki stl, scad i ino dla wersji Arduino pliki aia i apk dla wersji Arduino pliki stl i scad wtyczki
  2. ...czyli trochę już zakurzony (ale za to dobrze przetestowany) projekt. Zaczęło się od tego, że pewna osoba zapytała mnie, czy byłbym w stanie zrobić coś w rodzaju metrówki. Początkowa odpowiedź miała brzmieć "nie", ale postanowiłem trochę pogłówkować. Oczywiście jakieś specjalizowane czujniki nie wchodziły w grę - urządzenie miało być zmontowane z tego, co można kupić od ręki bez czekania pół roku na transport z Chin, i to za cenę w miarę przystępną. Najpierw nie miałem pomysłu - ale w pewnej chwili gdy spojrzałem na drukarkę uświadomiłem sobie, że przecież pasek GT2 powinien być na tyle dokładny, żeby zapewnić milimetrową dokładność na odcinku - powiedzmy - dwóch metrów. Miałem jakieś kawałki pasków, więc zabrałem się do testowania. Na pierwszy ogień poszedł zwykły tani enkoder z nałożoną na oś zębatką. Pomiar okazał się wystarczająco dokładny - niestety, sam enkoder nie wytrzymał, trzeba było bardzo powoli przesuwać pasek, a po paru szybszych próbach po prostu przestał działać. Na szczęście miałem pozostałe po jakimś niezrealizowanym projekcie transoptory szczelinowe. Trochę projektowania, trochę drukowania - i to okazało się strzałem w dziesiątkę. Osadzony na łożyskach bęben z PLA bardzo dobrze współpracował zarówno z paskiem jak i z transoptorami, zapewniając pożądaną rozdzielczość pomiaru 1mm. Reszta była już prosta. Większość programu już miałem, czyli tym nie musiałem się przejmować. Użyłem jak zwykle płytki LOLIN32 Lite i typowego modułu MAX98357A. Kilka rezystorów wlutowałem po prostu w kawałek płytki uniwersalnej, to samo z wyłącznikiem i przyciskami - i urządzenie praktycznie ruszyło bez większych problemów. Piny na schemacie oznaczone są nazwami funkcji - przykładowe (zastosowane przeze mnie) przyporządkowania pinów znajdują się w pliku ESPMeter.h. Na zdjęciu urządzenie może sprawiać wrażenie jakiejś plątaniny kabelków - ale to dlatego, że nie chciałem odcinać przewodów od akumulatora, poza tym chciałem mieć jednak wszystko połączone na goldpinach. Na razie urządzenie spisuje się nieźle, zarówno mój egzemplarz jak i (podobno) kolegi @Jaha. Dodatkowo może z powodzeniem służyć jako centymetr krawiecki (zdaniem osoby niewidomej). Przy okazji wyszło, że niewidomy nawet pierwszy raz stykając się z Arduino IDE jest w stanie posługując się Windowsem z NVDA zarówno dokonać potrzebnych modyfikacji plików, jak i skompilować/wgrać program na płytkę - potrzebna tylko bardziej szczegółowa instrukcja. Szkoda, że Arduino IDE nie współpracuje z Linuksową Orcą 😞 I to tyle. Tym razem bez filmiku - byłby krótki i nudny i pewnie ktoś by się doczepił do tempa mowy 🙂 Dokładna instrukcja, plik OpenSCAD-a, schemat, kod źródłowy razem z microleną, Mimbrolą i polskim głosem - w załączniku.Metrowka.zip
  3. Alternatywne klawiatury to rzadko poruszany temat - mimo różnego rodzaju układów, dzielenia na bloki klawiatura pozostaje typową pecetową klawiaturą różniącą się od standardowej w praktyce tylko ułożeniem klawiszy. Tymczasem jedną z ciekawszych jest tzw. klawiatura akordowa. Ma ona mniej klawiszy niż normalna, mimo to poprzez użycie kombinacji klawiszy można na niej napisać to samo, co na standardowej. Jako ciekawostkę mogę podać, że najstarszym do dziś używanym z niewielkimi modyfikacjami urządzeniem wyposażonym w klawiaturę akordową jest wynaleziona w końcu XIX wieku mechaniczna brajlowska maszyna do pisania. Zainteresowanych tematem odsyłam do obszernego artykułu w Wikipedii - niestety w wersji angielskojęzycznej, bo w polskiej wersji jest tylko krótka notka, nawet bez podstawowych linków. Dodam tylko, że historycznie podejmowano różne próby stworzenia w różnych celach takiej klawiatury, jednak najpopularniejszy jest układ siedmiu klawiszy (przynajmniej jeden model - BAT keyboard - jest wciąż produkowany), tak więc postanowiłem zrobić swoją wersję właśnie na tym układzie. Oczywiście - istnieją gotowe programy, zarówno dla klawiatury łączonej przez USB (różne rodzaje ATmeg/PIC-ów z software'owym USB czy Arduino Pro Micro) jak i BLE (Adafruit Feather). Po zapoznaniu się z tymi rozwiązaniami stwierdziłem, że chcąc wprowadzić te możliwości o których myślałem potrzeba byłoby zbyt wielu zmian w programach, tak więc zdecydowałem się na napisanie czegoś swojego. Jako "serce" urządzenia wybrałem RPi Pico (najważniejszy powód był taki, że leżał sobie w szufladzie). Myślałem jeszcze o jakimś Lolin 32 Lite (leżał sobie obok Pico w tej samej szufladzie) z uwagi na wbudowaną ładowarkę, ale po przemyśleniu postanowiłem pozostać przy USB i zasilaniu z hosta - mam niemiłe doświadczenia z akumulatorami rozładowującymi się nie wtedy kiedy trzeba... Na początku przemyślałem sobie mechaniczną budowę. Ułożenie klawiszy w oglądanych modelach wydało mi się niezbyt fortunne. Ułożenie ręki na takiej klawiaturze jest zupełnie inne niż na tradycyjnej, tak więc położenie klawiszy musi być dopasowane do ręki użytkownika. Po przeprowadzonych kilki próbach "na sucho" wyszło na to, że najlepszym rozwiązaniem będzie układ, gdzie dłoń opiera się o powierzchnię biurka, a klawisze umieszczone są tam, gdzie trafiają luźne palce. Po wykonaniu pomiarów okazało się, że układ który mi najbardziej pasuje jest zupełnie inny. Co prawda pozostaje podstawowy układ (trzy klawisze dla kciuka i po jednym dla pozostałych palców), ale rozmieszczenie klawiszy w obu blokach było nieco inne, a wzajemny układ obu bloków to już całkowicie inna sprawa). Pierwsza wersja powstała na dwóch oddzielnych kawałkach płytki uniwersalnej przykręconych do kawałka płyty spienionego PCW, co pozwalało na dokładne wzajemne dopasowanie obu bloków. Do tego użyłem aż pięciu LED pokazujących stan klawiatury. Jako klawisze wybrałem Cherry ML1A-11NW - nie wiem czy dobrze, ale działają. Natomiast założenia programowe były następujące: Podobnie jak w innych klawiaturach sygnał o wciśnięciu klawisza jest generowany po puszczeniu wszystkich klawiszy akordu, ale z możliwością pozostawienia wciśniętego jednego z klawiszy kciuka. Po pierwsze ułatwia to użycie klawiatury, gdy używamy jednego z bloków znakowe/numeryczne/kursor, a w przypadku klawiszy kursora ważne jest, aby klawiatura pamiętała wciśnięty Shift, Alt czy Ctrl. Programowo klawiatura podzielona jest na trzy bloki: Podstawowy (literowy) (26 podstawowych liter, spacja, enter, dodatkowo makra dla "dż" i "dź" które wymagałyby wciśnięcia zbyt wielu klawiszy), klawisz CENTRAL zmienia po prostu bank, przy czym dla ułatwienia spółgłoski bezdźwięczne i odpowiadające im dźwięczne są na tym samym miejscu (np. "s" to dwa pierwsze klawisze, "z" to te same dwa pierwsze klawisze ale z wciśniętym CENTRAL). Blok kursorów i klawiszy specjalnych (w tym funkcyjnych) Blok znaków interpunkcyjnych przełączany na numeryczny, przy czym w trybie numerycznym musi być dodatkowy dostęp do kropki (zapis ułamków dziesiętnych), dwukropka (zapis godzin) i klawisza TAB. Po wstępnych próbach znów okazało się, że zwykłe klawisze nie nadają się do tej klawiatury. O ile dla palców klawisze powinny zapewniać po prostu pewne ułożenie palca uniemożliwiające przesunięcie (w tym przypadku typowy kształt jako-tako się sprawdza)), o tyle klawisze kciuka są wciskane bokiem palca i tradycyjny kształt jest po prostu niewygodny. Dlatego zaprojektowałem zupełnie inny kształt klawisza - plik STL w załączeniu.kciuk.zip Układ połączeń klawiatury jest bardzo prosty, całość składa się z: RPi Pico (bez wlutowanych pinów) Siedmiu klawiszy podłączonych bezpośrednio do GPIO Pięciu diod połączonych przez rezystory 1.2k (takie miałem) do GPIO. Dla porządku zamieszczam schemat I tu jedna uwaga: ponieważ wszystkie diody sterowane są sygnałem PWM, w programie przewidziałem możliwość korekty jasności każdej z nich, tak więc można wybrać dowolne rezystory (w pierwszej wersji było to 1.5k, dioda nie ma oświetlać pomieszczenia tylko sygnalizować stan urządzenia). Wygląd gotowego urządzenia pokazałem już wyżej, teraz tylko dwa zdjęcia z procesu składania: I od razu kilka słów wyjaśnienia: Użyłem płytek z wersji próbnej z bardzo prozaicznego powodu: musiałem kupić Pico (i kilka innych drobiazgów) a nie znalazłem sklepu który sprzedawałby wszystko co trzeba. Zamawianie płytki za 5 PLN plus płacenia za paczkomat uznałem za zły pomysł. Również wytrawianie własnej płytki (nawet nie bardzo mam w czym wytrawić) uznałem za niewygodne rozwiązanie - zrobienie kilku połączeń kynarem było dużo szybsze, szczególnie że miałem już coś działającego. "Krzywa" płytka z diodami i brak jednej śrubki to nie wynik niedbalstwa; po prostu w tym miejscu przechodzi jedna ze śrub mocujących górną część obudowy. Widoczna "dziura" przed klawiszami kciuka to też nie wynik braku materiału. Po prostu obudowa musiałaby być obniżona w tym miejscu z uwagi na położenie palca, a po pierwsze trudno określić konieczne obniżenie bez prób, po drugie takie coś fatalnie się drukuje. Poza tym wieczko po zamknięciu i tak zakrywa to miejsce... a w ogóle to nie jest do oglądania i podziwiania tylko do pisania. Poza tym jak już wspominałem, cała klawiatura musi być dostosowana do ręki użytkownika, tak więc publikowanie jakichś STL-i czy projektów PCB na nic by się nie przydało. A prawidłowe ułożenie palców powinno wyglądać tak: (przepraszam za fatalne ujęcie, ale nie bardzo miałem jak zrobić fotkę bez statywu). I kilka słów o technice pisania. Pełna mapa klawiatury jest w pliku sciaga.txt w załączniku. Użyte nazwy klawiszy to kolejno (od najdalszego kciuka): FAR CENTRAL NEAR A E I O. Muszę jednak jeszcze wspomnieć o kilku drobiazgach. Przyciski kciuka jeśli wciskane są samodzielnie (bez klawiszy palców) działają jak modyfikatory, Rozróżniane są krótkie i długie wciśnięcia - np. krótkie wciśnięcie CENTER to shift, dłuższe to capslock. Stan danego modyfikatora sygnalizują odpowiednie diody. Jeśli po puszczeniu klawisza w ciągu 5 sekund nie nastąpi żadna reakcja użytkownika, modyfikator jest kasowany. Kasowany jest również po odebraniu następnego znaku, z następującymi wyjątkamu: - klawisze ruchu kursora zapamiętują stan Alt, Shift i Ctrl dopóki nie zostanie puszczony przycisk NEAR alo nie zostanie wprowadzony znak inny niż ruch kursora. Zapamiętanie stanu odbywa się w samej klawiaturze, czyli np. wciśnięcie kolejno "Shift, Right, Right" spowoduje wysłanie do hosta sekwencji: SHIFT Pressed RIGHT Pressed ALL Released SHIFT Pressed RIGHT Pressed ALL Released - Klawisze makr "Alt-Tab" i "Shift-Alt-Tab" zapamiętują modyfikator Alt w nieco inny sposób: ponieważ w trakcie zmiany okien klawiszami TAB i SHIFT/TAB klawisz Alt musi pozostawać wciśnięty, sekwencja np. "Alt-Tab Alt-Tab" jest przesyłana jako: ALT presssed TAB pressed TAB released TAB pressed TAB released ALT released Jest to co prawda techniczny szczegół, ale warto o nim pamiętać. Klawisz Super jest rzadko wykorzystywany, więc normalnie jest zablokowany aby nie mylił się z Ctrl. W każdej chwili można go odblokować odpowiednią kombinacją klawiszy (NEAR-AEIO NEAR-AIO). W trybie klawiatury - jak już wspominałem - znak interpretowany jest dopiero po puszczeniu wszystkich klawiszy AEIO. Umożliwia to spokojne wciskanie klawiszy akordu po kolei. W trybie myszy jest jednak inaczej. Teoretycznie klawisze powinny reagować od razu powodując przesłanie informacji o ruchu do hosta. Istnieją jednak kombinacje klawiszy nie związane z ruchem myszy (np. obrót kółka czy wciśnięcie/puszczenie modyfikatora). Dlatego pierwszy komunikat po wciśnięciu jest lekko opóźniony, dając czas na wciśnięcie dwóch lub trzech klawiszy. Czas (50 msec) jest na tyle krótki, aby nie utrudniał poruszania myszą, a jednocześnie umożliwiał operowanie takimi kombinacjami, należy jednak liczyć się z tym, że może wystąpić przesunięcie wskaźnika o piksel. Klawiatura jest przystosowana do obsługi prawą ręką, ale nic nie stoi na przeszkodzie aby zrobić lustrzaną wersję dla lewej ręki. Należy jedynie odkomentować w pliku keyboard.c linijkę: #define LEFTHAND co spowoduje właściwe ułożenie klawiszy kursora, nawiasów oraz myszy. I jeszcze o możliwych modyfikacjach. Klawiatura w tej postaci nie nadaje się dla niewidomych - niektóre kombinacje klawiszy (np. Insert-Space) są nieosiągalne. Na chwilę obecną widzę trzy rozwiązania: - dodanie dodatkowego klawisza (może być niewygodne) - zmiana programu w ten sposób, że akord "Insert" reaguje z opóźnieniem, a wciśnięcie jakiegoś akordu przed upłynięciem czasu opóźnienia powpoduje wysłanie np. sekwencji: INSERT Pressed, COŚTAM Pressed, ALL Released. - rezygnacja z makr "dż" i "dź" i wprowadzenie w to miejsce dodatkowych poleceń dla screenreadera. Tak zmodyfikowana klawiatura może być użyteczna przy jednoczesnym pisaniu i posługiwaniu się linijką brajlowską. Ponieważ klawiatura może być dołączona równolegle z normalną nic nie szkodzi aby używać obu zamiennie. Moim zdaniem taką klawiaturę należałoby wyposażyć również w jakiś sygnał akustyczny zastępujący wskaźnik diodowy, ale to już zależałoby od samego zainteresowanego. Ponieważ klawiatura nie wymaga trzymania ręki nad nią - może być użyta przez osoby o ograniczonej zdolności ruchu. Jeśli np. palce są sprawne, a niedowład dotyczy wyłącznie możliwości uniesienia ręki w takim przypadku nie trzeba żadnych zmian. Można również rozdzielić klawiaturę tak, aby palce jednej ręki obsługiwały modyfikatory, a drugiej klawisze palców. Oczywiście taka klawiatura może być również bez żadnych zmian użyta przez osoby posługujące się tylko jedną ręką. I to by było na tyle. Zamieszczam jeszcze pełną mapę klawiatury (w bloku "Pozostałe" trzecią i czwartą pozycję makr uzyskuje się poprzez włączenia AltGr): aeio | CENTRAL | ------+-------------+ x--- | A U | -x-- | E Y | xx-- | S Z | --x- | I J | x-x- | C X | -xx- | N M | xxx- | P B | ---x | O H | x--x | F W | -x-x | L R | xx-x | K G | --xx | T D | x-xx | V Q | -xxx | Dż Dź | xxxx | Space Enter | ------+-------------+ === MODYFIKATORY === Klawisz | Short | Long --------+-------+---------- FAR | AltGr | Alt CENTRAL | Shift | CapsLock NEAR | Ctrl | Super --------+-------+---------- === POZOSTAŁE KLAWISZE === aeio | FAR | FAR/NUM | NEAR Fn | ------+-----------+-------+----------+-------+-----------------+ x--- | . > | x--- | 1 ! | x--- | left F1 | -x-- | , < | -x-- | 2 @ | -x-- | up F2 | xx-- | [ { | xx-- | 3 # | xx-- | pgup F3 | --x- | ; : | --x- | 4 $ | --x- | right F4 | x-x- | ( % ^ \ | x-x- | 5 % | x-x- | a-tab F5 | -xx- | / ? | -xx- | 6 ^ | -xx- | bs/del F6 | xxx- | @ & | § | xxx- | 7 & | xxx- | home F7 | ---x | ' " | ---x | 8 * | ---x | down F8 | x--x | ! $ # € | x--x | 9 ( | x--x | esc F9 | -x-x | ) * = + | -x-x | 0 ) | -x-x | s-a-tab F10 | xx-x | - _ | xx-x | - _ | xx-x | insert F11 | --xx | ] } | --xx | = + | --xx | pgdown F12 | x-xx | ` ~ | x-xx | \ | | x-xx | menu/prt Super| -xxx | tab | -xxx | tab . : | -xxx | end Mouse| xxxx | NUM | xxxx | NUM | xxxx | Fn FnOff| ——————+———————————+———————+——————————+———————+—————————————————+ ==== MYSZ ==== aeio | ------+------------ x--- | Left -x-- | Up xx-- | LeftUp --x- | Right x-x- | ScrollUp -xx- | RightUp xxx- | Keyboard: Show Cursor ---x | Down x--x | LeftDown -x-x | ScrollDown xx-x | Keyboard: Alt Key --xx | RightDown x-xx | Keyboard: Ctrl Key -xxx | Keyboard: Shift Key xxxx | Mouse Off ——————+------------ === MOUSE BUTTON EMULATION == FAR = LMB CENTRAL = MMB NEAR = RMB === LED === Keyboard mode: No | Light | Blink | Dark ---+----------+--------+----------- 1 | CapsLock | Power | 2 | Numeric | | 3 | AltGr | Alt |Keep alt 4 | Ctrl | Super |Keep ctrl 5 | Shift | Fn |Keep shift ---+----------+--------+----------- Mouse mode: 1/2 Blink - mouse mode active 3 - Alt pressed 4 - Ctrl pressed 5 - Shift pressed Do tego w załączniku pełny kod programu.PicoChorder.tgz Oczywiście odpowiadam na wszystkie pytania i sugestie (nawet pozornie głupie - w końcu nie jestem wszechwiedzący i coś co pozornie może nie mieć sensu może okazać się ciekawym rozwiązaniem).
  4. Witam. Przyznam się, że miałem trudności z napisaniem tego artykułu. Bo gdybym chciał opisać całą historię powstania zarówno urządzenia, jak i niezbędnego oprogramowania wyszłaby z tego całkiem niezła książka. Ograniczę się więc do bardzo skrótowego opisu. Od lat bawię się syntezą mowy (zaczynałem jeszcze w czasach Amigi, potem był Linux, ostatnio mikrokontrolery). Do tej pory na ESP używałem syntezatora Klatta. Co prawda jest niespecjalnie wymagający jeśli chodzi o moc obliczeniową (najmniejszą implementację widziałem na C-16 z 32 kB RAM), ani o techniczne parametry wyjścia audio (czterobitowe przetworniki mogą wygenerować całkowicie zrozumiałą mowę przy 8 kHz, a pięć bitów to w ogóle hi-fi), ale... no właśnie: głos jest mechaniczny jak przystało na kod z końca lat 70-tych ubiegłego wieku, a nie każdy lubi wysłuchiwać co mu ten smędzący robot opowiada. Na szczęście w 2018 roku wygasły patenty na algorytmy używane w Mbroli i kod został opublikowany na bardzo miłej (jak dla mnie) licencji AGPL. Trochę zwlekałem, zwalając sam przed sobą na trudności techniczne, ale w końcu kiedy w Botlandzie pokazał się ESP32-WROVER z 16 MB flasha i 8 MB PSRAM stwierdziłem, że nie ma co dalej udawać i trzeba się wziąć do roboty. Trudności trochę owszem było (między innymi zrozumienie kodu pisanego w jakiś straszliwie manieryczny sposób) ale w końcu jakoś przez to przebrnąłem. W dodatku okazało się, że zastosowanie prostej kompresji A-law pozwoliło zmniejszyć o połowę wielkość danych dla programu praktycznie bez zauważalnej straty jakości generowanej mowy, co pozwoliło mi na zmieszczenie bazy próbek dla języka polskiego w 4-megabajtowej pamięci typowego ESP-32, przy czym PSRAM jak na razie pozostał niewykorzystany. Tak więc powstała implementacja Mbroli na mikrokontrolery: Mimbrola. I tu od razu uwaga, gdyby ktoś w tej chwili od razu wskoczył na githuba i zaczął narzekać. To prawda, biblioteka w tej postaci jest pisana dla ESP-32 i Arduino IDE. Ale główna część biblioteki jest pisana w C, a Arduinowa część to tylko interfejs pozwalający na użycie w prosty sposób Mimbroli z typową biblioteką ESP8266Audio. Dla innych mikrokontrolerów zmiany ograniczałyby się chyba tylko do sposobu odczytu danych bezpośrednio z pamięci flash albo do wybrania wersji wkompilowanej bezpośrednio w kod. No, ale Mbrola to tylko syntezator a nie TTS, nie każdy lubi karmić program tekstami w stylu dz' 20 i 14 e 95 0 214.00 100 200.00 n' 50 d 35 o 95 0 191.00 100 144.00 b 70 r 50 I 205 0 154.00 100 146.00 _ 2 Na szczęście działający procesor języka polskiego już miałem, pozostawała kwestia dość mocnego okrojenia (bo tam dane idą w grubsze dziesiątki megabajtów). Jednak i to okazało się możliwe: Milena powstała z myślą o tworzeniu audiobooków, tak więc można było wyrzucić jakieś 90% słownika wyrazów obcych, większość reguł wymowy różnych przedziwnych łamańców oraz cały oparty na morfologiku moduł gramatyki (służący w praktyce tylko do odmiany rzadko spotykanych skrótowców i liczb mianowanych). Co prawda pozostawiłem sobie furtkę w postaci możliwości włączenia rozszerzonych słowników dla mikrokontrolerów z większą ilością flasha (np. gdyby ktoś chciał tym ustrojstwem książki czytać), ale w zastosowaniach takich jak omawiane nie są one absolutnie potrzebne. Tak więc powstała microlena, która razem z Mimbrolą tworzą pełnoprawny system TTS dla języka polskiego. I znów zachodzi ta sama sytuacja: kod jest pisany w C, Arduinowy fragment to tylko interfejs. Dobra, biblioteki już miałem. Teraz trzeba było zaprzęgnąć to do jakiejś sensownej roboty. I znów dorwał mnie znany już nam niewidomy: znalazł gdzieś w necie gadającą poziomicę i stwierdził, że bez takiej życie mu niemiłe... tylko ma gadać po polsku. Obejrzałem filmik, stwierdziłem że da się zrobić i zabrałem się do projektowania. Od razu pomyślałe, że sama poziomica to za mało. Ponieważ chciałem użyć ESP32, konkretniej Lolin32 Lite, mogłem coś tam jeszcze dokombinować. W szufladzie miałem czujnik ToF VL53L1X, postanowiłem więc zrobić takie trochę wielofunkcyjne urządzenie: poziomica plus dalmierz. Sama poziomica opiera się na popularnym MPU6050 (tu nawet biblioteki specjalnej nie trzeba, szybciej napisać kod od zera), do dalmierza postanowiłem użyć oryginalnej bibhlioteki od ST (szczególnie, że Pololu opublikował interfejs do Arduino). No cóż - jest Arduino i Arduino. Biblioteka najpierw się nie chciała skompilować (kompilator uznał, że komentarze i znaki kontynuacji linii to dla niego trochę za skomplikowane). Po niezbędnych poprawkach (czyli zakomentowaniu komentarza) co prawda skompilowała się wspaniale, ale w działaniu zacięła się na takim małym drobiazgu - mianowicie odczycie odległości. Na szczęście wśród dyskusji na githubie znalazło się rozwiązanie, i po zaaplikowaniu potrzebnych zmian wszystko ruszyło. Tak więc gdyby ktoś potrzebował podłączyć tę bibliotekę do ESP32/Arduino, należy: W pliku vl53l1_platform.cpp poprawić lub usunąć komentarze w okolicy linii 253; W tym samym pliku zamienić w funkcji VL53L1_Error VL53L1_ReadMulti linię: uint8_t reading = Wire.requestFrom(Dev->I2cDevAddr >> 1, count); na uint8_t reading = Wire.requestFrom(Dev->I2cDevAddr >> 1, 1); I oczywiście nie zapomnieć o usunięciu pliku vl53l1x-st-api.ino który powinien siedzieć w examples a nie siedzi Na wszelki wypadek podaję wynik polecenia diff: --- vl53l1_platform.cpp.orig 2021-02-18 03:38:09.000000000 +0100 +++ vl53l1_platform.cpp 2021-06-02 20:02:22.500859648 +0200 @@ -152,7 +152,7 @@ while (count > 0) { - uint8_t reading = Wire.requestFrom(Dev->I2cDevAddr >> 1, count); + uint8_t reading = Wire.requestFrom(Dev->I2cDevAddr >> 1, 1); if (reading == 0) { return VL53L1_ERROR_CONTROL_INTERFACE; } count -= reading; @@ -250,7 +250,7 @@ *ptick_count_ms = millis(); return VL53L1_ERROR_NONE; } - +/* //#define trace_print(level, ...) \ // _LOG_TRACE_PRINT(VL53L1_TRACE_MODULE_PLATFORM, \ // level, VL53L1_TRACE_FUNCTION_NONE, ##__VA_ARGS__) @@ -258,7 +258,7 @@ //#define trace_i2c(...) \ // _LOG_TRACE_PRINT(VL53L1_TRACE_MODULE_NONE, \ // VL53L1_TRACE_LEVEL_NONE, VL53L1_TRACE_FUNCTION_I2C, ##__VA_ARGS__) - +*/ VL53L1_Error VL53L1_GetTimerFrequency(int32_t *ptimer_freq_hz) { return VL53L1_ERROR_NOT_IMPLEMENTED; Teraz trzeba było już na poważnie zabrać się do roboty. Na pierwszy ogień poszło mocowanie czujników (ToF i MPU). Postanowiłem, że użyję którejś z obudów Kradexu, a wszystko będzie mocowane do górnej pokrywy. Tak więc po krótkiej zabawie OpenSCAD-em wyszło mi coś takiego: Jeśli chodzi o elektronikę (to taka szumna nazwa dla paru modułów połączonych kabelkami) postanowiłem, że użyję wyłącznie gotowych modułów - tak, aby do zbudowania urządzenia wystarczyły podstawowe narzędzia i umiejętność lutowania nie przekraczająca pierwszych lekcji kursu Forbota. Schemat (o ile można ten szkic tak nazwać) przedstawia się następująco: Skompletowałem wszystkie elementy, znalazłem jakąś samotną obudowę Z34J, podrukowałem wszystkie klawisze, wsporniczki, kratkę na głośnik i... i okazało się, że głośnik który chciałem zastosować jest do niczego. Niestety, jedyny pasujący głośnik który miałem okazał się nieco za duży, tak że musiałem poupychać elementy w obudowie (co widać na zdjęciach). Niestety - moduł DAC mi się już nie zmieścił, musiałem użyć zwykłego małego wzmacniacza podłączonego do wewnętrznego DAC-a ESP32. Jakość głosu jest niestety dużo niższa, do tego dochodzą brzydkie artefakty (syntezator kończy pracę ustawiając DAC-a na środkową wartość czyli jego zdaniem zero, a za chwilę wyłączenie przetwornika powoduje pojawienie się na tym pinie rzeczywistego zera)[1], ale nie jest to wada eliminująca urządzenie (szczególnie, że chciałem zrobić działający model, a nie końcowy produkt). Po zmontowaniu zadziałało pięknie, zabrałem się więc za dopracowywanie programu. No i tu przeżyłem przykrą niespodziankę. Otóż zaprojektowałem uchwyt do dalmierza w ten sposób, aby można tam było wstawić ochronne szkiełko (między innymi dlatego użyłem oryginalnej biblioteki od ST a nie uproszczonej - pełna kalibracja). Cóż - mimo prób z różnymi materiałami nie udało mi się osiągnąć prawidłowej pracy dalmierza. Musiałem ze szkiełka zrezygnować... dodrukowałem więc troszkę inny element uchwytu a oprócz tego małą zatyczkę z TPU chroniącą czujnik. W kodzie zakomentowałem część odpowiedzialną za kalibrację czujnika, ale pozostawiłem możliwość szybkiego odblokowania jej jeśli komuś uda się znaleźć odpowiedni materiał. Podobnie zresztą było z ustawieniem ROI. Próba ustawienia innego obszaru niż pełny skutkowała dość dużymi błędami odczytu. Zacząłem podejrzewać, że czujnik może być uszkodzony, ale nie miałem już szans na sprowadzenie nowego. Tak więc postąpiłem podobnie - część odpowiedzialna za zmianę ROI jest zablokowana, ale w łatwy sposób można ją odblokować. Mimo to urządzenie działa, spełnia swoją funkcję, a działanie można obejrzeć (i posłuchać) na filmie poniżej. Dołączam poziomica.zip: kod programu (bez bibliotek, te lepiej ściągnąć z gita) polski głos A-law do Mbroli przeznaczony do wkompilowania w kod pliki OpenSCAD-a do zamocowania czujników pliki txt z instrukcjami obsługi i montażu plik opisu partycji ESP32 dla Arduino. A oto wykaz części użytych do budowy urządzenia: WEMOS LOLIN32 Lite Czujnik VL53L1X (moduł Pololu 3415) MPU6050 (moduł GY-521) Akumulator LiPo 1400 mAh Głośnik (8Ω/3W) Rezystory 47k, goldpiny, przyciski, wyłącznik - według uznania Zamiast planowanego modułu MAX98357A (SparkFun DEV-14809) użyłem: moduł wzmacniacza PAM=8403 potencjometr montażowy 10 kΩ kondensator 4.7µF Jeśli chodzi o obudowę, może być to oczywiście jakakolwiek obudowa pasująca rozmiarami, ważne jest jednak, aby ścianki boczne były płaskie i pionowe (zastowowana przeze mnie obudowa nie spełnia tego warunku). Jeszcze jedna uwaga: aplikacja po skompilowaniu ma ponad 3 MB, w związku z tym nie mieści się na żadnym standardowym układzie partycji. Moja propozycja to stworzenie następującego układu: # Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x5000, otadata, data, ota, 0xe000, 0x2000, app0, app, ota_0, 0x10000, 0x3F0000, i dopisanie w boards.txt dla ESP32 linijek: lolin32-lite.menu.PartitionScheme.apponly=4M Flash (Application only) lolin32-lite.menu.PartitionScheme.apponly.build.partitions=apponly lolin32-lite.menu.PartitionScheme.apponly.upload.maximum_size=4128768 Dokładna instrukcja w załączniku. I to by było na tyle. Przyjemnego poziomowania życzy ethanak [1] Wiem teoretycznie jak to "naprawić", ale nie chcę ingerować w bibliotekę ESP8266Audio
  5. Naszła mnie ostatnio ochota na skonstruowanie gadającego miernika. Bo to oczy już nie te co kiedyś, a i nie zawsze jest wygodne gapienie się w wyświetlacz w moim mierniku - po pierwsze kontrast jest taki z niższej (a raczej z bardzo niskiej) półki, po drugie miernik zawsze leży nie tam gdzie trzeba i pchanie końcówek pomiarowych w różne miejsca przy patrzeniu gdzie indziej może skończyć się jakimś ładnym zwarciem. Ponieważ podobną konstrukcję kiedyś już zrobiłem, postanowiłem nie wydziwiać, skopiować ze starej to co działa dobrze i przerobić to co działało źle. Przede wszystkim - konstrukcja była stacjonarna (zewnętrzne zasilanie 5V) i dość duża, wyświetlacz LCD też nie grzeszył czytelnością. Poza tym o ile omomierz działał całkiem sprawnie, o tyle woltomierz pokazywał jakieś dziwne wyniki. No i zasilanie z zewnętrznego zasilacza też nie wpływało pozytywnie na wyniki... A więc poczyniłem sobie założenia: Miernik nie musi być bardzo precyzyjny. Omomierz ma służyć przede wszystkim do sprawdzenia jaki to opornik leży mi na biurku (propozycje oglądania jakichś pasków pominę milczeniem, ja się cieszę jeśli opornik na biurku znajdę, a istnienie jakichś pasków mogę sobie badać pod większą lupą). Również woltomierz nie musi być specjalnie precyzyjny - raczej ma służyć do sprawdzenia jakie mniej więcej napięcie występuje w danym miejscu (czy to 3.3V czy może 5V) i czy w ogóle jakieś występuje. Do tego dochodzi pomiar napięcia przewodzenia diody (choćby w celu odróżnienia czy to co trzymam w ręku to dioda Schottky czy zwykła prostownicza) i kilka drobnych bajerów (np. ustawianie "na słuch" napięcia). I tu uwaga: miernik nie jest przeznaczony do użytku dla niewidomych - do wielu czynności konieczne jest widzenie wyświetlacza. Nic nie stoi jednak na przeszkodzie, aby zaadaptować go również dla takich osób, wymaga to jednak kilku dość istotnych modyfikacji programu. Poprzednia konstrukcja bazowała na Arduino Pro Mini (układ pomiarowy) i ESP8266 (syntezator). Postanowiłem zastąpić to ESP32, wyświetlacz LCD zastąpić OLED-em a zasilanie zrobić na dwóch 14500. Nie będę tu pokazywał dokładnej konstrukcji i schematów - całe urządzenie jest średnio udane i ktoś, kto chciałby zrobić sobie podpbne urządzenie powinien zaprojektować całość od początku. Zamieszczam jedyne kod programu - ale raczej w celu podpatrzenia sobie jak to zrobiłem czy skorzystania z różnych mniej lub bardziej pomysłowych pomysłów (np. czytelne fonty w ISO-8859-2, software-owy bold czy duża czcionka użyta do wyświetlania wyników pomiaru). Zacząłem od omomierza - bo to wydało mi się najprostsze jako że miałem przed nosem działającą konstrukcję. Niestety - to co było proste na Arduino okazało się absolutną porażką na ESP. Wielozakresowy omomierz w Arduino działał na zasadzie podłączenia rezystora dzielnika do jednego z wyjść Arduino, podczas gdy pozostałe ustawione były na INPUT. Przy ESP pierwsze próby podłączenia (pojedynczego zakresu) wyszły wspaniale... niestety, podłączenie kilku zakresów zaowocowało jakimiś potwornymi błędami odczytu. Teoretycznie podłączenie rezystorów przez diody powinno dać lepsze wyniki - niestety, to ładna teoria, ale jakoś mi się w praktyce nie sprawdziła. Skończyło się na użyciu multipleksera 4051. Niestety - przy najwyższym zakresie omomierza (gdzie rezystor dzielnika miał mieć 470k) okazało się, że multiplekser ma jakieś problemy egzystencjonalne, skończyło się niestety na 4 zakresach zamiast 5. Na szczęście na czterech zakresach działa całkiem zacnie, a do pomiarów rezystancji w okolicach megaoma i więcej mam przecież zwykły omomierz. Natomiast woltomierz ruszył od strzału. Pisałem swego czasu o pierwszych próbach, okazało się, że wystarczyło doświadczalnie dobrać sobie rezystory z tych co miałem w szufladzie, i wyszło mi coś co ma rezystancję wewnętrzną w okolicach 50kΩ/V (czyli lepiej niż myślałem) i wystarczającą liniowość. Trzeba było niestety zwiększyć napięcie zasilania wzmacniacza, ale to już szczegół. Do sterowania przekaźnikami (dwucewkowymi, żeby mi prądu nie żarły w czasie pracy) zastosowałem ULN2803A. Dodatkowo jeden z kanałów służy mi jako wzmacniacz audio (ESP daje mi sygnał audio w postaci delta-sigma, czyli nie muszę stosować jakichś wymyślnych konstrukcji, w praktyce wystarczył rezystor 68Ω włączony szeregowo z głośnikiem). Całość umieściłem na płytce uniwersalnej - niestety, próby zaprojektowania płytki zakończyły się fiaskiem, technicznie nie jestem w stanie wykonać dwuwarstwowej płytki, a jednowarstwowa albo wychodziła dwa razy większa niż przewidziane miejsce w obudowie, albo miała tyle samo zworek i kabelków co uniwersalna 🙂 Jak widać, przypomina to plątaninę przewodów, co nie zmienia faktu że działa. Miernik mieści się w obudowie Kradexu Z34B. No... prawie się mieści, bo zabrakło miejsca na akumulatory. Ale może to i lepiej - przynajmniej łatwo je wyjąć z koszyka i włożyć do ładowarki 🙂 Na zdjęciu widać, że całość zmontowana jest na jednej stronie obudowy, tak aby można było w trakcie testów używać urządzenia ze zdjętym spodem i podłączenia kablem USB do komputera. No - ale dotychczas nie było czym się chwalić, całe ustrojstwo wygląda dość topornie, na szczęście nadrabia funkcjonalnością. Miernik może pracować w następujących trybach: Omomierz (używalny zakres od kilkunastu omów do kilkuset kiloomów, automatyczne przełączanie zakresów) Przypisanie rezystora do typoszeregu (10% lub 20%) Woltomierz (dwa zakresy, -10..10V - -24..24V) Czujnik zwarcia Pomiar napięcia przewodzenia diody Pomoc w regulacji napięcia do ustalonej wcześniej wartości (patrz film) Wyjście mowy może być również realizowane na kilka sposobów: Wbudowany syntezator Klatta Połączenie z zewnętrznym speech-dispatcherem (wymagana rekonfiguracja tak, aby pracował w trybie inet_socket i oczywiście odpowiednie ustawienie firewalla, żeby mi jakiś Chińczyk nie próbował czegoś zdalnie powiedzieć) Połączenie z zewnętrzną aplikacją (miernik po prostu wysyła na socket tekst do powiedzenia, aplikację np. na Windowsa z Ivoną trzeba sobie napisać samemu) Konfiguracja WiFi jest chyba najprostsza z możliwych - ESP pracuje w trybie AP_STA, można się podłączyć np. telefonem lub laptopem do AP i poprzez prosty interfejs WWW ustalić wszystkie szczegóły połączenia. I kilka szczegółów technicznych: Użyłem płytki DevKit ze względu na cenę i rozmiar (no i najważniejsze - leżała w szufladzie) Układ zasilany jest bezpośrednio z dwóch akumulatorów 14500 - zrezygnowałem ze stabilizatora. Tym napięciem zasilana jest zarówno płytka ESP, jak i wzmaniacze operacyjne woltomierza oraz przekaźniki i głośnik. Wyświetlacz zasilany jest natomiast z wyjścia 3.3V płytki. Syntezator pracuje z częstotliwością próbkowania 11025 Hz. Podsystem audio przekształca to na 44100 (po prostu czterokrotnie powielając każdą próbkę) i tak otrzymany sygnał poddawany jest obróbce sigma-delta. Wyświetlane wyniki są zaskakująco czytelne - mimo że cyfry są mniejsze niż na moim multimetrze, to jednak glify są dużo wyraźniejsze niż siedmiosegmentowe cyferki, a i potężny kontrast daje dobrego kopa. W załączniku można znaleźć dwa fonty kodowane w ISO-8859-2 oraz duży font do wyświetlania wyników (zakres 0x20..0x7e, z dodatkowym znakiem Ω na pozycji 0x7f). Trzeba tylko dobrze poszukać 🙂 A tu można obejrzeć krótki filmik z działania miernika No i oczywiście obiecany kod źródłowy: EMeter.tgz
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.