No, no es que vaya a ir con un burro cargado con la cámaras de 11 objetivos que usa Google para el street view, aunque molaría, mas bien es una actividad que me he propuesto hacer para motivarme a entrenar un poco más.
Quiero hacer el camino de Santiago desde Madrid (aunque siendo fiel a mi filosofía de ser un cretino diferente, creo que cuando lo haga, lo haré al revés, de Santiago a Madrid), pero eso no va a poder ocurrir hasta que tenga unas vacaciones de las de la gente normal, de esas que hace un año que no tengo, así que entre tanto se me ha ocurrido prepararme para el viaje haciendo el recorrido “virtualmente”.
Tengo el track GPS de la ruta completa hecho por Rafa Esva bajado de wikiloc. Tengo un rodillo Tacx Fortius conectado al PC. Tengo el software TTS 2.0 cortesía de Tacx B.V. que está integrado con google earth plugin… solo me hacen falta ganas y una horita y media diaria.
El autor original de la ruta tardó 10 días a unos 70 km diarios… claro que el tenía todo el día. Yo tardaré mas, unos 18. De momento solo puedo hacer unos 40Km al día, lo que duran un par de capítulos de StarTrek TNG que me veo al mismo tiempo que veo la ruta en google earth para no aburrirme demasiado; a ver si al llegar a la planicie castellana me cunden un poco mas las etapas, que mañana me toca pasar a Segovia y la Fuenfría puede ser mortal con una bici de carretera.

Se que no es lo mismo, se que no es igual, pero me consuelo pensando que yo tengo una ventaja, en cuanto me bajo de la bici no tengo que buscar alojamiento ni restaurante porque ya estoy dentro de el.

1. 2009-12-08 Cerro de los Ángeles – El Goloso: Paseito por el anillo ciclista de Madrid hasta salir por el norte. 42Km
2. 2009-12-09 El Goloso – Matalpino: Ya he llegado a las faldas de la sierra. Atravesar Colmenar viejo ha sido duro. Hoy mas cuestas que ayer, pero menos que mañana. 36Km
3. 2009-12-10 Matalpino – Inmediaciones de La Granja: El puerto de la fuenfría se ha hecho duro pero ha sido mucho peor el pueblo de cercedilla y navacerrada. Los GPS dan valores de altitud muy erráticos cuando entras en poblaciones y eso hace que el rodillo me marque pendientes de entre el 11 y el 20% en algunos puntos. Rompen el ritmo y desesperan. 42Km
4. 2009-12-11 La granja – Pinilla-Ambroz: La provincia de segovia parece que está hecha al reves, es cuesta abajo de sur a norte. Hoy no tenia mucho tiempo y no he podido llegar a Santa María la Real de Nieva. Este finde tengo que “descansar”. El lunes retomo.
5. 2009-12-14 Hoy se ha estropeado el TTS y no he podido hacer etapa
6. 2009-12-16 Pinilla-Ambroz – Alcazarén: To pabajo por la llanura castellana. Una vez recuperado el TTS he conseguido hacer una buena etapa. 53Km.
7. 2009-12-17 Alcazarén – Ciguñuela: Bordeando Valladolid con perfil bastante asequible. 42Km.
8. 2009-12-28 Ciguñuela – Medina de rioseco Un par de mesetas de las que se baja y a las que se sube. Peñaflor tenia pendientes del 20%, afortunadamente, cortas. 39Km
9. 2009-12-29 Medina de rioseco – Fontihoyuelo Bonito paseo por la vega del rioseco. 40Km
10. 2009-12-30 Fontihoyuelo – Bercianos del real camino Pasando de Valladolíd a la provincia de León, temo que echaré de menos esta llanura castellana cuando pase Astorga. 42Km.

Escribe un comentario sobre "Camino de Santiago Virtual"

Tras unos meses metido en esto de grabar vídeo, editarlo, codificarlo y distribuirlo me he dado cuenta de que lo que yo intuía como un mundo enorme que desconocía, es efectivamente un mundo enorme que desconozco.
Voy a tratar de plasmar en poco espacio las nociones básicas que he aprendido en mi breve incursión, para dejar constancia de lo que me ha parecido importante y de no. Al lío.

