Short answer: An event camera discards the frame. Each pixel independently reports only when its brightness changes, timestamped as it happens, so the sensor outputs a stream of changes rather than a sequence of pictures. The result is microsecond-level timing, very high dynamic range and far less data when little is moving — bought at the price of an unfamiliar data type that conventional vision software cannot read. In robotics, suppliers such as Prophesee, profiled in the directory's machine vision section, are building this into a commercial sensing category.
A different kind of pixel
In a frame camera, every pixel is read out together at a fixed rate, moving or not: a static scene costs the same bandwidth as a chaotic one, and fast motion smears across the exposure. In an event camera, each pixel watches its own brightness and fires an event — its coordinates, the time, and whether brightness rose or fell — when the change crosses a threshold. Nothing moves, nothing is sent. A spinning rotor, a vibrating part or a drone's sudden pitch produces a dense, precisely timed stream. The output is not an image in any normal sense, and the first evaluation task is internal: make sure your team understands it is buying a new data type, not a better webcam.
Where the speed actually pays
The applications that justify event sensing share one property: the information lives in fast change. High-speed counting and inspection on lines where parts move too quickly for frame exposure. Vibration and oscillation monitoring, where the event stream reads like a microphone for motion. Fast obstacle avoidance and docking for mobile robots and drones, where reaction latency, not image beauty, is the specification. Low-light and high-dynamic-range scenes — a robot passing between shadow and glare — where frames saturate and event pixels, working logarithmically, keep reporting. If your application's problem is a static scene read slowly, a conventional camera remains the right and cheaper eye; our comparison of 3D camera technologies covers the depth-sensing side of the same decision.
The algorithm ecosystem is the real specification
Frames arrive with sixty years of software behind them; events arrive with a young research ecosystem. Standard tasks — tracking, optical flow, recognition, depth estimation — all have event-based methods, but they are less standardised, less tooled and harder to hire for than their frame-based equivalents. Suppliers therefore sell development kits, reference pipelines and software libraries alongside the sensor, and those deserve as much evaluation as the silicon: What does the vendor's software do out of the box? What data formats does the stream convert into for the rest of your stack? Who in the market has shipped a product on this sensor, as opposed to publishing a paper with it? In a young category, the ecosystem questions are the due diligence.
Events plus frames: the pragmatic architecture
Most serious designs do not choose between the two sensing types; they fuse them. A frame camera provides the recognisable image — what the thing is — while the event stream provides the timing layer — exactly when and how it moved. Some sensors combine both outputs in one device for precisely this reason. Evaluation should therefore be architectural: decide which decisions in your system are latency-critical and which are identity-critical, and let that split, rather than novelty, assign the sensors. Teams that start from the decision list buy one evaluation kit and learn something; teams that start from the sensor buy three and hold a seminar.
How to evaluate an event camera
Run it against your fastest real motion, not a demonstration fan. Measure end-to-end latency from motion to your software's reaction, in your lighting, including the interface and driver — not the sensor's headline figure alone. Check behaviour at your scene's extremes: the flicker of industrial lighting can flood event sensors with noise events, and the mitigations (filters, thresholds) are themselves settings to test. Ask about the practicalities that decide projects quietly: lens and mounting options, synchronisation with your other sensors, power draw, and the supplier's roadmap for the exact model you are designing in. Event cameras reward teams who evaluate them as a system component — which, at their best, is exactly what they are: the fastest eye a robot can currently buy, for the jobs where fast is the whole job.
Frequently asked questions
What is an event camera?
A camera whose pixels independently report only brightness changes, each with a precise timestamp, instead of capturing full frames at a fixed rate. The output is a stream of events — where and when change happened — rather than a sequence of images.
What are event cameras used for in robotics?
Tasks where information lives in fast change: high-speed counting and inspection, vibration monitoring, fast obstacle avoidance and drone or mobile-robot reaction, and scenes with extreme lighting range where frame cameras saturate or smear.
Can event cameras replace normal cameras?
Usually they complement rather than replace them. Frame cameras answer 'what is it'; event streams answer 'exactly when and how did it move'. Many designs fuse both, and some sensors provide both outputs in one device.
What should I check before designing in an event camera?
End-to-end latency in your lighting and on your interface, behaviour under flickering industrial light, the maturity of the vendor's software and reference pipelines, synchronisation with your other sensors, and who else has shipped a product on the sensor.