Semana 15 - Automatización
Índice
- Herramientas contempladas
- Organización
- Script de generación de dataset
- Script de entrenamiento y testeo
- Script generación y entrenamiento
- Debugging
Herramientas contempladas
Ahora que las pruebas con el dataset son mucho más frecuentes y hay que grabar varios datasets para pruebas, el proceso más pesado es grabar los datasets e ir comprobando uno a uno todos los resultados, por lo que esta semana nos centraremos en la automatización del entrenamiento. Esto nos permitirá un estudio más rápido y efectivo de las redes neuronales.
Investigando, no se encontró un programa o librería que sea capaz de realizar esta tarea. Dependiendo del lenguaje de programación, se necesitarían cargar distintas librerías que monitorizaran el sistema operativo. Por lo tanto, la solución más sencilla fue hacer esta automatización por scripts de bash, ya que todo lo que necesitamos realmente es mandar comandos al sistema.
Se encontraron varios enlaces interesantes pero no ofrecían lo que se buscaba.
Organización
El siguiente paso fue subdividir los problemas.
-
Script de generación de dataset: Este script se encargaría de, a partir de un piloto experto seleccionado, generar un dataset y usando el script rosbag2generalDataset.py generar un dataset.
-
Script de entrenamiento y testeo: Un script que junte la etapa de entrenamiento con distintos parámetros y después del entrenamiento de la red mida su rendimiento. Dejándolo una lista de resultados numéricos del desempeño del mapa.
-
Una vez hechos estos 2 scripts, podemos añadir otra capa de abstracción que nos permita realizar todo este proceso donde, partiendo de un piloto experto, el programa realice el dataset y con varias distribuciones del mismo dataset entrene varias redes, dejando en un documento la comparación entre el camino ideal, el piloto experto y el piloto neuronal.
-
Una buena práctica podría ser dejar un documento con configuraciones del piloto experto y el entrenamiento para que no todo dependa de parámetros y tener el código mejor organizado.
-
Además, aunque con mejor organización, también se generarán los datos generados las anteriores semanas para la posibilidad de análisis manual y una buena organización de cada prueba.
-
Como documentación adicional, la dinámica y ejecución de estos scripts quedará reflejada en el README.
Script de generación de dataset
Se utilizó tmux que permitió un desarrollo fácil de la interfaz. Primero se divide la ventana en 3, en una se ejecutará el simulador, en otra el piloto experto y en otra el rosbag recorder. Se muestra así para tener la posibilidad de depurar. En un bucle se va ejecutando cada circuito en ambas direcciones.
Hay que tener en cuenta que la salida del piloto experto se volcará a un fichero para que solo se empiece a grabar cuando el drone esté siguiendo la línea. Cuando se pase el tiempo de grabación pasado por argumento, se pasará al siguiente mapa.
Una vez terminado el proceso, se generará el dataset y se saldrá de la sesión de tmux. Y por último, se muestra la distribución del dataset.
Script de entrenamiento y testeo
Para este script, se realizó un procedimiento parecido. Primero, en la terminal principal se ejecuta el entrenamiento. Después de este mismo, se ejecuta el piloto experto y el neuronal en circuito de test. Por último, se muestran los resultados finales del entrenamiento.
Script generación y entrenamiento
Al script de entrenamiento se le añadieron varios argumentos optativos booleanos, entre ellos (Custom balance), que balanceará pero no totalmente, y augmentation. Para probar si realmente estas opciones son efectivas.
Primero se grabará el piloto experto y después entrenará las 3 redes neuronales a la vez. Posteriormente, probará uno a uno y comparará las soluciones.
Este script nos permitirá finalmente, con una sola línea, ejecutar el proceso de obtención del dataset, entrenamiento y testeo.
Debugging
Antes, a la hora de ejecutar, se mostraban varias pestañas para depurar.
- Imagen filtrada: Se añadió un argumento para que se muestre o no.
- Consola tmux Aerostack2: Como solo se utilizaba las primeras semanas cuando se estaba implementando la base del software, se decidió que directamente no se mostrase comentando su línea en el launcher.
- Cliente gazebo: Normalmente es favorable tenerlo abierto ya que nos permite un seguimiento del funcionamiento del drone, pero tras varias pruebas en ocasiones es favorable que solo se ejecute el servidor para ahorrar almacenamiento. Sin embargo, esto no depende del launcher de nuestro paquete sino el de aerostack. Fácilmente se puede añadir una variable de entorno para dejar el cliente activo o desactivado, pero de momento se hizo lo mismo que con el elemento anterior, se comentó.