Un vídeo no es mas que una sucesión de imágenes fijas que reproducidas a una velocidad determinada dan impresión de movimiento. Al igual que pasa con las imágenes, los vídeos se comprimen para optimizar su tamaño. Las imágenes se comprimen aprovechando la información repetida en pixels adyacentes. Con los vídeos ocurre lo mismo, solo que ademas de la dimensión de una sola imagen o fotograma (compresión intraframe), también podemos buscar esa información repetida en los fotogramas siguientes (compresión interframe).

Veamos los conceptos más comunes: contenedor, codec, bitrate, framerate, GOP o frecuencia de keyframes, bitrate variable, entrelazado

Contenedor: es el formato que se usa para empaquetar la información de vídeo en un archivo. El contenedor es lo que da nombre a la extensión que llevan los archivos de vídeo , así podemos tener AVI, MPG, MOV, FLV, 3GP. El contenedor de por si no nos proporciona información de como está comprimido el vídeo, solo en que parte o partes del archivo está la información.

Codec: (Coder-Decoder) es la herramienta que nos permite comprimir un vídeo y luego descomprimirlo para poder visualizarlo en un reproductor. Existen multitud de codecs con miles de opciones para optimizar la compresión. Si tienes un reproductor que puede leer un contenedor en concreto, pero no tienes instalado en tu sistema el codec con el que se ha comprimido el vídeo que está dentro, no podrás verlo. Los pack de codecs como el ffdshow son para eso. Algunos reproductores llevan incorporados algunos codecs, unos mas, otros menos. Por ejemplo el Flash player 10 soporta Sorenson Spark, On2 y H.264 el solito, mientras que el VLC soporta muchísimos mas y el windows media, muy pocos.
Como en los vídeos también hay pistas de audio, se utilizan otros codecs para comprimirlo, como puede ser el MP3, AC3 y otros.

Bitrate: se mide en bits por segundo, es decir, la cantidad de bits que le damos al codec para que almacene todos los fotogramas de vídeo que haya en un segundo. Cuanto mayor bitrate, mayor calidad, y por supuesto mayor tamaño. El bitrate es el único ajuste de codificación que nos permite variar el tamaño final del archivo de vídeo . El resto de ajustes de vídeo solo sirven para hacer que quepa mas o menos “información visual” en esos bits, obteniendo mayor o menor calidad, pero el tamaño será siempre el resultante de multiplicar el bitrate por la duración del vídeo. Por ejemplo, un vídeo codificado a 400 kbits por segundo, con una pista de audio codificada a 96 kbits por segundo, ocupará:

496 kbps / 8 bits/byte = 62 Kbytes por segundo

Si el vídeo dura 5 minutos, 62 kbps * 5 min * 60 segundos por minuto = 18600 kbytes, es decir, unos 18 Megabytes. Siempre.

Framerate: es la frecuencia de fotogramas, es decir, la cantidad de fotogramas que se reproducen por segundo. El ojo humano, a partir de 10 fps, ya percibe movimiento fluido. El estándar son 24 para cine, 25 para televisión PAL/SECAM (Europa) y 29.97 para la televisión NTSC (EEUU). No es habitual grabar a mas de 30 fps, salvo en cámaras de alta velocidad. Es recomendable respetar los fps en cualquier recodificación, aunque claramente, si bajamos el framerate dejamos mas bitrate para menos frames, con lo que la calidad de la imagen aumenta, pero si el vídeo tiene escenas de mucho movimiento, vamos a notar los saltos.

