=?ISO-8859-1?Q?Re:_Estudiando_firmware_pues_h?= =?ISO-8859-1?Q?ay_un_ligero_error_de_medici=F3n?=



Se ha realizado ya el experimento, se adjunta una hoja de cálculo en
OpenOffice con los datos y las conclusiones (contiene 3 hojas)

Extracto de las conclusiones:

-------------
Comparación realizada conectando la salida de una plataforma de contactos a:
-2 chronopics3
-1 chronopic1
-1 Biopac

Como se ve en la hoja "biopac_3chronopics":
-las tres chronopics ofrecen valores muy similares
-se mantiene una diferencia de -5ms en Tcs y +5ms en Tfs entre biopac
y los chronopics
-la diferencia entre biopac y las chronopics es muy estable
-se constata que las chronopics no captan valores inferiores a 50ms
(tal y como está programado en su firmware)

Como se ve en la hoja "3chronopics":
-las dos chronopics3 ofrecen resultados muy similares
-las chronopics3 difieren ligeramente respecto a la chronopic1:
... los Tcs son de media 0,17 superiores en la chronopic1
... los Tfs son de media 0,23 inferiores en la chronopic1
De 293 tramas han aparecido 2 en las que los datos difieren notablemente,
se cree que es debido a la conexión de los cables (fila 21, fila 33)
estos datos han sido despreciados
Las diferencias entre Chronopics son despreciables

En cualquier caso son diferencias inferiores a 1ms, que corroboran la
precisión de 1000Hz, y convertidas a altura de vuelo son totalmente
despreciables

Se estima que Biopac no capta correctamente los datos o que hay un
error en el firmware de las Chronopics
En biopac están entrando los datos por su entrada digital a una
frecuencia de muestreo de 2000Hz. Quizás habría que usar la analogica
(que es imposible en este momento)
Las diferencias de hardware entre Chronopic3 y Chronopic1 (posibilidad
de problema de condensador) se estima que sea de 0,5ms, en cualquier
caso despreciable.
En el caso de que el firmware tenga un error, al ser tan estable,
sería fácilmente corregible

Se recomienda usar un Osciloscopio y/o un generador de ondas cuadradas
para realizar la medición

Se apunta para un futuro que se pueda disminuir el valor de
tiempo_antirrebotes desde chronojump para tiempos muy pequeños,
aunque con pulsaciones manuales no se han alcanzado valores inferiores a 50ms

Xavier de Blas, Bernat Buscà. 28-enero-2008
-------------

Juan, ¿tienes posibilidad del generador o del osciloscopio?

Saludos


