Arduino Gadająca poziomica z dalmierzem

[ethanak]

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

 

Edytowano Czerwiec 28, 2021 przez ethanak

[Treker (Damian Szymański)]

@ethanak dziękuję za opis kolejnego oryginalnego DIY. Wpis został właśnie zatwierdzony, więc jest już widoczny publicznie

[SOYER]

Brawo @ethanak . Jak zawsze profesjonalna robota. Ja by tylko widział dwie proste poprawki idioto odporne. Wolniejsze tempo mowy i oznaczenie w piśmie i mowie klawiszy jako 1,2,3,a nie prawy, środkowy, lewy, bez opisu fizycznego.

Świetna robota.

[deshipu]

Nie wiem czy miałeś kiedyś okazję słyszeć niewidomego posługującego się czytnikiem ekranu — powiem tak, jak dla nich, to to mówienie jest super-wolne.

[ethanak]

7 godzin temu, deshipu napisał:

to mówienie jest super-wolne.

Pełna zgoda - ta prędkość była na potrzeby filmiku, to jest mniej więcej 1.2 (maksymalna 2.0). Poza tym w instrukcji (tej w pliku) jest to wyraźnie opisane

11 godzin temu, SOYER napisał:

oznaczenie w piśmie i mowie klawiszy jako 1,2,3,a nie prawy, środkowy, lewy,

A dlaczego?

Jeśli są trzy klawisze obok siebie, to naturalne jest oznaczenie lewy-środkowy-prawy. Owszem,  nie ma problemu z nadrukowaniem brajlowskich oznaczeń na klawiszach, ale przy trzech sztukach to chyba przesada...

[bjrk]

Względne określenie klawiszy lewy, środkowy, prawy lub górny, środkowy, dolny zależy od ułożenia przyrządu, a nie widzę naturalnego domyślnego położenia. Bezwzględne identyfikowanie klawiszy (bez względu na położenie) było by chyba nieco lepsze, bo jednoznaczne. Ale po kilku próbach i tak dojdzie się jak to ma leżeć i który klawisz jest który.

[ethanak]

Pytanie kontrolne: gdzie jest lewy klawisz w myszy dla leworęcznego?

[SOYER]

2 godziny temu, ethanak napisał:

Pytanie kontrolne: gdzie jest lewy klawisz w myszy dla leworęcznego?

tak, ale myszy nie obracasz w trakcie pracy we wszystkich osiach, leży zwrócona w jedną stronę, także porównanie nietrafione. Jasne, że bez oznaczenia każdy trochę rozgarnięty sobie poradzi, ale trzymając poziomicę "lewą ręką po prawej stronie, na pochyłym suficie", zejdzie mu sekunda zanim zorientuje się który to teraz lewy

[ethanak]

7 godzin temu, bjrk napisał:

nie widzę naturalnego domyślnego położenia

To zależy. Jeśli nie uprzesz się aby zmierzyć odległość od własnego pępka to okienko dalmierza wyznacza przód...

8 minut temu, SOYER napisał:

trzymając poziomicę "lewą ręką po prawej stronie, na pochyłym suficie", zejdzie mu sekunda zanim zorientuje się który to teraz lewy

Tak, ale na odmianę na pewno zorientuje się który to jest "pierwszy"

Zdaje się że przy następnym urządzeniu z serii postaram się jednak nadrukować brajlowskie oznaczenia na obu przyciskach... tylko może kolega @Jaha wypowie się czy jest mu to do czegokolwiek potrzebne.

[deshipu]

45 minut temu, ethanak napisał:

postaram się jednak nadrukować brajlowskie oznaczenia na obu przyciskach...

Wydaje mi się, że praktyczniejsze byłoby po prostu zrobienie wypustki na "pierwszym" przycisku. Albo odróżnienie go kształtem, na przykład przez zaokrąglenie narożników.

[ethanak]

1 minutę temu, deshipu napisał:

Wydaje mi się...

A mi się wydaje że nie przeczytałeś tego pięknego artykułu który napisałem...

