Mi primer RLV

Para cocinar un RLV de Tacx se necesita como materia prima los siguientes ingredientes:

• Un ví­deo de un recorrido en carretera o camino, grabado a una velocidad que no supere en mas de 20Km/h la velocidad que llevaría un ciclista normal en ese tramo
• Una grabación simultanea del track GPS del recorrido.

Como los GPS tienden a perder señal de vez en cuando y se vuelven un poco erráticos, siempre hay que hacer una labor de limpieza antes de poder pasar a usar el track obtenido.
Se trata de ajustar el archivo GPX obtenido del GPS eliminando puntos parados y sobrantes al inicio y final y puntos aberrantes a lo largo del recorrido. Usando CompeGPS sobre un mapa de google puedes darte cuenta cuando el track se ha desviado del recorrido e intentar retocar esos puntos para que cuadren lo mas posible.
Un indicador muy sencillo es pedirle al Compe la lista de puntos poniendo una columna con la velocidad entre ellos. Como los puertos los subo a una velocidad baja, cuando hay perdida de señal suele haber variaciones imposibles de velocidad, como 120 o 200 Km/h. Esos puntos hay que corregirlos ubicandolos de tal modo que la velocidad entre ellos sea la que tiene que ser, o cercana.
También se toman medidas erróneas de altitud y estas son mas difíciles de corregir, ya que los errores suelen acumularse y luego corregirse de golpe, con lo que aparecen escalones de varias decenas de metros en el perfil que serian sencillas de suavizar si no fuera porque lo mas probable es que luego la pendiente obtenida no coincida con lo que estamos viendo en el vídeo.

Cuando el track está ya limpio paso a ejecutar la aplicación de conversión que he creado, que convierte el GPX en un fichero RLV que básicamente contiene las velocidades a las que ha sido grabado cada tramo del video y un PGMF que contiene las pendientes para cada tramo del recorrido. Ambos tramos, el de la velocidad y el de la pendiente, no tienen por qué ser coincidentes.

Aún con estas correcciones, la mayoría de las veces no se consiguen unas pendientes coincidentes con la carretera que estamos viendo en el vídeo. Si suavizas mucho poniendo tramos largos con la misma pendiente, habrá cuestas arriba y abajo que no se reflejen en el rodillo. Si por el contrario haces tramos demasiado cortos, en algunos momentos las pendientes serán ridículamente altas para distancias muy cortas y variarán mucho, por lo que no se consigue un recorrido fluido.

Todo esto es especialmente cierto si, como me ocurrió en las primeras grabaciones, has configurado mal el GPS y has grabado muy pocos puntos. Si el GPS captura un punto del track cada 10 segundos, por ejemplo, a 40 o 50 por hora recorres mas de 100 metros en ese tiempo (50km/h = 11.1m/s) y ahí puedes haberte perdido muchos altibajos del camino. Lo ideal es configurar el GPS para grabar un punto por segundo.

He intentado arreglar el desaguisado resampleando el track con un programa que he descubierto que te permite hacer esto y muchas otras cosas (cosas muy curiosas como redes de caminos a partir de tracks y varias opciones muy interesantes para ciclismo) con los mapas y tracks. El TopoFusion tiene una opción de interpolar mediante splines un track que te permite insertar el número de puntos que quieras entre los puntos de tu track, trazando curvas donde antes habí­a rectas y siguiendo así­ de manera mas natural lo que podrí­a ser el movimiento real que ha habido entre dos puntos capturados por el GPS.
Aquí se puede ver un ejemplo de track resampleado con splines.
A pesar de que TopoFusion también interpola y splinea las alturas, decidí­ volver a recalcular automáticamente la altura de los puntos. Esto lo hace el CompeGPS mediante mapas de relieve, pero el TopoFusion también lo hace usando además diferentes métodos (Climbing Analisys) para que elijas el que mas se ajuste a la realidad. Las alturas interpoladas son inventadas y las del mapa de relieve, aunque no tienen mucha resolución, al menos son reales.

El problema es que muchas veces una carretera no se corresponde con la altura media de la zona donde se encuentra, y esto es especialmente cierto para pasos elevados, puentes, túneles, o curvas en herradura, que son bastante habituales, por lo que al final, el resultado del cálculo automático de alturas sigue siendo desastroso e irreal y las pendientes no corresponden con la realidad mas que en unos pocos tramos.

Por eso he tenido que construirme un programita en AS3, usando Air para poder guardar archivos, que sobreimpresiona el perfil de la etapa sobre el vídeo de la misma y permite ir seleccionando tramos para corregir o establecer su pendiente de forma manual, consiguiendo de este modo un resultado mucho mas natural y unas sensaciones mas realistas. A cambio, la programación para sincronizar el vídeo, que funciona por tiempo, con el perfil, que lo hace por distancia, ha sido bastante compleja, pero aquí tenéis un ejemplo de como luce la aplicación. Como es para uso interno, no tiene adornos, que nadie me tache de cutre!!

