{"id":"eb173d67-592f-4086-a261-447e689cacb3","arxiv_id":"2505.09837","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":2,"one_line_summary":"A 5G-linked hexacopter with edge-AI vision guided an excavator and a ground vehicle around detected workers, but the actual field tests ran the AI on a Raspberry Pi because the microcontroller was too slow.","lead":"This paper describes a custom hexacopter with an onboard camera and edge-AI vision that detects people on a construction site and sends their locations to an autonomous excavator and a ground vehicle over 5G. It also releases a new aerial image dataset for small microprocessor-based vision models.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The paper's own field-test section swaps the MCU for an A72 CPU, so the MCU-based real-time detection claim is never closed-loop validated; 0.85 FPS on STM32 is not shown sufficient for dynamic planning.","rationale":"The reader's weakest assumption identifies exactly the load-bearing gap: the field test ran AI on the A72, not the MCU, and the MCU's best measured rate (0.85 FPS) is not demonstrated to be sufficient for the dynamic path-planning loop. This is not merely a stylistic mismatch; it is an internal contradiction between the abstract/contribution list and Section IV-B. The claim that the system achieves real-time MCU-based detection validated in the field cannot be accepted without a closed-loop MCU experiment. A quantitative reframing to an A72-based edge-AI drone could make the demonstrator claim supportable, but as written the reject verdict stands. No further concern about the dataset or localization method is needed to reach this conclusion, and the concrete switch-back test would settle the matter directly.","tokens_in":6098,"tokens_out":3070,"duration_ms":31976,"concrete_test":"Re-run the same field-test scenario (excavator, UGV, human obstacle, central coordinator) with YoloLC-192 inference running on the STM32H769I instead of the A72, keeping all other components unchanged. Record per-trial collision-avoidance success, detection-to-waypoint-update latency, and number of missed or false obstacle detections at the chosen 8 m altitude. If the MCU loop cannot sustain planning updates fast enough to avoid obstacles, or if no latency and accuracy numbers are reported, the paper's central MCU claim is not supported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central contribution, stated in the abstract and in Section I as \"real-time obstacle and human presence detection using edge-AI on constrained MCU hardware, validated in a realistic construction environment,\" is contradicted by Section IV-B: \"Since the performance of the detection models are not enough to satisfy real-time requirements, as shown in the Table I, we used the A72 to run the AI during field tests.\" Table I lists the best MCU result, YoloLC-192 on the STM32 M7, at 0.85 FPS, while the same model on the A72 runs at 257.9 FPS. Thus the only closed-loop evidence for collision avoidance and path replanning was generated by a Raspberry Pi-class CPU, not by the microcontroller that the paper highlights as the enabler of low-cost edge-AI. The paper does not define its real-time requirement, does not report detection accuracy on the TUBITAK-EdgeDrone test split, and does not measure end-to-end latency from frame capture to updated waypoint. Without an experiment that exercises the MCU inside the closed loop, the claimed MCU-based real-time performance is unsupported; the RANSAC localization results in Table II and the dataset itself are separate contributions that do not rescue that specific claim.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper describes an integrated demonstrator for autonomous multi-robot coordination on a construction site, comprising a custom hexacopter with an onboard STM32 microcontroller, a 5G-connected ground control station, an autonomous excavator, and a custom UGV. The authors propose lightweight, quantized object detection models deployed on the MCU, a monocular RANSAC-based pixel-to-meter scale model for localizing detected objects, and a publicly released dataset (TUBITAK-EdgeDrone). They report frame-rate benchmarks on three processors, RANSAC mapping errors at several altitudes, and a field test in which the drone detects people and the coordinator replans vehicle routes. The central asserted contribution is real-time MCU-based obstacle and human-presence detection validated in a realistic construction environment.","tokens_in":6326,"tokens_out":4687,"duration_ms":50332,"significance":"If the claims were fully supported, the paper would offer a useful data point for low-power edge-AI in construction robotics, a public dataset for small-footprint detection, and a working multi-agent integration on 5G. The public dataset and the full-system field integration are potentially reusable artifacts, and the explicit frame-rate benchmark table across i7, A72, and M7 is a useful negative result for MCU-based real-time detection. However, the paper's headline claim is undercut by its own field-test description, and several quantitative evaluation components are missing. The significance of the work as a research contribution therefore depends on a substantial revision that aligns the claims with the evidence and adds missing metrics.","major_comments":[{"comment":"The central claim that real-time obstacle and human-presence detection was implemented and validated on constrained MCU hardware is directly contradicted by the field-test description. Section IV-B states: 'Since the performance of the detection models are not enough to satisfy real-time requirements, as shown in the Table I, we used the A72 to run the AI during field tests.' Table I shows the fastest MCU result (YoloLC-192 on the STM32 M7) at 0.85 FPS. Consequently, the closed-loop collision-avoidance and path-replanning demonstration was executed on the Raspberry Pi-class A72, not on the MCU. The abstract and the contribution list in Section I therefore overstate what was validated. The paper must either report an experiment that exercises the MCU inside the closed loop, or substantially reframe the central contribution to the A72-based edge-AI system and present the MCU results as a benchmark of current limitations.","section":"Abstract, Section I, Section IV-B, Table I"},{"comment":"No detection accuracy is reported for any model on any dataset. Table I reports only frame rates, and Table II reports RANSAC RMSE values, which are conditioned on correctly detected cone markers. Without precision, recall, or mAP on the TUBITAK-EdgeDrone test split, the reader cannot judge whether the detector reliably finds humans or obstacles at the operating altitudes used in the field test. Detection failures are especially important here because the RANSAC localization error is meaningless for missed detections. The authors should add standard detection metrics and, ideally, report detection accuracy at the chosen operational altitude of approximately 8 m.","section":"Section IV-A, Tables I and II"},{"comment":"The term 'real-time' is never defined, and no end-to-end latency is measured. The paper does not specify a required frame rate or a maximum acceptable delay between image capture, object detection, localization, transmission to the GCS, and updated waypoint dispatch. Without this definition, the statement that the MCU's 0.85 FPS is 'not enough to satisfy real-time requirements' is an unquantified judgment, and the substitution of the A72 in the field test cannot be evaluated against a concrete requirement. The authors should define a quantitative real-time criterion for the dynamic path-planning loop and report the corresponding end-to-end latency for the deployed configuration.","section":"Section IV-B, Section I"},{"comment":"The field-test evaluation is only qualitative. The text describes the scenario and states that the drone relayed detected individuals and the GCS adjusted routes, but it reports no quantitative outcome measures such as the number of successful replans, minimum separation distances, detection-to-replan delays, or the total distance traveled under replanning. The claim that 'field experiments demonstrate practical viability' is therefore supported only by narrative. Quantitative field-test logs, or at least a table of measured event timings and route deviations, should be added.","section":"Section IV-B, Figure 4"}],"minor_comments":[{"comment":"The text refers to a 'RANSAC model' trained on cone-marked data. This should be clarified as a polynomial regression fitted with RANSAC, with the polynomial degree and the number of inlier/outlier samples specified.","section":"Section III-D"},{"comment":"Table II reports RMSE values as point estimates without the number of test samples, standard deviations, or confidence intervals. This makes it hard to judge whether the cubic model is significantly better than the quadratic or quartic alternatives.","section":"Table II"},{"comment":"The hardware names are inconsistent: Section III-C mentions an 'STM32F769i-Discovery' board, while Section IV-A refers to an 'STM32H769-I with M7-Cortex.' The same applies to the general-purpose processor being called both 'i7-8700' and 'CPU i7-8700.' The authors should standardize these names and verify the exact STM32 part number.","section":"Section IV-A and Section III-C"},{"comment":"There are typographical issues such as 'UA V' with a spurious space in the abstract and elsewhere, and the section heading 'C ONCLUSION ACKNOWLEDGEMENT' should be split into separate 'Conclusion' and 'Acknowledgment' sections.","section":"Abstract and Section IV-B"},{"comment":"The text says the route, loading site, and dumping site are shown in Figure 4, but the figure caption only describes the OpenAirLab area. The route overlay and site labels should be made explicit in the figure or a new figure should be added.","section":"Figure 4"}],"recommendation":"major_revision","confidential_remarks":"The disconnect between the abstract's MCU-based real-time claim and the field test's use of the A72 is serious and must be resolved before resubmission. If the authors are unwilling or unable to reframe the central claim away from MCU-based real-time validation, the manuscript should not be accepted. The public dataset and full-system integration are valuable enough to justify a revision opportunity, but the revision must include quantitative detection accuracy and a defined real-time criterion, not just narrative changes. I would also suggest the editor ask the authors to confirm that the GitHub repository link is live and that the dataset is actually curated as described."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper is best read as an engineering demonstrator, not a research claim. The headline contribution in the abstract and introduction—MCU-based real-time obstacle detection, validated in a realistic environment—is not supported by the paper's own data. Table I shows the fastest STM32 result at 0.85 FPS, and Section IV-B explicitly says the field tests ran the AI on the A72. That is a load-bearing mismatch. The stress-test note is right about that, and it is the main thing to know about this paper.\n\nThat said, there is real work here. The integrated system—custom hexacopter, Pixhawk, STM32 board, 5G/MQTT coordination, Voronoi-A* planner, autonomous excavator and UGV—is a nontrivial build, and the paper reports a 250-meter field operation where the drone's detections rerouted ground vehicles. The RANSAC altitude-to-scale mapping is a sensible idea, and Table II gives RMSE values on unseen altitudes, which is more than many integration papers do. The TUBITAK-EdgeDrone dataset, with roughly 25k training and 5k test images plus GNSS metadata, is publicly available and could be a useful resource for MCU-oriented aerial vision. The paper also honestly admits the MCU limitation in IV-B, which earns some trust.\n\nThe soft spots are concentrated around that admission. No detection accuracy (precision/recall) is reported anywhere. There is no end-to-end latency measurement from camera frame to updated waypoint. The field test is qualitative; we do not learn whether the A72-based system actually prevented a collision or just produced a path change. The real-time requirement is never defined, so we cannot tell what threshold the MCU would need to meet. The dataset is introduced but not benchmarked against existing detectors, so its value as an artifact is plausible but unproven.\n\nProportionately, the central claim fails as stated, but the narrower claim—that an edge-AI drone with a Raspberry Pi-class processor can feed obstacle locations into a 5G-connected multi-robot coordination loop—is demonstrated at a qualitative level. The paper is salvageable if the authors reframe it as exactly that, add detection accuracy and latency numbers, and either exercise the MCU in the loop or remove the MCU real-time claim entirely.\n\nWho is this for? Groups working on low-cost construction-site monitoring, edge AI on UAVs, or multi-robot coordination who want a concrete demonstrator and a possible training dataset. It deserves a serious referee: the integration is real, the artifact is public, and the flaws are fixable. I would send it to review with a request for major revision rather than desk-reject, and I would tell the authors to bring the claims in line with what they actually measured.","headline":"A construction-drone demonstrator with a real integration and a public dataset, whose headline MCU real-time claim is contradicted by its own field-test section.","tokens_in":6927,"tokens_out":1633,"would_cite":false,"duration_ms":18264,"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":"A custom hexacopter with on-board edge-AI detection and 5G coordination rerouted construction vehicles in a field demonstration.","keywords":["edge-AI","object detection","UAV surveillance","construction site","multi-robot coordination","quantization","5G","dataset"],"falsifier":"Run the same field scenario with only the microcontroller performing detection while a person walks through the planned vehicle path; if the coordinator cannot reroute the vehicles before the person crosses the safety margin, the MCU-only real-time claim is refuted.","tokens_in":5842,"feed_emoji":"🚁","tokens_out":8259,"duration_ms":81022,"temperature":0.7,"pith_summary":"This paper describes a demonstrator in which a custom-built hexacopter surveys a construction site, detects people and obstacles with an on-board edge-AI detector, and sends their global locations over a 5G link to a central coordinator that reroutes an autonomous excavator and a UGV. The authors want to show that low-power edge hardware, specifically a microcontroller-class device running a quantized object-detection model, can carry the real-time perception load that currently forces drones to rely on heavier computers. They also release a custom dataset of roughly 25,000 training and 5,000 test images designed for small input resolutions, along with a monocular altitude-to-distance calibration method. A field test at a 50-by-100-meter test site demonstrated the full detection-to-rerouting loop over about 250 meters of vehicle travel. The paper also reports that the fastest microcontroller model runs at 0.85 frames per second and states that the field test used the drone's faster general-purpose processor for the AI, so the MCU-only real-time claim is a target rather than a demonstrated result.","feed_headline":"Edge-AI drone spots people and reroutes construction vehicles","feed_subtitle":"The full detection-to-rerouting loop worked; the microcontroller's own speed remains the open question.","key_machinery":"The key machinery is the quantized lightweight detector YoloLC-192, shown in Table I as the fastest model on the microcontroller at 0.85 FPS, paired with a RANSAC-trained polynomial that estimates ground distance from drone altitude and pixel size. This calibration lets a single monocular top-down camera place detected objects in global coordinates using GNSS data, so the central coordinator can treat them as dynamic obstacles. The coordination side rests on MQTT messaging over 5G and a Voronoi-graph A* path planner that recomputes vehicle routes from the drone's obstacle updates. In the field test, the inference step ran on the A72 rather than the microcontroller, so the demonstrated real-time loop depends on that faster processor.","core_discovery":"The paper's central claim is that a quantized, small-footprint object-detection model running on a microcontroller can provide real-time obstacle and human-presence detection from a monocular UAV camera, and that this detection, sent through 5G, is enough for a central coordinator to keep construction vehicles collision-free. The authors validate the architecture with a full demonstrator: a hexacopter with a microcontroller-class board, an onboard computer, a 5G router, and a flight controller; an excavator and a UGV executing waypoint commands; and a Ground Control Station that uses Voronoi-graph A* path planning and MQTT messaging over 5G. They also introduce a custom dataset and a RANSAC-trained polynomial that maps image scale to real-world distance from drone altitude, which converts monocular detections into global obstacle coordinates. The paper's own data qualify the claim: on the microcontroller, the best model runs at 0.85 FPS, so the authors explicitly state that field tests used the A72 processor to run the AI. The contribution is therefore best understood as a demonstrated end-to-end coordination system plus a dataset and calibration method, with microcontroller-level real-time detection as the motivating goal the architecture is built around.","pith_inferences":["A practical near-term system would likely keep the A72-class processor for inference and use the microcontroller for sensor abstraction, because the reported 0.85 FPS on the MCU would make obstacle updates too slow for a moving pedestrian.","The paper's RANSAC scale estimator could be reused outside construction sites, for example in warehouse or disaster-response surveys, but its accuracy at altitudes above 15 meters is untested in this work.","A direct test of the closed loop with MCU-only inference and a person walking through the vehicle path would separate the architecture's value from the hardware's current limits.","The dataset's GNSS metadata, described as useful for visual odometry, could support future work on metric monocular localization for small drones even when altitude is less stable."],"forward_implications":["If the microcontroller inference speed reaches real time, the same 5G coordination loop can detect a person and reroute ground vehicles without any GPU or ground-station processing.","The custom dataset, built for small input resolutions, lets other teams train and compare tiny detectors for construction-site surveillance without re-collecting imagery.","The altitude-to-scale calibration gives monocular drones a practical way to produce global obstacle positions, reducing the need for stereo or LiDAR on the aerial platform.","Because ground vehicles speak MQTT over 5G, adding more vehicles or a second drone to the site requires no change to the UAV's onboard perception pipeline.","The field tests point to roughly 8 meters as the operating altitude that balances low-altitude false cone detections against high-altitude misses, which is directly usable in deployment planning."],"supporting_citations":[{"why":"Public drone-detection dataset used as the comparison baseline whose low object-to-frame ratio motivates the custom small-input dataset.","marker":"[19]"},{"why":"Single-excavator autonomous loading system whose scope the demonstrator extends to multi-vehicle coordination.","marker":"[14]"},{"why":"Earlier drone-imagery and AI construction management system that this work contrasts with MCU-based edge AI.","marker":"[18]"},{"why":"5G-connected vehicle mobility architecture that informs the coordinator's communication design.","marker":"[12]"},{"why":"Survey of UAV-based construction monitoring that frames the drone's real-time operational role.","marker":"[16]"}],"fun_headline_variants":["Edge-AI drone demo coordinates construction vehicles via 5G","Drone + MCU detection: proven on A72, not on chip","Construction drone surveillance: full loop works, MCU too slow","5G drone system ties edge AI to vehicle collision avoidance","Edge-AI UAV demo proves detection-to-rerouting, MCU lags"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the microcontroller's best detection rate of roughly 0.85 frames per second is fast enough for the path-planning and collision-avoidance loop, because the field test ran detection on a faster onboard processor and never exercised the microcontroller in the closed loop.","fun_headline_variants_meta":{"raw":{"variants":["Edge-AI drone demo coordinates construction vehicles via 5G","Drone + MCU detection: proven on A72, not on chip","Construction drone surveillance: full loop works, MCU too slow","5G drone system ties edge AI to vehicle collision avoidance","Edge-AI UAV demo proves detection-to-rerouting, MCU lags"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000634,"raw_usage":{"total_tokens":2944,"prompt_tokens":983,"completion_tokens":1961,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":599,"completion_tokens_details":{"reasoning_tokens":1869}},"tokens_in":599,"tokens_out":1961,"duration_ms":12891,"temperature":1.0,"reasoning_tokens":1869,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T21:22:53.733705+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same field scenario with only the microcontroller performing detection while a person walks through the planned vehicle path; if the coordinator cannot reroute the vehicles before the person crosses the safety margin, the MCU-only real-time claim is refuted.","supporting_citations":[{"cited_title":"2nd Future of Construction Workshop at the Int","cited_arxiv_id":null,"evidence_quote":"Single-excavator autonomous loading system whose scope the demonstrator extends to multi-vehicle coordination."},{"cited_title":"Integrating Drone Imagery and AI for Improved Construction Site Management through Building Information Modeling,","cited_arxiv_id":null,"evidence_quote":"Earlier drone-imagery and AI construction management system that this work contrasts with MCU-based edge AI."},{"cited_title":"Cloud assisted connected and automated mobility system architecture design and experimental verification: The 5G-MOBIX autonomous truck routing use case,","cited_arxiv_id":null,"evidence_quote":"5G-connected vehicle mobility architecture that informs the coordinator's communication design."},{"cited_title":"Towards UA Vs in construction: ad- vancements, challenges, and future directions for monitoring and inspection,","cited_arxiv_id":null,"evidence_quote":"Survey of UAV-based construction monitoring that frames the drone's real-time operational role."}],"review_version":1}