Bird Flight Simulator — a virtual fleet for real platform testing

Imagine an engineer changes the configuration for a slow-speed zone. How can they verify that the scooter detects the zone, the backend recognizes the location, Powerline sends the speed limit, the scooter applies the command, and telemetry reports the updated state?

Doing this with physical scooters is slow, expensive, and difficult to automate. We wanted something much better.

Instead of simulating the backend, we simulated the scooter. We launched virtual Bird brains that connected directly into Powerline exactly like physical scooters.

Each virtual scooter established a Powerline connection, streamed GPS coordinates, published telemetry, received commands, maintained internal state, and behaved like a real scooter.

The backend couldn't tell the difference. As far as the platform was concerned, they were real vehicles.

Once we had virtual scooters, another question appeared: how do you actually ride them? That became the Flight Simulator.

Instead of walking outside and physically riding a scooter, engineers could control virtual scooters through a game-like interface. The experience felt remarkably similar to piloting a remote drone — except the drone existed only inside Bird's infrastructure.

The simulator wasn't replaying mock data. Every interaction flowed through Bird's production communication layer.

Every message traveled exactly the same path that a real scooter would use. That meant the simulator automatically inherited Habitat configuration, geofences, slow-speed zones, no-ride zones, operational commands, firmware behavior, and backend rules.

If production behavior changed, the simulator reflected it automatically.

One of my favorite capabilities was that the simulator could operate in any city where Bird had deployed scooters.

Engineers could instantly test Los Angeles, Santa Monica, Paris, Berlin, Austin, or any other supported city. Maps and Street View provided real-world context while the virtual scooter moved through production geofences exactly as a physical scooter would.

The simulator wasn't only useful for manual testing. Every ride could be recorded, and that recording became a deterministic test case.

Imagine discovering a bug where scooters slowed down too early entering a slow-speed zone. Instead of physically repeating the ride over and over, engineers could update Habitat configuration, replay the ride, observe behavior, adjust configuration, and replay again.

The same ride could be executed repeatedly until the desired behavior was achieved. The simulator became both a debugging tool and an automated testing environment.

The UI wasn't limited to one vehicle. I designed the simulator so engineers could instantly switch between different virtual scooters.

That made it possible to test multiple cities, compare behaviors, monitor fleets, inspect telemetry, and validate different configurations — all from a single interface.

In effect, engineers could pilot an entire virtual fleet from one screen.

Looking back today, I realize we weren't really building a simulator. We were building a digital twin.

Long before "digital twins" became a widely used engineering term, we had created virtual vehicles that behaved like real scooters inside a production mobility platform.

That allowed engineers to safely test complex operational scenarios without requiring physical hardware. The project dramatically reduced the friction involved in validating changes across one of the most complicated parts of Bird's infrastructure.