{"id":"ce1eed61-114d-4691-b0bb-9839a7bc04e7","arxiv_id":"2502.00749","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"An event-camera-only perception pipeline detects table tennis balls at about 4,140 updates per second, around 28 times the rate of a frame-based baseline, with comparable pixel accuracy.","lead":"Researchers built a real-time ball-tracking pipeline for a table tennis robot using only event-based cameras, which report brightness changes asynchronously instead of at fixed frame rates. It produces ball position updates about 28 times more often than a frame-based system, with similar accuracy and lower estimated position and spin uncertainty.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The trajectory-prediction comparison is confounded by different camera geometries; the reported lower uncertainties may reflect placement rather than the 28x update rate.","rationale":"The paper's central, well-supported contribution is the measured update rate of (4.14 ± 0.10) × 10^3 updates/s with pixel error 1.34 ± 0.79, close to the frame-based baseline's 1.32 px. That part of the claim stands. The remaining claim, that the higher update rate reduces position, velocity, and spin uncertainties, rests on Section IV-E, where the event cameras and frame cameras have different placements (side-of-robot versus ceiling corners) and the EKF parameters are EM-fitted without an explicit train/test split. The paper itself concedes the setup difference influences the positional error, so the attribution to the perception pipeline is not established. The reader identified the same camera-setup confound as the weakest assumption, and I agree. I would keep the verdict CONDITIONAL: the update-rate result is solid, but the uncertainty-reduction claim needs a controlled comparison before it can be accepted as stated. The missing citation placeholder in Section II-C ('[ ?]') and the stated limitation that the pipeline is not yet integrated into a full robot system do not change this assessment.","tokens_in":13235,"tokens_out":2966,"duration_ms":36184,"concrete_test":"Re-run the trajectory-prediction experiment using only the two event cameras: feed the EKF with (a) the full-rate event-based detections and (b) the same detections temporally decimated to 149 Hz, with EM parameters fitted on a held-out trajectory in both cases. If the full-rate version still yields lower position, velocity, and spin uncertainties than the decimated version, the advantage is caused by update rate rather than camera placement or in-sample fitting; if not, the cross-camera comparison in Figures 7 and 8 is not evidence for the claimed benefit.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The update-rate result in Table I is well supported and is not the weak point. The load-bearing weakness is the trajectory-prediction experiment in Section IV-E, which is used to justify the claim that the higher update rate 'results in lower mean errors and uncertainties.' In that experiment, the event-based 3D positions come from two cameras mounted on the side of the robot, while the frame-based positions come from four cameras on the ceiling corners, a difference the paper itself says 'partially influences' the positional-error comparison (Section IV-E). A second in-sample risk is that the EKF noise parameters are fitted with EM on the data used for evaluation; the text does not state that a separate trajectory was held out. If the EM fit is in-sample, the lower uncertainty curves in Figures 7 and 8 could reflect parameter tuning to the evaluated trajectories, not the event-based update rate. The 2D pixel-error comparison in Table I is less affected by this confound, but the claimed control-relevant benefit depends on the trajectory comparison, so the central claim is only conditionally supported.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes what it claims to be the first real-time perception pipeline for a table tennis robot that uses only event-based cameras. The pipeline combines an EROS event surface, updated event-by-event, with a fast Hough-based circle detector running as-fast-as-possible in a separate thread. The experiments compare this pipeline with a frame-based baseline and two event-based baselines on 2D detection accuracy, runtime, update rate, and EKF-based trajectory prediction. The headline results are an update rate of (4.14 ± 0.10) × 10^3 updates/s with a pixel error of 1.34 ± 0.79 pixels, versus 149 Hz and 1.32 pixels for the frame-based baseline, and lower position, velocity, and spin uncertainties in the trajectory-prediction experiment. The code is publicly released.","tokens_in":13347,"tokens_out":4869,"duration_ms":53695,"significance":"The update-rate and runtime measurements are direct and clean, and they support the paper's central quantitative claim that an event-based pipeline can provide roughly 28 times more ball-position updates per second than a frame-based pipeline while retaining comparable 2D accuracy. This is a useful and creditable contribution, and the release of the pipeline is a practical benefit to the community. However, the more ambitious claim that the higher update rate 'results in lower mean errors and uncertainties' for position, velocity, and spin rests on a trajectory-prediction comparison that is confounded by different camera geometries and by in-sample EM fitting of the EKF parameters. The accuracy comparison also uses ground truth derived from reconstructed event frames with manual cleaning. If the trajectory-prediction claim is either supported by a controlled comparison or appropriately softened, the paper would be a solid and useful systems contribution.","major_comments":[{"comment":"The trajectory-prediction comparison, which grounds the conclusion that the higher update rate leads to lower mean errors and uncertainties, is confounded by different camera geometries. The event cameras are mounted on the side of the robot while the frame-based cameras are placed on the four ceiling corners, as shown in Fig. 2, and the paper itself states in Section IV-E that the difference in positional error 'is partially influenced by the different camera setups.' With different baselines, resolutions, and viewing angles, the lower positional errors and uncertainties in Figs. 7 and 8 cannot be attributed to the update rate. Please either compare both pipelines using the same camera geometry (for example, frame-based detections derived from the same views, or event-based detections from the ceiling-mounted setup), or explicitly limit the paper's claim to update rate and 2D accuracy and remove the trajectory-prediction benefit claim.","section":"Section IV-E"},{"comment":"The EKF transition covariance, observation covariance, and initial-state statistics are fitted via EM on the same data used for the predictions shown in Figs. 7 and 8, and the text does not describe any held-out trajectory. In-sample EM fitting can artificially reduce both the errors and the reported uncertainties, so the comparison does not demonstrate that the event-based update rate itself improves prediction. Please add a train/test split or cross-validation, report the number of trajectories used, and show the variability across trajectories or folds rather than plotting a single trajectory.","section":"Section IV-E"},{"comment":"The ground-truth 2D positions for the accuracy comparison in Table I are obtained by running a circle detector on e2vid-reconstructed frames from the same event streams and then manually removing inaccurate detections. This ground truth is not independent of the event-based methods being evaluated, and the manual cleaning is not quantified. Please validate the pixel-error comparison against an independent source, such as a high-speed frame camera or motion capture, or report the sensitivity of the results to the reconstruction parameters and cleaning decisions.","section":"Section IV-B"}],"minor_comments":[{"comment":"The placeholder citation '[ ?]' in the discussion of speed-invariant time surfaces must be resolved before publication; a missing reference is not acceptable in the final version.","section":"Section II-C"},{"comment":"The entry for the event-based median-filter baseline ('0.000 08(1.1)') mixes the update runtime and the initialization runtime in an unclear way; please use a consistent notation for runtime columns and define what the parenthetical values represent.","section":"Table I"},{"comment":"The trajectory durations used to compute update rates are measured manually in Metavision Studio; since update rate is one of the paper's headline results, please state the uncertainty of this manual measurement or replace it with an automatic timestamp-based duration.","section":"Section IV-D"},{"comment":"The caption states that the camera setup has 'baselines of 3m to 5m'; please clarify whether this refers to the baseline distance between cameras or to the distance from the table/setup, as the schematic alone is ambiguous.","section":"Figure 2"},{"comment":"The 'Require:' line contains 'd = 0.31.0/kEROS', which appears to be a typographical error; should it read 'd = 0.31/kEROS' or 'd = 1.0/kEROS'? Please correct the notation.","section":"Algorithm 1"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is honest in disclosing the camera-setup confound in Section IV-E, but the current framing overstates what the trajectory-prediction experiment can establish. A revision should either add a same-geometry comparison with held-out data or substantially soften the control-relevant conclusions; with that change, the update-rate contribution would be publishable on its own merits."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The core result is a real, measured system: an event-camera-only pipeline that reports ball positions at 4.14k updates/s versus 149 Hz for a frame-based baseline, with pixel error 1.34 vs 1.32. That update-rate difference is an order of magnitude and the measurement is clean. The 2D accuracy comparison is also fair enough: the ground truth comes from e2vid reconstructions, which is not independent, but the frame-based baseline still edges out the event method by 0.02 px, so the \"comparable accuracy\" claim holds.\n\nThe soft spot is the trajectory-prediction experiment. The event cameras are on the side of the robot, the frame cameras on the ceiling corners, and the authors admit this partially explains the positional error difference. On top of that, the EKF noise parameters are EM-fitted on the same trajectories used for evaluation. So the lower velocity and spin uncertainties in Figures 7 and 8 could reflect placement or in-sample tuning, not the 28x update rate. This is the experiment that backs the \"beneficial for control\" contribution, so it needs a controlled setup and out-of-sample validation before the causal claim is supported.\n\nOther issues: the ground truth from e2vid with manual cleaning is a weak gold standard; manual cleaning could introduce bias. And there is an unresolved citation placeholder in Section II-C. These are minor.\n\nWho this is for: people building event-based perception systems, especially for fast object tracking. The code is public, which adds value. It is not a new method—EROS, Hough, and EKF are all known—but it is a legitimate integration and a useful benchmark for the field.\n\nRecommendation: send to peer review. The central claim is sound and the demo is useful, but the trajectory comparison needs revision. I would accept with major revisions.","headline":"Solid event-only perception pipeline with a well-supported 28x update-rate advantage; the trajectory-prediction benefit is confounded by camera placement and in-sample EM fitting.","tokens_in":539,"tokens_out":698,"would_cite":true,"duration_ms":33349,"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":"An event-camera-only perception pipeline can track a table tennis ball at roughly 28 times the update rate of a frame-based system while matching its pixel accuracy.","keywords":["table tennis robot","event camera","event-based perception","EROS event surface","ball detection","trajectory prediction","Extended Kalman Filter"],"falsifier":"Rerun the experiment with the two event cameras placed at the same four ceiling-corner positions used by the frame-based cameras, keeping all other settings identical; if the event-based pipeline's lower trajectory uncertainty disappears, the reported advantage is caused by camera placement rather than by the higher update rate.","tokens_in":12935,"feed_emoji":"🏓","tokens_out":7146,"duration_ms":58831,"temperature":0.7,"pith_summary":"This paper claims that a table tennis robot can perceive the ball using only event-based cameras, with no frame-based cameras at all, and that this is the first such real-time pipeline. The proposed pipeline detects the ball at roughly 28 times the update rate of a conventional frame-based pipeline, about 4,140 updates per second versus 149, while keeping nearly identical pixel accuracy (1.34 vs. 1.32 pixels). Because the ball is reported far more frequently, an extended Kalman filter fed with these positions produces lower uncertainties in the ball's position, velocity, and spin, which matters for a robot that has to swing back within a fraction of a second. The paper argues that event-based cameras remove the frame-rate bottleneck and the motion blur that limits frame-based systems at high ball speeds.","feed_headline":"Event cameras track table tennis balls 28x faster than frame-based","feed_subtitle":"First real-time event-only pipeline matches frame-based accuracy and sharpens spin, velocity, and position estimates.","key_machinery":"The load-bearing object is the EROS (Exponential Reduced Ordinal Surface) event representation, a decaying gray-level surface that is updated incrementally with each incoming event, so the latest state of the scene is always available without recomputing from scratch. The pipeline runs two threads: one updates EROS event-by-event, and the other samples the surface and runs a fast C++ Hough circle detector, first at full resolution for initialization and then within a region of interest centered on the previous detection. EROS makes the representation velocity-independent, so a fast-moving ball appears as a compact circle rather than a blurred trail, and its cheap per-event update lets the pipeline keep up with event streams of roughly 10 million events per second.","core_discovery":"On its own terms, the paper's central claim is that a perception pipeline built entirely on event-based cameras—two synchronized Prophesee EVK4 sensors whose asynchronous event stream updates an EROS surface event-by-event—can replace a frame-based pipeline in a table tennis robot. In their measurements, the proposed pipeline reaches (4.14 ± 0.10) × $10^{3}$ position updates per second with a mean pixel error of 1.34 ± 0.79, compared with 149 Hz and 1.32 pixels for the frame-based baseline from [3]. When the resulting 3D positions are fed into an extended Kalman filter, the event-based pipeline yields lower positional error and lower uncertainty in position, velocity, and spin throughout most of the flight. The authors conclude that the update rate of an event-based pipeline is no longer bounded by the sensor but by the detection algorithm, and that the higher rate is directly useful for robot control in the 0.1–1 s available before the robot must hit the ball.","pith_inferences":["It is a plausible extension that the same event-by-event EROS plus Hough circle design would transfer to other fast ball sports (tennis, cricket, badminton) or to evasive robotics, wherever the limiting factor is how often the sensor can report position.","The paper's comparison is not fully controlled: the event cameras sit on the side while the frame-based cameras hang from four ceiling corners, and the ground-truth 2D positions come from e2vid reconstructions that were manually cleaned; a controlled side-by-side with co-located cameras and an independent high-speed ground truth would isolate the contribution of update rate from the contribution o","Because the EROS update cost scales with the number of events, the pipeline's advantage may shrink in low-contrast or slow-motion scenes where the ball generates few events; an event-based pipeline shines when motion is fast and high-rate updates are needed.","A testable next step is to replace the Hough circle detector with a learned detector operating on EROS surfaces; since the ROI detection already runs in about 91 µs, a learned detector of similar speed could raise accuracy while preserving the update-rate advantage."],"forward_implications":["An event-based-only pipeline can match a frame-based pipeline's pixel accuracy while delivering roughly 28 times more position updates per second, so frame rate is no longer the bottleneck for high-speed ball perception.","Feeding these frequent updates into an extended Kalman filter reduces the uncertainty of the ball's position, velocity, and spin earlier in the flight, giving the robot controller a better basis for planning a return stroke within the 0.1–1 s flight time.","The pipeline's update rate is set by the detection algorithm's runtime (about 91 µs in ROI mode), not by the camera's frame rate, so faster detection algorithms would directly translate into even more frequent updates.","Since EROS is updated event-by-event, the representation always reflects the latest events, avoiding the motion blur that degrades frame-based detection of fast balls.","The full pipeline, including source code, is released, so other groups can integrate event-only perception into their table tennis robots without building the representation and detector from scratch."],"supporting_citations":[{"why":"Supplies the frame-based baseline pipeline and the EKF trajectory prediction model that the proposed event-based pipeline is compared against.","marker":"[3]"},{"why":"Introduces the ordinal-surface event representation and the event-by-event processing philosophy that the EROS surface in this pipeline extends.","marker":"[13]"},{"why":"Demonstrates the EROS update and its ability to keep up with event streams up to roughly 10 Mevents/s, which underlies the proposed pipeline's real-time capability.","marker":"[14]"},{"why":"Provides the particle-filter event-based tracking baseline that the proposed pipeline must beat in update rate and accuracy.","marker":"[26]"},{"why":"Supplies the wand-based calibration method used to calibrate the two event cameras, a prerequisite for triangulating 3D ball positions.","marker":"[33]"},{"why":"Provides e2vid, used to reconstruct frames from the event stream to create the ground-truth 2D positions for accuracy evaluation.","marker":"[37]"}],"fun_headline_variants":["Event-only pipeline gives table tennis robot 28x faster ball tracking","Event-based perception gives table tennis robot 28x update rate","No more blur: event cameras give table tennis robot 28x faster vision","Event-based pipeline boosts table tennis ball tracking to 4kHz"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The comparison assumes that the event cameras and the frame-based cameras are placed so similarly that the event pipeline's lower errors and uncertainties come from its higher update rate, not from its more favorable camera positions; the paper itself notes that the two setups differ, with event cameras on the side and frame cameras on the ceiling.","fun_headline_variants_meta":{"raw":{"variants":["Event-only pipeline gives table tennis robot 28x faster ball tracking","Event-based perception gives table tennis robot 28x update rate","No more blur: event cameras give table tennis robot 28x faster vision","Event-based pipeline boosts table tennis ball tracking to 4kHz"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000714,"raw_usage":{"total_tokens":3216,"prompt_tokens":957,"completion_tokens":2259,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":573,"completion_tokens_details":{"reasoning_tokens":2193}},"tokens_in":573,"tokens_out":2259,"duration_ms":14911,"temperature":1.0,"reasoning_tokens":2193,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-09T17:50:25.500319+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Rerun the experiment with the two event cameras placed at the same four ceiling-corner positions used by the frame-based cameras, keeping all other settings identical; if the event-based pipeline's lower trajectory uncertainty disappears, the reported advantage is caused by camera placement rather than by the higher update rate.","supporting_citations":[{"cited_title":"A table tennis robot system using an industrial KUKA robot arm,","cited_arxiv_id":null,"evidence_quote":"Supplies the frame-based baseline pipeline and the EKF trajectory prediction model that the proposed event-based pipeline is compared against."},{"cited_title":"luvharris: A practical corner detector for event-cameras,","cited_arxiv_id":null,"evidence_quote":"Introduces the ordinal-surface event representation and the event-by-event processing philosophy that the EROS surface in this pipeline extends."},{"cited_title":"eWand: A calibration framework for wide baseline frame-based and event-based camera systems","cited_arxiv_id":"2309.12685","evidence_quote":"Supplies the wand-based calibration method used to calibrate the two event cameras, a prerequisite for triangulating 3D ball positions."},{"cited_title":"High speed and high dynamic range video with an event camera,","cited_arxiv_id":null,"evidence_quote":"Provides e2vid, used to reconstruct frames from the event stream to create the ground-truth 2D positions for accuracy evaluation."}],"review_version":1}