[manooooh]

Hola!

Para mis amigos del foro los físicos seguro les "atrapará" este problema que estoy teniendo

Diseñé una aplicación muy sencilla que intenta ser una réplica lo suficientemente realista como el siguiente simulador de PhET "El Hombre Móvil":

https://phet.colorado.edu/sims/cheerpj/moving-man/latest/moving-man.html?simulation=moving-man&locale=es



Utilicé App Inventor que es una página web gratuita para iniciarse con la programación. Utiliza bloques de programación.

Adjunto el archivo .AIA (descomprimir el .rar) que pueden ustedes descargarse e importarlo a través de http://ai2.appinventor.mit.edu/. Se registran con Google y para probar el funcionamiento tienen que instalarse la app AI2 Companion en su celular para que puedan crear una réplica de lo que programan en su celular (no ocupa nada de espacio, y no se instalan la app sólo es una réplica. Luego si quieren la pueden desinstalar).

Cómo probar la app

Para importar el proyecto van a Proyectos > Importar proyecto (.aia) desde mi ordenador...

Para conectarlo con su celular primero abran el proyecto, luego van a Conectar > AI Companion > Agarran el celular, abren la aplicación y escanean el QR (es más rápido que tipearlo).

[cerrar]

Básicamente lo que hago es que en cada intervalo del RelojMRU calcular la posición con:

\( x=x_0+vt \)

RelojMRU está configurado con un intervalo de 1000 ms, equivale a 1 s. Si lo prueban van a ver que funciona.

Sin embargo, no es nada realista porque el chico va dando "saltos". Necesito bajar el intervalo, digamos a 20 ms.

Pero ahora si lo cambio y corro la app, ¡el chico camina lento! Cuando no quiero que suceda.

Y si modifico en los bloques el / 1000 y se lo saco (o queda / 1 que es lo mismo), ¡ahora el chico vuela! Cuando no quiero que suceda.

Si con un intervalo de 1000 ms (= 1 s) el ancho de mi pantalla son 650 px (supongamos que son 650 m) y tiene una velocidad de 65 m/s, el tiempo real deberán ser 10 s. Si lo prueban da ese tiempo.

¿Qué habría que modificar y no estoy sabiendo qué para que con un intervalo de 20 ms (= 0,02 s) y todo configurado igual (velocidad de 65 m/s), el chico tarde la misma cantidad de tiempo en recorrer todo (10 s)? Intenté dividir el tiempo por 1000, pero jamás consigo los 10 segundos de la realidad...

Estos son todos los bloques pasados a limpio:



No me animé a agregar la aceleración (MRUV) ya que si no estoy seguro cómo funciona a velocidad constante... ni me quiero imaginar con velocidad variable

Gracias!!
Saludos

[Richard R Richard]

Hola manooooh


Observa que  los mlilisegundos (1000) es el tiempo que seteas entre calculo y calculo de posicion,  luego veras 11 fotogramas uno a 0 m o posicion inicial, el primero en movimiento a 65m (10% de tu pantalla) , el segundo a 130m (20% de pantalla)... hasta llegar a 650 px o 100% de pantalla en 10 segundos.


Si tu evaluas cada 20 milisegundos la distancia recorrida es 1000/20 = 50 veces menor  (pero 50 veces mas de evaluaciones de posición por unidad de tiempo) entonces en vez de moverse 65 m solo se debe mover $$65/50 =1.3m$$  o $$1.3 pixeles$$ en cada toma de tiempo.

o lo que es lo mismo

$$\Delta Pixeles =velocidad(pixeles /segundo)\cdot \Delta t = \dfrac{650pixeles\ total\  pantalla}{10s\ tiempo\ total} 0.02s=1.3p $$ 

Espero te ayude, si es que interpreté correctamente lo que te está sucediendo,  revisa que los saltos en pixeles  tienen que ser proporcionales a tiempo entre cálculo y cálculo de la posición.
Si varias la velocidad  es decir 650/10=65 por otro valor , si la cantidad de pixeles es constante, la duracion del viaje hasta la  llegada se acorta si la aumenas y se demora si la achicas.

Pd. Enhorabuena!!!! Me alegra que se te ocurran esos proyectos.


Para velocidad variable la posicion es pixeles es  similar a lo que sucede en la vidad diaria con la posicion en metros , solo hay un factor de escala que los diferencia  ( en metros /pixeles o viceversa)

