Una transcripción detallada de otro informe de la reunión Yandex.Zhelezo: sobre el desarrollo de dispositivos para UAV.
- Hola a todos, mi nombre es Vitaly Podkolzin, soy el responsable del desarrollo de sistemas integrados para el proyecto de vehículos no tripulados. Y hoy me gustaría hablar con usted sobre qué es un automóvil no tripulado, qué componentes se incluyen en su composición, cómo hacer que el automóvil se mueva y cómo funcionan el piloto automático y sus componentes dependen de los dispositivos utilizados.
Para entender a dónde ir después, una persona primero necesita averiguar dónde está. Un auto no tripulado, también. Para esto, el subsistema de localización es responsable de nosotros. Entonces necesitas entender lo que está sucediendo a nuestro alrededor. El sistema de percepción o percepción es responsable de nuestra visión, percepción del mundo. Con base en los datos de ubicación, sobre los objetos que nos rodean, podemos hacer pronósticos sobre la situación de la carretera, su desarrollo y el comportamiento de los usuarios de la carretera. Y elija la ruta óptima de movimiento, trayectoria, convirtiéndola aún más en una acción de control.
Pero todo lo anterior son, en el caso general, algoritmos. Y podría ejecutar estos algoritmos en su computadora, si fuera lo suficientemente potente. Por supuesto, esto no haría un auto no tripulado con una computadora. Faltan dos cosas importantes.
El primero es un conjunto bastante rico de sensores, los principales de los cuales se enumeran en la diapositiva. Y, por supuesto, necesitamos una plataforma que ejecute nuestros comandos. Necesitas interactuar con ella.
Detengámonos en el tema de la interacción con el automóvil. El piloto automático, como una persona, necesita hacer cosas simples para conducir un automóvil: girar el volante, acelerar, reducir la velocidad. Una solución lógica podría parecer utilizar actuadores para controlar estos cuerpos.
Pero este enfoque tiene varias dificultades significativas. El desarrollo de un vehículo no tripulado aún implica la presencia de un conductor en ciertas etapas: debe llevar el automóvil a un servicio o monitorear el piloto automático cuando probamos varias características, especialmente en las primeras etapas. Estos dispositivos complican significativamente la vida del conductor.
Por supuesto, todo el sistema es complejo y, en general, dicha mecánica puede introducir retrasos desagradables en los controles. Esto afecta negativamente el circuito de control del vehículo.
Sí, todavía necesitábamos una plataforma simple al comienzo del proyecto, pero necesitábamos algún otro enfoque para interactuar con esta plataforma. Y comenzamos a cavar profundamente en el auto.
Después de estudiar las características de las diferentes plataformas, descubrimos que muchos automóviles modernos tienen la capacidad de controlar sus propios órganos. Por ejemplo, un asistente controla el volante durante el estacionamiento. El control de crucero afecta la aceleración del automóvil, el control de crucero adaptativo o un sistema de límite de velocidad pueden afectar el sistema de frenado.
Todos estos sistemas, por regla general, están cerrados en los automóviles. Y para interactuar con ellos, se requirió el desarrollo de una serie de dispositivos especializados. Además de interactuar con el automóvil, se requería que el sistema proporcionara una interfaz conveniente y fácil de usar para conducir el automóvil. Y, por supuesto, el sistema debería haber sido simple, directo y muy flexible.
Llegamos a una plataforma donde, dependiendo del automóvil, se desarrollan pequeños tableros de control que interactúan con un nodo específico. La composición y la funcionalidad de estas placas difieren de una plataforma a otra, pero todas se unen en una red, donde hay una unidad principal, que convencionalmente llamamos una puerta de enlace. Monitorea estos dispositivos. Además, la puerta de enlace proporciona una interfaz para piloto automático en dispositivos convenientes. Aquí vemos Ethernet, conveniente para nuestra infraestructura, y CAN, la interfaz automotriz más popular. Además, nuestra unidad principal interactúa constantemente con el automóvil, monitorea el estado de los componentes y ensamblajes. Si se detectan desviaciones, entonces, dependiendo de su naturaleza, junto con el piloto automático, se toma una decisión sobre los pasos adicionales.
Decidimos implementar la placa en microcontroladores bastante populares y probados. Los tomamos con un margen de rendimiento y elegimos aquellos que admiten las interfaces necesarias para el trabajo: CAN, Ethernet y entradas / salidas digitales analógicas.
Obtuvimos una solución que realmente resultó ser flexible para nosotros y que nos permitió cambiar de plataforma a plataforma con menos problemas.
Hablemos de sensores. Cada vehículo no tripulado tiene un rico conjunto de sensores. Cada vehículo no tripulado Yandex tiene cuatro lidares en el techo y tres en la parte delantera, seis cámaras que se colocan en el techo y seis radares: dos en la parte trasera y cuatro en la parte delantera, dos de los cuales se encuentran a los lados.
Tomamos radares, lidares, cámaras, nos conectamos, manejamos en la computadora. Pero no tan simple. Es muy importante asegurarse de que los datos del sensor sean adecuados y de alta calidad. Llevamos a cabo una gran cantidad de experimentos para comprender dónde colocar los sensores, de modo que podamos ver el mundo mejor y más claramente.
Además, nuestros diseñadores tuvieron que trabajar duro para garantizar que todos los cambios en el automóvil relacionados con los sensores cumplan con los requisitos de los organismos de certificación.
Esto es lo que pasó. Seis cámaras en el techo ofrecen una buena vista de 360 grados con una superposición significativa: las áreas oscuras están marcadas en la diapositiva. Estas cámaras también ofrecen una buena vista vertical. La cámara es el único sensor que ve los semáforos, ya que pueden ubicarse en diferentes partes, dependiendo de la intersección y otras cosas.
Los radares son otro sensor importante para cada automóvil. Son interesantes porque tienen un ángulo de visión no muy amplio, pero un buen alcance. Dos radares frontales realizan la función de monitorear lo que sucede adelante, los radares traseros en nuestros algoritmos se usan, por regla general, en la reconstrucción, adelantamientos y maniobras similares. Los radares que miran hacia los lados son necesarios para conducir a través de intersecciones bastante complejas donde la información de los sensores puede no ser suficiente.
Probablemente el sensor más interesante es lidar. Está interesado en la información que proviene de él. Aquí hay una nube de puntos, nube de puntos, estos son datos de lidars. Muestran peatones, automóviles, la carretera, incluso los bordes de la carretera y otros objetos. Las cajas ya son el resultado del trabajo de nuestros algoritmos de reconocimiento.
En total, todos los sensores dan aproximadamente la misma imagen. Como puede ver, es imposible no notar nada alrededor del automóvil con este conjunto de sensores.
Me gustaría detenerme en dos ejemplos que encontramos cuando necesitábamos desarrollar hardware. Comenzaré con el caso de localización.
La fuente principal son las tarjetas de alta definición. En cada momento, un vehículo no tripulado compara datos de lidars con estas tarjetas. Basado en tal comparación, obtiene su ubicación con precisión de centímetros. GPS, Glonass o cualquier otra navegación por satélite simplemente no es adecuada para trabajar con un vehículo no tripulado debido a su baja estabilidad, alta dependencia de condiciones externas, clima, ruido, interferencia. En la ciudad, todo esto se complica significativamente por las superposiciones de señales, los reflejos de los edificios, etc. Pero, ¿dónde obtenemos estas tarjetas? Construimos mapas nosotros mismos, utilizando nuestros vehículos no tripulados con un conjunto de sensores.
Para construir estos mapas, necesitamos lidares y algún tipo de referencia sobre el terreno. Necesitas de alguna manera obtener tu coordenada. El GPS podría dar inicialmente una coordenada, pero su precisión no es muy alta. Como dije, la precisión del GPS se ve afectada por las condiciones atmosféricas, las interferencias, y en la ciudad también hay reflejos.
La tecnología cinemática en tiempo real viene al rescate. La conclusión es: en algún lugar del suelo, se instala una estación base fija con el mismo dispositivo receptor que en un automóvil. Si la distancia entre el automóvil y la estación base no supera los 30 km (en algunos casos, 50 km), los datos de satélite recibidos por el automóvil y la estación base serán aproximadamente similares. Pero la estación base, que conoce su coordenada exacta (es estacionaria) y calcula la coordenada de acuerdo con los datos del satélite, recibe, condicionalmente, un error de cálculo. En base a este error, se desarrollan enmiendas que se envían por automóvil al automóvil a través de Internet. El automóvil, teniendo en cuenta las correcciones recibidas al calcular las coordenadas por satélite, obtiene sus coordenadas con una precisión de centímetros. Por supuesto, para trabajar con este sistema, necesita un buen canal de Internet y buen clima para que la señal GPS sea estable.
Para obtener un dispositivo que funcione con soporte RTK en un automóvil o estación base, necesita software. Las bibliotecas que proporcionan funciones RTK RTKLib están disponibles públicamente. Existen diferentes variaciones con diferentes características. Las bibliotecas generalmente requieren un entorno Linux y módulos de navegación por satélite que proporcionen datos sin procesar.
Después de realizar un par de experimentos, crear prototipos de un par de cosas, obtuvimos un diagrama de bloques del bloque de localización, al que llamamos GeoHub.
Además del módulo de navegación por satélite especificado, también hay un módulo de mediciones de inercia, que utilizamos en el sistema de localización. Internet está llegando ahora a través de la interfaz Ethernet que es conveniente para nuestra infraestructura.
Aquí está el segundo dispositivo, su segunda generación y las principales características técnicas.
Reemplazamos el módulo de medición de inercia y el módulo de señal satelital. Como resultado, nos permitió llevar a cabo una serie de experimentos en un automóvil y elegir el módulo de medición de inercia que sea óptimo desde el punto de vista de varios parámetros, y en cuanto al módulo de señal satelital, pudimos cambiar a un receptor de doble banda en el proceso, lo que mejoró significativamente la calidad de la determinación de la ubicación.
¿Por qué desarrollar su dispositivo cuando ciertamente puede ir al mercado y comprar algo similar? La respuesta es que para nosotros, uno de los parámetros más importantes es la flexibilidad del dispositivo. Debido a los requisitos que cambian rápidamente en el proyecto, la nueva funcionalidad emergente, debemos ser capaces de responder muy rápidamente a esto. Solo teniendo dentro del proyecto, internamente, el desarrollo de hardware y software, obtenemos una velocidad realmente alta de desarrollo de estos cambios.
Otro sensor interesante desde el punto de vista de un vehículo no tripulado es la cámara. De acuerdo, hay una cámara en cada teléfono y computadora portátil. ¿Qué podría ser complicado aquí? Pero veamos qué problemas puede encontrar al usar la cámara en un dron.
El primer problema es el parpadeo de las fuentes de luz LED. La mayoría de los semáforos son solo tales fuentes. El video se detuvo en el momento en que, debido al parpadeo, la señal roja casi desapareció.
Para este problema, hay soluciones de hardware integradas en el sensor, pero para que funcione bien y con alta calidad, debe poder interactuar activamente con el sensor.
El segundo requisito para las cámaras es un alto rango dinámico, es decir, la capacidad de trabajar en cualquier condición de luz, tanto de noche como a pleno sol. La presencia de HDR también es importante, es decir, la posibilidad de combinar cuadros con iluminación diferente en uno para obtener una mejor imagen.
A la izquierda hay un ejemplo de una imagen donde se usa la función HDR, y a la derecha, donde está deshabilitada.
Además, nosotros, por supuesto, debemos obtener una imagen con una resolución suficiente y una velocidad de fotogramas suficiente. En la diapositiva, se destacan un par de puntos más, inherentes a los vehículos no tripulados, incluidos. La cámara debe producir una transmisión de video sin comprimir, preferiblemente del formato RGB888, porque nuestras redes y algoritmos funcionan con este formato, desean recibir cuadros en este formato.
La mayoría de las cámaras, soluciones listas para usar en el mercado, proporcionan datos comprimidos: H264, MPEG. Los problemas aquí son simples: perdemos calidad durante la compresión e introducimos un retraso en la compresión y descompresión. El retraso puede ser no determinista, especialmente a altas cargas del sistema. Una cámara con resolución Full HD y una frecuencia de 30 cuadros por segundo con una velocidad de bits de 16 bits por píxel produce una transmisión de aproximadamente gigabits por segundo de datos de video puro.
Además, las cámaras suelen ubicarse a cierta distancia del dispositivo receptor, y en el automóvil, especialmente durante algunos experimentos, pueden ubicarse generalmente en el otro extremo del automóvil. Necesitábamos cámaras que permitieran transmitir todo el flujo de video sin comprimir a una distancia de 6-8 metros, teniendo en cuenta el cableado. Para una cámara Full HD con 16 bits por píxel, el flujo de video es de 1 gigabit, lo que ya no permite el uso de gigabit Ethernet, ya que varios datos de servicio, etc., están involucrados en la transferencia. Diez gigabit Ethernet no es del todo apropiado. Es caro, alto consumo de energía, alta disipación de calor, mayor complejidad de la infraestructura de red.
Sí, hay otras interfaces interesantes. Me gustaría hablar sobre dos de ellos con los que hemos trabajado. Son proporcionados por Maxim Integrated y Texas Instruments. La peculiaridad es que el flujo de video se serializa en datos que van en un nivel físico simple, en este caso a través de un cable coaxial, a una velocidad de 3-4, a veces 6 gigabits por segundo. Además, esta interfaz le permite utilizar el canal de retorno para controlar la cámara en el mismo cable coaxial. Y en eso puede ir la cámara. Todo lo anterior hace que esta interfaz sea muy atractiva.
Cuando comenzamos, encontramos una solución en el mercado que básicamente satisface la mayoría de los requisitos. Lo usamos durante algún tiempo al comienzo del proyecto.
El diagrama de bloques de la solución está delante de usted. Este es un sensor desde el cual los datos se serializan a la interfaz GMSL / FPD-Link. En la parte receptora, que se puede quitar hasta 15 metros, los datos se deserializan y se transmiten al receptor. En nuestra solución, este receptor proporcionó datos a través de la interfaz USB 3.0.
Pero al comenzar a usar esta solución, nos encontramos con una serie de problemas desagradables. El problema principal: la solución funcionó extremadamente inestable, "se cayó" en el proceso, las cámaras no se iniciaron bien cuando se inició el piloto automático. Además, la solución no permitió ajustar los parámetros de los propios sensores para mejorar la calidad de la imagen. También hubo una serie de problemas. Por ejemplo, fue difícil obtener la marca de tiempo exacta de la cámara, el tiempo de disparo, lo cual es bastante importante, porque a una velocidad de 15 m / s con un retraso de 100 ms, el automóvil ya viaja un metro y medio, y esto puede afectar muy negativamente a los algoritmos de percepción.
Hubo otro punto interesante. La interfaz de salida de la solución seleccionada fue USB 3.0, y descubrimos que era extremadamente ruidosa. ¿Cómo entendemos esto? Teníamos dos autos no conectados a nada. En uno, lanzaron la cámara, en ambos, la señal de navegación por satélite se hundió mucho. Entonces comenzamos a estudiar lo que estaba pasando.
Después de analizar todas estas deficiencias en general, después de estudiar el diagrama estructural frente a usted, etc., llegamos a la conclusión de que el problema está en la parte receptora. Luego comenzaron a pensar qué hacer con él. Analizamos lo que hay en el mercado, las soluciones de otros equipos y llegamos a la conclusión de que necesitamos hacer nuestro propio dispositivo receptor que funcione con la cámara a través de la interfaz GMSL o FPD-Link.
Tomamos deserializadores, que, por regla general, tienen una interfaz MIPI CSI2, y comenzamos a buscar un módulo o procesador que pudiera admitir esta interfaz. Y encontramos una solución interesante con seis interfaces MIPI CSI2, así como un alto rendimiento y periféricos ricos. Esto nos permitió eventualmente usar la interfaz Ethernet de 10 gigabits que es conveniente para nuestra infraestructura de red como la interfaz de salida de este dispositivo. Después de recibir datos de GMSL / FPD-Link de 6 cámaras (o, en algunos casos, de 12 cámaras), haberlas procesado, el dispositivo transfiere la transmisión de video ya procesada a la computadora a través de Ethernet de 10 gigabits.
Aquí está la solución en sí y sus características principales. Habiendo desarrollado tal cosa, aprendimos no solo cómo trabajar de manera confiable con 6 o 12 cámaras, sino que también tuvimos la oportunidad de ajustar las cámaras. Esto permitió mejorar la calidad de la imagen, lo que afectó positivamente el funcionamiento de los algoritmos de percepción. También obtuvimos una comprensión clara del tiempo que se tarda en fotografiar el marco y aprendimos a manejar este tiempo. Y las CPU de alto rendimiento, la potencia informática del módulo nos permitió llevar a cabo el procesamiento primario de video con demoras mínimas directamente en el módulo.
El códec de hardware de este módulo también permitió comprimir datos de video para su posterior almacenamiento en los registros.
Tuvimos que trabajar no solo con sensores de localización y cámaras. Tuvimos que desarrollar soluciones de hardware para casi todos los sensores que usamos. Todo esto se hizo para resolver el aumento de la fiabilidad y la calidad de los datos de los que dependen los algoritmos de detección y percepción. Y depende de ellos qué tan óptima será la solución emitida por el piloto automático.
De acuerdo, aprendimos a conducir un automóvil, trabajamos con sensores, los posicionamos bien, les enseñamos a darnos una imagen de alta calidad. ¿Qué otro trabajo hacen los ingenieros de sistemas embebidos, trabajadores de hardware en nuestro proyecto? Monitoreamos no solo el desarrollo de sensores que se han convertido en rutina, sino también fuentes alternativas de información. Estamos constantemente explorando aceleradores alternativos de redes neuronales y otros algoritmos, incluidos los que usan FPGA. Y es difícil imaginar el desarrollo del proyecto sin interacción con un fabricante de automóviles experimentado.
— , , .
. , . , , , . , .