Aktywny System Monitorujący

[Szern]

Dnia 3.04.2024 o 16:26, ethanak napisał:

4 MB to tyle masz flasha, a 3MB to ustawiona maksymalna wielkość kodu. A że przypadkiem masz też 4 MB PSRAM... to umówmy się że to przypadek. Mój WROVER ma na przykład 8 MB PSRAM i 16 MB flasha... i jedno z drugim nie ma nic wspólnego.

SPI jest na flashu (bo jak inaczej?). Przecież zawartość PSRAM ginie po wyłączeniu zasilania więc jak sobie wybrażasz przechowywanie danych?

Aha, nie "coś w rodzaju" partycji tylko partycje. Nie rozumiem skąd te cośwtymrodzaje... na dysku w kompie też masz różne partycje, prawda?

Chyba wreszcie jako tako to sobie poukładałem.

Piszę o module ESP32-CAM AI Thinker (dwa rdzenie 240 MHz):

RAM - pamięć wewnętrzna ulotna (wykorzystywana przez program m. in. do przechowywania danych) 320 KB

Flash - pamięć zewnętrzna nieulotna (tu ląduje program) 4 MB

PSRAM (Pseudo Static RAM) - pamięć zewnętrzna ulotna (pamięć dynamiczna z wewnętrzną logiką odświeżającą więc z zewnątrz może być traktowana jak pamięć statyczna SRAM, może być wykorzystywana przez program, np. jako bufor dla zdjęcia) 2 MB

W praktyce mogę wykorzystać każdą z tych trzech pamięci do swoich celów (a przynajmniej jej część).

Tak na marginesie tematu, to chyba ostatecznie zdecyduję się pisanie dla ESP32 w C używając VSC z Platform IO. Chyba najbardziej mi odpowiada. Nie mogę natomiast dojść do ładu z żadnym SDK dla Pico, na razie za głupi jestem, ale uczę się i próbuję, więc kto wie? W przypadku Pico jako tako radzę sobie tylko z ArduinoIDE, ale ani to wygodne, ani nie pozwala wykorzystać wszystkich możliwości.

[ethanak]

Z kilkoma uwagami:

Pamięci RAM jest w rzeczywistości więcej, 320k to tyle ile mozesz wykorzystać.

Pamięci FLASH może być więcej, ale tylko 4 MB dla aplikacji.

Pamięci PSRAM też może być więcej, ale bezpośrednio można użyć tylko 4 MB.

[Szern]

1 minutę temu, ethanak napisał:

Z kilkoma uwagami:

Pamięci RAM jest w rzeczywistości więcej, 320k to tyle ile mozesz wykorzystać.

Pamięci FLASH może być więcej, ale tylko 4 MB dla aplikacji.

Pamięci PSRAM też może być więcej, ale bezpośrednio można użyć tylko 4 MB.

W sensie, to co podałem, to wielkości możliwe do wykorzystania przez użytkownika, natomiast "nadwyżki" wykorzystuje system?

[ethanak]

W przypadku RAM raczej odwrotnie - system bierze ok. 200k, Ty masz do dyspozycji co zostanie.

W pozostałych przypadkach (flash, psram) jest inaczej - ogólnie bezpośrednio możesz wykorzystać 4 MB (tyle ESP potrafi zmapować). Żeby dobrać się do reszty trzeba użyć funkcji typu "odczytaj/zapisz sektor". System w ogóle nie używa psram, flash to w praktyce tylko non-volatile i aplikacja.

Flash powyżej 4 MB można wykorzystać np. na filesystem.

[Santiago]

@Szern mam zamiar zrobić to samo. Ale muszę się wiele nauczyć, pod koniec roku może 'wystartuję' . Pewnie pomożesz 

[Szern]

3 godziny temu, ethanak napisał:

W przypadku RAM raczej odwrotnie - system bierze ok. 200k, Ty masz do dyspozycji co zostanie.

To tłumaczy, dlaczego jedne źródła podają 520 MB RAM, a inne 320 MB.

[Szern]

27 minut temu, Santiago napisał:

@Szern mam zamiar zrobić to samo. Ale muszę się wiele nauczyć, pod koniec roku może 'wystartuję' . Pewnie pomożesz 

Pewnie, że pomogę, jeśli będę potrafił

[matsobdev]

W kwestii czujników: coś takiego. Przynajmniej łatwo zamknąć i uszczelnić w gotowej obudowie. Na ile to działa, nie mam pojęcia.