$$pixeles_{(t)} =factor(escala)\cdot(\pm x_o\pm v_ot\pm \frac12 a t^2)$$
Saludos

[Tachikomaia]

No entiendo el problema.

RelojMRU está configurado con un intervalo de 1000 ms, equivale a 1 s. Si lo prueban van a ver que funciona.

¿Significa que muestra 1000 imágenes (o situaciones) por segundo? Con tanta cantidad no debería haber problema de saltos salvo que la máquina o conexión sea lenta.

[manooooh]

Hola Richard, perdón la demora

Gracias por tomarte la molestia de pensar junto a mí!!

¿Lo que quieres decir es que lo que pido es impracticable o hay manera de solucionarlo?

Observa que  los mlilisegundos (1000) es el tiempo que seteas entre calculo y calculo de posicion,  luego veras 11 fotogramas uno a 0 m o posicion inicial, el primero en movimiento a 65m (10% de tu pantalla) , el segundo a 130m (20% de pantalla)... hasta llegar a 650 px o 100% de pantalla en 10 segundos.

Exactamente como lo describes!! No lo podrías haber dicho mejor.

¿Hay manera de que en mayor cantidad de fotogramas se pueda recorrer misma la distancia (650 píxeles) en el mismo tiempo (10 segundos)? ¿O no se puede?

Si tu evaluas cada 20 milisegundos la distancia recorrida es 1000/20 = 50 veces menor  (pero 50 veces mas de evaluaciones de posición por unidad de tiempo) entonces en vez de moverse 65 m solo se debe mover $$65/50 =1.3m$$  o $$1.3 pixeles$$ en cada toma de tiempo.

o lo que es lo mismo

$$\Delta Pixeles =velocidad(pixeles /segundo)\cdot \Delta t = \dfrac{650pixeles\ total\  pantalla}{10s\ tiempo\ total} 0.02s=1.3p $$ 

Esto ya se me escapa, ¿o sea tu \( \Delta Pixeles \) es lo mismo que \( \Delta x=x_f-x_i \)? Si es así, la fórmula es \( x_f=x_i+vt \), pero tú pareces reemplazar las variables y yo quiero que quede una ecuación donde la incógnita es \( x_f \) para que los alumnos vean que la fórmula funciona.

Hay algo que todavía no termino de comprender, ¿quieres decir que a los bloques que puse que básicamente simulan la ecuación \( x_f=x_i+vt \) hay que agregarle al bloque RelojMRU.IntervaloDelTemporizador (con valor 20 ms) un factor de escala? ¿Cuál sería y cómo se calcula?

Espero te ayude, si es que interpreté correctamente lo que te está sucediendo,  revisa que los saltos en pixeles  tienen que ser proporcionales a tiempo entre cálculo y cálculo de la posición.

No entendí a lo que te refieres con "proporcionales a tiempo entre cálculo y cálculo de la posición", pero sospecho que es que el intervalo sea parejo y no que tenga imperfecciones. Si es esto, creo que la página no es perfecta y a menor cantidad de intervalo se comete un error mayor, por eso decidí que el intervalo no sea 1 ms sino 20 ms.

Si varias la velocidad  es decir 650/10=65 por otro valor , si la cantidad de pixeles es constante, la duracion del viaje hasta la  llegada se acorta si la aumenas y se demora si la achicas.

Obviamente Al disminuir la velocidad el chico deberá andar más lento. Pero vuelvo a lo mismo: ¿cómo se calcula (si es que se puede) ese factor de escala para cualquier velocidad que le ponga? Puse 65 m/s para facilitar el razonamiento pero se debería (o al menos es lo que quiero ) simular correctamente con cualquier valor del intervalo \( [0,65] \).

Pd. Enhorabuena!!!! Me alegra que se te ocurran esos proyectos.

Gracias! No tiene nada de misterio, sólo lo embellecí un poco... pero ahí está, la Física haciendo de las suyas.

Para velocidad variable la posicion es pixeles es  similar a lo que sucede en la vidad diaria con la posicion en metros , solo hay un factor de escala que los diferencia  ( en metros /pixeles o viceversa)

$$pixeles_{(t)} =factor(escala)\cdot(\pm x_o\pm v_ot\pm \frac12 a t^2)$$

Como dije estaría buenísimo implementar MRUV, pero por lo pronto, si todavía no me sale entender MRU en un proyecto tan simple prefiero no "avanzar".

