{"id":"6eecc388-fc69-466d-bf8b-41145b5de22c","arxiv_id":"2411.14576","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"A lightweight optical flow network combined with image chunking achieves 93.6 FPS on a 1-watt Edge TPU and enables a tiny quadrotor to avoid static and dynamic obstacles in real time.","lead":"EdgeFlowNet runs dense optical flow at about 94 frames per second on a Google Coral Edge TPU using roughly a watt of power, and the authors fly a tiny quadrotor through obstacles using only this flow. The result could make vision-based navigation practical on palm-sized robots without GPUs or depth sensors.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 100FPS claim is an EdgeTPU-only inference number; the paper never measures the closed-loop perception-to-control rate, so the headline speed and the navigation speedup argument rest on an untested equivalence.","rationale":"The reader's weakest assumption correctly identifies the gap between the 100 FPS headline and the paper's own Run Time definition, which excludes image acquisition. This is the most load-bearing concern because the paper's novelty and its theoretical speed argument in Section III-F both depend on low perception latency being available in the closed loop. I agree with the reader that the core engineering result - a 2M-parameter optical flow network running at 93.6 FPS on the EdgeTPU and used successfully in real quadrotor navigation - is plausible and not invalidated by the overstatement. However, the exact quantitative claim in the title, abstract, and conclusion should not be taken at face value until end-to-end latency and power are measured. My recommendation is therefore UNCHANGED with respect to the reader's CONDITIONAL verdict: the paper should be accepted only with the requested measurements and numeric corrections, not rejected outright.","tokens_in":17446,"tokens_out":4944,"duration_ms":48803,"concrete_test":"On the PeARCorgi210 testbed, log timestamps for the full perception loop over at least 200 consecutive frames: t0 at camera exposure start (or GPIO sync), t1 when the 640x480 frame is available to the Coral Dev Board, t2 after 4-chunk assembly and EdgeTPU inference, and t3 after the control command is sent via MAVLink. Compute the effective closed-loop frequency as the median and 95th percentile of 1/(t3-t0), and separately measure EdgeTPU-only inference time. Also measure total power draw of the Coral Dev Board and camera during sustained inference with a current probe. If the end-to-end frequency falls materially below 100 Hz, the headline should be revised to state the actual closed-loop rate and the measured power.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central assertion in Section IV ('We achieved an inference of 100FPS using only 1.08W...') is not supported by the paper's own measurements. Table III reports 93.6 FPS for the deployed chunked EdgeFlowNet on the EdgeTPU, not 100 FPS. More importantly, the Run Time metric in Section III-B.1 explicitly excludes image acquisition, and Section III-C describes an Arducam OV9281 at 640x480 feeding the stack. At 93.6 FPS inference, each inference takes about 10.7 ms; at the camera's 120 FPS rate the frame period is about 8.3 ms, so even with perfect overlap the closed-loop rate cannot reach 100 Hz when acquisition is included. Chunk assembly, cropping, control computation, and MAVLink transmission add further latency. Section III-F argues via Eq. 4 that perception latency directly bounds achievable flight speed, so the speed claim is load-bearing for the 'enabling advanced autonomy' narrative. If the real closed-loop rate is substantially below 100 Hz, the speed advantage over prior work and the theoretical max-speed improvement in Fig. 6 are correspondingly overstated, even though the navigation demonstrations themselves may remain valid at modest flight speeds. The 1.08W figure is likewise asserted without any measurement description, leaving the '1W' half of the headline unverified. These issues do not invalidate the architecture or the real-world trials, but they do mean the central quantitative claim is not yet established.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents EdgeFlowNet, a lightweight multi-scale convolutional neural network for dense optical flow estimation that is designed to run on a Google Coral EdgeTPU, together with an image chunking strategy that substantially increases the achieved inference throughput on this low-power accelerator. The authors report that the network runs at about 100 FPS using 1.08 W, is about 20× faster and more than 20% more accurate than the prior NanoFlowNet approach, and demonstrate its use on a small quadrotor for static obstacle avoidance, unknown-gap traversal, and dynamic obstacle dodging in physical experiments. They also provide simulation-based comparisons on navigation metrics and optical flow benchmarks.","tokens_in":17711,"tokens_out":5878,"duration_ms":52598,"significance":"If the headline performance figures are correct, the paper makes a meaningful contribution to tiny-robot perception: it would be the first demonstration of dense optical flow at near-100 FPS on a sub-2 W edge device, with real-world navigation validation. The chunking idea is simple and potentially generalizable, and the release of code and data would benefit the community. The real-world trials are a genuine strength, and the evaluation covers both standard optical flow metrics and navigation outcomes. However, the paper's central quantitative claims are not fully supported by its own measurements: the deployed EdgeTPU configuration runs at 93.6 FPS, not 100 FPS; the accuracy improvement over NanoFlowNet for that configuration is about 18%, not 'over 20%'; and the 1.08 W power figure is not accompanied by any measurement description.","major_comments":[{"comment":"The claim '100FPS using only 1.08W of power' is not supported by the paper's data. Table III reports 93.6 FPS for the deployed EdgeFlowNetChunking on the EdgeTPU, not 100 FPS. The 1.08 W figure appears to be derived from the FPS/Watt column (93.6/86.7 ≈ 1.08 W), but no power measurement procedure is described anywhere in the manuscript. The authors should either present a direct measurement of power consumption or clearly state the source of the figure, and they should correct the FPS claim to the measured 93.6 FPS.","section":"Abstract; Conclusions (Section IV); Table III"},{"comment":"The 'over 20% accuracy improvement' over NanoFlowNet is not consistent with the deployed model's results. On the MPI Sintel 'final' pass, NanoFlowNet has EPE 7.98 and EdgeFlowNetChunking has 6.53, which is an 18.2% improvement, not 'over 20%'. The 20.9% improvement holds only for the non-chunked EdgeFlowNetFull (6.31), which runs at 22.7 FPS on the EdgeTPU, not at the claimed high speed. Additionally, the text in Section III-E states that EdgeFlowNet is 'about 22% more accurate' than Ajna, but Table III shows EPE 7.32 for Ajna versus 6.31 for EdgeFlowNetFull, a 13.8% improvement.","section":"Abstract; Introduction; Section III-E; Table III"},{"comment":"The paper's speed and maximum-flight-speed arguments rely on perception latency, but the presented 'Run Time' metric explicitly excludes image acquisition, and the robot experiments do not report the end-to-end closed-loop perception-to-control rate. Section III-F uses τp in Equation (4) to bound the achievable flight speed, so the inference-only latency cannot be simply equated to the closed-loop control rate. The authors should measure and report the actual pipeline latency (including camera capture, chunk assembly, and control-command transmission) or clearly restrict their speed claims to the inference component.","section":"Section III-B.1; Section III-C; Section III-F; Figure 6"},{"comment":"There is an internal inconsistency between the reported runtime of the EdgeTPU deployment and Table III. Tables I and II list 'GPU Time' of 9.8 ms for EdgeFlowNet(Ours, EdgeTPU Chunking), which corresponds to about 102 FPS, whereas Table III reports 93.6 FPS (about 10.68 ms) for the same configuration. The authors should reconcile these numbers or clarify what exactly is being measured.","section":"Tables I and II; Section III-C"},{"comment":"The statement that EdgeFlowNet is 'about 20× faster' than previous state-of-the-art approaches is an overstatement when compared directly with the paper's own numbers: the 93.6 FPS on EdgeTPU versus NanoFlowNet's 5.6 FPS on the GAP8 gives a factor of about 16.7×, and comparisons against GPU-based methods are not 20×. The speedup claim should be qualified by the specific baseline and hardware, or the reported factors should be corrected.","section":"Abstract; Section IV"}],"minor_comments":[{"comment":"The column header 'GPU Time (ms)' is misleading for rows that run on the EdgeTPU; it should be renamed to 'Inference Time (ms)' with a clear footnote about the platform.","section":"Section III-C; Tables I-II"},{"comment":"The phrase 'previous state-of-the-art approaches' is used in the abstract without naming the baseline; the comparisons in Table III are against multiple methods on different hardware, so the speedup factor should be stated relative to a specific baseline.","section":"Section I; Section III-E"},{"comment":"Several references in the appendix remain as '[?]' placeholders (for example, in the discussion of related architectures and in Table SX). These should be resolved before publication.","section":"Appendix, Sections S-I and S-VI"},{"comment":"The definition of 'Run Time' says it is the time 'for the perception stack to give a control command', but the procedure for measuring this time is not described; a short experimental description would improve reproducibility.","section":"Section III-B.1"}],"recommendation":"major_revision","confidential_remarks":"The paper's core idea and real-world demonstrations are valuable, but the headline claims are not fully backed by the reported measurements. The discrepancies between the stated 100 FPS / 1.08 W / 20% accuracy improvement and the paper's own tables are significant enough that a revision with corrected numbers and an explicit power-measurement description is necessary. The missing closed-loop latency evidence is also important given the role that perception latency plays in the paper's speed analysis. The manuscript is otherwise technically sound and likely publishable after these issues are addressed."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear [Colleague],\n\nThe paper's real contribution is the chunking analysis on EdgeTPU and the EdgeFlowNet architecture that runs dense optical flow at about 93.6 FPS on a Coral EdgeTPU at 480x352, plus real-world quadrotor trials for obstacle avoidance, gap traversal, and dynamic dodging. That's a solid engineering result, and the measured numbers are actually in the paper: Table III shows 93.6 FPS on EdgeTPU with chunking, and EPE of 6.53 on Sintel final. Compared to NanoFlowNet on GAP8 (5.6 FPS, 7.98 EPE), that's a ~17x speedup and ~18% accuracy improvement, which is genuinely useful for tiny-robot autonomy.\n\nThe problem is that the headline claims in the abstract and conclusion don't match their own tables. They say \"100FPS\" and \"over 20% accuracy improvement\" and \"1.08W\", but the measured EdgeTPU rate is 93.6 FPS, the chunked model's EPE improvement over NanoFlowNet is 18.2%, and there's no description of how the 1.08W was measured. The stress-test note is right that the run time metric excludes image acquisition, so the closed-loop rate on the robot is likely lower than the inference rate. The camera is 120 FPS, so even with perfect pipelining, the 93.6 FPS inference rate caps throughput below 100 Hz; and the control pipeline adds latency. None of this invalidates the architecture or the flight trials, but it means the central quantitative claim is overstated.\n\nAlso, the EPE evaluation uses the Sintel train subset, which is fine for zero-shot generalization but should be labeled more prominently. The appendix has unresolved reference placeholders ([?]) and the network ablation table is informative but the comparisons to VanillaNet etc. are not fully fleshed out. These are minor.\n\nThe chunking insight—that batching small chunks on EdgeTPU gives speedups while preserving resolution better than resizing—is empirical but useful and likely generalizable to other dense prediction tasks on EdgeTPU. The paper is worth engaging with, and I'd cite the chunking data if I were building on EdgeTPU perception. But I'd want the authors to correct the abstract and conclusion to match their own Table III, and to describe the power measurement. It's a solid RA-L paper with an overreach in the headline; a careful reader can recover the real numbers from the tables.\n\nRecommendation: send to peer review, but with a request to fix the claim/reporting mismatch before acceptance.","headline":"Solid EdgeTPU optical-flow engineering with real flight demos, but the 100FPS@1W headline overstates the paper's own measured 93.6 FPS and unverified 1.08W.","tokens_in":18344,"tokens_out":5453,"would_cite":true,"duration_ms":46031,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"EdgeFlowNet claims dense optical flow at 100 FPS on a 1.08 W edge chip, enabling onboard reactive navigation for palm-sized quadrotors.","keywords":["optical flow","edge computing","Edge TPU","tiny robots","quadrotor navigation","image chunking","multi-scale network","UINT8 quantization"],"falsifier":"Log timestamps from camera exposure to control output on the same quadrotor; if the end-to-end perception period is substantially above 10 ms, for example if the full loop runs at 30 Hz rather than 100 Hz, then the headline rate is an inference-only result and the closed-loop advantage is not realized.","tokens_in":17188,"feed_emoji":"🚁","tokens_out":8707,"duration_ms":79888,"temperature":0.7,"pith_summary":"This paper aims to make dense optical flow cheap enough to run onboard a palm-sized quadrotor. The authors introduce EdgeFlowNet, a lightweight multi-scale network compiled for the Google Coral Edge TPU, and report roughly 100 FPS inference at 1.08 W, about 20x faster than the closest prior edge optical-flow work with over 20% lower endpoint error. The central trick is image chunking: instead of feeding one full-resolution frame pair, the same pixels are rearranged into four half-resolution chunks stacked in the batch dimension, which the EdgeTPU processes far faster while preserving fine details that resizing would lose. They demonstrate the resulting flow in real flights for static obstacle avoidance, gap traversal, and dodging thrown obstacles, with success rates of 83.3%, 85.0%, and 93.75%. If the speed holds in the full control loop, dense optical flow becomes a practical onboard perception modality for tiny robots without a GPU or depth sensor.","feed_headline":"Palm-sized drones get 100FPS optical flow on 1 watt","feed_subtitle":"A chunked multi-scale network lets tiny quadrotors dodge obstacles and fly through gaps using only onboard vision.","key_machinery":"The load-bearing mechanism is image chunking along the batch dimension: the input pair of shape $B\\times H\\times W\\times 2C$ is reshaped to $MNB\\times \\frac{H}{M}\\times \\frac{W}{N}\\times 2C$, so the same pixels are processed as many smaller images in one batch. On the EdgeTPU this raises throughput from 22.8 to 93.4 FPS with the same total pixel count, because larger batches parallelize better across the chip's processing units and use cache more effectively; resizing the image to the same smaller resolution instead loses fine detail and increases endpoint error. The companion architecture, EdgeFlowNet, is a lightweight multi-scale ResNet-style encoder-decoder that predicts incremental flow at each pyramid scale, which keeps values inside the UINT8 quantization range and recovers most of the accuracy that naive chunking sacrifices. The training loss combines a multi-scale $L_1$ term with self-supervised uncertainty, and chunk overlap is available as a speed-accuracy dial.","core_discovery":"EdgeFlowNet's central claim is that dense optical flow can be estimated at about 100 FPS within a 1.08 W power budget on a Google Coral Edge TPU, and that this speed makes flow-based autonomy feasible on sub-2 W palm-sized robots. The paper reports roughly a 20x speedup over NanoFlowNet, the closest prior edge optical-flow work, together with over 20% accuracy improvement. The design is chip-aware: a ResNet-style multi-scale encoder-decoder predicts incremental optical flow at each scale so that unsigned 8-bit quantized values stay in range, trained with a self-supervised uncertainty loss, plus a chunking scheme that re-arranges the input as $4 \\times 240 \\times 176 \\times 6$ to exploit the EdgeTPU's batch-level parallelism. On MPI Sintel, EdgeFlowNet reaches 6.31 px endpoint error without chunking and 5.66 px with chunking, at 93.6 FPS on the EdgeTPU; in simulation it beats relative-depth and many flow baselines on gap and dynamic-object detection while trading some accuracy against RAFT. The paper positions the result as enabling autonomy, not as a new navigation algorithm, and argues that the speed gain can offset the accuracy loss: in the authors' latency model, the faster, less accurate network supports a higher theoretical maximum flight speed than a slower, more accurate one.","pith_inferences":["If image acquisition and control overhead can be kept near the 9.8 ms inference time, the same chunking recipe may push other EdgeTPU vision tasks, such as depth or segmentation, toward real-time onboard rates; the paper only demonstrates optical flow, so this is an extrapolation.","The measured speedups on GPUs shrank as VRAM size grew, so the chunking rule is not universal; a similar FPS-versus-chunk-count sweep on other edge accelerators would show whether the effect is an EdgeTPU-specific cache phenomenon or a general batch-parallelism one.","The paper's own overlap experiments imply a tunable trade-off: objects near chunk boundaries lose context, so a controller that adjusts overlap based on detected object size or position could keep accuracy high at lower average speed cost.","A direct closed-loop comparison, using the same robot and planner with EdgeFlowNet at 100 FPS versus a slower higher-accuracy flow network, would test whether the latency model's predicted speed advantage materializes in practice."],"forward_implications":["Dense optical flow becomes an onboard perception modality for robots with under 2 W compute budgets, replacing or augmenting depth sensors for reactive navigation.","The chunking speedup is architecture-agnostic on the EdgeTPU, so other vision networks compiled for this chip can adopt the same reshaping rule to gain throughput.","Because the latency model shows faster perception can beat higher accuracy for a given sensing range, the optimization target shifts from endpoint error alone to end-to-end latency.","The synthetic-to-real training recipe transfers to real flights, suggesting the approach can be retrained for other tiny-robot platforms.","The same flow output can drive multiple behaviors, such as static obstacle avoidance, gap finding, and dynamic obstacle dodging, simplifying the onboard perception stack."],"supporting_citations":[{"why":"NanoFlowNet is the closest prior edge optical-flow work and supplies the speed and accuracy baseline that EdgeFlowNet claims to beat by about 20x and 20%.","marker":"[28]"},{"why":"RAFT is the high-accuracy optical-flow baseline whose cost-volume architecture is too compute-intensive for the EdgeTPU, motivating EdgeFlowNet's design.","marker":"[22]"},{"why":"Ajna provides the base architecture, self-supervised uncertainty formulation, and evaluation protocol that EdgeFlowNet extends and improves upon.","marker":"[32]"},{"why":"PRGFlow supplies the hardware-aware ResNet-based architecture lineage and the methodology of matching network design to a specific accelerator.","marker":"[10]"},{"why":"GapFlyt provides the gap-detection control strategy and part of the static-obstacle avoidance policy adapted for EdgeFlowNet's flight experiments.","marker":"[17]"},{"why":"EvDodgeNet supplies the dynamic-obstacle dodging strategy and the Blender-based simulation setup used for quantitative evaluation.","marker":"[14]"},{"why":"This work provides the free-space control policy used for static obstacle avoidance with low-magnitude optical flow.","marker":"[35]"},{"why":"FlyingChairs2 is the dataset used for the first 400 epochs of training.","marker":"[33]"},{"why":"FlyingThings3D is the dataset used for 50 epochs of fine-tuning to improve real-world generalization.","marker":"[34]"},{"why":"This latency analysis is the basis for the paper's theoretical model relating perception latency, detection rate, and maximum safe flight speed.","marker":"[41]"}],"fun_headline_variants":["Tiny drones get 100FPS dense flow on just 1 watt","EdgeFlowNet: 20x faster flow, 20% better, 1W","Palm-sized quadrotors dodge obstacles at 100FPS","1W edge flow hits 100FPS for tiny robot navigation","Sub-2W drones achieve 100FPS optical flow"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The 100 FPS number is the chip's inference speed measured without image acquisition, so the whole approach assumes that this speed survives the full onboard loop of grabbing frames, assembling chunks, and sending control commands; if those steps dominate, the real flight rate is lower.","fun_headline_variants_meta":{"raw":{"variants":["Tiny drones get 100FPS dense flow on just 1 watt","EdgeFlowNet: 20x faster flow, 20% better, 1W","Palm-sized quadrotors dodge obstacles at 100FPS","1W edge flow hits 100FPS for tiny robot navigation","Sub-2W drones achieve 100FPS optical flow"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000602,"raw_usage":{"total_tokens":2824,"prompt_tokens":972,"completion_tokens":1852,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":588,"completion_tokens_details":{"reasoning_tokens":1754}},"tokens_in":588,"tokens_out":1852,"duration_ms":14293,"temperature":1.0,"reasoning_tokens":1754,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T15:08:54.673709+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Log timestamps from camera exposure to control output on the same quadrotor; if the end-to-end perception period is substantially above 10 ms, for example if the full loop runs at 30 Hz rather than 100 Hz, then the headline rate is an inference-only result and the closed-loop advantage is not realized.","supporting_citations":[{"cited_title":"Nanoflownet: Real-time dense optical flow on a nano quadcopter","cited_arxiv_id":null,"evidence_quote":"NanoFlowNet is the closest prior edge optical-flow work and supplies the speed and accuracy baseline that EdgeFlowNet claims to beat by about 20x and 20%."},{"cited_title":"Raft: Recurrent all-pairs field transforms for optical flow (extended abstract)","cited_arxiv_id":null,"evidence_quote":"RAFT is the high-accuracy optical-flow baseline whose cost-volume architecture is too compute-intensive for the EdgeTPU, motivating EdgeFlowNet's design."},{"cited_title":"Ajna: Generalized deep uncertainty for minimal perception on parsimonious robots","cited_arxiv_id":null,"evidence_quote":"Ajna provides the base architecture, self-supervised uncertainty formulation, and evaluation protocol that EdgeFlowNet extends and improves upon."},{"cited_title":"Prgflow: Unified swap-aware deep global optical flow for aerial robot navigation","cited_arxiv_id":null,"evidence_quote":"PRGFlow supplies the hardware-aware ResNet-based architecture lineage and the methodology of matching network design to a specific accelerator."},{"cited_title":"Gapflyt: Active vision based minimalist structure-less gap detection for quadrotor flight","cited_arxiv_id":null,"evidence_quote":"GapFlyt provides the gap-detection control strategy and part of the static-obstacle avoidance policy adapted for EdgeFlowNet's flight experiments."},{"cited_title":"Evdodgenet: Deep dynamic obstacle dodging with event cameras","cited_arxiv_id":null,"evidence_quote":"EvDodgeNet supplies the dynamic-obstacle dodging strategy and the Blender-based simulation setup used for quantitative evaluation."},{"cited_title":"Vision based forward sensitive reactive control for a quadrotor vtol","cited_arxiv_id":null,"evidence_quote":"This work provides the free-space control policy used for static obstacle avoidance with low-magnitude optical flow."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"FlyingChairs2 is the dataset used for the first 400 epochs of training."},{"cited_title":"How fast is too fast? the role of perception latency in high-speed sense and avoid","cited_arxiv_id":null,"evidence_quote":"This latency analysis is the basis for the paper's theoretical model relating perception latency, detection rate, and maximum safe flight speed."}],"review_version":1}