Keyframes y GOP: Como hemos dicho, los frames de vídeo se comprimen porque hay información en los frames anteriores o posteriores que se repite en relación a un frame anterior. Esto supone que es necesario que haya frames de referencia con respecto a los que se calcule la compresión. Estos frames se llaman “clave”, keyframes o I-Frames y por ser los de referencia, no pueden recibir en si mismos una compresión interframe, tan solo intraframe (de ahí que se les denomine I-Frames). Por ello estos frames ocupan más espacio que el resto, de modo que si tenemos muchos keyframes y poco bitrate, la calidad será pésima, ya que la mayor parte del bitrate irá a parar a los keyframes.
La solución sería poner pocos keyframes, o mejor aun, solo el primero, pero esto tiene otras contrapartidas. Por ejemplo, algunos reproductores de vídeo, como el de Flash, solo permiten posicionarse en keyframes, es decir, si queremos acceder a una parte concreta del vídeo, y esa parte no tiene un keyframe, el reproductor nos envía al keyframe mas cercano, que en caso anterior sería el primero, con lo que no podremos posicionarnos en ningún otro sitio mas que al principio.
GOP (Group of pictures) es el mismo concepto e indica cuantos frames acompañan a un keyframe. Un GOP de 12, por ejemplo, significa que cada 12 frames hay un keyframe, si el framerate es 24, eso es dos keyframes por segundo de vídeo.
Aparte de los Iframes, existen otros dos tipos de frames, los P-frames (Predictive frames) y los los B-frames (Bidirectional predictible frames). Ambos van con compresión interframe y dependen del Iframe anterior y en el caso de los B-frames, de los frames anteriores y posteriores.

Bitrate variable: La compresión que se consigue en una imagen depende mucho de lo que esta contenga, igualmente en el vídeo, la compresión depende de lo mucho o poco que cambien unos frames respecto a otros. No es lo mismo un vídeo grabado desde el casco de una moto, en el que todo se mueve a gran velocidad y pocas cosas se repiten, a un video de un telediario (lo que se denomina “talking head”) en el que solo una pequeña porción de la imagen cambia en cada fotograma. Por eso, para vídeos cuyo contenido es heterogeneo se creó el VBR (variable bitrate). El bitrate se va adaptando a los contenidos de la imagen de manera dinámica, con lo que se usan menos bits cuando no hace falta mucho bitrate y mas cuando la imagen cambia mucho entre fotogramas. El tamaño de los vídeos con VBR ya no se puede predecir de antemano como en los CBR (constant bitrate), claro, pero se consiguen mejores relaciones tamaño/calidad.
Para saber el bitrate necesario para una zona concreta del vídeo se necesita procesar antes cada parte para luego aplicar la compresión en una “segunda pasada”. El concepto de codificación de 1 pasada y de 2 pasadas entra en juego aquí. Para codificar en VBR siempre hacen falta 2 pasadas, lo cual ralentiza mucho la misma.

Otro día más

Escribe un comentario sobre "Video digital para gente con prisa"

Antes de nada quiero avisar de que este post es uno de mis “EPIC FAILS“, una de esas veces que me pongo a hacer un invento y que luego el invento no sirve ni para dar de comer a los cerdos. Avisados quedaís, no sea que os leáis todo el tocho y luego os desilusione el resultado.

Una de las cosas que mas me gusta de iniciar proyectos nuevos es el reto de encontrar los comercios que venden cosas que la gente normal no va a comprar habitualmente. A veces me frustro porque no encuentro lo que necesito, pero otras veces, como ahora, siento una extraña alegría al internarme en una tienda en la que única y exclusivamente se venden… ¡MUELLES!.

Para fabricar un brazo isoelástico como el que llevan las steady cams o mas cercano al ciudadano de a pie, los flexos de sobremesa, se necesitan construir dos paralelogramos articulados en 4 puntos cada uno y cuya cuadratura se mantenga mediante un muelle de dimensiones y características específicas al tamaño del brazo y al peso que va a tener que soportar el mismo. Un brazo isoelástico permite desacoplar los movimientos que se producen en uno de sus extremos, del objeto que se encuentre en el otro, de tal modo que el objeto permanece siempre en la misma posición pase lo que pase (dentro de unos parámetros, claro está) en el otro extremo. Es la solución ideal para estabilizar una cámara de vídeo y aislarla de los movimientos que inevitablemente tiene que hacer quien la porta, ya sea persona, animal o vehículo.
Me he basado en el diseño que se puede encontrar en instructables. Posteriormente a diseñar mi brazo encontré esta página de un home made steady cam que me ha sido de gran ayuda para las mejoras.

Estas pasadas vacaciones de semana santa, en lugar de irme a llorar desconsoladamente y a gritar “guapa” a una figura de madera, que me da mucha vergüenza hacer el ridículo, me he puesto este proyecto como deberes.
Con estos suministros:

• Tubo cuadrado de aluminio de 1000×10 mm
• 8 bisagras alargadas de 60×30mm
• Tornillos de 20×4mm de varias cabezas, tuercas y arandelas a juego en número de alrededor de 22
• Retales de perfil en U de aluminio
• Dos muelles de 14cm y especificaciones erróneas
• Ventosa de cristalero, doble, de plástico

Me he fabricado mi primer brazo isoelástico, que por supuesto no ha funcionado a la primera (ni a la segunda tampoco ) debido a que los muelles aunque bien dimensionados en cuanto a longitud, no soportan el peso de la estructura y la cámara y el brazo se queda siempre abajo del todo, vencido por el peso.

No problemo, el tipo de la tienda de muelles que os comentaba al principio me dijo que si no me valían podía ir a cambiarlos. La verdad es que me esforcé mucho para ir con la lección aprendida a la tienda. Gracias a la página de Vanel, donde disponen de un buscador de muelles que quita el aliento, sabia los parámetros del muelle que hay que proporcionarle al tendero para que te atienda bien y no se te quede mirando pensando que eres un pardillo.

• Tipo de muelle, de compresión, extensión o torsión
• Material: acero inox o de cable de piano
• Longitud en reposo o libre
• Longitud en máxima enlongación
• Fuerza o peso a soportar en máxima enlongación
• Diámetro del hilo
• Diámetro del muelle
• Tipo de gancho (Inglés o Alemán) y posicion (0º o 90º)

En mi caso particular los datos eran:

• Muelle de extensión
• Cualquier tipo de material, finalmente de cable de piano
• Longitud 160mm, finalmente me dieron uno de 140mm
• Longitud máxima 280mm
• Para un peso de 500g
• Hilo de 0.9
• 10mm de diámetro del muelle
• Gancho alemán con 0 grados

Los datos del muelle los saqué con la calculadora de muelles para brazos isoelásticos que tienen en la página de home built stabilizers. Si la vais a usar tened en cuenta que las unidades son imperiales, es decir, pesos en libras y longitudes en pulgadas, para kilos y centímetros mejor convertid vuestros valores antes de usarlos en la calculadora y volved a convertir los resultados.
Todos mis datos parecían perfectos ya que los recalculé al llegar a casa dado que los muelles eran un poco mas cortos de lo que yo había planeado en principio y debido a ello los brazos tuvieron que ser un poco mas cortos también. Pero cuando una vez montado el sistema lo sujeté en vilo con una mano, se hizo evidente que esos muelles no valían.
El fallo estuvo en la estimación de peso por dos motivos. Primero porque pedí­ muelles que soportasen 500g. y el sistema completo, brazo + cámara resulta que pesa unos 850g. Pero sobre todo porque el peso o fuerza que se da como dato en las características del muelle, es el que hace que se estire hasta su punto de máxima enlongación, y en mi caso el peso tiene que soportarlo en la MITAD de su enlongación para que el brazo permanezca en el punto medio, estirado y para que haga su función.
Así­ que me ha tocado volver a la tienda con el invento en la mano para que me den unos muelles que hagan que el invento funcione. Comprar los muelles por internet habría sido mas barato, pero no habría podido cambiarlos cuando, como era de prever, metiese la pata en su cálculo.

Después de esto tuve que buscar la forma de acoplar el brazo al coche, y la fórmula que encontré fueron las ventosas de cristalero que se usan para transportar vidrio. Se adhieren con una fuerza tremenda a cualquier superficie mas o menos lisa y no porosa, como los vidrios del coche o la chapa de la carrocería. Hay modelos realmente baratos en algunas ferreterías (no es fácil dar con una que tenga), desde unos 10 Euros. Pasaron semanas de estrujarme el cerebro para ver como enganchar la ventosa al brazo, hasta que me di cuenta de lo fácil que era con el trozo de cuadradillo de aluminio que me sobró.