RelojMRU está configurado con un intervalo de 1000 ms, equivale a 1 s. Si lo prueban van a ver que funciona.

¿Significa que muestra 1000 imágenes (o situaciones) por segundo? Con tanta cantidad no debería haber problema de saltos salvo que la máquina o conexión sea lenta.

No. Justo al revés. Significa que cada 1 segundo, se muestra una imagen. Si reduces el intervalo digamos a 0,01 segundos, entonces en ese tiempo se muestra 1 imagen, o lo que es lo mismo 100 imágenes en 1 segundo.

Saludos

[Richard R Richard]

Hola Richard, perdón la demora

Gracias por tomarte la molestia de pensar junto a mí!!

¿Lo que quieres decir es que lo que pido es impracticable o hay manera de solucionarlo?

100% solucionable.

Observa que  los mlilisegundos (1000) es el tiempo que seteas entre calculo y calculo de posicion,  luego veras 11 fotogramas uno a 0 m o posicion inicial, el primero en movimiento a 65m (10% de tu pantalla) , el segundo a 130m (20% de pantalla)... hasta llegar a 650 px o 100% de pantalla en 10 segundos.

Exactamente como lo describes!! No lo podrías haber dicho mejor.

Entonces si el hardware no te aporta ningun retraso por pedirle que calcule mas posiciones por unidad de tiempo veamos si te puedo ayudar a encontrar el fallo.

Como no tengo idea de como lo programaste  yo te doy ideas generales las que deberas adaptar,  y preguntame si es que así no funciona o debe funcionar distinto
Olvida la nomeclatura que di antes

Ahora llamaré
$$x_0$$ a la posicion de origen de su situacion rela simuladas
$$x_1$$ a la posicion final si viaja hacia las x positivas
$$x_2$$ a la posicion final si viaja hacia las x negativas

$$P_i$$  valor del minimo pixel a la izquierda de la pantalla
$$P_f$$  valor del maximo pixel a la derecha de la pantalla
Es decir $$Pf-Pi=L =$$longitud horizontal de la pantalla en pixeles (tu me decias que eran 650 pixels, cualquier ejemplo te lo doy en base a eso)
$$t_o$$ tiempo cuando inicia el cronometro
$$t_f$$ tiempo cuando finaliza el cronometro
o bien $$D_t=t_f-t_o=$$Tiempo durante el cual habrá movimiento(esto probablemente sea dato... son los 10 segundos que dijiste  funcionaba la apliacion)

$$v= $$velocidad del objeto , si es positiva se mueve a derecha si es negativa se mueve a izquierda.

ahora ...yo lo pienso de este modo pero quizá tu lo pienses distinto

a tiempo cero estoy en el medio de la pantalla en el pixel $$Pm=(Pf-Pi)/2$$
cuando pase el tiempo $$D_t$$ estara en $$P_i$$ si la velocidad fue negativa o en $$P_f$$ si la velocidad fue positiva. es decir a la izquierda  o a la derecha de la pantalla.

La escala es $$ E= \dfrac{Desplazamiento\ en\ pantalla}{Desplazamiento\ real}$$  llamo real a lo que pretendes simular en la vida real,  y pantalla a lo que veas en pixeles en pantalla

si durante el tiempo de la aplicacion vas de la posicion inicial al medio  hacia la derecha o final porque $$v$$ es positiva  entonces el desplazamiento en pantalla es $$Pf-Pm$$ y en la vida real hubiese sido $$v.D_t=x_1-x_0$$ si va hacia un lado o bien $$v.D_t=x_2-x_0$$ si va hacia el otro.

Asi la escala es $$E=\dfrac{Pf+Pi}{2|v|D_t}$$

Así lo que pasa en la vida real con $$x=x_0+vt$$  en pantalla será  $$p=\overbrace{(Pf-Pi)/2}^{pos\ inicio}+\overbrace{E\cdot v}^{vel\ en\ pantalla}\cdot t$$

Ahora el tiempo lo puedes ir variando como  $$t =t_0+n \Delta t $$  donde $$t_0$$ es el  tiempo de inicio(de maquina ) o por lo general lo tomas cero , $$n$$ es un entero entre 0 y la cantidad maxima de fotogramas que vas a representar en el tiempo que dure el movimiento y $$\Delta t$$ es el tiempo entre fotogramas

