Jak zrobić samemu videodomofon ?

[kolorado]

1) Co do kamery to można zastosować IP. Ale problem raczej będzie z przesłaniem dźwieku w obie strony. Trzeba by miec położone po dwa dobre kable koncentryczne.

Ale po co ? Kamera z dwukierunkowym audio załatwi sprawę. Tylko pytanie po co RPi wtedy?

[szczukot]

Hmmm. A co to jest "kamera z dwuierunkowym audio" ? Bo wychodzi ze to juz samo w sobie jest videodomofonem ?

 

Co do tej kamery IP, to chodziło o to, aby RPI był wewnątrz domu. No i oczywiście odpowiadałby wtedy za przesył dźwięku, nagrywanie zdjęć, sterowanie furtką itp.

 

Fantom

[kolorado]

Hmmm. A co to jest "kamera z dwuierunkowym audio" ?

Np. coś takiego: http://www.tp-link.com.pl/products/details/?categoryid=230&model=TL-SC3230. To przykład, dość sporo kamer ma taką funkcję.

 

Bo wychodzi ze to juz samo w sobie jest videodomofonem ?

Dokładnie tak, to jest rozwiązanie które zaproponowałem jako alternatywa na samym początku. Pozostaje jedynie elektrozamek i przycisk wywołania. no i oprogramowanie, ale jak pisałem można skorzystać z dedykowanego wywoływanego w odpowiednim momencie. Napisanie programu będzie proste. Oczywiście do tej funkcji (przycisk + zamek) może być RPi, może być cokolwiek innego (np. DS2408 na 1-wire). Wystarczy tylko program który będzie się łączył i odczytywał stan przycisku. Jeśli przyciśnięty - uruchamia dedykowane oprogramowanie do kamery. Pozwala też wpuścić delikwenta przez sterowanie zamkiem. Odpada oprogramowanie streamingu A/V w obie strony. Można też sterowanie zrobić przez Integrę - podłączyć pod wejście i wyjście. Nawet głupi SMS da nam znać że ktoś dzwoni i uruchomić aplikację dedykowaną. Straszny pająk, ale banalny do wykonania...

[szczukot]

No niby tak. Ale taka akmera z tego ci widze tez tania nie jest. a wbrew pozotom może być dużo większy problem z naspisaniem softu do połączenia całości (A/V/sterowanie). Odpada tez mozliwość nagrywania osób dzwoniących. Problem z identyfikacją, że ktoś dwoni przyciskiem. Gdzieś to i tak trzeba by podłączyć do jakiegoś komputerka. Więc chyba i tak RPI musiało by byc (lub coś podobnego)

 

Na razie powalczę z wersją pierwotną. Czyli RPI B + kamera + głośnik/mikrofon przez kartę dźwiekową USB. Jak sie uda, to alternatywą będzie wersja RPI A + WIFI USB (dla tych bezkablowych)

[szczukot]

No i pierwszy wieczór za mną.

Podłączyłem kamerkę do RPI B.

Temat zacząłem od przesyłu obrazu. Jak narazie masakra. Rozwiązań w sieci sporo, ale ogólnie podzielonych na kilka grup. Wczoraj bawiłem się "motion" a w sumie przeróbką "motion-mmal". Bez efektu. Nie udało mi się uzyskać żadnego real-time. Zacznę więc przeglądanie kolejnych rozwiązań. Na pierszy rzut pójdzie dedykowany raspivid.

 

Fantom

[starki]

Nie udało mi się uzyskać żadnego real-time.

 

Jak duże były opóźnienia?

[szczukot]

Co najmniej 1 sek + bardzo małe fps (maks 5)

Teraz kombinuje z ffmpeg i raspivid. Ale same przekompilowanie ffmpeg to kilka godzin !

 

Fantom

[starki]

Co najmniej 1 sek + bardzo małe fps (maks 5)

Czyli na zsynchronizowanie dźwięku z obrazem raczej nie ma szans. Przez raspivid chwalą się że spokojnie idzie 30fps 1080p.

[szczukot]

A możesz pokazać gdzie tak piszą ?

Bo pytanie czy chodzi o streaming czy o nagrywanie lokalne.

 

Po 4 godzinach kompilacji ffmpeg - wysypało się

Masakra.

 

Chyba zacznę od przeysłu xieku w obie strony - to też nie będzie łątwe, ale chyba prostsze jednak

 

Fantom

[starki]

Faktycznie nie zwróciłem uwagi, że problem jest tylko ze streamingiem...

Mam nadzieje, że tego http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=63276&p=468491#p468491 nie sprawdzałeś i okaże się rozsądnym rozwiązaniem

 

Inne rozwiązania to:

http://rpiquadcopter.blogspot.fi/2014/06/raspberry-pi-camera-module-video.html

Jednak to już byłby większy kłopot, żeby to fajnie potem oprogramować.

[szczukot]

To pierwsze to nawet odpałiłem. Działa z lagami. To też jest na motion mmal.

Te drugie rozwiazanie oparte na Gstreamer mam zapisane - do sprawdzenia.

Ogólnie w sieci jest sporo różnych tematów, ale opierają się chyba na 4 czy 5 rozwiązaniach. I ogólnie dwóch streamach (mjpeg lub h264).

Musze przetestować wszystkie z różnymi kombinacjami

 

Fantom

[starki]

W sumie to do celów domofonu 5 fps spokojnie wystarczy, byleby lag nie był za duży. Może szkoda na razie na siłę walczyć z tym.

[szczukot]

Postanowiłem testować wszystkie kombinacje jakie znajde.

Na pierwszy rzut poszedł mjpgstreamer (ver 182) + raspistill.

Działa. Bez opymializacji większej da rade jakieś 10 fps 640x480. Opoźnienie na pewno poniżej 1 sek.

Teraz kolej na dwie kolejne modyfikacje - czyli użycie dwóch innych mjpegstremerow jakie znalazłem + rapistill

 

Fantom

[szczukot]

Kolejny test z wersja experimental. Moim zdaniem dużo lepsze efekty i działa. Przykładowe 640x480 i 15 fps, małe lagi, obciążenie procka około 5%. To może być dobre wyjście do dalszych testów tej kombinacji.

Abym się nie pogubił, kolejne do testowania :

1) MMAL MOTION

2) RaspiMJPEG (ale to chyba tylko nakładka na poprzednika)

3) Różne kombinacje z raspivid (netcat, vlc, rtmp, gstreamer itd)

4) Niszowe rpi-mmal-opencv-modetect i http://sjj.azurewebsites.net/?p=1251 . Ale tu musi mi ktoś pomóc : jak zrobić aby z stdout szedł stream do netu ?

 

Fantom

Edytowane 18 Grudnia 2014 przez szczukot

[szczukot]

Kolejne testy : mmal-motion.

Mozliwości softu bardzo duże, ale sa dwie wady lagi i fps rzędu maks 5 klatek/sek. Teoretycznie do obsługi przez internet (np smartphone odbieram poza domem) to może wystarczyc. Ale jak w domu na tablecie zobaczę to za wooolnoooo.

Do tego problemy z odtwarzaniem w przeglądarkach. Nie działa mi np na chrome czy na IE. Poszło bez problemu na Firefox. Trzeba sie pobawić więcej i sprawdzić.

 

Fantom

Edytowane 17 Grudnia 2014 przez szczukot

[szczukot]

RaspiMJPEG też działa - ale tylko kilka fpsów udało mi się uzyskać. Trudno więc na razie coś więcej powiedzieć.

Chyba wszystko zrobiłem co było na MJPEG.

 

Czas na h264.

Ogólnie zostało mi do zabawy ffmpeg - zaczynam więc kompilacje.

 

5 godzin później ....

Nie udało mi się uruchomić ffmpeg z nginx. Wszytsko niby ok, ale obrazu na żadnej przeglądarce nie mam.

Uruchomiłem ffmpeg z crtmpserver. Działa, ale opóźnienie rzędu 1 s, i start po kilku sekundach. Nie wiem o co chodzi, ale na w sieci znalazłem ten sam problem. Nie mam czasu się z tym bawić.

Ale może się okazać, że dla przekazania dźwięku trzeba będzie wrócić do tej metody przesyłania danych. Wtedy w jeden strumień mozna wpiąć audio+video.

 

Daję tez linki do gotowych aplikacji (do potestowania) :

https://github.com/mpodroid/door-berry

https://github.com/bne/doorbell

 

Fantom

Edytowane 17 Grudnia 2014 przez szczukot

[szczukot]

No i kolejne tematy.

Z teo co widzę, to problem przesyłu video będzie najmniejszym problemem

Zostały jeszzce co najmnie dwa tematy do sprawzdenia :

1) przesył dźwięku w obie strony

2) przycisk dzwonka

 

No i już widzę, że ten drugi będzie sporym problemem ! Bo zwykła notyfikacja np za pomocą https://developer.android.com/google/gcm/index.html się nie sprawdzi. Nie udało mi się znaleźć czasu, ale może to trwac chyba nawet kilka minut. Przy domofonie takie opóźnienie odpada. Zostaje więc

1) zrobienie w domu "zwykłego dzwonka" i do tego ewentualnie pushover na komórke

2) na stale np tablet, cały czas zasilany i napisać włsną obsługę dzwonka do niego.

