Abbiamo costruito la più grande rete di sensori di parcheggio del Paese per inviare sensori di parcheggio all'inferno

Lo scorso settembre abbiamo installato sensori di parcheggio ottici per misurare l'occupazione di oltre 500 parcheggi su strada nella città del distretto universitario di Braunschweigs. Questa è la più grande installazione di sensori di parcheggio mai lanciata in uno spazio pubblico in Germania e una cosa è certa: la faremo l'ultima. Questa è la storia dei grandi sforzi, un'azienda di intelligenza artificiale creata alla ricerca della verità sul terreno dati per alimentare i suoi algoritmi.

Questa è anche la storia dietro un bellissimo pezzo di ingegneria, che è risultato essere il sottoprodotto di una missione più grande e alla fine non sarà mai più messo in produzione. Tutto ciò a favore di una tecnologia basata sui dati più dirompente. Poiché, in Bliq, lavoriamo su algoritmi predittivi per modellare la disponibilità dei parcheggi in base ai dati sul traffico, abbiamo la naturale necessità di dati sulla verità del suolo dell'occupazione reale dei parcheggi in una zona di riferimento.

Per ottenere questo tipo di dati, abbiamo deciso di costruire la nostra configurazione sperimentale di sensori di parcheggio nel mondo reale che misura l'occupazione di oltre 500 parcheggi in strada, in tempo reale, 24 ore al giorno. Con questo articolo, vorrei condividere alcuni spunti sugli sforzi ingegneristici che sono stati coinvolti in questo progetto. Più nello specifico, parliamo bene del sito di test che abbiamo scelto, dell'architettura del sistema e del sensore vero e proprio che abbiamo progettato e costruito per raccogliere i dati.

Il sito di prova A volte, le aziende di intelligenza artificiale hanno bisogno di diventare creative quando si tratta di raccogliere verità di base per i loro modelli. Nel nostro caso, modellare la disponibilità di parcheggi per auto, significava trovare un quartiere che soddisfa determinati criteri in termini di flusso di traffico, utilizzo e demografia. Abbiamo scelto il quartiere universitario di Braunschweig per la sua grande varietà di influenze su uno spazio relativamente piccolo: a sud, abbiamo il campus principale dell'università che attrae migliaia di studenti e centinaia di dipendenti ogni giorno.

Ancora più a sud, il centro della città con i suoi negozi e le sue attrazioni è a pochi minuti a piedi (non mostrato nella mappa sopra). La parte settentrionale del quartiere forma una zona residenziale con parcheggi pubblici su strada non soggetti a restrizioni. La maggior parte delle persone che vivono in questa zona sono studenti o impiegati nell'industria automobilistica locale.

La stragrande maggioranza dei residenti si reca al lavoro utilizzando auto private. Il distretto è separato da un'arteria circolare, che abbraccia il quartiere centrale della città. Come funziona il sistema L'architettura del sistema di base dell'installazione del sensore è piuttosto semplice e sostanzialmente ciò che ci si aspetterebbe dalla maggior parte delle applicazioni IoT: un piccolo pezzo di hardware è distribuito da qualche parte nel mondo reale e trasmette i dati a un backend cloud.

Il back-end archivia i dati e li rende accessibili per ulteriori elaborazioni, per fungere da verità di base per le attività di apprendimento automatico o semplicemente per la semplice visualizzazione in un'app o un'app Web. Requisito difficile: privacy in base alla progettazione La particolarità dell'architettura dei sensori è la capacità computazionale abbastanza forte potenza che abbiamo implementato al limite: a causa dei requisiti normativi nello spazio pubblico tedesco, ulteriormente attivati ​​dalle discussioni recenti e in corso sul GDPR, non siamo stati in grado di elaborare le immagini su un cloud remoto con molte risorse di calcolo. Ecco perché dovevamo fare tutto il sollevamento di carichi pesanti per determinare i punti aperti direttamente sul dispositivo sensore piuttosto che da qualche altra parte.

