Nous avons construit le plus grand réseau de capteurs de stationnement du pays pour envoyer les capteurs de stationnement en enfer

En septembre dernier, nous avons installé des capteurs de stationnement optiques pour mesurer l'occupation de plus de 500 places de stationnement dans la rue du quartier universitaire de la ville de Braunschweigs. C'est la plus grande installation de capteurs de stationnement jamais déployée dans l'espace public en Allemagne et une chose est sûre : nous en ferons la dernière. C'est l'histoire des grands efforts d'une société d'IA à la recherche de la vérité terrain. des données pour alimenter ses algorithmes.

C'est aussi l'histoire derrière une belle pièce d'ingénierie, qui s'est avérée être le sous-produit d'une plus grande mission et qui ne sera finalement plus jamais mise en production. Tout cela en faveur d'une technologie plus disruptive et basée sur les données. Puisque, chez Bliq, nous travaillons sur des algorithmes prédictifs pour modéliser la disponibilité des parkings en fonction des données de trafic, nous avons naturellement besoin de données de vérité terrain sur l'occupation réelle des parkings. dans une zone de référence.

Pour obtenir ce type de données, nous avons décidé de construire notre propre configuration expérimentale de capteurs de stationnement dans le monde réel qui mesurent l'occupation de plus de 500 places de stationnement dans la rue, en temps réel, 24 heures sur 24.Avec cet article, nous aimerait partager quelques idées sur les efforts d'ingénierie qui ont été consacrés à ce projet. Plus précisément, parlons du site de test que nous avons choisi, de l'architecture du système et du capteur réel que nous avons conçu et construit pour collecter des données.

Le site de test Parfois, les entreprises d'IA doivent faire preuve de créativité lorsqu'il s'agit de collecter la vérité terrain pour leurs modèles. Dans notre cas, modéliser la disponibilité des parkings, cela signifiait trouver un quartier répondant à certains critères en termes de flux de trafic, d'usage et de démographie. Nous avons choisi le quartier universitaire de Braunschweig pour sa grande variété d'influences sur un espace relativement petit : nous avons le campus principal de l'université qui attire chaque jour des milliers d'étudiants et des centaines d'employés.

Encore plus au sud, le centre-ville avec ses commerces et ses attractions n'est qu'à quelques minutes à pied (non représenté sur la carte ci-dessus). La partie nord du quartier forme une zone résidentielle avec un parking public sans restriction dans la rue. La plupart des habitants de cette région sont soit des étudiants, soit des employés de l'industrie automobile locale.

La grande majorité des habitants se rend au travail en voiture particulière. Le quartier est séparé par une route circulaire artérielle, qui englobe le quartier du centre-ville.Comment fonctionne le systèmeL'architecture système de base de l'installation du capteur est assez simple et correspond essentiellement à ce que l'on attend de la plupart des applications IoT : un petit morceau de matériel est déployé quelque part dans le monde réel et transmet les données à un backend cloud.

Le backend stocke les données et les rend accessibles pour un traitement ultérieur, pour servir de vérité de terrain pour les efforts d'apprentissage automatique ou simplement pour une simple visualisation dans une application ou une application Web. puissance que nous avons déployée à la périphérie : en raison des exigences réglementaires dans l'espace public allemand qui sont en outre déclenchées par les discussions récentes et en cours sur le RGPD, nous n'avons pas été en mesure de traiter des images sur un cloud distant avec beaucoup de ressources de calcul. C'est pourquoi nous devions tout faire le gros du travail pour déterminer les points ouverts directement sur le capteur plutôt qu'ailleurs.

L'avantage à ce sujet est que cette approche ne consomme pas de gros volumes de données pour l'envoi d'images dans les deux sens. Au lieu de cela, nous pouvons maintenir les coûts de fonctionnement des capteurs pour la connectivité également dans une fourchette relativement faible. En revanche, équiper l'appareil d'une puissance de calcul suffisante pour effectuer une analyse d'image nécessite de nombreux efforts supplémentaires dans le développement du matériel.

Pourquoi ne pas utiliser un autre capteur de stationnement ? Pourquoi avons-nous décidé de concevoir et de construire notre propre capteur de stationnement au lieu de simplement acheter l'un des nombreux modèles de capteurs finis déjà disponibles ? Il y a trois réponses à cela : nous Je ne savais pas à quel point la construction d'un nouvel appareil allait devenir complexe ;) Les capteurs de stationnement existants avaient tous des défauts : la situation réglementaire nous interdisait d'utiliser tout type de solution optique disponible, car ce type de système violerait la vie privée.

Les capteurs montés en surface ne résisteraient pas au déneigement en hiver. Et enfin, les capteurs enterrés étaient eux-mêmes assez coûteux et encore plus chers à installer. Nous avions un budget assez serré lorsque nous avons lancé ce projet.

