• Para poder continuar con el desarrollo de brain con predicción de control, primero he adaptado tanto el código que usamos para la grabación de dataset como el de predicción, brain_rec y brain_predict.

• Se han eliminado, por el momento, el sensor LiDAR y su visualización, ya que se está trabajando con la cámara frontal y así reducimos el coste computacional.

• Modo síncrono para que la simulación avance de forma controlada, frame a frame, y para que los sensores, imágenes, control y etiquetas queden alineados temporalmente.

• Ajuste del tamaño de imagen a mejor resolución, para reducir carga computacional.

He estado probando la simulación con los últimos modelos entrenados en semanas anteriores para testear qué tal funcionan en este nuevo entorno de simulación. Se predice de forma coherente el steering, realizando correcciones de volante y giros siguiendo las carreteras de los entornos. No obstante, está por refinar el balanceo de los datos y su el entrenamiento.

Ahora estoy en la grabación de un dataset que esté bien registrado y con el entrenamiento de un modelo con PilotNet con este nuevo conjunto de datos.

Ya se ha empezado y avanzado con la redacción del segundo capítulo y se sigue a la espera de que esté operativo el servidor Libélula, para poder continuar con el desarrollo y las pruebas en Carla del sistema de control (brain) con un modelo de predicción entrenado con PilotNet.

Estas últimas semanas, debido a que se está pendiente de que se restablezca el servidor Libélula, he estado organizando el contenido en Overleaf y la bibliografía de consulta para la realización de este proyecto, además de redactar el contenido de la introducción y el estado del arte de la memoria.

Además, se estuvo probando en otro PC (con Carla instalado) el último modelo entrenado con PilotNet. Sin embargo, no se pueden extraer conclusiones de las simulaciones realizadas debido a diversos factores condicionantes (PC, GPU del equipo, dataset, entrenamiento, etc).

Semana 21: Redacción de la memoria

Esta última semana se ha continuado con la redacción del capítulo introductorio y con la estructura de los ficheros de Overleaf (que causaban errores la semana anterior).

La estructura que se plantea para el índice de la memoria, con respecto a los dos primeros capítulos, es la siguiente:

1.Introducción y objetivos
- 1.1 Contexto y motivación
- 1.2 Aprendizaje profundo extremo a extremo
- 1.3 Objetivos
- 1.4 Metodología
- 1.5 Organización de la memoria

2.Estado del Arte
- 2.1 Sensores LiDAR
- 2.2 Segmentación semántica
- 2.3 Conducción autónoma
- 2.4 Aprendizaje por Imitación

Se espera poder seguir avanzando en las próximas semanas con el entrenamiento de modelos de conducción autónoma.

Esta modificación de nuestro cerebro es una adaptación para poder simular la conducción autónoma del coche mediante la predicción de un modelo. A diferencia de brain, este módulo no cuenta con teleoperación por teclado del vehículo, si no que a medida que avanza la simulación, el modelo entrenado predice los actuadores del vehículo y se aplican al simulador con vehicle_control.

Además, y pese a las dificultades para simular con el equipo actual, se ha ido probando la predicción de los últimos modelos entrenados en varios escenarios de Carla. Se ha configurado en dichas pruebas que throttle sea constante (=0.5) y steer sea el valor de salida del modelo de PilotNet.

El coche acaba por desviarse o colisionar con obstáculos en las vías, ya que la tasa de frames a la que se generan imágenes (entrada del modelo) y la velocidad a la que puede procesar/recibir el modelo es muy baja. Por tanto, se va acumulando error en la predicción a causa del retardo. El modelo acaba prediciendo frames de momentos que ya han sucedido y la predicción llega tarde, por lo que no reacciona a tiempo.

Como se ha explicado anteriormente, con throttle constante y a un valor intermedio, conseguimos “ganar tiempo” para que el modelo pueda predecir y reaccionar. Los resultados de simulación con las predicciones de steer han sido satisfactorias y coherentes, en cuanto a conducción se refiere, y a pesar de las dificultades.

