Cómo hicimos el piloto automático para una estación de servicio

Hola Habr! Trabajo en una pequeña startup en Berlín que desarrolla pilotos automáticos para automóviles. Estamos completando un proyecto para estaciones de servicio de un importante fabricante de automóviles alemán, y me gustaría hablar sobre ello: cómo lo hicimos, qué dificultades encontramos y qué cosas nuevas descubrimos. En esta parte hablaré sobre el módulo de percepción y un poco sobre la arquitectura de la solución en su conjunto. Sobre el resto de los módulos, probablemente lo diremos en las siguientes partes. Estaré muy contento de recibir comentarios y una mirada desde el exterior sobre nuestro enfoque.

El comunicado de prensa del proyecto del cliente se puede encontrar aquí .

Para empezar, te diré por qué el fabricante de automóviles se dirigió a nosotros y no hizo el proyecto por su cuenta. Para las grandes empresas alemanas es difícil cambiar los procesos, y el formato de desarrollo del automóvil rara vez es adecuado para el software: las iteraciones son largas y requieren una buena planificación. Me parece que los fabricantes de automóviles alemanes entienden esto y, por lo tanto, puede conocer nuevas empresas fundadas por ellos, pero que trabajan como una empresa independiente (por ejemplo, AID de Audi y Zenuity de Volvo). Otros fabricantes de automóviles están organizando eventos como Startup Autobahn, donde buscan posibles contratistas para tareas y nuevas ideas. Pueden solicitar un producto o prototipo y, después de un corto período de tiempo, obtener el resultado final. Esto puede resultar más rápido que intentar hacer lo mismo usted mismo, y no cuesta más que su propio desarrollo en términos de costos. La complejidad de los cambios en el proceso está bien demostrada por la cantidad de permisos necesarios para comenzar a probar un automóvil con piloto automático en los clientes: consentimiento para la grabación de video de personas (incluso si no guardamos datos, y usamos la transmisión de video solo en forma anónima sin identificar a personas específicas), consentimiento para la grabación de video territorios, el consentimiento del sindicato y el cónsul de trabajo para probar estas tecnologías, el consentimiento del servicio de seguridad, el consentimiento del servicio de TI; esta no es la lista completa.

Desafío

En el proyecto actual, el cliente quiere comprender si es posible conducir automóviles en centros de servicio utilizando "AI". El script del usuario es:

1. El técnico quiere comenzar a trabajar con una máquina que esté en algún lugar del estacionamiento fuera del área de prueba.
2. Selecciona el automóvil en la tableta, selecciona la casilla de servicio y hace clic en "Conducir adentro".
3. El automóvil conduce adentro y se detiene en el punto final (elevador, rampa u otra cosa).
4. Cuando el técnico termina de trabajar en el automóvil, presiona un botón en la tableta, el automóvil sale y se estaciona en un espacio vacío afuera.

Características: no todos los autos tienen cámaras. En las máquinas en las que se encuentran, no tenemos acceso a ellas. Los únicos datos en la máquina a los que tenemos acceso son sonares y odometría.


Por lo tanto, el automóvil debe ser controlado por sensores externos instalados en el área de servicio.

Solución

La arquitectura del producto final es la siguiente:

• En el área de servicio instalamos cámaras externas, lidares y otras cosas (hola Tesla).
• Los datos de las cámaras van a Jetson TX2 (tres cámaras cada uno), que se dedican a la tarea de encontrar la máquina y procesar previamente las imágenes de las cámaras.
• Además, los datos de la cámara llegan al servidor central, que con orgullo se llama Torre de control y en el que caen en los módulos de percepción, seguimiento y planificación de rutas. Como resultado del análisis, se toma una decisión sobre la dirección de movimiento adicional del automóvil y se envía al automóvil.
• En esta etapa del proyecto, se coloca otro Jetson TX2 en el automóvil, que, utilizando nuestro controlador, se conecta a Vector, que descifra los datos del automóvil y envía comandos. TX2 recibe comandos de control de un servidor central y los transmite al automóvil.

Para el nivel de infraestructura, se utiliza ROS .

Esto es lo que sucede después de que un técnico elige un automóvil y hace clic en "conducir":

1. El sistema está buscando un automóvil: enviamos un comando al automóvil para que parpadee las alarmas, después de lo cual podemos determinar cuál de los automóviles en el estacionamiento es seleccionado por el técnico. En la etapa inicial de desarrollo, también consideramos la opción de determinar la máquina por la placa de matrícula, pero en algunas áreas del automóvil estacionado el número puede no ser visible. Además, si tomamos la determinación del automóvil por el número de registro, entonces la resolución de las fotos tendría que aumentarse considerablemente, lo que afectaría negativamente el rendimiento, y utilizamos la misma imagen para buscar y conducir. Esta etapa ocurre una vez y se repite solo si por alguna razón perdimos el auto en el seguimiento.
2. Tan pronto como se encuentra el automóvil, soltamos las imágenes de las cámaras que el automóvil golpea en el módulo de percepción, que segmenta el espacio y proporciona las coordenadas de todos los objetos, su orientación y tamaños. Este proceso está en curso y se ejecuta a aproximadamente 30 fotogramas por segundo. Los procesos posteriores también son constantes y se ejecutan hasta que la máquina llega al punto final.
3. El módulo de seguimiento recibe información de percepción, sonares y odometría, almacena todos los objetos encontrados en la memoria, los combina, refina la ubicación, predice la posición y la velocidad de los objetos.
4. A continuación, el planificador de ruta, que se divide en dos partes: planificador de ruta global para la ruta global y planificador de ruta local para el local (responsable de evitar obstáculos), construye una ruta y decide a dónde ir a nuestro automóvil, envía un comando.
5. Jetson toma el comando en automóvil y lo transmite al automóvil.

