El Electratón vuelve a correr: un control de energía de 2001, otra vez en la pista
En noviembre de 2001, para el servicio social, trabajé con dos compañeros en el control de energía de un vehículo eléctrico de competencia Electratón. El problema era concreto: los picos de corriente de más de 60 A afectaban de manera importante la autonomía de las baterías.
Veinticinco años después quise volver a ese problema. No para demostrar que hoy se puede escribir un controlador más complejo, sino para ver qué tanto de aquella respuesta sigue en pie cuando se pone contra un simulador, y qué tanto depende de cosas que en 2001 no podíamos medir.
El problema de noviembre de 2001
Del documento de entonces conservo esto: un control para administrar la demanda de energía del vehículo, sobre todo al acelerar y después de frenar, con un ATMEL 8535 programado en ensamblador. El diagnóstico documentado relacionaba los picos de más de 60 A con una reducción importante de la autonomía.
El diseño tenía tres mecanismos:
- Arranque suave: evitar una demanda brusca de corriente al empezar a acelerar.
- Recuperación del punto de operación: después de una frenada, evitar que el motor volviera de golpe a una condición de alta demanda.
- Un comparador de 60 A: detectar cuando la corriente pasaba de ese umbral.
Además, el sistema registraba voltaje, corriente y velocidad cada 20 segundos, y la información se bajaba por comunicación serial.
Las restricciones de un AVR en ensamblador
El 8535 era un microcontrolador de 8 bits con 8 KB de memoria de programa y 512 bytes de RAM. Todo se escribía en ensamblador: cada comparación, cada cuenta. No había sistema operativo ni bibliotecas.
Con eso no se hace un modelo del vehículo ni una optimización. Se toman decisiones sencillas que quepan en unos cuantos ciclos: subir despacio, no pasar de un umbral, no volver de golpe. Lo interesante es que esas decisiones sencillas eran, en el fondo, una política de energía.
Lo que conservamos y lo que ya no podemos verificar
Aquí tengo que ser preciso, porque es fácil reconstruir de más.
No tengo el código fuente de 2001. No recuperé las especificaciones del motor, la química ni la capacidad de las baterías, ni los resultados de vueltas o autonomía. Tampoco voy a afirmar una modalidad del reglamento de aquella competencia sin la documentación.
Del control, tampoco sé todo:
- La curva del arranque suave: es razonable pensar en un incremento progresivo del accionamiento, pero no tengo documentadas la forma ni la duración.
- Qué era exactamente el “punto de operación” después de frenar: un ciclo de trabajo, una referencia de velocidad u otro parámetro.
- Qué hacía el comparador al detectar los 60 A: cortar el accionamiento, limitarlo o activar otra protección.
- Cuál era la relación entre el acelerador del piloto y el control.
Y una cosa más, que importa: un registro cada 20 segundos no alcanza para caracterizar picos de corriente de corta duración. No tengo el procedimiento con el que se diagnosticaron, y no voy a decir que fueron esos registros. Tampoco tengo resultados de autonomía antes y después del control.
La reconstrucción
Por eso lo que hice no es una traducción del ensamblador. Es una reimplementación experimental en C, inspirada en los principios documentados, puesta contra un simulador. Corre en la Raspberry Pi 5 del laboratorio.
El simulador tiene un modelo sencillo de motor de corriente directa, de una batería con su resistencia interna y de la carga mecánica: masa, rodadura y aire. Todo lo físico es hipótesis de modelado, no del vehículo original:
| Hipótesis | |
|---|---|
| Vehículo con piloto | 150 kg |
| Motor | corriente directa, 24 V, unos 48 km/h de velocidad máxima |
| Batería | dos de 12 V de plomo-ácido, 35 Ah, 0.03 Ω de resistencia interna |
| Recorrido | vuelta de 1 km: dos rectas de 350 m y dos curvas de 150 m que se toman a 25 km/h |
| Piloto | a fondo en la recta, frena para la curva y la sostiene |
La batería de plomo-ácido entrega menos capacidad mientras más corriente se le pide. Eso se modela con el efecto Peukert, un exponente que no sé cuánto valía en aquellas baterías. Por eso corrí cuatro: 1.0, que es no tener el efecto, y 1.1, 1.2 y 1.3. Y lo aplico a cada pulso de corriente, sin un capacitor que lo alise: es la hipótesis que menos favorece al control.
Tres estrategias, con el mismo recorrido, el mismo piloto, la misma batería cargada y los mismos parámetros:
- Sin control: el ciclo de trabajo del motor es lo que pide el acelerador.
- Rampa: el ciclo de trabajo sube, a lo más, de 0 a 100 % en tres segundos; bajar es inmediato.
- Rampa y límite de 60 A: además, mientras la corriente del motor pasa de 60 A, el ciclo de trabajo baja.
El “punto de operación después de frenar” no lo modelé: no sé qué era.
Los resultados
Con Peukert 1.2:
| Estrategia | Hasta vaciar la batería | En 30 minutos | Pico de corriente |
|---|---|---|---|
| Sin control | 27.6 km | 17.4 km | 254 A |
| Rampa | 28.3 km | 17.3 km | 191 A |
| Rampa y 60 A | 30.6 km | 16.9 km | 64 A |
El pico es la corriente del motor, que es la que da la batería en cada pulso; con el límite pasa un poco de 60 A antes de que el comparador la regrese.
Las dos columnas de distancia cuentan cosas distintas, y ése es el compromiso que quería ver. Cuando la energía es el límite, el comparador hace rendir la batería un 11 % más. Cuando la batería alcanza para toda la carrera, gana el que no tiene control: en 30 minutos recorre un 2.8 % más, porque sale más rápido de cada curva.
Lo que gana el límite no depende sólo de Peukert. Sin el efecto, el límite sigue rindiendo un 6.5 % más. Unas tres cuartas partes de eso vienen de perder menos en calor, en las resistencias de la batería, del motor y de los cables; el resto, de ir un poco más despacio, que cuesta menos aire y menos frenada. Con Peukert 1.3, la ventaja sube a 13.5 %. Es decir: el sentido del resultado aguanta, pero el tamaño depende de una hipótesis que no puedo confirmar.
La rampa sola casi no ayuda. Rinde un 2.6 % más que sin control. Mirando la corriente milisegundo a milisegundo se ve por qué: baja los picos, pero no los quita. En el arranque, de 254 A a 191 A, porque una rampa de tres segundos llega a fondo antes de que el vehículo tome velocidad. Y el pico no está sólo en el arranque: vuelve en cada salida de curva, dos veces por vuelta, cuando el piloto acelera desde unos 25 km/h. Sin control son unos 133 A durante cinco segundos; con la rampa, unos 117 A. El comparador, en cambio, actúa en cada una. Eso sale de cómo modelé al piloto, pero dice algo que en 2001 tenía sentido: el problema no era un arranque, eran todos.
El umbral también es un compromiso. Moviendo el límite, con la misma hipótesis:
| Umbral | Hasta vaciar la batería | En 30 minutos | Tiempo por vuelta |
|---|---|---|---|
| 30 A | 41.1 km | 15.0 km | 118.0 s |
| 60 A | 30.6 km | 16.9 km | 106.5 s |
| 100 A | 28.5 km | 17.3 km | 104.9 s |
Con 30 A, la batería rinde un 49 % más que sin control, pero cada vuelta tarda 11 % más que con 60 A. No hay un umbral que gane en todo: depende de si la carrera la decide la energía o el tiempo.
Lo que ve la telemetría cada 20 segundos
El simulador también toma una muestra cada 20 segundos, como el registro de 2001, y la compara con lo que pasa milisegundo a milisegundo.
Sin control, la corriente pasó de 60 A durante 258 segundos de los 48 minutos que duró la batería. La telemetría cada 20 segundos tomó 143 muestras, y 12 cayeron arriba de 60 A: más o menos la misma proporción, 8 % contra 9 % del tiempo. Pero la mayor que vio fue de 110 A, y el pico real fue de 254 A. Una muestra cada 20 segundos puede decir que algo pasa a veces; no puede decir qué tan alto llega ni cuánto dura.
Es el mismo problema de el promedio que nunca pasó: la medición que tienes decide lo que puedes ver.
Qué cambió en veinticinco años, y qué no
En 2001 teníamos un microcontrolador de 8 bits, ensamblador y un registro cada 20 segundos. Hoy tengo un procesador de 64 bits en una placa del tamaño de una tarjeta, un simulador que corre una carrera completa en menos de un segundo y la corriente de cada milisegundo. Puedo mover un exponente y ver cuánto cambia la conclusión. En 2001 no podíamos.
Pero la pregunta es la misma. Los picos que se comen la batería, el compromiso entre rendir y llegar primero, la medición que no ve lo que importa: nada de eso lo resolvió la potencia de cómputo.
El código, las pruebas y los datos de la corrida están en el repositorio, con las hipótesis juntas en un solo lugar para que cualquiera las mueva.
La misma pregunta
En 2001 intentábamos que un vehículo eléctrico aprovechara mejor la energía disponible con decisiones de control ejecutadas por un microcontrolador de recursos limitados. Veinticinco años después hay procesadores mucho más potentes, simuladores, mejores instrumentos y herramientas de análisis.
Pero la pregunta fundamental sigue siendo la misma: ¿cómo conseguimos el mejor desempeño posible sin desperdiciar los recursos que tenemos disponibles?
Lo interesante de volver al Electratón no era demostrar que hoy podemos escribir un controlador más complejo, sino comprobar cuánto aprendimos sobre un problema que sigue vigente.
Israel Negrete Lepe es ingeniero en electrónica. Veinticinco años haciendo que sistemas distintos funcionen juntos en condiciones reales: del sensor, el vehículo o la transacción al backend, los datos, la seguridad y la operación. Hoy, cada vez más, IA en el borde. Acepto proyectos por hora o por entrega: israel0negrete@gmail.com.