Wykrywanie obecności Grid-Eye AMG8833

[szczawiosław]

Potrzebuję pomocy z interpretacją algorytmu do czujnika Grid-Eye Panasonica (konkretnie posiadam AMG8833) umożliwiającego wykrycie obecności w pomieszczeniu. Producent w jednym z udostępnionych materiałów opisuje sposób postepowania, jednak są to informacje tak szczątkowe że nie jestem w stanie nic konkretnego z nich wywnioskować. Nie udało mi się także znaleźć przykładowych kodów implementujących podobną funkcjonalność. Wszystko co udało mi się znaleźć to „kamera termowizyjna” zrealizowana na różne sposoby i rozwiązania oparte o progi wartości co jest mało skutecznym rozwiązaniem.

Nie znalazłem bezpośredniego linku: https://drive.google.com/file/d/0B_piNicRDc_TbE5NcFNoZTNCM1U/view?usp=sharing

[marek1707]

Na jednej ze stron linkowanego dokumentu jest algorytm i to - jak rozumiem - z nim masz problemy. Zacznijmy od tego, że opisz go tutaj własnymi słowami, w punktach tak jak byś go zrealizował. Może to być także jakiś pseudokod, choć tekst jest chyba bardziej zrozumiały i można więcej wyjaśnić. To będzie niezły punkt wyjścia do dyskusji. My, żeby pomóc także musimy ten algorytm zrozumieć a części pewnie się domyślić. Zadanie nie wydaje się trudne. Masz jakiś inny pomysł?

[szczawiosław]

Żeby jakoś to ogarnąć będę wypisywał numery stron, bo algorytm pojawia się na jednej stronie, ale wcześniej pojawiają się informację jak zwiększyć dokładność odczytu, a z tym nie do końca wiem co zrobić. I żeby nie było wątpliwości jako klatkę rozumiem odczyt z całej matrycy oraz utworzoną tablice jej odpowiadająca, czyli 64 piksele ułożone w tablicy 8x8.

• Strona 3 – Jeżeli dobrze rozumiem co autor miał na myśli jest tutaj informacja o tym aby odczytaną klatkę zamienić na wypełnioną zadaną wartością i w ten sposób zwiększyć dokładność tła eliminując tym samym szumy. Tylko pojawia się pytanie czy ta wartość ma być ustawiona „na pałę” (np. odczytem z termistora, wg widzimisię programisty) , czy wyliczona (np. uśredniona wartość odczytanej klatki).

• Strona 5 – Nie bardzo rozumiem rolę tego 5 bitu: MAMOD. No i pojawia się ten wzór: Vo(t)={Vout(t)+ Vout(t-1)}/2, rozumiem że odczytuję dwie klatki i od nowszej odejmuje starszą i dziele przez 2, przesuwam indeks o jeden, odczytuje kolejną klatkę i ponawiam proces obliczeń, w ten sposób podnoszę dokładność odczytu z czujnika eliminując zakłócenia.

• Strona 9 – No i ten nieszczęsny algorytm. Na wstępie pojawia się pytanie czy/w jaki sposób zaimplementować informacje ze strony 3 i 5 . Chyba można uznać że wzór ze strony 5 pojawia się w czerwonej ramce, tylko w wersji bardziej rozbudowanej.

Pobieram 20 klatek (A), następnie dodaje do siebie każdy odpowiadający sobie piksel i sumę dziele przez 20 otrzymując jedną uśrednioną klatkę (B).

Kolejnym krokiem jest zrobienie średniej ze wszystkich pikseli z klatki (B). Teraz od każdego piksela odejmuje średnią i wyniki zapisuję do klatki ©.

Następnie poddaje ocenie każdy piksel z klatki © na spełnienie warunku >=1,0°C lub <1,0°C i w tym momencie pojawia się pierwsza wątpliwość. Bo pierwszy odczytany piksel determinuje zachowanie całego algorytmu. Jeżeli wejdę na którakolwiek ze ścieżek (1 albo 2) nie wracam już do tej oceny i wszystkie oceny wykonuję dla pierwszego piksela z klatki ©.

Kolejnym krokiem jest pobranie klatki (D) i obliczenie różnicy (D) – (B), otrzymuję (zależnie od ścieżki) wartość (E) bądź (G) i poddaje ją ocenie (odpowiednio zależnie od ścieżki: 0,75°C <= (E) < 0,75°C lub 1,0°C <= (G) < 1,0°C). Jeżeli wartość jest mniejsza od 0,75°C (dla (E)) bądź od 1,0°C (dla (G)) przechodzę do ścieżki 2. Czyli ponownie pierwszy odczytany piksel determinuje dalsze zachowanie.

