Construimos la red de sensores de estacionamiento más grande del país para enviar sensores de estacionamiento al infierno

En septiembre pasado, instalamos sensores de estacionamiento ópticos para medir la ocupación de más de 500 lugares de estacionamiento en la calle en el distrito universitario de la ciudad de Braunschweigs. Esa es la mayor instalación de sensores de estacionamiento jamás realizada en un espacio público en Alemania y una cosa es segura: haremos que sea la última. Esta es la historia de los grandes esfuerzos que una empresa de IA realizó en busca de la verdad sobre el terreno datos para alimentar sus algoritmos.

Esta es también la historia detrás de una hermosa pieza de ingeniería, que resultó ser el subproducto de una misión más grande y, finalmente, nunca se volverá a poner en producción. Todo eso a favor de una tecnología más disruptiva basada en datos. Dado que, en Bliq, trabajamos en algoritmos predictivos para modelar la disponibilidad de estacionamiento en función de los datos de tráfico, tenemos la necesidad natural de obtener datos reales de la ocupación de estacionamiento en la vida real. en un área de referencia.

Para obtener ese tipo de datos, decidimos construir nuestra propia configuración experimental real de sensores de estacionamiento que miden la ocupación de más de 500 lugares de estacionamiento en la calle, en tiempo real, las 24 horas del día. Con este artículo, Me gustaría compartir algunas ideas sobre los esfuerzos de ingeniería que se han realizado en este proyecto. Más específicamente, hablaremos sobre el sitio de prueba que elegimos, la arquitectura del sistema y el sensor real que diseñamos y construimos para recopilar datos.

El sitio de pruebaA veces, las empresas de IA necesitan ser creativas cuando se trata de recopilar datos reales para sus modelos. En nuestro caso, modelar la disponibilidad de estacionamiento para automóviles significaba encontrar un distrito que cumpliera con ciertos criterios en términos de flujo de tráfico, uso y demografía. Elegimos el distrito universitario en Braunschweig por su gran variedad de influencias en un espacio comparativamente pequeño: en el sur, tenemos el campus principal de la universidad que atrae a miles de estudiantes y cientos de empleados todos los días.

Aún más al sur, el centro de la ciudad con sus tiendas y atracciones está a solo unos minutos a pie (no se muestra en el mapa de arriba). La parte norte del distrito forma una zona residencial con estacionamiento público en la calle sin restricciones. La mayoría de las personas que viven en esta área son estudiantes o empleados de la industria automotriz local.

La gran mayoría de los residentes se desplaza al trabajo en vehículos privados. El distrito está separado por un camino circular arterial, que abarca el distrito central de la ciudad. Cómo funciona el sistema La arquitectura básica del sistema de la instalación del sensor es bastante sencilla y básicamente lo que uno esperaría de la mayoría de las aplicaciones de IoT: una pequeña pieza de hardware se implementa en algún lugar en el mundo real y transmite datos a un servidor en la nube.

El backend almacena los datos y los hace accesibles para su posterior procesamiento, para que sirvan como base para los esfuerzos de aprendizaje automático o simplemente para una visualización simple en una aplicación o aplicación web. Requisito difícil: privacidad por diseño. potencia que desplegamos en el perímetro: debido a los requisitos reglamentarios en el espacio público alemán que también se desencadenan por las discusiones recientes y en curso de GDPR, no pudimos procesar imágenes en una nube remota con muchos recursos computacionales. Es por eso que necesitábamos hacer todo el trabajo pesado para determinar puntos abiertos directamente en el dispositivo sensor en lugar de en otro lugar.

La ventaja de esto es que este enfoque no consume grandes volúmenes de datos para enviar imágenes de un lado a otro. En cambio, podemos mantener los costos de funcionamiento de los sensores para la conectividad también dentro de un rango relativamente bajo. En el lado negativo, equipar el dispositivo con suficiente poder computacional para realizar análisis de imágenes requiere muchos esfuerzos adicionales en el desarrollo de hardware.

¿Por qué no usar otro sensor de estacionamiento? ¿Por qué hemos decidido pasar por el dolor de diseñar y construir nuestro propio sensor de estacionamiento en lugar de simplemente comprar uno de los muchos modelos de sensores terminados que ya están disponibles? Hay tres respuestas a eso: Nosotros no sabía lo complejo que iba a ser construir un nuevo dispositivo;) Todos los sensores de estacionamiento existentes tenían algunos defectos: la situación regulatoria nos prohibía usar cualquier tipo de solución óptica disponible, ya que este tipo de sistemas violarían la privacidad.

Los sensores montados en la superficie no soportarían la remoción de nieve durante el invierno. Y, por último, los sensores enterrados eran bastante costosos e incluso más caros de instalar. Teníamos un presupuesto bastante ajustado cuando comenzamos este proyecto.