Así si quieres  un movimiento continuo  sera de 10 a 30 fotogramas o por segundo (las pelis, videos y juegos los tienen)  entonces $$\Delta t$$ esta entre 1seg/10 y 1seg/30 es decir de 33ms a 100ms  Entonces el maximo $$n$$ será un entero  $$n_{max}\cong\dfrac{D_t}{\Delta t}$$  luego el tiempo $$t$$  lo modelas  con un bucle entre $$0 <n< n_{max}$$ resultando  $$t =to+n \Delta t $$
Así a cada $$\Delta t$$ calculas la nueva posicion del objeto con $$p=(Pf-Pi)/2+E\cdot v\cdot  t$$  y listo.

Si quieres evitar el bucle $$n$$ puedes usar directamente la diferencia del tiempos de maquina como $$t=t(actual)-t(inicial)$$

Entonces resumiendo el chico se mueve mas lento si aumentas $$D_t$$ (el tiempo en moverse en pantalla) (pero si varias la velocidad  se movera siempre igual en pantalla ya que  eso te  lo ajustará la escala) recorrera los mismos pixeles en mas o menos tiempo $$D_t$$.

Ejemplo si dices arranca en posicion 10m y se mueve a 3m/s en $$D_t=10$$ segundos su posicion es 40m . En pantalla ira del medio que sera el pixel 650/2 =325 y en 10 segundos estará en el pixel 650

si dices  arranca en posicion -60m y se mueve 50m/s en $$D_t=10$$ segundos su posicion es 440m (estos valores son lo que presentas en pantalla numericamente) pero en pantalla partirá de nuevo siempre del medio que será el pixel 325 y en 10 segundos estará en el pixel 650 o en el 0,   solo tardará mas o menos si tu dices que el movimiento dure más o menos ... es decir  si aumentas $$D_t$$  o lo disminuyes, ejemplo si duplicas será 20s  y recorrera los 325 pixeles ahora en 20 segundos.   

[Tachikomaia]

entonces en ese tiempo se muestra 1 imagen, o lo que es lo mismo 100 imágenes en 1 segundo.

1 imagen en 1s no es lo mismo que 100 en 1s.

Sigo sin tener mucha idea, pero capáz que se resuelve multiplicando o dividiendo t por esa velocidad de imágenes.

Por ejemplo si son 100 por segundo prueba:
\( x=x_0+vt/100 \)
eso haría que en el cálculo se usen centécimos de segundo en vez de segundos ¿no?

si no funciona:
\( x=x_0+vt*100 \)
No le veo sentido, pero por probar...

Si algo de eso funciona, capaz que en otros casos no, o sea, capaz que la fórmula "universal" sería: \( x=x_0+vt*Intervalo \)

Sería bueno que grabes un video de lo que sucede. Si usas PC te recomiendo VSDC Free Screen Recorder. Si no sabes usarlo te lo explico.

[Richard R Richard]

entonces en ese tiempo se muestra 1 imagen, o lo que es lo mismo 100 imágenes en 1 segundo.

1 imagen en 1s no es lo mismo que 100 en 1s.

Relee la frase, no es lo que estas pensando.  Hay un intervalo de tiempo entre frame y frame, es $$\Delta t$$, la cantidad de frames por segundo es $$\dfrac{1}{\Delta t}$$. Ej,  si quieres una imagen cada 50 milisesgundos  habra  $$\dfrac{1}{0.05}=20fps$$ , si el viaje dura 30 segundos y hay 20fps  entonces  se debe evaluar 600 veces la posicion y presentar 600 imagenes ese significa dividir  325 pixeles entre 600 y eso es lo que avanza entre imagan e imagen.
Todo es cuestion de proporciones, la maxima longitud en pixeles sobre la maxima longitud en la vida real es la relacion de escalas entre lo real y lo que quieres representar.   

Sigo sin tener mucha idea, pero capáz que se resuelve multiplicando o dividiendo t por esa velocidad de imágenes.

Por ejemplo si son 100 por segundo prueba:
\( x=x_0+vt/100 \)
eso haría que en el cálculo se usen centécimos de segundo en vez de segundos ¿no?

si no funciona:
\( x=x_0+vt*100 \)
No le veo sentido, pero por probar...

Si algo de eso funciona, capaz que en otros casos no, o sea, capaz que la fórmula "universal" sería: \( x=x_0+vt*Intervalo \)