[Szern]

2 godziny temu, matsobdev napisał:

W kwestii czujników: coś takiego. Przynajmniej łatwo zamknąć i uszczelnić w gotowej obudowie. Na ile to działa, nie mam pojęcia.

Dzięki, wygląda interesująco, wypróbuję.

[Szern]

Kolejna przygoda z alarmem. W dalszym ciągu jestem poza domem (niedługo czeka mnie szpital, a później może uda się wrócić na wieś).

Na niespełna 24 godziny padło Pico.

Przypominam jak działa asm. PicoW pracuje jako centralka - bezprzewodowo podłączone jest do internetu i korzysta z API modemu Huawei do odbierania i wysyłania SMS-ów. W internecie korzysta z FTP, wrzucając pliki na mój serwerek. SMS-y jedynie odczytuje (służą do sterowania). Poza tym steruje bezpośrednio czterokanałowym systemem przekaźników (aktywowanych stanem niskim). Dwa przekaźniki obsługują zasilanie modułów ESP32-CAM, dwa zasilanie syren.

ESP komunikują się przez Wi-Fi (bez pośrednictwa Pico) przez FTP - pobierają ustawienia, wysyłają zdjęcia.

W pewnym momencie padło Pico. Jednak obie kamery działały w tym czasie idealnie. Czyli PicoW, kiedy nie działa, ale generuje wtedy na pinach stan niski (bo inaczej przestałby działać przekaźnik i kamery).

Pico samo wstało, jednak zaniepokoiłem się i napisałem prosty skrypt, znajdujący różnice w obrazie pomiędzy dwoma zdjęciami (aktualnym i poprzednim). Poniżej wersja skryptu w PHP zapisująca różnice do logu (plik tekstowy).

#!/usr/bin/php

<?php

date_default_timezone_set('Europe/Warsaw');

$folder = 'archiwum';
$path = '/home/www/asm/';
$logi = $path . 'logi/';

$i=0;
    for ($j=0; $j<2; $j++) {
        $mask = 'k' . $i + 1 . '*.jpg';
        $gl = $path . $folder . '/' . $mask;
        $images = glob($gl); // hamulec
        $imagesr = array_reverse($images);
        $im = $path . $folder . '/' . rawurlencode(basename($imagesr[$j]));
        $image[$i][$j] = new imagick($im);
        $image[$i][$j]->setImageFormat('jpg');
        $image[$i][$j]->setOption('fuzz', '8%');
        $image[$i][$j]->setImageType(Imagick::IMGTYPE_GRAYSCALEMATTE);
        $image[$i][$j]->readImageBlob($image[$i][$j]);
        switch ($image[$i][$j]->getImageWidth()) {
            case 320: //x240
                $xy = array(5,64,5,48);
            break;
            case 640: //x480
                $xy = array(8,80,8,60);
            break;
            case 800: //x600
                $xy = array(8,100,8,75);
            break;
            case 1024: //x760
                $xy = array(16,64,10,76);
            break;
            case 1280: //x1024
                $xy = array(10,128,8,128);
            break;
            case 1600: //x1200
                $xy = array(10,160,10,120);
            break;
        }
        for ($y = 0; $y < $xy[2]; $y++) {
            for ($x = 0; $x < $xy[0]; $x++) {
                $temp = new imagick();
                $temp->readImageBlob($image[$i][$j]);
                $temp->cropImage($xy[1], $xy[3], $x * $xy[3], $y * $xy[3]);
                $kawalek[$i][$j][$x][$y] = new imagick();
                $kawalek[$i][$j][$x][$y]->readImageBlob($temp);
                $temp->destroy();
            }
        }
    }

    for ($y = 0; $y < $xy[2]; $y++) {
        for ($x = 0; $x < $xy[0]; $x++) {
            $result[$i][$x][$y] = $kawalek[$i][0][$x][$y]->compareImages($kawalek[$i][1][$x][$y], 1);
            $kawalek[$i][0][$x][$y]->destroy();
            $kawalek[$i][1][$x][$y]->destroy();
        }
    }

$suma = array(0,0);
$maks = array(0,0);

    for ($y = 0; $y < $xy[2]; $y++) {
        for ($x = 0; $x < $xy[0]; $x++) {
            if ( $result[$i][$x][$y][1] > $maks[$i] ) {
                $maks[$i] = $result[$i][$x][$y][1];
            }
            $suma[$i] += $result[$i][$x][$y][1];
        }
    }

