Aktywny System Monitorujący

[ethanak]

Raczej nic trudnego. Zacząłbym od wykrywania człowieka przez OpenCV, dostajesz prostokąt, ustawiasz na środek w poziomie i jakieś 75% w pionie, ustawiasz serwa (patrz zabawki dla kota) I odpalasz laser

[Szern]

System jednak sprawia trochę problemów. Albo ptaki wiją gniazdo przy jednej z czujek albo ulega ona zawilgoceniu. W połączeniu jedną uszkodzoną czujką zostają spełnione warunki włączenia syren i syreny włączają się częściej niż bym chciał. Chyba będę musiał wybrać się w podróż i zainterweniować.

Chciałbym mieć możliwość zdalnego wgrania nowego programu na Pico np. przy pomocy innego Pico. To rozwiązałoby wszystkie problemy i pozwoliło mi pracować nad oprogramowaniem asm nie będąc w domu. Że też wcześniej na to nie wpadłem!

W skrócie jedno Pico (nazwijmy je P1) steruje asm. Drugie Pico W albo inny mikrokontroler podłączony do internetu (nazwijmy je P2) łączy się systematycznie z serwerem i sprawdza czy znajduje się na nim konkretny plik (konkretna lokalizacja i nazwa). Jeśli jest taki plik, to P2 ściąga go, zapisuje w swojej pamięci i łączy się z P1 i ustawia go w tryb wczytywania nowego oprogramowania. Następnie P2 przesyła pobrany wcześniej plik z nową wersją oprogramowania do P1 (nie wiem czy najlepiej będzie przez USB czy w inny sposób). Na koniec P1 uruchamia się z nowym oprogramowaniem, a P2 wraca do tryby cyklicznego sprawdzania nowej wersji oprogramowania na serwerze.

Wydaje się to relatywnie proste do wykonania. Czy widzicie jakieś miny, na które mogę się wpakować?

[jand]

1 godzinę temu, Szern napisał:

Czy widzicie jakieś miny

A co będzie, jak w trakcie programowania P1 przez P2 pojawi się błąd, albo zaniknie zasilanie?

W ESP (obu) często jest stosowane przesyłanie programu OTA (Over The Air) - w czasie wgrywania nowej wersji stara cały czas pracuje i dopiero jak wszystko zakończy się sukcesem następuje podmiana wersji.

Nie wiem, czy dla Pico jest takie coś dostępne.

Edytowano Grudzień 15, 2023 przez jand

[Szern]

9 minut temu, jand napisał:

A co będzie, jak w trakcie programowania P1 przez P2 pojawi się błąd, albo zaniknie zasilanie?

W ESP (obu) często jest stosowane przesyłanie programu OTA (Over The Air) - w czasie wgrywania nowej wersji stara cały czas pracuje i dopiero jak wszystko zakończy się sukcesem następuje podmiana wersji.

Nie wiem, czy dla Pico jest takie coś dostępne.

Jeśli w trakcie programowania P1 przez P2 pojawi się błąd to: P2 się zresetuje (obsłużę błąd na poziomie programu P2), ponownie pobierze program, ustawi P1 w trybie wczytywania i ponowi próbę wgrani programu.

Zasilanie jest na UPS-ie, więc zanik napięcia w sieci nie przeszkodzi we wgrywaniu programu.

Wielkie dzięki za pomysł OTA dla Pico! Oczywiście wypróbuję za kilka dni, ale to może być najlepsze rozwiązanie.

 

[ethanak]

2 godziny temu, Szern napisał:

Czy widzicie jakieś miny, na które mogę się wpakować?

Jak dla mnie jedyną miną jest uzycie mikrokontrolera tam, gdzie potrzebny jest SBC.

[Szern]

1 minutę temu, ethanak napisał:

Jak dla mnie jedyną miną jest uzycie mikrokontrolera tam, gdzie potrzebny jest SBC.

Jasne, zastanawiam się nad taką zmianą, ale jakie konkretnie odniosę korzyści? W sensie: czego w tej chwili brakuje Pico (pomijając moje błędy programistyczne i techniczne)? Nie brakuje mi ani mocy, ani pamięci, ani portów.

