DAGr — truly asynchronous graph neural networks for event cameras, published in Nature 2024

The latency number that matters for terminal guidance is the time from a new event arriving at the sensor to the corresponding update being incorporated into the guidance law. Every processing step between those two points adds to that latency: binning events into windows, running inference on a batch, passing the result to the estimator. For a guidance loop that needs to respond on a millisecond timescale, each added step is expensive.

DAGr — published in Nature Machine Intelligence in 2024 — makes a specific architectural choice that eliminates most of that added latency: it processes each event individually, as it arrives, without accumulating batches. This sounds simple but is architecturally challenging. Standard GNNs operate on static graphs; DAGr maintains a dynamic graph that updates with each new event, propagating activations through the network topology in response to each individual event arrival.

The architecture

In standard event-camera GNNs, you accumulate a window of events, build a graph with events as nodes and spatial/temporal proximity as edges, run message-passing over the static graph, and produce an output. This introduces a minimum latency equal to the window length. For a 10 ms window, detection latency is at least 10 ms regardless of when the target event arrives within the window.

DAGr replaces the static graph with a dynamic graph that evolves as events arrive. When a new event occurs, it becomes a new node in the graph with edges to spatially and temporally nearby existing nodes. The network propagates the new node’s activation through the existing graph using a selective update rule — only nodes affected by the new node’s arrival are recomputed. This amortizes the computation across individual events rather than batching it.

The result is that the first update after a target generates its first event arrives with latency equal to a single forward pass through the affected subgraph — typically 200–500 microseconds on the hardware the authors benchmark. Subsequent events from the same target update the activation incrementally. The effective detection latency — from target first appearing to the detection being reported — is measured in milliseconds rather than tens of milliseconds.

Benchmark results

The paper benchmarks against the NCALTECH101 and N-CARS datasets, as well as a proprietary automotive dataset. On all benchmarks, DAGr achieves detection latency at least 5x lower than the best batch-based alternative with equivalent or better accuracy. The latency advantage is largest on sparse event streams (few background events, target well-separated from background), which is the case for a terminal guidance engagement where the seeker is focused on a single target.

Hardware implications

The asynchronous processing in DAGr has a hardware-friendly structure for FPGA implementation. The selective update rule means that only a small fraction of the network nodes are active for any given event. A hardware accelerator that can identify and process only the active nodes avoids the wasted compute of a naive dense forward pass. The irregular memory access pattern is the challenge — graph topology requires random access to node state — but this is the same pattern addressed by the FPGA GNN papers we’ve covered, and spatial hashing approaches apply here.

The combination of DAGr-style asynchronous processing with an FPGA accelerator designed for sparse graph updates is probably the architecture that gives the lowest achievable detection latency for an event-camera seeker. Whether the achievable latency is low enough for a specific guidance law depends on the guidance bandwidth requirement, which in turn depends on target maneuverability and engagement geometry.

The practical limit

DAGr demonstrates that the bottleneck is not algorithmic — the processing architecture exists to achieve sub-millisecond detection latency from an event camera. The remaining question is whether a DAGr-equivalent network can be made small enough to implement on flight-weight hardware and whether it can be trained to perform on the target class and background conditions that matter for terminal C-UAS guidance. Both questions are engineering problems, not research problems. That’s a meaningful distinction.