3) wysłanie SMSa z RPi - pośrodku obu powyższych rozwiązań, ale czas otrzymania może być mocno losowy jednak.

 

Fantom

Edytowane 17 Grudnia 2014 przez szczukot

[szczukot]

Jak widać, temat raczej nie jest prosty.

Do ogarnięcia trzy tematy

1) video - tu mam jakieś rezultaty

2) audio full duplex

3) przycisk dzwonka - problem z opóźnieniami - jak pisałem wcześniej

4) otwieranie furtki (to będzie chyba najprostsze)

 

Trochę zastanawiam się jeszcze nad punktem 1. W sumie juz go zrealizowałem, ale zastanawiam się, czy ogólnie lepszym rozwiązaniem nie jest zastosowanie osobnej kamery IP. Takiej zwykłej + ewentualnie dodatkowy naświetlacz IP. Cenowo nie będzie dużo więcej niż kamera do RPi, a mozliwości będa spore i to chyba większe niż to co wydusimy z RPi. Musze to przemyśleć. W takim wypadku dałbym ta kamere poza videodomofonem (gdzieś na domu). A wtedy przy furtce wystarczy zwykła kaseta domofonowa (głośnik, mikrofon, przycisk) a w niej RPi.

 

Fantom

Edytowane 18 Grudnia 2014 przez szczukot

[starki]

Jak widać, temat raczej nie jest prosty.

Do ogarnięcia trzy tematy

1) video - tu mam jakieś rezultaty

2) audio full duplex

3) przycisk dzwonka - problem z opóźnieniami - jak pisałem wcześniej

4) otwieranie furtki (to będzie chyba najprostsze)

 

Trochę zastanawiam się jeszcze nad punktem 1. W sumie juz go zrealizowałem, ale zastanawiam się, czy ogólnie lepszym rozwiązaniem nie jest zastosowanie osobnej kamery IP. Takiej zwykłej + ewentualnie dodatkowy naświetlacz IP. Cenowo nie będzie dużo więcej niż kamera do RPi, a mozliwości będa spore i to chyba większe niż to co wydusimy z RPi. Musze to przemyśleć. W takim wypadku dałbym ta kamere poza videodomofonem (gdzieś na domu). A wtedy przy furtce wystarczy zwykła kaseta domofonowa (głośnik, mikrofon, przycisk) a w niej RPi.

 

Fantom

 

Ja u siebie mam to zorganizowane tak:

Mam kiepski videodomofon i jestem wpięty w niego Raspberry. Jak dzwonek zadzwoni to kamera zewnętrzna na budynku robi stop-klatkę i wysyła komunikat pushover'em. Jak jestem w domu to audio mam przez stary videodomofon a jak jestem poza domem to widzę w telefonie kto dzwoni i ewentualnie mogę otworzyć zdalnie furtkę też przez raspberry.

Bardzo mi nie pasuje ten stary videodomofon i dlatego podpatruję ten wątek. Bo zastanaiwam się jak całość zastąpić i w miejsce videodomofonu wstawić tablet.

 

Co do opóźnień dzwonka to faktycznie czasami się zdarzają (próbowałem przez hangouts i pushover). Najlepiej wypada pushover ale u mnie około 95% dzwonków jest niemal natychmiast a 5% ma opóźnienia. Jednak i tak musiałby być zamontowany anologowy dzwonek - jednak to nie problem.

Kamera IP jaką mam zamontowałem właśnie po to bo z kamerki w videodomofonie nie widziałem nic. Jedna stop-klatka mówi mi wszystko

Co do dźwięku full duplex i dzwonienia w czasie rzeczywistym to przy zastosowaniu raspberry z jakimś oprogramowaniem do voice IP powinno dać się to osiągnąć - jednak nie mam doświadczenia w tym temacie.

Osobiście najlepiej by mi pasował domofon na RPi lub coś podobnego z kamerą szerokokątną+dźwięk i to wszystko wkomponowane w OpenHaba .

[szczukot]

No własnie chciałbym zrobić coś fajnego Ale prosto nie będzie. Może zacznę od czegoś, gdzie nie ma za dużo możliwości. Czyli obsługę przycisku dzwonka. Sprawdzę tu z 5 rozwiązań (więcej nie znaalzłem) :

1) pushover do smartphona (różne platformy)

2) push przez google do smartphona (tylko android chyba)

3) MQTT

4) SMS

5) zwykły dzownek w domu (ale całość i tak obsługiwana przez RPI, bo oprócz tego może zastosować wcześniejsze opcje). To rozwiązanie ma sens tylko wtedy, gdy 4 poprzednie będą miały za duże lagi.

 

Fantom

Edytowane 19 Grudnia 2014 przez szczukot