Jeżeli jednak wartość spełnia warunek >=0,75°C bądź >=1,0°C przechodzę do oceny metodą czterech najbliższych sąsiadów. Rozumiem że biorę współrzędne ocenianego piksela i odpowiednio sprawdzam wartość pikseli w klatce (E) lub (G) z przesunięciem -1, +1, -8 i +8 (dla skrajnych pikseli ten warunek jest odpowiednio zmodyfikowany) stosując takie same kryteria oceny jak we wcześniejszym kroku. Zliczam sąsiadów spełniających ten warunek (czyli >=2 bądź <2) i decyduje ostatecznie czy czujnik wykrył obecność czy nie.

I teraz pojawia się kolejna wątpliwość, bo kieruje mnie na początek ścieżki 1 bądź 2, rozumiem że w tym momencie mogę podbić indeks dla klatki © i wykonać cały proces oceny dla kolejnego piksela.

Pojawia się u mnie wątpliwość czy przy każdej zmianie ścieżki podbijać indeks i przesuwać się do kolejnego piksela (nie tylko na zakończeniu pętli, ale też przy wcześniejszym przeskoku), oraz czy wykonywać ocenę klatki (E) i (G) dla piksela o tym samym indeksie co w klatce ©.

Kolejną wątpliwością jest [update background data]. Zakładam że background data to klatka (B). Całość rozumiem w taki sposób że pobieram klatkę (X), później sprawdzam w pierwszej kolejności wszystkie piksele w klatce © czy piksele spełniają warunek <1,0°C, jeżeli tak nową wartość tego piksela obliczam ze wzoru (B)*127/128+(X)/128 (oczywiście wartość obliczam z odpowiednim indeksem aby piksele sobie odpowiadały). Następnie sumuję wszystkie zaktualizowane piksele i dzielę otrzymaną wartość przez ich ilość, otrzymując średnią (Y). Kolejnym krokiem jest ponownie sprawdzenie klatki © czy piksele spełniają warunek >=1,0°C, jeżeli tak nową wartość tego piksela obliczam w analogiczny sposób do powyższego zastępując wartość z klatki (X), wartością (Y).

Moje wątpliwości budzi miejsce w algorytmie w którym musze wstawić tą funkcję.

Ostatnią wątpliwością jest to w jaki sposób należy to wszystko zapętlić, zakładając próbkowanie 1fps wykonanie całego algorytmu może zając ok 2min, a w tym czasie może się wiele zmienić w otoczeniu.

• Pozostałe strony są chyba pomijalne, bo opisują specyfikację czujnika.

[marek1707]

Na szybko:

Na stronie 3 opisana jest przykładowa procedura kalibracji pixeli. Musisz mieć przedmiot o dużej, jednolitej powierzchni o stałej i znanej temperaturze na całym obszarze jaki widzi czujnik. Pokazujesz mu tę rzecz, czytasz wyniki, uśredniasz za kilka ramek dla pozbycia się szumów a potem zapamiętujesz wzór odchyłek dla całej matrycy. Potem, gdy będziesz z nią pracował zawsze dodajesz te offsety, bo są to błędy stałe pixeli. Ta procedura jest oczywiście związana z daną sztuką czujnika, bo te błędy są charakterystyczne dla konkretnych "termometrów" w pixelach. To robisz tylko raz, np. po zakupie czujnika. Dobrze byłoby zapisać jego numer seryjny i wzór offsetów w jakiejś bazie danych na przyszłość, gdyby trzeba było czujnik wymienić na inną sztukę. Wtedy musisz też uaktualnić wzorzec błędów w oprogramowaniu systemu.

Bit MAMOD załącza uśrednianie dwóch kolejnych ramek. Ty tego nie widzisz, ale po włączeniu tej funckji to co odczytasz jest zawsze średnią z ramki najnowszej i poprzedniej. To oczywiście zmniejsza szumy o współczynnik 1/1.41, ale zwalnia odpowiedź matrycy. Jak to filtr. Nie rozumiem jedynie tego obrazka o uśrednianiu filtrem moving average 10 klatek przywołanego w tym samym kontekście na str 6. Czy jest tam gdzieś rejestr sprzętowego uśredniania dowolnej liczby klatek? Czy może tylko tak narysowali żeby zrozumieć ideę? Bo te dwa obrazki różnią się u samych podstaw. Ten na górze pokazuje, że dostajesz ramki z tą samą szybkością, ale każda jest uśredniona za dwie ostanie. Prz uśrednianiu np. za 10 ostatnich byłoby tak samo, też mógłbyś dostawać je z tą samą prędkością. Natomiast dolny pokazuje, że przy uśrednianiu za 10 klatek nie dostajesz każdej, tylko co 10. Hm..