A continuación, un ejemplo de la predicción del último modelo entrenado con PilotNet: https://youtu.be/bm7dYxGvnlc

Principalmente, se ha revisado el dataset completo con el objetivo de eliminar muestras que pudieran causar error en el aprendizaje del modelo durante el entrenamiento, es decir, todas aquellas muestras que son de mala conducción hecha a propósito que finalmente tienen una rectificación (reflejada en los actuadores). Dejando las muestras que forman parte de la rectificación o corrección del error.

Posteriormente se ha balanceado el dataset, ya con las muestras que son de interés, y se ha procedido al entrenamiento de un modelo de redes neuronales con PilotNet. A diferencia de estas últimas semanas, la salida de esta red neuronal será de los actuadores steer y throttle.

Tras realizar varios entrenamientos y ver progresos positivos con respecto a las anteriores semanas y que el modelo converge (comparando los valores de pérdida de train y val), se piensa que el error no está en el entrenamiento o en el dataset. La predicción, como se ha explicado en anteriores reportes semanales, empieza siendo acertada y coherente desde el punto de vista de la conducción en los primeros segundos. No obstante, a causa de un frame rate muy bajo (5 FPS) la predicción no está sincronizada con los frames a medida que avanza nuestro vehículo. Esto provoca que el coche se desvíe, a falta de recibir un valor actualizado de los actuadores, y a pesar de poder llegar a ‘reengancharse’ a la conducción con algún frame nuevo actualizado, la corrección en la predicción no llega a tiempo.

Para aumentar el número de FPS se ha intentado optimizar el código durante la simulación: evitar prints innecesarios, corregir funciones asíncronas (callbacks), quitar la visión de la cámara frontal (que visualizábamos con pygame), etc. Sin embargo, sigue siendo insuficiente.

Se plantea, por ahora, la realización de un test off-line, con la creación de un nuevo dataset (o buscar alguno de dominio público) y realizar pruebas de predicción para poner a prueba el modelo.

A continuación, un ejemplo de la predicción del último modelo entrenado con PilotNet: https://youtu.be/h_bwam8taaE

Posteriormente se ha balanceado el conjunto de datos de siguiendo el siguiente criterio: la parte central del (valores de steer rondando el 0) se han mantenido con mayor número de muestras al ser el caso más común en conducción, se ha aumentado el resto de los bins que eran menos comunes y los valores más extremos (que representan giros forzados o volantazos) se han aumentado también, pero en menor proporción que los demás casos. El aumento de datos se ha realizado repitiendo casos ya existentes en el dataset.

A diferencia de las anteriores semanas y por probar con alternativas al uso de steer_rate label de entrada a nuestro modelo, se ha vuelto probado con el valor de steer, cuyos valores obtenidos son a partir del mismo valor de steer_rate. Gracias al valor de steer_rate, como entrada de teclado, obtenemos valores de steer mucho más graduales que en semanas anteriores, lo cual nos proporciona gran variedad de etiquetas para entrenar un modelo.

A continuación se muestra el balanceo explicado anteriormente para ambas etiquetas: steer_rate y steer, respectivamente.

Finalmente, se han entrenado modelos con PilotNet y MobileNet.

-PilotNet: para el dataset con etiquetas de steer_rate no ha sido para nada exitoso, pues se desvía con rapidez y pasa a valores extremos. Por otra parte, con valores de steer en los labels sí muestra una buena conducción con giros coherentes y corrección en los giros. Todo esto teniendo en cuenta que se ha probado en varias simulaciones y distintos escenarios con un valor de throttle constante y con el manejo de los actuadores de throttle y brake.

-MobileNet: no ha dado tiempo a probar un modelo entrenado, por errores en la entrada del modelo para su predicción y falta de tiempo. Es decir, errores en para conectar el modelo a Brain.

Semanas anteriores.

Este post es un resumen de lo realizado estas semanas, así que vamos a repasar lo que teníamos hasta ahora.

