Acto I: el radio que se rompe

Un motor de buje de 2.000 W es un buje de veintiún centímetros de diámetro enlazado a una llanta con radios cortos y gruesos: 160 mm en total, 2,6 mm de diámetro, treinta y seis en total, cruzados una vez. Cuando uno se rompe, nunca es una sorpresa para la rueda, solo para el ciclista. Iba por mi segunda rueda: la primera había acabado igual, un radio, luego dos, luego una llanta que se descentra y ya no se recupera.

Un radio casi nunca se rompe por estar demasiado tenso. Se rompe porque no lo está bastante: en cada vuelta de rueda, cuando pasa por abajo, la carga lo afloja, y un radio que se afloja y se vuelve a tensar miles de veces por kilómetro acaba por fatiga, casi siempre en el codo, en el agujero de la brida. Así que la respuesta correcta no es sustituir el radio roto, sino saber a qué tensión están los otros treinta y cinco, y llevarlos todos al mismo nivel, el correcto.

El problema es que ese nivel nadie me lo daba. Igualar de oído, haciendo sonar los radios, es un método antiguo que sirve para igualar pero no dice nada del valor absoluto: una rueda entera demasiado tensa suena igual de bien que una rueda entera demasiado floja, y en los foros de bicicletas eléctricas las llantas rajadas por exceso de tensión son tan frecuentes como los radios rotos por defecto. Necesitaba una medida.

Acto II: por qué no un tensiómetro comercial

Un tensiómetro de bicicleta clásico, el modelo de 18 euros igual que el de 80, funciona flexionando el radio entre dos apoyos separados unos sesenta milímetros con un muelle calibrado, y una tabla convierte la flecha leída en tensión. Funciona bien en un radio de bicicleta de 2 mm y 280 mm de largo, porque ese radio, dejado a su aire, casi no resiste la flexión: lo que el aparato mide es realmente la tensión que lo rigidiza.

En mi radio de 2,6 mm es otra historia. La rigidez propia de una varilla a flexión crece con la cuarta potencia de su diámetro: pasar de 2 a 2,6 mm casi la triplica. Sobre 60 mm de apoyos, la parte de la tensión en lo que mide el aparato cae por debajo de la mitad; el resto es el propio radio defendiéndose, con tensión o sin ella. Y la tabla de papel de esos aparatos se acaba de todos modos antes de 2,6 mm. Habría tenido una cifra, pero no una medida.

La solución cabe en dos ideas. Primero, flexionar sobre una luz lo más larga posible, porque la parte de la tensión crece con la luz: sobre 125 mm en vez de 60, pasa del 45 % a más del 70 % para un radio libre. Segundo, sustituir el muelle por una fuerza realmente repetible. Tenía una llave dinamométrica de clic de 3 a 20 Nm en un cajón. Un clic es un par conocido, el mismo cada vez, con un 4 % de margen. Con una palanca, es una fuerza conocida.

Acto III: el diseño, y sus callejones sin salida

El principio no cambió desde el primer croquis hasta la herramienta soldada: tres puntos de contacto en el radio, dos de un lado en los extremos de la luz, uno en el medio del otro lado, llevado por un brazo que la llave hace girar alrededor de un pivote. La llave hace clic, el brazo ha empujado el radio con una fuerza fija, y la flecha que ha tomado depende de su tensión.

Lo que cambió fueron todos los detalles, y los trabajé sobre un modelo paramétrico en 3D, con un asistente de IA para mantener el modelo, abrirlo en Blender y hacer los cálculos en cada iteración. Algunos callejones sin salida merecen contarse, porque son instructivos.

La primera versión era impresa en plástico. El cálculo la mató antes de imprimirla: para 1,5 mm de flecha que medir en el radio, el brazo de PLA se flexionaba 2,5 mm. Todo el camino de esfuerzo pasó al acero.

La segunda flexionaba el radio fuera del plano de la rueda, hacia el exterior, porque era más fácil de construir. La rechacé: un radio trabaja en el plano de la rueda cuando el motor empuja, y quería medirlo en ese sentido. Para un radio redondo ambos son equivalentes, pero no era natural, y el pivote habría quedado en un sitio imposible una vez puesta la herramienta en una rueda real, con los radios vecinos pasando a 24 mm.

Los apoyos son rodamientos, no pivotes fijos. La literatura sobre tensiómetros es clara: el rozamiento del radio sobre sus apoyos falsea la lectura, y mucho. Dos rodamientos de patín, 22 mm de diámetro, 8 mm de agujero, no cuestan casi nada y ruedan sin rozar. El tercer punto es una simple horquilla, porque no se mueve.

El clic suelta la carga. Me saltó a la vista animando el mecanismo en Blender: una llave de clic toma unos tres grados de holgura en el momento de disparar, y el par cae. El radio solo necesita dos grados del brazo para volver. Si se leyera la posición del brazo después del clic, se leería cualquier cosa. De ahí una lectura de máximo retenido: la varilla de profundidad de un calibre, empujada por el brazo, se queda donde el brazo la llevó cuando este retrocede. Se lee el máximo, el del clic.

Acto IV: la herramienta soldada

Entre el modelo y el taller la herramienta volvió a cambiar, como siempre que se tienen pletinas de acero, un equipo de soldar y una caja de tornillos a mano en lugar del inventario exacto del modelo. El modelo 3D se reajustó después sobre la herramienta real, cota por cota, con fotos. Esto es lo que existe.

El bastidor es un tubo cuadrado de 25 mm que se apoya por encima del radio, a 6 mm de él, y queda enteramente fuera del plano de los radios vecinos. Solo tres elementos bajan al nivel del radio: la horquilla en el extremo del lado del buje, una ranura de 3,5 mm colgada bajo el extremo del tubo, y los dos rodamientos, cada uno en el extremo de un tornillo vertical. El primer rodamiento, A, está al final de un tornillo soldado bajo el tubo, a 125 mm de la horquilla. El segundo, B, al otro lado del radio, a 60 mm de A, está al final de un tornillo soldado al brazo móvil.

El brazo móvil es una pletina de 4 mm colocada por encima del tubo. Gira sobre un tornillo dejado flojo, X, clavado en una placa de 4 mm soldada sobre el tubo, a 15 mm de A y 46 mm de B. Un vaso soldado sobre el brazo, a 25 mm de A, recibe el cuadrado de la llave dinamométrica, cuyo mango sale radialmente hacia la llanta. Cuando la llave empuja, el brazo gira alrededor de X y B aprieta el radio con el par dividido por 46 mm: 111 N a 5 Nm, 156 N a 7.

El calibre va deslizado entre el brazo y el tubo, junto a la placa del pivote, y su varilla de profundidad toca el tornillo de B. Lee directamente el desplazamiento de B respecto al tubo, es decir, la flecha del radio respecto a la cuerda que une sus dos apoyos fijos, A y la horquilla.

Acto V: las primeras cifras, y una lección de mecánica

Primera sorpresa, y la que más me enseñó. En un radio libre, sostenido en el aire dentro de la herramienta, leí 3,4 mm a 3 Nm, 4,6 mm a 5 Nm y 5,9 mm a 7 Nm. Tres puntos perfectamente alineados, 0,625 mm por Nm, pero una recta que no pasa por cero: hay 1,5 mm de lectura antes de que el radio empiece a resistir. Es la holgura de montaje, la ranura de 3,5 sobre un radio de 2,6, el pivote flojo, los tornillos. Es constante, al menos esas tres veces, y se resta. Pero impide leer una medida sola sin haberla caracterizado.

Segunda sorpresa: esa pendiente era dos veces y media más baja de lo que preveía el cálculo para un radio de 2,6 mm libre sobre dos apoyos. Primero busqué adónde se iba el par. No se iba a ninguna parte. La viga era la que estaba mal: un radio que se sujeta por el extremo entre dos dedos ya no es libre, y sobre todo, un radio montado en una rueda tiene sus extremos sujetos, el codo en el agujero de la brida a 20 mm de la horquilla, la cabecilla en la llanta a 15 mm del rodillo A. Con extremos sujetos tan cerca de los apoyos, la rigidez a flexión es cuatro veces la de una viga libre. Con eso, la parte de la tensión en lo que lee la herramienta vuelve a caer a un 40 % hacia 1.000 N. Menos de lo esperado, pero todavía muy medible.

En el radio montado leí 3,8 mm a 7 Nm. Restada la holgura, quedan 2,3 mm elásticos, y el modelo los convierte en unos 850 N, entre 640 y 1.140 según la holgura valga realmente 1,2 o 1,8 mm. Para un radio de 2,6 mm en un motor de buje, el orden de magnitud habitual es 1.000 N. Así que ese radio no anda lejos, pero la cifra sigue siendo un cálculo, no una medida: la posición exacta de los apoyos y la sujeción real del codo pesan un 20 % en el resultado. Para comparar radios entre sí, el modelo basta. Para newtons, hará falta un banco.

Y la tensión mecánica en el radio, porque la herramienta puede doblar lo que mide. El radio libre tomó 6,7 mm de flecha real sobre 125 mm a 7 Nm sin quedar curvado, lo que corresponde a 1.300 MPa en superficie: el límite elástico de un radio estirado, no más. En un radio montado y flojo, 7 Nm suben a 1.500 MPa. El ajuste correcto es 5 Nm: entre 800 y 1.100 MPa sea cual sea la tensión, 0,07 mm de lectura por cada 100 N alrededor de 1.000 N, y la llave en la zona de su rango donde su 4 % está garantizado. Ese 4 % de par se lee como un 8 % de tensión; es la incertidumbre dominante, y ninguna palanca la reduce. Para igualar una rueda, es suficiente.

Lectura esperada en el calibre a 5 Nm, holgura de 1,5 mm incluida, para un radio montado:

La curva se aplana hacia las tensiones altas: más allá de 1.200 N la herramienta distingue mal. Para mi rueda, ese no es el problema.

Acto VI: lo que queda por hacer

Todo lo anterior se apoya en un puñado de lecturas. El siguiente paso es hacer hablar a la herramienta en serio, en este orden.

1. Diez medidas a 5 Nm en un mismo radio, sin tocar la cabecilla, cursor puesto a cero entre cada una, mango de la llave siempre en la misma dirección. Es la dispersión real de la herramienta, la que cuenta.
2. Cinco medidas a 3 Nm en el mismo radio, para comprobar que la holgura de 1,5 mm no se mueve.
3. Un punto de control a tensión nula, en el radio libre, sujetando solo el tubo esta vez.
4. Un banco de calibración: un perfil, un radio de repuesto, un dinamómetro, de 600 a 1.200 N. Es lo que convertirá los milímetros en newtons sin pasar por el modelo.
5. Luego el mapa de los treinta y seis radios, la búsqueda de la tensión objetivo y la sustitución del radio roto, anotando exactamente dónde se rompió.

Si rompes radios en un motor de buje, quédate sobre todo con esto: el sonido no te dará el nivel, un tensiómetro de bicicleta clásico tampoco en 12G, y un radio montado se comporta de otra manera que un radio libre. El resto es chatarra, una llave de clic y un calibre.

La versión del 19 de septiembre, cerrada, con las bicis cargadas. Eje de Córdoba, caja de 2,30 × 1,61 m, lanza de 2 m con el mástil de elevación desmontado y tumbado encima. La que he elegido finalmente está más abajo: mide 1,30 m menos de alto.

El pliego de condiciones cabe en una frase

Cuando salimos en familia a escalar, a surfear o a caminar, la T5 se llena enseguida. La idea: sacar del habitáculo todo lo que estorba —la cocina, la nevera, el material, las bicis— y meterlo en un remolque pensado para ello, donde cada cosa tenga su sitio y se abra sin desembalar el resto.

Lo describí de un tirón, más o menos así: un eje de Mini; en el nivel cero, cajones de cocina a un lado (fregadero y hornillo pequeño), la nevera y su bombona de gas al otro; en el nivel de arriba, un gran cofre para la escalada, el surf y los bastones, cerrado por una tapa con bisagras de maletero que se mantiene abierta con amortiguadores de gas; y encima, tres huecos para nuestras tres bicis, subidas por una rampa desmontable guardada bajo el remolque.

Fue una IA (Claude) la que convirtió esa frase en un modelo 3D: un script de Python que construye el remolque pieza a pieza en Blender, con todas las cotas al principio del archivo. No abrí Blender para dibujarlo. Miré las imágenes, corregí, precisé… y fue justo al pasar de las imágenes a los números cuando el proyecto cambió.

Tres pisos, uno por uso

El principio es el de una cómoda: lo pesado abajo, lo voluminoso en medio, lo ligero y abultado arriba.

Las cotas principales de la versión elegida. El suelo está alto (0,75 m) porque la caja pasa por encima de las ruedas: eso es lo que permite una caja más ancha que la vía.

La planta baja, del lado de la acera, es la cocina. Una trampilla se levanta y hace de toldo. Debajo, dos cajones bajos salen hacia fuera: uno lleva el fregadero y su grifo, el otro un hornillo de dos fuegos. Su parte superior forma la encimera, a 0,95 m del suelo, la altura de una cocina. No es casualidad: la altura de esos cajones se calcula a partir de la altura del suelo, que depende del eje. Si se cambia de eje, la encimera sigue a 0,95 m. Encima, dos cajones para la vajilla y la despensa; al fondo, una columna para dos garrafas de 20 L, una bomba de 12 V y la batería.

Lado cocina, con las bicis puestas. Todo se abre sin descargar nada del techo.

Al otro lado, la nevera y el gas. Una nevera trivalente de 40 L (12 V, 230 V, gas) sobre una guía extraíble, para abrirla por arriba una vez fuera. Delante, un compartimento estanco hacia el interior y ventilado hacia el exterior —rejillas alta y baja en la puerta, rejilla en el suelo, porque el propano pesa más que el aire— para una bombona de 6 kg. Detrás, la mesa y las sillas plegables.

Lado nevera. La bombona queda separada del resto por un tabique, con su propia ventilación.

Arriba, el cofre. 2,26 m de largo por dentro: sitio para tumbar una tabla de surf de 7‘0, un crash pad, las cuerdas, las mochilas y los bastones. La tapa gira sobre tres bisagras de maletero y se queda abierta a 82° gracias a dos amortiguadores de gas.

El cofre abierto, sin las bicis; y no es una decisión de puesta en escena.

Fue lo primero que me enseñó el modelo, antes de cualquier cálculo: las bicis van sobre la tapa. Mientras estén ahí, el cofre no se abre. La cocina y la nevera, sí. Es una limitación que se asume (se carga el cofre antes que las bicis) o que se esquiva (una baca fija sobre montantes y trampillas laterales), pero no algo que uno quiera descubrir en el aparcamiento de la escuela de escalada.

Actualización del 21 de septiembre: limitación levantada. Las bicis han dejado la tapa, y el cofre se abre con las bicis cargadas; véase Las bicis bajan del techo.

El primer borrador era bonito y no demostraba nada

La primera versión daba imágenes limpias en una tarde. Eje de Mini, caja de 2,30 × 1,45 m, lanza de 1,35 m, eje colocado «un poco por detrás del centro para tener peso sobre la bola», rampa telescópica de cuatro tramos para subir las bicis. Todo parecía plausible.

Y ese es justamente el problema: un render limpio parece una validación. Nada en esas imágenes decía cuánto pesa el remolque, qué soporta el eje ni cómo se comporta a 130 km/h detrás de una furgoneta. Así que pedí lo que habría pedido un carrocero: el reparto de masas calculado de verdad, y una lanza lo bastante larga para maniobrar con facilidad con mi T5 larga.

El cálculo es un segundo script, independiente de Blender. Toma cada elemento —bastidor, lanza, paneles, cajones, nevera, agua, gas, material, bicis— con su masa estimada y su posición, y de ahí saca el centro de gravedad y la carga sobre la bola y sobre el eje, para cinco casos de carga: vacío; cargado sin bicis; cargado con bicis; a la vuelta, con el agua y la comida consumidas; y con bicis eléctricas.

Primer resultado: el remolque pesa 416 kg en vacío en su versión más ligera (bastidor de tubo de 50×30, contrachapado de chopo de 15 mm). Cargado con las bicis, 582 kg. La primerísima estimación, hecha a ojo antes de este cálculo, daba de 260 a 400 kg en vacío: la parte baja de la horquilla era muy optimista.

El eje de Mini no pasó el examen de los números

Mi eje es el tren trasero de un Mini clásico: una cuna, dos brazos tirados, conos de caucho a modo de muelles, ruedas de 10 pulgadas. Es compacto y ligero. También es el tren trasero de un coche de 650 kg, que normalmente soporta de 250 a 300 kg, y del orden de 450 kg como máximo.

Cargado con las bicis, el remolque pone 541 kg sobre su eje; 563 kg con bicis eléctricas. Es decir, entre un 20 y un 25 % por encima de lo que el tren debe soportar, de forma permanente y en autopista. Aun aligerando todo lo aligerable, con una cocina, una nevera, 40 L de agua y tres bicis no se baja del límite.

Tenía otras dos opciones a mano o a mi alcance: un tren trasero de Peugeot 205 o 206, y el de un Seat Córdoba 1.9D (primera generación). El cálculo los pasa a todos por el mismo tamiz:

Las cargas máximas son órdenes de magnitud; el valor real del «eje trasero» figura en la placa del fabricante del coche donante.

El mismo remolque sobre los cuatro trenes, generado cambiando una sola variable. La caja se ensancha sola para cubrir las ruedas. El Córdoba aparece dibujado con muelles separados apoyados en los brazos: no es el montaje del coche (véase la corrección).

Sobre el papel, gana el Córdoba: el mayor margen de carga, ruedas de 13 pulgadas que encajan mejor los baches y calientan menos los rodamientos a 130, una vía ancha. Y su suspensión debería trabajar dentro de su rango original: la parte trasera de un Córdoba diésel está dimensionada para cargas del mismo orden que las del remolque (de 430 a 610 kg según la carga). Una ventaja que no había visto venir: en este tipo de eje, la viga que une los dos brazos se retuerce cuando una rueda sube y la otra no; hace de barra estabilizadora, justo lo que se quiere con bicis subidas en alto.

Corrección: los muelles sí ocupan sitio

Añadido el 19 de septiembre de 2026, el mismo día de la publicación.

La primera versión de esta entrada decía aquí que los muelles helicoidales del Córdoba «no cuestan ni un centímetro de altura»: se alojarían entre el brazo de suspensión y la parte inferior del bastidor, en la treintena de centímetros que el neumático deja libre de todos modos bajo el suelo. Es lo que muestra el render de arriba, con sus muelles rojos.

Al releerlo, algo no me cuadró: en el coche, el muelle sube hasta dentro de la carrocería, muy por encima de la rueda. Una guía de desmontaje del Polo 6N, que comparte plataforma con el Córdoba 6K, lo confirma. El muelle rodea el amortiguador, los dos forman un conjunto, y su parte superior se atornilla en el maletero, en lo alto del paso de rueda, detrás de los guarnecidos. Abajo, un ojo horizontal lo fija a la viga, cerca del buje. La IA había razonado sobre un muelle separado apoyado en el brazo, como en otros ejes de este tipo, sin comprobarlo en este coche concreto. Y el render limpio hizo creíble la hipótesis: justo la trampa que se describe más abajo.

La consecuencia: entre el ojo inferior y la parte de abajo del bastidor quedan unos 38 cm, y el conjunto es claramente más largo. Asomaría en el nivel 0, justo debajo del cajón del hornillo por un lado y de la nevera por el otro. Cuatro salidas, aún sin decidir:

• separar muelle y amortiguador: conservar la viga y los brazos del Córdoba, apoyar el muelle solo en una copela sobre el brazo (atornillada mejor que soldada, al ser una pieza de suspensión) y otra bajo el bastidor, con un amortiguador corto montado aparte;
• torretas en el nivel 0, reorganizando la cocina y el lado de la nevera alrededor del eje;
• subir el suelo lo que sobresale: lo más sencillo, pero las bicis y el centro de gravedad suben otro tanto, y el viento lateral ya es el punto débil;
• volver al tren del 205, cuyas barras de torsión van dentro del tubo y cuyos amortiguadores van tumbados: ningún problema de altura, pero poco margen de carga con bicis eléctricas.

Para elegir necesito tres medidas del eje: la longitud del conjunto montado, la del muelle solo en reposo y la altura del ojo inferior respecto al centro de la rueda.

Actualización del 21 de septiembre: el cálculo ha reducido desde entonces esas tres medidas a una sola. Véase El Córdoba, reducido a una cota.

Aguantar la carretera detrás de la T5

La regla que se oye en todas partes: peso sobre la bola, o el remolque culebrea. Aún hay que saber cuánto. Apunté a un 7 % de la masa sobre la bola a plena carga. El cálculo coloca entonces el eje a 1,20 m de la parte trasera de la caja, 5 cm por delante del centro, donde el primer borrador lo había puesto 17 cm por detrás, a ojo. Según la carga, el peso sobre la bola se queda entre el 5,8 y el 7,6 %, es decir, de 31 a 45 kg, lejos de los 100 kg que admite el enganche de la T5.

Para el culebreo en sí, el cálculo usa un modelo clásico de dinámica vehicular: coche y remolque vistos desde arriba, unidos por la rótula, cada uno con su masa, su inercia y sus neumáticos que derivan. Se busca la velocidad a partir de la cual una pequeña oscilación, en lugar de amortiguarse, crece.

Resultado: por encima de 400 km/h. En todos los casos de carga, con todos los ejes, e incluso colocando el eje para tener un peso nulo o negativo sobre la bola.

Un resultado tan cómodo me hace desconfiar. Un modelo que responde «todo bien» le des lo que le des puede muy bien ser un modelo que no calcula nada. Así que lo probamos con un caso cuya respuesta se conoce: una caravana de 1,5 t detrás de una berlina de 1,4 t. El mismo modelo la hace perder el control hacia los 160 km/h con un 5 % sobre la lanza, 110 km/h con un 3 %, 80 km/h sin nada, lo que coincide con lo que se lee en todas partes sobre caravanas. El modelo sabe, pues, predecir una inestabilidad; si aquí no la encuentra, es porque la T5 pesa cuatro veces lo que el remolque. El perro mueve la cola, y no al revés.

El verdadero riesgo está en otra parte, y es mucho más banal: el viento lateral. Tres bicis a casi 3 m de altura, un costado de 1,20 m, una vía de 1,40 m. A la vuelta, con el agua y la comida consumidas, basta una racha de costado de 55 km/h para descargar la rueda de barlovento cuando se circula a 110 km/h; en curva, unos treinta. (Corrección del 21 de septiembre: la primera versión decía «unos 100 km/h». Esa cifra salía de un modelo casero, y solo vale para un remolque parado. La historia de esta corrección se cuenta más abajo.) La consigna es evidente: con previsión de viento fuerte, se circula más despacio, o las bicis viajan dentro de la T5.

Una lanza para recular sin pensarlo

Dar marcha atrás con un remolque corto es una prueba de nervios: se cruza antes de que uno entienda por qué. Lo que cuenta es la relación entre dos longitudes: la distancia de la bola al eje del remolque y la del eje trasero de la T5 a la bola (unos 1,10 m en una T5 larga). Cuanto mayor es esa relación, más despacio reacciona el remolque y más tiempo hay para corregir.

Con una lanza de 2 m, la bola queda a 3,10 m del eje: una relación de 2,8. Alargar más apenas aporta (3,0 con una lanza de 2,20 m) y cuesta longitud (4,35 m en total, ya 9,60 m para el conjunto con la T5).

Dos errores de cálculo, de paso, resultaron más instructivos que los buenos resultados. La primera versión del cálculo anunciaba que, con el volante a tope, el remolque formaría un ángulo de 164° con la T5; es decir, que la adelantaría. Una rotación en el sentido equivocado; corregida, el ángulo baja a 51°. La segunda anunciaba un contacto entre remolque y T5 a 55°, fuera cual fuera la longitud de la lanza. Sospechoso: si la longitud no cambia nada, no es ella la que limita. Era la propia cabeza de enganche, a 25 cm de la bola, que en realidad pasa por debajo del parachoques, como en cualquier remolque. Una vez quitado ese punto, apareció lo que limitaba de verdad: la apertura de la V de la lanza cerca de la bola.

De ahí la forma elegida: una viga central única en el primer metro detrás de la bola, y la V solo a partir de ahí. El primer contacto con la T5 se va entonces más allá de los 100° de articulación. Con el volante a tope solo se usan 51.

Con el volante a tope, en régimen estable: 51° entre la T5 y el remolque, con buen margen antes de cualquier contacto. El remolque recorta la curva cerca de 1 m por dentro de la trayectoria de las ruedas traseras de la T5.

Un detalle que el modelo hace evidente y en el que no habría pensado: el remolque (1,61 m) es más estrecho que la T5 (1,90 m). En línea recta, no se ve por los retrovisores. Una cámara de marcha atrás inalámbrica, o dos piquetas testigo en las esquinas traseras, forman parte del proyecto.

Enganchado. Las bicis sobresalen un metro por encima del techo de la T5: conviene recordarlo ante las barreras de los aparcamientos.

Subir tres bicis a casi 2 m

Actualización del 21 de septiembre: esta sección describe una solución abandonada dos días después. La dejo, porque el razonamiento que mata la rampa sigue siendo válido, y porque la buena respuesta era dejar de subir las bicis. Véase Las bicis bajan del techo.

La rampa de mi idea inicial murió por un simple cálculo de trigonometría. Las bicis descansan a casi 1,90 m; para una pendiente de 25°, ya empinada para empujar una bici, hace falta una rampa de más de 4,40 m: cuatro tramos telescópicos, una pata en medio para que no se doble y una bici eléctrica de 25 kg que empujar con los brazos estirados. Factible entre dos con bicis normales, penoso en otro caso.

La alternativa la propuse yo, y es la que nos quedamos: un mástil desmontable, un pescante que gira en lo alto del mástil y una polea en la punta. El mástil, en dos tramos de aluminio de 1,50 m, se encaja en una funda soldada sobre la viga de la lanza, justo delante de la caja. El pescante, de 1,45 m de alcance, cubre los tres canales y un punto de recogida en el suelo junto al remolque. Un torno manual en el mástil, un cable que pasa por una polea arriba y luego por la de la punta del pescante, y un balancín enganchado al sillín y a la potencia de la bici para que suba horizontal.

La bici de la derecha, subiendo. Desmontados, el mástil y el pescante se tumban sobre la lanza (se ven en las otras vistas).

Del modelo salieron dos limitaciones. La altura, primero: para que una bici apoyada en su canal pase bajo la polea, balancín incluido, el mástil tiene que llegar a 3,45 m. Y el orden de carga: primero la bici del medio. Si no, habría que pasarla por encima de otra, y ningún mástil razonable llega tan alto. Por último, una obviedad que más vale escribir: no se levanta nada con el remolque desenganchado y mal calzado.

Actualización del 21 de septiembre: el Mini vuelve por partida doble, y el viento pasa por la biblioteca

Dos días después de la publicación. No hay nada construido, así que todo puede moverse todavía, y se ha movido.

¿Y con dos ejes de Mini?

Tras la publicación me sugirieron una idea que había descartado demasiado deprisa: puesto que una cuna de Mini no basta, poner dos, una detrás de otra, con separadores de rueda de 5 cm. El argumento cabía en una línea: la carga se duplica, el comportamiento en carretera es muy superior y la resistencia al viento lateral, mucho mayor.

Añadir la variante al modelo costó una línea de parámetros, como con los demás ejes. Quedaba poner cifras a cada afirmación.

• La carga: cierto, y mejor de lo previsto. Cada cuna soporta 290 kg, es decir 145 kg por rueda, más o menos lo que carga una rueda trasera de Mini en carretera. Cada cono de caucho trabaja, pues, donde fue pensado para trabajar. El margen pasa del −25 % con una sola cuna a un +33 %, bicis eléctricas incluidas.
• El comportamiento: cierto, por una razón precisa. Dos ejes separados 80 cm se oponen al giro del remolque sobre sí mismo (la guiñada) mucho más que uno solo: el efecto de recuperación de los neumáticos se multiplica por 4,7. Es lo que calma un remolque tras una racha o el paso de un camión.
• El viento lateral: empate. El vuelco solo depende de dos cosas, el ancho de vía y la altura del centro de gravedad. El tándem gana porque sus ruedas de 10 pulgadas permiten un suelo 11 cm más bajo, y pierde otro tanto porque su vía sigue siendo más estrecha que la del Córdoba.
• «La carga se duplica»: sí para el eje, no para el remolque. Lo que limita la carga útil es la masa máxima declarada en la homologación: por encima de 750 kg hacen falta frenos y otro permiso. El tándem compra margen y vida útil, no kilos que llevar.

La variante con dos cunas de Mini. El resto del modelo se adaptó solo: caja de 1,46 m, suelo a 0,64 m, bicis a 2,82 m en lugar de 2,93.

Y tiene un precio. El arrastre lateral de los neumáticos, primero: para pivotar, un remolque de dos ejes tiene que hacer deslizar sus ruedas de lado. Con la dirección a tope hacen falta 52 kg de empuje lateral en la bola. La T5 ni se entera; yo sí, el día que quiera moverlo a mano en una parcela de camping. Después, un defecto conocido de este montaje, que encontré descrito por los fabricantes de ejes: dos suspensiones independientes no se reparten la carga por sí solas. Es la altura de la bola de la T5 la que fija el asiento — 5 cm de diferencia, y el eje delantero pierde 51 kg mientras el trasero gana 39 — y sobre un resalte un solo eje se lo lleva casi todo. Los fabricantes rebajan la capacidad de estos ejes en torno a un 20 % cuando los montan por parejas; aquí cada uno trabaja al 65 % de su carga, así que la regla se cumple. Por último, 43 kg más en vacío y cinco neumáticos de 10 pulgadas por encontrar, una medida que se ha vuelto rara.

El viento: tres objeciones y luego el método de los puentes

El pasaje sobre el viento lateral, más arriba, estaba mal. No en su conclusión — las bicis en el techo siguen siendo el punto débil — sino en sus cifras. La historia de la corrección me enseñó más que la corrección misma.

El primer cálculo era un modelo escrito a mano por la IA: el empuje del viento sobre el costado del remolque, como sobre un panel. Puse tres pegas.

«He visto remolques altos, sin suspensión, que no sufren con el viento.» Comprobado: la misma caja, sin las bicis, aguanta una racha mucho más fuerte. El problema no es la altura de la caja, son las bicis: subidas a 2,30 m, suponen ellas solas el 41 % del esfuerzo que intenta tumbar el remolque. De paso, el modelo resultó demasiado optimista. Olvidaba que un remolque en marcha no recibe el viento de costado sino de tres cuartos, sumado a su propia velocidad, y que una caja atacada en diagonal recibe mucho más empuje que un panel atacado de frente.

«Una bici no es un panel macizo.» Exacto. Contada pieza a pieza — neumáticos, llantas, radios, cuadro — una bici solo ofrece al viento el 34 % de su silueta. Y el aire pasa a través: sufre resistencia, no el efecto de ala que sufre la caja. Las dos bicis de sotavento quedan además resguardadas por la primera.

«Te olvidas de la T5 delante, que abre camino.» Ahí me sorprendió ser yo quien lo pensara. Respuesta: la T5 sí resguarda el remolque… con viento flojo. Su estela se va con el viento, no por el eje de la carretera. A 110 km/h, el abrigo es completo por debajo de 20 km/h de viento de costado, se pierde a medias a 40 y es casi nulo a 60. Y las bicis sobresalen de su techo de todas formas.

Tres correcciones para tres objeciones: íbamos a tientas. Así que pregunté lo que debería haber preguntado desde el principio: ¿cómo lo hace la gente que se dedica a esto? Bastaron diez minutos de búsqueda. El método existe, está publicado y en acceso abierto: es el de Baker y Soper (2018), que sirve para decidir a partir de qué racha se cierra un puente a los camiones. Cabe en tres líneas, se apoya en coeficientes medidos en túnel de viento y a escala real, y ya contenía mi tercera objeción: un remolque medido detrás de su camión solo gana alrededor de un 10 % de abrigo.

Rehecho con ese método, a la vuelta y con las bicis en el techo: basta una racha de 55 km/h para descargar la rueda de barlovento cuando se circula a 110 km/h, 61 km/h cuando se circula a 90. Remolque lleno y sin bicis: 85. Son velocidades de viento a la altura del remolque; la previsión anuncia rachas medidas a 10 m de altura, y en terreno despejado el viento es aproximadamente una cuarta parte más flojo a ras de carretera. El método clasifica cada vehículo por una «velocidad característica»: con sus bicis, mi remolque es más vulnerable que un autobús de dos pisos vacío, el primer vehículo que se detiene cuando se levanta el viento en el puente de Queensferry, en Escocia. La consigna práctica: a partir de 80 km/h de rachas previstas, se baja a 90, o las bicis viajan dentro de la T5.

El modelo casero daba 58 km/h en lugar de 55: el orden de magnitud correcto, alcanzado tras tres parches. Una parte del cálculo sigue siendo de cosecha propia, y así está señalada: el tratamiento de las bicis, a falta de medidas publicadas sobre bicis colocadas en un techo.

Cuándo se va

Lo que quería saber, en el fondo, no es lo que dice el código de circulación: es dónde están los límites reales. El cálculo saca tres, reunidos en un gráfico.

Las tres maneras de irse, para la variante con dos cunas de Mini (rótulos del gráfico en francés: vent = viento, virage = curva, louvoiement = culebreo). El Córdoba da las mismas curvas con pocos km/h de diferencia. Pulsar para ampliar.

• El viento. Lleno y sin bicis, nada se va con tiempo normal: harían falta rachas previstas de 110 km/h para inquietarlo a 130 km/h. Con las bicis, el margen se funde.
• La curva. El remolque vuelca entre 0,56 y 0,64 g de aceleración lateral, según la carga. Es antes de que los neumáticos deslicen en seco (0,8 g), pero después en mojado (0,5 g). Dicho de otro modo: en seco se tumba sin haber deslizado; en mojado, el conjunto desliza primero. Con las bicis, 0,58 g son 61 km/h en un ramal de 50 m de radio.
• El culebreo. No hay velocidad crítica detrás de la T5, ni siquiera con 120 kg mal colocados al fondo. La curva verde es el caso de control, una caravana de 1,5 t detrás de una berlina del mismo peso: cruza el cero hacia los 115 km/h.

El Córdoba, reducido a una cota

Quedaba el problema que dejó abierto la corrección: el conjunto muelle-amortiguador que sube hacia la caja. Al mirar qué hay en ese punto dentro del remolque, la restricción primero se endureció: el cajón del hornillo a un lado y la guía de la nevera al otro barren el suelo justo encima. No se tolera ningún saliente, ni siquiera un abombado.

Luego el cálculo la aflojó. Bajo la carga del remolque (290 kg por rueda), el muelle de origen se comprime y el conjunto ya solo mide unos 41 cm. Su cabeza puede alojarse entonces dentro del espesor del bastidor, 45 mm por debajo del suelo, sobre una simple pletina taladrada soldada entre dos largueros.

Con una condición, que es la única incógnita que queda: que el ojo inferior del conjunto esté a menos de 1,5 cm por encima del centro de la rueda. Lo he supuesto 3 cm por debajo; se mide en cinco minutos sobre el coche, antes de desmontarlo. Si la cota sale mal, existen conjuntos roscados, regulables en altura, homologados para este coche.

El montaje del Córdoba tal como lo dibuja ahora el cálculo: el conjunto termina dentro del bastidor, y dos soportes bajan a buscar las articulaciones de los brazos.

El verdadero trabajo de calderería está en otra parte, y no lo había visto. Como la caja pasa por encima de las ruedas, el bastidor queda a 67 cm del suelo, mientras que las articulaciones de los brazos del eje están a 33 cm. Hacen falta, pues, dos soportes descendentes de 35 cm, que aguantan alrededor de 1,6 kN·m en un bache cogido deprisa: cajones de chapa de 5 mm, un tirante hacia delante y un tubo entre los dos para los esfuerzos laterales.