Jeśli mechanizmu uśredniania większej liczby klatek nie ma w tym czujniku, to i tak nie ma znaczenia co jest na obrazkach. Ważne, jak działa bit MAMOD. Czy przy 10kl/s po jego włączeniu dostajesz nadal 10 czy tylko 5kl/s. Z górnego rysunku na str. 6 wygląda, że nadal 10.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[szczawiosław]

Dzięki wielkie, sporo to rozjaśniło. Odnośnie tej strony 6, w opisach jest że czujnik działa z 1 albo 10fps, a większą dokładność uzyskuje się przy 1fps. Wychodzi na to że ten 1fps to w rzeczywistości nadal jest 10 klatek tylko uśrednione do 1 klatki i dopiero na tym zrealizowano moving average.

Pozostaje nadal ten główny algorytm i sposób oceny kolejnych pikseli. Ale w nim chyba trzeba pobrać jeden piksel z ©, wykonać wszystkie operacje dla niego, jeżeli dojdzie się do końca ścieżki trzeba pewnie przesunąć indeks o jeden i zrobić znów całą ścieżkę. Tylko w którym miejscu w całości pojawia się aktualizacja tła?

[marek1707]

Jeżeli są tylko dwie możliwości, to te rysunki pasują.

Operacja z uaktualnianiem tła jest de facto dolnoprzepustowym filtrem IIR założonym na każdym pixelu osobno. Duża stała czasowa tego filtru (bo tylko ułamek procenta nowego wyniku bierzesz z ostatniego pomiaru a resztę z dotychczasowej historii pixela) pozwala na ciągłe "śledzenie" tła i dopasowywanie naszego wzorca do powolnego płynięcia temperatur związanych np. z przesuwaniem się słońca po pokoju czy pracą systemów CO. Zawsze więc "obraz odniesienia" jest dobrze uśrednionym, ale nie zafiksowanym na stałe widokiem otoczenia czujnika. To ma sens.

Wg mnie powyższe powinno być wykonywane po każdym wczytaniu nowej ramki, niezależnie od tego co robi główny algorytm. No i przy wykrywaniu ludzi praca 10fps jest chyba koniecznością, ew. z włączonym uśrednianiem za dwie ostatnie.

Na sam algorytm spojrzę w wolnej chwili.

[szczawiosław]

Nie jestem jeszcze pewien czy dobrze zrealizowałem główną pętle, ale wygląda na to że wszystko działa jak powinno. Muszę jeszcze wgryźć się trochę w główny algorytm aby to sprawdzić czy moje rozumowanie ma sens 🙂 no i trochę zoptymalizować cały kod.

Ale dzięki wielkie za pomoc.

[marek1707]

Ech, w pracy mnie przycisnęło i trochę o tym wątku zapomniałem. Czy możesz w kilku zdaniach opisać jak zrozumiałeś i jak zrealizowałeś algorytm? Pewnie idea jest w sumie dość prosta, ale rysunek wcale już taki nie jest - przynajmniej na pierwszy rzut oka. Opisanie podstawowego pomysłu na jakim bazuje wykrywanie ludzi na pewno zainteresuje paru forumowiczów, więc masz szansę na dobry uczynek dla społeczności 🙂 Takie czujniki są coraz powszechniejsze. Ja sam mam w szufladzie kilka kompletnych matryc termicznych 16x4 z optyką germanową i od dwóch lat leżą czekając na pomysł ich wykorzystania. Nie jest to jakaś rewelacja i kamerki się z tego nie zrobi, ale właśnie jakiś ciekawy czujnik to już może. Wykrywacz kota na szafie?

[szczawiosław]

Zastanawiałem się nad Omronami właśnie, ale bardziej o matrycy 4x4. Ale trochę stara konstrukcja, ciężko było znaleźć dystrybutora i chyba już przestali je produkować. No i z tą firmą mam mało pozytywne doświadczenia z czujnikami.

Odnośnie algorytmu, wrzucam „wygląd” matrycy (klatki) dla łatwiejszego zobrazowania:

Nie mam jeszcze zaimplementowanej kalibracji i uśredniania dwóch następujących po sobie klatek. No i będę używał tych samych oznaczeń co w algorytmie, chyba tak będzie łatwiej zrozumieć. Domyślnie znacznik obecności mam ustawiony że nikogo w pomieszczeniu niema i dopiero „pozytywny” rezultat algorytmu zmienia ten stan.

1. odczytuje klatkę (A) 20 razy;

2. sumuję wszystkie klatki (A) (odpowiadające sobie piksele) i wynik dziele przez 20. Otrzymuję uśrednioną klatkę (B);