1. Hemos creado un cerebro (brain.py), para visualizar mediante una cámara frontal y un sensor LiDAR, y teleoperar un vehículo mediante teclado en el simulador Carla. Realizado a partir de trabajo previo hecho por compañeros.

2. Hemos creado (esta última vez) un dataset para registrar por una parte, los frames de la cámara frontal del vehículo (simulado en Carla), y por otra, los valores de steer_rate obtenidos tras pulsar A o D (con los que se calcula steer, es decir, una variable intermedia que mide la velocidad de giro del volante).

3. Tras la creación del dataset, de 17k muestras (aprox.), hemos balanceado el mismo para igualar el número de muestras/etiqueta del conjunto, para que haya un número igual o parecido de muestras para cada valor de steer_rate. No obstante, se ha dejado un número superior de muestras para un steer_rate que ronde el origen, para que siga habiendo superioridad en el caso más común de conducción, “ir recto”. Finalmente, el dataset balanceado es de 40k muestras.

4. Tras el balanceo, se ha construido un modelo de PilotNet (mostrado en las anteriores semanas) para entrenarlo con el dataset balanceado. Tras varios intentos tras el entrenamiento del modelo, que no ha dado resultados de giro coherente del volante, surge la duda de dónde podría estar el error.

Al analizar qué es lo que puede estar fallando en la predicción, hay varias partes de nuestro trabajo que podrían estar causando error:

• El conjunto de datos: tanto el contenido de información como la manera en que obtenemos los frames (espacio de color, tamaño, etc.) como las etiquetas o los valores de steer_rate.
• El balanceo del dataset: el número de muestras por cada ‘label’.
• El modelo de redes neuronales (PilotNet en nuestro caso) en el entrenamiento.
• Brain, al predecir el modelo el valor de steer_rate: la predicción, el cálculo de steer o el input del modelo entrenado.

Se han identificado y corregido errores en las imágenes del dataset, en el balanceo del mismo y en el cálculo de steer (tras obtener la predicción de steer_rate) que, a priori, podían ser los causantes de la mala conducción. Sin embargo, seguimos teniendo un volante (con velocidad constante, throttle = 0.5) que gira de extremo a extremo. Pasa de forma gradual de valores de steer=1 a steer=-1. Analizando varias pruebas, puede que realmente el error de predicción esté en el balanceo del conjunto de datos.

Creación de un nuevo dataset

Se ha creado un dataset nuevo, en varios escenarios del simulador Carla, controlando con los actuadores la aceleración (throttle), el freno (brake) y la velocidad de giro (steer_rate). Este último parámetro, como se intrudujo la semana pasada, se trata de una variable intermedia a partir de la cual se obtiene el actuador steer (ángulo/desplazamiento de giro del volante).

Inicialmente, se ha creado un dataset de 17k muestras, pues por el momento no es posible entrenar un conjunto de datos mayor por las limitaciones del equipo y por la inactividad del servidor, Libélula.

Para el balanceo del dataset, se ha normalizado a área 1 el histograma (cálculo de la FDP) y, posteriormente, se han ido eliminando bins hasta obtener una forma lo más parecida posible a la función gaussiana calculada con la media (media=0.00847) y desviación típica (desv=0.274) del propio conjunto de datos. A continuación, se muestra la FDP del conjunto de muestras antes y después del balanceo, respectivamente:

Entrenamiento y simulación para predecir STEER

Como se ha comentado antes, no se ha podido entrenar un modelo con PilotNet, ni simular posteriormente con el modelo que pueda predecir el valor de steer_rate.

Sí se ha realizado, con las limitaciones que tiene el equipo actual, un entrenamiento con 10k muestras en local. No obstante, se tiene en cuenta que el número de muestras es muy bajo e insuficiente como para poder entrenar un modelo funcional.