Sería bueno que grabes un video de lo que sucede. Si usas PC te recomiendo VSDC Free Screen Recorder. Si no sabes usarlo te lo explico.

No no es así no es cuestion de probar . relee mi mensaje anterior...


Manooooh

• Si aumentas la cantidad de frames por segundo (fps) para la misma duracion de viajes, lo único que reduces es el salto entre imagen e imagen y aumenta la cantidad de evaluaciones p(t) por viaje.
• Si se define una duración de viaje y se reduce la velocidad, en el mismo tiempo debe moverse menos pixeles, si es que has fijado una relación entre el espacio real y el de la máquina.
• Si se define una relación de longitudes para la escala,  aumentar la velocidad hará que llegué mas pronto a fin de pantalla. 

Pero hay que entender que todo a la vez no se puede hacer.  Si la escala de tiempo es 1 a 1 , es decir lo que sucede en la vida real pasa a la misma tasa de tiempo en el programa , lo unico que hay que establecer es una relacion entre el espacio real y el espacio en pixeles del telefono, pc o tablet.   Si la escala la defines para que se llegue a final de pantalla en un tiempo $$D_t$$  el maximo espacio será $$vD_t$$ y eso ocupara  tantos pixeles  en pantalla como desees, yo lo trabajé como si parte siempre del centro de pantalla hacia alguno de los lados, pero es cuestión de como seteas el programa.
 

Saludos

[Tachikomaia]

Ya veo, había cortado la frase.

Pero sigo diciendo que a veces es cuestión de probar.

Y parece que le estás cambiando toda la fórmula... Pero me parece que su fórmula no sirve para que recorra D distancia en T tiempo, sólo calcula la posición en base a una posición inicial, velocidad y tiempo transcurrido. Efectivamente, para lograr eso se requiere hacer D/T, pero el programa que vi no hace eso, pensé que lo quería imitar...
Dime si no sirve D/T*Intervalo

[manooooh]

Hola

Entonces si el hardware no te aporta ningun retraso por pedirle que calcule mas posiciones por unidad de tiempo veamos si te puedo ayudar a encontrar el fallo.

No estoy seguro que no tenga retraso. Supongo que cuando el intervalo del reloj es cada vez menor, va a ser más propenso a tener algún retraso. 20 ms no está tan mal, antes quería hacerlo con 1 ms pero ya se me fue de la cabeza.

Como no tengo idea de como lo programaste  yo te doy ideas generales las que deberas adaptar,  y preguntame si es que así no funciona o debe funcionar distinto

No es para nada difícil, Richard. Tómate un segundo en mirar los bloques que puse y verás el cálculo que hago.

Son bloques de programación para aprender a programar, y yo creo que te sobra la inteligencia para entenderlo.

$$t_o$$ tiempo cuando inicia el cronometro
$$t_f$$ tiempo cuando finaliza el cronometro
o bien $$D_t=t_f-t_o=$$Tiempo durante el cual habrá movimiento(esto probablemente sea dato... son los 10 segundos que dijiste  funcionaba la apliacion)

Lo de 650 píxeles está bien, pero los 10 segundos claro que es dato! Si quiero moverme 650 px a una velocidad de 65 px/s necesariamente t=10 s (en situación de MRU, como lo que estamos programando).

$$v= $$velocidad del objeto , si es positiva se mueve a derecha si es negativa se mueve a izquierda.

Bien.

ahora ...yo lo pienso de este modo pero quizá tu lo pienses distinto

a tiempo cero estoy en el medio de la pantalla en el pixel $$Pm=(Pf-Pi)/2$$
cuando pase el tiempo $$D_t$$ estara en $$P_i$$ si la velocidad fue negativa o en $$P_f$$ si la velocidad fue positiva. es decir a la izquierda  o a la derecha de la pantalla.

La escala es $$ E= \dfrac{Desplazamiento\ en\ pantalla}{Desplazamiento\ real}$$  llamo real a lo que pretendes simular en la vida real,  y pantalla a lo que veas en pixeles en pantalla

si durante el tiempo de la aplicacion vas de la posicion inicial al medio  hacia la derecha o final porque $$v$$ es positiva  entonces el desplazamiento en pantalla es $$Pf-Pm$$ y en la vida real hubiese sido $$v.D_t=x_1-x_0$$ si va hacia un lado o bien $$v.D_t=x_2-x_0$$ si va hacia el otro.

Asi la escala es $$E=\dfrac{Pf+Pi}{2|v|D_t}$$