La salida se realiza de la misma manera que la llegada.

La percepción

Uno de los principales y, en mi opinión, el módulo más interesante es la percepción. Este módulo describe los datos de los sensores de tal manera que puede tomar una decisión precisa sobre el movimiento. En nuestro proyecto, proporciona las coordenadas, orientación y tamaños de todos los objetos que caen sobre la cámara. Al diseñar este módulo, decidimos comenzar con algoritmos que nos permitieran analizar la imagen de una sola vez. Intentamos:

1. VAE desenredado . Una pequeña modificación hecha a β-VAE nos permitió entrenar la red para que los vectores latentes almacenaran la información de la imagen en una vista esquemática de arriba hacia abajo.
2. GAN condicional (la implementación más famosa es pix2pix ). Esta red se puede usar para construir mapas. También lo usamos para construir una vista esquemática desde arriba, colocando datos de una o todas las cámaras al mismo tiempo y esperando una vista esquemática desde arriba en la salida.

Una de las iteraciones condicionales de GAN para una cámara, de izquierda a derecha: imagen de entrada, predicción de red, resultado esperado



De hecho, la idea de estos enfoques es garantizar que la red final pueda comprender la ubicación y orientación de todos los automóviles y otros objetos en movimiento que han caído sobre la cámara mirando la foto de entrada una vez. Los datos sobre objetos en este caso se almacenarán en vectores latentes. La capacitación de la red se realizó con los datos del simulador, que es una copia exacta del punto donde se realizará la demostración. Y logramos ciertos resultados, pero decidimos no usar estos métodos por varias razones:

• En el tiempo asignado, no pudimos aprender a usar datos de vectores latentes para describir la imagen. El resultado de la red siempre ha sido una imagen: una vista superior con un diseño esquemático de los objetos. Esto es menos preciso y temíamos que tal precisión no fuera suficiente para conducir un automóvil.
• La solución no es escalable: para todas las instalaciones posteriores y para los casos en que necesite cambiar la dirección de algunas cámaras, se requiere la reconfiguración del simulador y la capacitación completa repetida.

Sin embargo, estábamos interesados ​​en comprender las posibilidades de estos enfoques, y los tendremos en cuenta para futuras tareas.

Después de eso, abordamos la tarea por otro lado, a través de una búsqueda regular de objetos + una red para determinar la posición espacial de los objetos encontrados (por ejemplo, esto o aquello ). Esta opción nos pareció la más precisa. Lo único negativo es que es más lento que los enfoques propuestos anteriormente, pero se ajusta a nuestro posible marco de retraso, ya que la velocidad del automóvil en el área de servicio no es más de 5 km / h. El trabajo más interesante en el campo de la predicción de la posición 3D del objeto nos pareció ser este , que muestra muy buenos resultados en KITTI . Construimos una red similar con algunos cambios y escribimos nuestro propio algoritmo para determinar el cuadro circundante y, para ser más precisos, un algoritmo para estimar las coordenadas del centro de la proyección del objeto en el suelo; para tomar decisiones sobre la dirección del movimiento, no necesitamos datos sobre la altura de los objetos. La imagen del objeto y su tipo (automóvil, peatón, ..) se alimentan a la entrada de la red, y se envían sus dimensiones y orientación espacial. A continuación, el módulo evalúa el centro de proyección y proporciona datos para todos los objetos: las coordenadas del centro, la orientación y las dimensiones (ancho y largo).

En el producto final, cada imagen se ejecuta primero a través de la red para buscar objetos, luego todos los objetos se envían a la red 3D para predecir la orientación y el tamaño, después de lo cual estimamos el centro de proyección de cada uno y lo enviamos y los datos de orientación y tamaño. Una característica de este método es que está muy relacionado con la precisión del límite del cuadro de límite de la red de búsqueda de objetos. Por esta razón, las redes como YOLO no nos convenían. Encontramos el equilibrio óptimo de rendimiento y precisión del cuadro de límites en la red RetinaNet.

Vale la pena señalar una cosa con la que tuvimos suerte en este proyecto: la tierra es plana. Bueno, es decir, no es tan plano como una comunidad conocida, pero no hay curvas en nuestro territorio. Esto permite el uso de cámaras monoculares fijas para proyectar objetos en las coordenadas del plano terrestre sin información sobre la distancia al objeto. Los planes futuros incluyen la introducción de la predicción de profundidad monocular. Hay muchos trabajos sobre este tema, por ejemplo, uno de los últimos y muy interesantes que estamos intentando para futuros proyectos. La predicción de profundidad le permitirá trabajar no solo en terreno plano, sino que también podría aumentar la precisión de la determinación de obstáculos, simplificar el proceso de configuración de nuevas cámaras y eliminar la necesidad de etiquetar cada objeto; no nos importa qué tipo de objeto es si es algún tipo de obstáculo.

Eso es todo, gracias por leer, y estaré encantado de responder preguntas. Como beneficio adicional, quiero hablar sobre un efecto negativo inesperado: al piloto automático no le importa la orientación del automóvil, para él no importa cómo ir, adelante o atrás. Lo principal es conducir de manera óptima y no chocar con nadie. Por lo tanto, existe una alta probabilidad de que el automóvil recorra parte del camino en reversa, especialmente en áreas pequeñas donde se requiere alta maniobrabilidad. Sin embargo, las personas están acostumbradas al hecho de que el automóvil se está moviendo principalmente hacia adelante, y a menudo esperan el mismo comportamiento del piloto automático. Si una persona de negocios ve un automóvil que, en lugar de conducir al frente, viaja hacia atrás, entonces puede considerar que el producto no está listo y contiene errores.

PD: Pido disculpas porque no hay imágenes y videos con pruebas reales, pero no puedo publicarlos por razones legales.