Nous avons entièrement démarré l'entreprise à ce stade : nos fonds se composaient d'un financement gouvernemental, de premiers revenus et de certains prix que nous avons gagnés ici et là. Les autres modèles de capteurs avec un prix compris entre 75 et 250 EUR par spot étaient tout simplement trop chers pour nous à cette époque. Le nouveau capteur optique de stationnementL'idée du principe de fonctionnement de notre capteur était simple : déployer le même algorithme que nous avions déjà développé dans notre précédent projet de recherche sur du matériel de taille réduite, le connecter à Internet, mettre le tout dans un boîtier étanche et le monter à un lampadaire.

L'algorithme lui-même est essentiellement un classificateur d'images, qui nécessite l'examen de régions d'intérêt prédéfinies. L'objectif initial du modèle était d'automatiser l'analyse de l'occupation des parkings dans d'énormes séries d'images que nous avons collectées dans un projet précédent avec des caméras hors ligne. Le défi consistait désormais uniquement à concevoir une plate-forme matérielle appropriée avec une puissance de calcul suffisante, à réduire le modèle pour qu'il s'exécute sur cette configuration et à assurer une alimentation électrique continue.

C'était notre liste de souhaits : faible coût par spot : composants standard. Fréquence de mesure jusqu'à 3 min jusqu'à 30 sec. G.

une voiture occupant deux places) Surveillance de l'état de santé de l'appareil Option pour les mises à jour logicielles à distance Faible consommation d'énergie Durée de vie utile de 25 ans Logiciel Le logiciel du capteur se compose de trois couches : Le système d'exploitation, qui était un développement personnalisé pour ce projet, la routine de base contrôlant toutes les modèle d'apprentissage automatique réel pour la détection des points ouverts. La décision a été prise de construire une distribution personnalisée de Linux en utilisant Yocto.

De cette façon, nous pourrions avoir un contrôle total sur tout ce que fait le système d'exploitation. Les fonctionnalités principales étaient deux partitions distinctes, afin de pouvoir effectuer des mises à jour du système de fichiers et des partitions d'échange, un certain nombre de bibliothèques, requises par la routine principale et une réinitialisation du chien de garde. Le chien de garde matériel de notre SBC redémarre l'appareil au cas où quelque chose ne fonctionnerait pas comme prévu.

Avoir des compteurs de briques intelligentes au-dessus du sol sur des lampadaires à cause d'un bogue dans le logiciel serait littéralement le pire des cas.Routine de baseLa routine de base est chargée de faire fonctionner le détecteur dans un intervalle de temps réglable, de surveiller l'état de santé des capteurs et de communiquer avec le backend (récupération des données de configuration et envoi des mises à jour). La routine principale est implémentée en Python.

Cela nous a donné une grande flexibilité et un traitement d'image simplifié, car nous pouvions utiliser la grande base de code Python existante que nous avions déjà dans l'entreprise. Une grande chose à propos de la conception du logiciel est sa capacité à effectuer des mises à jour à distance indépendantes de chaque composant individuel : Du modèle de détection au code source de la routine principale jusqu'au noyau ou même à l'ensemble du système de fichiers, chaque partie peut être remplacée à distance. Face aux évolutions rapides du CV et du domaine de l'apprentissage automatique en général, nous voulions nous assurer que le code qui exécute les capteurs sera à la pointe de la technologie pendant toute la durée de vie.

Machine LearningPour effectuer la tâche de détection, nous avons pris une version de tensorflow et après quelques ajustements, nous l'avons finalement fait fonctionner sur notre configuration. Une fois cela fait, nous pouvions déployer à peu près n'importe quel flux tenseur pré-formé qui s'intégrerait dans la mémoire GPU. Nous avons décidé d'utiliser le MobileNet, car il présentait le meilleur rapport entre précision et performances sur notre configuration.

Nous avons également examiné plusieurs autres approches basées sur des fonctionnalités de vision par ordinateur traditionnelles telles que les fonctionnalités HOG, les histogrammes, etc. en combinaison avec des classificateurs d'apprentissage automatique conventionnels comme les SVM. Bien que ces tests aient donné des performances de calcul assez élevées en raison d'une conception de modèle beaucoup plus simple par rapport à MobileNet, la précision du modèle était plus faible, ce qui peut s'expliquer par les inconvénients habituels des descriptions de caractéristiques CV standard (invariance à la lumière, invariance à l'échelle).

MatérielTravailler avec du matériel était une expérience assez nouvelle pour nous, étant jusqu'à présent une pure entreprise de logiciels. Bien que Mathias, notre CTO, ait travaillé sur la conception d'électronique lors de son travail précédent chez Volkswagen R &D, notre entreprise n'était pas tout à fait prête pour une tâche de développement matériel et, honnêtement, avec le recul, elle ne l'est toujours pas aujourd'hui.