Il vantaggio di questo è che questo approccio non consuma grandi volumi di dati per l'invio di immagini avanti e indietro. Possiamo invece mantenere i costi di gestione dei sensori per la connettività anche all'interno di un range relativamente basso. L'aspetto negativo è che dotare il dispositivo di una potenza di calcolo sufficiente per eseguire l'analisi delle immagini richiede molti sforzi extra nello sviluppo dell'hardware.

Perché non utilizzare un altro sensore di parcheggio? Perché abbiamo deciso di affrontare il dolore di progettare e costruire il nostro sensore di parcheggio invece di acquistare solo uno dei tanti modelli di sensori finiti che sono già disponibili là fuori? Ci sono tre risposte a questo: Noi non sapevo quanto sarebbe diventata complessa la costruzione di un nuovo dispositivo ;) I sensori di parcheggio esistenti avevano tutti dei difetti: la situazione normativa ci proibiva di utilizzare qualsiasi tipo di soluzione ottica disponibile, poiché questo tipo di sistemi violerebbe la privacy.

I sensori montati in superficie non resisterebbero alla rimozione della neve durante l'inverno. Infine, i sensori interrati erano di per sé piuttosto costosi e persino più costosi da installare. Avevamo un budget piuttosto limitato quando abbiamo iniziato questo progetto.

A questo punto abbiamo completamente avviato l'azienda: i nostri fondi consistevano in alcuni finanziamenti governativi, primi ricavi e alcuni prezzi che abbiamo vinto qua e là. Gli altri modelli di sensori con un prezzo compreso tra 75 e 250 EUR per spot erano semplicemente troppo costosi per noi in questo momento. Il nuovo sensore di parcheggio otticoL'idea del principio di funzionamento del nostro sensore era semplice: implementare lo stesso algoritmo che avevamo già sviluppato nel nostro precedente progetto di ricerca su hardware di dimensioni ridotte, collegarlo a Internet, mettere tutto in una scatola impermeabile e montarlo ad un palo della luce.

L'algoritmo stesso è fondamentalmente un classificatore di immagini, che richiede regioni di interesse predefinite da guardare. Lo scopo originale del modello era automatizzare l'analisi dell'occupazione dei parcheggi in alcune enormi serie di immagini raccolte in un precedente progetto con telecamere offline. La sfida ora era solo progettare un rig hardware adatto con una potenza di calcolo sufficiente, ridurre il modello in modo che funzionasse su questa configurazione e garantire un'alimentazione continua.

Questa era la nostra lista dei desideri delle specifiche:Basso costo per spot: Componenti standardFrequenza di misurazione fino a 3 min fino a 30 sec.Rilevamento robusto contro agenti atmosferici, cambiamenti nell'illuminazione e parcheggio impreciso delle auto (ad es. G.

un'auto che occupa due posti) Monitoraggio dello stato di salute del dispositivo Opzione per aggiornamenti software da remoto Basso consumo energetico Durata utile 25 anni Software Il software del sensore è composto da tre livelli: il sistema operativo, che è stato uno sviluppo personalizzato per questo progetto, la routine principale che controlla tutte le funzioni dei sensori e il modello di apprendimento automatico effettivo per il rilevamento di punti aperti.Sistema operativoPer eseguire un modello di visione completo sull'edge, ci siamo subito resi conto che avremmo avuto bisogno di una configurazione software molto più ampia rispetto ad altri progetti hardware IoT. È stata presa la decisione di creare una distribuzione personalizzata di Linux utilizzando Yocto.

In questo modo, potremmo avere il pieno controllo su tutto ciò che il sistema operativo sta facendo. Le funzionalità principali erano due partizioni separate, per poter eseguire aggiornamenti del file system e scambiare partizioni, un numero di librerie, richieste dalla routine principale e un ripristino del watchdog. Il watchdog hardware del nostro SBC riavvia il dispositivo nel caso in cui qualcosa non funzioni come previsto.

Avere smart brick a metri da terra su pali della luce a causa di un bug nel software sarebbe letteralmente il caso peggiore. backend (recupero dei dati di configurazione e invio di aggiornamenti). La routine principale è implementata in Python.

