Al crear un vehículo inteligente no tripulado StarLine, un paso importante no es solo el desarrollo del software principal (software) que se ejecuta en él, sino también la creación de elementos de infraestructura diseñados para simplificar las pruebas del sistema desarrollado. Uno de los elementos clave es un simulador virtual.
Cada vez que se desarrolla un nuevo algoritmo o se moderniza uno existente, surge la necesidad de realizar pruebas exhaustivas antes de usarlo en un automóvil en condiciones reales de la carretera. Si el comportamiento del software requerido está predeterminado, entonces se pueden usar pruebas de software especiales para las pruebas preliminares. Sin embargo, tienen varios inconvenientes importantes: en primer lugar, su creación para cada algoritmo requiere costos de tiempo significativos; en segundo lugar, no pueden usarse si el comportamiento del sistema no está estrictamente regulado.
Por lo tanto, para la verificación inicial de los algoritmos de investigación y prueba, generalmente se acepta usar un simulador en el que se crea un doble virtual de un automóvil no tripulado y su comportamiento se simula en varios escenarios de carretera.
Además, el uso del simulador ofrece una serie de ventajas:
- Se reduce el tiempo de prueba para el software desarrollado: es mucho más fácil ejecutar un simulador que recrear un script de interés en el mundo real;
- es posible realizar pruebas en las situaciones de tráfico más improbables y difíciles sin riesgo para las personas o la infraestructura;
- Es posible reproducir repetidamente la misma situación de tráfico en las mismas condiciones.
Debe entenderse que la desventaja clave del simulador es la imposibilidad de crear mundos virtuales totalmente realistas. Como resultado, el uso del simulador no reemplaza completamente las pruebas en un automóvil real, sino que solo reduce su número.
En los últimos años, ha habido muchos simuladores abiertos diseñados para probar software de vehículos no tripulados:
Gazebo ,
V-Rep ,
Webots ,
LGSVL Simulator ,
MicrosoftAirSim ,
CARLASimulator ,
Deepdrive y muchos otros.
Entonces, ¿por qué, con tanta variedad de simuladores existentes, elegimos Gazebo? Todo se explica de manera bastante simple: necesitábamos en el menor tiempo posible un simulador simple que tenga una buena integración con ROS y todas las herramientas necesarias para crear una copia virtual de nuestro automóvil. Para resolver nuestro problema, era necesario simular el funcionamiento de varios sensores (lidares, cámaras, sistema de navegación inercial, etc.), el control y la dinámica de un automóvil, semáforos y peatones. Todo esto estaba presente en Gazebo en forma de complementos.
Para crear una copia de seguridad virtual para un vehículo no tripulado, tomamos su modelo 3D y establecimos los parámetros cinemáticos y dinámicos básicos: masa del automóvil, agarre de la rueda, radio de giro mínimo, etc. Luego lo equipamos con copias virtuales de todos los sensores que usamos y establecemos parámetros idénticos a las características de sus prototipos reales.
Para crear polígonos virtuales en Gazebo, utilizamos mapas de terreno construidos en el mundo real: todos los objetos se colocan en las mismas posiciones que en la realidad. Al mismo tiempo, pasamos a la simulación: la red de carreteras, las señales de tráfico, los cruces de ferrocarril, los semáforos y los principales participantes en el tráfico por carretera: peatones y automóviles.
Por ejemplo, este es el modelo del autopolito utilizado por nosotros para prepararnos para la calificación de la competencia tecnológica
"Ciudad de Invierno" :
Durante la preparación, el doble virtual de un vehículo no tripulado supera varias veces varias rutas en un campo de entrenamiento virtual.
Si observa el polígono creado, pueden surgir varias preguntas: ¿por qué es un realismo tan bajo? ¿Dónde están las casas, la caída de nieve, los árboles, etc.? En este caso, tales detalles son redundantes y ausentes, porque el simulador debe reflejar solo aquellos aspectos del mundo real que son más importantes para el sistema de software actual. Agregar aspectos redundantes requeriría mucho más tiempo que los ahorros del uso del simulador. Es importante recordar que la configuración final y las pruebas se llevan a cabo en un automóvil real.
El uso del simulador Gazebo nos dio una serie de ventajas durante el proceso de desarrollo. Sin embargo, destacamos una serie de deficiencias que se están volviendo cada vez más importantes en el proceso de desarrollo del automóvil StarLine no tripulado. Las desventajas significativas de Gazebo incluyen:
- errores en el funcionamiento de los rayos verticales de los lidares 3D al calcularlos en una tarjeta de video;
- falta de herramientas para la generación automática de infraestructura urbana y escenarios viales;
- bajo realismo que simula la dinámica del automóvil;
- bajo fotorrealismo;
- falta de condiciones climáticas simuladas.
En este sentido, planeamos cambiar el simulador utilizado, si para fines de año Gazebo permanece en el mismo nivel de programa.
También en el futuro, planeamos crear pruebas completamente automáticas y continuas de todo el software StarLine para automóviles inteligentes en una simulación implementada en un servidor remoto. Esto le permitirá acumular kilómetros virtuales para cada versión del software y asegurarse de que cada algoritmo desarrollado haya sido probado exhaustivamente antes de implementarse en un vehículo real no tripulado.
Instagram