Este montaje sigue siendo mucho más sencillo que el tándem: un tren, cuatro puntos de fijación, ningún ajuste, neumáticos que se encuentran en cualquier parte y un remolque que todavía se mueve a mano. El tándem tiene más margen y un suelo más bajo. No me he decidido.

Segunda actualización del 21 de septiembre: todo baja

El mismo día, unas horas más tarde. Dos preguntas de diseño han hecho más por el remolque que todos los refinamientos de cálculo de la mañana.

Hundir el eje en la caja

Desde el principio, la caja pasaba por encima de las ruedas. Eso le permitía ser más ancha que la vía, y también dejaba el suelo encaramado a 75 cm. De ahí mi pregunta: ¿por qué no hacer como el propio Seat, o como cualquier furgoneta? Bajar el suelo entre las ruedas, dejar que estas suban dentro de unos pasos de rueda en el interior de la caja, y construir los cajones alrededor.

El suelo puede bajar hasta casi rozar la viga que une las dos ruedas: 0,51 m en lugar de 0,75. Todo lo demás baja en bloque, 24 cm. Y las dos dificultades del montaje, las de la actualización de esta mañana, desaparecen de golpe:

• los soportes de 35 cm que debían bajar del bastidor hasta las articulaciones de los brazos se quedan en 10: los apoyos se atornillan casi directamente bajo los largueros, como en el coche;
• la cabeza del conjunto muelle-amortiguador ya no tiene que caber bajo un suelo. Sube dentro del paso de rueda, exactamente como en el maletero del Seat. La famosa cota por medir ya no condiciona nada: solo fija la altura del paso de rueda.

El precio es carpintería y bastidor. Dos pasos de rueda de 73 × 36 cm, de 20 cm de alto, se llevan un centenar de litros de 2 400. Cada portón lateral recibe una muesca a la altura de la rueda. Y el bastidor deja de ser un rectángulo: la rueda está en el camino de los largueros exteriores, así que dos largueros pasan por dentro de las ruedas y unos travesaños sostienen los costados por delante y por detrás.

La distribución se reorganiza con una regla sencilla: lo que se conforma con poca altura va encima de la rueda, lo que la necesita va delante o detrás. El cajón del hornillo mide 22 cm de alto. Ya estaba a la altura del eje, y ahí se queda, apoyado en el paso de rueda. El fregadero gana un cajón hondo, con sitio para un bidón de aguas grises debajo. La nevera deja la zona del eje y se va atrás; y como todo ha bajado, su tapa pasa de 1,27 m a 1,03 m: por fin se puede meter el brazo.

Lado cocina. El cajón del hornillo va apoyado en el paso de rueda; el fregadero y la columna de agua, a un lado y a otro, bajan hasta el nuevo suelo.

Lado nevera. La nevera ha pasado atrás; encima de la rueda, lo que se guarda en plano.

En carretera: el centro de gravedad baja 21 cm, el vuelco en curva pasa de 0,58 a 0,71 g, y la racha límite a 110 km/h de 55 a 66 km/h.

La idea no se suma a la de la mañana. Con dos ejes de Mini, los pasos de rueda medirían 1,45 m de largo, el 63 % de cada costado: casi no quedarían cajones bajos.

Las bicis bajan del techo

Segunda pregunta: ¿por qué empeñarse en subir tres bicis a casi 2 m? Podrían ir sobre un soporte detrás del remolque. O dos detrás y una delante, sobre la lanza.

En cuanto al viento, no hay color. Colocadas de través a un metro del suelo, el viento de costado las coge de punta, y ya no están encaramadas: casi no cuentan en el vuelco. Pero es el peso sobre la bola lo que decide entre las ubicaciones, y ahí el cálculo no dijo lo que yo esperaba.

En el centro, el peso sobre la bola para cada ubicación: un punto por estado de carga, entre los límites del 4 y el 10 % (rótulos del gráfico en francés). Pulsar para ampliar.

• Tres bicis detrás: de 40 a 60 kg a metro y medio por detrás del eje. Según el remolque vaya lleno o vacío, con o sin bicis, el peso sobre la bola va del 3 al 10 % de la masa. Demasiado poco a la vuelta con bicis eléctricas, demasiado cuando se circula sin bicis. Es exactamente lo que los caravanistas reprochan al portabicis trasero.
• Tres bicis sobre la lanza: el defecto contrario. La bola se descarga en cuanto se circula sin bicis.
• Dos detrás, una delante: la bici de delante compensa las de detrás. El peso sobre la bola se mantiene entre el 5 y el 8 % en todos los casos, tan formal como con las bicis en el techo. La más pesada va delante.

El culebreo no se mueve. Tres bicis al fondo aumentan un 17 % la inercia de giro del remolque, y detrás de una T5 cuatro veces más pesada eso no cambia nada. Detrás de una berlina sería otra historia.

El portabicis lo haré yo mismo, y es de una sencillez que da gusto: una plataforma, y una mordaza que desliza sobre un raíl en el eje del remolque. Se colocan las bicis de través, se avanza la mordaza hasta apretar los cuadros contra unos topes fijados a la caja, se pone el pasador, se cierra el candado — la mordaza hace de antirrobo — y luego se atan las ruedas con cinchas. El modelo sacó a la luz dos detalles. Hay que girar el manillar un cuarto de vuelta. Y aun con las bielas en vertical, el pedal sobresale 14 cm: por eso los topes van separados 15 cm de la caja, si no es el pedal el que toca antes que el cuadro.

El portabicis trasero. La mordaza desliza sobre el raíl perforado, en el eje; pasador naranja y candado en el carro; cinchas naranjas en las ruedas; luces y matrícula repetidas detrás de las bicis.

El mismo principio sobre la lanza, para la bici más pesada. Con la dirección a tope queda lejos de la T5.

Lo que esto cambia en el uso importa más que las cifras. El mástil, el pescante y el torno de la sección Subir tres bicis a casi 2 m ya no existen: una bici se carga a la altura de la cintura. Y la primera lección del modelo — las bicis van sobre la tapa, mientras estén ahí el cofre no se abre — también cae.

El cofre se abre con las bicis cargadas.

La versión elegida

Esta vez me he decidido: tren de Córdoba, caja rebajada, dos bicis detrás y una sobre la lanza.

Enganchado. Todo el conjunto pasa por debajo del techo de la T5.

A 0,79 g, el umbral de vuelco alcanza el límite de adherencia de los neumáticos en seco: el remolque deslizaría antes de volcar. Y con 1,63 m, todo el conjunto pasa bajo el techo de la T5, es decir, bajo las mismas barreras de aparcamiento que ella.

El precio: 74 cm más de longitud, luces y matrícula que repetir detrás de las bicis, bicis expuestas a las salpicaduras de la carretera, y un bastidor más complicado de soldar que un rectángulo.

Caja sobre las ruedas frente a caja rebajada, para el Córdoba y para los dos ejes de Mini (rótulos del gráfico en francés). Pulsar para ampliar.

Lo que me llevo

Un render no es una comprobación. Las primeras imágenes eran convincentes y descansaban sobre un eje sobrecargado un 20 %. Lo que hizo avanzar el proyecto no fue el modelo 3D, fue la pregunta «¿cuánto pesa, y dónde?».

Desconfiar de un resultado demasiado cómodo. «Estable por encima de 400 km/h» podía ser un fallo. La única forma de saberlo era pasar el mismo cálculo por un caso con respuesta conocida. Es el mismo reflejo que con una suma de cotas que cuadra: la coherencia no es una prueba.

Comprobar con la pieza real. El error de los muelles no vino de un cálculo ni de un render, sino de una generalización («en este tipo de eje, el muelle va apoyado en el brazo») que nunca se contrastó con el coche. Bastó con acordarse del coche para verlo, y una guía de desmontaje lo confirmó.

Un error absurdo es una buena noticia. 164° de articulación se ve enseguida. Los errores peligrosos son los que dan una cifra plausible, como esos 55° que no dependían de la longitud de la lanza, y que solo ese detalle delataba.

Parametrizarlo todo. Cambiar de eje costó una línea: la caja se ensanchó, el suelo subió, los cajones de cocina se acortaron para mantener la encimera a 0,95 m y el cálculo recolocó el eje. Sobre el papel, habría sido una semana de goma de borrar.

Buscar el método publicado antes de escribir uno propio. (Añadido el 21 de septiembre.) El cálculo del viento se corrigió tres veces antes de que preguntara qué decía la bibliografía. La respuesta cabía en tres líneas y se apoyaba en medidas; el modelo casero, en hipótesis apiladas. Una IA escribe un modelo físico plausible en treinta segundos, y ahí está el peligro: nada la empuja a ir a ver si ya existe uno.

Una objeción de quien ha visto la carretera vale una revisión de código. No sé calcular una sustentación lateral. Pero «he visto remolques altos que no sufren con el viento», «una bici no es un panel», «hay una furgoneta delante»: cada una de esas observaciones encontró un fallo real. Hay que hacerlas, y exigir que se comprueben con el cálculo en lugar de rebatirse con un argumento.

La palanca era la arquitectura, no el cálculo. (Añadido el 21 de septiembre por la tarde.) Una mañana refinando el modelo de viento movió el resultado unos pocos km/h. Dos preguntas de diseño — por qué la caja es tan alta, por qué las bicis van en el techo — lo llevaron de 55 a 91. La IA optimizaba con aplicación el proyecto que yo le había dado; nunca lo puso en duda. Eso me tocaba a mí, y he tardado dos días.

Lo que queda por hacer

• Medir dos cotas en el Córdoba, con el coche apoyado en sus ruedas: la altura de la viga del eje (fija los 43 cm bajo el bastidor, y con ello todo lo demás) y la del ojo inferior del conjunto muelle-amortiguador (fija la altura del paso de rueda). De paso, anotar la posición de las articulaciones de los brazos y la plantilla de taladros de sus soportes.
• Dibujar el bastidor de verdad: dos largueros por dentro de las ruedas, travesaños que sostienen los costados, un puente de tubos sobre cada rueda, y la estanqueidad de los pasos de rueda.
• Probar de verdad la bici de la lanza: tiene que convivir con la rueda jockey y con la puerta del cofre del gas.
• Leer la carga máxima del eje trasero en la placa del fabricante del Córdoba, y revisar silentblocks y rodamientos.
• Pesar. Las masas del cálculo son estimaciones. El remolque terminado pasará por una báscula, lanza y eje por separado, y el eje todavía podrá desplazarse unos centímetros sobre sus largueros antes de la soldadura definitiva.
• El papeleo (normativa francesa). Cargado, el remolque superará los 500 kg de MMA: necesitará su propio permiso de circulación y, por tanto, una homologación individual (RTI) ante la DREAL al ser de construcción artesanal. Quedándose por debajo de 750 kg, no son obligatorios los frenos y basta el permiso B. Queda por confirmar, junto con la masa remolcable y la MMC que figuran en la documentación de la T5.
• Construir ligero. Cada kilo ganado en la caja es un kilo de margen en el eje y un poco más de estabilidad con viento de costado.

Preguntas frecuentes

¿Se puede usar un eje de Mini para un remolque?

Sí, para un remolque pequeño y ligero: es compacto, bajo, y las ruedas de 10 pulgadas permiten un suelo bajo. Pero es el tren trasero de un coche de 650 kg, previsto para del orden de 450 kg como máximo. Un remolque equipado (cocina, nevera, agua, bicis) supera con facilidad los 500 kg sobre el eje.

¿Cuánto peso sobre la lanza hay que buscar?

Entre el 5 y el 10 % de la masa del remolque, nunca menos del 4 % ni más de lo que admite el enganche del coche (a menudo de 75 a 100 kg). Aquí, un 7 % a plena carga, unos 44 kg. Se consigue colocando el eje, no añadiendo lastre.

¿Un eje con muelles helicoidales ocupa más sitio?

Depende del montaje. Un muelle separado, apoyado en el brazo, cabe bajo el bastidor cuando la caja pasa por encima de las ruedas. Un conjunto muelle-amortiguador, como en el Seat Córdoba 6K o el VW Polo 6N, sube por encima de la rueda: hay que hacerle sitio en la caja, subir el suelo o sustituirlo por un muelle y un amortiguador separados. Conviene comprobarlo antes de concluir: bajo carga el muelle se comprime, y en mi remolque el conjunto de origen acaba cabiendo dentro del espesor del bastidor, a falta de una cota.

¿Qué longitud de lanza para dar marcha atrás con facilidad?

Lo que cuenta es la relación entre la distancia bola–eje del remolque y la distancia eje trasero–bola del coche. Por encima de 2,5, la marcha atrás se vuelve cómoda; aquí, 2,8 con una lanza de 2 m. La forma importa tanto como la longitud: una viga central única cerca de la bola evita que la V de la lanza toque el coche en los giros cerrados.

¿Puede culebrear un remolque ligero detrás de una furgoneta?

Es muy poco probable si la furgoneta pesa bastante más: el cálculo no encuentra inestabilidad por debajo de 400 km/h con una T5 de 2,4 t y un remolque de 0,6 t. El riesgo práctico es el viento lateral, y sobre todo lo que se sube al techo.

¿Con qué viento puede volcar un remolque?

Depende de su masa, su vía, su altura y la velocidad a la que se circule. El método de referencia es el de Baker y Soper (2018), que se usa para las restricciones de tráfico en puentes. Para mi remolque de 0,6 t: 85 km/h de racha de costado a 110 km/h sin nada en el techo, 55 km/h con tres bicis. Son velocidades de viento a la altura del remolque; las rachas previstas, medidas a 10 m, son alrededor de un 40 % más fuertes.

¿Son mejores dos ejes que uno en un remolque pequeño?

Cargan más y mantienen mejor el rumbo: los neumáticos se oponen casi cinco veces más a la guiñada. A cambio, el remolque arrastra las ruedas al maniobrar y ya no se mueve a mano, pesa más en vacío, y si los dos ejes son independientes (suspensión de caucho), es la altura de la bola la que fija el reparto de la carga: hay que remolcarlo bien nivelado.

Pequeño glosario

Bogie, tándem — Dos ejes próximos montados uno detrás de otro bajo el mismo remolque.

Conjunto muelle-amortiguador — Un amortiguador con el muelle montado a su alrededor; los dos se montan y desmontan de una pieza. Su cabeza se fija en la carrocería del coche.

Carga sobre la lanza — La carga vertical que el remolque ejerce sobre la bola de enganche. Demasiado baja o negativa, aligera la parte trasera del coche y favorece el culebreo.

Culebreo — Oscilación del remolque de un lado a otro que, por encima de una velocidad crítica, crece en lugar de amortiguarse.

Arrastre lateral (ripado) — Deslizamiento lateral forzado de los neumáticos cuando un remolque de dos ejes gira: sus dos ejes no pueden seguir el mismo círculo.

Eje torsional — Eje en el que los dos brazos tirados están unidos por un travesaño que se retuerce cuando las ruedas no se mueven a la vez; hace de barra estabilizadora.

Guiñada — Giro de un vehículo alrededor de un eje vertical: el morro va a la izquierda, la cola a la derecha.

RTI — Réception à titre isolé: homologación individual, por la administración regional francesa (DREAL), de un vehículo construido o modificado como unidad.

Lanza — La parte delantera del remolque, del chasis a la cabeza de enganche.

Vía — Distancia entre los centros de las dos ruedas de un mismo eje.

Referencias y copias locales

• El modelo completo, regenerable: scripts de Blender y Python, remorque.blend, cálculo detallado (comentarios y nombres de archivo en francés) — remorque-famille.zip
• El cálculo solo, legible en línea (en francés): CALCULS.md
• Los gráficos, en vectorial (rótulos en francés): limites.svg, architecture.svg, velos.svg
• Baker y Soper (2018), The calculation of the overturning wind speed of large road vehicles at exposed sites (en inglés, acceso abierto): el método de cálculo del viento, y la medida de un remolque detrás de su camión
• Mechanical Elements: los ejes de suspensión de caucho montados por parejas (en inglés): por qué no se reparten la carga
• Guía de Autodoc: cambiar el amortiguador trasero de un VW Polo 6N1 (en inglés): la fuente de la corrección sobre los muelles
• La entrada anterior: otra pieza diseñada dialogando con una IA, y la trampa de la suma de cotas que cuadra

El problema de la primera contribución

Todo el mundo da el mismo consejo: «busca una incidencia etiquetada good first issue». Es un buen consejo y no funciona demasiado bien, por una razón sencilla: esas tareas son o bien triviales hasta el punto de no enseñar nada, o bien ya las ha cogido alguien más rápido.

Lo que funciona mejor, creo, es partir de lo que uno tiene y los demás no. En mi caso: un teléfono viejo que había decidido hacer funcionar con Linux, y por tanto hardware físico sobre el que ejecutar código que otros escriben a ciegas.

Es una ventaja más rara de lo que parece. Muchos desarrolladores trabajan sobre controladores de hardware que no poseen, fiándose de fichas técnicas y de informes de usuarios. Quien tiene el aparato conectado en su escritorio puede responder preguntas que nadie más puede zanjar.

El hilo: una tarea bien delimitada

El proyecto postmarketOS mantiene una lista de tareas por aparato. Para el mío, una incidencia paraguas titulada «Camera TODOs» enumeraba una docena de puntos, todos marcados salvo uno:

imx355 driver (front camera) is missing features for libcamera, makes the later complain (e.g. when running cam -l)

Alcance claro, síntoma reproducible, un comando para constatarlo. Exactamente lo que se busca.

Ejecuté el comando en el teléfono. Se quejó, tal como anunciaba. Abrí el repositorio de libcamera para escribir la corrección.

Y la entrada ya estaba ahí.

Primera lección: una incidencia abierta no está necesariamente abierta

El soporte del sensor se había añadido el 17 de julio de 2026, por un ingeniero de Raspberry Pi. La versión instalada en mi teléfono era del 10 de julio.

Siete días de diferencia. El aviso que veía no era una carencia del proyecto, era un desfase entre la versión publicada y el repositorio.

Es una confusión fácil de cometer, y merece un reflejo: antes de escribir código, comprobar que el problema sigue existiendo aguas arriba, no solo en la propia máquina. Se hace con dos peticiones.

F="src/libcamera/sensor/camera_sensor_properties.cpp"
for ref in v0.7.2 master; do
  echo -n "$ref: "
  curl -s ".../repository/files/$(urlencode $F)/raw?ref=$ref" | grep -c '"imx355"'
done
# v0.7.2: 0
# master: 1

Dos tareas de tres se habían evaporado. Podría haberme detenido ahí con la sensación de haber perdido la tarde. Salvo que, al leer la entrada recién añadida, algo no cuadraba.

Segunda lección: la revisión no ve las tablas

La entrada asociaba dos patrones de prueba a valores numéricos. Pero el controlador del sensor, en el núcleo, define esos valores en el orden inverso. «Color sólido» y «barras de color» estaban intercambiados.

Lo verifiqué tres veces, por caminos independientes:

Y busqué activamente el contexto en el que el autor habría tenido razón: su empresa mantiene su propio núcleo, a veces con controladores distintos. Lo comprobé: mismo orden en ambos árboles. El error era real, también en su propio hardware.

Lo interesante de esta historia no es el error. Es que el commit había sido revisado por cuatro personas, incluido el mantenedor del proyecto, y llevaba la marca de «probado» de una quinta.

¿Cómo se les escapan a cinco personas competentes dos valores intercambiados?

Porque no hay lógica que revisar. Es una correspondencia entre dos documentos que no viven en el mismo repositorio: una tabla por un lado, una lista de cadenas en el núcleo por el otro. Para verificarla hay que abrir ambos ficheros lado a lado, o tener el aparato a mano. Y «probado» significaba aquí la cámara funciona, apunto y obtengo una imagen — lo cual es cierto, y nunca ejercita los patrones de prueba, que son una herramienta de diagnóstico.

El resto de la entrada era correcto. El tamaño del fotosito, los retardos del sensor: todo lo que se ejercita a diario estaba bien. Solo la parte que nadie hace funcionar estaba mal.

Ahí es donde poseer el aparato se vuelve una ventaja decisiva. No porque yo sea mejor, sino porque era el único que podía plantearle la pregunta al hardware.

Lo que debe contener un parche de dos líneas

El parche son dos líneas. Su mensaje de commit son treinta, deliberadamente.

Un revisor no debe tener que ir a buscar nada. Así que incluí la tabla del controlador del núcleo citada tal cual, la salida del comando que interroga a mi teléfono, la consecuencia concreta en una frase — pedir un color sólido produce barras de color, y viceversa — y el argumento de coherencia con los dos sensores correctamente descritos.

Y me adelanté a la pregunta que iba a llegar: «¿y las demás entradas, están mal también?». No, y lo verifiqué controlador por controlador: otros dos sensores sí usan el orden inverso, porque sus controladores lo definen así. Una frase en el mensaje ahorra un ida y vuelta de tres días.

Fixes: a1db25dabaee ("libcamera: camera_sensor: Add Sony IMX355 sensor properties")

git rev-parse --short=12 <referencia>

El trabajo de verdad, y el valor que no se puede demostrar

Quedaba algo realmente ausente: el segundo sensor del teléfono no figuraba en ninguna parte. Ni en la biblioteca, ni en el núcleo oficial — su controlador se escribió en un fabricante de chips hace ocho años y nunca se envió aguas arriba.

Tomé los valores del aparato y del código del controlador. Tres se deducen con rigor. El cuarto no: es un parámetro que se lee en una ficha técnica, y las fichas técnicas de estos sensores no son públicas.

Intenté respaldarlo. Encontré un fichero de configuración, en mi propio teléfono, que declaraba exactamente el valor que había supuesto. Excelente noticia durante unos tres minutos — hasta que comprobé si era independiente. No lo era: los diez ficheros equivalentes del proyecto declaran el mismo valor, incluso para sensores de tres fabricantes distintos. No eran diez mediciones concordantes, era un valor por defecto copiado diez veces.

Así que lo escribí tal cual en el mensaje del commit: este valor sigue lo documentado para los sensores de la misma familia. No «según la ficha técnica», ninguna formulación que sugiriera una medición. Un revisor que tenga la documentación lo corregirá en un mensaje, y está muy bien así.

Vestir una incertidumbre es la forma más eficaz de perder la confianza de un proyecto en el primer parche.

La predicción que fallé

Leyendo el código, había entendido qué provocaba la ausencia de ese sensor: sin él, la biblioteca deja de convertir la ganancia de la cámara. Escribe un número de ajuste donde debería escribir un factor de amplificación, y relee el número como si fuera el factor. El bucle de exposición automática queda falseado en ambos sentidos.

De ahí saqué una predicción: tras la corrección, las fotos con poca luz deberían mejorar. Monté un protocolo limpio — teléfono fijado y nunca movido, mediciones objetivas de luminancia y ruido, una serie antes y una serie después.

Resultado: 39,2 % de luminancia antes, 38,1 % después. Nada.

La explicación es aritmética, y la había señalado como riesgo antes de lanzar la prueba — sin sacar la consecuencia, que fue el error.

El error solo es enorme con ganancia alta. Mi escena de prueba tenía una zona blanca saturada: la exposición automática tenía luz de sobra, se mantenía cerca de cero de ganancia, y en ese punto ambas fórmulas dan el mismo resultado.

El parche sigue siendo correcto, y funciona — lo verifiqué de otro modo. Tras la instalación, la biblioteca no emite ningún aviso para ese sensor, mientras que el otro sensor del teléfono, sin corregir, los emite todos. Un testigo negativo limpio.

Pero no demostré una mejora visible, así que no lo escribiré. La marca de «probado» que adjuntaré dirá que el sensor ya está reconocido. No que las imágenes sean mejores.

Es una distinción que suena quisquillosa y no lo es. Un razonamiento correcto sobre un mecanismo no dice nada de su magnitud en las condiciones de la prueba. Tenía el mecanismo; no tenía la magnitud.

El hallazgo que no estaba en ninguna lista

Durante todo este trabajo, la aplicación de cámara se congelaba con regularidad. Una molestia, que al principio sorteaba reiniciando.

Luego la instrumenté, a falta de algo mejor. Y resultó que una sola línea, emitida una vez en la inicialización, lo explicaba todo:

Importing input DMABuf failed, falling back to upload

El procesamiento de imagen se hace en el procesador gráfico. Normalmente la imagen en bruto le llega sin copia, mediante memoria compartida. Aquí la importación falla — y la biblioteca pasa a modo copia: doce megapíxeles transferidos a la GPU en cada imagen. El bus de memoria se satura, la pantalla ya no obtiene ancho de banda para sus propias operaciones, y el pipeline acaba estrangulado.

No es un fallo abrupto. Es una asfixia, lo que explica que no dejara ningún rastro aprovechable.

Y aquí está lo que da todo su valor a esa línea. Viene de un parche añadido por el mantenedor del paquete, que la había restaurado deliberadamente después de que el proyecto aguas arriba la retirara. Su argumento:

Las importaciones fallidas degradan enormemente el rendimiento e indican problemas accionables en los controladores V4L2 o de GPU.

El mantenedor había colocado el detector, dejando por escrito que su disparo merece una investigación. Se disparó en mi teléfono. Nadie lo había reportado.

Todavía no he demostrado la causalidad — la correlación es clara, el mecanismo coherente, y una prueba sencilla lo zanjaría. Pero es con diferencia lo más útil que encontré aquella mañana, y no estaba en ninguna lista de tareas.

Lo que me llevo, para la próxima

Lo que uno aporta no es talento, es una posición. No fui mejor que nadie. Tenía el aparato conectado y cinco revisores competentes no. Eso es todo, y basta.

Comprobar que el problema sigue existiendo antes de escribir. Dos tareas de tres se habían evaporado, corregidas aguas arriba pero aún sin publicar. Dos peticiones lo habrían dicho de entrada.

Una fuente que confirma solo sirve si es independiente. Diez documentos que copian el mismo valor por defecto no valen más que uno.

Separar lo demostrado de lo deducido — en un mensaje de commit como en una conversación. Tenía un mecanismo correcto y una predicción errónea; decir uno sin el otro habría sido una mentira educada.

Y instrumentar lo que molesta. La congelación de la aplicación era una molestia que llevaba horas sorteando. Fue al dejar de sortearla cuando encontré lo único que nadie más buscaba.

Es realmente un ovillo: uno tira de un hilo de dos líneas, y salen tres cosas que no había pedido.

El punto de partida: tres vistas, siete cotas y la pieza original al lado. Esta foto es todo lo que la IA tendrá jamás de esta ventosa.

El problema no es dibujar, es entenderse

Tenía una ventosa de goma que rehacer y una impresora recién calibrada. El modelado en sí no es el asunto: una ventosa es un disco, un cilindro, un tetón y un taladro. Cualquier programa de CAD la saca en diez minutos — siempre que sepas qué estás dibujando.

El asunto es que quería que la dibujara una IA. No por comodidad: porque quería ver dónde se rompe. Una IA que escribe código tiene el bucle de realimentación más corto posible — el código funciona o no. Una IA que dibuja una pieza mecánica no tiene ninguno: no ve el objeto, no puede medir nada, y su resultado solo se vuelve falso en el momento en que la pieza sale de la impresora y no entra en su alojamiento. Todo lo que ocurre en medio es conversación.

Así que hice un croquis. Tres vistas, acotado, limpio: lo que se enseña en dibujo técnico. Y ahí es donde se pone interesante, porque ese croquis es correcto — y no bastó.

Seis preguntas hechas sobre mi propia foto

El primer reflejo de la IA, y fue el bueno: no adivinar. Cogió mi foto, le puso seis chapas numeradas en rojo y me devolvió la imagen con sus seis preguntas ancladas a puntos concretos del dibujo.

Las seis ambigüedades, señaladas sobre el propio croquis. Anotar la imagen en vez de describir con palabras: lo único que funcionó a la primera en toda esta historia.

Ese método ya lo conocía: viene del artículo anterior, donde describir un gesto de medida en prosa me bloqueó dos veces seguidas, y donde anotar mi propia foto lo desbloqueó en un solo envío. Funciona en los dos sentidos. Cuando la IA no entiende mi dibujo, tiene que enseñarme dónde no entiende, no pedirme que «precise las dimensiones».

Y aun así. Contesté a las seis, una línea cada una. «Es una vista en corte de la misma pieza, materializa el espesor de la ventosa.» «Es el agujero, debajo de la ventosa.» «Tiene 3 mm de diámetro y 4 de profundidad.» «Es ciego.» Seis respuestas exactas, sin ambigüedad. Tras lo cual la geometría seguía estando mal.

Lo que le falta a un croquis no son las cotas

Aquí está el nudo. Mi croquis llevaba todas las cotas necesarias. Lo que no llevaba es a qué se refiere cada cota — y eso es justamente lo que un dibujo a mano alzada no dice, mientras que un plano acotado en regla lo dice mediante la posición de las líneas de referencia.

Un ejemplo. Había escrito «6,5 mm» con una flecha vertical a la derecha del corte. Para mí, evidente: la altura del fuste. Para la IA, igual de evidente: la altura total, ya que la flecha va de un extremo a otro del dibujo. Ambas lecturas se sostienen en una foto tomada de lado, donde la flecha se pasa un poco.

Lo mismo con el agujero y el tetón, ambos de tres y pico milímetros, en los dos extremos de la pieza. Escribí «3» en uno y «3,5» en el otro sabiendo cuál era cuál. Nada en el papel lo decía.

Lo que funciona: hacer que enseñe, no que diga

Tras el sexto intercambio, cambio de método: en vez de hacerme una séptima pregunta, la IA modeló la pieza con sus hipótesis, sacó un render y me lo envió — con un código de color explícito en el corte acotado: en rojo las cotas que venían de mí, en cian las que se había inventado.

Miré el render tres segundos y escribí: «de la punta del tetón al borde del labio, la ventosa mide 10,5 mm. 2 mm de tetón, 6,5 mm de fuste, 2 mm de cuerpo de ventosa.»

La misma pieza, las mismas cotas, dos lecturas. A la izquierda lo que la IA había entendido; a la derecha lo que yo había dibujado. Ninguna pregunta habría producido esa frase — la produjo el dibujo equivocado.

Ahí está la inversión interesante. Una pregunta abierta («la cota 6,5, ¿qué mide?») me pide reconstruir mentalmente el contexto, recuperar lo que tenía en la cabeza tres días antes y formular una respuesta en el vacío. Un render equivocado me pone la geometría delante, y el ojo corrige más rápido que la memoria. La corrección ya no cuesta nada: veo que el fuste está aplastado, luego sé qué decir.

Hay una condición para que funcione, y no es menor: la IA tiene que señalar lo que inventa. Un render limpio, sin distinguir lo que viene de mí de lo que ha rellenado, me habría hecho validar una pieza con cinco valores salidos de la nada. El cian del corte es la confesión de ignorancia hecha visible. Es lo que convierte el render en instrumento de medida y no en ilustración.

La trampa de la suma que cuadra

Esta es la parte que me parece más instructiva, y merece detenerse.

Cuando la IA sacó su segunda versión — la del fuste, todavía equivocada — me explicó que por fin había conseguido colocar la última cota huérfana de mi croquis, el famoso 3,5. Su demostración: la copela mide 1,0, el fuste 3,5, el tetón 2,0, total 6,5, exactamente la altura total del dibujo. Todas las cotas cerraban entre sí. Escribió, y era sincera: «tus cinco cotas cierran entre ellas, lo cual es buena señal para mi lectura».

Salvo que era falso. El 6,5 no era la altura total, el 3,5 no era la altura del fuste, y la pieza reconstruida no se parecía a nada. La lectura correcta da 2 + 6,5 + 2 = 10,5, y el 3,5 es el diámetro del taladro — una cota que no tiene nada que ver con un apilamiento de alturas.

Una suma que cuadra no es una prueba. Con siete cotas y una pieza de revolución hay bastantes grados de libertad para que combinaciones falsas cierren por azar. La coherencia aritmética es un indicio débil, y es justo el tipo de indicio débil que una IA presenta con aplomo porque se parece a una verificación. Es un razonamiento con la forma de una prueba y ninguna de su fuerza.

Lo que lo zanjó no fue un cálculo: fue que la pieza dibujada no se parecía a la pieza que había sobre la mesa. El único juez, en este asunto, es el objeto.

Cuando lo que bloquea es una palabra, hay que colorear

Un último bloqueo, de otra naturaleza. Para que una ventosa agarre, su cara inferior no debe ser plana: sube ligeramente hacia el centro. A eso lo llamo, a falta de algo mejor, el «hueco». Aprietas, el aire atrapado escapa por el labio; sueltas, la goma quiere recuperar su forma, la presión baja en la cavidad y la presión atmosférica aplasta la pieza contra la superficie. Ese es todo el mecanismo.

Solo que mi pieza también tiene un agujero ciego en el centro. Así que cuando me hablaron del «hueco», respondí: «¿a qué llamas el hueco? en el centro de la ventosa hay un agujero de 3,5 mm por 4 mm de profundidad, ¿es el rebaje del centro de la ventosa?»

Reformular no habría servido de nada — la palabra ya estaba ocupada. Lo que funcionó cabe en una imagen:

El hueco es el azul. El agujero es el blanco, en el extremo opuesto. Colorear el volumen del que se habla resuelve en una imagen lo que tres párrafos no habrían resuelto.

La lección general: cuando un intercambio se atasca en una palabra, no es un problema de vocabulario sino de referente. No hay que definir mejor la palabra, hay que señalar la cosa. En geometría, señalar se hace con color.

Un detalle que cuenta: en sus primeros cortes, la IA dibujaba el taladro como un rectángulo blanco que sobresalía por debajo de la pieza y dentro del hueco, «para que se vea bien». Se lo dije — aquella vista era menos clara, porque un trazo que sobresale hace creer en una geometría que no existe, y sobresalía justo en la zona que intentábamos discutir. Un esquema técnico no mejora exagerando los trazos; mejora encuadrando la zona útil y coloreando los volúmenes.

La pieza

La pieza terminada: copela Ø19,5, cuerpo 2, fuste Ø9 × 6,5, tetón de centrado Ø3 × 2, taladro ciego Ø3,5 × 4. Total 10,5.

El modelo es un script de Python de 120 líneas que usa manifold3d, una biblioteca de geometría sólida. Al ser una pieza de revolución, todo cabe en un perfil (radio, altura) que se hace girar:

def profil(n=80):
    """Contorno cerrado (r, z) de la media seccion, sentido antihorario."""
    p = []
    r = np.linspace(0, R_INT, n)                    # cara inferior: concavidad parabolica
    p += [(x, CREUX * (1 - (x / R_INT) ** 2)) for x in r]
    p += [(R_EXT, 0.0), (R_EXT, E_LEVRE)]           # labio: apoyo plano y flanco
    r = np.linspace(R_EXT, R_FUT, n)                # cara superior del cuerpo, algo abombada
    t = (r - R_FUT) / (R_EXT - R_FUT)
    p += [(x, E_LEVRE + (Z_FUT - E_LEVRE) * (1 - u) ** BOMBE) for x, u in zip(r, t)]
    p += [(R_FUT, Z_TET), (R_TETON, Z_TET), (R_TETON, H), (0.0, H)]
    return p

m = Manifold.revolve(CrossSection([profil()]), 128) - trou

Lo que hace viable el ejercicio no es la biblioteca: es que todas las cotas son constantes al principio del archivo, cada una comentada con su procedencia — croquis, deducción o hipótesis. Cambiar un valor y regenerar el STL lleva diez segundos. En cinco idas y venidas, esa es la diferencia entre una conversación y una faena.

Dibujar para TPU no es dibujar una ventosa

La bobina que desencadenó todo esto. La etiqueta anuncia de 20 a 40 mm/s — precisando, un poco más arriba, que apunta a impresoras de extrusor directo.

Una ventosa de verdad es de silicona o PVC blando, en torno a 40-60 Shore A. El TPU más corriente, el que tengo, es 95A: más o menos la dureza de una rueda de carrito. No es un detalle de ajuste, es una restricción de diseño.