Przecież ja nie zamieściłem żadnych opisów kształtów klawiszy czy mechanicznej konstrukcji całości (z wyjątkiem mocowania dalmierza), pozostawiłem to inwencji osoby która to będzie konstruować. Wręcz napisałem, że użyta przeze mnie obudowa nie nadaje się do tego celu (w podtekście: również klawisze, mocowania głośnika i tym podobne szczegóły). A cała dyskusja rozpoczęła się od stwierdzenia kolegi @SOYER jakoby w opisach należało użyć numerków zamiast lewy-prawy...

9 minut temu, deshipu napisał:

praktyczniejsze byłoby po prostu zrobienie wypustki na "pierwszym" przycisku

Wiesz... następne ustrojstwo (właśnie się drukują fragmenty konstrukcji) będzie miało dwa klawisze które bardzo łatwo odróżnić po miejscu gdzie są (zerowanie, tryb, wyłącznik). Uważasz że ma jakikolwiek sens robienie jakichś wypustek? Jaka jest różnica w zapamiętaniu że "pierwszy klawisz to ten z wypustką" od tego że "pierwszy klawisz to ten bliżej brzegu"?

Aha, ja wcale nie żartuję, tylko czekam na odzew od tzw. "targetu" (który to target jak się zdążyłem zorientować już tu zaglądał i może się odezwie).

[deshipu]

A to ja przepraszam. Jakiś taki strasznie agresywny jesteś. Już nic nie mówię.

[ethanak]

11 minut temu, deshipu napisał:

Jakiś taki strasznie agresywny jesteś

E tam, nie zwracaj na to uwagi, po prostu bronię jako ten lew czy inny tygrys swoich racji

A kwestia tego, czy oznaczenia na klawiszach są potrzebne (w przypadku naprawdę niewielkiej ilości klawiszy - dwa lub trzy) jest dość ciekawa.

[SOYER]

41 minut temu, ethanak napisał:

kwestia tego, czy oznaczenia na klawiszach są potrzebne (w przypadku naprawdę niewielkiej ilości klawiszy - dwa lub trzy) jest dość ciekawa

Jeśli nie masz do czynienia z aktualnymi absolwentami(lub nie) przeróżnych szkół, to faktycznie możesz uważać, że takie oznaczenia są zbędne. 

Otóż nie są zbędne.

Choć to oczywiście uwaga natury ogólnej i niekoniecznie musi się tyczyć użytkowników akurat tego urządzenia.

Edytowano Lipiec 5, 2021 przez SOYER

[ethanak]

5 minut temu, SOYER napisał:

Jeśli nie masz do czynienia z aktualnymi absolwentami(lub nie) przeróżnych szkół, to faktycznie możesz uważać, że takie oznaczenia są zbędne. 

Oj, mam, mam... i z doświadczenia Ci powiem że w takich przypadkach dwa klawisze to co najmniej o jeden za dużo Zdziwiłbyś się gdybym CI pokazał, co zdałoby się inteligentny człowiek może wpisać mając do dyspozycji jedno pole oznaczone jako "adres e-mail klienta" i klawisz "wyślij" w aplikacji...

Tutaj jednak sytuacja jest trochę inna. Wizualne oznaczenia (np. kolorem) nie wchodzą w grę z oczywistych przyczyn. Z drugiej strony ludzie są przyzwyczajeni do klawiatur bez oznaczeń (owszem, klawiatura komputera ma znormalizowane markery klawiszy, ale dotyczą wyłącznie znaków, a taki "insert"[1] to wszędzie jest w innym miejscu). Poza tym w porównaniu ze skrótami klawiszowymi JAWS-a taki Emacs jest prosty...

Postawiłbym pytanie: czy dla tej konkretnej grupy docelowej konieczne są w tej sytuacji jakiekolwiek markery, czy wystarczy jednoznaczne określenie klawisza na podstawie jego położenia... szczególnie w przypadkach, kiedy na takie oznaczenie po prostu nie ma miejsca.

---

[1] Insert pełni rolę dodatkowego modyfikatora przy wywołaniu funkcji screenreadera