El caso es que una vez todo unido y montado, lo he sacado a dar una vuelta para probarlo. Era un día ventoso y nada mas arrancar con el coche ya me he dado cuenta de que el invento es un fiasco terrible. Debido a la longitud del brazo y a la holgura que presentan las bisagras, que son de las baratas, el brazo bandea de un lado a otro no solo con el viento, sino ante cualquier bache del camino.
Además al ponerle el gran angular, la cámara ha subido de peso de repente (había despreciado el peso del objetivo) y los muelles no han respondido como deberían, quedándose en hiperextensión el que mas peso soportaba, con lo que el efecto amortiguador se ha traducido en un efecto rebote insoportable, vamos, un completo desastre.
Como dirían en el hormiguero, ¡fracaso absoluto!

Podría hacer algún ajuste cambiando el enganche de los muelles para poder calibrarlos mediante un tensor que se coloca entre el chasis del brazo y un extremo del muelle, pero francamente, me parece que no merece la pena. He comprado un soporte con ventosa única para cámaras de mano que aunque no tienen las características del brazo isoelástico, al menos me permite llevar la cámara fuera del habitáculo sin que se mueva mucho mas de lo que se mueve el propio coche. De momento me sirve.

Escribe un comentario sobre "Brazo isoelástico"

Para editar los vídeos RLV he usado el Sony Vegas Movie Studio, programa muy completo y versátil que permite hacer infinidad de cosas con ellos.
Los dos vídeos que he hecho para el Tacx Fortius, La Cruz Verde y La Morcuera, disponibles para su descarga en la web de la Liga de Entrenamiento Virtual en Español (LEVE), funcionan a la perfección en el software Fortius, pero pronto me hicieron notar algunos de mis colegas holandeses que no funcionaban tan bien en el nuevo software que ha sacado Tacx, el TTS (Tacx Training Software).
El problema es que ya desde el momento de la previsualización del video, mientras todos los demás RLV de Tacx y de otros autores particulares presentan el primer fotograma, mis vídeos se ponen en marcha inexplicablemente y a una velocidad endemoniada.
El efecto mola si no fuera porque al iniciar el entrenamiento el vídeo va a su bola, y avanza a toda mecha sin necesidad de que demos pedales en el rodillo.

Intentando aislar el problema descarté primero que fuese el archivo rlv, y al final me di cuenta de que era problema del propio vídeo AVI. He intentado cambiar datos de la cabecera del mismo con un editor hexa, cosas como el dwQuality que estaba a 0xFFFF y solo debe tener valores entre 0 y 10000, o el xdwSampleSize que debería ser cero y no lo era, pero nada daba resultado.

La última prueba ha sido recodificar de nuevo el vídeo de AVI a AVI usando el ffmpeg, la herramienta por excelencia para el transcoding, y mire usted por donde, se ha arreglado.

Parece que tendré que darles un lustre final a todos los videos que haga a partir de ahora pasandolos por el ffmpeg.

Escribe un comentario sobre "Sony Vegas y la mala codificación"

Acabo de jubilar mi vieja tabla de snow, con unas heridas en la suela incompatibles con la práctica de este deporte.
Un amigo acaba de jubilar un par de tablas de esquí pasadas de moda sin carving ni nada y ha decidido donarlas a la ciencia.
Acabo de jubilar un somier de madera de pino sin tratar de IKEA, con alguna lama rota y una molesta tendencia a chirriar al mas mínimo movimiento nocturno.

¡TACHAN!

Si me vais a preguntar ¿y donde piensas poner ese monstruo? podéis ahorrároslo, no lo se, ¡solo quería reciclar!

Escribe un comentario sobre "Snow bench"

Uno de los pocos inconvenientes que tiene la cámara de vídeo que me regalaron en mi último cumpleaños, la Canon FS100, es que el objetivo no dispone de rosca para colocarle filtros o lentes diferentes, con lo que no se puede poner un simple filtro UV, que habitualmente se usa como protector de la óptica de la cámara dado su escaso precio.
Tampoco se le puede colocar un ojo de pez (lente gran angular) que en ocasiones vendría muy bien para determinados usos, entre los que se encuentra el que yo le doy, las grabaciones de carreteras para RLV.