Un labio grueso en 95A no se adaptará a los microdefectos de la superficie: apoyará en tres puntos altos y tendrá fugas entre ellos. Hace falta pues un labio fino, de 0,6 a 0,8 mm, capaz de flexar — a costa de fragilizarlo. Y hay algo peor: una pieza impresa por deposición de hilo es un apilamiento de cordones soldados, y entre dos cordones quedan microcanales. En una pieza estética nadie los nota. En una pieza cuya función es sostener una depresión, son fugas. De ahí capas finas, temperatura alta y un ligero exceso de material — no por resistencia, sino para soldar las capas entre sí.

Es el tipo de compromiso que un diálogo con una IA saca bien a la luz, siempre que se le dé el material antes que la geometría. Si hubiera pedido «dibújame una ventosa» sin más, habría obtenido un labio de 2 mm: correcto en goma moldeada, inservible aquí.

TPU en una impresora de extrusor remoto: el peor caso

Queda imprimirla, y ahí mi máquina se recuerda a sí misma. En una FLSun QQ-S, el motor que empuja el filamento no está en el cabezal: está en el bastidor, y el hilo recorre unos 700 mm dentro de un tubo guía antes de llegar a la boquilla. Es un montaje bowden. Con filamento rígido funciona: el hilo se comporta como una varilla que se empuja. Con filamento flexible se comporta como un muelle — empujas por un lado, no sale nada por el otro, y luego sale todo de golpe.

De ahí tres consecuencias, y se ven en el perfil de laminado:

• La retracción. Mi perfil de PLA retrae 5 mm. En TPU, 5 mm aflojan el hilo hasta el punto de que puede enrollarse a la entrada del tubo y atascarse — es el modo de fallo del flexible en bowden. Bajada a 2 mm, a velocidad reducida.
• La velocidad. La etiqueta anuncia de 20 a 40 mm/s suponiendo extrusor directo. En bowden, de 15 a 25.
• La aceleración. En una delta rápida, los tirones los absorbe la elasticidad del hilo en vez de la boquilla: falta material en las esquinas. Rebajada de 1500 a 800 mm/s², restaurada al terminar.

Lo que me llevo

Una IA que dibuja no tiene bucle de realimentación. No ve la pieza, no mide nada, y su error solo se hace visible al imprimir. Todo el trabajo consiste en fabricarle ese bucle a mano — y el render es eso.

Enseñar gana a preguntar. Una pregunta abierta me pide reconstruir un contexto; un dibujo equivocado me pone la geometría delante y el ojo corrige solo. Seis preguntas no convergieron; dos renders sí.

La IA debe señalar lo que inventa. El código rojo/cian — tus cotas, mis hipótesis — es lo que convierte un render bonito en instrumento de medida. Sin él habría validado cinco valores salidos de la nada.

La coherencia aritmética no es una verificación. Mis cotas cerraban perfectamente sobre una pieza falsa. Una IA presenta ese tipo de indicio con el aplomo de una prueba, porque tiene su forma. El único juez es el objeto sobre la mesa.

Cuando una palabra bloquea, señala la cosa. Nada de reformular: una imagen donde se colorea el volumen del que hablas.

El material se da antes que la geometría. «Una ventosa» y «una ventosa de TPU 95A impresa por deposición de hilo» no son la misma pieza, y la segunda no se obtiene ajustando los parámetros de la primera.

Y la parametrización hace todo esto llevadero. Cinco versiones sucesivas, diez segundos cada una. Si cada corrección hubiera supuesto rehacer un modelo de CAD, habría abandonado en el segundo render y dibujado la pieza yo mismo — lo cual, dicho sea de paso, habría sido perfectamente razonable.

Dónde estamos

Para reproducirlo

Lo que hace falta: la pieza original, un calibre, con qué hacer un croquis y un entorno Python con manifold3d, numpy y matplotlib. Ningún programa de CAD.

El croquis. Tres vistas valen más que una perspectiva. Pero sobre todo: escribe junto a cada cota qué mide, con todas las letras. «6,5 = altura del fuste», no «6,5». Queda feo en un plano en regla; es lo que aquí te ahorra cinco idas y venidas.

El bucle. En cada iteración, exige tres salidas: el STL, una vista 3D (¿se parece al objeto?) y un corte acotado (¿están las cotas en los sitios correctos?). El corte es el que encuentra los errores; la 3D, la que encuentra los disparates.

El código de color. Pide explícitamente que se distingan en pantalla las cotas tomadas de tu croquis y las inventadas por la IA. Es el punto más rentable de todo el método.

Las reglas de dibujo que fueron surgiendo, para un esquema técnico legible: cada forma se detiene en su geometría real, nunca un trazo que sobresale «para que se vea»; el texto fuera de la pieza, nunca encima; encuadrar la zona en discusión — un hueco de 1 mm es invisible a la escala de una pieza de 20; y colorear los volúmenes en vez de engordar los trazos.

Los archivos: el modelo ventouse.py y el STL que produce; el perfil de laminado qqs-tpu.ini (PrusaSlicer por línea de comandos, delta de 260 mm, boquilla 0,4); y esp32-supermini-tray.py, una pieza anterior hecha con la misma cadena, para comparar una geometría prismática con una de revolución.

El perfil TPU en resumen, si imprimes flexible en bowden: retracción 2 mm a 25 mm/s, perímetros 15-20 mm/s, aceleración 800, boquilla 225-230, cama 45-50, ventilación 40-60 %, primera capa menos aplastada de lo habitual (el flexible refluye en vez de extenderse), y una barra de pegamento sobre el vidrio como desmoldeante — el TPU se adhiere lo bastante como para arrancar una lasca.

Preguntas frecuentes

¿Se puede hacer CAD de verdad dialogando con una IA, sin software?

Para una pieza sencilla y bien definida, sí, y el resultado es paramétrico, versionable y comentado — tres cosas que un archivo de CAD da mal. Para una pieza cuya forma aún no conoces, no: el diálogo cuesta más que el boceto. La frontera está más o menos donde puedes describir la pieza en una frase.

¿Por qué no bastó mi croquis acotado?

Porque un croquis a mano alzada lleva las cotas pero no sus anclajes. En un plano en regla, la posición de las líneas de referencia dice a qué se refiere la cota; a mano alzada, en una foto tomada de lado, esa información desaparece. Escribir con todas las letras qué mide cada cota la restituye.

¿Puede una IA inventarse cotas sin decirlo?

Lo hace necesariamente — una pieza tiene más dimensiones de las que lleva un croquis. La cuestión es si lo señala. Exige que los valores inventados se marquen en el render y se comenten en el código; se comprueba de un vistazo y lo cambia todo.

¿Sirve el TPU 95A para una ventosa?

Es bastante más duro que la silicona de una ventosa real (40-60 Shore A). Puede funcionar sobre una superficie muy lisa con un labio fino y capas finas, pero no esperes el agarre de una pieza moldeada. Un TPU más blando, de 85A, iría mejor para el uso — y sería mucho más difícil de imprimir en bowden.

¿Hace falta extrusor directo para imprimir TPU?

No para 95A; en la práctica sí para 85A y más blandos. En bowden, lo que más cuenta no es la longitud del tubo sino el extrusor: un doble arrastre sujeta el filamento por ambos lados, donde un solo rodillo lo deja escapar. Un tubo de 1,9 mm de interior lo completa bien.

¿Por qué no montar el extrusor en el cabezal de una delta?

Porque la masa móvil es ahí el parámetro crítico y penaliza los tres ejes a la vez. Doblar la masa del efector hace caer la frecuencia de resonancia en un factor √2; por debajo de 25 Hz, la compensación por software empieza a redondear los detalles. Véase el recuadro de la sección sobre el bowden.

¿Cuánto tiempo llevó todo?

Una hora escasa de conversación, cinco versiones del modelo. La mayor parte de ese tiempo se fue en despejar seis ambigüedades del croquis — no en dibujar.

Pequeño glosario

Bowden (montaje) — El motor que empuja el filamento va fijado al bastidor, y el hilo llega a la boquilla por un tubo guía. Aligera el cabezal móvil, pero introduce elasticidad en el empuje.

Direct drive — Lo contrario: el motor va en el cabezal. Mejor control del material, cabezal más pesado.

Efector — En una impresora delta, la pieza móvil que sostiene la boquilla, suspendida de los tres pares de brazos.

manifold3d — Biblioteca de geometría sólida que garantiza mallas siempre válidas; la pieza se describe en Python mediante operaciones booleanas y revoluciones.

Pressure advance — Compensación por software del retardo entre la orden de extrusión y la salida de material, debido a la compresibilidad del filamento. Tanto mayor cuanto más elástico es el montaje.

Retracción — Retroceso del filamento durante los desplazamientos sin extrusión, para evitar hilos. Larga en bowden, muy corta en directo.

Shore A — Escala de dureza de los elastómeros. La silicona de una ventosa está en 40-60, una junta de puerta en 70, un TPU de impresión corriente en 95, una rueda de carrito en 98.

STL — Formato de archivo que describe una superficie mediante una malla de triángulos. Lo que espera el laminador.

Laminador (slicer) — El programa que convierte un STL en trayectorias de boquilla. Aquí PrusaSlicer, gobernado por línea de comandos con un archivo de perfil.

TPU — Poliuretano termoplástico: el filamento flexible más corriente.

Referencias y copias locales

• El modelo y sus salidas: ventouse.py, ventouse.stl
• El perfil de laminado para TPU: qqs-tpu.ini
• Una pieza prismática hecha con la misma cadena: esp32-supermini-tray.py
• manifold3d — la biblioteca de geometría sólida utilizada
• Documentación de Klipper — medida de resonancias — sobre el umbral de 25 Hz y el compromiso masa/rigidez
• El artículo anterior — la calibración de la misma máquina, donde nació el método de la foto anotada

La parte trasera del aparato. «Model G020F» — la variante europea. Al lado, el marcado CE y el contenedor tachado, ese pictograma que significa «no tirar con la basura doméstica». Han hecho falta siete años para que ese símbolo dejara de ser un trámite y se convirtiera en el tema.

Qué significa realmente «fin de soporte»

El Pixel 3a salió en mayo de 2019. Era el sensato de su generación: una cámara notable por 400 €, un conector de auriculares que los buques insignia ya habían suprimido, un procesador Snapdragon 670 sin pretensiones. Google lo actualizó hasta el 5 de mayo de 2022. La última versión instalada en este lleva el número SP2A.220505.008 — Android 12, parche de seguridad de mayo de 2022.

Desde entonces, nada. No porque el hardware haya fallado: funciona perfectamente. Porque una empresa decidió que un plazo se había cumplido.

«El dispositivo ya no tiene soporte» es una frase que se lee sin pensarla. Traduzcámosla. El procesador, la pantalla, las cámaras, el módem, la batería — todo eso sigue funcionando. Lo que se detiene es un servicio: alguien, en algún sitio, deja de compilar software para esa combinación concreta de chips. El teléfono no se vuelve defectuoso, se vuelve huérfano. Y como el software que ejecuta no lo puede modificar su propietario, huérfano significa condenado.

Salvo que este era un Pixel. Y los Pixel tienen una propiedad rara: Google, a diferencia de casi todos sus competidores, permite al propietario desbloquear el gestor de arranque — el pequeño programa que decide qué sistema operativo tiene derecho a iniciarse. Ese permiso, sobre el que volveré, es lo que separa un aparato recuperable de un ladrillo.

Tres maneras de poner Linux en un teléfono, y solo una que cuenta aquí

Un teléfono Android ya ejecuta un núcleo Linux. Pero un núcleo Android es una versión antigua del núcleo oficial, a la que el fabricante del chip ha añadido miles de modificaciones que nunca publica aguas arriba. Ese código solo vive lo que dura el producto. Ahí está toda la diferencia entre las tres opciones que había:

Ubuntu Touch es objetivamente la mejor opción para usar este teléfono: llamadas, SMS, 4G, Bluetooth, NFC, las dos cámaras, el lector de huella — todo funciona. Pero lo consigue reutilizando los controladores binarios de Android 9. Es decir, embalsamando 2019. Nada de lo que allí se corrija beneficia a nadie más, y el día en que esa base se pudra, no habrá nada que hacer.

postmarketOS toma el camino inverso: hacer funcionar el núcleo Linux oficial, el que usa todo el mundo, sobre este chip. Es más difícil, faltan cosas, y ahí está precisamente el interés — lo que se escribe allí sube al núcleo que el mundo entero usará dentro de diez años. Un grupo de desarrolladores se dedica específicamente a este procesador, bajo el nombre sdm670-mainline.

La elección era pues sencilla, a condición de asumir lo que implica: este teléfono no será mi teléfono. Es un banco de pruebas.

El desbloqueo, y la trampa del teléfono restablecido

El aparato llegó restablecido de fábrica, lo que parecía simplificar las cosas. No fue así.

Para desbloquear el gestor de arranque hay que activar una opción llamada Desbloqueo de OEM en los ajustes de Android. Ahora bien, esa opción permanece atenuada mientras el teléfono no haya alcanzado la red al menos una vez: Google comprueba que el aparato no esté denunciado como robado. Hay que encender el teléfono, atravesar el asistente de configuración, conectar el Wi-Fi — y solo entonces activar la opción. En un aparato que uno se dispone a borrar por completo, es un rodeo absurdo pero obligatorio.

Segunda trampa, más traicionera: la combinación de teclas para entrar en modo fastboot — el modo de mantenimiento del gestor de arranque — es Bajar volumen + Encendido, pero únicamente desde un teléfono completamente apagado. En un aparato encendido, esa misma combinación hace una captura de pantalla. Uno pulsa, no ocurre nada de lo esperado, vuelve a intentarlo y empieza a dudar de su hardware. Hay que apagar, esperar dos segundos, mantener Bajar volumen primero, y luego pulsar Encendido.

El resto cabe en un comando, y un aviso rojo en pantalla que hay que confirmar con los botones físicos:

fastboot flashing unlock

La pantalla de fastboot después de la operación. «Device state: unlocked» en rojo: el teléfono acepta ya arrancar un sistema que Google no ha firmado. Nótese «sargo MP1.0 (ROW)» — sargo es el nombre en clave del Pixel 3a, ROW confirma la variante internacional.

El teléfono lo borra todo y se reinicia. A partir de ahí, ya no pertenece del todo a Google.

Preparar el sistema: media hora de preguntas

Del lado del ordenador, postmarketOS se construye con una herramienta llamada pmbootstrap, disponible en los repositorios de la mayoría de las distribuciones. No descarga una imagen ya hecha: ensambla el sistema para tu aparato concreto, en un entorno aislado, haciéndote una veintena de preguntas.

La mayoría admiten la respuesta por defecto. Tres merecen reflexión, y resolví las tres con el mismo principio: ceñirse a lo que prueban los mantenedores.

Es un principio que merece explicitarse, porque es contraintuitivo. Cuando uno instala un sistema para sí mismo, elige lo que prefiere. Cuando lo instala para contribuir, cada desviación respecto de la elección mayoritaria es una variable más que hará inservibles tus informes de fallo. Si reporto un problema de audio sobre una pila que nadie más usa, el mantenedor no puede ni reproducirlo ni compararlo. Mi informe se convierte en ruido.

Así que tomé pulseaudio en vez del más moderno pipewire, wpa_supplicant en vez de iwd, el entorno Phosh en vez del muy tentador sxmo, y — a regañadientes — systemd. Sobre esto último, postmarketOS es uno de los pocos sitios donde OpenRC sigue siendo un ciudadano de primera clase; mi reflejo no tenía nada de marginal. Pero cuatro de los quince fallos abiertos para este aparato están reportados bajo Phosh con systemd, y journalctl sigue siendo lo más cómodo para extraer una traza limpia.

Dos respuestas merecen una advertencia.

No activar el cifrado del disco. La opción está ahí, es tentadora, y en este teléfono deja el aparato sin poder arrancar: un fallo abierto describe un sistema que no detecta la escritura de la contraseña durante el arranque. Uno acaba con una máquina que pide una frase de paso imposible de teclear.

Mantener la configuración regional en inglés. Contraintuitivo para un blog francófono, pero los mensajes de error y los registros saldrán en inglés, y por tanto podrán pegarse directamente en un informe y compararse con los de los demás. No impide en absoluto tener un teclado AZERTY.

Channel          edge          # donde se reportan los fallos y aterrizan las correcciones
Vendor           google
Device           sargo
UI               phosh
Audio backend    pulseaudio    # por defecto
WiFi backend     wpa_supplicant # por defecto
usb-moded        developer     # red USB SIEMPRE activa — el cabo de seguridad
Service manager  default       # systemd para Phosh
Locale           en_US

libcamera-tools,v4l-utils,evtest,tmux,vim,strace,usbutils

curl -s -o idx.tar.gz \
  "https://dl-cdn.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz"
tar xzf idx.tar.gz -O APKINDEX | grep '^P:' | sed 's/^P://' > paquetes.txt
grep -qx "libcamera-tools" paquetes.txt && echo presente

Media hora después, el sistema estaba construido. Quedaba escribirlo en el teléfono. Ahí es donde la tarde se torció.

Una hora culpando al responsable equivocado

El teléfono estaba en modo fastboot, conectado, reconocido. El comando de escritura arrancaba — y se quedaba colgado. Indefinidamente. Sin el más mínimo mensaje de error, ni en la salida estándar ni en la de error. Un proceso dormido, para siempre.

Lo desconcertante era que el aparato parecía perfectamente presente:

$ fastboot devices
058AY1WZGT     fastboot

Respondía. Estaba ahí. Y sin embargo toda escritura se bloqueaba.

Formulé cuatro hipótesis. Las cuatro eran falsas, y descartarlas me llevó una hora. Merece la pena enumerarlas, porque son exactamente las que formularía cualquiera.

Un problema de permisos. La hipótesis clásica: el nodo USB pertenece a root, el usuario no tiene derecho a escribir en él. Verificado: el fichero llevaba una lista de control de acceso que concedía explícitamente el acceso a mi cuenta. Descartado por la medida, no por la suposición.

Un cable o un puerto defectuosos. Es el reflejo siguiente, y el más extendido en los foros. Salvo que los registros del núcleo estaban impecables: enumeración a alta velocidad, ningún error, ninguna reinicialización, ninguna desconexión intempestiva. Un cable dañado deja rastro; no había ninguno.

Un problema de controladora USB. Pista seria: los Pixel solo tienen USB 2.0, y las controladoras modernas tienen fama de caprichosas con ciertos gestores de arranque. El consejo habitual es «conéctalo a un puerto USB 2.0». Dos medidas lo descartaron: el teléfono ya negociaba a 480 megabits, es decir ya en USB 2.0, y la placa base de la máquina (una Raptor Lake de Intel) ya no tiene controladora de generación anterior — todo pasa por el mismo bloque. «Cambiar a un puerto USB 2.0» no tenía sentido.

Una regresión del software. pmbootstrap ejecuta su propia copia de fastboot, en versión 37, mientras que mi sistema tenía la versión 35. Así que salté la herramienta y flasheé directamente con la del sistema. Se colgó exactamente igual. Hipótesis muerta.

Cuatro pistas, cuatro callejones sin salida. Y un detalle que debería haberme alertado mucho antes: en cada nueva entrada en modo fastboot, el primer comando pasaba — en trece milisegundos — y todos los siguientes se colgaban.

Tenía ese hecho delante desde el principio. Tardé una hora en escucharlo, porque seguía interrogando al aparato en lugar de interrogar al sistema.

La respuesta cabía en un fichero

El modo fastboot es un diálogo: el ordenador pregunta, el gestor de arranque responde. Acabé mirando no lo que respondía el teléfono, sino lo que el núcleo Linux pensaba de él. Esa información vive en /sys, un sistema de ficheros virtual donde el núcleo expone su estado interno en forma de ficheros legibles.

$ cat /sys/bus/usb/devices/1-9/power/control
auto
$ cat /sys/bus/usb/devices/1-9/power/autosuspend_delay_ms
2000
$ cat /sys/bus/usb/devices/1-9/power/runtime_status
suspended

Dormido.

Para ahorrar energía, el núcleo suspende los periféricos USB tras un plazo de inactividad — aquí, dos segundos. Es un comportamiento normal y deseable para la mayoría de aparatos, que saben despertar cuando se les vuelve a hablar. El gestor de arranque del Pixel no sabe. Una vez dormido, ya no responde nunca.

Todo encaja de golpe:

La corrección es una regla de tres líneas, que pide al núcleo no dormir nunca los aparatos Google:

# /etc/udev/rules.d/52-fastboot-no-autosuspend.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", \
    TEST=="power/control", ATTR{power/control}="on"

Salvo que no cambió nada. Y la razón de ese fracaso es la parte más interesante de la historia.

El segundo responsable, agazapado tras el primero

Mi regla era correcta — la herramienta de diagnóstico de udev confirmaba que se evaluaba y se aplicaba bien. Pero tras cada conexión, el ajuste volvía a auto.

Alguien pasaba detrás de mí. Ese alguien se llamaba TLP, un gestor de energía muy extendido en los portátiles Linux, que aplica sus propios ajustes de suspensión USB después de udev, y sobrescribe por tanto los tuyos en silencio. Mucha gente lo instala una vez para ganar autonomía y luego se olvida por completo.

TLP tiene precisamente una opción prevista para este caso:

# /etc/tlp.conf
USB_EXCLUDE_PHONE=1
USB_DENYLIST="18d1:4ee0 18d1:4ee1 18d1:4ee2 18d1:4ee3 18d1:4ee7"

Esta vez el ajuste aguantó. Un detalle que conviene saber: aplicar la corrección no desbloquea un aparato ya dormido. El estado USB del gestor de arranque solo se repara al reenumerar. Hay que corregir, y luego salir y volver a entrar en modo fastboot.

Y para maximizar las probabilidades, agrupé las tres escrituras en una sola invocación, en lugar de tres procesos sucesivos:

fastboot flash vbmeta   vbmeta.img \
         flash boot     boot.img \
         flash userdata google-sargo.img

Sending 'vbmeta_b' (4 KB)                   OKAY [  0.120s]
Writing 'vbmeta_b'                          OKAY [  0.071s]
Sending 'boot_b' (28008 KB)                 OKAY [  0.747s]
Writing 'boot_b'                            OKAY [  0.194s]
Sending sparse 'userdata' 1/9 (258751 KB)   OKAY [  6.306s]
...
Finished. Total time: 94.883s

Noventa y cinco segundos. Tras una hora de bloqueo.

lsusb | grep 18d1

cat /sys/bus/usb/devices/<puerto>/power/runtime_status

sudo readlink /proc/<pid>/root        # ¿se ejecuta en un chroot?
sudo ls -l /proc/<pid>/fd | grep usb  # ¿ha abierto el periférico?

Lo que arrancó

Veinte segundos después del reinicio, la máquina vio aparecer una interfaz de red. El teléfono repartía él mismo las direcciones.

$ ssh sam@172.16.42.1
$ uname -r
7.1.3-sdm670
$ df -h /
/dev/loop0p2   47.9G   2.2G   43.2G   5% /

Núcleo 7.1.3. En un teléfono cuyo fabricante dejó de ocuparse en mayo de 2022, con un núcleo Android congelado en el 4.9. El sistema de ficheros se había agrandado solo en el primer arranque para ocupar los 48 gigabytes disponibles.

Primer arranque. La pantalla lleva rota mucho tiempo; el aparato, en cambio, acaba de rejuvenecer cuatro años.

El panel de ajustes rápidos. Wi-Fi, Bluetooth, batería al 94 %. Y en las notificaciones, el selector «USB Developer mode» — exactamente el perfil elegido en la instalación, el que mantiene la red USB activa de forma permanente. El reloj marca «jueves 1 de enero, 4:12»: el reloj físico aún no está en hora, nadie le ha dicho todavía qué día es.

La cámara, o cómo una herramienta bien escrita te tiende el trabajo

Quedaba comprobar aquello a lo que venía. En postmarketOS, la gestión de las cámaras pasa por libcamera, una biblioteca libre que sustituye a la pila propietaria de Android. Un fallo conocido señala que el controlador del sensor frontal de este teléfono está incompleto, y que el comando cam -l — que lista las cámaras — se queja de ello.

Se quejó, en efecto. Pero mucho mejor de lo que esperaba:

ERROR V4L2 'imx355 4-001a': Unable to get rectangle 2 on pad 0/0
ERROR V4L2 'imx355 4-001a': Unable to get rectangle 1 on pad 0/0
ERROR V4L2 'imx355 4-001a': Unable to get rectangle 0 on pad 0/0
 WARN  'imx355 4-001a': Failed to retrieve the sensor crop rectangle
 WARN  'imx355 4-001a': The sensor kernel driver needs to be fixed
 WARN  See Documentation/sensor_driver_requirements.rst

Hay algo reconfortante en un software que te dice literalmente «el controlador del núcleo del sensor necesita ser corregido» y te da la referencia del documento que explica cómo. Es exactamente lo contrario de un error 4202 en una aspiradora.

Concretamente: el controlador no sabe responder cuando se le piden las dimensiones reales de su matriz de píxeles. libcamera se inventa entonces valores por defecto y trabaja sobre una geometría aproximada.

Pero la salida revelaba además esto, que no esperaba:

WARN 'imx363': No static properties available — Please consider updating the database
WARN 'imx355': No static properties available
WARN IPASoft: Failed to create camera sensor helper for imx355 / imx363

Este segundo problema no está en el núcleo. Son dos tablas de datos, dentro de la propia libcamera, donde los sensores del Pixel 3a faltan — mientras que decenas de otros ya figuran allí y ofrecen un modelo que copiar. Datos puros, nada de algoritmia.

Actualización, unas horas después. Al ir a escribir esa corrección, descubrí que la mitad acababa de hacerse: el sensor frontal, el imx355, se añadió aguas arriba después de la versión 0.7.2 que ejecuta este teléfono. El aviso de más arriba es pues un artefacto de versión, no una carencia — bastará con actualizar. El sensor trasero, el imx363, sigue ausente de todo el repositorio, y su controlador ni siquiera está en el núcleo oficial: se escribió en Intel, nunca se envió aguas arriba, y postmarketOS lo carga como módulo.

Y al comparar la entrada nueva del imx355 con lo que el controlador expone realmente en el aparato, algo no cuadra: asocia «barras de color» al valor 1 y «color sólido» al valor 2, cuando el controlador hace exactamente lo contrario. Otros dos sensores con menú idéntico, el imx258 y el imx471, están descritos correctamente justo al lado. Son pues dos correcciones en lugar de una — y la más sencilla es la que nadie esperaba.

Dicho de otro modo: la primera corrección que escribir no es la que venía buscando. Ha hecho falta encender el hardware real para darse cuenta. Es una lección bastante general — uno puede leer informes de fallos durante días sin ver lo que una máquina encendida te dice en tres segundos.

Por qué esto no es solo un pasatiempo

La misma mañana en que este teléfono arrancó, la cuenta balade.nomade publicaba un reel (copia local del texto y del hilo de comentarios) que resume lo que se está jugando ahora mismo en Bruselas. Termina con una pregunta que me parece bien planteada:

¿Estás dispuesto a escanear tu documento de identidad para usar Instagram?

El tono es militante, así que verifiqué los tres puntos. Dos se sostienen sólidamente, el tercero merece un matiz — y el hilo de comentarios añadió un cuarto, más pertinente para este artículo que los otros tres.

Chat Control. Exacto. El reglamento europeo llamado CSAR sigue bloqueado en trílogo, y las negociaciones se reanudan a finales de septiembre de 2026 bajo presidencia irlandesa del Consejo. El 9 de julio de 2026, el Parlamento Europeo votó 314 contra 276 por retirar el dispositivo — sin alcanzar el umbral de 360 votos necesario para bloquear la posición del Consejo. La excepción que autoriza el escaneo «voluntario» de los mensajes se prorrogó por tanto hasta 2028. El análisis en el lado del cliente se retiró de la última versión del texto, pero el propio servicio jurídico del Consejo, en un dictamen del 10 de junio de 2026, estima que ese escaneo voluntario sigue siendo un registro generalizado de las comunicaciones, incompatible con el artículo 7 de la Carta de los Derechos Fundamentales.

El fin del anonimato. Exacto, con una novedad que el reel no menciona: la ley francesa del 21 de julio de 2026 que prohibía las redes sociales a los menores de quince años fue anulada el 14 de agosto por el Consejo Constitucional (decisión n.º 2026-911 DC), por vulneración desproporcionada de la libertad de expresión y de la vida privada. No entrará pues en vigor tal cual. Pero el movimiento de fondo continúa en otros frentes: la Comisión Europea anunció el 15 de abril de 2026 que su solución de verificación de edad estaba lista para el despliegue, y la cartera de identidad digital europea debe llegar a los Estados miembros antes de fin de año.

Los metadatos. Aquí matizo. El EDPB sí adoptó el 7 de julio de 2026 unas nuevas directrices sobre anonimización, en consulta hasta el 30 de octubre, que sustituyen al dictamen de referencia de 2014. Pero es un trabajo de clarificación técnica, no un puñetazo en la mesa. Y la jurisprudencia reciente apunta más bien en sentido contrario: el Tribunal de Justicia de la Unión Europea, en septiembre de 2025, adoptó un enfoque relativo — un mismo dato seudonimizado puede ser anónimo para quien no tiene medio alguno de reidentificar, y personal para otro.

El cuarto punto, el que habla de verdad de este artículo

En los comentarios, alguien señala que Google está cambiando su política de instalación de aplicaciones y teme que eso «ponga en peligro GrapheneOS». La respuesta del autor corrige con razón ese temor, y los hechos le dan la razón.

Desde agosto de 2025, Google exige que toda aplicación instalada en un dispositivo Android certificado provenga de un desarrollador verificado — incluso cuando se instala un archivo APK a mano, fuera de cualquier tienda. Las primeras restricciones visibles llegan el 30 de septiembre de 2026 a Brasil, Indonesia, Singapur y Tailandia, antes de una extensión mundial en 2027. Instalar la aplicación de un desarrollador no verificado pasará por un recorrido indirecto con un plazo de espera obligatorio de veinticuatro horas. Y para verificarse, un desarrollador debe abrir una cuenta, pagar veinticinco dólares y aportar un documento de identidad oficial.

Relee la pregunta del reel y sustituye al usuario por el desarrollador. Es el mismo gesto: un documento de identidad como condición de acceso. De un lado para leer, del otro para escribir.

El comentarista se equivocaba sin embargo en un punto, y es el que cuenta. La restricción afecta a los dispositivos certificados — los que incorporan los servicios de Google bajo licencia. GrapheneOS no los incorpora: queda fuera del perímetro. La restricción no pone pues en peligro a los sistemas desgooglizados, hace que su existencia sea más necesaria.

Instalar tu propio software, esa batalla

Es lo que más me exaspera, y es anterior a toda esta actualidad. Tanto en Android como en iOS, instalar un software que uno mismo ha compilado, o recuperado de un repositorio Git, es una carrera de obstáculos.

En Android hay que autorizar un origen desconocido, pasar tres avisos, y pronto rebuscar en las opciones de desarrollador y esperar veinticuatro horas. En iOS es peor: una aplicación que compilas y firmas con una cuenta Apple gratuita deja de funcionar a los siete días y hay que reinstalarla desde un ordenador. Para que sobreviva, hay que pagar noventa y nueve euros al año. El reglamento europeo de mercados digitales entreabrió la puerta en 2024 — tiendas alternativas, distribución desde el propio sitio web — pero solo dentro de la Unión, y en las condiciones de Apple.

La justificación es siempre la misma: la seguridad. Merece tomarse en serio y, por tanto, examinarse.

Si la apertura causara inseguridad, se notaría. Linux permite instalar cualquier cosa desde cualquier sitio — un repositorio, un archivo comprimido, código compilado a mano — y no es un desastre de seguridad: es el sistema que hace funcionar la mayor parte de los servidores del planeta, bajo ataque permanente. Windows, en cambio, tuvo durante mucho tiempo el modelo más permisivo y la peor reputación. Si la teoría fuese buena, Android e iOS serían los sistemas más seguros jamás concebidos. Se observa más o menos lo contrario de lo que predice.

Lo que protege no es pues el cierre, sino una cadena de confianza verificable: repositorios firmados, mantenedores identificados, código fuente que cualquiera puede releer, compilaciones reproducibles. La seguridad viene de la transparencia, no del permiso. Y esa cadena ya existe en Android: F-Droid distribuye desde hace años aplicaciones libres compiladas a partir de fuentes públicas, sin peaje ni documento de identidad.

Mientras tanto, la tienda oficial deja pasar. En 2026, una familia de software malicioso llamada NoVoice se encontró en más de cincuenta aplicaciones de Play Store, sumando al menos 2,3 millones de descargas — con acceso root y capaz de sobrevivir a un restablecimiento de fábrica. El año anterior, la campaña SlopAds: 224 aplicaciones, 38 millones de descargas. Y Google baneó 80 000 cuentas de desarrollador en 2025, bajo un régimen que ya exige verificación de identidad para publicar en Play Store.

Es esa cifra la que zanja la discusión. La verificación de desarrolladores ya existe allí donde se supone que protege, y aun así hay que banear ochenta mil cuentas al año. Extenderla a la instalación manual no detendrá las campañas industriales — entran por la puerta grande, y está documentado. Detendrá al desarrollador solitario que publica su código en un repositorio Git.

El riesgo, en sí, es real: quien instala un archivo recibido por SMS cae efectivamente en la trampa. Pero eso aboga por un aviso claro, no por un derecho de entrada. Se protege a alguien diciéndole lo que está haciendo; no se le protege cobrando a quien escribe.

Y hay un criterio que zanja la cuestión. Para operar una tienda alternativa en la Unión Europea, Apple exige, a partir del 1 de octubre de 2026, cotizar en bolsa, o estar financiado por capital riesgo, o haber pasado una auditoría financiera, o sumar un millón de instalaciones anuales. Ninguno de esos criterios mide la seguridad de nada. Son criterios de tamaño.

Estoy dispuesto a conceder la buena fe en el principio. Me cuesta más cuando la misma empresa cierra la puerta y lleva la caja.

Lo que eso cambia para un teléfono viejo

El hilo común de todo esto es técnico, y es el que conecta esta actualidad con un Pixel de 2019.

El análisis en el lado del cliente consiste en inspeccionar los mensajes en el aparato, antes del cifrado. Un dispositivo así no se implementa en una aplicación: se implementa en el sistema. Ese es el desplazamiento decisivo. Mientras la garantía descansaba en el protocolo, podía auditarse desde fuera. En cuanto descansa en el aparato, la única pregunta que importa pasa a ser: ¿quién decide lo que hace este aparato?

En un teléfono cuyo sistema no puede reemplazarse, la respuesta es: el fabricante. Y a través de él, quienquiera que legisle sobre el fabricante. No es un escándalo, es una cadena de decisión perfectamente ordinaria — pero en ningún momento pasa por el propietario.

Las dos vías de escape existentes — GrapheneOS, postmarketOS — descansan exactamente en lo mismo: un gestor de arranque que se tiene derecho a desbloquear. La misma casilla en las opciones de desarrollador que abrió esta tarde. Toda la salida práctica, para Android, ha dependido hasta ahora de la buena voluntad de un solo fabricante sobre un solo ajuste. GrapheneOS solo está disponible en Pixel; habrá que esperar a los Motorola de gama alta de 2027 para que eso deje de ser cierto.

Y hay que decir lo que este artículo no demuestra. postmarketOS en un Pixel 3a no es una solución de privacidad. El módem sigue siendo una caja negra, un procesador autónomo que ejecuta software propietario al que el sistema no tiene acceso. Este aparato en concreto no es utilizable a diario, lo dije desde el principio. Para un uso real, la respuesta seria es la que el reel pone como etiqueta: GrapheneOS.

