The Electratón runs again: a 2001 energy controller, back on the track
In November 2001, for my social service—the community-service requirement for graduating in Mexico—I worked with two classmates on the energy control of an electric competition vehicle, an Electratón. The problem was concrete: current peaks above 60 A were significantly hurting the batteries’ range.
Twenty-five years later I wanted to go back to that problem. Not to show that today you can write a more complex controller, but to see how much of that answer still stands when you put it against a simulator, and how much depends on things we could not measure in 2001.
The problem of November 2001
From the document of that time I still have this: a controller to manage the vehicle’s energy demand, above all when accelerating and after braking, on an ATMEL 8535 programmed in assembly. The documented diagnosis tied the peaks above 60 A to a significant loss of range.
The design had three mechanisms:
- Soft start: avoid a sudden current demand when starting to accelerate.
- Recovering the operating point: after braking, keep the motor from jumping straight back into a high-demand condition.
- A 60 A comparator: detect when the current went above that threshold.
The system also logged voltage, current and speed every 20 seconds, and the data was downloaded over a serial link.
The constraints of an AVR in assembly
The 8535 was an 8-bit microcontroller with 8 KB of program memory and 512 bytes of RAM. Everything was written in assembly: every comparison, every count. There was no operating system and no libraries.
You do not build a model of the vehicle or run an optimization with that. You make simple decisions that fit in a few cycles: ramp up slowly, do not go past a threshold, do not jump back. What is interesting is that those simple decisions were, underneath, an energy policy.
What we kept and what we can no longer verify
I have to be precise here, because it is easy to reconstruct too much.
I do not have the 2001 source code. I did not recover the motor specifications, the battery chemistry or capacity, or any lap or range results. I am also not going to state a format of that competition’s rules without the documentation.
I do not know everything about the controller either:
- The shape of the soft start: a progressive increase of the drive is a reasonable reading, but I have neither its shape nor its duration on record.
- What exactly the “operating point” after braking was: a duty cycle, a speed reference or some other parameter.
- What the comparator did on detecting 60 A: cut the drive, limit it or trigger some other protection.
- How the driver’s throttle related to the controller.
And one more thing that matters: a log every 20 seconds is not enough to characterize short current peaks. I do not have the procedure used to diagnose them, and I am not going to say it was those logs. I also do not have range results from before and after the controller.
The reconstruction
So what I built is not a translation of the assembly. It is an experimental reimplementation in C, inspired by the documented principles, put against a simulator. It runs on the lab’s Raspberry Pi 5.
The simulator has a simple model of a DC motor, a battery with its internal resistance, and the mechanical load: mass, rolling and air. Everything physical is a modeling assumption, not the original vehicle:
| Assumption | |
|---|---|
| Vehicle with driver | 150 kg |
| Motor | DC, 24 V, a top speed of about 48 km/h |
| Battery | two 12 V lead-acid, 35 Ah, 0.03 Ω internal resistance |
| Track | a 1 km lap: two 350 m straights and two 150 m curves taken at 25 km/h |
| Driver | flat out on the straight, brakes for the curve and holds it |
A lead-acid battery delivers less capacity the more current you draw from it. That is modeled with the Peukert effect, an exponent I do not know for those batteries. So I ran four: 1.0, which is no effect at all, and 1.1, 1.2 and 1.3. And I apply it to each current pulse, with no capacitor smoothing it: it is the assumption that least favors the controller.
Three strategies, with the same track, the same driver, the same charged battery and the same parameters:
- No control: the motor’s duty cycle is whatever the throttle asks for.
- Ramp: the duty cycle rises at most from 0 to 100 % in three seconds; going down is immediate.
- Ramp and a 60 A limit: also, while the motor current is above 60 A, the duty cycle goes down.
I did not model the “operating point after braking”: I do not know what it was.
The results
With Peukert 1.2:
| Strategy | Until the battery is empty | In 30 minutes | Current peak |
|---|---|---|---|
| No control | 27.6 km | 17.4 km | 254 A |
| Ramp | 28.3 km | 17.3 km | 191 A |
| Ramp and 60 A | 30.6 km | 16.9 km | 64 A |
The peak is the motor current, which is what the battery delivers on each pulse; with the limit it goes a little above 60 A before the comparator pulls it back.
The two distance columns measure different things, and that is the trade-off I wanted to see. When energy is the limit, the comparator makes the battery go 11 % farther. When the battery is enough for the whole race, no control wins: in 30 minutes it covers 2.8 % more, because it comes out of every curve faster.
What the limit gains does not depend on Peukert alone. Without the effect, the limit still goes 6.5 % farther. About three quarters of that comes from losing less as heat, in the resistance of the battery, the motor and the wiring; the rest, from going a little slower, which costs less air and less braking. With Peukert 1.3, the advantage rises to 13.5 %. In other words: the direction of the result holds, but its size depends on an assumption I cannot confirm.
The ramp alone barely helps. It goes 2.6 % farther than no control. Looking at the current millisecond by millisecond shows why: it lowers the peaks, but does not remove them. At the start, from 254 A to 191 A, because a three-second ramp reaches full duty before the vehicle picks up speed. And the peak is not only at the start: it comes back at every curve exit, twice a lap, when the driver accelerates from about 25 km/h. Without control that is about 133 A for five seconds; with the ramp, about 117 A. The comparator, on the other hand, acts on every one of them. That comes from how I modeled the driver, but it says something that made sense in 2001: the problem was not one start, it was all of them.
The threshold is a trade-off too. Moving the limit, with the same assumption:
| Threshold | Until the battery is empty | In 30 minutes | Time per lap |
|---|---|---|---|
| 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 |
At 30 A, the battery goes 49 % farther than with no control, but every lap takes 11 % longer than at 60 A. No threshold wins at everything: it depends on whether the race is decided by energy or by time.
What a 20-second log sees
The simulator also takes a sample every 20 seconds, like the 2001 log, and compares it with what happens millisecond by millisecond.
Without control, the current was above 60 A for 258 seconds of the 48 minutes the battery lasted. The 20-second log took 143 samples, and 12 of them landed above 60 A: roughly the same proportion, 8 % against 9 % of the time. But the highest it saw was 110 A, and the real peak was 254 A. A sample every 20 seconds can tell you that something happens now and then; it cannot tell you how high it goes or how long it lasts.
It is the same problem as in the average that never happened: the measurement you have decides what you can see.
What changed in twenty-five years, and what did not
In 2001 we had an 8-bit microcontroller, assembly and a log every 20 seconds. Today I have a 64-bit processor on a board the size of a card, a simulator that runs a whole race in under a second, and the current of every millisecond. I can move an exponent and see how much the conclusion changes. In 2001 we could not.
But the question is the same. The peaks that eat the battery, the trade-off between lasting and finishing first, the measurement that does not see what matters: computing power solved none of that.
The code, the tests and the run’s data are in the repository, with the assumptions together in one place for anyone to change.
The same question
In 2001 we were trying to get an electric vehicle to make better use of the energy available, with control decisions run by a microcontroller with limited resources. Twenty-five years later there are much more powerful processors, simulators, better instruments and analysis tools.
But the fundamental question is still the same: how do we get the best possible performance without wasting the resources we have?
What is interesting about going back to the Electratón was not to show that we can write a more complex controller today, but to find out how much we learned about a problem that is still relevant.
Israel Negrete Lepe is an electronics engineer. Twenty-five years making different systems work together under real conditions: from the sensor, the vehicle or the transaction to the backend, the data, security and operations. Today, increasingly, edge AI. I take on projects by the hour or by deliverable: israel0negrete@gmail.com.