Le he ido añadiendo lo que necesitaba. Todos los datos sobre la posición actual, distancia, tiempo, pendiente y altitud así como botones para seleccionar tramos (zona en verde), cambiarles la pendiente, o flechas para subir o bajar el perfil y para guardar archivos con el resultado, tanto en un xml de cosecha propia que he llamado “prf” y que es el archivo que lee el programa para comparar el perfil original (en blanco), que se toma de un GPX, con el perfil retocado (en rojo), como en el formato nativo de Tacx pgmf.

Ahora ha producir perfiles como loco para la LEVE!!!

5 comments Diciembre 28th, 2008

Namespaces XML en AS3

Estaba intentando parsear un archivo xml desde ActionScript 3 y me he encontrado con que no funcionaba.
El contenido estaba en el objeto XML pero al intentar acceder a cualquiera de los nodos mediante nombre, AS3 me devolvía un elemento nulo.
Solo lograba hacerlo funcionar si en la cabecera del fichero XML le quitaba la declaración de namespace que se hace mediante el atributo xmlns.
El problema es que el XML lo produce un software de terceros y no tengo control sobre su formato, así que eliminar la declaración del namespace no es posible.

El problema ha sido precisamente el namespace. El atributo xmlns estaba definiendo el nombre del namespace del tipo de archivo XML que estaba leyendo, pero yo no estaba usando dicho namespace para acceder a los elementos del arbol XML, por eso no los encontraba.
El namespace es una clase que se usa prefijando con ella cada nombre de nodo separándolo de este con el operador :: (name qualifier) , por ejemplo

Esto es un auténtico coñazo, sobre todo cuando te enteras de que esa URI que se declara en el XML no tiene por qué apuntar a nada en concreto, simplemente debe ser única con respecto a todos los namespaces declarados por otros tipos de archivos XML. Como es un identificador tan largo se suele asignar el objeto Namespace a una constante y acortamos.

Pero como sigue siendo un rollo prefijar todos los accesos a los nodos, lo mejor es definir que el namespace por defecto apunte a la declaración correspondiente y ya está. Esto se hace con la orden

Y a partir de ese momento todos los accesos a nodos del xml se realizarán como si fuesen prefijados con ese namespace.

Así todo vuelve a funcionar.

2 comments Diciembre 11th, 2008

Precisión de playheadTime

El manejo de vídeo desde Flash es relativamente sencillo. Desde AS3 se utiliza la clase FLVPlayer a la que solo hay que definirle unos pocos parámetros para que enseguida comience a reproducir el vídeo en formato FLV que le especifiquemos.

Esta clase permite entre otras cosas posicionar la cabeza lectora del video en cualquier posición
de tiempo dentro del mismo con una precisión de milisegundos mediante la propiedad playheadTime, que es equivalente al método seek.
He necesitado usar esta propiedad pero me he encontrado una desagradable sorpresa cuando he intentado posicionar la cabeza lectora, por ejemplo, en el segundo 5, el vídeo se iba a la posición 5.75. Siempre.

Después de investigar un rato he llegado a la conclusión de que solo se puede posicionar la cabeza
en frames marcados como keyframes (o I-Frames), por lo que si has encodeado el vídeo con un keyframe cada 12 frames (valor habitual) y el video es a 25fps te encuentras con que solo te puedes posicionar en determinados momentos de tiempo del vídeo, en este caso puedes posicionarte en el segundo 0.48, 0.96, 1.44, 1.92, etc…
El caso es que necesito posicionarme en segundos exactos por lo que no me queda otra solución que encodear el vídeo con una frecuencia diferente, de un keyframe cada 5 o uno cada 25 si no necesito tanta resolución. La primera solución, por supuesto provoca un aumento significativo del tamaño del vídeo, pero en mi caso eso no es ningún problema, solo es algo que hay que tener en cuenta a la hora de preparar los vídeos para la aplicación. La segunda solución empeora la calidad, pero disminuye el tamaño. Como mi caso es para hacer una previsualización, pues tampoco es importante la calidad.

De los encoders de FLV que tengo a mano, el único que me ha dejado elegir el numero de keyframes ha sido el propio Adobe Flash CS3 Video Encoder y despues de esperar un buen rato porque es muy, muy lento, resulta que al principio lo hace bien, pero no es capaz de poner los keyframes EXACTAMENTE cada 25 frames de una manera constante, por lo que a los pocos segundos comienza a desincronizarse con lo que al final me encuentro con el mismo problema. Parece que los keyframes no son una ciencia exacta.

Add comment Diciembre 5th, 2008