Questo ci ha dato una grande flessibilità e ha semplificato molto l'elaborazione delle immagini, poiché abbiamo potuto utilizzare l'ampia base di codice Python esistente che già avevamo in azienda. Una cosa grandiosa della progettazione del software è la sua capacità di aggiornamenti remoti indipendenti di ogni singolo componente: Dal modello di rilevamento al codice sorgente per la routine principale fino al kernel o persino all'intero file system, ogni parte può essere sostituita in remoto. Di fronte alle rapide evoluzioni nel campo del CV e dell'apprendimento automatico in generale, volevamo assicurarci che il codice che esegue i sensori fosse all'avanguardia per l'intera durata della vita.

Apprendimento automatico Per eseguire l'attività di rilevamento, abbiamo preso una versione di tensorflow e dopo alcune modifiche alla fine l'abbiamo fatto funzionare sulla nostra configurazione. Una volta fatto ciò, abbiamo potuto distribuire praticamente qualsiasi flusso tensoriale pre-addestrato che si adattasse alla memoria della GPU. Abbiamo deciso di utilizzare MobileNet, poiché ha mostrato il miglior rapporto tra precisione e prestazioni sulla nostra configurazione.

Abbiamo anche esaminato molti altri approcci basati sulle tradizionali funzionalità di visione artificiale come le funzionalità HOG, gli istogrammi, ecc. in combinazione con classificatori di machine learning convenzionali come le SVM. Sebbene questi test abbiano portato a prestazioni di calcolo piuttosto elevate a causa di una progettazione del modello molto più semplice rispetto a MobileNet, l'accuratezza del modello era inferiore, il che può essere spiegato dai soliti svantaggi delle descrizioni delle caratteristiche CV standard (invarianza leggera, invarianza di scala).

HardwareLavorare con l'hardware è stata un'esperienza del tutto nuova per noi, essendo fino a questo punto una pura azienda di software. Sebbene Mathias, il nostro CTO, avesse lavorato alla progettazione di componenti elettronici nel suo precedente lavoro con la Volkswagen R &D, la nostra azienda non era ancora pronta per un'attività di sviluppo hardware e, onestamente, guardando indietro, non lo è ancora oggi. Tuttavia, avevamo bisogno di un design funzionale che fosse facile da produrre e da replicare con le risorse che avevamo come azienda avviata in quel momento.

Quindi, il nostro elenco di requisiti si è rapidamente rivelato simile a questo: La custodia deve essere impermeabile e stampabile in 3D Il sensore deve essere in grado di funzionare per almeno 12 ore con la batteria La fotocamera deve essere protetta dalla pioggia e dagli spruzzi d'acqua e funzionare anche al buioIl design deve contenere la fotocamera, un sensore di temperatura/umidità, il modulo LTE, il computer a scheda singola e alcuni componenti elettronici di potenza per convertire la tensione al livello appropriato. È necessaria una batteria per continuare a funzionare quando il palo della luce è spento (durante il giorno) L'intero setup deve essere modulare per facilitare l'installazione e per poter sostituire i singoli componenti in caso di guasto. Ha anche bisogno di essere piccolo e dipinto di grigio per sembrare discreto nel suo ambiente operativo Condizioni operative da -20 C a 70 C (poiché l'installazione può diventare piuttosto calda in estate quando è completamente esposta al sole) Abbiamo iniziato con un design che includeva gli infrarossi LED (come molte telecamere da esterno li hanno) per poter funzionare in condizioni notturne.

