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 :D) 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 :D.

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"

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.

Escribe un comentario sobre "Namespaces XML en AS3"

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.

Escribe un comentario sobre "Precisión de playheadTime"