2008/1/29, Xavi de Blas <xaviblas gmail com>:
> Ahora iniciaremos más pruebas, pero estoy dudando del uso del Biopac.
>
> Juan, ¿tienes acceso al generador de ondas cuadradas que usaste la
> otra vez? ¿tienes acceso a un osciloscopio?
>
> El miércoles nos darán el presupuesto de fabricación, sería importante
> saber si hay problema con el condesador antes de tirarlo a fábrica.
>
> Por cierto, gracias por el medidadas.sxc, creo que no lo habías
> enviado anteriormente
>
> Saludos
>
>
> 2008/1/28, Xavi de Blas <xaviblas gmail com>:
> > Hola Juan
> >
> > Acabo de realizar una comparación entre Chronopic3 y Chronopic1 a
> > partir de una plataforma de contactos que disponía de salida de cables
> > duplicada. Las dos Chronopic estaban conectadas a mi maquina
> > /dev/ttyUSB0, /dev/ttyUSB1 y eran gestionadas por chronojump_mini.
> >
> > Como veréis en el archivo adjunto (OpenOffice), existen diferencias
> > entre el TC y el TF (tiempo de vuelo o Time of Flight) en ambos
> > dispositivos, pero siempre (excepto en el caso comentado en el
> > siguiente párrafo) inferiores a 1ms, por tanto respetando la
> > frecuencia de muestreo estimada en 1000Hz.
> >
> > Como se ve también en la hoja de cálculo, los tiempos entre las
> > Chronopics difieren en mayor medida cuando el tiempo a medir es mayor.
> > Esto no supone un problema para los saltos, pero sí para cuando se use
> > chronopic para otras aplicaciones de tiempo más elevado. Además, la
> > aparición de las diferencias, refleja en mi opinión, que efectivamente
> > existe algún error en la medición/tratamiento de los datos que se
> > arrastra en cada bucle de tiempo.
> >
> > Así, se cree que Chronopic3 difiere en la medición por alguna
> > diferencia en el hardware, que esta diferencia no es significativa en
> > los saltos (objetivo inicial y principal del proyecto), pero que
> > conviene ser analizada y corregida cuanto antes para que Chronopic sea
> > funcional en tests de más duración entre eventos.
> >
> > Que la medición realizada entre Biopac y Chronopic3 (similar a la
> > incluída en este correo), pero con diferencias de un orden de magnitud
> > superior, puede que se explique por haber usado un a conexión de
> > cables distinta, en que ambos dispositivos no se encontraban en
> > paralelo. Puede que un dispositivo estuviera afectando al otro. Se
> > espera mañana poder probar con la misma  disposición usada en la
> > prueba entre Chronopic3 y 1.
> >
> > En el caso de que mañana la diferencia continue existiendo, se probará
> > sin el condensador C4.
> >
> > Saludos
> >
> >
> >
> >
> >
> > 2008/1/28, juan <juan iearobotics com>:
> > > Hola,
> > >
> > >   Pongo aquí unas observaciones:
> > >
> > >   1) Un error de 5ms es muchísimo para un microcontrolador. La chronopic
> > > puede ejecutar en ese tiempo unas 5.000 instrucciones (Todo el firmware
> > > completo no tiene más de 200 y muchas se ejecutan sólo en la
> > > inicialización).
> > >
> > >   2) El firmware es el mismo para la chronopic 1.0, 2.0 y 3.0. Y puesto
> > > que el microcontrolador es el mismo (no se ha modificado) el software se
> > > ejecuta en el mismo tiempo para todos los prototipos. No va a hacer
> > > cosas diferentes en chronopic 1.0 que en la 3.0. Es el mismo firmware
> > > corriendo en el mismo microcontrolador con el mismo reloj.
> > >
> > >   3) Podría haber un bug en el firmware de manera que no cronometrase
> > > bien. Por eso se hizo una primera validación conectando un generador de
> > > ondas cuadradas a la skypic y comprobando que el tiempo calculado por el
> > > firmware fuese correcto. Los resultados obtenidos fueron los que os
> > > adjunto en la hoja de cálculo (que se hizo con openoffice 1.0 por eso
> > > está en formato .sxc). El resultado fue que el firmware tiene un error
> > > máximo de 0.5ms. Y para tiempos de vuelo del orden de 500ms es de
> > > 0.04ms. Es decir, errores casi despreciables. Esto es lo normal al usar
> > > microcontroladores.
> > >
> > >   CONCLUSIONES
> > >   ------------
> > >
> > >   A partir de estos hechos medidos:
> > >
> > >   1) El firmware tiene un error casi despreciable, muy por debajo de los
> > > 5ms detectados.
> > >   2) Se ha detectado un error de unos 5ms en las pruebas de validación
> > >
> > >   --> Conclusión: el error NO está en el firmware, sino en otra parte
> > > del hardware.
> > >
> > >   POSIBLE CAUSA DEL PROBLEMA
> > >   --------------------------
> > >
> > >   Revisando el esquema del hardware he visto que puse un condensador de
> > > 1uF en paralelo con la plataforma para eliminar los rebotes (por
> > > hardware. Además se eliminan los rebotes por software).
> > >
> > >   Creo que el retraso lo puede estar provocando ese condensador. Al
> > > realizarse el salto, el condensador tarda un tiempo en cargarse. Hasta
> > > que no se carga no le llegan los 5v al PIC. Este tiempo de carga depende
> > > del valor de la resistencia de pull-up interna del PIC (tengo que mirar
> > > cuanto es). Un valor típico de pullup es 4K7 lo que daría un tiempo de
> > > carga del condensador de 4.7ms . Este dato cuadra bastante bien con el
> > > retraso encontrado de 5ms.
> > >
> > >   PRUEBAS A REALIZAR
> > >   -------------------
> > >
> > >   Sugiero repetir las pruebas pero quitando el condensador electrolítico
> > > C4 (desoldándolo).
> > >
> > >
> > > Saludos, Juan
> > >
> > >
> > >
> > > El lun, 28-01-2008 a las 18:05 +0100, Xavi de Blas escribió:
> > > > Después de diversas pruebas de validación, se han encontrado dos
> > > > errores en la medición. Ambos errores ya existían en Chronopic 1.0 y
> > > > aunque son muy pequeños, existen y hay que corregirlos.
> > > >
> > > > 1) En comparación con un osciloscopio (Biopac), el Tiempo de Contacto
> > > > de Chronopic es usualmente 5 ms menor y el Tiempo de vuelo 5 ms mayor.
> > > > Siendo 5 ms el valor escrito en el firmware como tiempo antirrebotes,
> > > > tal vez este valor se use erróneamente en el programa:
> > > >
> > > > TIEMPO_ANTIRREBOTES   EQU 0x05
> > > >
> > > > Estos 5ms oscilan entre (4,5 y 6,9) de hecho la media encontrada ha
> > > > sido de 5,7ms
> > > >
> > > > Para saltos, repercute en una diferencia en el vuelo de menos de 1cm,
> > > > así que es poco, pero sin duda es un error
> > > >
> > > > 2) Cuando los contactos son inferiores al tiempo de rebotes, las
> > > > diferencias con Biopac son mayores. Esto no es problema en saltos,
> > > > pero sí puede serlo en skipping, tiempos de reacción cortos, ...
> > > > Habría que poder ajustar desde el software este TIEMPO_ANTIRREBOTES
> > > > tal y como ya se ha hablado alguna vez.
> > > >
> > > > Si podemos modificarlo deprisa, el nuevo chronopic 3.0 saldrá con el
> > > > firmware corregido, y si no es así, entonces la siguiente versión de
> > > > Chronojump debería actualizar el firmware.
> > > >
> > > > Se apunta la posibilidad de que cuando se realice la corrección, se
> > > > ofrezca al usuario la posibilidad de corregir automáticamente todos
> > > > los datos captados previamente.
> > > >
> > > > Recuerdo que para saltos la desviación es muy ligera.
> > > >
> > > > Por otro lado, los datos concuerdan ligeramente con lo que se obtuvo
> > > > en comparación con Ergojump:
> > > > http://mail.gnome.org/archives/chronojump-list/2005-July/msg00002.html
> > > >
> > > > "Se advierte que en general los tiempos de contacto en Chronopic aparecen
> > > > ligeramente inferiores y los de vuelo ligeramente superiores. Por otro
> > > > lado, son datos que no difieren de más de 1 cm. de elevación del CdG, y
> > > > por tanto son poco relevantes."
> > > >
> > > > Aunque revisando la hoja de cálculo que se obtuvo de dicha
> > > > comparación, la variabilidad era mucho mayor, hecho que lleva a pensar
> > > > que dicho dispositivo quizás tenía menos precisión o arrastraba algún
> > > > otro error.
> > > >
> > > > Voy a estudiar el código del firmware. Para los interesados:
> > > > http://www.iearobotics.com/personal/juan/proyectos/chronopic/1.0/
> > > >
> > > > Ahora es cuando nos acordamos de que el firmware está en ensamblador y no en C.
> > > >
> > > >
> > > > Saludos
> > > > _______________________________________________
> > > > Chronojump-devel-list mailing list
> > > > Chronojump-devel-list gnome org
> > > > http://mail.gnome.org/mailman/listinfo/chronojump-devel-list
> > > --
> > > Juan Gonzalez Gomez
> > > juan iearobotics com
> > > www.iearobotics.com
> > >
> > > _______________________________________________
> > > Chronojump-devel-list mailing list
> > > Chronojump-devel-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/chronojump-devel-list
> > >
> > >
> > >
> >
> >
>

Attachment: chronopic1_chronopic3_chronopic3_biopac.ods
Description: application/vnd.oasis.opendocument.spreadsheet



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]