Detector de buits de drenatge: 11 passos (amb imatges)

2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:15

No deixeu que un desguàs obstruït us alenteixi! En tornar de les nostres vacances, jo i la meva dona ens vam sorprendre de l’aigua que cobria el terra del nostre apartament i vam descobrir que ni tan sols era aigua neta, sinó que hi havia desguassos a tot arreu. Després d’esborrar el desguàs i netejar el terra, tenia aquesta pregunta: per què no disposem d’un sistema d’alarma per a possibles embussos de desguàs? Els desguassos obstruïts no només poden aturar la vostra llar, sinó que consumiran costos addicionals de les butxaques; 206 dòlars de mitjana són el cost de netejar un desguàs obstruït segons HomeAdvisor, a més dels costos ocults de catifes, mobles de fusta danyats, etc. La nostra idea és permetre als propietaris d’habitatges, així com a empreses com a departaments de manteniment de ciutats / edificis i proveïdors de serveis especialitzats, que tinguin un sistema eficient i intel·ligent que alerti a qui mana el més aviat possible per actuar, cosa que contribueix a enriquir les ciutats intel·ligents amb característica.

La idea Tot i que la detecció d’esclops es pot fer mitjançant diverses tècniques, com ara l’ús de sensors de gas o mecanismes interns, el nostre equip es va centrar a utilitzar el so com a entrada, ja que sabem que tocar un tub on s’obre és un so diferent del que va passar en estar tancat. Segons aquest concepte senzill, si podem entrenar un model, els patrons sonors que es produeixen a la superfície del tub durant els embussos, així com aquests patrons, es produeixen a les canonades obertes, podem aplicar el model per detectar de forma proactiva quan un embussament comença a compondre’s, i llavors sonar algunes factures.

Crèdits per

• Mohamed Hassan
• Ahmed Emam

Projecte detallat: 3 fases s’implementen en aquest projecte: Recopilació de dades, Aprenentatge i predicció.

Abans d’aplicar aquest sistema a la vida real, havíem de crear un entorn de simulació forçat, on tinguéssim la canonada, l’aigua que flueix i, d’alguna manera, simular l’obstrucció. Així doncs, vam aconseguir un tub, una mànega d’aigua amb una font d’aigua que ho feia a la banyera i que utilitzem la superfície de la banyera per tancar el tub que representa l’obstrucció. En aquest vídeo, expliquem com hem creat l'entorn i com hem recopilat dades per a la formació del model.

I en aquest següent vídeo, que mostra com vam fer les proves del sistema i del model, en mode obert, després en mode obstrucció i de nou al mode obert, però

Per tant, explorem la nostra implementació pas a pas:

Pas 1: l'experiment

En aquest escenari fem servir una petita canonada d’aigua connectada al nostre maquinari i sensor de so. El maquinari llegeix el valor del sensor i el torna a enviar al núvol. Això s'ha fet durant 10 minuts per al tub bloquejat i després altres 10 minuts per al tub que no està bloquejat.

Pas 2: maquinari

I- Arduino

Per detectar el so de l’aigua a l’interior de la canonada necessitem un sensor de so. Tot i això, Raspberry Pi 3 no té GPIO analògic. Per solucionar aquest problema, fem servir Arduino ja que Arduino té GPIO analògic. Per tant, connectem el sensor de so Grove a l’escut Grove Arduino i el Shield a l’Arduino UNO 3. A continuació, connectem Arduino i Raspberry mitjançant un cable USB. Per obtenir més informació sobre el sensor Grove Sound, podeu consultar-ne la fitxa tècnica. Podeu trobar al full de dades un codi de mostra de com llegir els valors del sensor. El codi de mostra gairebé s’utilitza amb petits canvis. Al codi següent connectem el sensor a A0 en blindatge. Per escriure en sèrie, fem servir la funció Serial.begin (). Per comunicar-se amb la velocitat de transmissió de Raspberry establerta a 115200, s’enviaran dades a Raspberry si és més gran que un llindar determinat per reduir el soroll. S’han fet moltes proves per escollir els valors de llindar i de retard desitjats. El llindar es troba en 400 i el valor de retard és de 10 mil·lisegons. S'ha escollit el llindar per filtrar el soroll normal i assegurar-se que només s'enviaran dades significatives al núvol. S'ha escollit el retard per garantir que el sensor detecti immediatament qualsevol canvi en el so de flux dins del tub.

II- Raspberry Pi 3 Per descarregar coses d’Android a Raspberry, podeu descarregar la versió més recent des de Android Things Console. En aquest projecte utilitzem la versió: OIR1.170720.017. seguiu els passos del lloc de Raspberry per instal·lar el sistema operatiu a Raspberry. Per a Windows, podeu seguir aquests passos. Després de la instal·lació, podeu connectar Raspberry a l'ordinador mitjançant USB. A continuació, utilitzeu l'ordre següent a la consola de l'ordinador per obtenir Raspberry IP

nmap -sn 192.168.1. *

Després d'obtenir la IP, connecteu-vos al vostre gerd amb l'ordre següent

connectar adb

Per connectar el vostre gerd a Wifi (afegiu el vostre SSID i la vostra contrasenya)

