La Whoop que uso todos los días tiene un acelerómetro y un giroscopio que miden 100 veces por segundo. La app oficial los usa para pasos, sueño y esfuerzo. Yo quería saber si alcanzaban para algo más divertido: un juego de batería tipo Guitar Hero, con una pulsera en cada mano. La Whoop en la izquierda, un Apple Watch en la derecha, las notas bajando por la pista y vos pegando al aire a tiempo.
Funciona. Y lo más interesante no fue el juego, sino el problema que hubo que resolver para que funcionara.
Cómo está armado
Un puente chico en Python se conecta a la Whoop por Bluetooth, prende el sensor de movimiento, detecta los golpes y los reparte por WebSocket. El juego corre en el navegador: Three.js servido como módulos ES, sin build, y la batería es un sintetizador con Web Audio, sin samples. El Apple Watch manda su movimiento al mismo puente por Wi-Fi, y el teclado también juega, para probar sin pulseras.
Detectar un golpe es lo más simple de todo. En reposo la aceleración es 1 g, la gravedad. Un golpe es un pico que pasa los 2,5 g, seguido de 300 ms de pausa para no contar el rebote dos veces. Nada de machine learning.
El problema: la Whoop llega tarde
Lo primero que hice fue medir el retraso. La Whoop mide a 100 Hz, pero no manda cada muestra: junta un segundo entero y lo manda en un paquete. Así que cada golpe llega a la Mac entre 0,5 y 1 segundo después de que lo diste.
En un juego de ritmo eso es una eternidad. La ventana de un Perfecto es de 70 ms.
Parecía el final del proyecto, hasta que miré qué traía cada paquete: cada muestra viene con la hora exacta en que se midió. Entonces el juego no evalúa el golpe con la hora en que llegó, sino con la hora en que pasó. Un golpe que llega 900 ms tarde, pero que diste justo a tiempo, es un Perfecto.
Dos detalles más hacen que el retraso no se sienta. La música la pone el juego, no tu golpe, así que la canción nunca se corre. Y una nota no se da por perdida hasta que pasa el tiempo máximo que esa pulsera puede tardar en entregar el golpe. Si no, el juego diría "fallo" y un segundo después cambiaría de idea.
El segundo problema: el feedback también llega tarde
Que el puntaje esté bien no alcanza. Si pegás y el tambor se ilumina un segundo después, se siente roto aunque el número final sea correcto.
La solución es un truco chico. Si venís acertando las notas de la mano lenta, el juego asume que vas a acertar la siguiente y la hace explotar en su momento exacto. Cuando el golpe real llega, solo confirma la nota o la convierte en fallo. En el carril lento, además, el golpe de guía suena más fuerte y reemplaza al sonido de tu propio golpe. Es lo mismo que hacen los juegos online con la latencia de red: predecir y después corregir.
Calibrar en vez de adivinar
Cada dispositivo tiene su propio retraso, y su reloj puede estar un poco corrido respecto del de la Mac. En vez de modelar todo eso, hay una pantalla de Calibrar: ocho clicks, uno cada dos segundos, y pegás con cada mano. El juego toma la mediana de la diferencia entre tus golpes y los clicks, y esa es la corrección para ese dispositivo. Un solo número absorbe el retraso del sensor, el desfase del reloj y hasta tu forma de pegar.
Los clicks van lentos a propósito. Con un desfase de reloj grande, un ritmo rápido emparejaría cada golpe con el click equivocado.
Lo que aprendí
Antes de tirar una idea por la latencia, fijate si los datos traen la hora. El retraso de la Whoop parecía fatal. No lo era, porque lo que importa en un juego de ritmo no es cuándo te enterás del golpe, sino cuándo pasó. Medir primero cambió todo el diseño.
La latencia decide qué juegos podés hacer. La misma técnica sirve para ritmo y para nada en tiempo real: apuntar o esquivar con la mano de la Whoop es imposible. Por eso la lista de juegos es batería, boxeo al ritmo de la música y uno de cargar energía con la respiración. Ningún juego de reflejos.
Que el número sea correcto no alcanza; tiene que sentirse correcto. El puntaje estuvo bien desde el primer día. Lo que faltaba era el feedback inmediato, y eso salió de la predicción, no de más precisión.
El hardware real siempre te corrige el README. Varias cosas aparecieron recién con la pulsera en la mano:
- La Whoop solo entra en modo emparejamiento fuera de la muñeca: sacátela, esperá a que se apaguen las luces y tocala firme con dos dedos hasta que parpadee en azul.
- Se empareja con un solo dispositivo a la vez, así que hay que apagar el Bluetooth del teléfono.
- El sensor de movimiento tarda unos 10 segundos en empezar a mandar datos. Mi primer aviso de "no llega nada" saltaba demasiado rápido.
- Si la pulsera rechaza el emparejamiento, reintentar sin parar solo le gasta la batería. El puente ahora se rinde después de tres rechazos.
- Cuando la conexión funciona, la pulsera vibra. Esa vibración resultó mejor señal de "anda" que cualquier línea de log.
A veces el camino sin código es el mejor. Para el Apple Watch armé una app nativa para el Watch y el iPhone. Con una cuenta gratis de Apple, Xcode nunca encontró mi reloj, que se había quedado en watchOS 26 al lado de un iPhone con iOS 27. La salida fue Sensor Logger, una app gratis del App Store que manda el movimiento del Watch por HTTP. El puente lo recibe, detecta los golpes y listo, sin Xcode. Los datos llegan hasta 2 segundos tarde, pero la misma técnica de la hora real lo resuelve.
Leé la licencia de lo que usás como referencia. El protocolo Bluetooth de la Whoop no es público. Lo implementé a partir de la documentación del proyecto open source noop. El código es mío, pero la licencia de noop es no comercial, y lo dejé anotado en el proyecto antes de pensar en publicar nada.
Lo que sigue
Boxeo, con combos al ritmo de la música. La fuerza del golpe va a importar menos de lo que esperaba, porque el acelerómetro de la Whoop satura cerca de 8 g y todos los golpes fuertes miden parecido. Y Ki: cargar energía con la respiración y el pulso, que la Whoop también manda en vivo, y lanzarla con las dos manos.
Proyecto independiente, sin relación con WHOOP, Inc. ni Apple. Usalo solo con dispositivos tuyos.