Arrancamos completamente a la empresa en este punto: nuestros fondos consistían en algunos fondos del gobierno, los primeros ingresos y algunos precios que ganamos aquí y allá. Los otros modelos de sensores con un precio de entre 75 y 250 EUR por lugar eran simplemente demasiado caros para nosotros en este momento. El nuevo sensor de estacionamiento ópticoLa idea del principio de funcionamiento de nuestro sensor era simple: implementar el mismo algoritmo que ya habíamos desarrollado en nuestro proyecto de investigación anterior sobre hardware reducido, conectarlo a Internet, poner todo en una caja impermeable y montarlo a un poste de luz.

El algoritmo en sí es básicamente un clasificador de imágenes, que requiere regiones de interés predefinidas para mirar. El propósito original del modelo era automatizar el análisis de la ocupación de estacionamientos en algunas series de imágenes enormes que recopilamos en un proyecto anterior con cámaras fuera de línea. El desafío ahora solo era diseñar una plataforma de hardware adecuada con suficiente potencia computacional, reducir el modelo para que se ejecute en esta configuración y garantizar un suministro de energía continuo.

Esta fue nuestra lista de deseos de especificaciones: Bajo costo por lugar: Componentes estándar Frecuencia de medición de hasta 3 min a 30 seg. G

un automóvil que ocupa dos lugares) Monitoreo del estado de salud del dispositivo Opción de actualizaciones de software remotas Bajo consumo de energía 25 años de vida útil Software El software del sensor consta de tres capas: el sistema operativo, que fue un desarrollo personalizado para este proyecto, la rutina central que controla todas las funciones de los sensores y el modelo de aprendizaje automático real para la detección de puntos abiertos. Sistema operativo Para ejecutar un modelo de visión completo en el borde, rápidamente nos dimos cuenta de que necesitaríamos una configuración de software mucho más grande que en otros proyectos de hardware de IoT. Se tomó la decisión de construir una distribución personalizada de Linux usando Yocto.

De esta manera, podríamos tener control total sobre todo lo que hace el sistema operativo. Las características principales eran dos particiones separadas, para poder realizar actualizaciones del sistema de archivos e intercambiar particiones, varias bibliotecas, requeridas por la rutina principal y un restablecimiento de vigilancia. El controlador de hardware de nuestro SBC reinicia el dispositivo en caso de que algo no funcione como se esperaba.

Tener medidores de ladrillos inteligentes sobre el suelo en postes de luz debido a un error en el software sería literalmente el peor de los casos. Rutina central La rutina central es responsable de ejecutar el detector en un intervalo de tiempo ajustable, monitorear el estado de salud de los sensores y comunicarse con el backend (recuperación de datos de configuración y envío de actualizaciones). La rutina central se implementa en Python.

Esto nos dio una gran flexibilidad y simplificó mucho el procesamiento de imágenes, ya que podíamos hacer uso de la gran base de código de Python existente que ya teníamos en la empresa. Una gran cosa sobre el diseño del software es su capacidad para actualizaciones remotas independientes de cada componente individual: Desde el modelo de detección hasta el código fuente para la rutina central hasta el núcleo o incluso todo el sistema de archivos, cada parte puede reemplazarse de forma remota. Ante la rápida evolución en el campo del CV y ​​el aprendizaje automático en general, queríamos asegurarnos de que el código que ejecuta los sensores sea de última generación durante toda su vida útil.

Aprendizaje automáticoPara realizar la tarea de detección, tomamos una versión de tensorflow y, después de algunos ajustes, finalmente logramos que funcionara en nuestra configuración. Una vez hecho esto, pudimos implementar prácticamente cualquier flujo de tensor preentrenado que encajara en la memoria de la GPU. Decidimos usar MobileNet, ya que mostró la mejor relación entre precisión y rendimiento en nuestra configuración.

También analizamos varios otros enfoques basados ​​en funciones tradicionales de visión por computadora, como funciones HOG, histogramas, etc. en combinación con clasificadores de aprendizaje automático convencionales como SVM. Si bien estas pruebas dieron como resultado un rendimiento computacional bastante alto debido a un diseño de modelo mucho más simple en comparación con MobileNet, la precisión del modelo fue menor, lo que puede explicarse por las desventajas habituales de las descripciones de características de CV estándar (invariancia de luz, invariancia de escala).

HardwareTrabajar con hardware fue una experiencia bastante nueva para nosotros, siendo hasta ese momento una empresa puramente de software. Aunque Mathias, nuestro CTO, había trabajado en el diseño de componentes electrónicos en su trabajo anterior con Volkswagen R &D, nuestra empresa no estaba del todo preparada para una tarea de desarrollo de hardware y, sinceramente, mirando hacia atrás, todavía no lo está hoy. Sin embargo, necesitábamos un diseño funcional que fuera fácil de fabricar y de iterar con los recursos que teníamos como empresa de arranque en ese momento.

