Overdrive Arena, continued: fresh batteries and six cars on the grid

Sat, 26 Sep 2026 00:00:00 +0000

In the first Overdrive Arena post, I mostly wrote about talking to the cars again: Bluetooth LE, reading the track, controllers and racing from a PC. Near the end was a section about old batteries. The application could display their voltage, watch the drop under load and reconnect when a car rebooted.

That helped explain what was happening. Eventually, though, it was time to close the editor and get the soldering iron out.

More importantly, it was time to play. These changes grew out of playing with the kids. Driving a car from Python was the starting point; playing race after race as a family gave the project a different direction. You need to recover a car that has left the track, understand who won, restart without configuring everything again and keep a race interesting when players have different skill levels.

The game has evolved considerably since the first post. The six-car grid and parade are the newest additions, still in my local working version.

The next chapter starts under the body

I replaced batteries to bring the cars back into service. The photos from that session capture the other half of the project: a removed body shell, a small circuit board, two motors and a cell that occupies a fair amount of the available space.

Under the body shell, the software problem becomes a very physical one.

Here, replacing the battery means soldering its leads to the board. The cover photo shows the iron at the circuit board, with the replacement battery beside it. This is not soldering directly onto the cell’s pouch.

Space under the shell is tight. With a lithium cell, electrical compatibility and polarity matter as much as dimensions and advertised capacity. A damaged or swollen cell should not go back into service.

Replacement batteries, with a car for scale.

Overdrive Arena’s voltage monitoring remains useful after the repair: it provides a way to keep watching what happens to the power supply while the motors work. Battery replacement and measurement logs become two parts of the same repair effort.

Opponents that learn the corners

The original AI mostly kept cars moving at a cruising speed. Each car can now have one of four difficulty levels: Easy, Normal, Hard and Extreme. AI cars can fill out a race, or race entirely on their own.

They brake before corners and accelerate on straights. In race mode, they also check traffic before changing lanes: is someone ahead, is someone approaching from behind, is a lane available? Lane changes begin on straights, and route choices account for upcoming turns.

The interesting part is adaptation to each car. A confirmed departure from the track near a corner reduces that car’s corner-speed limit by 15%. A series of clean turns allows it to increase again. Extreme explores the limit more aggressively and accounts for lane radius: the inside and outside of a bend call for different speeds.

This learning belongs to the session: it survives between races but resets when the application restarts or the circuit changes. Behaviour can evolve as we play, without assuming that every old car has the same grip.

Leaving the track should not end the game

Playing with the kids makes the moments between things working properly matter a lot. A car has stopped off the circuit: you need to put it back, find its position and continue.

There is now a RECOVER command, also available by clicking the right stick. After replacing the car on the track, it triggers a short reading attempt: at most 1.5 seconds, at up to 250 mm/s. Braking or emergency stop cancels a player’s search. A disconnected car or one on its charger does not start searching.

An explicit off-track report stops the AI immediately. Missing telemetry causes a bounded search and then a stop, rather than endless attempts. Recovery invalidates the partial lap but preserves laps already completed.

Close racing with different skill levels

Fair Game is especially useful for family races. It applies a speed handicap based on position: the leader loses 50% of commanded speed, the last car has no penalty, and intermediate positions are distributed between them. With three cars, that means 50%, 25% and 0%.

The handicap follows live positions and applies to AI as well. The aim is to leave an opportunity to catch up. It does not guarantee equality: drivers still have to negotiate corners and stay on the track. Records for this mode are kept separate from ordinary races.

A shared speed ceiling also sets the pace, from 200 to 2,000 mm/s of commanded speed. It caps players, AI and boosts while respecting lower individual limits. Actual speed depends on the car and circuit; the setting mainly lets us choose a pace for the game together.

Counting the laps we can see

Position tracking and lap counting were brought together around a shared continuous estimate of progress around the circuit. That matters in a game: a car completing a circuit on screen should advance the lap counter even if a finish-line message was missed.

Tracking combines Bluetooth position fixes with predicted movement. Messages are timestamped on arrival to account for time spent waiting inside the application. After one second without a fresh position, prediction freezes: radio silence must not invent extra laps.

Corrections must neither count the same finish twice nor subtract distance already displayed. Reversing or recovering invalidates the current lap; a complete forward circuit is required to score again. This is less spectacular than a new mode, but it makes the outcome of a race much easier to understand.

Personal bests and rematches

Records now go beyond the single fastest time. The game saves best laps and completed races per circuit, including personal rankings by car and controller. Human and AI results are separate, as are modes and race lengths. You can improve your own time without beating the fastest driver in the house.

The HIGH SCORES scorebook opens in a local browser. It shows circuit shapes, offers filters and updates while the game runs, so it can stay on a second screen. One practical limitation: identical controllers are distinguished by player slot, not by the child’s identity. Keeping their connection order consistent helps preserve the same rankings.

The details around each race have changed too. Controllers pulse through the countdown, with a stronger pulse at the start. At the finish, the winning car stays lit and blinks while the others go dark. Start / Options starts another grid with the same selections. A rematch no longer requires repeating the whole setup.

Cars reconstruct the circuit together

The scanner in the first post waited for one car to report a usable complete lap. Cars can now pool compatible observations: a code or turn missed by one car can be filled in using other cars’ readings and wheel-distance measurements.

The map grows live, with question marks for uncertain sections. A car that stops reading codes stops independently while the others continue. The saved circuit is replaced only when reconstruction produces a complete, geometrically closed loop.

During a play session, the benefit is straightforward: preparation depends less on one car completing a perfect scan.

Six cars, two rows

Once more hardware is back in circulation, the next question follows naturally: how do you manage a small pack?

In the local version currently under development, the application looks for up to six cars by default. The connection screen distinguishes discovered cars, cars selected for connection and cars actually connected. It is a small detail, but “I only found four cars” and “I found six, but two are not connected yet” describe different problems.

The starting grid is changing too. With six participants, it uses two rows of three. The second row stops behind the finish-line row. Sending everyone to the same marker is no longer enough: each car has both a lane and a row to reach.

Another change since the first post: a participant that struggles to recover its position is no longer simply dropped from the grid after a timeout. Placement retries, with recovery bursts separated by pauses. The start waits for the participants; to leave one out, you return to setup and explicitly park it.

That is a deliberate trade-off. A stubborn car can hold up the start, but the application no longer quietly decides to race without it.

Sometimes I just want to watch them drive

The new PARADE mode serves a simpler purpose than racing: let the cars drive around the circuit together.

The code has them share a lane and adjust their speed to spread out along the track. The nominal pace is 350 mm/s, with adjustments between 200 and 450 mm/s, subject to speed and corner limits. A car can stop if the one ahead is too close. Parked cars stay parked.

There are no blasters, winners or records in this mode. Braking pauses your car, throttle resumes it, and Escape stops the parade.

Spacing still needs to be put through its paces on the circuit with the whole fleet. The idea gives the game another use: a small demonstration of robots trying to keep their distance, without needing six human drivers.

Repair continues in software

A soldering iron does not fix lost Bluetooth links, and automatic reconnection does not repair a tired battery. The two kinds of work complement each other.

The first post was about bringing back the game after the app disappeared. Playing with the kids supplied the next chapter: repair the hardware, make races easier to follow, recover after leaving the track and make everyone want to start the next one.

That is part of what I enjoy about this project. A single session can involve a soldering problem, a Bluetooth problem and a traffic problem. And all of it ends up on a toy-car track.

The source and protocol notes are in Overdrive Arena on GitHub. The six-car grid and parade described here are my current work in progress; they may change before being published in the repository.

Soldering | Antoine Weill--Duflos