3. sumuje wszystkie piksele z (B) i dzielę przez ich ilość;

4. odejmuję kolejno od każdego piksela w klatce (B) uzyskaną wcześniej średnią i wyniki zapisuję do odpowiednich pikseli klatki ©;

5. biorę piksel (i) z klatki © i sprawdzam który warunek spełnia: ©>=1°C/©<1°C;

6. na podstawie wyniku decyduję nad wyborem ścieżki (Human is in the pixel/Human is not in the pixel);

7. odczytuje kolejną klatkę (D);

8. wykorzystując klatkę (D) zamiast pobierania kolejnej (X), aktualizuje tło (B). Do określenia „ludzkich” i „nieludzkich” pikseli wykorzystuje dane z klatki © i warunek ©>=1°C/©<1°C;

9. odejmuję od wcześniej pobranej klatki (D) zaktualizowane tło (B), wynik zapisuje (E)/(G);

10. dokonuje kolejnej oceny (zależnie od ścieżki na warunek: (E)>=+0,75°C/(E)<+0,75°C albo (G)>=1°C/(G)<1°C) ale tylko dla piksela o tym samym numerze (i) dla którego dokonałem oceny w punkcie 5;

11. jeżeli piksel spełnia warunek (E)<+0,75°C albo (G)<1°C kończę przebieg, podnoszę (i) o 1 i wracam do punktu 5;

12. w przypadku kiedy (E)>=+0,75°C albo (G)>=1°C wykonuję sprawdzenie metodą „4 najbliższych sąsiadów” dla i-1, i+1, i-8, i+8 (dla pól skrajnych odpowiednio modyfikuję ten warunek), wykorzystuję takie samo kryterium oceny jak w punkcie 10 i zliczam piksele które go spełnią (s);

13. sprawdzam warunek (s)>=2/(s)<2, jeżeli (s)>=2 to ustawiam znacznik na „jest człowiek”, podnoszę (i) o 1 i wracam do punktu 5, w przypadku (s)<2 podnoszę (i) o 1 i wracam do punktu 5;

14. wykonuje całość 64 razy aby sprawdzić wszystkie piksele, po ostatnim przebiegu wysyłam komunikat, jeżeli chociaż raz pojawił się znacznik „jest człowiek” wysyłam taki komunikat, w przeciwnym wypadku wysyłam informację „nie ma człowieka”;

15. resetuje stan znacznika obecności;

16. wracam do punktu 3;

Odnośnie „Aktualizacji tła” zrealizowany algorytm wygląda następująco:

1. pobieram tablice (X) (w kodzie głównym zastępuje ją (D));

2. sprawdzam piksel (i) w tablicy © czy spełnia warunek ©<1°C, jeżeli tak to dla odpowiadającego mu piksela (i) w tablicy (B) wykonuje odpowiednie działanie. W przeciwnym wypadku podnoszę (i) o 1 i ponownie sprawdzam warunek. Wykonuje to dla wszystkich pikseli;

3. sumuję wszystkie zaktualizowane piksele i wynik dzielę przez ich ilość (jeżeli nie mam co sumować biorę poprzednią średnią, jeżeli jest to pierwsza aktualizacja tła to biorę średnią z punktu 3 z głównego algorytmu) otrzymując (Y);

4. dla wszystkich pikseli które nie spełniły warunku ©<1°C wykorzystuje wartość (Y) dla aktualizacji tła w tych pikselach wg odpowiedniego działania;

To chyba na tyle, cały program jest zapętlony od momentu wyliczenia ©. Wadą jest wolne działanie, cała pętla wykonuje się 7,52s, w tym czasie osoba może się przesunąć znacząco. No i zastanawiam się na czym mogę dokonać kalibracji.

[szczawiosław]

Trochę odświeżę temat.

Praktycznie wszystko już dział, ale trapi mnie jeden problem. Szukam łatwego sposobu na skalibrowanie czujnika i jego pikseli. Nie wiem o ile to podniesie skuteczność czujnika, ale nie mam pomysłu co może być użyte jako wzorzec temperatury. Może ktoś ma pomysł i pomoże 🙂

[marek1707]

Duży arkusz jednolitej tektury falistej zawieszony swobodnie w środku (z dla od zwykle zimniejszej ściany) w pokoju z wyłączonymi grzejnikami, zamkniętymi oknami w ponury dzień bez Słońca (dziś jest idealnie). Po 10 minutach dyndania ma temperaturę identyczną z powietrzem (można zawiesić obok termometr), jest chyba wystarczająco duży by czujnik widział tylko jego i kolor (współczynnik emisyjności) prawie identyczny ze skórą człowieka.