$srednia[0] = (int)($suma[0]/($xy[0]*$xy[2]));
$srednia[1] = (int)($suma[1]/($xy[0]*$xy[2]));

file_put_contents($logi . 'p_log.txt', date("Ymd H i s", time()) . "\n" . 'średnia 1: ' . $srednia[0] . '  ' . 'maksimum 1: ' . $maks[0] . "\n", FILE_APPEND);

?>
  

Jest uruchamiany skryptem, który cały czas monitoruje informacje przychodzące z Pico i ESP (uruchamianym z Crone'a).

Użyłem biblioteki imagemagic do wyznaczania różnicy pomiędzy tymi samymi punktami dwóch obrazków. Ponieważ to kolorowe jpg - to najpierw lekko je rozmyłem (8%), a później przekonwertowałem paletę na odcienie szarości. Jednak nie miało to większego sensu, zmiany oświetlenia (np. słońce i chmury) powodowały duże i częste zmiany.

Przykład:

zdjęcie pierwsze:

zdjęcie drugie:

różniące się pixele (na czerwono):

A tutaj prosty skrypt porównujący dwa ostatnio dodane zdjęcia z określonego folderu (efektem jego działania są powyższe obrazy):

<?php

// start ustawień

$folder = "archiwum";
$path = "/home/www/asm/";
$mask = "k2*";

// koniec ustawień

$gl = $path . $folder . "/" . $mask;

$images = glob($gl);
$imagesr = array_reverse($images);

for ($i=0; $i<2; $i++) {
    $im = $folder . "/" . rawurlencode(basename($imagesr[$i]));
    $image[$i] = new imagick($im);
    $image[$i]->setImageFormat('jpg');
    $image[$i]->setOption('fuzz', '8%');
    $image[$i]->setImageType(Imagick::IMGTYPE_GRAYSCALEMATTE);
    $image[$i]->readImageBlob($image[$i]);
}


$result = $image[0]->compareImages($image[1], 1);
$result[0]->setImageFormat("png");
file_put_contents($path . 'difference.png', $result[0]);
file_put_contents($path . 'diff01.jpg', $image[0]);
file_put_contents($path . 'diff02.jpg', $image[1]);

echo '<!DOCTYPE html>
<html>
  <head>
    <title>Porównywanie zdjęć</title>
    <meta charset="utf-8">
  </head>
  <body>
    <img src="diff01.jpg" />
    <img src="diff02.jpg" />
    <img src="difference.png" />
    ';
echo $result[1] ;
echo '
  </body>
</html>';

?>

Pociąłem więc zdjęcie na mniejsze kawałki, dla każdego kawałka porównuję zmiany i liczę średnią tych zmian. Po wyznaczeniu bezpiecznego progu zmian, kiedy co najmniej jeden kawałek zmieni się dużo bardziej niż pozostałe (średnia), prześlę sobie wiadomość (i ewentualnie w przyszłości uruchomię syrenę).

Wiem, że odkryłem ponownie koło, ale wydaje się to działać bardzo dobrze i jest bardzo odporne na małe zakłócenia, dużo bardziej niż czujki. Zmieniając wielkość analizowanego kawałka mam możliwość skalowania "czujności" systemu, jeśli mam odpowiednio duży kawałek, to nie reaguje na małe obiekty (ptaki, zwierzęta), a reaguje na człowieka. Z tym reagowaniem, to jestem jeszcze w fazie testów (jednak na razie to działa obiecująco).

Pozwoliłoby to zrezygnować definitywnie z czujek, w wykorzystać tylko kilka tanich modułów ECP32-CAM (które okazały się zaskakująco niezawodne, w przeciwieństwie do Pico). Mój serwer (chmura Oracle), w przypadku analizy z dwóch kamerek (zdjęcia wysyłane średnio co 14 sekund każda, na serwerze sprawdzane i analizowane co sekundę - załączony kod uruchamia się jedynie po przesłaniu zdjęcia) ma przy tym obciążenie maksymalnie 1,5%, czyli z wydajnością nie jest najgorzej.

Jestem pozytywnie zaskoczony, bo okazało się to proste, angażuje mało zasobów i nie wymaga użycia sieci neuronowych (a i tak się samo uczy, w uproszczeniu: będzie dostosowywać progi alarmu do warunków na bazie doświadczeń).

Jak zwykle: krytyka mile widziana!

 

[Szern]

Melduję posłusznie, że znowu jestem.

Poważne problemy zdrowotne wyhamowały bardzo mocno projekt, ale chyba wracam do życia.

System się sprawdził, mam sporo wniosków. Ze względów finansowych (szorowałem po dnie) projekt rozwija się skromnie i niskobudżetowo, ale jednak się rozwija. Konkrety w najbliższych dniach, na zachętę filmiki:

https://movies.metricsmaster.eu/w/4yUX7ZYtHdkFsKFKbyyPFb

https://movies.metricsmaster.eu/w/pqCtSLiMQ5Wrvwdk3cCFMf

Szczegóły wkrótce.

[Santiago]

Zdrowia i czekam na ciąg dalszy. 

[Szern]

Dzień dobry,

Z pewnym opóźnieniem (problemy zdrowotne) wracam do tematu. Na początek: pożegnanie z pierwszym prototypem alarmu.

Najpierw chciałbym serdecznie podziękować wszystkim, który pomagali mi czynnie lub biernie w tym wątku, doradzali, krytykowali albo kibicowali. Bez Waszej pomocy nie poradziłbym sobie z tym, a możliwe, że zabrakłoby mi motywacji - szczególnie dziękuję za słowa otuchy w chwilach zwątpienia.

Było pięć modułów z czujkami PiR i kamerami ESP32-CAM.

To jest moduł z dwoma czujkami, które "patrzą" w dwóch kierunkach.

Moduł taki dodatkowo wyposażony był w słabą syrenę z diodami (bardziej, żeby pokazać, że coś pilnuje niż robić realny, hałaśliwy alarm. Sąsiadom nie przeszkadzało, potwierdzili po roku, że praktycznie alarm jest niesłyszalny u nich.

Strzałem w dziesiątkę okazały się obudowy wycięte ze sklejki, połączone zwykłym przezroczystym silikonem. Dzięki niemu mogłem dokładnie ustawić płaszczyzny z czujnikami i kamerami aby "patrzyły" dokładnie w kierunku, w którym chciałem. Było to szczególnie ważne w przypadku czujników PiR.

Drugi typ modułu to czujka i kamerka w jednym.

Tak wygląda taki moduł od środka.

Nie był całkowicie hermetycznie zamknięty, chociaż się starałem. Na ekranowaniu kamerki widoczna jest delikatna śniedź. Zaszkodziło to kamerce - czasem działa, a czasem nie - jak jej się podoba. Poza tym, kamerka nie miała tutaj kondensatorów filtrujących, teraz już je stosuję.

A to całość centrali.

Od lewej: piezo-głośniczek wysokotonowy (odstrasza myszy), moduł przekaźników sterowanych napięciem 3V3, Raspberry Pico, a na dole zasilanie 5 V.

Centrala pozostaje w niezmienionej formie, ulega jedynie wymianie oprogramowanie i podłączone peryferia.

Bardzo krótko podsumowując, czujniki PiR nie sprawdziły się w ogóle, moduły ESP32-CAM okazały się co najmniej wystarczające, połączenia, które w trakcie pracy nad projektem wyewoluowały w takie złącza, okazały się strzałem w dziesiątkę, chociaż musiałem metodą prób i błędów (a są jakieś inne?) nauczyć się je montować. Co do centrali, to po drodze wymieniłem zasilacz, trochę poprawiłem oprogramowanie w Pico (okazało się, że problemy stwarzały wyłącznie moje błędy, płytka sprawuje się w dalszym ciągu bez zarzutu). Również moduł przekaźników sprawdza się w doskonale, chociaż straciłem mnóstwo nerwów zanim wpadłem na oczywiste rozwiązanie, że do podłączenia pinów na płytce najlepiej sprawdzają się takie kabelki.

PiR-y są niedokładne, bardzo kłopotliwa jest ich regulacja, ponieważ należałoby je wyregulować po ich zamocowaniu we właściwym miejscu, a reguluje się je dwoma potencjometrami montażowymi na płytce przy czujniku i są kompletnie nieodporne na warunki zewnętrzne - łapią każdą odrobinę wilgoci, która zabija je niemal natychmiast. Z siedmiu przetrwały jako-tako dwa. Poza tym one się po kilku miesiącach "rozkalibrowują" więc nawet te dwa, które się nie zniszczyły stały się kompletnie bezużyteczne bez rozbierania czujek i ponownej kalibracji.

ESP32-CAM jest doskonałym, niedocenianym modułem. W kolejnych wpisach podzielę się jego oprogramowaniem. Nie jest może bardzo trwały, ani bardzo szybki, ale odpowiednio zabezpieczony pracuje bardzo dobrze, zapewniając akceptowalną jakość i szybkość. Gdyby nie to, że obecnie funkcjonuję bardzo skromnie wymieniłbym mu obiektywy. Jedyną wadą jest to, że nie mam do niego na razie obiektywu na podczerwień.

Złącza Superseal są absolutnym hitem, łączą naprawdę dobrze, są hermetyczne i wymagają relatywnie niewiele pracy w stosunku do efektu.

Okablowanie pozostaje, choć będzie wykorzystana jedynie jego część.

Pico sprawdziło się całkowicie, ale dopiero kiedy napisałem proste oprogramowanie w C i zrezygnowałem ze sterowania SMS-ami przez modem Huawey - wprawdzie to moje błędy w oprogramowaniu były winą, a pisanie tego w Pythonie idiotyzmem, ale MQTT jest nieporównywalnie szybsze i wygodniejsze niż SMS-y.

Przekaźniki, pod warunkiem zapewnienia odpowiedniego prądu i dobrych złącz działają bezproblemowo (czego nie mogę powiedzieć o podobnym, dwukanałowym przekaźniku zakupionym gdzie indziej - pierwszy kanał padł po dwóch tygodniach, a drugi w drugim miesiącu).

Bardzo ważne okazało się zapewnienie odpowiedniego zasilania całemu układowi, po wymianie wtyczkowego zasilacza USB na ten opisany powyżej, problemy ze stabilnością układu zniknęły.

Obudowy spełniły swoje zadanie, a niezabezpieczona sklejka jest w stanie wytrzymać ponad rok w niesprzyjających warunkach atmosferycznych.

Żegnam więc pierwszy prototyp. Spełnił swoje zadanie - nikt się nie włamał, po wsi rozeszła się wieść, że dom aktywnie się chroni. Był daleki od doskonałości, przysporzył mi mnóstwo problemów, ale zapewnił spokojny sen, kiedy byłem poza domem i bardzo dużo się przy tym nauczyłem.

W następnym wpisie, pokażę, jak wygląda nieco przejściowa, niskobudżetowa wersja alarmu oparta na nieco innych założeniach.

Edytowano Październik 9, 2024 przez Szern

[matsobdev]

Ja bym postawił na takie albo takie przewody. Przewody typu "tęcza", 40 sztuk za 5-6 zł, bez żadnych oznaczeń AWG to loteria. Sprawdź magnesem. Moje, kupione kiedyś i gdzieś magnes przyciąga. I przewód i złącze. Zużywam je, nie ma tego dużo, ale wyświetlacz podłączony, nic nie robione i nie działa na drugi dzień. Wymiana przewodów i jest ok. Karta pamięci, tutaj już przewody przylutowałem, podobnie. To już wziąłem, zdjąłem osłonki z przewodów, docisnąłem zakucie żyły w konektorach i działa. Dosłownie jak się rusza izolacją, to linka też w fabrycznym zarobieniu się rusza.

Też już chyba w tym wątku było wspomniane. Jak widać, chyba jesteś szczęśliwym posiadaczem zaciskarki tulejek, to złącza ARK o rastrze 2,54 mm też kupisz.

Edytowano Październik 9, 2024 przez matsobdev

[Szern]

29 minut temu, matsobdev napisał:

Ja bym postawił na takie albo takie przewody. Przewody typu "tęcza", 40 sztuk za 5-6 zł, bez żadnych oznaczeń AWG to loteria.

Powiem Tobie, że użytkuję już trzecią paczkę kabelków justPi (wszystkie z Botlandu) i dotąd żadnych problemów z nimi nie miałem. Mam podpięty wyświetlacz do starego Pi i od ponad dwóch lat go używam. Odpinam, przenoszę, znowu zapinam. Żadnych kłopotów. Sporo majstrowałem na płytkach stykowych - również żadnych problemów, poza normalnymi, jak to na takich płytkach. Ale pewnie masz rację, ja nie mam doświadczenia.

Jak odróżnić przyzwoite przewody (AWG?) od innych? Porównując to z tym trudno mi dostrzec różnicę. Mam kierować się wyłącznie ceną?

Zaciskarkę faktycznie pokochałem, używam jej do każdego końca dowolnego kabla czy trzeba czy nie trzeba.