Lo que este artículo sí demuestra es más modesto, y basta: la capacidad existe, está al alcance de una tarde, y se ejerce. Una capacidad que nunca se ejerce acaba desapareciendo sin que nadie se dé cuenta — no por prohibición, simplemente porque un día ningún aparato la ofrece ya y nadie la habrá reclamado.

¿Y tu teléfono?

Fue la primera pregunta que me hicieron, y es la buena. Esto es lo que la responde — las cifras vienen del repositorio pmaports a fecha del 5 de septiembre de 2026 y del sitio oficial de Ubuntu Touch, no de una lista copiada de algún sitio.

Primero, una advertencia sobre el vocabulario. postmarketOS clasifica sus aparatos en tres niveles, y significan algo:

• community — funciona en general, con carencias identificadas. 39 aparatos, de los cuales solo catorce son teléfonos.
• testing — desde «arranca, en cierto sentido» hasta «funciona casi todo». 149 aparatos. Ahí está la mayoría del parque, y ahí está el trabajo.
• downstream — núcleo Android de origen, funcionalidades muy limitadas. 20 aparatos, desaconsejados.

Ningún aparato está hoy clasificado por encima de community. Eso sitúa honestamente el estado del ecosistema.

Los catorce teléfonos en community

Dos sorpresas en esa lista. El Xiaomi Poco F1 y los OnePlus 6 / 6T son excelentes candidatos: potentes para su edad, muy extendidos de segunda mano, y portados desde hace tiempo. Y el PinePhone original, diseñado para Linux, está en testing — es su sucesor Pro el que está en community.

El resto de la categoría no son teléfonos: una docena de Chromebooks ARM, el Lenovo ThinkPad X13s, la PineNote, la Odroid XU4, la RockPro64. Si lo que buscas es un pequeño ordenador ARM con Linux en lugar de un teléfono, es una vía muy infravalorada.

En testing, los 149 aparatos se reparten sobre todo entre Samsung (30), Xiaomi (18), Sony, OnePlus, LG y Google (5 cada uno), y Fairphone (4). Hay pues bastantes probabilidades de que tu teléfono esté ahí — con trabajo pendiente, que es precisamente el interés.

Si quieres un teléfono que funcione, no un banco de pruebas

Es otra necesidad, y tiene otras respuestas. Ubuntu Touch anuncia 111 aparatos compatibles, con un porcentaje de funcionalidad por aparato. Los mejor servidos:

El Fairphone 4 es el punto de equilibrio de todo esto: está a la vez en community en postmarketOS y al 97,3 % en Ubuntu Touch, y es además el teléfono más reparable del mercado. Si alguien me preguntara qué comprar para hacer esto en serio, sería ese — o el Fairphone 5 si el objetivo es sobre todo usarlo.

Y si quieres quedarte en Android saliendo de la órbita de Google, GrapheneOS sigue siendo la respuesta más sólida — pero solo en Pixel 6 y posteriores, con siete años de actualizaciones garantizadas en los Pixel 8, 9 y 10. La alianza con Motorola anunciada en agosto de 2026 debería levantar esa exclusividad en 2027; la lista oficial, hoy, sigue siendo exclusivamente Pixel.

Cómo comprobarlo con el tuyo

Busca el nombre en clave de tu aparato — no su nombre comercial — en el wiki de postmarketOS y en devices.ubuntu-touch.io. El nombre en clave se lee con un solo comando, con el aparato conectado por USB:

adb shell getprop ro.product.device

En el mío responde sargo. Y dos condiciones previas valen para todo el mundo, diga lo que diga la lista: el gestor de arranque debe poder desbloquearse, lo que excluye la mayoría de los aparatos vendidos por operadores estadounidenses; y la operación lo borra todo.

Lo que me llevo

La parte técnica es casi anecdótica. Me quedan tres cosas.

La trampa no está en ninguna parte. La suspensión automática USB no se menciona en ninguna guía de instalación. Quien la encuentra ve un comando que se cuelga sin mensaje, prueba otro cable, otro puerto, y concluye que su hardware tiene la culpa. Abandona. La corrección son dos líneas y vale para todos los Pixel. Es lo que voy a escribir primero — antes que cualquier código, antes que la cámara. Una tarde perdida por mí puede ahorrar muchas a otros, y es probablemente la contribución más rentable de toda la historia.

Busqué en el sitio equivocado durante una hora. No por falta de método, sino porque seguía interrogando al aparato — reintentar el comando, cambiar un parámetro, volver a probar — en lugar de interrogar al sistema que gobernaba el aparato. La respuesta estaba en un fichero de texto de nueve caracteres. Cada vez que una herramienta calla en lugar de fallar, hay que dejar de relanzarla e ir a leer el estado de la capa de abajo.

Y luego está el fondo. Este teléfono lleva grabado en la trasera un contenedor tachado, ese pictograma que significa que no se tira con la basura. El símbolo está ahí desde 2019, obligatorio, decorativo. Esta noche se ha vuelto exacto: el aparato no ha ido al vertedero, funciona, y funciona con un núcleo más reciente que el de muchas máquinas en servicio.

No es una proeza técnica — gente mucho más competente hizo el trabajo difícil, el de portar un núcleo moderno a este chip. Yo solo he seguido sus huellas y he tropezado con una trampa que no habían documentado. Pero es una demostración: el fin de soporte no es una propiedad del hardware. Es una decisión. Y cuando el fabricante deja la puerta abierta — como hace Google en los Pixel, hay que reconocérselo —, esa decisión puede retomarla otro.

Un Pixel 3a de segunda mano se encuentra por unas decenas de euros. Hay millones en los cajones.

Lo siguiente es la cámara.

El banco el tercer día. Todo lo que sirvió de juez: el calibre, un viejo micrómetro en pulgadas, el cubo de 20 mm, los marcos de primera capa, los cuadrados de espesor numerados a rotulador y, detrás, la pieza de siete pilares de la calibración extendida.

Una máquina «siempre un poco decepcionante»

Tengo una impresora delta FLSun QQ-S, comprada en enero de 2020. Una delta es esa impresora en forma de torre triangular en la que la boquilla cuelga de tres brazos articulados que suben y bajan por tres columnas; no hay ejes X, Y y Z separados como en una impresora cartesiana: la posición de la boquilla es el resultado de un cálculo a partir de la altura de los tres carros. Es rápida, silenciosa, elegante, y mucho más sensible a los errores de geometría que una máquina de ejes rectos: un brazo un milímetro demasiado largo o una columna desviada un grado no dan un error simple, sino una deformación en cuenco, en cúpula o en trébol que varía por todo el plato.

Poco usada, esta máquina siempre había sido un poco decepcionante. No catastrófica: las piezas salían. Pero las paredes no tenían consistencia, las cotas estaban desviadas unas décimas, la primera capa nunca agarraba en todas partes, y sobre todo ningún ajuste tenía un efecto claro. Había acabado imprimiendo con una boquilla más gruesa «para que fuera más rápido», cambiando las correas tras destruir un juego por sobretensión, y aparcando la máquina junto a una Bambu Lab que, ella sí, imprime bien sin que se le pida nada.

Esa comparación es lo que lanzó la investigación. No «cómo ajusto mi slicer», sino qué tiene exactamente esta máquina, y qué se puede recuperar. Este artículo cuenta tres días, del 4 al 6 de septiembre de 2026, llevados a cabo con una IA (Claude) que pilota la impresora, escribe las herramientas y lee los manuales, mientras yo sostengo el calibre, la hoja de papel y la cámara. Cuenta también un bonito error de método, el suyo y el mío, porque es lo que pasa cuando se busca de verdad.

El dispositivo

El firmware original iba a ser sustituido por Klipper. Klipper es un firmware de impresora 3D en dos partes: un programa minúsculo en la placa de la impresora, que solo pilota motores y calentadores en tiempo real, y un programa anfitrión, en un ordenador al lado, que hace todo lo demás: la cinemática, las calibraciones, las macros. Se pierde la pantalla táctil de la impresora (Klipper no sabe manejarla), se ganan herramientas de calibración que no existen en ningún otro sitio, en particular para las deltas.

Lo que Klipper aporta, en concreto, frente al Repetier original —o a un Marlin—:

• El cálculo deportado. Un firmware clásico hace toda la cinemática delta en el pequeño microcontrolador de la placa, con las aproximaciones que eso impone; Klipper la hace en el ordenador anfitrión, en coma flotante, y solo envía a la placa instantes de paso precalculados. En una delta, donde cada movimiento es una raíz cuadrada por columna, se nota en la precisión de los movimientos y en la velocidad posible.
• Las herramientas de calibración: DELTA_CALIBRATE, que deduce la geometría completa a partir de siete puntos, con o sin sonda; la calibración extendida de los brazos; la malla del plato; y TUNING_TOWER, que hace variar un parámetro con la altura durante la impresión, para ajustar en una pieza lo que exigiría diez intentos.
• El pressure advance y el input shaper, la compensación de la presión en el bowden y la de las vibraciones, que el firmware original no tiene y que explican la mayor parte de la diferencia de calidad con una máquina moderna.
• Una configuración en archivo de texto, legible, comentable, versionable, donde cada valor tiene su procedencia; y un socket local desde el que se pilota todo con un script.

Lo que no aporta: no eleva el techo de caudal del hotend, no sustituye una mecánica errónea, y necesita un ordenador al lado.

El anfitrión, de momento, es mi portátil conectado por USB; una Raspberry Pi tomará el relevo. Sin interfaz web por ahora: Klipper expone un socket local al que se envían comandos, y la IA escribió en una hora lo necesario para no teclear G-code a mano: un cliente para enviar un comando y leer la respuesta, un script de seguimiento de impresión y, sobre todo, calib.py, un control por teclado donde una tecla es un gesto: h para el homing, s para lanzar la calibración delta, m para la malla del plato, d/u para bajar o subir la boquilla 0,1 mm, [/] para ajustar la primera capa mientras se imprime.

El principio, desde el inicio, es el mismo que en la Bambu: se mide, no se inventa. Cada valor escrito en la configuración procede de una medida en la máquina, y cada corrección va seguida de una pieza de control.

Primero la mecánica: las correas

Antes de tocar el firmware, una auditoría rápida de lo que se mueve. Las correas de esta máquina tienen historia: un primer juego destruido por sobretensión («había leído que nunca había que tensarlas, y es lo que me pasó»), en la época en que «ningún ajuste tenía efecto». Esa frase, con perspectiva, era la firma de un problema mecánico y no de slicer, y es lo que justifica empezar por ahí.

La IA propuso primero el método que se lee en todas partes: pellizcar la correa, medir la nota con una aplicación de guitarra, apuntar a una frecuencia. Tres rondas después, zanjé: «no es una cuerda, si la tenso lo bastante para que suene lo romperá todo». Ella lo comprobó, y yo tenía razón: en esta máquina el tramo libre mide 65 cm, la frecuencia objetivo estaría por debajo de 30 Hz, donde las aplicaciones saltan una octava (yo leía 70 Hz sin caer nunca en el mismo valor). Sobre todo, un artículo de Hackaday recuerda que la calidad de impresión apenas cambia con correas francamente flojas, mientras el eje no se retrase respecto al motor; en cambio, tensar de más rompe ejes de motor (un NEMA 17 admite 28 N de carga radial). No hay compromiso que buscar: ningún beneficio al apretar, un riesgo al apretar.

El método elegido es el que uso desde hace años: aflojar francamente y volver a tensar justo hasta el umbral en que la correa empieza a vibrar blandamente en vez de flotar. Se llega por debajo, así que la sobretensión es imposible; el umbral es exactamente el límite bajo del sin-holgura; el mismo gesto en las tres columnas iguala por construcción. Las seis poleas giraban libres. Auditoría cerrada. Veremos más adelante que este retensado, hecho en el momento equivocado, salió caro de todos modos.

Lo que la máquina tenía dentro

Antes de flashear había que leer la memoria del firmware original: los valores que usaba son el punto de partida de la configuración Klipper, y una vez flasheada, ya no se pueden leer. Primera sorpresa, al conectar el USB: no es Marlin. Todo lo que se lee sobre la QQ-S da por hecho Marlin, y la IA había preparado los comandos Marlin (M503 para leer la configuración, M665/M666 para la geometría delta). Respuesta de la máquina: Unknown command. El firmware se anuncia como FIRMWARE_NAME:Robin y es Repetier, que vuelca su memoria con M205. Primera lección, no la última: comprobar antes de afirmar.

El volcado, 970 m de filamento y 233 horas de máquina, dio dos cosas.

Primero los valores reales: brazos 278,6 mm (la config Klipper de referencia dice 280), radio delta 140,8 (la referencia dice 130 — diez milímetros de diferencia, suficiente para una cúpula monstruosa si hubiéramos tomado la referencia), altura 376,03, 100 pasos/mm en las columnas y 367 pasos/mm en el extrusor (recuerden esa cifra).

Después, una constatación que ya explicaba mucho: todos los términos de corrección por columna estaban a cero. Radio delta A/B/C, corrección de diagonal A/B/C, todo a cero. Esta máquina nunca había sido calibrada finamente como delta — o lo había sido en fábrica y lo perdió en una actualización del firmware, que reinicia la EEPROM: es mi hipótesis, y la EEPROM no guarda historial para zanjarla. En ambos casos, sus errores de geometría, fueran los que fueran, llevaban años intactos, y los pasos del extrusor probablemente venían del mismo reinicio.

Klipper, y unos motores sin fuerza

El flasheo en sí no tiene historia: Klipper compilado para el STM32F103 de la placa MKS Robin Mini, con un bootloader de 28 KB, un cristal de 8 MHz y el puerto serie USART3; el binario pasado por el pequeño script update_mks_robin.py de Klipper que lo codifica en el formato que espera el bootloader MKS; copiado en una tarjeta SD de 4 GB en FAT32, impresora apagada al insertarla. Un pitido, «complete» en verde, y Klipper responde Klipper state: Ready.

Y entonces el primer homing falló. No trigger on stepper_b after full movement: un carro no llegó a su interruptor. El segundo homing también, en otra columna. Los motores gruñían, subían a 5 mm/s, se calaban a 25, y bajaban «blandamente».

Lo que siguió es más una lección que un relato. La IA fue encadenando hipótesis —duración de los pulsos de paso, modo de micropasos, correas, un potenciómetro de corriente que no existe en esta placa—, cada una probada, cada una descartada, y cada prueba alargaba la conversación sin añadir información. Es un comportamiento que conviene conocer al trabajar con una IA: cuanto más se llena su ventana de contexto de intentos fallidos, más se desliza hacia el siguiente intento en vez de volver a los hechos. Lo que la detuvo cabe en una frase, una restricción fuerte: «antes del flasheo, todo funcionaba perfectamente». La víspera, con Repetier, la misma mecánica funcionaba; el hardware quedaba descartado por construcción, y la única pregunta válida pasaba a ser: ¿qué hacía el firmware antiguo que el nuevo no hace?

Entonces hizo lo que debería haber hecho primero: leer el archivo de pines de esta placa en las fuentes de Marlin, pins_MKS_ROBIN_MINI.h, y buscar todo lo que el firmware antiguo inicializaba al arrancar. Y ahí:

MOTOR_CURRENT_PWM_XY_PIN  PA6
MOTOR_CURRENT_PWM_Z_PIN   PA7
MOTOR_CURRENT_PWM_E_PIN   PB0
MOTOR_CURRENT_PWM_RANGE   1500
DEFAULT_PWM_MOTOR_CURRENT { 800, 800, 800 }

En la Robin Mini, la tensión de referencia que fija la corriente de los motores no se ajusta con un potenciómetro: la genera el microcontrolador, como señal PWM en tres pines. Repetier las fijaba al arrancar. Klipper las dejaba flotando: referencia casi nula, par minúsculo, deriva con los minutos («se mueve mejor que al principio»). Y la configuración oficial de Klipper para esta impresora, printer-flsun-qqs-2020.cfg, no contiene esas líneas (en el momento de escribir esto). Quien siga esa configuración en una Robin Mini tiene los motores subalimentados.

La corrección son tres bloques de configuración: una salida PWM hardware por pin, 800 en una escala de 1500, a 1 kHz, el valor por defecto de Marlin. Homing inmediato, tres columnas disparadas, velocidad normal. «¡Movimiento perfecto!»

[output_pin motor_current_ab]
pin: PA6
pwm: True
hardware_pwm: True
cycle_time: 0.001
scale: 1500
value: 800

[output_pin motor_current_c]
pin: PA7
# ídem

[output_pin motor_current_e]
pin: PB0
# ídem

Calibrar una delta sin sonda

La sonda de la máquina no estaba. No importa: la documentación de Klipper recomienda de todos modos la calibración manual en una delta, porque una sonda montada al lado de la boquilla introduce su propio error cuando el efector se inclina. El método es la hoja de papel: DELTA_CALIBRATE METHOD=manual envía la boquilla a 2 mm sobre siete puntos del plato, uno en el centro y seis en círculo; en cada punto se baja la boquilla en pasos de 1 mm, luego 0,1, luego por bisección, hasta que una hoja de papel de 0,1 mm roza justo entre la boquilla y el cristal; se valida, la boquilla va al punto siguiente. Siete puntos, un cuarto de hora. Klipper calcula después los parámetros que ponen esos siete puntos en un plano.

La pieza calibrate_size.stl que viene con Klipper, para la calibración extendida de los brazos. Se imprimirá pero no se usará: veremos por qué.

El primer resultado, el 4 de septiembre por la tarde: radio delta 141,18 (la EEPROM decía 140,8), y sobre todo ángulo de la columna A a 211,02° y de la columna B a 330,45°, en lugar de los 210° y 330° nominales. Un grado en A. Es enorme para una delta, y era el defecto «que ningún ajuste corregía»: un ángulo de columna erróneo alabea las piezas y deforma el plato en trébol, y ningún ajuste de slicer, ninguna malla de plato, lo compensa.

A continuación, la bed mesh, la malla del plato: BED_MESH_CALIBRATE METHOD=manual, el mismo gesto con papel en 13 puntos, para corregir lo que el cristal tiene de no plano. Rango 0,51 mm, dominado por los dos bordes del eje Y. Guardada, cargada al inicio de cada impresión. Calibración en frío terminada.

Fíjense en este detalle: la malla se midió en frío, y yo retensé las correas entre la calibración delta y su verificación. Volveremos a ello.

El extrusor mentía un 11,5 %

La prueba más sencilla del mundo, y nunca la había hecho en seis años: una raya de rotulador en el filamento a 120 mm de la entrada del extrusor, se pide a la máquina que avance 100, se mide lo que queda. Esperado: 20 mm. Medido: 31,5 mm. La máquina había empujado 88,5 mm de los 100 pedidos.

Los 367 pasos/mm de la EEPROM, trasladados fielmente a Klipper (rotation_distance 8,719), estaban mal en un 11,5 %. Corregido a 7,716, contrastado con una segunda prueba: 20,0 mm restantes, «¡perfecto!».

Midan lo que eso significa: a cada capa que esta máquina depositó le faltaba una décima parte de su material. Paredes débiles, uniones abiertas, superficies irregulares, mala adhesión entre capas: todo lo que yo achacaba a «la delta» o «el PETG». Y ningún ajuste de slicer compensa un error que se ignora: se puede subir el flujo al 110 % al azar, no se sabe por qué, y no se mantiene de un filamento a otro.

Con los ángulos de columna y la corriente de motor, son tres defectos de fábrica — de fábrica o de una actualización de firmware que lo puso todo a cero, la máquina no dirá cuál — nunca vistos.

PID, PETG húmedo y la primera impresión

Las regulaciones de temperatura (PID) se recalibran en diez minutos, pero la de la boquilla hizo saltar la protección térmica de Klipper: heater extruder not heating at expected rate. La curva mostraba un calentamiento perfectamente sano (27 → 234 °C en 95 s), y luego una inercia inusual entre el bloque y su termistor que hace creer a la protección que el calentamiento se detiene. Sin desactivar nada: una ventana ampliada en [verify_heater extruder], documentada en la configuración.

Luego la primera pieza, en PETG, el que vivía en la máquina desde hacía siglos. El cubo salió… así:

El primer cubo, en PETG. Crepitaba en la boquilla durante la impresión: la bobina estaba saturada de agua. Las paredes son espuma.

No es la impresora: es el filamento. El PETG es higroscópico, y una bobina dejada al aire durante años crepita en la boquilla (el agua se vaporiza) y sale espumosa. Buena parte de la «fiabilidad decepcionante» de esta máquina era eso. Bobina de PLA nueva para toda la calibración; el PETG pasará por la secadora de filamento.

En PLA, el square.stl de Klipper (un marco de un milímetro de pared, cinco milímetros de alto, seis minutos): pared 1,00 mm, altura 5,00. Y el primer cubo de control: Z 20,00 · X 20,40 · Y 20,45. La altura es perfecta: las columnas están bien. El exceso del 2 % en XY lo resolveremos al final.

square.stl: la prueba de primera capa y de caudal de Klipper. Pared de 1,00 mm clavada.

El pie de un marco, muy de cerca: el pequeño labio que sobresale en la base dice que la primera capa está un poco demasiado aplastada. Con esta prueba se ajusta el desfase de primera capa, en pasos de 0,05 mm, durante la impresión.

Pressure advance

Último ajuste antes de atacar el plato: el pressure advance. En una máquina bowden (el motor del extrusor está en el chasis, un tubo largo lleva el filamento hasta la boquilla), la presión en el tubo tarda en subir y en bajar; sin compensación, las esquinas se hinchan y los finales de línea babean. Klipper compensa empujando un poco más antes de las aceleraciones y retirando antes de las deceleraciones, con un solo parámetro. Se mide con una torre de prueba en la que el parámetro aumenta con la altura (TUNING_TOWER), y se busca a ojo la altura en la que las esquinas son más nítidas.

La torre square_tower.stl: abajo, poca compensación, las esquinas se hinchan; arriba, demasiada, se hunden. La mejor esquina está a 19 mm.

Mejor esquina a 19 mm, paso de 0,020 por milímetro: pressure advance 0,38, en el rango esperado para un bowden. Grabado.

La espiral, o cómo ver la primera capa

Para juzgar el nivelado necesitaba algo mejor que la hoja de papel: recordaba un objeto en espiral que se imprime para ver la primera capa de un vistazo. En vez de buscar un archivo laminado para otra máquina, la IA generó el G-code directamente: una sola línea continua, en espiral de Arquímedes, del centro hasta 120 mm de radio, una vuelta cada 2,5 mm, una sola capa de 0,2. Doce minutos. Donde la boquilla está demasiado cerca, el cordón queda aplastado, plano, translúcido; donde está demasiado lejos, queda redondo, estrecho, mal pegado. En un plato redondo, es la prueba más legible que existe.

La primera espiral. Tres lóbulos brillantes a 120° uno de otro: la firma de una geometría delta, no de un plato alabeado.

La primera espiral mostraba un trébol de tres lóbulos. Un cristal alabeado no hace un trébol; una delta mal calibrada, sí. Y sin embargo la calibración acababa de hacerse. La conclusión correcta habría sido: la geometría aún no está bien, repetir la calibración. Tomamos el otro camino.

La pista falsa: dos días corrigiendo la malla

Mi petición era razonable: «una impresión con un espesor predeterminado sería más pertinente que la prueba de la hoja». La IA construyó el método: imprimir un cuadrado de una capa en cada uno de los 13 puntos de la malla, medir su espesor, y corregir cada punto de la malla según su desviación de la media. Un cuadrado más grueso que los demás = la boquilla estaba más alta ahí = el plato está más bajo ahí de lo que la malla cree = se baja el punto. Escribió el script (fix-mesh.py) que hace el homing, coloca la boquilla a 100 mm sobre cada cuadrado para identificarlo («¿cómo saber cuál es cuál?» — el logo no es una referencia), registra las medidas, reescribe la malla. Como mi micrómetro está graduado en pulgadas, se introducen milésimas (13t).

Pasada 1: trece cuadrados de 20 mm, una capa, uno por punto de la malla.

El micrómetro, graduado en pulgadas: una marca del cilindro son 25 milésimas, el tambor da la unidad. 13 thou = 0,33 mm.

El instrumento en sí: un Lufkin Rule Co. de Saginaw, Michigan, n.º 1941. Tiene más años que yo y sigue midiendo a la milésima de pulgada. Entre sus topes, una capa de PLA.

Funcionaba. Pasada 1: rango de espesores 0,30 mm. Pasada 2: 0,084 mm. La espiral siguiente era claramente mejor, el trébol se difuminaba. Luego pasamos a una malla más fina, 7×7 (29 puntos, paso de 40 mm en vez de 55), porque los defectos restantes parecían caer entre los puntos. Pasada 3, pasada 4, ganancia reducida para no oscilar. Y en cada espiral, volvían las mismas zonas, atenuadas pero en el mismo sitio.

Espiral 3, anotada por mí: rojo = demasiado cerca (raspado), azul = demasiado lejos (no pegado). Cinco manchas, ya sin trébol claro.

Espiral 4, tras la malla 7×7: dos zonas rojas en vez de cinco, el azul siempre en la misma esquina.

Malla 7×7, 29 cuadrados de 10 mm. Dos cuadrados de la izquierda están arrancados: demasiado cerca. El micrómetro, sin embargo, los medía «gruesos».

Ahí es cuando dije lo que había que decir: «para mí el error es muy repetible en las tres últimas espirales. Falta material en las mismas zonas y las correcciones han mejorado las cosas pero no corrigen realmente el fondo del problema.» Tres pasadas de corrección deberían haber bastado. Algo independiente del ajuste se resistía.

Espiral 5: rojo, casi sin filamento; rosa, ligera falta; azul, no pegado. Las mismas zonas, otra vez.

Dos macros lo zanjaron. En la zona azul, el cordón es redondo, estrecho, depositado sin presionar, y la transición es progresiva a lo largo de 25 mm hacia el borde: la boquilla se aleja regularmente al ir hacia el borde. En la zona roja, los cordones son anchos, planos, translúcidos, aplastados hasta ser una película: se ven los puntos del plato a través. Demasiado cerca, de verdad.

Zona azul: cordón redondo, sin presionar, que ondula y hace nudos donde ha agarrado. Demasiado lejos.

Zona roja: cordones aplastados, translúcidos, se ve el plato a través. Demasiado cerca, sin discusión.

Y ahí está la contradicción: en esas zonas rojas, los cuadrados medían un espesor normal. La explicación, una vez que se ve: un cuadrado impreso demasiado cerca forma un labio levantado en todo su contorno, y los topes del micrómetro, seis milímetros de diámetro, se apoyan en ese labio. Lee «grueso» exactamente donde está aplastado. El método de los cuadrados estaba sesgado en la dirección precisa que impedía converger. Dos conclusiones de la IA construidas sobre esas medidas («la boquilla está a 0,4 mm del cristal de media», «hay que bajar el cero global») cayeron con él.

Quedaba la pregunta de fondo: ¿por qué zonas tan repetibles? Mi pista eran las correas. La IA escribió una prueba de repetibilidad (tecla R: mismo punto, cinco aproximaciones por caminos distintos, hoja de papel): repetible a 0,1 mm fuera cual fuera el camino. Correas y holgura descartadas. Pero esa prueba dio otra cosa: en esos puntos, la hoja rozaba a Z = +0,2 y +0,6 mm — la máquina creía que el plato estaba medio milímetro más bajo de lo que está. Y la propia malla llevaba una pendiente de 0,65 mm de delante atrás, que nada justifica en una delta calibrada.

La causa estaba en la secuencia del primer día. La calibración delta se había hecho en frío; entre esa calibración y su verificación, yo había retensado las correas; la verificación había mostrado un desfase, y la IA había aplicado +0,4 mm uniforme a los tres topes. Pero el retensado había desplazado las tres columnas desigualmente. El residuo, una pendiente inclinada, se fue a la malla, y una malla de delta nunca vuelve plana una pendiente: deja lóbulos, que cuatro pasadas de cuadrados al micrómetro persiguieron sin atraparlos.

La llegada: rehacerlo todo en caliente, con papel

Plato a 60 °C, boquilla fría, malla vaciada. DELTA_CALIBRATE manual, siete puntos con papel, quince minutos. El veredicto está en los topes:

Los ángulos apenas se movieron (A 211,02 → 210,93, B 330,45 → 330,33), el radio tampoco (141,18 → 141,29). La geometría aguantaba. Lo que estaba mal eran los topes, desigualmente: 0,38 mm de diferencia entre A y B. Exactamente la pendiente que llevaba la malla.

Guardar, homing, y luego la malla con papel en los 29 puntos, media hora. Centro plano a ±0,1 mm en 80 mm de radio; el borde delantero se hunde 0,6 mm a 120 mm del centro — es el propio cristal, o la delta al final de su alcance, y esta vez está medido directamente y la malla lo sabe. Luego la espiral:

Espiral 6, la primera con geometría y malla coherentes, ambas medidas en caliente. Uniforme de borde a borde, borde delantero incluido.

El cordón, con lupa: regular, mismo ancho de una vuelta a otra, pegado en todas partes.

Seis espirales, y la buena fue aquella en la que dejamos de corregir y recalibramos, en treinta y cinco minutos, con un solo método.

Quedaba una última trampa, de la misma familia: el desfase de primera capa, +0,07 mm, se había ajustado el primer día sobre el cero frío. Sobre el nuevo cero, en caliente, el cubo de control no se pegó. Un cero nuevo implica reajustar el desfase de primera capa, nunca arrastrar el antiguo. Marco de prueba, ajuste en directo en pasos de 0,05: −0,10 apenas pega, −0,20 pega con un labio de 0,3 mm en el pie; grabado a −0,15.

El cubo de control relanzado con el antiguo desfase de primera capa: no se pegó. El cero había cambiado, el desfase no.

Y el cubo, por fin: 20,3 × 20,4 × 20,00, labio de 0,1 mm por lado. El primer día medía 20,40 × 20,45 × 20,00. El exceso en XY no se movió con la geometría, porque no es geometría: la pieza de siete pilares, medida con el calibre, daba una distancia entre ejes de 65,0 ± 0,4 mm sobre 65 nominales, es decir una escala correcta al 0,5 %; un error de brazos habría dado +1,3 mm ahí. Lo que queda es un exceso constante de ancho de cordón —esquinas que se hinchan, pared de 1,07 para 1,00— y eso se ajusta en el laminado como en cualquier máquina: multiplicador de extrusión 0,95, compensación XY −0,1 mm, compensación de pie de elefante 0,1 mm, en un perfil de producción separado del perfil bruto de pruebas. La calibración extendida de los brazos, larga y delicada, no era necesaria. Cubo de control con ese perfil: 20,0 × 20,1 × 20,0.

Lo que me llevo

Calibrar en el estado en que se imprime. En caliente. Una máquina calibrada en frío describe un plato que ya no existe cuando llega el PLA.

Un solo método de medida, de principio a fin. El papel para la geometría, el papel para la malla, el marco de prueba para la primera capa. Cada cambio de método introdujo un sesgo que nadie veía.

La geometría primero, la malla después, nunca al revés. Una malla que no converge en dos pasadas no necesita más puntos: está compensando un error que no es suyo. Y cualquier retensado de correas pone la geometría de nuevo en juego: repetir s y luego m, sin atajos.

Cuando dos medidas se contradicen, se va a mirar. La lupa sobre el cordón zanjó en un minuto lo que cuatro pasadas de micrómetro no habían resuelto. Una medida no es una verdad, es un instrumento con sus puntos ciegos.

La IA sobreingenieriza cuando entiende mal. El script de corrección de malla por cuadrados al micrómetro era ingenioso, estaba bien hecho, era persistente, con reanudación y correcciones — y optimizaba una mala idea. Fui yo quien dijo «es repetible, no es el ajuste», y fue la macro la que zanjó. En cambio, ella encontró en una lectura lo que seis años de foros no habían encontrado: la corriente de motor por PWM, el extrusor desviado un 11,5 %, la calibración nunca hecha.

«Antes funcionaba» es un dato. Dos veces en esta historia, mi juicio sobre mi máquina valió más que un método leído en otra parte: sobre la tensión de las correas, sobre el homing. Y dos veces, la IA acabó comprobándolo y dándome la razón, con fuentes. Ese es el reparto correcto: ella lee rápido, no mide por mí.

Dónde estamos

Para reproducir

Material: una FLSun QQ-S de 2020 (placa MKS Robin Mini) —el planteamiento vale para cualquier delta, los pines no—; un ordenador con Linux y un puerto USB; una tarjeta SD ≤ 8 GB en FAT32; una hoja de papel de 80 g; un calibre; una bobina de PLA seca. Sin sonda, sin acelerómetro.

Antes de flashear, leer la memoria del firmware original (en Repetier: M205; en Marlin: M503) y guardar el volcado. Anotar en particular la longitud de los brazos, el radio delta, la altura y los pasos/mm del extrusor.

Firmware: Klipper, make menuconfig → STM32F103, bootloader 28 KiB, cristal 8 MHz, USART3 (PB11/PB10), 250000 baudios; luego scripts/update_mks_robin.py out/klipper.bin Robin_mini.bin; el archivo en la raíz de la tarjeta SD, impresora apagada al insertarla, encender, esperar «complete». El bootloader renombra el archivo a .CUR. El script build-firmware.sh lo hace todo.

Configuración: printer.cfg, con sus valores reales y sus comentarios. Los tres bloques [output_pin motor_current_*] son imprescindibles en una Robin Mini. El bloque SAVE_CONFIG al final del archivo contiene los resultados de las calibraciones; para empezar de cero, borrarlo y volver a poner los valores de la EEPROM en [stepper_a/b/c] y [printer].

Herramientas: start-klipper.sh (arrancar el anfitrión), send-gcode.sh y klippy-client.py (enviar un comando), calib.py (control por teclado de las calibraciones), watch-print.py (seguimiento de impresión), make-spiral.py (la espiral). Los perfiles de PrusaSlicer en línea de comandos están en slicer/: qqs-pla.ini bruto para las pruebas, qqs-pla-prod.ini para las piezas.

En orden, en caliente (plato a la temperatura de impresión, boquilla fría para el papel):

Tres reglas, si se ponen a ello: en caliente, un solo método de medida, y cualquier intervención mecánica (correas, brazos, plato) devuelve al paso 2. Si una malla no converge en dos pasadas, no añadir puntos: rehacer la geometría.

Leer la espiral: rojo = demasiado cerca (cordón plano, translúcido, raspado), azul = demasiado lejos (cordón redondo, mal pegado). Un trébol de tres lóbulos = geometría; manchas locales = plato o malla; un borde que se hunde progresivamente = el cristal o la delta al final de su alcance. En caso de duda, la lupa.

Preguntas frecuentes

¿Hace falta una sonda para calibrar una delta con Klipper?

No. La documentación de Klipper recomienda la calibración manual con papel en las deltas, porque una sonda desplazada respecto a la boquilla introduce su propio error cuando el efector se inclina. Siete puntos para la geometría, de trece a veintinueve para la malla, media hora en total.

Mis motores gruñen y el homing falla tras pasar a Klipper en una MKS Robin Mini. ¿Por qué?

Porque la corriente de los motores se fija por PWM desde el microcontrolador (pines PA6, PA7, PB0) y la configuración oficial de Klipper para la QQ-S no lo hace. Tres bloques [output_pin] en PWM hardware, valor 800 sobre 1500, resuelven el problema. Ver Klipper, y unos motores sin fuerza.

¿Mi FLSun QQ-S lleva Marlin?

La QQ-S de 2020 no: lleva Repetier (FIRMWARE_NAME:Robin). M503, M665, M666, M900 responden Unknown command; es M205 el que lee la memoria. Los tutoriales de Marlin no aplican.

Mi malla del plato no converge, ni siquiera tras varias pasadas. ¿Necesito más puntos?

Casi nunca. Una malla que no converge suele estar compensando un error de geometría (topes desiguales, ángulo de columna) o una calibración hecha en frío. Rehacer DELTA_CALIBRATE en caliente, luego la malla, con el mismo método de medida.