Por lo tanto, nuestra lista de requisitos resultó ser rápidamente así: El estuche debe ser impermeable e imprimible en 3D. El sensor debe poder funcionar al menos 12 horas con la batería. La cámara debe protegerse de la lluvia y el agua rociada, y también debe funcionar en la oscuridad. El diseño necesita sostener la cámara, un sensor de temperatura / humedad, el módulo LTE, la computadora de placa única y algunos componentes electrónicos de potencia para convertir el voltaje al nivel apropiado. Se necesita una batería para continuar funcionando cuando el poste de luz está apagado (durante el día) Toda la configuración debe ser modular para facilitar la instalación y poder intercambiar componentes individuales en caso de falla. También debe ser pequeño y estar pintado de gris para parecer discreto en su entorno operativo. Condiciones de funcionamiento de -20 C a 70 C (ya que la configuración puede calentarse bastante en verano cuando está completamente expuesta al sol). Comenzamos con un diseño que incluye infrarrojos. LED (como los tienen muchas cámaras al aire libre) para poder operar en condiciones nocturnas.

Sin embargo, esta elección de diseño resultó tener algunos defectos: estos LED consumían bastante energía (en comparación con el resto de la electrónica), lo que hacía necesaria una fuente de alimentación no estándar. A pesar del gran consumo de energía, no eran realmente capaces de iluminar todo el campo de visión. Probablemente hubiéramos necesitado un proyector IR externo que, de nuevo, no era una alternativa seria.

Y, por último, el diseño con LED tampoco era muy bonito. Para superar el problema de las operaciones nocturnas, decidimos utilizar la configuración estática de la cámara: dado que la posición de la cámara es estática y los objetos que intentamos detectar normalmente también están quietos, podemos aumentar la exposición y la sensibilidad a la luz de los sensores para trabajar solo con luz residual. Así que sobrescribimos la exposición interna de las cámaras y el control ISO y escribimos un ciclo de retroalimentación simple que ajusta la configuración de iluminación en función de la luminancia del último cuadro capturado.

Este enfoque resultó funcionar bastante bien, ya que en la mayoría de las calles hay suficiente luz residual de las farolas. Después de varias iteraciones más, finalmente terminamos con el diseño que se muestra arriba: La cámara se encuentra dentro de un cono para protegerla del agua rociada. y reflejos solares tanto como sea posible. Los componentes electrónicos están montados en un zócalo en el interior y un cable plano conecta la cámara a la placa principal.

La parte inferior es removible y se monta en la caja con cuatro tornillos estándar. Dado que la caja está impresa en ABS, las tuercas cuadráticas se colocan en los recortes para garantizar que los tornillos se puedan apretar correctamente. Una junta tipo GoPro conecta la carcasa al soporte, que se sujeta al poste de luz usando cinta de acero estándar.

Todas las piezas están optimizadas para la capacidad de impresión en 3D, lo que significa que no hay voladizos pesados, importar superficies paralelas para obtener una superficie de alta calidad. Por último, la caja de la batería está separada del sensor para una mejor capacidad de servicio. Es una caja estándar de ABS moldeado por inyección y contiene 4.

Batería de plomo de 5 Ah y 12 V y una unidad de carga, que toma una entrada de 230 V (que es el voltaje de la mayoría de las luces de la calle en Alemania). ¿Qué sigue? Los datos que recopilamos a lo largo de este proyecto nos ayudan mucho a mejorar nuestra comprensión (y también algoritmos) de cómo funciona el estacionamiento en diferentes situaciones de tráfico y varios contextos de factores que influyen en la disponibilidad de estacionamiento. Próximamente publicaremos más sobre los resultados reales desde la perspectiva de la ciencia de datos.

También dedicaremos algo de tiempo y profundizaremos en los detalles de la parte del software y, finalmente, incluso abriremos el código fuente del software, así como los diseños de hardware. Agradecimientos En este punto, nos gustaría expresar nuestro agradecimiento a la ciudad de Braunschweig por darnos acceso a la infraestructura de tráfico para respaldar este proyecto. No solo proporcionaron todos los permisos necesarios, sino que también cubrieron parte de los costos.

También nos gustaría enviar un gran agradecimiento al operador de tráfico local Bellis y al proveedor de energía BS Energy por el apoyo con respecto a la instalación y el suministro de energía de los sensores. Sobre el autorJulian es el director ejecutivo y cofundador de Bliq, empresa de tecnología basada en. Bliq proporciona mapas de estacionamiento en vivo para desarrolladores en movilidad.

PREGUNTA RELACIONADA No recibí Google Glass Explorer Edition. ¿Es un esfuerzo inútil intentar aprender Glass dev sin el hardware? No, todavía puede aprender los fundamentos del desarrollo de vidrio sin el hardware.

Hay tres enfoques principales para lograr esto: 1) Visite la documentación de la API de Mirror, ingrese al patio de recreo y comience a elaborar un código. Descargue la biblioteca PHP, Java y Python, con la que se sienta más cómodo. Familiarízate con la jerga y las conjuras (línea de tiempo, paquetes, menús, etc).

Lea la documentación de soporte (segundo enlace a continuación) para ver cómo funciona realmente el hardware Glass. Cree algunas aplicaciones según esta especificación. Muy pronto, encontrará un amigo con hardware a t