La solución pasaría por encontrar una lente que se pueda colocar sin rosca, a presión, magnética o con pestañas (la Raynox q 707 p.ej), pero tampoco es viable ya que la estratégica colocación del micrófono incorporado le hace ubicarse justo a ras del objetivo, impidiendo la superposición de ningún adaptador de tubo.
Lo único que parece que queda es lo que ha hecho AlBaraa con la suya, que es pegarle con algún pegamento extra fuerte al cianocrilato (superglue) o quizás de epoxi (nural) un adaptador step-down de 37 a 52mm para aprovechar sus lentes y filtros de 37.
También tenemos este vídeo de otro personaje que ha hecho lo propio para adaptarle un ojo de pez.

En mi caso, tras buscar anillos reductores infructuosamente en tiendas de fotografía de mi pequeña ciudad llamada Madrid, capital de un país en el que solo encuentras mierdas de consumo masivo, he tenido que recurrir a Ebay y a los USA para pedir mi solución completa, en forma de un maravilloso pack que contiene un ojo de pez de 0.5x, un objetivo telefoto x2, 3 filtros (UV, polarizador y antifluorescente) y atención: 6 adaptadores step-up de diversos diámetros de rosca y un step-down de 43-37 que coincide exactamente con las medidas de diámetro de la cámara, por lo que resulta muy sencillo de pegar en el extremo del objetivo sin sobresalir ni llamar la atención. Todo ello por el precio que tendría solo el ojo de pez en una tienda de fotografía que tuviese ojos de pez, lo cual no es fácil de encontrar.

Así que eso he hecho, he pegado con cianocrilato el anillo step-down de 43-37mm (43M37F) al objetivo de la cámara tal como se puede ver en este vídeo.

Por cierto, mucho cuidado con el cianocrilato, no ya por que os podáis pegar los dedos, que es lo típico, sino porque hay que dejarlo secar bien en un lugar ventilado. Los vapores que produce se pegan a las grasas por lo que si tenéis alguna huella cerca del sitio donde ponéis el pegamento esta quedará “fijada”. Es un truco de los CSI que a los profanos nos puede jugar una mala pasada. También forma una película o velo sólido sobre los cristales, así que si ponéis una lente roscada al anillo mientras se seca el pegamento la lente quedará velada hasta que la limpiéis con un buen limpiador de lentes. Que mala es la experiencia.

Escribe un comentario sobre "Lentes y ojo de pez en la FS100"

Como sabéis los mas asiduos, he pasado los 3 últimos meses intentando crear un vídeo RLV para el rodillo Fortius. En mi ultimo post, afinando aún mas los RLV, parecía que por fin había conseguido mi propósito, pero no. Debido a un incompleto entendimiento de uno de los conceptos fundamentales de los RLV, mis vídeos nunca estaban bien sincronizados con el perfil de la etapa.

El concepto en cuestión es el de “distance per frame“. Los archivos RLV tienen unos registros que se llaman así. Se componen de un número de frame y un valor que indica la distancia que es necesario recorrer con el rodillo a esa altura del vídeo para que se pase al siguiente frame.
Este dato se calcula a partir de la velocidad a la que nos movíamos mientras se grabó el vídeo y su tasa de frames por segundo, por ejemplo, si he grabado un tramo a 50Km/h, que son 13,8m/s y el video fue grabado a 25fps, en ese tramo el valor de distancia por frame será de 13,8 / 25 = 0,555 metros por frame.
Me he pasado semanas haciendo números, porque yo entendía que desde un registro hasta el siguiente el valor de distancia por frame se mantenía constante… y ademas no se me ocurría ninguna otra posibilidad.
Pregunté por el tema a Phil, el que hace los videos oficiales, y no obtuve ninguna respuesta (no les hace gracia que la gente haga sus propios vídeos). Pregunté a B. Maesen (Wesp_im), el que hace las camisetas oficiales del VR y aunque el no sabía nada, me puso en contacto con Hannes Schellnast, un Austriaco que ha hecho un par de vídeos a mano, usando una variante del sistema de hojas de cálculo de Carsten Jost.
El ha sido quien, después de investigar un poco se ha dado cuenta de una cosa muy importante. Desde un registro de distance per frame a otro, el valor de distancia NO se mantiene constante, sino que se interpola desde el valor de origen hasta el de fin. Una vez entendido esto, ya he podido corregir mi conversor para que saque unos valores de distance per frame adecuados.

