Week 90 - Recorder/Replayer, muestreo temporal y revisión de augmentations en PilotNet
Durante esta etapa se implementó una nueva pipeline de generación de datasets basada en dos herramientas:
- Recorder
- Replayer
El objetivo fue separar la captura de conducción humana de la generación del dataset final, permitiendo reutilizar una misma sesión de conducción múltiples veces.
Arquitectura de adquisición de datos
El flujo general es:
Driver → Recorder → session.log → Replayer → Dataset
Recorder
El recorder registra la sesión completa de conducción manual en CARLA, almacenando:
- timestamp\
- controles del conductor (steer, throttle, brake)\
- estado del vehículo
El resultado es un archivo session.log que funciona como una caja
negra de la sesión de conducción.
Replayer
El replayer reconstruye la sesión y genera el dataset final aplicando un intervalo de muestreo.
Ejemplo:
python3 replayer_sync.py –log runs/session.log –interval 0.5 –out dataset/dataset_new
El parámetro clave es:
interval = 0.5 s
lo que equivale a 2 muestras por segundo.
Muestreo temporal
Con un muestreo de 0.5 s se obtienen aproximadamente:
Tiempo Muestras ———- ———- 1 minuto 120 1 hora 7200 7 horas ~50000 14 horas ~100000
Esto implica que para construir datasets grandes se requieren sesiones largas de conducción.
En la práctica, obtener un dataset de tamaño comparable al utilizado previamente (~50k muestras) requiere aproximadamente 7–10 horas de grabación continua.
Estrategia para ampliar el dataset
Para acelerar la construcción del dataset se aplicó una estrategia de reprocesamiento del mismo recorder con distintos intervalos:
interval = 0.4
interval = 0.5
interval = 0.6
El objetivo era generar datasets ligeramente diferentes a partir de la misma sesión de conducción y aumentar el número total de muestras disponibles para entrenar el modelo PilotNet.
Resultados iniciales
El modelo se reentrenó utilizando el dataset generado con el pipeline recorder–replayer, pero los resultados no fueron satisfactorios.
Durante la conducción en CARLA el modelo mostró un comportamiento errático:
- zigzagueo constante dentro del carril\
- inestabilidad lateral\
- colisiones frecuentes
En comparación con el modelo entrenado con el dataset Burbuja original, el nuevo modelo resultó claramente menos estable.
Revisión de augmentations
Inicialmente el pipeline de entrenamiento incluía varias transformaciones geométricas:
- Affine
- Perspective
- ElasticTransform
además de efectos suaves como:
- GaussianBlur
- MotionBlur
- CoarseDropout
El objetivo era aumentar la diversidad del dataset.
Sin embargo, se observó que algunas transformaciones geométricas pueden entrar en conflicto con las estrategias de robustez utilizadas posteriormente, especialmente Noise Injection y DAgger.
Las transformaciones geométricas modifican la posición aparente de la
carretera respecto al vehículo sin modificar la etiqueta de control
(steer), generando inconsistencias entre imagen y acción.
En la práctica esto equivale a introducir perturbaciones artificiales adicionales sobre datos que ya incluyen perturbaciones reales durante la recolección.
Como consecuencia, el modelo puede aprender asociaciones incorrectas, por ejemplo:
carretera desplazada + steer ≈ 0
lo que reduce su capacidad de recuperación lateral durante la conducción.
Ajuste del pipeline de augmentations
Para evitar estas inconsistencias se decidió simplificar las augmentations y limitarse a transformaciones no geométricas, como:
- GaussianBlur
- MotionBlur
- CoarseDropout
Estas transformaciones enriquecen el dataset sin alterar la geometría del carril.
De esta manera, las perturbaciones que modifican la posición del vehículo quedan exclusivamente a cargo de:
- Noise Injection
- DAgger
manteniendo mayor coherencia entre las imágenes y las etiquetas de control.
Próximos pasos
Dado que el dataset generado mediante reprocesamiento con distintos intervalos produjo un modelo inestable, el siguiente paso es:
- ampliar la duración del recorder para obtener más datos reales\
- generar un dataset más grande usando interval = 0.5 s\
- evaluar también intervalos más densos (0.1–0.2 s)
El objetivo es determinar si el comportamiento errático proviene de:
- la densidad temporal del dataset\
- la reutilización de trayectorias\
- o la interacción entre augmentations y políticas de control aprendidas.
Resumen de algunas pruebas realizadas
| Métrica | Caso 6 | Caso 11 | Promedio (6-11) | Caso Canónico 1 | Mejor |
|---|---|---|---|---|---|
| Average speed (km/h) | 57.552 | 57.479 | 57.515 | 57.108 | Caso 6 |
| Max speed (km/h) | 72.714 | 72.334 | 72.524 | 72.260 | Caso 6 |
| Completed distance (m) | 757.377 | 756.489 | 756.933 | 756.651 | Caso 6 |
| Effective completed distance (m) | 386.083 | 613.833 | 499.958 | 648.583 | Canónico |
| Dev mean (m) | 0.822 | 0.460 | 0.641 | 0.420 | Canónico |
| Lane invasions (eventos) | 2.333 | 3.000 | 2.667 | 2.833 | Caso 6 |
| Collisions (eventos) | 0 | 0 | 0 | 0 | Empate |
| Suddenness throttle (1/s) | 0.799 | 0.782 | 0.790 | 0.807 | Caso 11 |
| Suddenness steer (1/s) | 0.233 | 0.227 | 0.230 | 0.234 | Caso 11 |