¿Cómo sé si mi extrusor empuja la cantidad correcta?

Una raya en el filamento a 120 mm de la entrada del extrusor, M83 y luego G1 E100 F60, medir lo que queda: 20 mm esperados. Aquí quedaban 31,5: un 11,5 % de subextrusión desde siempre. Nuevo rotation_distance = antiguo × extruido / 100.

¿Es bueno el método de los cuadrados de espesor al micrómetro?

Está sesgado donde la boquilla está demasiado cerca: el cuadrado aplastado forma un labio levantado en su contorno, y el micrómetro lo lee «grueso». Si se empeñan, cuadrados de 20 mm medidos en el centro, topes lejos del borde. La espiral y el papel son más fiables.

¿Hay que tensar las correas de una delta a una frecuencia precisa?

No. La frecuencia depende de la longitud del tramo, de la masa y de la composición de la correa; una misma nota no significa una misma tensión de una máquina a otra, y en una QQ-S el tramo es demasiado largo para medirlo. Aflojar, y volver a tensar hasta el umbral en que la correa vibra blandamente en vez de flotar, en las tres columnas. Y rehacer la calibración delta después.

El cubo mide 20,3 en vez de 20,00 en XY: ¿debo calibrar los brazos?

No si el exceso es constante. Compruébenlo en una pieza mayor (la pieza de siete pilares de Klipper, 65 mm entre ejes): si la escala es correcta, el exceso viene del ancho de cordón y se corrige en el slicer (multiplicador de extrusión, compensación XY). La calibración de los brazos corrige un error de escala, no un exceso constante.

¿Qué hizo exactamente la IA, y qué hizo el humano?

Claude leyó la EEPROM y el archivo de pines de la placa, compiló y preparó el firmware, escribió la configuración y todos los scripts, generó la espiral, condujo las calibraciones y redactó este artículo conmigo. Se equivocó sobre el firmware (Marlin), sobre la causa del homing (varias horas), sobre la tensión de las correas y sobre el método de los cuadrados. Yo sostuve la hoja de papel, el calibre, el micrómetro y la cámara; leí las espirales; dije «antes funcionaba», «no es una cuerda» y «es repetible, no es el ajuste». Las tres veces era la pista correcta.

Pequeño glosario

• Delta: impresora en la que la boquilla va sujeta por tres brazos articulados sobre tres carros verticales; la posición se calcula, no se mide eje por eje.
• Efector: la pieza central que lleva la boquilla, al extremo de los brazos.
• Brazos (arm_length), radio delta (delta_radius), ángulo de columna, tope (position_endstop): los parámetros de la geometría; ver el recuadro «qué corrige cada ajuste».
• Homing: enviar los carros arriba hasta sus interruptores, para conocer su posición.
• Bed mesh (malla del plato): mapa de alturas del plato, medido en unos pocos puntos, que el firmware interpola para corregir la boquilla en continuo.
• Prueba del papel: bajar la boquilla hasta que una hoja de 0,1 mm roza justo; el Z = 0 queda entonces 0,1 mm por encima del cristal.
• Desfase de primera capa: pequeño desplazamiento en Z aplicado al inicio de cada impresión para ajustar el aplastamiento de la primera capa.
• Rotation distance: en Klipper, la distancia recorrida (o de filamento empujado) por vuelta de motor; sustituye a los pasos/mm.
• Pressure advance: compensación de la presión en el tubo bowden, que limpia las esquinas.
• PID: la regulación de temperatura; se recalibra con PID_CALIBRATE.
• Bowden: configuración en la que el motor del extrusor está en el chasis y empuja el filamento por un tubo largo hasta la boquilla; ligero para el efector, pero elástico.
• Thou: milésima de pulgada, 0,0254 mm. Los micrómetros antiguos están graduados así.
• Labio / pie de elefante: reborde en la base de una pieza, señal de una primera capa demasiado aplastada.
• PWM: señal cuadrada cuya anchura se modula; sirve aquí para fabricar una tensión de referencia para la corriente de los motores.
• EEPROM: la memoria del firmware original donde guarda sus ajustes.

Referencias y copias locales

Para que este artículo siga siendo útil cuando los enlaces hayan desaparecido, los archivos del proyecto están alojados aquí.

• Klipper, documentación: Delta Calibrate · Bed Mesh · Bed Level · Manual Level · Pressure Advance · Resonance Compensation · Config Reference. Las piezas de prueba (square.stl, square_tower.stl, calibrate_size.stl, ringing_tower.stl) están en docs/prints/ del repositorio.
• Configuración Klipper de referencia para la QQ-S 2020 — printer-flsun-qqs-2020.cfg (sin las salidas de corriente de motor, a 6 de septiembre de 2026).
• Pines de la MKS Robin Mini en Marlin — pins_MKS_ROBIN_MINI.h (origen de los pines PWM de corriente).
• Hackaday, «Don’t Tune Your 3D Printer To Middle ‘C’ After All» — sobre la tensión de correas por frecuencia (búsqueda en el sitio).
• PrusaSlicer 2.8.1, última versión con AppImage para Linux — releases. Ejecutado en línea de comandos sin pantalla (env -u DISPLAY); añade sus propios comandos de calentamiento salvo si encuentra M104/M140 reales en el G-code inicial.
• Los archivos del proyecto: printer.cfg · calib.py · klippy-client.py · send-gcode.sh · start-klipper.sh · watch-print.py · build-firmware.sh · make-spiral.py · perfiles slicer/ · README-flsun.md (el estado de la máquina y el manual del repositorio, en francés).
• Para memoria, la pista falsa: fix-mesh.py, mesh-to-7.py, first_layer_29.stl, y analyze-delta.py para la calibración extendida de los brazos, si algún día fuera necesaria.

Fotos y medidas: mías. Firmware, configuración, scripts y redacción: con Claude. Este artículo también está disponible en Markdown en bruto.

La placa del pack, una vez abierta la funda. Los dos pequeños pads marcados «DA» y «CL», a la derecha, son todo lo que necesitamos. Los grandes del centro, C+ y C−, son los que no se tocan.

Una nube apagada, y luego un botón que muere

Mi robot aspirador es un Neato D800. Un buen robot: un LIDAR giratorio (un pequeño radar láser que gira en la parte superior y mide las distancias a las paredes), un mapa de la casa, líneas prohibidas que se trazan en la aplicación, 600 € en su día. En 2023, Neato Robotics cerró. Vorwerk, la empresa matriz, mantuvo los servidores encendidos durante un tiempo —la «nube», es decir, los ordenadores remotos sin los cuales la aplicación, los mapas y la programación no funcionan— y luego anunció el 6 de octubre de 2025 (copia local) que esa nube se apagaba. « Your Neato robot will continue to function manually. Simply press the button once to launch a full house run. » Un robot de 600 € degradado a aspiradora de un solo botón, por comunicado.

Y luego, unos meses más tarde, el propio botón dejó de responder. Luz roja, error 4202, «batería descargada». La aplicación, en sus últimos estertores, precisaba que el contador de cargas de la batería estaba superado y que había que sustituirla. Batería original: 90 €, cuando se encuentra. Compatible: de 30 a 50 €, con el riesgo, bien documentado en los foros, de que el robot la rechace.

Este artículo cuenta cómo pasamos de «robot muerto, batería muerta» a una batería que explica por sí misma lo que le pasa, sin comprar nada, con tres cables y un microcontrolador que cuesta lo que un café. Cuenta también una falsa esperanza, porque es lo que ocurre cuando se investiga de verdad. Se detiene en lo que esta investigación me habría costado hace tres años, antes de que una IA pudiera leerse un manual de 250 páginas por mí, y en el notable chip que gobierna esta batería. Y explica por qué esta historia me deja un regusto amargo sobre la manera en que fabricamos los objetos.

Primer reflejo: las celdas

Una batería de robot es una carcasa que contiene varias celdas —acumuladores de litio en formato 18650 (18 mm de diámetro, 65 mm de largo, el aspecto de una pila AA grande)— conectadas en serie y gestionadas por una pequeña placa electrónica. Una batería «descargada» que ya no se recarga son, clásicamente, celdas muertas. Así que hice lo que hace cualquier manitas: abrí el pack, desoldé las cuatro celdas, soldé en su lugar cuatro celdas recuperadas —desparejadas, lo que tendrá su importancia más adelante— y lo cerré.

Resultado: error 4202, igual que antes.

Y sin embargo, multímetro en mano (el aparato que mide la tensión, es decir, la «presión» eléctrica, en voltios), todo era perfecto. 4,1 V en cada celda, que es una celda de litio llena; 16,4 V en los bornes del pack; 16,4 V en el conector de salida, lo que significa que el circuito de protección —el interruptor electrónico capaz de aislar las celdas en caso de peligro— dejaba pasar la corriente. El termistor (una resistencia cuyo valor cambia con la temperatura, que el robot lee para vigilar la batería) marcaba 6 kΩ, un valor normal para una habitación templada. El robot tenía entre manos una batería cargada al 95 % y en buen estado, y mostraba «batería descargada».

Es el momento en que uno comprende que el problema no es la batería. Es lo que la batería dice de sí misma.

La batería tiene cerebro

Los packs de los Neato de última generación (D8, D9, D10, D800) son «baterías inteligentes» (smart batteries): junto a las celdas, la pequeña placa lleva un medidor de carga (gas gauge), un chip —un circuito integrado, una minúscula lámina de silicio que contiene un ordenador especializado— de Texas Instruments, el bq40z50-R2. Es él quien mide la corriente, suma lo que entra y lo que sale, deduce el estado de carga, corta en caso de sobretensión o sobrecalentamiento, y es él quien habla con el robot a través de un bus serie: dos cables por los que circulan mensajes digitales, uno para los datos y otro para el reloj que marca el ritmo de la conversación. El protocolo (el idioma que se habla en esos cables) se llama SMBus, primo industrial del I²C que conocen todos los aficionados a Arduino. Un cable azul adicional en el conector del pack lleva esa conversación hasta el robot.

El robot no mide la tensión de la batería. Le pregunta al medidor: «¿a cuánto estás cargada?», «¿qué corriente de carga quieres?», «¿qué tensión?», «¿cuántos ciclos llevas?». Y obedece a lo que responde. Si el medidor dice «0 %» o «no me cargues», el robot muestra «batería descargada», sea cual sea la realidad eléctrica a tres centímetros de ahí.

Esta arquitectura no es absurda: un medidor dentro del pack conoce el historial de las celdas, gestiona su equilibrado (mantener las cuatro celdas al mismo nivel de carga, sin lo cual la más débil se desgasta primero) y protege eficazmente contra la fuga térmica (la reacción en cadena que hace arder una celda de litio maltratada). Pero tiene una consecuencia: sustituir las celdas no pone el medidor a cero. El contador de ciclos, la capacidad aprendida, los indicadores de error (flags: casillas de «sí/no» que el chip marca cuando detecta un problema): todo eso vive en la memoria del chip, no en las celdas. Se cambia el corazón, el cerebro conserva sus recuerdos.

En los foros, la pista suele terminar aquí. Los chips de los packs D3–D7 son de un fabricante oscuro y están bloqueados; para los bq40z50 «hace falta un EV2400 y bqStudio» —el adaptador oficial de Texas Instruments, 150 €, y su software para Windows— y nadie sabe realmente qué datos comprueba el robot. Fin de la historia, compra una batería.

Tres cables y un ESP32 de dos euros

Solo que el bq40z50 es un chip documentado públicamente. Texas Instruments publica su Technical Reference Manual, el manual de referencia: 250 páginas que describen cada registro, cada comando, cada dirección de memoria (copia local del PDF, 1,6 MB). Y el SMBus lo sabe hablar cualquier microcontrolador —un ordenador completo en un chip, unos pocos euros, el que se encuentra en una placa Arduino— en cuanto tiene dos pines I²C.

Tengo un cajón lleno de ESP32-C3 «Super Mini»: una placa del tamaño de un sello, dos euros la unidad, que se conecta por USB y se programa como un Arduino.

En la placa del pack, dos pads de prueba —puntos de contacto dejados a propósito por el fabricante para conectar sus aparatos de control al final de la cadena de montaje— llevan serigrafiadas las marcas DA y CL: data y clock, los dos cables del SMBus. Un cable en DA, otro en CL, otro en el menos de las celdas, y al otro lado los pines GPIO 4, GPIO 5 (GPIO: los pines de entrada-salida numerados de un microcontrolador) y GND (la masa, el «cero voltios» común) del ESP32. Ningún componente que añadir, ninguna alimentación que suministrar: el medidor se alimenta de sus celdas y el ESP32 de su USB.

En cuanto al software, doscientas líneas en Arduino, escritas con una IA (Claude) que se leyó el manual por mí: se leen los registros estándar (tensión, corriente, estado de carga, contador de ciclos, tensiones por celda), luego los registros de estado internos —estado de seguridad, fallos permanentes, estado de los transistores de carga y descarga— y después se copia la memoria flash. No se escribe nada sin una orden explícita. Escuchamos.

Lo que dijo el chip

Primera lectura, en el monitor serie:

Voltage            : 16386 mV
RSOC               : 97 %
RemainingCapacity  : 2343 mAh
FullChargeCapacity : 2437 mAh
DesignCapacity     : 2500 mAh
CycleCount         : 1547
ChargingCurrent    : 0 mA
ChargingVoltage    : 0 mV
Cellules           : 4094 / 4097 / 4100 / 4095 mV
ManufacturerName   : BLUEWAY-
DeviceName         : bq40z50-
ManufactureDate    : 2022-01-09
OperationStatus    : PRES DSG CHG SEC0  -> sécurité : FULL ACCESS
SafetyStatus       : (aucun flag)
PFStatus           : (aucun flag)

Para leer este informe: mV y mA son milivoltios y miliamperios (milésimas de voltio y de amperio); los mAh, miliamperios-hora, miden una cantidad de energía almacenada —2437 mAh es lo necesario para suministrar 2,4 A durante una hora—; RSOC es el porcentaje de batería que se muestra; FullChargeCapacity es lo que el medidor cree poder almacenar hoy, DesignCapacity lo que el pack almacenaba nuevo.

Tres cosas saltan a la vista.

El medidor está en plena forma. Ningún fallo de seguridad, ningún fallo permanente, transistores de carga y descarga conduciendo (los transistores, o FET, son los interruptores electrónicos con los que el medidor autoriza o corta la carga y la descarga), estado de carga estimado en el 97 %, coherente con los 4,1 V por celda. No está «descargada», y lo sabe.

Ni siquiera está bloqueado. El nivel de seguridad es FULL ACCESS: el modo más permisivo del chip, el que TI recomienda abandonar antes de salir de fábrica. Sin contraseña que romper, sin clave que adivinar. Toda la memoria es legible y escribible. El fabricante del pack entregó la casa con las llaves puestas en la puerta.

Y sin embargo le dice al robot que no la cargue. ChargingCurrent = 0 mA, ChargingVoltage = 0 mV. Son los dos registros que un cargador inteligente lee para saber qué hacer. A cero, significan: «no envíes corriente».

Y el contador: 1547 ciclos. Un ciclo, para un medidor, es una descarga acumulada equivalente a una batería entera: dos medias descargas hacen un ciclo. Para una batería fabricada en enero de 2022, es un ciclo al día durante cuatro años, plausible para un robot que pasa a diario. Es también el número que la aplicación me había reprochado.

Diecisiete mil líneas de manual, y una falsa esperanza

La pregunta pasa a ser: por qué el medidor rechaza la carga. El manual de TI enumera con precisión los casos en que ChargingVoltage() cae a cero: transistor de carga cortado por una protección, temperatura fuera de rango, fallo permanente, pack declarado «retirado», sobretensión del cargador detectada. Los comprobamos todos, registro a registro. Ninguno estaba activo. Temperatura 26 °C, región de temperatura «recomendada», región de tensión «alta», todo en verde.

Exploramos también una pista seductora: el bq40z50 tiene una función de degradación por contador de ciclos, que reduce voluntariamente la tensión y la corriente de carga a medida que el pack envejece: una obsolescencia programada en sentido literal, activable con un bit de configuración. Leímos ese bit en la memoria flash. Estaba a cero. Neato no la había activado. La tabla de carga decía 4,2 V por celda y 1,5 A en todos los rangos de temperatura. Sobre el papel, el medidor debía anunciar 16,8 V y 1500 mA. Anunciaba 0 y 0.

Antes de ir más lejos, hicimos lo que siempre hay que hacer antes de tocar una memoria que no se podrá volver a comprar: una copia de seguridad completa. 8 KB, 256 bloques de 32 bytes (un byte son ocho bits, la unidad mínima de memoria), leídos uno a uno y guardados en un archivo (aquí está, por si el tuyo es el mismo pack). Si una escritura sale mal, se puede restaurar todo.

Luego probamos la cosa más tonta del mundo. El manual documenta un comando 0x0041 : Reset —reinicio del chip: su memoria RAM (la memoria de trabajo, que se borra en cada reinicio) se reconstruye desde la flash, no se escribe nada—. El equivalente de «¿has probado a apagarlo y volverlo a encender?». Una letra r enviada por el monitor serie, tres segundos de espera:

>>> Envoi MAC 0x0041 Reset
ChargingCurrent    : 1500 mA
ChargingVoltage    : 16800 mV
RSOC               : 97 %
FET DSG ON, FET CHG ON, PF inactif

Victoria, creímos. Pack montado de nuevo, robot en su base: se acabó el error, carga, anuncia que está listo. Escribí una primera versión de este artículo esa misma noche, con una conclusión triunfal sobre el contador de ciclos del que «el robot nunca se había preocupado».

A la mañana siguiente, luz roja, error 4202.

El síntoma que desaparece cuando se le mira

Pack conectado de nuevo al ESP32. ChargingCurrent : 0 mA, otra vez. Reinicio: 1500 mA. Y ahí, en lugar de cantar victoria, lo dejamos correr y miramos el reloj.

A los 3 segundos: 1500 mA. A los 20 segundos: 1500 mA. A los 31 segundos: 0 mA, y en la misma lectura un indicador que no estaba diez segundos antes: SLEEP. Dos intentos, dos lecturas completas comparadas línea a línea: entre los 20 y los 31 segundos, lo único que cambia es ese indicador.

El medidor se duerme. En cuanto casi no circula corriente (menos de 10 mA, umbral fijado en su configuración), pasa a reposo para ahorrar sus celdas, y en ese estado anuncia «corriente de carga: 0». El reinicio no reparaba nada: lo despertaba treinta segundos. En el banco de trabajo, con un ESP32 que no consume nada, se volvía a dormir enseguida. En el robot, que tira unos cientos de miliamperios, está despierto y anuncia 1500 mA. El «no me cargues» nunca fue el problema. Era un espejismo de laboratorio.

El laboratorio de la mañana siguiente: un sofá, el pack bajo kapton (la cinta adhesiva amarilla que aísla y resiste el calor), el ESP32 al extremo de tres cables y un terminal que compara las lecturas a diez segundos de intervalo.

Es una lección que ya conocía y que aun así tuve que reaprender: cuando un síntoma desaparece en el momento en que se le observa, probablemente es la observación la que lo ha hecho desaparecer. Hay que mirar lo que vuelve, no lo que se va.

El contador

Quedaba el sospechoso inicial, el que la aplicación había nombrado: 1547 ciclos. Al medidor le da igual: la degradación por ciclos está desactivada, lo comprobamos. Pero el robot lee ese número (CycleCount, comando 0x17), y un software embebido (un firmware: el programa grabado en el robot) que muestra «contador de cargas superado» tiene por fuerza un umbral en alguna parte.

El contador es un simple valor de dos bytes en la flash, en la dirección 0x4340. En Full Access, se escribe como se ha leído: un comando de bloque, la dirección, dos bytes. Escribimos cero.

>>> CycleCount SBS avant = 1547 ; écriture DF 0x4340 = 0
>>> relecture 0x4340 : 00 00  (OK)
>>> CycleCount SBS après écriture = 0

Inmediato, sin reinicio, sin ningún indicador de seguridad activado. Una batería nueva, a ojos de quien solo mira ese número.

El giro

1 de septiembre por la noche: luz roja. Error 4202. El robot había aguantado un día.

Tercera vez que se repite el guion: se toca el pack, se vuelve a conectar, el robot arranca, y al día siguiente se para. Reiniciar el medidor había «funcionado» una noche; poner el contador a cero, un día y unos ciclos. Mirado de cerca, esas dos «victorias» tienen algo en común que no es la corrección: cada vez se desconectó y se volvió a conectar el pack. El robot se reinicia, olvida su estado «batería descargada», vuelve a intentarlo… y tropieza con la misma causa, que no habíamos encontrado.

Esta vez, antes de cualquier reinicio, el pack fue al ESP32 tal cual. Contador de ciclos: sigue en 0. Ninguna protección activa, ningún fallo permanente, medidor en plena forma: la misma lectura tranquilizadora de la primera noche. Solo que habíamos aprendido a desconfiar de las lecturas tranquilizadoras, y fuimos a leer una zona de la flash que nunca habíamos decodificado: los datos de vida (Lifetimes), el diario que el medidor lleva sobre sí mismo desde que salió de fábrica: tensiones extremas vistas por cada celda, cuántas veces ha saltado cada protección y en qué ciclo fue la última.

Comparada con la copia del 29 de agosto, decía esto:

                              29 ago       1 sep
COV (sobretensión de celda)   6            246   (+240 en tres días)
Vmáx de por vida, celda 4     4213 mV      4293 mV   (umbral COV: 4225)
Terminaciones de carga válidas 21813       21813 (ninguna desde el cambio de celdas)
Celdas en reposo              —            3986 / 3986 / 3995 / 3939 mV

Doscientos cuarenta disparos de la protección de sobretensión en tres días, todos en la celda 4, y ni una sola carga llevada hasta el final. El pack original había visto seis en cuatro años.

La explicación cabe en una imagen. Cuatro celdas en serie son cuatro cubos que se llenan por la misma manguera: si uno es más pequeño, rebosa el primero. La celda 4 de mi juego de celdas recuperadas tiene menos capacidad que las otras tres: en reposo es la más baja (3,94 V frente a 3,99) y en carga es la primera en cruzar los 4,225 V. El medidor hace entonces su trabajo: corta el transistor de carga, espera a que la celda baje a 4,1 V, vuelve a abrir, vuelve a cortar un segundo después. Doscientas cuarenta veces. El cargador del robot, por su parte, ve una carga que nunca termina; al cabo de un rato su firmware saca la única conclusión que conoce: «batería descargada», 4202.

El contador de ciclos no tenía nada que ver, o no del todo. Para el pack original nunca lo sabremos: cambié dos cosas a la vez. Sus datos de vida, eso sí, muestran 67 subtensiones, la última en el ciclo 1547; la celda de 41 mΩ hundiéndose en plena aspiración es una explicación al menos tan buena como el contador. El código 4202 es un cajón de sastre.

El nuevo intento. La solución limpia es pasar las cuatro celdas recuperadas por el probador, como las originales, y montar un pack con las cuatro celdas mejor emparejadas de las ocho. Mientras tanto, el medidor permite un parche sin soldador, siempre por los tres cables, y eso es lo que hicimos esa misma noche:

• tensión de carga bajada de 4200 a 4100 mV por celda: el pack se detiene en 16,4 V en lugar de 16,8; la celda 4 se queda por debajo del umbral de sobretensión, a cambio de un 10 % de autonomía;
• capacidad de referencia reducida a 2100 mAh (se había quedado en 2500, la del pack nuevo), capacidad química de las celdas alineada con ella;
• medidor puesto de nuevo en modo aprendizaje: sus valores aprendidos (capacidad química, tabla de resistencias) databan de las celdas de 2022; un bit le dice que lo reaprenda todo en los próximos ciclos.

Reinicio: el medidor anuncia 16 400 mV y 1500 mA, una capacidad a plena carga estimada de 1792 mAh, ningún fallo. Pack cerrado, robot en su base. Esta vez no cantamos victoria: esperamos unos días y volveremos a abrir el diario del medidor. Si el contador de sobretensiones sigue en 246, era eso.

Dónde estamos

Y luego está el epílogo que no vi venir. Las cuatro celdas originales, las que había desoldado al principio porque «la batería estaba muerta», andaban por el banco de trabajo. Por descargo de conciencia, las medí: 3,6 V cada una. Ninguna está por debajo del umbral en el que una celda de litio se condena. Así que las pasé por el probador de capacidad: un Liitokala Lii-500, un cargador-analizador de unos treinta euros, en modo «NOR TEST»; carga la celda a tope, la descarga después a corriente constante contando los miliamperios-hora que salen, y vuelve a cargarla. Es la única forma honesta de saber lo que vale una celda: vaciarla con el cronómetro en marcha.

Veredicto, sobre celdas dadas por 2500 mAh cuando eran nuevas:

El probador da también la resistencia interna de cada celda: la «fricción» eléctrica de la química, en miliohmios (mΩ). Cuanto más alta, más se hunde la tensión cuando el robot tira corriente, y más se calienta la celda en lugar de entregar. Tres celdas oscilan entre 16 y 19 mΩ, un buen valor para unas 18650 de esa edad. La cuarta está en 41 mΩ: más del doble. Es el eslabón débil del pack, la que se desploma primero en plena aspiración, arrastra a las demás hacia el umbral de corte y por tanto acorta la autonomía mucho más de lo que sus 1819 mAh dejarían suponer.

Pero ninguna está muerta. Tras algo así como 1547 ciclos, estas celdas todavía entregan tres cuartas partes de su capacidad original: una pérdida normal, la que se espera de un litio que llega al final de su vida anunciada. En la práctica, la autonomía habría pasado de la hora y media larga a poco más de una hora. Una aspiradora algo menos resistente, no una aspiradora muerta.

Ahí es donde la historia cobra sentido. El pack que desencadenó todo esto no estaba averiado: estaba gastado un 25 %, y algo —un contador, o más probablemente su celda de 41 mΩ hundiéndose en plena aspiración— decidió que se había acabado. El cambio de celdas que hice por primer reflejo probablemente no era necesario, y hecho con celdas recuperadas nunca medidas, añadió un problema (ver El giro); al menos me deja cuatro celdas originales en funcionamiento, medidas y documentadas, listas para servir de recambio el día en que las recuperadas fallen.

Lo que me habría costado hace tres años

Seamos honestos sobre el escalón que subí sin verlo.

Hace tres años, esta historia se habría detenido en el párrafo «Primer reflejo: las celdas». Celdas cambiadas, error todavía ahí, multímetro tajante: la batería está bien. ¿Y después? Después, un callejón sin salida. Habría buscado en los foros, encontrado los mismos hilos que todo el mundo —«hace falta un EV2400 y bqStudio», «el chip está bloqueado», «compra una batería»— y habría comprado, o guardado el robot en un armario a la espera de un valor que nunca llega.

Porque el resto del proceso, que aquí cabe en unos pocos párrafos, representa un trabajo que yo no habría podido aportar en tardes de aficionado. Pongámoslo sobre la mesa:

1. Identificar el chip y encontrar su manual: fácil.
2. Leer el manual: 250 páginas, 17 000 líneas de inglés técnico denso, escritas para ingenieros de baterías que ya dominan el vocabulario. No se trata de hojearlo: hay que encontrar las tres tablas que dicen cuándo la corriente de carga cae a cero, el procedimiento de escritura en la flash, el mapa de las 400 direcciones de configuración, el significado de cada bit de una decena de registros de estado.
3. Aprender el SMBus a nivel de protocolo (el block read, el block write, el comando 0x44 y su eco, el autoincremento de dirección) y escribir un programa que lo hable sin errores.
4. Interpretar una lectura de cuarenta indicadores y 8 KB de bytes en bruto, cruzándolos con el manual.
5. Diseñar los experimentos: el reinicio y luego —tras la falsa esperanza— la idea de comparar dos lecturas completas a diez segundos de intervalo para aislar la línea que cambia.
6. Escribir en la flash sin romper nada.

Para un desarrollador competente que no es ingeniero de baterías, son varias semanas de tardes, con un riesgo real de abandono en el punto 2, que es exactamente donde se detienen los hilos de los foros. No es que sea difícil en el sentido intelectual; es que es largo, y nada garantiza, de entrada, que esas semanas lleven a alguna parte.

Con Claude, los puntos 2 a 6 llevaron dos tardes y una mañana. La IA absorbió el manual en unos segundos, escribió el sketch de una pasada, decodificó los registros a medida que llegaban, propuso el reinicio y luego —cuando el reinicio mintió— propuso repetirlo grabándolo todo, y encontró el indicador SLEEP en la comparación. Lo que yo conservaba: el soldador, el multímetro, las fotos, las decisiones («no tocamos Qmax, dejamos que aprenda») y, sobre todo, la duda: fue la prueba de una noche en el robot de verdad la que desmintió la victoria, no una lectura más.

Dos matices, para no convertirlo en un cuento. Primero, la IA cofirmó la falsa esperanza: tenía la misma conclusión errónea que yo la primera noche, porque teníamos los mismos datos incompletos. Lee rápido, pero no mide por mí. Segundo, encontró un error en el propio manual (el reposo que pone la corriente a cero cuando la documentación dice lo contrario) únicamente porque medimos lo contrario; sin el ESP32 conectado, habría defendido la documentación.

Pero el desplazamiento es real, y me parece importante para la reparación en general: un saber que estaba encerrado en un manual de 250 páginas, y por tanto reservado a los profesionales, se vuelve accesible a alguien que sabe sostener un soldador y formular una pregunta. Los fabricantes cuentan, sin decirlo, con que nadie leerá el manual. Esa hipótesis acaba de caer.

Enfoque: el bq40z50, el chip que gestiona tu batería

Ya que hemos pasado dos días con él, presentémoslo. El bq40z50-R2 es lo que Texas Instruments llama un battery pack manager: un único chip, del tamaño de una uña (encapsulado QFN de 32 pines, con los contactos bajo el encapsulado), que hace todo lo que un pack de litio de 1 a 4 celdas en serie necesita. Se encuentra en buena parte de las baterías de portátiles de los últimos diez años, en herramientas eléctricas, robots, drones, baterías médicas.

Lo que hace

• Medir: mide la corriente a través de una resistencia de medida (un shunt, unos pocos miliohmios) y la tensión de cada celda, y deduce el estado de carga con un algoritmo propio, Impedance Track: en lugar de limitarse a contar lo que entra y sale (lo que deriva con el tiempo), aprende la capacidad química real de las celdas (Qmax) y su resistencia interna en cada ciclo, y corrige permanentemente. Es lo que da los porcentajes precisos de los portátiles recientes.
• Proteger: integra el AFE (analog front-end: la parte analógica que vigila tensiones y corrientes en tiempo real, con independencia del software) y gobierna directamente los transistores de carga y descarga. Sobretensión y subtensión por celda, sobrecorriente en carga y en descarga, cortocircuito, sobrecalentamiento y baja temperatura, cada una con sus umbrales, sus retardos y sus condiciones de vuelta a la normalidad.
• Condenarse: una segunda familia de protecciones, los fallos permanentes (PF), corta definitivamente el pack —si hace falta, fundiendo un fusible químico irreversible— en caso de celda abierta, desequilibrio incorregible, transistor quemado o demasiadas sobretensiones repetidas.
• Equilibrar: durante la carga, descarga ligeramente las celdas adelantadas para que todas lleguen llenas a la vez.
• Recordar: contador de ciclos, temperaturas y tensiones extremas vistas a lo largo de su vida (lifetime data), y una caja negra que registra los últimos eventos de seguridad antes de un fallo permanente: material para hacer la autopsia de un pack muerto.
• Hablar: SMBus, todo el estándar SBS, más los comandos del fabricante. Y autenticarse: un mecanismo criptográfico (SHA-1 con una clave secreta) permite al aparato verificar que el pack es original. Es lo que bloquea las baterías compatibles en algunos aparatos.

Sus puntos fuertes

• Completo y documentado. Todo está en un solo encapsulado, y el manual lo describe todo: es lo que ha hecho posible esta investigación. Muchos chips de la competencia están documentados bajo acuerdo de confidencialidad, o no lo están en absoluto.
• Preciso. Impedance Track sigue siendo la referencia en medición de carga para el gran público; el error de estimación baja al 1 % en un pack bien configurado.
• Seguro por construcción. El AFE protege incluso si el software se cuelga; los fallos permanentes no se negocian.
• Ubicuo. Decenas de millones de unidades en packs de portátiles: abundan las placas, los archivos de configuración y las experiencias compartidas.
• Abrible. El software oficial bqStudio y el adaptador EV2400 existen, pero, como hemos visto, un microcontrolador de dos euros basta para leer, y a menudo para escribir.

Sus puntos débiles

• Complejo de configurar. Más de 400 parámetros en flash. Hacer funcionar correctamente Impedance Track exige una «imagen de referencia» (golden image) construida en laboratorio: identificación de la química de las celdas, calibración, ciclo de aprendizaje completo. Un pack DIY mal configurado mide mal, y el aprendizaje que hemos elegido lleva varios ciclos.
• La seguridad depende del fabricante del pack. TI proporciona las cerraduras; es el ensamblador quien decide cerrarlas. El pack Neato se entregó en Full Access. Una batería de portátil de marca, en cambio, casi siempre está sellada, y sin las claves solo se leen los registros estándar.
• La seguridad, a la inversa, puede ser un muro. La autenticación SHA-1 y el sellado son precisamente lo que hace irreparables algunos packs: un fallo permanente en un pack sellado es basura, sea cual sea el estado de las celdas.
• No más de 4 celdas en serie. Para una bicicleta eléctrica (de 10 a 13 celdas en serie) hace falta su hermano mayor, el bq40z80 (hasta 7 en serie), u otra arquitectura.
• Difícil de cablear uno mismo. El encapsulado QFN se suelda en horno o con aire caliente, no con soldador; las placas de desarrollo de TI cuestan un centenar de euros. En la práctica, el DIY pasa por placas recuperadas.

Lo que se puede hacer con él, fuera del Neato

• Diagnosticar una batería de portátil antes de tirarla. Un pack Dell, HP o Lenovo «muerto» contiene muy a menudo un bq40z50 (o un primo: bq30z55, bq40z80) y seis celdas de las que tres están bien. El ESP32 y el sketch de este artículo leen el estado de salud, el contador, los fallos, y dicen si son las celdas o el chip. En un pack sellado se lee menos, pero se lee.
• Rearmar un pack tras un cambio de celdas. Exactamente este artículo: contador, eventualmente fallo permanente (PFStatus se pone a cero por comando, en Full Access o con la clave), y luego ciclo de aprendizaje.
• Construir una «batería inteligente» para tus propios proyectos. Una placa BMS recuperada con su bq40z50, cuatro celdas 18650 nuevas, y se obtiene un pack de 14,4 V que se autoprotege, se equilibra y anuncia su porcentaje: para un robot DIY, una radio de campo, un SAI de respaldo para un servidor doméstico, una lámpara de obra.
• Vigilar una batería a distancia. El ESP32 tiene Wi-Fi: el mismo sketch puede publicar tensión, corriente, temperatura y estado de carga por MQTT (un protocolo de mensajes ligero, el estándar de la domótica) hacia Home Assistant o una base de datos. Un pack que avisa antes de fallar.
• Aprender. El bq40z50 es un curso completo de gestión de baterías de litio, con un manual gratuito y un chip que se encuentra en la basura. Todo lo que hace el BMS de un coche eléctrico, él lo hace en pequeño, y se deja mirar mientras lo hace.

Una reserva: todo esto supone un pack abierto (no sellado) o del que se tienen las claves. Los fabricantes de portátiles sellan; los fabricantes de packs para robots, herramientas y juguetes, a menudo, se olvidan. Compruébalo antes de lanzarte: es la primera lectura, y no cuesta nada.

Lo que esto cuenta

No creo que nadie, en Neato ni en su proveedor de baterías, decidiera que este robot moriría en 2026. Creo algo peor: nadie decidió que viviría.

Observemos las capas.