Frame number Distance per Frame 0 0,5 1 0,5 8 1 9 1

Esto es lo que yo pensaba que ocurría: Y esto lo que ocurría en realidad:

Como se ve, el valor de distancia por frame varía de forma lineal en el intervalo que no está definida, es decir, entre el frame 2 y el 7. Esto explica todos los comportamientos anómalos que obtenía en mis pruebas ya que en cuanto creaba un registro nuevo, mis valores estimados de velocidad no coincidían con los que al final calculaba el software de Fortius y todo se desfasaba.

En palabras del propio Hannes: “Teóricamente la distancia cubierta se calcularía vía una integral desde el frame 1 hasta el 9. En nuestro caso hemos interpolado valores discretos para los puntos de distancia por frame. Esto significa que no usaremos integración gracias a que los saltos entre frames son discretos y no infinitesimales. Supongo que el algoritmo que usa Tacx calcula la nueva distancia cubierta para cada paso de frame al siguiente con el valor de distancia por frame interpolado. Hay que tener en cuenta que la dependencia entre frames y distancia cubierta no será lineal para el rango de frames entre el 1 y el 9. Debido al uso de valores de frame discretos se produce un pequeño error de cuantización respecto al valor que saldría con un cálculo teórico basado en integrales. Este error es tan pequeño que se puede despreciar.”

Ahora ya comprendido el funcionamiento he cambiado la generación de los .rlv y parece que todo coincide, casi a la perfección. A Hannes le debo una y probablemente le envie un regalito, ¿alguna sugerencia de algo que enviarle que no se rompa de aqui a Austria?

Escribe un comentario sobre "Distance per frame"

Tengo la impresión últimamente de que los dispositivos electrónicos de consumo cada vez los hacen peor. Yo pensaba que precisamente la electrónica, al carecer de partes móviles que pudieran sufrir desgaste, tendía a durar mas que la mecánica, pero estas navidades pasadas, coincidiendo con el momento en el que mas necesitaba el GPS por estar de viaje, resulta que el Parrot CK3300 con antena GPS que venía instalado en mi coche ha dejado de funcionar.
El primer síntoma fueron las palabras “no signal” en la pantalla del manos libres. Luego ya no se encendía y por supuesto no había ni rastro de la señal bluetooth de la antena GPS.
Ya de vuelta a casa, como no podía ser de otro modo, busqué, encontré y saqué la centralita del aparato, una caja azul escondida en la parte mas recóndita de las inferioridades del salpicadero.
En los foros del SAT de parrot la solución que dan a quien le pasa esto es que desconecten la alimentación de la unidad de control durante un tiempo, para resetear el micro del parrot, y que si después de eso no vuelve a funcionar… pues simplemente puedes darte por jodido. O se arregla con una actualización de firmware o te toca cambio de unidad de control, 75 E mas IVA (y si encima no eres manitas, mas la instalación).

Como cabía esperar he desconectado la alimentación, abierto la caja, desmontado el aparato, rociado con limpia contactos y esperado una semana a tener un rato libre para volver a montarlo. Pero los resultados no han variado. NO SIGNAL.
Dentro del circuito, ni un mal jumper o microinterruptor para hacer reset. Solo SMDs por todos lados y micros con miles de patillas. Así no hay quien juegue a reparar cacharros.

Si es que ya no hacen las cosas como antes.

En fin, que no me ha quedado mas remedio que llevarlo a “reparar” al servicio técnico, donde por el módico precio de 15 euros lo único que han hecho es una actualización del firmware que se hace con un cable serie especial que cuesta unas 20 libras, siguiendo unas simples instrucciones y usando un software que es gratis y se descarga de aquí. Si la reparación dura al menos un año, bien empleado está porque ademas tiene garantía… me estoy volviendo un blando de mierda… es la falta de tiempo, sin duda .

Escribe un comentario sobre "Parrot CK3300"