Tuttavia, questa scelta progettuale si è rivelata con alcuni difetti: questi LED consumavano abbastanza energia (rispetto al resto dell'elettronica), rendendo necessaria un'alimentazione non standard e quindi necessaria. Nonostante il grande consumo di energia, non erano davvero in grado di illuminare l'intero campo visivo. Probabilmente avremmo avuto bisogno di un proiettore IR esterno, che, ancora una volta, non era un'alternativa seria.

E infine, anche il design con spezie a LED non era molto carino. Per ovviare al problema delle operazioni notturne abbiamo deciso di utilizzare l'impostazione della telecamera statica: poiché la posizione della telecamera è statica e gli oggetti che stiamo cercando di rilevare sono normalmente fermi, possiamo aumentare l'esposizione e la sensibilità alla luce dei sensori per poter lavorare solo con luce residua. Quindi abbiamo sovrascritto l'esposizione interna della fotocamera e il controllo ISO e abbiamo scritto un semplice ciclo di feedback che regola le impostazioni di illuminazione in base alla luminanza dell'ultimo fotogramma catturato.

Questo approccio si è rivelato abbastanza efficace, poiché nella maggior parte delle strade c'è abbastanza luce residua dai lampioni. Dopo molte altre iterazioni, abbiamo finalmente ottenuto il design come mostrato sopra: la fotocamera si trova all'interno di un cono per essere protetta dagli spruzzi d'acqua e il più possibile i riflessi del sole. L'elettronica è montata su una presa interna e un cavo piatto collega la telecamera alla scheda principale.

Il fondo è rimovibile e fissato alla custodia con quattro viti standard. Poiché la custodia è stampata in ABS, i dadi quadratici si trovano in ritagli per assicurarsi che le viti possano essere serrate correttamente. Un giunto simile a una GoPro collega la custodia al supporto, che viene fissato al palo della luce utilizzando un nastro di acciaio standard.

Tutte le parti sono ottimizzate per la stampabilità 3D, il che significa nessuna sporgenza pesante, superfici di importazione parallele per un'elevata qualità della superficie. Infine, la scatola della batteria è separata dal sensore per una migliore manutenzione. È una scatola standard in ABS stampata ad iniezione e contiene un 4.

Batteria al piombo da 5 Ah 12 V e un'unità di ricarica, che richiede 230 V in ingresso (che è il voltaggio della maggior parte dei lampioni in Germania). Che cosa succede dopoI dati che stiamo raccogliendo durante questo progetto ci stanno aiutando notevolmente a migliorare la nostra comprensione (e anche il nostro algoritmi) di come funziona il parcheggio in diverse situazioni di traffico e vari contesti di fattori che influenzano la disponibilità di parcheggio. A breve pubblicheremo ulteriori informazioni sui risultati effettivi dal punto di vista della scienza dei dati.

Dedicheremo anche un po' di tempo e approfondiremo i dettagli della parte software e alla fine andremo anche a rendere open source il software, così come i progetti hardware. Ringraziamenti A questo punto, vorremmo esprimere la nostra gratitudine alla città di Braunschweig per averci concesso l'accesso all'infrastruttura del traffico per supportare questo progetto. Non solo hanno fornito tutte le autorizzazioni necessarie, ma hanno anche coperto parte dei costi.

Vorremmo anche inviare un grande ringraziamento all'operatore del traffico locale Bellis e al fornitore di energia BS Energy per il supporto relativo all'installazione e all'alimentazione dei sensori. Informazioni sull'autoreJulian è l'amministratore delegato e co-fondatore di Bliq, una società di Berlino società tecnologica con sede. Bliq fornisce mappe di parcheggio in tempo reale per gli sviluppatori in mobilità.

DOMANDA CORRELATA Non ho ricevuto Google Glass Explorer Edition. Provare a imparare Glass dev senza l'hardware è uno sforzo inutile? No, puoi ancora imparare i fondamenti dello sviluppo del vetro senza l'hardware.

Ci sono tre approcci principali per raggiungere questo obiettivo: 1) Visita la documentazione di Mirror API, entra nel parco giochi e inizia a eseguire l'hashing di un codice. Scarica la libreria PHP, Java e Python, a seconda di quale ti trovi più a tuo agio. Familiarizzare con il gergo e le convernazioni (timeline, fasci, menu, ecc.).

Leggi la documentazione di supporto (secondo link sotto) per vedere come funziona effettivamente l'hardware Glass. Costruisci alcune app secondo questa specifica. Ben presto, troverai un amico con hardware per t