Así lo que pasa en la vida real con $$x=x_0+vt$$  en pantalla será  $$p=\overbrace{(Pf-Pi)/2}^{pos\ inicio}+\overbrace{E\cdot v}^{vel\ en\ pantalla}\cdot t$$

Ahora el tiempo lo puedes ir variando como  $$t =t_0+n \Delta t $$  donde $$t_0$$ es el  tiempo de inicio(de maquina ) o por lo general lo tomas cero , $$n$$ es un entero entre 0 y la cantidad maxima de fotogramas que vas a representar en el tiempo que dure el movimiento y $$\Delta t$$ es el tiempo entre fotogramas

Así si quieres  un movimiento continuo  sera de 10 a 30 fotogramas o por segundo (las pelis, videos y juegos los tienen)  entonces $$\Delta t$$ esta entre 1seg/10 y 1seg/30 es decir de 33ms a 100ms  Entonces el maximo $$n$$ será un entero  $$n_{max}\cong\dfrac{D_t}{\Delta t}$$  luego el tiempo $$t$$  lo modelas  con un bucle entre $$0 <n< n_{max}$$ resultando  $$t =to+n \Delta t $$
Así a cada $$\Delta t$$ calculas la nueva posicion del objeto con $$p=(Pf-Pi)/2+E\cdot v\cdot  t$$  y listo.

Si quieres evitar el bucle $$n$$ puedes usar directamente la diferencia del tiempos de maquina como $$t=t(actual)-t(inicial)$$

Aquí me pierdo sinceramente.

Lo del bucle no lo había pensado, pero es que el "evento Temporizador" que es el bloque amarillo en la imagen de los bloques justamente se lo puede ver como un bucle: realiza las acciones una y otra vez. El "paso" (el "i" en programación) está dado por el IntervaloDelTemporizador que dijimos es 20 ms.

• Si aumentas la cantidad de frames por segundo (fps) para la misma duracion de viajes, lo único que reduces es el salto entre imagen e imagen y aumenta la cantidad de evaluaciones p(t) por viaje.
• Si se define una duración de viaje y se reduce la velocidad, en el mismo tiempo debe moverse menos pixeles, si es que has fijado una relación entre el espacio real y el de la máquina.
• Si se define una relación de longitudes para la escala,  aumentar la velocidad hará que llegué mas pronto a fin de pantalla. 

Pero hay que entender que todo a la vez no se puede hacer.  Si la escala de tiempo es 1 a 1 , es decir lo que sucede en la vida real pasa a la misma tasa de tiempo en el programa , lo unico que hay que establecer es una relacion entre el espacio real y el espacio en pixeles del telefono, pc o tablet.   Si la escala la defines para que se llegue a final de pantalla en un tiempo $$D_t$$  el maximo espacio será $$vD_t$$ y eso ocupara  tantos pixeles  en pantalla como desees, yo lo trabajé como si parte siempre del centro de pantalla hacia alguno de los lados, pero es cuestión de como seteas el programa.

Por "todo a la vez no se puede hacer" entiendo que ahora sostienes que lo que pretendo lograr con un intervalo menor no se puede ¿O sí?

Vamos a ver, me voy a tomar el trabajo de grabar la pantalla y mostrarles lo que está sucediendo para que me comprendan que no es tan difícil entender los bloques.

Saludos

[manooooh]

Hola

Aquí están los resultados. Arriba a la derecha está el cronómetro capturado a 30 fps al igual que la grabación de la pantalla del celular.

Intervalo 1000 ms:


Intervalo 500 ms:


Intervalo 100 ms:


Intervalo 20 ms:


En cada video no se modificó la programación, solamente el intervalo del temporizador.

Saquemos conclusiones:

1) Con 1000 ms son 10 segundos (y 500 ms parece que también).
2) A partir de 100 ms ya se empieza a notar la diferencia. En 20 ms es casi el doble.
3) El / 1000 para el primer video hace que termine quedando la ecuación \( x=x_0+v\cdot1000/1000\to x=x_0+v \) (posición actual = posición anterior + 65). En el segundo video sería \( x=x_0+v/2 \) (porque el intervalo son 500 ms), pero como se ejecuta cada 500 ms supongo que se compensa.
4) A partir de 100 ms ya parece no funcionar.

¿¿POR QUÉ NO FUNCIONA?? No entiendo

Saludos