[ethanak]

Przed chwilą, Szern napisał:

Nie brakuje mi ani mocy, ani pamięci, ani portów.

A zdalne programowanie?

Kombinujesz z drugim Pico zamiast wrzucić tam jakiego Zero W. Dużo więcej nie zapłacisz, a spokojnie możesz programować przez openocd zamiast kombinować z jakimiś usb.

Sprawdzone, działa od strzału z tandemem Pico i Zero W. A dodatku jak się postarasz to tak to oskryptujesz, że z domowewgo kompa jednuym poleceniem prześlesz program do swojego Pico na drugi koniec świata.

[Szern]

11 minut temu, ethanak napisał:

A zdalne programowanie?

Kombinujesz z drugim Pico zamiast wrzucić tam jakiego Zero W. Dużo więcej nie zapłacisz, a spokojnie możesz programować przez openocd zamiast kombinować z jakimiś usb.

Sprawdzone, działa od strzału z tandemem Pico i Zero W. A dodatku jak się postarasz to tak to oskryptujesz, że z domowewgo kompa jednuym poleceniem prześlesz program do swojego Pico na drugi koniec świata.

Źle zrozumiałem. Teraz rozumiem, że chodzi Ci o tandem - centralka na Pico W i Zero W z OpenOCD jako system do upgrade. Tylko czy użycie do tego Zera to nie będzie overkill? Ja tylko potrzebuję pobrać plik z serwera i wysłać go na Pico (po włączeniu trybu wgrywania programu). Nie mam w domu zewnętrznego IP, nie znam OpenOCD - czy naprawdę jego użycie da mi coś więcej niż OTA dla Pico W?

[ethanak]

To że nie masz zewnętrznego prywatnego IP raczej nie powinno przeszkadzać. Sprawdź czy możesz skorzystać z tunelu IPv6 (np. Hurricane). A nawet jeśli nie to możliwości jest mnóstwo.

A zresztą rób jak uważasz - ja podaję sprawdzone rozwiązania. A użycie najtańszego SBC to chyba nie overkill...

[Szern]

21 minut temu, ethanak napisał:

To że nie masz zewnętrznego prywatnego IP raczej nie powinno przeszkadzać. Sprawdź czy możesz skorzystać z tunelu IPv6 (np. Hurricane). A nawet jeśli nie to możliwości jest mnóstwo.

A zresztą rób jak uważasz - ja podaję sprawdzone rozwiązania. A użycie najtańszego SBC to chyba nie overkill...

Po kolei. Używam serwerka w Oracle i mam tam postawionego OpenVPN'a (i cały panel do obsługi monitoringu). To trochę moja obsesja, aby wszystko zrobić samemu, wiem, ale dzięki temu sporo się uczę. Jednak do tej pory nie mam możliwości bezpośredniego nawiązywania połączenia z zewnątrz z moją siecią domową (ze względu na brak zewnętrznego IP, bezpieczeństwo i brak takiej rzeczywistej potrzeby).

W dosyć prymitywny sposób rozwiązałem zmianę ustawień kamer na ESP32-CAM. Wrzucam na serwerek pliki tekstowe (przygotowane presety za pomocą interfejsu webowego) z wartościami ustawień. Cyklicznie sprawdzam przez FTP (z ESP32-CAM) czy są takie pliki, a jeśli są, to to je pobieram i na podstawie ich zawartości zmieniam ustawienia kamer.

W taki sam prymitywny sposób chciałbym móc zaktualizować Pico. Wiem, ze bardziej elegancko byłoby się połączyć z mojego laptopa z Zero w domu i wgrać software, ale w tej chwili (o ile OTA się sprawdzi) wydaje mi się to bardziej żmudne do zrealizowania.

Overkill nie w sensie kasy, tylko wykorzystania rzeczy niepotrzebnych.

To i tak jest dopiero drugi prototyp, silnie obciążony moją fascynacją mikrokontrolerami, a pewnie w przyszłym roku zmienię koncepcję i architekturę i oprę całość na SBC, zapomnę o czujkach i przestawię się na analizę obrazu z kamer (o ile moje łącze to udźwignie). No chyba, że kolejny prototyp będzie dział całkiem dobrze, a ja będę bardzo zajęty wymianą dachu i odbudową pasieki.