Después de hacer pruebas con el programita que me hice y que comenté en el anterior post me he dado cuenta de que hay aún problemas para empatar correctamente las pendientes con las imágenes del vídeo.
Si antes el problema lo presentaba el mapeo entre pendientes y distancias, ahora el problema está entre distancias y velocidades de grabación del vídeo. En efecto, la pésima grabación que hice del track no solo afectó a las alturas mal calculadas, también hacía que las velocidades fuesen distintas a las que se reflejan en el vídeo.
Esto hace que al reproducir el RLV en su entorno propio, el software de Tacx, al cabo de unos kilómetros la posición que reflejaba el vídeo, por ejemplo en la entrada de una población, no correspondía con la distancia recorrida que marcaba el track y por eso las pendientes tampoco se correspondían.

El mejor método que se me ocurrió para arreglar esto de una vez por todas es el de usar un mapa de google sobre el cual se dibuja el recorrido y sobre el que se va actualizando la posición real. En este mapa podría ir marcando puntos a medida que se reproduce el vídeo para empatar momentos de tiempo (frames de video) con posiciones GPS y de esa forma consigo exactamente la velocidad entre los puntos que vaya marcando. Por ejemplo, cuando veo en el vídeo una curva a derechas, busco en el mapa de google si la posición actual que me marca en el mapa corresponde con el inicio de dicha curva y si no es así, lo que hago es colocar un marcador que indica donde debería estar (dentro de la propia linea del track) y el programa recalcula las velocidades para todo el recorrido. De este modo, colocando unos cuantos marcadores, se consigue cuadrar a la perfección el vídeo con el track GPS y la corrección que se haga después sobre el perfil quedará perfectamente sincronizada con el vídeo en el software de Tacx.
Para esto he usado el API de Google Maps para Flash. Tardé aproximadamente 30 minutos en poner el mapa, dibujar el recorrido y centrar el mapa en punto de latitud y longitud correspondiente a medida que se reproducía el vídeo, es muy fácil de usar.
En seguida se hicieron evidentes las diferencias entre la reproducción del vídeo y las posiciones en el mapa.
Hacer la funcionalidad para recalcular los tiempos y las velocidades me llevó alguna que otra semana, pero al final todo salió.

En la captura de pantalla se puede ver en azul los marcadores utilizados a lo largo del recorrido para empatar vídeo y latitud-longitud. Hay tramos en los que la velocidad es mas constante y hay menos marcadores y otros tramos en los que hay que colocar mas.
Los marcadores se colocan haciendo click en el punto del track que queramos y también se pueden eliminar si nos hemos equivocado al colocarlos simplemente clickando encima de su icono.
El resto del mapa funciona igual que cualquier otro mapa de google maps, con la salvedad de que en ocasiones al usar el zoom el programa da un error de seguridad (pero no siempre). Supongo que es un problema por usar AIR en vez de simplemente Flash ya que hace poco que el API de Gmaps soporta AIR.

Soy consciente de que es probable que no esté quedando nada claro lo que hago ni porqué lo hago, pero el explicarlo aquí no solo me permite documentarlo un poco sino también organizar mis ideas y conclusiones respecto a este tema. La verdad es que todo esto me resulta muy difícil de explicar porque el problema es bastante complejo de entender si no te has metido a resolverlo, pero lo importante es que voy a tener una herramienta fiable para producir casi en serie los vídeos RLV que quiera. De hecho con este nuevo añadido voy a poder incluso hacer RLV sin disponer del track GPS ya que me bastaría dibujarlo sobre un mapa, calcularle las alturas, ponerle una velocidad constante y luego ir ajustando visualmente con mi mapa las coincidencias entre fotogramas y posiciones geográficas.

Me imagino que en Tacx tendrán una herramienta similar, porque no me imagino a Phil, el encargado de hacer los RLV comerciales, corrigiendo a mano sobre una hoja de cálculo las cifras de pendientes tal y como hace Carsten Jost en su guía de creación de RLV.
… y si no la tienen, siempre estoy dispuesto a trabajar para alguien que conjugue bicicletas + informática

(Creo que esta última frase solo tendría sentido si postease en Inglés como mi colega futur3, pero me da tanta pereza…)

Escribe un comentario sobre "Afinando más los 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!!!

Escribe un comentario sobre "Mi primer RLV"