Skipping the Image Entirely: Event Simulation Fast Enough to Learn Flight in 30 Minutes

Event cameras are a natural fit for small, fast robots. They report per-pixel brightness changes rather than full frames, which gives microsecond latency, very high dynamic range, and power draw in the milliwatt range — exactly the properties a 56 gram quadrotor needs when it flies through clutter at two and a half metres per second. The sensor has never been the bottleneck. The bottleneck has been training.

Reinforcement learning for vision-based flight needs hundreds of millions of simulated interactions. The standard approach renders a photorealistic image, then converts that image into an event stream. Rendering dominates the cost, and because event cameras respond to edges and motion rather than appearance, most of that rendering work computes detail the sensor would never report. The result is a pipeline where the simulator is thousands of times slower than the thing being simulated, and where photorealistic textures consume compute that contributes nothing to the event signal.

Core innovation

The authors build an analytic simulator around a simple observation: an event camera fundamentally measures moving contrast edges. If that is all the sensor reports, then the simulator only needs scene geometry and ego-motion — not appearance.

Direct synthesis from geometry. Event streams are generated analytically from scene structure and camera motion, with no image rendered at any point in the loop. Because the simulation never touches a rasterized frame, the cost per observation collapses.

A 17 microsecond observation. A 64x64 event observation is produced in 17 microseconds on a single GPU, which the authors measure as over 400x faster than a state-of-the-art rendering-based pipeline.

Training that fits in a coffee break. End-to-end reinforcement learning for goal-directed obstacle avoidance converges in under 30 minutes, roughly three orders of magnitude faster than training on rendered events. That changes the practical workflow: architecture and reward iteration becomes an afternoon activity instead of a cluster reservation.

Transfer checked against a physically based simulator. Policies trained in this analytic world transfer zero-shot to ray-traced event simulation in Isaac Sim, which is the check that separates “the simulator is fast” from “the simulator is a useful approximation.”

Results

The hardware result is the one that matters.

• 83% success in cluttered courses unseen during training, at mid difficulty (traversability probability around 0.57), flying at 2.4 m/s average goal velocity.
• 70% success retained in a texture-dense simulated indoor hall — a deliberately adversarial setting for a sensor that keys on edges.
• The policy was quantized to a 1.2 MB int8 network running fully onboard a 56 gram Crazyflie carrying a Prophesee GenX320 event camera and an OpenMV N6 microcontroller.
• With no fine-tuning, no external processing, and no positioning system, it achieved 82% average success across three real obstacle courses of increasing difficulty (5/5, 5/6, 4/6 flights).

The 82% figure is the honest one to quote, and the per-course breakdown is what makes it credible. A single aggregate number hides whether the policy degrades gracefully or falls off a cliff on the hardest course; 5/5, 5/6, 4/6 shows a real but survivable decline.

Limitations

Flight trials are small — eighteen flights across three courses — so each success rate carries wide uncertainty, and the paper reports no crash analysis or failure attribution. The evaluation is goal-directed obstacle avoidance in courses, not a navigation task with a map, a return-to-home requirement, or a moving obstacle. The 2.4 m/s average velocity is brisk for a 56 gram platform but well below the agility that event cameras are usually pitched for, so the regime where events beat frames most decisively is not the regime tested. The simulator’s fidelity is bounded by its geometry-only assumption: it cannot represent events caused by lighting changes, reflections, or non-Lambertian surfaces, and texture-dense environments already cost 13 points of success. Finally, all real flights appear to share one airframe and one camera, so sensor-to-sensor variation is unmeasured.

Industry implications

The interesting consequence is not a faster simulator; it is that the training loop for event-based flight is now cheap enough to be routine. When a policy trains in half an hour, teams can afford to sweep rewards, sensing rates, and course distributions the way they currently sweep hyperparameters — and event-based navigation stops being a research specialty and becomes an engineering option.

The onboard result sets a concrete integration target: a 1.2 MB int8 network on a microcontroller, with no companion computer, no VIO, and no external positioning. For inspection drones, indoor survey platforms, and any airframe where payload and power are the binding constraints, that bill of materials is what makes event sensing deployable. It also removes a common objection — that event pipelines need a GPU companion board that costs more power than the camera saves.

The remaining gap is task scope. Course traversal is the entry-level demonstration; the commercial value sits in inspection, tracking, and operation near moving machinery, where the dynamic range advantage of events should matter more than it does in a static obstacle field. This paper supplies the training infrastructure and the embedded deployment path. Showing that the same stack handles those richer tasks is the next step, and it is now a much cheaper experiment to run.