PAANI : On Device Visual Evidence Fusion and Explainable Guidance for River Robot Simulation
cs.AI
Quick verdict
On-device river-robot prototype (YOLO11n+MobileNetV3 on UNO Q) with explainable corridor guidance; admirably honest scoping, but no baselines or closed loop.
Summary
PAANI is an engineering research prototype that runs a two-model perception pipeline on the Linux side of an Arduino UNO Q and converts its outputs into inspectable navigation advisories for a simulated river vessel. A YOLO11n detector fine-tuned on 10,000 WaterScenes images (person, vessel, pier, buoy) and a custom MobileNetV3-Small/FPN segmenter trained on 1,127 MaSTr1325 images run sequentially as FP32 ONNX (14.817 MB total) on CPU. Timestamp-aligned evidence feeds a corridor policy that combines non-water fraction, obstacle severity, legacy urgency and mask uncertainty into left/center/right risk scores, emitting explained advisories over ROS 2 to a separate Gazebo host. Reported results: detector test mAP@0.5 of 0.7388 (checkpoint) and 0.7367 (rectangular ONNX on validation); segmentation mIoU 0.9750 on 198 validation images; five-minute board benchmark medians of 467.8 ms latency and 46.3% CPU at 0.5 Hz. The authors candidly report a black-input misclassified as 97.56% water (advising STRAIGHT), an apparent-motion estimator that cannot collect enough samples at the deployed 0.5 Hz cadence, and a rejected INT8 candidate (mIoU 0.7303). Main limitations: no shared-benchmark baselines, camera imagery independent of simulated pose (no closed visual loop), image-level segmentation split, single training seeds, and no on-water validation.
Review complete
Assessment at a glance
5
risk flags identified
● high 0
● medium 3
● low 2
5 strengths · 5 weaknesses · 5 author questions
AI text signal = Binoculars zero-shot detector score over 20 sampled passages (Fast-DetectGPT co-reported) — absence does not prove human authorship, and a flag does not imply misconduct.
Levels reflect verification complexity — not a quality score. Evolve never rates your paper.
Key claims under review
- A compact two-model FP32 ONNX pipeline (14.817 MB total) executes on the Arduino UNO Q Linux CPU at a configured 0.5 Hz cadence with median pipeline latency of 467.8 ms.
- The corridor policy produces advisories whose contributing evidence and policy reasons are fully inspectable, making model errors, temporal rejections and stale-message conditions distinguishable.
- The detector reaches test mAP@0.5 of 0.7388 (checkpoint) and the segmenter validation mIoU of 0.9750 on their respective recorded splits.
- The evaluation exposes genuine failure modes — black-input acceptance and motion-estimator cadence starvation — demonstrating that model accuracy does not imply navigation safety.
- The contribution is an inspectable, reusable edge-robotics foundation, explicitly not validated on-water autonomy.
Strengths
Exceptional epistemic hygiene
Section 9.2 explicitly disclaims on-water autonomy, calibrated distance and battery results; Section 8.2 reports the black-frame STRAIGHT failure (97.56% water) and Section 8.3 the motion-estimator cadence mismatch as first-class findings rather than burying them.
Reproducibility granularity
Appendix A (Tables 9-11) records seed 42, optimizer schedules, augmentation probabilities, every runtime threshold, thread counts and simulator constants; export parity verified at 7.63e-4/4.12e-4 max abs diff; code released with public datasets (WaterScenes, MaSTr1325).
Clean authority separation
Disciplined evaluation taxonomy
Honest quantization negative result
Weaknesses
No comparative baselines
Flattering aggregate segmentation metric
Closed loop never demonstrated
Policy constants unvalidated
Single-seed training, weak safety-critical class
Full Review Report
$1.99 · one-timeUnlock the complete preliminary analysis Evolve produced for this paper.
Report preview
Scope & Claims
PAANI (arXiv 2609.22353, cs.AI) is a systems paper that self-describes accurately as an engineering research prototype, not a new neural architecture (Section 1). It couples a project-fine-tuned YOLO11n detector (person, vessel, pier, buoy) with a custom MobileNetV3-Small encoder plus 64-channel FPN decoder segmenter (water/obstacle/sky), deployed as FP32 ONNX (opset 17, static [1,3,256,320], 14.817 MB combined: 10.473 + 4.345 MB) on the Linux side of an Arduino UNO Q. Timestamp-aligned evidence feeds a deterministic corridor policy (Eq. 3: Rj = min(1, 0.55Nj + 0.65Oj + 0.20Mj + 0.15Uj)) that emits explained LEFT/RIGHT/STRAIGHT/STOP advisories over ROS 2 to a separate Intel NUC running Gazebo Harmonic. The core claims — inspectable on-device evidence fusion at 0.5 Hz, and a sharp separation between model accuracy and validated on-water collision avoidance — are both supported by the presented evidence; nothing is overclaimed, which is rare and worth crediting.
The remaining sections cover Methodology Assessment, Statistical Evidence, Results & Reproducibility, Limitations & Risks, and Verdict & Recommendations.
- All 5 strengths & 5 weaknesses, analyzed in detail
- 5 risk flags with severity, section & reviewer questions
- Methods & statistical evidence assessment
- 5 questions a peer reviewer would ask
- Full six-dimension evaluation report & recommendations
One-time purchase · this paper only
One-time purchase, this paper only. AI-generated preliminary analysis — not peer review.
Frequently asked questions
What is PAANI?
PAANI is an on-device river-robot perception prototype: a YOLO11n detector and a MobileNetV3-Small segmenter run as FP32 ONNX models on the Linux side of an Arduino UNO Q, and a deterministic corridor policy turns their combined evidence into explainable navigation advisories (left/center/right/stop) that are sent over ROS 2 to a separate computer running a Gazebo vessel simulation.
How accurate are PAANI's models?
The detector reaches a test mAP@0.5 of 0.7388 (four classes: person, vessel, pier, buoy, on WaterScenes) and 0.7367 for the rectangular ONNX export on validation. The segmenter reaches mIoU 0.9750 on 198 MaSTr1325 validation images. An INT8 quantized variant was rejected because mIoU fell to 0.7303 and edge F1 to 0.2318.
Does PAANI actually avoid collisions on real water?
No. The paper explicitly states there is no physical river deployment: camera imagery is independent of the simulated vessel pose, the visual feedback loop is never closed, and no on-water collision avoidance or complete camera-guided run is demonstrated.
What hardware does PAANI run on and how fast is it?
It runs on the Arduino UNO Q (Qualcomm QRB2210 Linux side, CPU-only ONNX Runtime) with FP32 ONNX models totaling 14.817 MB. A five-minute benchmark recorded median 467.8 ms and 95th-percentile 580.3 ms pipeline latency at a configured 0.5 Hz cadence, with about 46.3% median whole-board CPU.
About this review
This is an AI-generated preliminary review by Evolve.Pub, produced from the openly available text of the paper. It is not peer review and does not represent the authors' views. The canonical record of the paper is at the publisher link above.
- Figures 1-8 are available only as captions and axis labels in the extracted text; plotted training/telemetry curves could not be visually verified.
- Per-class AP@0.5 values are not reported in the text, limiting assessment of the deployed 0.40-threshold operating point.
- The metadata abstract is truncated mid-sentence; the embedded full text (complete through references and Appendix A) was used as the review basis.
Go deeper on this paper
Wrote a paper? Stress-test it before reviewers do.
Upload your manuscript for the same structured scrutiny — reasoning, statistics, evidence, figures, and reproducibility.