La nube. El robot fue diseñado para no hacer nada sin un servidor. Cuando el servidor se apaga, solo queda el botón. En los D3 a D7, una comunidad consiguió conectar un ESP32 al puerto serie de la placa base y devolver a los robots su autonomía (vacuula/fang, OpenNeato). En los D8 a D10, ese puerto está bloqueado con contraseña. Una generación más tarde, la puerta se cerró con llave. No por la seguridad del usuario: por nada, al parecer, salvo para que no la toque.

La batería autenticada. El robot verifica la identidad del pack. Los foros están llenos de D5 bloqueados tras insertarles una batería compatible. El fabricante lo llama seguridad; también es, muy concretamente, un peaje sobre la pieza de desgaste número uno.

El contador. 1547 ciclos, y una aplicación que dice «a sustituir». No porque la batería esté fuera de uso —el propio medidor la daba cargada al 97 %, y las celdas originales, medidas desde entonces, todavía entregan del 73 al 77 % de su capacidad de fábrica—, sino porque un número ha cruzado un umbral que nadie te muestra. El robot fue puesto fuera de servicio por un cuarto de autonomía de menos.

Y la ausencia de camino. Un chip perfectamente documentado, dejado en acceso total, cuyo contador se pone a cero con un comando. Ningún camino, en el producto, lleva a ese comando. El diagnóstico entregado al usuario es «batería descargada», que es falso, y la solución propuesta es «comprar», que es cara.

La obsolescencia, aquí, no es una bomba de relojería programada por un ingeniero cínico. Es una suma de no-decisiones: nadie presupuestó la función «reiniciar la batería», nadie escribió el mensaje de error honesto, nadie dejó un puerto abierto. Cada elección se justifica por separado. Su suma fabrica un residuo de 600 € con una batería cargada dentro.

La buena noticia es que las mismas no-decisiones dejan grietas. El chip no se bloqueó. El fabricante del pack dejó sus pads de prueba. TI publica su manual. Y un microcontrolador de dos euros, más una IA que acepta leer 17 000 líneas de documentación sin quejarse, bastan para colarse por ellas.

A partir del 18 de febrero de 2027, el artículo 11 del reglamento europeo sobre baterías (extracto local) exigirá que las baterías portátiles de los aparatos sean « readily removable and replaceable by the end-user ». Es un avance. Pero esta historia muestra que «sustituible» no basta: mi batería era sustituible, y precisamente la sustitución era lo que me vendían como única salida. Lo que habría que exigir es que los objetos digan la verdad sobre su estado, y que dejen un camino para corregirlo. Un botón «reiniciar la batería» en una aplicación cuesta una tarde de desarrollo. El silencio, en cambio, cuesta una batería a cada cliente.

Cómo reproducirlo

Material: un ESP32-C3 Super Mini (o cualquier ESP32/Arduino con I²C), tres cables, un soldador y, eventualmente, dos resistencias de 4,7 kΩ. El pack debe estar abierto a la altura de su placa electrónica: la funda va pegada, un cúter la raja sin forzar.

Seguridad: las celdas permanecen conectadas durante toda la operación. Ninguna herramienta metálica cerca de los pads C+ y C−, que llevan 16 V y varias decenas de amperios de cortocircuito posible. Ni pulsera, ni anillo. Los pads DA y CL, en cambio, están a 3,3 V y no corren ningún riesgo.

La otra cara de la placa: no se toca, pero muestra que el fabricante previó muchos más puntos de prueba que los dos que nos interesan.

Cableado:

Software: bq40z50-reader.cpp y platformio.ini (PlatformIO es la herramienta que compila y sube el programa; entorno Arduino, destino esp32-c3-devkitm-1). Monitor serie a 115200 baudios. Los registros esenciales, en la dirección SMBus 0x0B:

En orden: (1) conectar, leer, comprobar que DeviceType responde 0x4500 y que el nivel de seguridad es Full Access —si no, harán falta las claves del fabricante, y este artículo no las tiene—; (2) guardar la flash (el sketch lo hace al arrancar) y poner el archivo a buen recaudo; (3) leer PFStatus y SafetyStatus —un fallo permanente es otra historia—; (4) leer los datos de vida (0x4380…) y compararlos con la copia tras unos días en el robot: un contador COV o CUV que sube señala a una celda, no a un contador; (5) solo entonces, teclear c, y esperar varios días antes de concluir.

Tres reglas, si te pones a ello: leer primero, guardarlo todo después, escribir solo al final. Un medidor en Full Access se deja reparar tan fácilmente como destruir.

Preguntas frecuentes

¿Qué significa el error 4202 en un Neato?

Es el error «batería descargada» de los D8, D9, D10 y D800. La aplicación (cuando funcionaba) precisaba que el contador de cargas de la batería estaba superado y que había que sustituirla. Aparece incluso con celdas en perfecto estado: lo que lo dispara es lo que el chip del pack le cuenta al robot; en particular, según lo que hemos observado, un contador de ciclos demasiado alto.

¿Cambiar las celdas del pack resuelve el error 4202?

No por sí solo. El contador de ciclos y el estado de salud viven en el chip bq40z50 del pack, no en las celdas. Tras el cambio de celdas, el error persistía en mi caso con celdas a 4,1 V.

¿Hace falta un EV2300/EV2400 y bqStudio para hablar con el medidor?

No. Un ESP32 (o un Arduino) con dos pines I²C, tres cables y el manual de TI bastan: el chip está documentado y, en los packs Neato que he visto, se deja en Full Access, sin contraseña. bqStudio es más cómodo, no necesario.

¿Una batería compatible del mercado resuelve el problema?

A veces, y a veces el robot la rechaza: los foros documentan D5 bloqueados tras insertar un pack compatible. Antes de comprar, cuesta una tarde comprobar que la batería original no ha superado simplemente un umbral de ciclos.

¿Es peligroso?

Las líneas DA y CL están a 3,3 V y no entrañan riesgo. El peligro está en otra parte: los pads C+/C− y B+/B− a 16 V, capaces de decenas de amperios en cortocircuito. Una sola herramienta metálica a la vez, nada de joyas, y no se toca nada más que DA, CL y el menos.

¿Por qué el medidor anuncia 0 mA de corriente de carga?

Porque duerme. En cuanto la corriente baja de 10 mA durante una treintena de segundos, entra en reposo y pone ChargingCurrent y ChargingVoltage a cero. En el robot, que consume permanentemente, se mantiene despierto. No es una avería, y un reinicio no «repara» nada: lo despierta treinta segundos.

¿Funciona en un D3, D4, D5, D6 o D7?

Los packs de esas generaciones usan un chip diferente, bloqueado, y las investigaciones de la comunidad no han dado fruto. En cambio, su puerto serie está abierto, y vacuula/fang u OpenNeato devuelven a esos robots su autonomía sin la nube.

¿Se puede reutilizar el chip bq40z50 de una batería vieja en otro proyecto?

Sí, si el pack no está sellado o si se tienen sus claves. Una placa BMS recuperada con sus celdas sustituidas hace una batería inteligente de 1S a 4S para un robot, una radio o un SAI DIY; un ESP32 conectado a ella puede publicar su estado por MQTT hacia la domótica. Ver la sección «Enfoque: el bq40z50».

¿Qué hizo exactamente la IA, y qué hizo el humano?

Claude leyó el manual de 250 páginas, escribió el programa de lectura, decodificó los registros, propuso el reinicio y luego el experimento de comparación que reveló el modo de reposo, y redactó este artículo conmigo. Yo soldé, medí, fotografié, decidí no tocar Qmax y dejé que el robot pasara una noche en su base, lo que desmintió la primera conclusión, la suya tanto como la mía.

¿Está reparado el robot?

Todavía no con certeza. Poner el contador a cero (30 de agosto) le dio un día, y luego el error 4202 volvió: la causa real era una celda recuperada más débil que disparaba la protección de sobretensión en cada carga. Corrección aplicada el 1 de septiembre (tensión de carga de 4100 mV por celda, reaprendizaje del medidor), en observación. Sigue sin comprarse ninguna pieza. Ver Dónde estamos.

Pequeño glosario

• Celda: el acumulador elemental, aquí en formato 18650 (18 mm × 65 mm). Un pack ensambla varias.
• BMS (battery management system): la placa electrónica del pack, que protege, equilibra y mide las celdas. Aquí está construida en torno al bq40z50.
• Medidor de carga (gas gauge): el chip que cuenta lo que entra y sale de la batería y deduce el estado de carga.
• Chip / circuito integrado: un ordenador o un circuito completo grabado en unos milímetros de silicio.
• Microcontrolador: un pequeño ordenador completo en un chip, programable; el ESP32-C3 lo es.
• Bus serie / SMBus / I²C: dos cables (datos y reloj) por los que los chips intercambian mensajes digitales; SMBus es la variante que usan las baterías.
• Dirección, registro, comando: el número de un chip en el bus, una casilla de memoria que se puede leer, el número que la designa. 0x…: número escrito en hexadecimal.
• Bit, byte: la casilla elemental (0 o 1) y el grupo de ocho; un indicador (flag) es un bit que señala un estado.
• Firmware: el programa grabado en un aparato. Flash: la memoria que sobrevive al apagado; memoria RAM: la de trabajo, borrada al reiniciar.
• Ciclo: una descarga acumulada equivalente al 90 % de la capacidad (umbral ajustable). El contador se limita a sumar.
• RSOC: estado de carga relativo, el «porcentaje de batería»; FCC: capacidad a plena carga, tal como la estima el medidor; Qmax: capacidad química aprendida de las celdas; mAh: miliamperio-hora, unidad de cantidad de energía almacenada.
• Resistencia interna: la «fricción» eléctrica de una celda, en miliohmios (mΩ). Cuanto más alta, más cae la tensión bajo carga y más se calienta la celda; sube con la edad y delata a una celda cansada antes de que su capacidad se desplome.
• FET / transistor: interruptor electrónico con el que el medidor autoriza o corta la carga y la descarga.
• Pull-up: resistencia que mantiene una línea del bus a 3,3 V cuando nadie habla.
• PF (Permanent Failure): un fallo que el medidor juzga irrecuperable; se condena y nada lo borra. No había ninguno.
• COV / CUV (Cell Over-/Under-Voltage): protecciones de sobretensión y subtensión por celda. El medidor corta la carga (COV) o la descarga (CUV), reanuda cuando la tensión vuelve al rango y cuenta cada disparo en sus datos de vida.
• Impedance Track: el algoritmo de TI que aprende la capacidad y la resistencia de las celdas para medir con precisión.
• Full Access / Unsealed / Sealed: los tres niveles de acceso al chip, del más abierto al más cerrado.

Referencias y copias locales

Para que este artículo siga siendo útil cuando los enlaces hayan desaparecido, los documentos citados se alojan aquí, con su fuente original.

• TI bq40z50-R2 Technical Reference Manual, SLUUBK0B (junio de 2017, rev. octubre de 2018) — fuente · copia local (PDF, 1,6 MB).
• Mapa de la data-flash del pack Neato, decodificado — bq40z50-df-map-neato.md · copia de seguridad en bruto del 29 de agosto de 2026 — bq40z50-df-backup-neato-blueway-20260829.txt.
• El sketch y su configuración — bq40z50-reader.cpp · platformio.ini.
• Neato Robotics, «Announcement – 6th Oct 2025» (fin de los servicios en la nube) — fuente · copia en texto.
• Reglamento (UE) 2023/1542 sobre baterías, artículo 11 (aplicable a partir del 18 de febrero de 2027) — fuente EUR-Lex · extracto local.
• vacuula/fang (firmware ESP32 que libera los Neato D3–D7 de la nube) — fuente · README del 30 de agosto de 2026.
• renjfk/OpenNeato — fuente · README del 30 de agosto de 2026.
• Hilo de laptopu.ro sobre los chips de los packs Neato (acceso Full Access mediante bqStudio) — fuente (sin copia: el sitio rechaza el archivado).

Fotos y mediciones: mías. Lectura del manual, código y redacción: con Claude. Este artículo también está disponible en Markdown en bruto.

La primera entrada contaba la construcción de la herramienta y terminaba con su enseñanza más incómoda: el modelo no predice lo que el incendio va a hacer, predice lo que haría si nadie se le opusiera. La diferencia entre ambas cosas — un factor 1,7 el día en que el fuego corría libremente, un factor 12 el día en que los equipos de extinción mantenían el frente — es la lucha contra el fuego, y el modelo no la representaba en absoluto.

Esta entrada cuenta cuatro cosas: lo que el fuego ha hecho desde entonces, lo que el modelo ha aprendido al intentar representar a los equipos de extinción, lo que la lucha real debe a un ejército que nadie presupuesta — los vecinos y los agricultores —, y lo que este modelo permite decir — con prudencia — sobre una pregunta política que me han hecho: si el programa de l’Avenir en commun (« el Porvenir en común », el programa de La France insoumise) se hubiera aplicado durante dos mandatos, ¿qué habría cambiado en un episodio como este?

Cómo se califica un modelo sobre el pasado — tres términos que volverán a lo largo de todo el texto. La repetición retrospectiva (rejeu rétrospectif): uno se sitúa en un instante pasado, no le da al modelo más que lo que se sabía en ese momento, simula hacia adelante y compara con lo real. El sesgo de superficie: la relación entre la superficie predicha y la superficie observada — un sesgo de 7,5 significa que el modelo quema siete veces y media de más. El AUC: tomen al azar una celda que ardió y otra que no ardió; el AUC es la probabilidad de que el modelo haya dado una puntuación más alta a la primera. A 0,95, rara vez se equivoca sobre el dónde — incluso cuando se equivoca gravemente sobre el cuánto.

Seis días, cuarenta y cinco mil hectáreas

Primero los hechos, porque dan la escala. El incendio principal no empezó en Biscarrosse: empezó el 22 de julio en Saumos, en la Gironda (Gironde, el departamento de Burdeos), en una obra de desbroce — 1 400 hectáreas esa misma noche. El de Biscarrosse, una furgoneta en llamas, siguió al día siguiente. A partir de ahí, las jornadas se cuentan en decenas de miles de hectáreas:

• 24 de julio — 19 000 ha en la Gironda, 110 000 personas evacuadas, entre ellas la península del Cap Ferret por tierra y por mar;
• 25 de julio — más de 32 000 ha, 167 000 evacuados, primera descarga de retardante — un producto que no se evapora como el agua, sino que recubre la vegetación para volverla ininflamable — desde un A400M del Ejército del Aire francés;
• 26 de julio — 42 000 ha, cinco municipios a las puertas de Burdeos evacuados mediante FR-Alert (el sistema francés de alerta por teléfono móvil): alrededor de 220 000 personas desplazadas en total, una de las mayores evacuaciones francesas en tiempos de paz;
• 27-28 de julio — tregua, cortafuegos ampliados con bulldozer, incendio « contenido pero no fijado », luego « estabilizado »… y una nueva ola de calor anunciada por Météo-France (el servicio meteorológico nacional).

Hagan clic en las figuras para abrirlas en grande.

Según el último balance que he podido documentar: 42 000 ha en la Gironda, 3 500 en las Landas (Landes, el departamento vecino, al sur), 88 bomberos heridos, más de 2 750 bomberos y cerca de 3 000 gendarmes y militares desplegados, refuerzos europeos (Canadair croatas, Air Tractor portugueses, helicópteros pesados checo y eslovaco), un dron Reaper para la cartografía térmica. EDF ha indicado que la central del Blayais, a unos cincuenta kilómetros de las llamas, no está amenazada — la pregunta que había puesto en marcha todo este proyecto tiene por tanto, de momento, una respuesta tranquilizadora. El Laser Mégajoule del CEA (el organismo francés de energía atómica), en cambio, ha visto cómo se abrían cortafuegos de urgencia alrededor de sus instalaciones.

📡 Del lado de la herramienta: el mapa kokusho.ss2i.ca sigue rastreando los dos focos. Esta mañana, el modelo ha puesto la base aérea de Cazaux en vigilancia reforzada frente al foco secundario — el frente observado está a 7,3 km y un tercio de los escenarios sin lucha alcanzan la zona de los 6 km en menos de 48 h. Precisión por honestidad: ninguna fuente de prensa documenta amenaza alguna sobre Cazaux; es una salida del modelo, y una salida contrafactual. Es exactamente el matiz que esta entrada va a pasarse todo el tiempo haciendo.

Lo que funcionó en el modelo

Desde la primera entrada, el modelo ha superado dos pruebas y ha ganado un piso.

Primera prueba: la hipótesis de la falta de combustible. La sobrepredicción del 25 de julio (factor 12) tenía una explicación rival a la de la lucha: quizá el fuego estaba simplemente atrapado entre el océano, las lagunas y su propia cicatriz, sin nada más que quemar. La prueba es sencilla y se la recomiendo a todos los modelizadores: mirar dónde hace arder el modelo sus hectáreas sobrantes. Veredicto inapelable — el 94 % de la superficie predicha cae sobre pinar intacto que el fuego real nunca tocó. El combustible estaba ahí. El fuego no lo tomó. Lo que se lo impidió fue, en efecto, la lucha contra el fuego, y había que modelizarla.

Segunda prueba: dos intentos de modelo de lucha, dos fracasos instructivos. El primero sorteaba, celda por celda, si los equipos aguantaban: habría hecho falta ganar el 93 % de las escaramuzas, y se ganaba el 15 %. El segundo mantenía tramos enteros de pista — una treintena de kilómetros defendidos… que el fuego rodeaba tranquilamente. La lección merece escribirse en negrita: un incendio no se contiene defendiendo mucha línea, se contiene defendiendo un bucle cerrado, anclado en barreras que el fuego no franquea. El confinamiento es un problema de topología, no de física local.

El piso ganado: modelizar el razonamiento del jefe de operaciones. Encontrar el mejor bucle cerrado alrededor de un incendio, apoyándose al máximo en el agua, las zonas ya quemadas y las carreteras existentes, es un problema que las matemáticas saben resolver de forma exacta, y la idea se cuenta sin ecuaciones. Todo camino que lleve del fuego al exterior debe atravesar la línea de defensa — si no, el bucle no está cerrado, y el fuego encontrará el agujero. Buscar el mejor bucle es, por tanto, buscar el conjunto de celdas más barato de defender que corte todos los caminos: es lo que se llama un corte mínimo. Un teorema clásico — Ford y Fulkerson, 1956 — dice que ese corte se calcula resolviendo un problema de flujo: imaginen que intentamos empujar un fluido desde el fuego hacia el exterior, dejando pasar cada celda un caudal igual a su coste de defensa; el caudal máximo que consigue circular es exactamente el precio de la mejor barrera, y las celdas que se saturan son la barrera. Es lo que calcula el algoritmo de Dinitz, implementado en SciPy. El agua es gratis, una pista cuesta la mitad, el pinar abierto cuesta tarifa completa — y cada kilómetro se factura según la probabilidad de que un equipo pueda realmente defenderlo, de acuerdo con los umbrales operativos documentados: por debajo de 2 000 kW por metro de frente, el ataque directo es posible; por encima de 10 000, nada aguanta, medios aéreos incluidos.

Intensidad de Byram (Byram, 1959): la potencia liberada por metro lineal de frente, en kW/m — el producto del poder calorífico del vegetal, la masa consumida por metro cuadrado y la velocidad de avance del frente. Es la magnitud que lo decide todo: un pinar landés que corre a 600 m/h libera unos 6 000 kW/m — ya fuera del alcance de un ataque directo por tierra. La altura de las llamas se deduce de ella casi directamente (unos 4 m en este caso).

Dos detalles de implementación, para quien quiera rehacer el cálculo. Primero, los algoritmos de flujo hacen que las capacidades las lleven los enlaces entre casillas, mientras que aquí lo que se compra es la casilla misma: se desdobla entonces cada casilla en una « entrada » y una « salida » unidas por un arco interno al precio de la casilla — la técnica llamada node splitting (Ahuja, Magnanti y Orlin, Network Flows, 1993, § 2.4). Después, el corte debe separar las casillas contando sus ocho vecinas, diagonales incluidas — el « vecindario de Moore » de los autómatas celulares — porque el fuego también se propaga en diagonal: una barrera que solo bloquea las cuatro vecinas cardinales deja que el fuego se cuele entre dos casillas dispuestas al tresbolillo.

El bucle del jefe de operaciones, en principio: cada tipo de terreno tiene su precio, y el corte más barato que cierra el círculo es la estrategia.

La puesta a punto fue una lección de humildad por iteraciones, cada una pagada con una repetición retrospectiva de unos veinte minutos:

• sin precio para la superficie concedida, el corte « óptimo » se iba a buscar las lagunas a treinta kilómetros y abandonaba 150 000 hectáreas — matemáticamente mínimo, operativamente absurdo;
• una línea defendida a las 3 de la madrugada no está defendida a las 15 h: hubo que añadir el desbordamiento, la nueva puesta a prueba de las líneas cuando el frente se intensifica claramente — es el repunte del mediodía el que hace ceder las líneas establecidas de noche;
• y los medios son finitos: la defensa siempre se intenta, pero las unidades se agotan arco tras arco, y los huecos de financiación se convierten en las brechas por las que desbordan los grandes incendios.

Y el mismo bucle en la realidad: el plan calculado por el corte mínimo sobre el incendio del 25 de julio, anclado en el océano, las lagunas y la cicatriz. Cada islote naranja al este ciñe un foco secundario detectado a distancia del incendio principal.

El resultado, en las dos jornadas de referencia: el día contenido, el sesgo cae de 12 a 7,5 — mejor, no bien; el resto se reparte entre los rincones de la cicatriz que el satélite no vio arder, los saltos de fuego que el modelo todavía no combate, y la humedad de los combustibles, que sigue calculándose con una fórmula instantánea sin memoria (Simard, 1968): solo mira la temperatura y la humedad de la hora, de modo que una tarde a 39,8 °C puede parecer más húmeda que la víspera. El remedio conocido es el índice meteorológico de incendios forestales canadiense (Van Wagner, 1987) y sus componentes acumulativas DMC y DC — dos « depósitos » que se llenan con cada lluvia y se vacían día tras día con el calor, guardando así la memoria de las semanas de sequía acumulada. Es la próxima obra. El día en que el fuego se escapó, en cambio, el modelo predice ahora una superficie media con un margen del 14 % respecto a lo observado, y sabiendo por qué: las líneas defendidas por la mañana ceden en el pico térmico. En ambos casos, el AUC se mantiene por encima de 0,95 — el modelo sigue sabiendo adónde va el fuego.

El experimento que un modelo permite: hacer variar los medios

Y es aquí donde la modelización se convierte en un instrumento político — en el sentido noble. La v3 parametriza la lucha en « unidades desplegadas », donde una unidad defiende aproximadamente un kilómetro de línea, y el efectivo se sortea alrededor de una media calibrada sobre las movilizaciones reales (de 2 000 a 2 750 bomberos en los grandes incendios girondinos de 2022 y 2026). Nada impide entonces girar el mando: ¿qué pasa con un 30 % menos de medios? ¿Con un 50 % más?

Repetí las dos jornadas de referencia a tres niveles de despliegue, veinte sorteos cada uno:

Repeticiones retrospectivas a +12 h, 20 sorteos por nivel de despliegue. « Mediana »: la mitad de los sorteos queman más, la otra mitad menos — más robusta que una media frente a los sorteos extremos. Observado: 1 645 ha el 25, 4 642 ha el 24. Órdenes de magnitud de un modelo experimental, no previsiones.

Esperaba una bonita curva decreciente — más medios, menos hectáreas. El modelo me respondió otra cosa, y es el resultado más interesante de la semana: los medios no compran hectáreas, compran un bucle. Por debajo del umbral en que el bucle deja de ser financiable — aquí, alrededor del −70 %, el equivalente de un dispositivo repartido entre tres megaincendios simultáneos, que es exactamente el temor de los veranos que vienen — se pierden miles de hectáreas de golpe. Por encima del umbral, el rendimiento marginal se desploma: entre el nominal y el +50 %, ni una hectárea de diferencia. Y el 24 de julio, la columna entera lo dice: se alineen 34 o 168 unidades, el fuego pasa — las líneas ceden ante la intensidad, no ante el número.

La forma de la curva es el resultado: un umbral, luego una saturación — y el 24 de julio, una curva que los medios ya no mueven.

Una reserva importante antes de sacar conclusiones políticas: esta tabla minimiza el efecto real de los medios, porque el modelo no representa ni el ataque a los incendios incipientes — sofocar un conato en la primera hora, allí donde cada Canadair disponible cuenta doble — ni la rapidez de las rotaciones aéreas, ni el reparto del dispositivo entre varios incendios. Lo que establece es la forma de la curva: un umbral, luego una saturación. No la inutilidad de los medios.

El otro ejército: la logística que se resquebraja, y quienes la sostienen

Hay algo que ni la tabla ni la curva muestran, y que salta a la vista en cuanto se leen los partes de situación y la prensa local: la cuestión no era solo cuántas unidades, sino cómo se mantenían en pie. La logística — el agua, los vehículos, los aviones, el avituallamiento de los hombres — fue el eslabón débil de principio a fin, y ya se resquebrajaba antes del episodio.

Los hechos, con fecha. Durante los incendios, siete Canadair de doce estaban operativos, los demás inmovilizados por el mantenimiento de aparatos con treinta años de servicio — y el pedido de dos aparatos adicionales había sido anulado en 2024, antes de volver a cursarse en junio de 2026 para entrega… en 2032. El parque nacional de camiones cisterna forestales pasó de 5 117 en 2002 a 3 845 en 2020, con una tasa de obsolescencia que subió del 51 al 61 %; la federación de bomberos estima que harían falta 10 000. Tres semanas antes del episodio, el 6 de julio, un sindicato de bomberos profesionales alertaba de que faltaban más de 300 vehículos para cubrir las necesidades de una temporada que ya iba por 7 000 conatos de incendio. Sobre el terreno, un jefe de batallón pedía un camión de 13 000 litros para « mantener una permanencia de agua », las columnas de refuerzo llegaban desde Île-de-France, y un bombero voluntario de Bouches-du-Rhône murió en la carretera — en misión de avituallamiento. Un suboficial lo dice sin rodeos en la prensa: « no tenemos medios suficientes, ni humanos ni materiales, para responder a catástrofes de una dimensión tan importante ». No son accidentes: la Cour des comptes (el Tribunal de Cuentas francés, 2022) hablaba de « falta de anticipación » en la flota aérea, el Sénat (2022) de « subinversión crónica » en los camiones, y las federaciones de bomberos de un « modelo agotado ». Cuatro años después, el episodio de 2026 se jugó con esas mismas carencias, conocidas, escritas y no corregidas.

Y sin embargo las líneas aguantaron los días defendibles. En parte porque se levantó un segundo ejército, que nadie presupuesta. El 24 de julio a las 7 de la mañana, la préfecture de las Landas (la delegación del Gobierno en el departamento) lanza oficialmente « un llamamiento a la solidaridad de los agricultores para aportar cubas de agua » — esas cisternas de decenas de miles de litros que se remolcan detrás de un tractor y que reabastecen a los camiones lo más cerca posible del frente. En pocas horas, la chambre d’agriculture (la cámara agraria) de la Gironda registra más de 500 voluntarios — viticultores del Médoc, comerciantes con sus camiones cisterna, empresas de obras públicas con gradas, palas y bulldozers — de los que un centenar intervendrán efectivamente en el incendio de Saumos, hasta el punto de que el llamamiento se suspende el 27, desbordado por la afluencia. El sector maderero tumbó 22 kilómetros de pinos en veinticuatro horas para abrir cortafuegos — 103 km de cortafuegos y pistas de acceso creados en total, dice el parte de la prefectura del 27. Detrás del frente: voluntarios que sostienen los centros de avituallamiento de los 2 750 bomberos, restauradores que preparan miles de comidas, veterinarios que atienden gratis a los animales evacuados, el recinto ferial de Bordeaux-Lac abierto para 10 000 personas. Nada de esto se improvisa desde cero: ya en 2022, en Landiras, las cubas de purín de los agricultores habían hecho ganar « hasta tres horas al día » a los bomberos, según la cámara agraria — y es precisamente esa experiencia la que la Gironda había empezado a formalizar, un mes antes del episodio, censando el material agrícola movilizable.

Releamos esto con las gafas del modelo, porque ilumina a ambos. El modelo cuenta « unidades que defienden un kilómetro » sin preguntar quién las dota: en realidad, una parte de esas unidades eran tractores. El reabastecimiento de agua, las tres horas al día de 2022, los cortafuegos labrados — en el vocabulario del modelo, eso es resistencia: arcos que siguen defendidos en lugar de ceder por falta de agua, unidades que se quedan en la línea en lugar de hacer viajes de ida y vuelta. Dicho de otro modo, el margen bajo el umbral, ese margen del que la curva muestra que lo decide todo, lo aportó en parte la sociedad misma — en el momento en que el Estado, que tenía sobre su mesa desde hacía cuatro años los informes que cifraban lo que faltaba, no lo tenía. Hay que decir las dos mitades de esta frase: la ayuda mutua fue magnífica, y es el síntoma de una carencia. Una cuba de purín no sustituye a un Canadair en mantenimiento; quinientos voluntarios en veinticuatro horas no se encargan, no se planifican, y se suspenden cuando la afluencia desborda la coordinación; y un sistema que necesita estructuralmente los tractores de sus vecinos para mantener sus líneas no es un sistema dimensionado — es exactamente lo que el informe parlamentario sobre el « valor de lo salvado », presentado diez días antes del episodio, intentaba decir en lenguaje presupuestario.

¿Y si l’Avenir en commun se hubiera aplicado durante dos mandatos?

Vayamos a ello. La pregunta me la plantearon así: las medidas propuestas por La France insoumise (LFI, el partido de Jean-Luc Mélenchon), aplicadas desde 2017, ¿habrían cambiado algo en un episodio como este? El ejercicio es un contrafactual: no se verifica, se argumenta. Voy a empezar, pues, por lo que el programa contiene de verdad, porque la primera sorpresa está ahí.

Lo que el programa contiene — y lo que no contiene. He buscado. Ni la edición de 2017 ni la de 2022 de l’Avenir en commun incluyen un capítulo de protección civil. Ningún número de bomberos que reclutar, ningún presupuesto para los SDIS (los servicios departamentales de incendios y salvamento, es decir, los cuerpos de bomberos), ningún número de Canadair. Las medidas que tocan nuestro tema están en otra parte:

• la sección 27 (« Defender el bosque »): reforzar los medios y las plantillas de la ONF (Office national des forêts, la agencia forestal pública), prohibir las cortas a hecho — la tala de una parcela entera de una sola vez —, promover bosques diversificados en especies y en edades frente a los monocultivos, y « reforzar los medios de prevención y de lucha contra los incendios » — formulación sin cifra;
• el cuaderno temático Bosque: duplicación de la plantilla de la ONF (unos 8 400 agentes hoy, 16 000 a mediados de los años ochenta), adquisición pública de 100 000 ha, medios contra incendios considerados « notoriamente insuficientes »;
• la sección 79: una fuerza mediterránea de intervención y de protección civil contra los incendios — la medida más directamente « fuego » del programa;
• la sección 68: un servicio ciudadano obligatorio de nueve meses que incluye misiones de protección civil, y una guardia nacional bajo mando civil.

En el Parlamento, en cambio, las cifras existen. He vaciado los archivos de las dos últimas legislaturas (2022-2026), y el cuadro es más preciso — y más modesto — de lo que dejaría creer un eslogan en un sentido o en otro:

Enmiendas y preguntas del grupo LFI, XVI y XVII legislaturas (PLF: projet de loi de finances, el proyecto de ley de presupuestos; LOPMI: la ley de programación del Ministerio del Interior de 2022). Enlaces al final del artículo. La cifra de 220 000 bomberos voluntarios en 2027 que a veces se cita es un objetivo gubernamental, que LFI apoyó y sobre el que preguntó — no una propuesta de LFI.

Dos observaciones de honestidad sobre esta tabla. La primera: la fórmula « LFI proponía tantos bomberos y tantos Canadair » sería engañosa — los archivos muestran mecanismos de financiación (75 M€ de inversión, ~+10 % de recursos permanentes, el « valor de lo salvado » del informe Maudet–Pantel presentado diez días antes del episodio) y la exigencia de cumplir objetivos gubernamentales ya existentes, no metas propias de plantilla o de flota. La segunda: todo fue rechazado, retirado o dejado sin curso, y los presupuestos pasaron después por el 49.3 (el artículo de la Constitución que permite al Gobierno aprobar una ley sin votación). Frente a eso, la realidad: las plantillas de la ONF se han fundido un 40 % en veinte años, la flota francesa cuenta con doce Canadair de más de treinta años, el Tribunal de Cuentas denunciaba ya en julio de 2022 una « falta de anticipación » en su renovación — y los dos aparatos encargados en junio de 2026 se entregarán en 2032.

Ahora, hagamos trabajar al modelo. En kokusho, una política pública solo puede actuar por tres canales, y no tienen en absoluto el mismo peso:

Canal 1 — las unidades disponibles. Más bomberos, más vehículos, una flota aérea de dieciséis aparatos en lugar de doce: en el modelo, es la media de despliegue la que sube. Y ahí, el cotejo de las dos tablas de esta entrada es instructivo: las propuestas parlamentarias reales — +10 % de presupuesto para los SDIS, 75 M€ de inversión — son de un orden de magnitud que, trasladado a mi curva de sensibilidad, cae en la zona de saturación. En una jornada defendible, con todo el dispositivo nacional concentrado en un solo incendio, un +10 % no habría cambiado la superficie quemada. Su valor está en otra parte, y es doble: margen bajo el umbral para el día en que los medios estén dispersos — tres conatos simultáneos, una flota medio clavada en tierra, columnas a ocho horas de carretera — y material que sale más rápido hacia los incendios incipientes, el canal que mi modelo todavía no representa y donde cada aparato disponible cuenta doble. Es exactamente el terreno de los dieciséis Canadair y de los aviones complementarios a 30 M€: no ganar la batalla del 24 de julio, sino hacer que no tenga lugar.

Canal 2 — la anchura de los cortafuegos. La DFCI — défense de la forêt contre l’incendie, defensa del bosque contra el incendio — es esa red de pistas arenosas, cortafuegos y puntos de agua que cuadricula el macizo landés precisamente para ofrecer a los equipos de extinción líneas de apoyo ya preparadas. Mantenida, desbrozada, ampliada — trabajo de la ONF y de entidades locales financiadas —, es, en el modelo, cortafuegos más anchos, y por tanto probabilidades de aguante más altas a igual intensidad. Es el canal del 40 % de plantilla de la ONF perdida: el mantenimiento de la red es precisamente el trabajo que se ha desmantelado. Difícil de cifrar, pero el mecanismo es el correcto.

Canal 3 — el combustible mismo. Y es el canal decisivo, porque es el único que actúa sobre la intensidad. El macizo landés es un monocultivo de pino marítimo de un millón de hectáreas — nuestro mapa de combustible es monocromo, y esa monocromía es una política pública con ciento setenta años de antigüedad. Un bosque diversificado en especies y en edades, salpicado de frondosas menos inflamables, es una intensidad de frente más baja; y la intensidad es la única magnitud que decide si una línea es defendible. Por debajo de 2 000 kW/m, todo el mundo aguanta. Por encima de 10 000, nadie. Las medidas lentas son las únicas que desplazan los umbrales. Pero seamos honestos con el horizonte: dos mandatos no transforman un pinar industrial — diez años de diversificación son lindes, parcelas de prueba, interfaces mejor defendidas. El efecto en 2026 habría sido marginal; el efecto en 2046 sería estructural.