Ale całkiem możliwe, że masz rację, a ja się kompletnie mylę.

[ethanak]

1 minutę temu, Szern napisał:

Używam serwerka w Oracle i mam tam postawionego OpenVPN'a

 

1 minutę temu, Szern napisał:

nie mam możliwości bezpośredniego nawiązywania połączenia z zewnątrz z moją siecią domową (ze względu na brak zewnętrznego IP

Nie widzisz w tym drobnej sprzeczności?

Poza tym możesz sobie postawić jakiegoś telegramowego bota na malince, do tego nie trzeba zewnętrznego IP, i np. poprosić malinkę aby uprzejmie połączyła się z VPN-em. A jak wolisz to możesz SMS-a wysłać. A jak chcesz, to możesz jakiegoś whispera postawić i(chociaż RPi to może być za mało) i gadać z nim przez telefon.

6 minut temu, Szern napisał:

wydaje mi się to bardziej żmudne do zrealizowania.

Hm... w moim przypadku to prosty skrypt odpalany z konsoli, co wrzuca elfa na malinkę, a ta sobie kabelkami programuje Pico. Przy okazji mam zdalnego seriala...

Coś takiego:

#!/bin/bash
picohost=tam.gdzie.mieszka.malinka
if [ -n "$1" ]; then
    flik="$1"
else
    dy=`pwd`
    flik=`basename "${dy}"`.elf
fi
if [ ! -f "${flik}" ]; then
    echo "A gdzie ${flik}?"
else
    ssh ${picohost} pifs < "${flik}"
fi

Po stronie malinki akurat dwa skrypty (tak jakoś na kolanie to robiłem):

pifs

#!/bin/bash
cat > /run/shm/pifs.elf && /usr/bin/pif /run/shm/pifs.elf && rm /run/shm/pifs.elf

pif

#!/bin/bash
openocd -f interface/raspberrypi-swd.cfg -f target/rp2040.cfg -c "targets rp2040.core0; program $1 preverify verify reset exit"

Oczywiście można to zrobić lepiej, ale ja razie to mi wystarczy. A wydanie jednego polecenia raczej nie jest specjalnie żmudne

 

[Szern]

@ethanak

Przeceniasz moje umiejętności.

VPN nie jest spięty z moim domowym routerem. Wpinam indywidualnie tunele dla lokalnych maszyn. Nie wszyscy w domu chcą z niego korzystać. Akurat monitoring nie korzysta, głównie dlatego, że nie potrafiłem tego zrobić dla ESP32.

"Telegramowy bot" nic mi nie mówi. Poszukam, poczytam. Tak samo "whisper". Pico nie chodzi na VPN-ie. Dlatego, że tego na razie nie zrobiłem.

Bardzo słabo znam skrypty basha i właściwie z nich nie korzystam.

Mam bardzo fragmentaryczną i chaotyczną wiedzę. Wrzuciłeś mi dużo nowych tematów. Obwącham, zobaczę czy sobie poradzę i wrócę.

Dziękuję.

[ethanak]

Telegram to komunikator z możliwością tworzenia prywatnych botów.

Whisper to system speech to text (nie wymaga połączenia z netem), niestety trochę za duży na rpi (u mnie bez GPU na I7 i 16 GB RAM ledwo da się używać przy średnim modelu językowym). Bardzo dobrze sobie radzi z polskim.

[Szern]

Dzień dobry!

Wiosna, wyszedłem ze snu zimowego, sprawy życiowe jak zwykle mi się pokomplikowały, więc w dalszym ciągu jestem poza domem i po przerwie wracam do tematu Aktywnego Systemu Monitorującego.

Doświadczenia z niemal czterech miesięcy są następujące:

• słabym elementem jest oprogramowanie centralki, które napisałem na Pico: wymaga kilku znaczących poprawek (w praktyce przepisania od nowa),
• problemy z centralką nie pochodzą od ArduinoIDE, ale od mojej nieznajomości tego środowiska: namieszałem z bibliotekami, ale chyba już umiem sobie z tym poradzić; inna rzecz, że wieloprocesowości nie zaimplementuję pod ArduinoIDE,
• kolejnym słabym elementem jest przekaźnik, który od początku sprawiał problemy, a w ostatnich dniach najprawdopodobniej oddał ducha (prawdopodobnie zbyt wiele przełączeń: w okolicach 5 000-10 000) - IMHO nie nadaje się do poważniejszych zastosowań, rozważam zastosowanie tej płytki,
• zasilanie - popełniłem błąd, podłączając zbyt słaby zasilacz, wymieniłem go już na taki zasilacz, co znacząco poprawiło stabilność,
• syreny, których użyłem okazały się całkowicie nieodporne na warunki atmosferyczne (jeszcze muszę sprawdzić czy dokładnie to je załatwiło); prawdopodobnie wykorzystam jedną, silniejszą syrenę, ale to już po dopracowaniu systemu tak, aby obyło się bez fałszywych alarmów, włączaną dopiero po manualnym zweryfikowaniu zagrożenia,
• czujki PIR, które zastosowałem, nie nadają się do tego celu; reagują na drobne ptaki, ruszające się na wietrze gałęzie itp., a ich regulacja jest trudna technicznie (dwa potencjometry montażowe przy samej czujce - w praktyce siedem czujek ustawiałbym latami), "rozkalibrowują" się w zależności od warunków meteorologcznych - albo zmienię czujniki na takie albo zastąpię je analizą obrazu, a może jedno i drugie,
• kamerki w modułach ESP32-CAM świetnie zdały egzamin, zarówno sprzętowo jak i programowo, najprawdopodobniej dostaną obiektywy szerokokątne i zamiast przesyłać zdjęcia spróbuję strumieniować obraz na serwer (a później automagicznie go analizować),

Ogólnie testy wypadły bardzo dobrze. System działa i ma szanse działać efektywnie.

Roadmap na najbliższy czas:

1. napisanie kodu dla ESP32-CAM zapisującego obraz na serwer (w postaci filmu, a nie zdjęć),
2. napisanie serwerowej aplikacji do analizy obrazu dostarczanego na serwer.
3. podłączenie szerokokątnego obiektywu do ESP32-CAM.

Jeśli to się uda, to pojedyncze kamery strumieniujące obraz plus aplikacja serwerowa wystarczą jako monitoring. Przy odrobinie wysiłku poprzez ESP32-CAM uruchomię również syrenę, więc wyeliminuję: czujki, Pico i okablowanie (poza zasilaniem).

Streaming obrazu z ESP32-CAM poprzez wystawienie go na lokalnym IP jest bardzo prosty(przy założeniu, że ESP32-CAM pracuje jako webserwer). Ja jednak chciałbym przesyłać obraz na żywo na serwer w sieci, przy założeniu, że ESP32-CAM nie ma stałego globalnego adresu IP i chciałbym aby ten obraz był analizowany przez aplikację uruchomioną na serwerze w sieci. 

Spróbuję wyjść od tej biblioteki, posiłkując się tym opisem, ale mam do rozgryzienia dwa problemy: jak wystawić strumień do sieci bez stałego globalnego IP i jak przechwytywać taki strumień na serwerze webowym. Będę informował na bieżąco o postępach.

Tradycyjnie: wszelkie uwagi bardzo mile widziane.

[ethanak]

10 minut temu, Szern napisał:

wieloprocesowości nie zaimplementuję pod ArduinoIDE,

Nie znam wersji Arduino na Pico, ale jak na mój gust to masz dwa wyjścia:

1. Pożegnać się z Arduino IDE i zacząć pisać w picowym SDK (bardzo fajnie się pisze w C, w C++ nie próbowałem)
2. Pożegnać się z Pico i użyć ESP32 (wersja Arduino na ESP32 pozwala na wykorzystanie 99.9% możliwości ESP, wszystko co potrafi FreeRTOS  z modyfikacją dla wielu rdzeni)

Do wyboru...