Ainsi, notre liste d'exigences s'est rapidement avérée ressembler à ceci : Le boîtier doit être étanche et imprimable en 3D Le capteur doit pouvoir fonctionner au moins 12 heures sur batterie La caméra doit être protégée de la pluie et des projections d'eau et fonctionner également dans l'obscurité La conception doit contenir la caméra, un capteur de température/humidité, le module LTE, l'ordinateur monocarte et certains composants électroniques de puissance pour convertir la tension au niveau approprié. Une batterie est nécessaire pour continuer à fonctionner lorsque le lampadaire est éteint (pendant jour) L'ensemble de l'installation doit être modulaire pour faciliter l'installation et pouvoir échanger des composants individuels en cas de panne. Il doit également être petit et peint en gris pour paraître discret dans son environnement de fonctionnementConditions de fonctionnement de -20 C à 70 C (puisque la configuration peut devenir assez chaude en été lorsqu'elle est complètement exposée au soleil) Nous avons commencé avec une conception incluant l'infrarouge Des LED (comme de nombreuses caméras extérieures en ont) pour pouvoir fonctionner dans des conditions nocturnes.

Cependant, ce choix de conception s'est avéré comporter quelques défauts : Ces LED étaient assez énergivores (par rapport au reste de l'électronique), rendant nécessaire une alimentation non standard et donc électrique. Malgré la grande consommation d'énergie, ils n'étaient pas vraiment capables d'éclairer tout le champ de vision. Nous aurions probablement eu besoin d'un projecteur infrarouge externe, ce qui, encore une fois, n'était pas une alternative sérieuse.

Et enfin, la conception aux épices à LED n'était pas très jolie non plus. on peut augmenter l'exposition et la sensibilité à la lumière des capteurs pour ne travailler qu'avec la lumière résiduelle. Nous avons donc écrasé l'exposition interne et le contrôle ISO des caméras et écrit une simple boucle de rétroaction qui ajuste les paramètres d'éclairage en fonction de la luminance de la dernière image capturée.

Cette approche s'est avérée assez performante, car dans la plupart des rues, il y a suffisamment de lumière résiduelle provenant des lampadaires.Après plusieurs itérations supplémentaires, nous avons finalement abouti à la conception illustrée ci-dessus : la caméra se trouve à l'intérieur d'un cône pour être protégée des projections d'eau et les réflexes solaires autant que possible. L'électronique est montée sur une prise à l'intérieur et un câble ruban relie la caméra à la carte mère.

Le fond est amovible et monté sur le boîtier avec quatre vis standard. Étant donné que le boîtier est imprimé en ABS, des écrous quadratiques reposent dans des découpes pour s'assurer que les vis peuvent être correctement serrées. Un joint de type GoPro relie le boîtier au support, qui est fixé au lampadaire à l'aide d'un ruban en acier standard.

Toutes les pièces sont optimisées pour la prinabilité 3D, ce qui signifie qu'il n'y a pas de porte-à-faux importants, importez des surfaces parallèles pour une qualité de surface élevée. Enfin, le boîtier de la batterie est séparé du capteur pour une meilleure facilité d'entretien. Il s'agit d'un boîtier standard en ABS moulé par injection et contient un 4.

Batterie au plomb 5 Ah 12V et une unité de charge, qui prend une entrée de 230V (qui est la tension de la plupart des lampadaires en Allemagne). algorithmes) sur le fonctionnement du stationnement dans différentes situations de circulation et divers contextes de facteurs qui influencent la disponibilité du stationnement.

Nous allons également passer un peu de temps et entrer plus dans les détails de la partie logicielle et finirons même par ouvrir le logiciel, ainsi que les conceptions matérielles.RemerciementsÀ ce stade, nous voudrions exprimer notre gratitude à la ville de Braunschweig de nous avoir donné accès à l'infrastructure de circulation pour soutenir ce projet. Ils ont non seulement fourni toutes les autorisations nécessaires, mais ont également couvert une partie des coûts.

Nous voudrions également adresser un grand merci à l'opérateur de trafic local Bellis et au fournisseur d'énergie BS Energy pour le soutien concernant l'installation et l'alimentation des capteurs.À propos de l'auteurJulian est le PDG et cofondateur de Bliq, un entreprise technologique basée. Bliq fournit des cartes de stationnement en direct pour les développeurs en mobilité.

QUESTION CONNEXE Je n'ai pas reçu Google Glass Explorer Edition. Est-ce que d'essayer d'apprendre Glass dev sans le matériel est un effort futile? Non, vous pouvez toujours apprendre les principes fondamentaux du développement du verre sans le matériel.

Il existe trois approches principales pour y parvenir: 1) Visitez la documentation de l'API Mirror, entrez dans le terrain de jeu et commencez à hacher du code. Téléchargez la bibliothèque PHP, Java et Python, celui avec qui vous êtes le plus à l'aise. Familiarisez-vous avec le jargon et les converntions (chronologie, bundles, menus, etc.).

Lisez la documentation d'assistance (deuxième lien ci-dessous) pour voir comment le matériel Glass fonctionne réellement. Construisez des applications selon cette spécification. Bientôt, vous trouverez un ami avec du matériel à t