¿Y el 24 de julio? Es la pregunta que decide la honestidad de un contrafactual. Respuesta del modelo: ese día, nada de lo anterior bastaba. Con un 50 % más de medios, la superficie simulada del 24 no se mueve ni una hectárea: las líneas ceden ante la intensidad, no ante el número. Cuando el frente supera los 10 000 kW/m, la aritmética de los medios ya no se aplica — no se hace frente con bulldozers a una tormenta de fuego. La única victoria posible el 24 estaba aguas arriba: que el fuego nunca hubiera alcanzado ese tamaño. Ataque a los incendios incipientes en la primera hora — lo que la flota aérea envejecida hace cada vez más despacio — y prevención para que el conato accidental de una obra de desbroce no se encuentre con 40 °C, viento del este y un pinar continuo. Dicho de otro modo: en las jornadas extremas, solo existe la política de antes del incendio. Y las jornadas extremas son precisamente las que fabrican los megaincendios.

Los límites del ejercicio, sin los cuales no vale nada: el programa en sí no cifra ni bomberos ni aviones, y las cifras parlamentarias reales (75 M€, +10 %) son mucho más modestas que los ±50 % de mi tabla, que siguen siendo una hipótesis de lectura; el modelo es experimental y su sesgo residual está documentado; la ola de calor, el viento y siglo y medio de monocultivo no se gobiernan en dos mandatos; y un contrafactual nunca se verifica. Lo que el ejercicio establece es más modesto y más sólido: por qué canales actúa una política sobre un megaincendio, y cuáles de esos canales estaban saturados el 24 de julio.

Lo que me llevo de todo esto

La primera entrada terminaba con una lección de modelización: el modelo no respondía a la pregunta que yo creía hacerle. Esta termina con la lección simétrica, del lado político: « más medios » no es una respuesta única, porque « el fuego » no es un problema único. Están las jornadas defendibles, en las que cada unidad adicional compra hectáreas — ahí, los Canadair de 2032 encargados en 2026 son un escándalo de aritmética presupuestaria. Y están las jornadas indefendibles, en las que la única política que todavía existe se jugó diez años antes, en la composición del bosque, el mantenimiento de los cortafuegos y la velocidad de ataque a los incendios incipientes.

Un programa político que quiera pesar sobre los megaincendios se juzga, pues, con la vara de esos dos regímenes a la vez. Sobre el primero, el programa da la dirección y es en el Parlamento donde se encuentran las cifras: modestas — 75 millones, +10 % —, sistemáticamente rechazadas o aprobadas por el 49.3, pero puestas en los dos lugares que el modelo señala como las verdaderas palancas del régimen defendible, la financiación permanente de los SDIS y la flota de ataque inicial. Sobre el segundo — el bosque, sus plantillas, su diversidad — l’Avenir en commun plantea el problema en el lugar donde se desplazan los umbrales. Y hay que apuntar en el balance lo que ni los programas ni mi modelo cuentan: el margen aportado por la sociedad misma — las cubas de agua de los agricultores, los voluntarios de los centros de avituallamiento —, que aguantó una vez más, y que ningún Estado seriamente dimensionado debería inscribir en su presupuesto como algo adquirido.

Hay que terminar diciéndolo sin rodeos: lo que acaba de pasar no es una anomalía, es un anticipo. El informe del Senado de 2022 — el mismo que cifraba la subinversión — lo escribía negro sobre blanco: de aquí a 2050, las superficies quemadas podrían aumentar un 80 %, y cerca de la mitad de las landas y bosques de la Francia metropolitana quedar expuestos a un riesgo de incendio elevado. Cuatro años después de Landiras, el mismo bosque ha vuelto a arder — más grande, más rápido, más cerca de Burdeos. Dos « incendios del siglo » en cuatro años no constituyen una excepción: constituyen un régimen. Es la nueva normalidad, y su firma es precisamente la más inquietante de las dos columnas de mi curva: las jornadas indefendibles del tipo 24 de julio, aquellas en las que la aritmética de los medios ya no se aplica, serán cada verano más numerosas.

Conocen la escena: el gato al borde de la mesa, la pata sobre el vaso, los ojos clavados en los de uno — y empuja. Nos reímos del gato. Deberíamos mirar al observador: quien ve el vaso deslizarse y no se mueve no es un testigo, es coautor de la rotura. Hace cuatro años que ese vaso se desliza ante los ojos de todos nosotros. Los informes estaban sobre la mesa — el Tribunal de Cuentas en 2022, el Senado en 2022, las federaciones de bomberos año tras año. Las enmiendas estaban presentadas — 75 millones para los camiones en 2022, rechazados; los créditos para los Canadair, rechazados y luego aprobados por el 49.3; el pedido de aparatos, anulado en 2024 para volver a cursarse en 2026, con entrega en 2032. Las supresiones de puestos en la ONF continúan en 2026, el mismo verano en que arde el bosque. A estas alturas, la palabra « carencias » es demasiado suave: son decisiones, tomadas con conocimiento de causa, por gente que tenía las cifras. Y esta entrada ha pasado suficiente tiempo midiendo como para ganarse el derecho a decirlo: no seré el observador que no le dice nada al gato.

Y no me crean solo a mí: en pleno episodio, el medio independiente Bon Pote rehízo la cuenta, votación por votación, de los votos de la Asamblea Nacional sobre la lucha contra los incendios. El cuadro no deja lugar a dudas: dos bloques. De un lado comunistas, insumisos, ecologistas y socialistas, que votan los medios y la prevención; del otro, desde el partido presidencial hasta el Rassemblement national (la extrema derecha de Marine Le Pen), que votan lo contrario — la tasa turística para los SDIS, rechazada dos veces; la contribución de las aseguradoras, rechazada cuando la enmienda esperaba de ella « al menos 800 millones de euros »; el programa de reclutamiento de bomberos profesionales, votado únicamente por la izquierda junto con LIOT (el grupo de independientes de centro); y el decreto firmado por Gabriel Attal en 2024 que anula 50 millones de créditos de protección civil, llevándose por delante el pedido de dos Canadair. La única unanimidad del expediente: 3 millones para la DFCI — así se mide el orden de magnitud de los consensos. Y la medida que se parece rasgo por rasgo al canal del combustible de mi modelo — cortafuegos de frondosas entre las parcelas de coníferas, para romper la continuidad del pinar — solo la votaron los insumisos, los socialistas y los ecologistas. Los umbrales de los que habla esta entrada tienen un color político en el Parlamento, y es verificable voto por voto.

Así que sí, esta entrada toma partido. De todo lo que he leído y cotejado, l’Avenir en commun es hoy el único programa nacional que responde a los dos regímenes a la vez — y las votaciones citadas muestran que, cuando esas medidas llegan al pleno, es la izquierda entera la que las vota: el combustible y el bosque — diversificación de especies, fin de las cortas a hecho, plantilla de la ONF duplicada, allí donde se desplazan los umbrales que deciden si una línea es defendible — y el dimensionamiento de la protección civil — financiación permanente de los SDIS mediante el « valor de lo salvado », flota de ataque inicial ahora y no en 2033. Que no me respondan que le faltan cifras: fueron presentadas, enmienda tras enmienda, con los números que cita esta entrada — y son quienes las rechazaron los que hoy deben rendir cuentas. El resto de la oferta política, cuando habla del fuego, solo habla de aviones — el régimen defendible — y nunca del combustible — el régimen que mata. Pero los Canadair de 2033 no cambiarán nada en las jornadas en que nada vuela, y esas jornadas son las que hacen los megaincendios. Un programa que no habla del bosque no habla del problema. Los tractores de los agricultores aguantaron la línea esta vez. La próxima vez — y la nueva normalidad garantiza que la habrá — me gustaría que la República estuviera allí antes que ellos.

El fuego, por su parte, no espera al final del debate: Météo-France anuncia una nueva ola de calor. El mapa sigue girando.

🔥 Ver la herramienta en línea — kokusho.ss2i.ca

Experimental, sin valor oficial. En caso de incendio, la única fuente fidedigna es la prefectura: landes.gouv.fr · gironde.gouv.fr.

Fuentes

• Cronología y balance: Wikipedia, Incendios forestales de 2026 en la Gironda y en las Landas; comunicados de la prefectura de la Gironda y de la prefectura de las Landas; partes de situación de franceinfo (27 de julio) y France 2 (28 de julio).
• Blayais: Montel News, 27 de julio de 2026. Emplazamientos estratégicos: armees.com.
• Programa: l’Avenir en commun, sección 27; cuaderno Bosque; secciones 68 y 79 en laec.fr.
• Los votos de la Asamblea, votación por votación: Bon Pote, « Quels partis politiques ont voté pour la lutte anti-incendie ? » (« ¿Qué partidos políticos votaron a favor de la lucha contra los incendios? »), Sophie Kloetzli, 27 de julio de 2026 — tasa turística SDIS (votaciones 302 y 4074, XVII legislatura), contribución de las aseguradoras (4076), reclutamiento de bomberos profesionales (133, XVI legislatura), plan de adaptación del bosque (1509), cortafuegos de frondosas entre coníferas (1556), decreto de anulación de 50 M€ de créditos de protección civil (2024).
• Parlamento y presupuesto: enmiendas II-CF1334 (PLF 2023, 75 M€ SDIS), I-CF594 (PLF 2025, TSCA ≈ +10 % SDIS), I-3166 (PLF 2026, tasa turística), CL265 (LOPMI 2022, Canadair 100 % UE), II-CF2221 (PLF 2026, aviones complementarios ≈ 30 M€); preguntas escritas n.º 2391 (F. Chauche, voluntarios) y n.º 9156 (C. Lejeune, dieciséis Canadair); nosparlementaires.fr, « Canadair : ce que le Parlement a voté » (« Canadair: lo que votó el Parlamento »); La Gazette des communes, informe « valor de lo salvado ».
• Contexto: Basta!, plantillas de la ONF; Cour des comptes, informe del 26 de julio de 2022; L’Usine nouvelle, pedido de Canadair (junio de 2026); Sénat, informe n.º 856 (2022).
• Logística y ayuda mutua, episodio 2026: siete Canadair de doce operativos (Le Monde, vía Wikipedia); llamamiento de la prefectura a las cubas de agua (Landas, 24 de julio, 7 h); Vitisphere: 100 agricultores intervinieron, 500 voluntarios, llamamiento suspendido; coordinación por la cámara agraria de la Gironda; parte de la prefectura del 27 de julio: balance, 103 km de cortafuegos; franceinfo: el avituallamiento sostenido por voluntarios; franceinfo: « no tenemos medios suficientes »; France 3: « Quería ser útil »; Bordeaux Métropole: acogida en Bordeaux-Lac, recogida de donativos; CNEWS: un bombero voluntario muerto en misión de avituallamiento; SNSPP-PATS, 6 de julio de 2026: más de 300 vehículos que faltan; reportaje: « corremos detrás del fuego », el camión de 13 000 litros; la columna de refuerzo de Île-de-France, los 22 km de pinos cortados en 24 h.
• El precedente de 2022 y las constataciones estructurales: Réussir: las cubas de purín de Landiras (50 000 litros aportados); Réussir: más de 100 tractores y cubas censados en la Gironda (agosto de 2022); Pleinchamp: « hasta tres horas al día » ganadas, y la formalización de 2026; Ministerio de Agricultura, 2022; Europe 1: la población avitualla a los bomberos (La Teste, 2022); parque de camiones cisterna: 5 117 (2002) → 3 845 (2020), obsolescencia 61 %, objetivo FNSPF de 10 000 (datos DGSCGC citados en anexo presupuestario); Sénat, PLF 2023: « subinversión crónica », y los pactos de capacidad; FO-SIS: « un modelo de protección civil agotado ».
• Física del fuego: Byram G.M. (1959), « Combustion of forest fuels », en K.P. Davis (dir.), Forest Fire: Control and Use, McGraw-Hill — la intensidad de frente I = H·w·R y la relación de longitud de llama L = 0,0775·I^(0,46); Rothermel R.C. (1972), A Mathematical Model for Predicting Fire Spread in Wildland Fuels, USDA Forest Service INT-115 — la amortiguación por la humedad de los combustibles finos; Simard A.J. (1968), The Estimation of Moisture Content of Fine Fuels, Forest Fire Research Institute, Ottawa, FF-X-14 — la fórmula de humedad instantánea utilizada (y criticada) aquí; Van Wagner C.E. (1987), Development and Structure of the Canadian Forest Fire Weather Index System, Servicio Forestal Canadiense, informe técnico 35 — los índices con memoria DMC/DC.
• Umbrales operativos de aguante: Hirsch K.G. & Martell D.L. (1996), « A Review of Initial Attack Fire Crew Productivity and Effectiveness », International Journal of Wildland Fire 6(4); Alexander M.E. & Cruz M.G. (2019), « Fireline Intensity », en Encyclopedia of Wildfires and Wildland-Urban Interface (WUI) Fires, Springer — ataque directo posible por debajo de 2 000 kW/m, vehículos hasta ~4 000, nada aguanta por encima de 10 000; la regla « un cortafuegos aguanta a partir de dos longitudes de llama » es una regla del arte de la ordenación DFCI, tratada aquí como transición suave y no como umbral neto.
• Algorítmica del confinamiento: Ford L.R. & Fulkerson D.R. (1956), « Maximal Flow Through a Network », Canadian Journal of Mathematics 8 — el teorema corte mínimo/flujo máximo; scipy.sparse.csgraph.maximum_flow (algoritmo de Dinitz); el paso de capacidades de nodos a capacidades de aristas (node splitting) se describe en Ahuja R.K., Magnanti T.L. & Orlin J.B. (1993), Network Flows, Prentice Hall, § 2.4; panorama de los modelos de propagación (autómatas celulares incluidos): Sullivan A.L. (2009), « Wildland surface fire spread modelling, 1990–2007 », IJWF 18, tres partes.
• Puntuaciones de validación: Brier G.W. (1950), « Verification of Forecasts Expressed in Terms of Probability », Monthly Weather Review 78; AUC calculada mediante el estadístico de Mann-Whitney; diagramas de fiabilidad y puntuaciones espaciales (Sørensen-Dice, Jaccard): Wilks D.S. (2019), Statistical Methods in the Atmospheric Sciences, 4.ª ed., Elsevier. La comparación con la persistencia como referencia nula es la salvaguarda clásica de la predicción.
• Datos del modelo: NASA FIRMS, detecciones activas VIIRS 375 m (Schroeder W. et al. (2014), Remote Sensing of Environment 143); Open-Meteo (modelos de Météo-France, y altimetría Copernicus DEM GLO-90); ocupación del suelo y viario: © colaboradores de OpenStreetMap (ODbL) vía la API Overpass. Cargas de combustible y velocidades base por clase: órdenes de magnitud asumidos, documentados en el código, no un inventario medido.

El jueves 23 de julio, una furgoneta se incendia en una carretera departamental en Biscarrosse (en las Landas, departamento del suroeste de Francia). A las 15:45 las llamas pasan al macizo forestal, y en tres días se evacúa a 30 000 personas. Como todo el mundo, sigo aquello en mapas de puntos rojos, y una pregunta se instala — el tipo de pregunta que uno no se atreve a formular del todo mientras no sabe responderla: ¿y si fuera hacia el Blayais?

El Blayais es la central nuclear situada en la orilla derecha del estuario de la Gironda, a unos cincuenta kilómetros al norte de Burdeos. Un mapa de puntos rojos no responde a esa pregunta. Muestra dónde está el fuego. Nunca adónde va.

Entre ambas cosas hace falta un modelo. Quise ver hasta dónde se podía improvisar uno honesto en dos días. El resultado existe, funciona y se puede consultar aquí:

👉 kokusho.ss2i.ca — el mapa es público y se actualiza con cada nuevo cálculo.

Herramienta experimental, sin ningún valor oficial. En caso de incendio, la única fuente que da fe es la prefectura (la representación del Estado en cada departamento francés).

Pero esa no es la parte interesante de la historia. La parte interesante es la lista de todo lo que tuvo mal — y sobre todo, con qué se dejó atrapar cada error.

La primera decisión es moral, no técnica

Una herramienta como esta puede mostrar dos cosas muy distintas. La primera:

«El fuego alcanzará la central dentro de 17 horas.»

Es nítido. Es accionable. Y es una estafa. Para escribir una frase así, habría que conocer la posición exacta del frente, el viento de las próximas diecisiete horas, la sequedad real de los combustibles y la eficacia de los equipos de extinción. No conozco ninguno de esos cuatro elementos. Nadie los conoce.

La segunda se parece más bien a esto:

«De 200 escenarios simulados, 6 llevan el fuego a la zona ampliada alrededor de la central, como muy pronto dentro de 29 horas. El viento previsto es transversal al eje del emplazamiento. Confianza baja: última detección satelital hace 5 horas.»

Es bastante menos satisfactorio de leer. Es verdad.

Todo lo demás se deriva de esa elección. La herramienta nunca traza una trayectoria; dibuja envolventes — el término consagrado para esos contornos que delimitan la zona alcanzable — a 6, 12, 24 y 48 horas, en tres niveles de plausibilidad decreciente: la zona alcanzada en más de un escenario de cada dos, la alcanzada en uno de cada diez, y la envolvente extrema que solo se cruza en un escenario de cada cien, aquel en el que todo sale mal a la vez.

Y se niega a resumir la situación en una única cifra. Da tres, por separado: el nivel de amenaza, la confianza que se puede otorgar a ese juicio, y la frescura de la última observación. Porque un «verde» calculado con datos de cuatro horas de antigüedad no es una buena noticia: es un vacío de información. Un satélite que no ve nada no demuestra que el fuego se haya detenido — demuestra que no ve nada.

Los ladrillos, y lo que hacen de verdad

Haz clic en las figuras para abrirlas en grande.

Ver el fuego: FIRMS y VIIRS. La NASA difunde gratuitamente, casi en tiempo real, las detecciones térmicas de sus satélites — el servicio se llama FIRMS, y los sensores que uso, VIIRS, dividen el suelo en píxeles de 375 metros. Los prefiero a MODIS, más antiguo y cuatro veces más grueso.

Hay que entender bien qué es una detección FIRMS: un píxel cuya temperatura de superficie es anómala. No un contorno de incendio. Con retraso, con huecos cuando no pasa ningún satélite, y nada en absoluto cuando el humo o las nubes tapan la vista. Este matiz gobierna todo el resto del artículo.

Saber qué lo empuja: AROME, OSM, MDT. Tres ingredientes hacen avanzar un fuego. El viento en primer lugar, que pesa mucho más que el resto: lo tomo de AROME, el modelo de malla fina de Météo-France (el servicio meteorológico nacional francés), y no en un único punto sino muestreado sobre todo el dominio — un incendio de este tamaño atraviesa varias mallas, y el viento puede girar localmente. La vegetación después, extraída de OpenStreetMap: un pinar seco arde, un estanque no, una viña apenas. El relieve por último, a través de un modelo digital del terreno — un archivo de altitudes, sencillamente — porque un fuego sube una pendiente mucho más deprisa de lo que la baja.

Hacerlo avanzar: el autómata celular. El corazón del cálculo lleva un nombre erudito para una idea sencilla.

Autómata celular — se divide el espacio en celdas regulares, aquí cuadrados de 150 metros, y se da una regla que dice cómo el estado de una celda depende de sus vecinas. Se aplica la regla en todas partes, se avanza un paso de tiempo, se vuelve a empezar. El Juego de la vida de Conway es el ejemplo más conocido.

Mi regla: una celda en llamas intenta prender a sus ocho vecinas, tanto más deprisa cuanto más inflamable es la vegetación, más sube la pendiente y más empuja el viento en esa dirección. El frente adopta espontáneamente una forma elíptica alargada a sotavento — lo que los bomberos observan sobre el terreno, y lo que los modelos reproducen desde los años 1980.

Aceptar que no se sabe: Montecarlo. Es el punto que lo cambia todo.

Método de Montecarlo — en lugar de calcular una sola vez con los mejores valores posibles, se rehace el cálculo cientos de veces sorteando, cada vez, los parámetros que se conocen mal. Después se mira la distribución de los resultados. El nombre viene del casino, y el método, de la bomba atómica — Ulam y von Neumann, 1946.

Lanzo pues 200 sorteos. Cada vez perturbo lo que es realmente incierto: el error de previsión del viento — que crece con el plazo y se mantiene correlacionado en el tiempo, porque una previsión equivocada lo es de forma duradera y no una hora de cada dos — el error de mi propio modelo de velocidad, la sequedad real de los combustibles y la aparición de saltos de fuego, esas brasas proyectadas por delante del frente que cruzan una carretera o un cortafuegos.

Lo que se muestra después ya no es una previsión sino un recuento: esta celda ardió en 150 de mis 200 mundos posibles, aquella en 3. Es la misma lógica que el cono de incertidumbre de las trayectorias de los ciclones.

Una precisión que importa: esas frecuencias no son probabilidades en el sentido actuarial. Son frecuencias condicionadas a mis hipótesis. Si mis hipótesis son malas, mis porcentajes también lo son. Tenlo en cuenta — el resto del artículo no habla prácticamente de otra cosa.

Primer resultado: un fuego perfectamente inmóvil

Primer lanzamiento con los datos reales. Cae el informe: superficie nueva quemada al cabo de 6 horas, 103,5 hectáreas. Al cabo de 12 horas: 103,5 hectáreas. Con precisión de una décima de hectárea.

Un fuego que no gana ni un metro en seis horas bajo 17 km/h de viento es falso. Y mis 200 sorteos, que se suponía que exploraban mundos distintos, daban todos rigurosamente el mismo resultado — lo que es aún más sospechoso.

La causa estaba en una elección de índice. Cuando calculaba la velocidad de paso de una celda a su vecina, tomaba la velocidad de la celda fuente, la que ya arde. Ahora bien, marco toda la superficie ya recorrida como «cicatriz», con una velocidad de propagación casi nula — lo cual es correcto: una zona ya quemada no vuelve a arder fácilmente.

Salvo que el fuego parte forzosamente de la superficie ya quemada. Todas mis celdas fuente eran cicatrices, y por tanto incapaces de transmitir nada. El fuego era prisionero de su propio perímetro.

La corrección cabe en una palabra: tomar la velocidad de la celda objetivo, aquella cuyo combustible está a punto de consumirse. Además es físicamente más justo — un fuego avanza a la velocidad que le permite lo que ataca, no lo que ya ha quemado. Bonificación inesperada: también corrige el cruce de las masas de agua, que una celda fuente combustible podía atravesar.

Luego miré el mapa más de cerca

La herramienta funcionaba, las envolventes se extendían con elegancia, las cifras parecían plausibles. Las miré un rato antes de hacer lo que debería haber hecho desde el principio: abrir el mapa de entrada, el que usa el modelo, y mirarlo de verdad.

Había un problema. El modelo hacía arder el mar.

Y era cierto. Aquí está el mapa de combustible — la imagen que le dice al autómata, para cada celda, a qué velocidad puede avanzar el fuego allí. A la izquierda lo que veía mi programa, a la derecha la realidad:

Toda la masa verde oscuro de la izquierda es el Atlántico. Clasificado como pinar.

La razón es casi divertida. OpenStreetMap no cartografía el océano como una superficie. No existe ningún polígono «Atlántico»: los contribuidores han trazado la línea de costa — en la jerga de OSM, un camino etiquetado natural=coastline — es decir, una línea, no una superficie. Mi consulta, en cambio, buscaba superficies. Recuperaba concienzudamente los lagos, los estanques y los ríos, todos polígonos, y el mar abierto no correspondía a nada.

Ahora bien, fuera de un polígono reconocido, mi programa supone pinar. Era una elección deliberada: en el macizo forestal de las Landas domina el pino marítimo, y equivocarse del lado de «esto arde» sesga el modelo hacia el lado prudente. Salvo que aplicar esa prudencia al 40 % del dominio de cálculo ya no se llama prudencia. En este mapa, el agua pasa del 3,4 % al 40,7 % una vez corregido: más de un tercio de mi zona de trabajo era océano inflamable.

Mi primera corrección recuperaba la línea de costa y recortaba el dominio con ella — perfecto en mi prueba aislada. En condiciones reales, fracaso: tres consultas de doce al servidor de OpenStreetMap volvieron con error, la línea quedó agujereada, y una línea agujereada no recorta nada. El mar volvió a ser combustible.

La buena solución estaba en otra parte, y explota una convención de OpenStreetMap: cuando se traza una costa, la tierra está siempre a la izquierda del sentido de trazado. Basta entonces, para cada celda, con encontrar el segmento de costa más cercano y mirar de qué lado cae — un simple producto vectorial. A la izquierda la tierra, a la derecha el mar. Un hueco en los datos ya solo cuesta la precisión local alrededor del hueco.

Solo supe que mi primera corrección había fracasado porque me había tomado la molestia de hacer gritar al programa. Cuando no conseguía reconstituir el mar, escribía negro sobre blanco en su informe: «línea de costa presente pero imposible deducir de ella la extensión del mar: el mar abierto corre el riesgo de tratarse como combustible». Un modelo que falla en silencio miente. Un modelo que falla ruidosamente se deja reparar.

La pregunta incómoda: ¿funciona?

A estas alturas, la herramienta producía bonitos mapas. Un bonito mapa nunca ha demostrado nada.

Y tenía a mano con qué ponerla en evidencia: el incendio duraba ya varios días, así que su propio pasado estaba disponible. En lugar de esperar a ver si las próximas previsiones acertaban, mejor repetir las que se habrían podido hacer dos días antes y mirar cuánto valían. Es un método conocido, y tiene nombre: la retroprevisión.

Retroprevisión (o hindcast) — uno se sitúa en un instante del pasado, conserva solo los datos disponibles en esa fecha, simula hacia delante y luego compara con lo que ocurrió realmente. Es la manera estándar de evaluar un modelo de previsión cuando uno no puede permitirse esperar.

Me sitúo pues en la mañana del 24 de julio, descarto todo lo observado después, simulo doce horas y comparo con lo que realmente ardió. Luego vuelvo a empezar el 25. Dos ejecuciones, un puñado de minutos de cálculo — y con mucha diferencia la mejor relación entre el esfuerzo invertido y lo que me enseñó.

La mañana del 24, cuando el fuego corría libremente, el modelo sobrepredice por un factor de 1,7. Para un modelo de propagación es honorable — se está en el orden de magnitud correcto. El 25, cuando los equipos de extinción retomaban el control del frente: factor 12,3.

Lo interesante no es que el modelo se equivoque. Es por dónde pasa la diferencia entre las dos jornadas. El modelo no se volvió malo de un día para otro: mismo código, mismo viento, mismo bosque. Lo que cambió entre el 24 y el 25 fueron los medios de lucha.

Mi programa no los ve. No sabe nada de los efectivos desplegados, ni de las líneas de apoyo — esos cortes que los bomberos abren con bulldozer para detener el frente — ni de las descargas aéreas. Calcula por tanto, sin que yo lo haya decidido explícitamente, un contrafactual sin lucha: lo que haría el incendio si nadie se le opusiera. El 25, la física sola daba 22 758 hectáreas; el fuego solo recorrió 1 645, porque hubo gente que se lo impidió.

Hay un consuelo en esas cifras, y es importante. Cabe en una medida que se llama AUC.

AUC, por área bajo la curva ROC — mide la calidad de una clasificación, independientemente de los valores absolutos. Si tomo al azar una celda que ardió y una que no ardió, el AUC es la probabilidad de que el modelo haya clasificado mejor la primera. 0,5 = cara o cruz, 1 = clasificación perfecta.

Mi AUC vale entre 0,96 y 0,98 en ambos casos — mientras el sesgo de superficie, por su parte, varía por un factor de siete. Dicho de otro modo: el modelo sabe muy bien adónde va el fuego, y se equivoca gravemente sobre cuánto. Es el mejor modo de fallo posible, porque un error de escala se calibra, mientras que un error de dirección condena la herramienta.

Lo que me lleva a la decisión menos intuitiva de todo este bricolaje. Tenía un factor de ajuste listo: frenar la propagación lo justo para volver a caer en el 25 de julio. No lo apliqué. Sería grabar en el modelo la hipótesis «la lucha siempre tiene éxito» — precisamente aquella de la que no hay que fiarse delante de una central nuclear. La herramienta, por lo demás, se niega por sí misma a publicar un factor global cuando sus casos de validación son demasiado heterogéneos, y explica por qué en lugar de promediar dos regímenes incomparables.

Lo que no hace — y es lo más grave

La peor limitación no es ninguna de las que acabo de contar. Cabe en una palabra: el acoplamiento es de sentido único. La meteorología gobierna el fuego; el fuego nunca modifica la atmósfera.

Ahora bien, un gran incendio fabrica su propia meteorología. Es la piroconvección: la columna de aire sobrecalentado que envía hacia el cielo puede subir varios kilómetros y formar un pirocumulonimbo, una auténtica nube de tormenta nacida del propio fuego. Produce rayos secos que encienden focos a decenas de kilómetros, y puede colapsar de golpe, abatiendo contra el suelo una ráfaga violenta, en una dirección cualquiera.

Es exactamente lo que hace escapar a los fuegos que se creían contenidos, y es independiente del viento sinóptico — el viento de gran escala, el que prevé AROME. Por tanto, invisible para mi modelo. Existe un verdadero acoplamiento fuego-atmósfera, lleva nombres como Meso-NH/ForeFire o WRF-SFIRE, y exige medios de cálculo de laboratorio. Fuera de alcance.

El compromiso: no simular el fenómeno, sino evaluar su potencial. Existe para ello un indicador, el índice de Haines continuo, que combina la inestabilidad del aire en altura y su sequedad — en suma, dice si el cielo «hace chimenea» ese día. Cruzado con la potencia radiativa del fuego, me da una puntuación. Una fracción de mis 200 sorteos, igual a esa puntuación, pasa entonces a régimen piroconvectivo: dirección mucho más incierta, propagación aumentada, saltos de fuego más numerosos y más lejanos. Esos sorteos alimentan naturalmente la envolvente extrema.

Un potencial elevado se lee entonces como «las envolventes amplias se vuelven creíbles», nunca como «va a ocurrir esto».

Otro punto ciego, descubierto viendo llegar la ola de calor de esta semana. Mi humedad de los combustibles finos procede de una fórmula clásica de peligro meteorológico, la de Simard, que solo mira la temperatura y la humedad relativa instantáneas. No tiene ninguna memoria. Ahora bien, tres días a 38 °C secan la hojarasca en profundidad, y el suelo con ella. De ahí este resultado absurdo: mi modelo muestra una humedad de los combustibles que sube el día en que hará 39,8 °C. Subestima por tanto el efecto de una ola de calor. Harían falta índices con memoria, del tipo DMC y DC del índice meteorológico de incendios forestales canadiense, que acumulan el déficit hídrico a lo largo de días y semanas. Es el próximo frente de trabajo.

Entonces, ¿el Blayais?

Haz clic para ampliar — o ve a ver la versión viva en kokusho.ss2i.ca.

La respuesta se mantuvo igual del primer al último cálculo: frente observado a 36 kilómetros, ninguno de los 200 escenarios se acerca a menos de 10 kilómetros, viento que empuja en sentido opuesto. La central nunca estuvo amenazada. Y la herramienta lo dice con sus motivos, no con un veredicto.

El emplazamiento realmente expuesto estaba en otra parte: la base aérea de Cazaux, a 7 kilómetros del foco de Biscarrosse, con hasta un 6,7 % de los escenarios alcanzando su zona ampliada.

Y luego hubo esa última mañana en que Cazaux pasó bruscamente a naranja, con un 96,7 % de los escenarios alcanzando esa misma zona. Espectacular. Y falso.

El satélite no había visto nada desde hacía quince horas. Mi programa había recurrido a su hipótesis de repliegue: a falta de saber dónde se encuentra el frente activo, considerar que todo el perímetro recorrido está activo. El incendio se propagaba, pues, en todas las direcciones a la vez, y mi 96,7 % ya no medía una convergencia hacia Cazaux — medía mi ignorancia. La velocidad de aproximación realmente observada, en cambio, era nula.

Desde ahora, en ese caso concreto, el nivel vuelve a caer en «incertidumbre elevada, ninguna aproximación observada» en lugar de gritar ¡fuego! — salvo si se mide realmente una aproximación, en cuyo caso la alerta se mantiene. Es quizá la corrección de la que estoy más contento: impide que la herramienta convierta una ausencia de información en alerta.

Lo que me llevo de todo esto

Todo esto se improvisó en dos días, y el código no lo tecleé yo: lo hice escribir por una IA. El mismo método que para el descapotable checo hace tres semanas, pero esta vez sobre un tema en el que equivocarse no es anodino.

Lo que no se delega, en cambio, es el resto: decidir que se mostrarían envolventes y nunca una trayectoria, elegir las fuentes, exigir que el modelo se pusiera a prueba con el pasado del incendio y no con pruebas de laboratorio, y volver a abrir el mapa de entrada cuando un resultado olía a falso. La máquina escribe rápido y bien. No sabe qué hay que verificar.

Se encontraron cinco errores de fondo en el modelo. Lo que más me sorprendió fue mirar por medio de qué:

• el fuego prisionero de su cicatriz: por una cifra inverosímil en un informe;
• la rasterización que se atascaba: por un cálculo que ya no devolvía el control;
• el mar combustible: porque acabé mirando el mapa de entrada, el que nadie piensa en abrir;
• la reconstrucción del litoral que no aguantaba en condiciones reales: por un aviso que me había tomado la molestia de escribir para ese caso concreto;
• la falsa alerta naranja: confrontando lo que decía la simulación con lo que decía la observación.

Ninguno fue encontrado por las pruebas automáticas. Tengo sesenta y cuatro, y cada uno de esos bugs tiene ahora la suya — impedirán la regresión. Pero ninguna prueba podía adivinar que OpenStreetMap no cartografía el océano. Las pruebas verifican aquello en lo que ya se ha pensado. Callan sobre el resto.

Lo que funcionó fue el roce con lo real: los datos verdaderos, el mapa verdadero, el pasado verdadero del incendio. La retroprevisión me enseñó más en dos ejecuciones que dos días de desarrollo.

Y su enseñanza principal no era «el modelo se equivoca en tanto». Era: el modelo no responde a la pregunta que yo creía hacerle. Le preguntaba qué iba a hacer este incendio. Me respondía qué haría si nadie se le opusiera.

Es una información útil — es incluso exactamente la que hace falta para saber de qué es capaz un incendio. Pero no es la que uno cree leer en un mapa.

🔥 Ver la herramienta en línea — kokusho.ss2i.ca

Experimental, sin valor oficial. En caso de incendio, la única fuente que da fe es la prefectura: landes.gouv.fr · gironde.gouv.fr.

Son las 16 h, fuera hace 37,7 °C en el momento más caluroso de las últimas veinticuatro horas, y mi cuarto de baño marca 30 °C. No el cuarto de baño después de una ducha: el cuarto de baño vacío, con las persianas bajadas, sin nadie dentro. Eso es lo que una ola de calor le hace a una casa — la va llenando despacio, grado a grado, por el tejado, por las paredes, por cada cristal, y al caer la tarde la casa se ha convertido en un radiador que le devuelve a uno la jornada entera mientras intenta dormir.

Contra eso, en el momento, poco se puede hacer. Pero la ola de calor tiene un defecto: la noche. Hacia las 4 h de la madrugada, el aire exterior baja a 20 °C, a veces menos. Durante unas horas hay fuera una reserva de frescor gratuita, inmensa, renovada cada noche — y la única pregunta que importa es: ¿cómo hacerla entrar?

Un extractor de cuarto de baño como caballo de tiro

La casa ya tenía todo lo necesario, en realidad. Bastaba con mirarlo de otra manera.

Abajo, una toma de aire fresco, instalada en su día para alimentar la estufa de leña. Arriba, en la planta superior, el cuarto de baño — el punto más caliente de la casa, física elemental. Y entre ambos, una modesta VMC (la sigla francesa de la ventilación mecánica controlada) que desde hace años solo se ocupa de la humedad: se enciende cuando la ducha empaña, se apaga cuando está seco.

Ahora bien, si se hace funcionar ese extractor por la noche, ocurre algo más interesante: aspira el aire caliente acumulado arriba, lo expulsa fuera, y la depresión tira del aire fresco de la noche por la toma de aire de abajo. Toda la casa se convierte en un circuito: el aire fresco entra por la planta baja, la atraviesa, sube y vuelve a salir por arriba llevándose el calor del día. El beneficio no es local, del cuarto de baño — es un tiro térmico a escala de la casa, con un ventilador de unas decenas de vatios como único motor.