adb am startservice

-n com.google.wifisetup /. WifiSetupService

-a WifiSetupService. Connect

-e ssid *****

-e contrasenya ****

Pas 3: Google Cloud: registre

Google ofereix un nivell gratuït per a tots els usuaris durant un any amb un límit de 300 $, gràcies a Google:). Seguiu les pantalles per crear un projecte nou a Google Cloud

Pas 4: Google Cloud - Pub / Sub

Google Cloud Pub / Sub és un servei de missatgeria en temps real totalment gestionat que us permet enviar i rebre missatges entre aplicacions independents.

Pas 5: Google Cloud: IOT Core

II- IOT Core Un servei totalment gestionat per connectar, gestionar i ingerir dades de dispositius dispersos a tot el món de manera fàcil i segura. IOT Core segueix sent beta, per tenir-hi accés, heu de fer una sol·licitud amb Justificació a Google. Vam fer la sol·licitud, la nostra justificació era aquest concurs. Aprovat per Google, gràcies a Google de nou:). Raspberry enviarà dades del sensor a IOT Core que reenviarà les lectures al tema de PubSub creat al pas anterior

Pas 6: Google Cloud - Funcions Cloud

Cloud Functions és un entorn sense servidor per crear i connectar serveis al núvol. El desencadenant d'aquesta funció és el tema de PubSup que es va crear al pas 1.;; Aquesta funció s'activarà quan s'escrigui un valor nou a PubSup i s'escrigui a Cloud DataStore amb el tipus "SoundValue".

Pas 7: Google Cloud: Cloud DataStore

Google Cloud Datastore és una base de dades de documents NoSQL creada per a l’escala automàtica, l’alt rendiment i la facilitat de desenvolupament d’aplicacions. Tot i que la interfície Cloud Datastore té moltes de les mateixes funcions que les bases de dades tradicionals, com a base de dades NoSQL es diferencia d’elles en la forma en què descriu les relacions entre objectes de dades. No cal cap configuració, ja que un cop les funcions del núvol escriuen els valors del sensor a DataStore, les dades s’afegiran a DataStore

Pas 8: Google Cloud: BigQuery

Recollim una mostra a 10 min de la canonada normal i a 10 min de la canonada bloquejada amb diferència exactament 1 hora entre les 2 iteracions. Després de descarregar les dades DataStore i fer alguna manipulació per afegir classificació per a cada fila. Ara tenim 2 fitxers CSV un per a cada categoria. Com a pràctica recomanada, pengeu primer fitxers CSV de dades a Cloud Storage. A la pantalla següent, creem un nou dipòsit i carreguem els 2 fitxers CSV, ja que aquest dipòsit només s’utilitzarà per a anàlisis, no cal escollir un dipòsit multi-regional. A continuació, creeu un conjunt de dades nou i una taula nova a BigQuery i pengeu els dos fitxers CSV del dipòsit a la nova taula

Pas 9: Google Cloud: Data Studio

A continuació, fem servir Data Studio per obtenir algunes idees. Data Studio llegirà les dades de la taula BigQuery. A partir de gràfics podem veure la diferència entre 2 categories en nombre de telemetries i suma de valors per minut. Basant-nos en aquestes idees, podem dissenyar un model senzill, es considera que la canonada està bloquejada si en 3 minuts consecutius, el recompte de valors de telemetries superiors al llindar de soroll (400) és superior a 350 telemetres. i en 3 minuts consecutius, el valor del recompte de telemetries que és superior al llindar d’espurna (720) és superior a 10 telemetres.

Pas 10: Fase de predicció

Ens referim a una lectura, quan supera un determinat valor (THRESHOLD_VALUE) que es va establir a 350 que filtra el soroll i els cabals d’aigua més baixos al tub, de no ser considerada com una lectura

L'anàlisi de dades va mostrar que en mode obert el nombre de lectures és inferior a 100, però en mode obstrucció, els valors són molt superiors (arriben a 900 per minut), però en casos rars també eren inferiors a 100. No obstant això, aquests casos no es repeteixen en conseqüència, i durant tres minuts conseqüents, el nombre total de lectures sempre va superar les 350. Tenir el mode obert en els mateixos tres minuts sumarà menys d'un 300, podríem posar aquesta regla amb seguretat: Regla # 1 Durant tres minuts en brut, si el total de lectures > 350, es detecta un embussament. Hem trobat que el valor màxim assolit en mode obert no supera un determinat valor (SPARK_VALUE) que es troba a 770, de manera que hem afegit aquesta regla: Regla núm. 2 Si es llegeix un valor> 350, es detecta sobretot un embussament.

La combinació d’ambdues regles ens va proporcionar una manera senzilla d’implementar la lògica de detecció, tal com es mostra. Tingueu en compte que el codi següent es va desplegar a Arduino, que avalua les telemetries rebudes en funció del nostre model i les envia a raspberry si la canonada està obstruïda o oberta.

Pas 11: Codi

Tot el codi per a la funció Arduino, Raspberry i Cloud es pot trobar a Github.

Per obtenir més informació podeu consultar aquest enllaç