Esta semana hemos creado un nuevo controlador para teleoperar un vehículo simulado en Carla con el objetivo de mejorar nuestro dataset. Esta vez, nos centramos en el steering y, para ello, hemos seguido la idea con la que trabajamos la anterior semana: crear una variable intermedia entre teclas y actuadores. Nos vamos a enfocar, para probar cómo aprende nuestro modelo de redes neuronales, en la velocidad de giro (steer_rate).

El target representa la intención de giro del conductor (o del sistema), y se obtiene a partir de la entrada por teclado: pulsar la tecla A genera un target negativo (giro a la izquierda) y la tecla D genera un target positivo (giro a la derecha). Si no hay entrada, el target es cero. Este target no corresponde al ángulo del volante, sino a una velocidad deseada de giro (steer_rate_cmd).

Para evitar cambios bruscos e irreales, el comando de velocidad se somete a un filtro de primer orden:

- steer_rate : es la velocidad real del volante
- steer_rate_cmd : es la velocidad objetivo
- ALPHA_STEER : parámetro de suavizado para hacer más gradual el aumento/disminución de la velocidad. Es la inercia del sistema del volante.

    steer_rate = (1 - ALPHA_STEER) * steer_rate + ALPHA_STEER * steer_rate_cmd

A partir de esta velocidad de giro del volante, obtenemos el ángulo o el desplazamiento de giro del volante (steer_real), que es el que irá directamente al actuador de steer:

    steer_real += steer_rate * dt

A continuación, se muestra el código completo del controlador del vehículo:

# Parámetros del volante
STEER_RATE_MAX = 1     # velocidad máxima de giro
ALPHA_STEER = 0.2        # suavizado

def control(vehicle):
    global steer_real, steer_rate, last_time, throttle

    control = carla.VehicleControl()
    keys = pygame.key.get_pressed()

    now = time.time()
    dt = now - last_time
    last_time = now

    # Velocidad objetivo según el giro izquierda(A)/derecha(D)
    if keys[pygame.K_a]:
        steer_rate_cmd = -STEER_RATE_MAX
    elif keys[pygame.K_d]:
        steer_rate_cmd = STEER_RATE_MAX
    else:
        steer_rate_cmd = 0.0
        steer_real = 0.0

    # Velocidad real de giro del volante
    steer_rate = (1 - ALPHA_STEER) * steer_rate + ALPHA_STEER * steer_rate_cmd


    # Cálculo de Steer
    steer_real += steer_rate * dt

    # Limitar ángulo de giro
    steer_real = max(-1.0, min(1.0, steer_real)) 
    control.steer = steer_real
   
    velocidad_giro.append(steer_rate)
    tiempo.append(now)

    # W throttle 
    if keys[pygame.K_w]:
        throttle = min(throttle + 0.25, 1.0)
    else:
        throttle = max(throttle - 0.25, 0.0)

    control.throttle = throttle

    # S freno
    if keys[pygame.K_s]:
        control.brake = 1.0
    else:
        control.brake = 0.0

    vehicle.apply_control(control)

    print(
        "| steer_rate:", round(steer_rate, 3),
        "| steer:", round(steer_real, 3),
        "| throttle:", round(control.throttle, 2)
    )

    return steer_rate, control.throttle, control.steer, control.brake

Para comprobar que los progresos fueran por “buen camino”, se ha ido representando la evolución de la velocidad del volante en función del tiempo en varias simulaciones. A continuación, se muestra una figura en que se pueden observar varios picos positivos, que indican giros a la derecha (botón D) y un pico negativo, que es un giro a la izquierda (botón A):

Se ha relizado una captura de unos pocos minutos de una simulación mientras se teleopera el coche con este nuevo controlador. A continuación, el enlace del vídeo: https://youtu.be/XJHhS1smjVQ

Conclusiones

Esta semana hemos creado un nuevo controlador para obtener un parámetro intermedio (entre botón y actuador), la velocidad de giro del volante, con el que vamos a generar un nuevo dataset como único parámetro.

La próxima semana, el objetivo será el de crear un dataset con dicho parámetro como label y estudiar cómo mejora el entrenamiento y aprendizaje de nuestro modelo de redes neuronales.