Los anglófonos lo llaman free cooling. A mí me gusta más decirlo a mi manera: la noche trabaja para nosotros.

La regla, y las trampas que evita

Quedaba por escribir la regla de decisión. El pequeño ordenador que gobierna el extractor consulta ahora la meteorología y solo enciende la extracción si se cumplen cuatro condiciones a la vez:

1. el máximo exterior de las últimas 24 horas supera los 22 °C — estamos de verdad en temporada cálida;
2. el cuarto de baño supera los 24 °C — arriba hace calor de verdad;
3. el salón supera los 20 °C — la casa no está ya refrescada;
4. el aire exterior está al menos 3 °C más fresco que el interior — si no, removeríamos aire para nada.

La sutileza está en la primera condición. Uno podría pensar que basta con comparar dentro y fuera. Error — y un error que saldría caro en enero: una casa calentada con la estufa a 24 °C con 5 °C fuera muestra una diferencia de 19 °C, más que suficiente para disparar una regla ingenua… que entonces tiraría el calor de la leña por la ventana, aspirando aire helado por la toma de aire. La misma que alimenta la estufa. El sistema se sabotearía a sí mismo.

De ahí el criterio de temporada: el máximo exterior en 24 h deslizantes. Mis registros de enero no pasan de 14,6 °C; los del verano nunca bajan de 22 °C. Entre ambos, un abismo — la barrera es infranqueable por accidente. Y sobre todo, no mira la temperatura del instante: una noche a 13 °C después de un día a 32 °C es precisamente el momento de extraer, y un umbral instantáneo lo habría prohibido.

Lo que dicen las cifras

Antes de conectar nada, reproduje la regla sobre los datos reales de la semana anterior — la casa lo registra todo desde hace años, que sirva de algo.

La semana en una imagen: el exterior (azul) respira de 20 a 38 °C, el cuarto de baño (rosa) encaja el golpe y se instala en torno a los 28-30 °C. Y en el extremo derecho, ese trazo que sube: la orden del ventilador que pasa a ON — el sistema acaba de armarse, a unas horas de su primera noche.

Veredicto: en la semana del 6 al 13 de julio, la regla habría disparado 48 horas de extracción. Diferencia media entre dentro y fuera en el momento de los disparos: 4,9 °C. Franjas: concentradas entre la 1 h y las 9 h de la mañana, nunca por la tarde — la regla ha encontrado por sí sola el ritmo de las noches.

Y la cifra que más me ha divertido: durante esa misma semana de ola de calor, el extractor no funcionó ni un solo minuto. El aire estaba tan seco (del 29 al 37 % de humedad en el cuarto de baño, con un umbral de disparo del 60 %) que su misión histórica nunca lo despertó. Un motor perfectamente funcional, instalado, cableado, alimentado — y dormido al 100 %, justo la semana en que más tenía que ofrecer. Es exactamente el tipo de yacimiento que me gusta: cero material que comprar, solo una regla que escribir.

Esta noche es la primera en condiciones reales. La incógnita es franca: la toma de aire se dimensionó para la combustión de una estufa, no para ventilar una casa. Si su sección es demasiado justa, el ventilador tirará sobre todo de las fugas de estanqueidad y el caudal real será decepcionante. Será la curva de mañana por la mañana la que decida — si el cuarto de baño se desmarca claramente de las noches anteriores, está ganado.

Acontecimientos notables: −7 °C y +41,7 °C, el mismo año

Una casa que lo registra todo acumula su pequeña mitología. La tabla de récords exteriores de 2026, por su parte, casi no necesita comentario:

• 6 de enero de 2026: −7,0 °C. El día más frío jamás anotado por la estación. La estufa funcionó sin parar, la toma de aire de abajo aspiraba escarcha.
• 23 de junio de 2026: 41,7 °C. El más caluroso — antes incluso del verano oficial. Tres horas seguidas por encima de los 41 °C.

La mañana del récord: la llanura bajo la nieve, cielo límpido — el mismo cielo despejado que, seis meses después, dejará que el sol empuje el termómetro hasta los 41,7 °C.

48,7 grados de amplitud en menos de seis meses, en el mismo lugar, medidos por la misma cadena de sensores. La media, en cambio, se desliza sin hacer ruido — y ahí está precisamente la trampa.

Me recordó a Mélenchon, en su primera campaña presidencial, que ya se irritaba con la palabra «calentamiento»: una palabra demasiado suave, casi una promesa de primavera temprana, dos grados más sobre una media, ¿quién lo notaría? Y que le prefería, con insistencia, «desajuste climático». El matiz no es cosmético, es toda la cuestión: lo que estropea las casas, las cosechas y a las personas no es la media que se desliza — son los extremos que se separan en ambos sentidos. Las heladas más mordientes y las olas de calor más tempranas. Una máquina climática que no ha ganado simplemente un grado: que ha perdido su termostato.

El 13 de julio a lo largo de los años, desde 1970 (agregados de Open-Meteo para mi casa). La media sube +0,32 °C por década — 19,5 °C en los primeros años de la serie, 21,5 °C en los diez últimos. Dos grados en medio siglo: eso es el «calentamiento», y en este gráfico parece inofensivo. Lo que solo se ve entornando los ojos es la curva rosa de las máximas, que se desboca — los picos recientes revientan el techo de los años 70. El desajuste es ella.

Mis dos récords de 2026 sostienen la demostración por sí solos. Y exactamente por eso se instrumenta una casa: uno no se prepara para una media, se prepara para los extremos — en ambos sentidos.

Bajo el capó, para quien quiera construirlo

Todo lo anterior se sostiene con material de fondo de cajón — ese es el punto importante, y la razón de ser de esta entrada: cualquiera puede montarlo un domingo.

• En el cuarto de baño: una Raspberry Pi Zero W (~15 €), un sensor de temperatura/humedad DHT11 de 2 € en un GPIO, y un emisor de radio de 433 MHz de 2 € en otro.
• El extractor no se modifica ni en un cable. Está enchufado a un enchufe con mando a distancia de 433 MHz de supermercado (~10 €): la Pi se limita a reproducir los códigos ON/OFF del mando original (biblioteca rpi-rf, protocolo 1, pulso de 350 µs — los valores se capturan escuchando el mando con un receptor de 1 €). Ningún cableado a 230 V, reversible en treinta segundos.
• Un pequeño servidor en alguna parte — aquí un VPS de unos pocos euros, pero un NAS o una segunda Pi harían exactamente lo mismo: una página PHP, una base SQLite, y nada más.

Los obreros de la casa. Arriba, el veterano: una Raspberry Pi Model B de 2012 — 14 años de servicio, gobierna la calefacción del salón en Ruby. En medio, la Pi Zero del cuarto de baño, que acaba de aprender el free cooling. Abajo, sus ojos: el DHT11, el sensor de temperatura/humedad de 2 € — la cajita azul estriada con la que cualquier aficionado a la electrónica se ha cruzado alguna vez. (Fotos: Gareth Halfacree CC BY-SA 2.0; Evan-Amos, dominio público; Crackopl CC BY-SA 3.0.)

La caza de vatios forma parte del juego, para máquinas que funcionan las 24 h del día. La Pi Zero consume ~0,6 W. La vieja Model B se lleva ~2,5 — por culpa de sus reguladores lineales de 2012, que queman el exceso de tensión en puro calor, y de su chip USB/Ethernet alimentado permanentemente. Contra la arquitectura no se puede hacer nada, pero sí se puede recortar la grasa del software: hurgando en el veterano esta semana, encontré un MySQL y un Apache de 2017 que llevaban nueve años funcionando para nada, una salida HDMI activa en NTSC sin pantalla al otro extremo, un Bluetooth nunca emparejado y un demonio que esperaba los atajos de un teclado fantasma. Todo apagado: dos grados menos en el procesador en plena ola de calor, 38 MB de RAM devueltos y, sobre todo, se acabaron las escrituras inútiles en la tarjeta SD — ella sí que es la verdadera asesina. A escala de la factura es anecdótico (2,5 W ≈ 22 kWh/año ≈ 5 €), pero un sistema que uno quiere ver durar diez años tiene que ser magro.

Las decisiones de arquitectura las dicta todas la misma obsesión: sobrevivir a las averías, a los reinicios del router y a los años.

• Nada de demonio: un cron. El controlador se lanza cada 5 minutos, vive veinte segundos, mide, decide, envía su código de radio y se apaga. Un proceso que no está en ejecución no puede tener fugas ni bloquearse — la Pi va por 267 días de uptime sin pensar en ello.
• Siempre es la Pi la que tira, nunca el servidor el que empuja. La Pi vuelve a descargar su configuración (un YAML) cada minuto con un simple curl, y consulta la meteorología en el momento de decidir. Detrás de cualquier router, NAT o cambio de IP, funciona — y la casilla «Activar» marcada en la página web es efectiva sobre el terreno al minuto siguiente.
• La meteorología viene de Open-Meteo (open-meteo.com): API gratuita, sin clave, con histórico. Un cron horario la archiva del lado del servidor, y la Pi recibe un JSON mínimo: temperatura actual, máximo en 24 h deslizantes, temperatura del salón. Servir únicamente lo observado — nunca la previsión — tiene su importancia: la línea de las 23 h anunciaba 24 °C mientras fuera hacía 35, y una regla alimentada con previsiones habría aspirado el aire del horno.
• Una tabla única para todo: observations (source, metric, value, unit, metadata). Sensores, consignas, órdenes, meteorología — todo entra en el mismo molde. Añadir un sensor es añadir una source, cero migraciones. Es esta tabla la que permitió reproducir la regla sobre los archivos antes de conectarla.
• Fallo cerrado. Servidor inalcanzable o meteorología con más de dos horas de antigüedad → la Pi vuelve a su lógica de humedad original. Sin máximo de 24 h → sin extracción (la barrera de temporada no se salta por accidente). El peor escenario de una avería es el comportamiento de antes.
• Las curvas de la página las traza uPlot, una biblioteca de ~50 KB que aguanta decenas de miles de puntos sin inmutarse.

Y una palabra sobre lo que, a mis ojos, no es negociable: estos datos nunca salen de mi perímetro. Lo que miden estos sensores es el interior de una casa — cuándo uno se ducha, cuándo la calienta, cuándo está vacía. Las Pis empujan sus lecturas por SSH hacia un servidor que administro yo, la página que las muestra pide una contraseña, y el bucle se detiene ahí. Nada de nube del fabricante, nada de «skill» de Alexa, nada de SaaS domótico que cierra dentro de tres años llevándose el histórico, ni un byte en las analíticas de nadie. La única dependencia exterior va en el otro sentido: la casa descarga la meteorología pública de Open-Meteo, no envía nada. El día que cambie el servidor — un NAS, otro VPS, una caja de zapatos — se mueve un archivo SQLite y todo vuelve a arrancar.

Presupuesto total por habitación instrumentada: menos de 30 €. El lujo no está en el material — está en los años de datos que se acumulan, que se pueden consultar el día en que se tiene una idea, y que no pertenecen a nadie más que a uno mismo.

Lo que viene: entrar en el espesor de las cosas

Hasta ahora, todos mis sensores miden habitaciones. El siguiente paso es más íntimo: entrar en el aislante.

El proyecto: una varilla clavada verticalmente en el aislante del desván, con cuatro sondas de temperatura escalonadas — superficie, un tercio, dos tercios, fondo contra la placa de yeso. Encima, una quinta sonda en el aire bajo las tejas, que en estos días sube a 60-70 °C. Debajo, el termostato del salón, ya instalado. Una columna de medida completa, del sol a la sala de estar.

Lo que contará, día tras día:

• El desfase real: ¿cuántas horas tarda el pico de calor bajo las tejas en atravesar el aislante? El fabricante anuncia un valor teórico; el aislante apelmazado y envejecido hace lo que le da la gana. Quiero la cifra verdadera, en mi casa.
• La amortiguación: ¿cuánto se aplasta la amplitud día/noche entre la superficie y el fondo?
• El efecto de las chimeneas de tiro que instalé en el tejado para evacuar el calor bajo las tejas: con meteorología comparable, la superficie del aislante debe estar más fresca si el tiro hace su trabajo. Dos columnas de sondas — una cerca de las chimeneas, otra lejos — y la respuesta caerá por sí sola.
• Y a largo plazo, un detector de envejecimiento: un desfase que se acorta año tras año es un aislante que se degrada. Más vale saberlo antes de que lo diga la factura de calefacción.

En cuanto al material, nada heroico: sondas estancas de unos pocos euros en un bus de un par de hilos, un microcontrolador que duerme el 99,9 % del tiempo con dos baterías recuperadas — lo bastante para aguantar unos dos años sin cambiar las pilas. La electrónica se queda al fresco en la parte baja del desván; solo las sondas suben al frente.

Y en invierno, se invierte todo

La ola de calor terminará. Y la misma fontanería intelectual volverá a servir, vuelta del revés como un guante.

La próxima obra que me ronda la cabeza: paneles térmicos de aire en la fachada exterior — captadores solares de lo más simple, una caja negra acristalada en la que el aire se calienta al sol de invierno. Incluso con 5 °C fuera, un panel bien orientado saca aire a 30 o 40 °C a mediodía. Conectado a la toma de aire de la casa, se convierte en precalentamiento gratuito: en lugar de aspirar aire a 5 °C para alimentar la estufa y compensar la extracción, se aspira aire ya templado por el sol.

Y el bucle se cierra con elegancia: es la misma lógica de decisión que el free cooling, invertida. En verano se extrae de noche cuando fuera \< dentro. En invierno se inyectará de día cuando panel > dentro. Los mismos sensores, la misma meteorología, la misma regla de cuatro condiciones con sus barreras — solo cambia el signo. Las sondas del aislante dirán incluso si el precalentamiento se nota en el gradiente del desván.

Una casa, en el fondo, es un sistema térmico que se ignora a sí mismo. La mía apenas empieza a conocerse — y esta noche, por primera vez, va a intentar refrescarse sola mientras duermo. Mañana les cuento si lo ha conseguido.

Post scriptum, la mañana del 14 de julio

La primera noche ha tenido lugar. El ventilador extrajo durante cerca de doce horas, de las 19 h a las 8 h, con una pausa de una hora hacia la 1 h de la madrugada — la diferencia había vuelto a caer por debajo del umbral de parada, la regla hizo exactamente lo que se le enseñó.

Resultado en bruto: cuarto de baño de 31 °C al acostarse a 26 °C al levantarse. La mejor noche de la semana. Pero la cifra que me gusta está en otra parte. Las noches anteriores, el exterior bajaba a 23-24 °C y el cuarto de baño se quedaba clavado en 28: cuatro o cinco grados de diferencia al levantarse, la firma de una casa que no intercambia nada con la noche. Esta vez, el controlador mantuvo la diferencia entre 1,4 y 2,4 °C hasta la mañana — el interior siguió al exterior en su descenso, hora tras hora. La renovación del aire está ahí, y la incógnita de la toma de aire queda despejada: da caudal.

Transparencia obligada: las ventanas estuvieron abiertas esa noche, ola de calor obliga — imposible separar su parte de la del ventilador. La próxima noche se hará con las ventanas cerradas, solo el extractor. Si por la mañana el cuarto de baño sigue pegado al exterior a dos grados de diferencia, la demostración será completa. La ciencia doméstica avanza una noche cada vez.

Episodio siguiente: las curvas de la primera noche con las ventanas cerradas, y lo que 48 horas de tiro nocturno cambian (o no) en una ola de calor.

Ilustración: reinterpretación al estilo manga de una foto del vendedor — el original está en justchairs.eu.

Me crucé en internet con un sofá cama checoslovaco de los años 70, firmado OPP Drevovyroba, a la venta en una tienda de Budapest. Línea baja, reposabrazos esculturales en contrachapado de teca curvado, y un mecanismo despachado en una frase: «el sofá se transforma en cama con un solo gesto». 1 550 €, a 1 500 km de mi casa, y unas dimensiones que no encajan en mi salón. La conclusión se imponía: en lugar de comprarlo, volver a dibujarlo — y aprovechar para entenderlo.

Esta entrada cuenta el ejercicio, llevado a cabo con una IA (Claude) que pilota Blender en directo. Spoiler: la IA se equivocó tres veces sobre el mecanismo, y eso es precisamente lo que hace interesante la historia.

El montaje

En cuanto a herramientas, la cosa se ha vuelto casi rutinaria: Blender, un pequeño addon que abre un servidor en la máquina (BlenderMCP) y la IA que se conecta a él. Diez minutos de instalación. A partir de ahí, escribe Python dentro de Blender, construye geometría, hace capturas del viewport para comprobar su trabajo y vuelve a empezar. Yo miro el modelo girar en directo en mi pantalla y comento.

La apuesta desde el principio: un modelo paramétrico. Nada de esculpir con el ratón, sino un script con un bloque de parámetros en cabecera — anchura, altura de asiento, grosor de los cojines, inclinación del respaldo — y toda la geometría, mecanismo incluido, que se recalcula al cambiar un valor. Veremos que esta decisión salvó la partida más de una vez.

Tres teorías para un mecanismo

El vendedor aporta unas quince fotos, ninguna del mecanismo en acción. Así que hubo que deducir.

Teoría n.º 1: la bisagra simple. Primera interpretación de la IA: el respaldo bascula hacia atrás sobre una bisagra, como un clic-clac. Modelado, animado… y demolido al mirar mejor las fotos: en posición cama, la franja delantera del colchón queda delante del asiento, no detrás. El respaldo pasa, por tanto, por encima del asiento. Adiós a la bisagra.

Teoría n.º 2: la cinemática de cuatro barras. Si el respaldo tiene que sobrevolar el asiento sin chocar con él, me decía yo, tiene que girar y trasladarse — o sea, dos pivotes y unas bieletas. La IA se tomó la idea en serio, muy en serio incluso: escribió un solver que coloca los pivotes por búsqueda numérica a lo largo de las mediatrices de las dos poses, maximizando la holgura entre respaldo y asiento durante el vuelco. Resultado: un mecanismo de cuatro barras perfectamente funcional, con 17 mm de holgura verificados en todo el recorrido. Elegante. Y completamente falso.

Teoría n.º 3: el pivote único. Fue un primer plano del reposabrazos lo que zanjó la cuestión: los tornillos que unen el brazo al respaldo son una fijación rígida, no un pivote. El brazo y el respaldo forman una sola pieza móvil, que gira alrededor del espárrago redondo visible en el costado del cajón. Un solo pivote por lado. Y ahí todo se ilumina: como el pivote está bajo y centrado, el arco de rotación sube por encima del asiento. Nunca hubo ningún problema de colisión que resolver. Los diseñadores checos no necesitaban bieletas — simplemente habían colocado bien un eje.

La lección merece enmarcarse: cuando la IA entiende mal la realidad, no se equivoca tímidamente — sobreingenieriza. El mecanismo de cuatro barras era la respuesta brillante a un problema que no existía.

El bonito gesto matemático sobrevivió al naufragio de la teoría n.º 2: dos poses de un sólido en el plano determinan un centro de rotación único — la intersección de las mediatrices. Ya no hace falta búsqueda numérica: el pivote se calcula, exactamente. Y cuando se le da la geometría de entrada correcta, cae a pocos milímetros de la ubicación del espárrago original. Una bonita validación cruzada, cincuenta años después.

El reposabrazos que se convierte en pata

Otro hallazgo de las fotos en posición cama: el respaldo sobresale 46 cm en voladizo por delante del cajón, y es el reposabrazos el que lo sostiene — al bascular, la rama del reposabrazos apunta al suelo y su extremo se apoya en él, como un puntal improvisado. La pequeña bandeja donde uno apoyaba el codo se convierte en un patín.

En el modelo paramétrico invertimos la lógica: en lugar de dibujar el reposabrazos y luego constatar dónde aterriza, la IA calcula sus puntos de apoyo por rotación inversa a partir de su objetivo en el suelo. La punta del reposabrazos se define como «el punto que, tras una rotación de 110°, toca el suelo en y = -47 cm». Comprobación en el frame final: z = 0,0 mm. De paso se entiende también por qué el reposabrazos original es tan corto y está tan retrasado: su posición no es una elección estética, es la restricción de aterrizaje. La forma sigue al mecanismo.

Donde superamos al original

Entender está bien; mejorar está mejor. Tres defectos del mueble original pasaron por el tamiz.

El colchón con dos firmezas. En el original, el asiento grueso y el respaldo más fino dan una cama con dos zonas. Corrección: grosor común de 14,5 cm en todas partes, superficie de descanso de 126 × 200 cm perfectamente uniforme.

El asiento de 65 cm de profundidad. Imposible recostarse manteniendo los pies en el suelo. Mirando mejor, el original ya hace trampa: su respaldo no está en el borde trasero sino adelantado sobre la plataforma, y la zona muerta que queda detrás se convierte en cama al desplegar. Lo parametrizamos como es debido: prof_utile = 50 cm, y el pivote se recalcula solo.

La cara mullida en el lado equivocado. El verdadero rompecabezas. El vuelco hacia delante expone el dorso del respaldo como superficie de descanso: si la cara delantera es mullida para sentarse, se duerme sobre la cara firme. El original tomó partido y peor para el asiento. Nuestra solución: un eje central que atraviesa el respaldo por su mitad. Durante el vuelco, el respaldo da media vuelta sobre sí mismo — y la misma cara mullida sirve de respaldo de día y de cama de noche. Consecuencia en cascada: el brazo ahora se detiene a media altura del respaldo para sostener ese cojinete… justo a la altura del reposabrazos. El reposabrazos es el cojinete.

Quedaba impedir que el respaldo girase libremente a su antojo. Primera idea: un pestillo. Segunda idea, mucho mejor: un tetón que corre por una ranura semicircular de 180°, concéntrica al eje, fresada en la cara interior del brazo. Los extremos de la ranura son los topes de las dos posiciones — el recorrido de la ranura es el recorrido de la media vuelta. Cero cerrojos que manipular, indexación automática, y en ambas poses las cargas aprietan el tetón contra su tope. Verificado en el modelo: el tetón está exactamente en el extremo de la ranura en las dos posiciones.

Lo que me llevo de esto

Una foto vale más que mil tokens. Las tres correcciones decisivas vinieron de primeros planos que le envié a la IA: los tornillos rígidos, el reposabrazos-pata, el respaldo adelantado. Razona notablemente bien — pero sobre lo que se le muestra.

La IA sobreingenieriza cuando entiende mal. El solver de cuatro barras era magnífico e inútil. Desconfíen de las soluciones brillantes: comprueben primero el problema.

Lo paramétrico abarata los errores. Tres rediseños completos del mecanismo, y cada vez unos minutos de recálculo en lugar de horas de remodelado. Como los puntos de anclaje (pivote, apoyos en el suelo, cojinete) se calculan en lugar de colocarse a mano, todo sigue.

La colaboración tiene sentido. Ella calcula intersecciones de mediatrices y verifica holguras al milímetro; yo veo que un asiento de 65 cm de profundidad es invivible y que un tornillo no es un pivote. Ninguno de los dos habría producido este diseño por su cuenta.

Continuará en el próximo episodio: planos 2D acotados, detalle del cojinete y de la ranura, y fabricación en contrachapado de 18. El script y el modelo ya funcionan — solo faltan las dimensiones de mi salón.

Los archivos

Todo se puede descargar, sírvanse:

• sofa_parametrique.py — el script completo: parámetros, cálculo del pivote, construcción, animación. Para abrir en Blender (pestaña Scripting) y volver a ejecutar después de cambiar los PARAMS.
• canape_convertible.blend — la escena de Blender con la animación de vuelco (frame 1 = sofá, frame 61 = cama).
• canape_convertible.glb — el modelo en formato glTF, animación incluida, legible en cualquier parte (visores 3D en línea, motores de juego, RA).

Fotos del sofá original: justchairs.eu. Modelo 3D: Blender 5.1 + BlenderMCP.

Todo empezó con una discusión tonta.

«Apaga, ya es la hora.» Una frase de lo más corriente. Salvo que aquella noche la respuesta no fue el suspiro normal de un adolescente. Fue seca, a flor de piel, casi hostil — como si acabara de arrancarle algo. Diez minutos después volvía a ser él mismo. Pero entre medias hubo ese momento: un chaval que no reconocía, irritable, cerrado, en otra parte.

Y no era la primera vez. El patrón se repetía: veía vídeos de Roblox — un youtuber llamado Kevko, Steal a Brainrot, Lucky Block — y cuando lo interrumpía en pleno vídeo, la cosa se descontrolaba. No después. En pleno vídeo.

Podría haberlo dejado ahí. Decretar «las pantallas son malas», poner una regla y agotarme haciéndola cumplir. Pero tenía una intuición más precisa, y un hijo demasiado inteligente como para tragarse una prohibición sin explicación. Necesitaba entender exactamente qué pasaba en su cabeza. Y para eso necesitaba datos, no impresiones.

Acto II — La investigación

Primera hipótesis, la más inquietante: ¿y si el problema fuera el contenido en sí? Muchos vídeos de Roblox giran en torno a robar, vencer, tender trampas, trolear, ganar a los demás. ¿Estaba mi hijo pasando las tardes interiorizando una lógica de competición y dominación?

El problema es que no tenía ni idea. Yo sentía. Y el sentimiento, en materia de educación, es el camino más corto hacia la injusticia.

Así que decidí hacer lo que haría un periodista: leer las fuentes. No mirar distraídamente un par de vídeos — recuperar las transcripciones completas de los vídeos más grandes del canal y analizarlas, palabra por palabra.

Identifiqué sus 10 vídeos más vistos (de 426 000 a 786 000 visualizaciones), extraje los subtítulos automáticos en francés y lo limpié todo: 48 437 palabras de transcripción. Luego conté. Clasifiqué el vocabulario en grandes familias — urgencia, competición, recompensa, acumulación, conflicto, burla — y medí su frecuencia por cada 1 000 palabras.

Ahí las cifras empezaron a hablar. Y no dijeron lo que yo creía.

El contenido agresivo que yo temía — la dominación, la burla, el troleo — era casi inexistente: 0,4 y 0,5 por cada 1 000 palabras, básicamente ruido estadístico. Mi hijo no estaba aprendiendo a aplastar a los demás.

Lo que dominaba era otra cosa muy distinta: la acumulación y la urgencia. Siempre un objeto más. Siempre más rápido. Las dos palabras-tema más frecuentes de todo el canal eran «encore» («más», «otra vez») y «vite» («rápido»). Y al medir las interjecciones y las risas — un indicio de la intensidad — algunos vídeos subían hasta 23 marcadores de excitación por cada 1 000 palabras, sin un solo respiro.

Me había equivocado de culpable. El peligro no era ideológico. Era fisiológico.

Acto III — Lo que encontramos

Quedaba confrontar mis cifras con la ciencia. Y ahí todo encajó.

1. La máquina de recompensa imprevisible. El corazón de Steal a Brainrot es el azar: el Lucky Block que puede soltar un brainrot raro, el ingreso pasivo que corre sin parar y empuja a volver a conectarse. Es exactamente el refuerzo de razón variable — el mecanismo que los casinos explotan desde hace un siglo porque es el más adictivo que existe. El cerebro libera dopamina al anticipar la recompensa, no al recibirla. Uno se queda en tensión permanente: ¿y si el próximo es el bueno?

2. No es la violencia, es el ritmo. La pieza clave la encontré en un estudio publicado en la revista Pediatrics en 2011. Unas investigadoras mostraron a unos niños 9 minutos de un dibujo animado simplemente rápido — cortes cada once segundos — sin ninguna violencia. Justo después, su capacidad de concentración y de paciencia estaba degradada de forma medible, en comparación con niños que habían visto un dibujo animado lento. Nueve minutos. El formato Kevko es precisamente eso: caudal verbal saturado, montaje picado, cero respiración. No es lo que cuenta lo que actúa sobre mi hijo. Es la velocidad.

3. Y por eso explotaba en casa. Cuando yo cortaba en pleno vídeo, el cerebro de mi hijo seguía «arriba». Y la Academia Americana de Pediatría lo dice explícitamente: al apagar la pantalla, la dopamina cae, y esa caída nos deja gruñones e irritables. La irritabilidad que me llevaba en plena cara no era insolencia. Era un estado químico previsible — la resaca de un estado de excitación al que no se había dejado bajar.

Lo más cruel es el efecto relacional. El contenido lo ponía en un estado en el que rechazaba, sin quererlo, a las personas presentes en la misma habitación. Y la trampa del «siempre uno más» es que nunca hay un buen momento para parar — así que nunca había realmente un momento en el que estuviera presente con nosotros. El verdadero coste no era el tiempo de pantalla. Eran los momentos reales, con personas reales, que desaparecían.

El matiz, porque hay que ser honesto. No, el brainrot no «pudre el cerebro» en sentido literal — fue la palabra del año del diccionario Oxford en 2024, pero es un marcador cultural, no un diagnóstico. No, la famosa «desintoxicación de dopamina» no es un concepto científico real: uno no «reinicia» su dopamina apagando las pantallas. Y sí, el brainrot es también humor de chavales, un lenguaje generacional. Mi hijo no está en peligro. Pero está, por construcción, manipulado — y eso sí tiene arreglo.

Acto IV — Lo que intentamos hacer al respecto

Decidí hacer una apuesta: la de su inteligencia.

Nada de prohibición frontal — un chaval listo se la salta y te guarda rencor. En su lugar, cambié de bando. El mensaje ya no era «papá te lo prohíbe» sino «hay ingenieros a los que pagan millones que están jugando con tu cerebro, y yo estoy en tu equipo contra ellos». Nada irrita más a un adolescente que ser manipulado. Era mi mejor palanca.

Luego le propuse un experimento, porque le gusta la ciencia:

«Durante una semana, observa simplemente tu estado de ánimo en los 10 minutos después de apagar. Puntúalo sobre 10. Y compara: cuando te cortan en pleno vídeo, frente a cuando tú eliges el momento de parar. Si me equivoco, lo reconoceré. Pero mira los datos tú mismo.»

Devolverle el control es precisamente lo que la investigación identifica como el factor que más reduce las crisis de fin de pantalla. Y convertir una discusión recurrente en una investigación compartida es sacarlo de la posición defensiva.

Por último, vimos vídeos juntos — nada de sermones, sino análisis hechos por gente a la que un adolescente respeta:

• Serie « Dopamine » — ARTE, episodio TikTok (~9 min): desmonta, técnica por técnica, la aplicación que él conoce. Tono clínico, cero moralina, el clic de «me están manipulando». → https://www.youtube.com/watch?v=-pOWdBpVR3s
• « Et tout le monde s’en fout » — #59 Les algorithmes (~7 min): divertido, cómplice, nunca aleccionador. → https://www.youtube.com/watch?v=5NiVg4DBJrI
• Tracks ARTE — « Brainrot : est-ce qu’internet fait pourrir nos cerveaux ? »: aborda de frente su universo. (Conviene verlo antes uno mismo.) → https://www.youtube.com/watch?v=ubT8hS0lAlg
• Stupid Economics — « L’économie de l’attention »: el enfoque «tu atención es el producto que se vende». → https://www.youtube.com/watch?v=rMV1WaWGb3I
• Tristan Harris — TED Talk (subtítulos en francés): el exingeniero de Google que dio la primera voz de alarma. Credibilidad máxima. → https://www.ted.com/talks/tristan_harris_how_a_handful_of_tech_companies_control_billions_of_minds_every_day?language=fr

El plan: empezar por el primero (9 minutos, reconoce su aplicación), dejarle comentar, no sacar conclusiones en su lugar. El formato corto y factual hace el trabajo por sí solo.

Epílogo

No he «ganado». No es una batalla que se gane en una noche, y nunca fue ese el objetivo. Pero algo ha cambiado: mi hijo ha dejado de ver a un padre que confisca y ha empezado a ver un mecanismo que lo manipula. Ahora tiene un vocabulario para nombrarlo. Y entre nosotros, la conversación ha sustituido a la discusión.

El contenido que ve no es el mal. Ni siquiera es ideológico — mis propios datos me lo demostraron. Es solo una máquina, muy bien diseñada, para mantener el cerebro de un niño en estado de excitación máxima y hacerlo volver. Entender la máquina ya es liberarse a medias de ella.

Y esa es una apuesta que estoy dispuesto a hacer por la inteligencia de mi hijo.

Fuentes y referencias

Sobre la dopamina y la irritabilidad tras la pantalla - American Academy of Pediatrics — Screen Time and Temper Tantrums (la caída de dopamina al apagar vuelve irritable): https://www.healthychildren.org/English/family-life/Media/Pages/screen-time-and-temper-tantrums-helpful-tips-for-parents.aspx

Sobre el ritmo/montaje que degrada la atención - Lillard, A. S., & Peterson, J. (2011). The Immediate Impact of Different Types of Television on Young Children’s Executive Function. Pediatrics, 128(4), 644-649. (El estudio «SpongeBob».) Resumen accesible (NPR): https://www.npr.org/sections/health-shots/2011/09/12/140401099/spongebob-may-be-too-speedy-for-preschool-brains - Metaanálisis reciente sobre los efectos a corto plazo de los medios en la atención y las funciones ejecutivas de los niños (PMC, 2024): https://pmc.ncbi.nlm.nih.gov/articles/PMC12412071/

Sobre los bucles de recompensa y el diseño adictivo - The Vegas Effect of Our Screens — Psychology Today (refuerzo de razón variable): https://www.psychologytoday.com/us/blog/tech-happy-life/201901/the-vegas-effect-of-our-screens - Why We Can’t Stop — Communication Research / Taylor & Francis (elementos recompensantes de los juegos y juego problemático en adolescentes): https://www.tandfonline.com/doi/full/10.1080/15213269.2023.2242260 - Debunking the Dopamine Detox Trend — The Scientist (la «desintoxicación de dopamina» es un mito): https://www.the-scientist.com/debunking-the-dopamine-detox-trend-72036

Sobre el «brainrot» y Steal a Brainrot - « Brain rot » named Oxford Word of the Year 2024 — Oxford University Press: https://corp.oup.com/news/brain-rot-named-oxford-word-of-the-year-2024/ - Steal a Brainrot — ficha enciclopédica (ingreso pasivo, bucle de juego, monetización): https://en.wikipedia.org/wiki/Steal_a_Brainrot

Sobre el uso de las pantallas como regulador emocional - Using screens to calm kids may hurt their emotional regulation — CNN (eco de un estudio publicado en JAMA Pediatrics): https://edition.cnn.com/2022/12/12/health/tantrum-distraction-screens-parenting-wellness

Recursos de vídeo divulgativos (citados en el artículo) - Serie Dopamine — ARTE (lista de reproducción): https://www.youtube.com/playlist?list=PL8Ax_z5vzflwdvoTnARE5FiYl42Sg-fYb - Et tout le monde s’en fout — #59 Les algorithmes: https://www.youtube.com/watch?v=5NiVg4DBJrI - Brainrot : est-ce qu’internet fait pourrir nos cerveaux ? — Tracks / ARTE: https://www.youtube.com/watch?v=ubT8hS0lAlg - L’économie de l’attention — Stupid Economics: https://www.youtube.com/watch?v=rMV1WaWGb3I - Tristan Harris — TED (subtítulos en francés): https://www.ted.com/talks/tristan_harris_how_a_handful_of_tech_companies_control_billions_of_minds_every_day?language=fr

Nota metodológica: el análisis léxico se basa en las transcripciones automáticas (subtítulos de YouTube en francés) de los 10 vídeos más vistos del canal, es decir, ~48 000 palabras. Límite asumido: una transcripción mide las palabras, no el volumen sonoro ni el ritmo de montaje — y es precisamente ese ritmo el que la ciencia identifica como el factor más determinante. Las cifras son, por tanto, un indicio convergente, no una medida directa de la sobreestimulación.