{"id":"5eabfe0f-a9ab-424d-9273-76dea75745be","arxiv_id":"2506.07924","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"YellowCube is a modular UUV whose modules exchange messages over power lines via ROS, yet the claimed advantages over centralized designs are not quantitatively demonstrated.","lead":"This paper describes YellowCube, a modular underwater vehicle where each module runs its own computer and communicates over power lines using ROS. The system was tested in a tank and in a sea trial, but the reported evidence is mostly qualitative and the key decentralization benefits are not measured.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The paper's own sea-trial report of PLC lag under full thruster power weakens the claim that the P2P inter-module network reliably carries ROS control traffic; without latency/loss data the decentralization benefit is unverified.","rationale":"The paper is an integration report with a concrete vehicle, so the central claim has some evidentiary support: a working YellowCube is shown, tank and sea-trial runs are described, and sensor/software integration is detailed. However, the strongest asserted benefit — that P2P modular communication gives quick integration, upgradability, and fault tolerance — requires the inter-module network to be dependable enough for control and data traffic. The authors' own Section VI contradicts that condition without providing quantitative data: PLC lag appears precisely at full thruster power. Because the low-level control module depends on PLC-carried ROS command messages, any significant lag or loss directly affects maneuverability, which is the core function of a UUV. Additionally, no failure-injection or module hot-swap experiment is reported, so \"failure of one module will not affect other modules\" remains an assertion. This aligns with the reader's CONDITIONAL verdict; no verdict change is needed.","tokens_in":6891,"tokens_out":3402,"duration_ms":46772,"concrete_test":"Run a controlled water-tank experiment with the full YellowCube vehicle: log end-to-end PLC latency and packet loss for /thruster_cmds from the operator terminal to the low-level control module at 0%, 50%, and 100% commanded thrust, with 10-minute runs at each level and at battery states near 100%, 50%, and 20%. Also inject a deliberate failure by powering off the sensing module and measure how quickly the remaining modules continue normal publish/subscribe operation. If p99 latency exceeds 100 ms or any control packet is lost at 100% thrust, the paper's claimed P2P advantage is not reliable under the operating conditions where the vehicle needs control most.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The load-bearing assumption is that the PLC inter-module link reliably carries ROS control and sensing messages during real operation. Section VI reports that in the sea trial \"communication lag occasionally occurred in the PLC network, especially when the thrusters were in full power,\" and the authors attribute it to insufficient voltage. Section IV shows the low-level control module only actuates thrusters after receiving /thruster_cmds over this same PLC network, and Section V shows high-bandwidth video was moved to fiber specifically to avoid PLC limitations. Consequently, the central advantage claimed for the P2P architecture — independent modules that can be updated, integrated, and fault-tolerant — rests on a communication medium that the paper itself records as degraded in the high-thrust regime where control matters most. No latency, packet-loss, or throughput numbers are reported, no failure-injection test is described, and no evidence shows that ROS messages arrive within any deadline. The system may exist and run, but the distinctive decentralized benefit is not demonstrated.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents the design and implementation of YellowCube, a modular and decentralized UUV. The vehicle is split into three core modules (low-level control, sensing, navigation) plus an optional vision payload, each with its own Raspberry Pi running ROS nodes. Inter-module communication is implemented over Power Line Communication (PLC), forming what the authors describe as a Peer-to-Peer (P2P) ROS network, while high-bandwidth video is carried over a separate fiber-optic link. The authors report laboratory tank experiments and a sea trial, stating that all modules worked smoothly and that the UUV maneuvered against strong tide, but noting that communication lag occasionally occurred in the PLC network at full thruster power. The conclusion claims advantages in software updating, module integration, and fault tolerance, and mentions future upgrades from PLC to fiber optics and from ROS1 to ROS2.","tokens_in":7046,"tokens_out":2426,"duration_ms":30762,"significance":"If the modular P2P architecture performs as claimed, it would be a useful demonstration of an inexpensive, easily reconfigurable UUV built from commercial off-the-shelf components, with potential interest to the underwater robotics community. The paper provides concrete hardware details, a clear node graph, and cites relevant ROS documentation, showing that a basic working system exists. However, the verification is entirely qualitative: there are no latency, throughput, packet-loss, positioning-error, or fault-injection metrics, no error bars, and no comparison against a centralized baseline. The manuscript explicitly records degraded PLC communication in the high-thrust regime, which is exactly when reliable control messages are most critical. The claimed benefits of P2P decentralization—particularly fault tolerance—are asserted but not demonstrated. The paper is best viewed as an engineering systems report; its scientific contribution is limited by the absence of quantitative evidence for the core architectural advantage.","major_comments":[{"comment":"The sea-trial report states that 'communication lag occasionally occurred in the PLC network, especially when the thrusters were in full power' and attributes this to insufficient voltage. This is a load-bearing reliability concern because the low-level control module receives /thruster_cmds over this same PLC network (Section IV.A), and high-thrust operation is precisely the regime where control commands must arrive reliably. The paper provides no latency, packet-loss, throughput, or deadline-violation data, and no fault-injection tests. Without quantitative communication metrics, the claim that the P2P network reliably carries ROS control and sensing traffic is unverified. The authors should either supply such measurements or explicitly state the operational limitations of the PLC link and how they affect the claimed decentralization benefits.","section":"Section VI, Section IV.A"},{"comment":"The paper's P2P claim is weakened by the fact that not all modules communicate over the PLC network: the DVL and USBL in the navigation module use Ethernet directly to the operator terminal (Section IV.C), and the vision module uses a separate fiber-optic link with data rates over 1000 Mbps (Section V). Thus, the P2P inter-module network carries only the low-level control and sensing data that fit within PLC bandwidth. The manuscript should clarify what fraction of the vehicle's data traffic is actually carried over the P2P network, and how the direct Ethernet and fiber links affect the claimed 'any module can talk or listen to an arbitrary module' capability.","section":"Sections IV.C and V"},{"comment":"The introduction lists 'The failure of one module will not affect other modules' as a key advantage of the P2P design, but the manuscript reports no fault-injection experiments or failure-mode analysis. This is a central claimed benefit that is never tested. At minimum, a qualitative description of how a module failure would be isolated (e.g., what happens when a Raspberry Pi or a PLC node drops off the network) is needed to substantiate the fault-tolerance claim. As written, the claim is an unsupported assertion.","section":"Introduction, Section I"}],"minor_comments":[{"comment":"The phrase 'Instead a centralised software architecture' is grammatically incomplete; it should read 'Instead of a centralised software architecture'.","section":"Abstract"},{"comment":"The sentence 'Tolstonogov uses the Bluetooth 5.0 Mesh technology ... to develop a new modular underwater vehicle' would be clearer as 'Tolstonogov et al. use Bluetooth 5.0 Mesh technology ... to develop a new modular underwater vehicle.'","section":"Section II, paragraph on Tolstonogov"},{"comment":"The phrase 'the like-mailbox data transferring mechanism' is unclear; 'mailbox-like' would be more precise.","section":"Section II, paragraph comparing ROS and MOOS"},{"comment":"The line 'the other devices connect to Raspberry Pi via the USB serial' should likely read 'via USB serial' or 'via a USB serial interface'.","section":"Section IV.B"},{"comment":"There is a typo: 'the UUV preformed well' should be 'the UUV performed well'.","section":"Section VII"},{"comment":"The statement that 'The communication methods will be upgraded from the PLC to the fibre optics' is slightly confusing because the vision module already uses fiber optics; the authors should clarify whether they mean the inter-module control/sensing network will be migrated to fiber.","section":"Conclusion, future work"}],"recommendation":"major_revision","confidential_remarks":"This manuscript reads as a systems description rather than a research contribution with testable hypotheses. The engineering is real but the verification is anecdotal. The most serious gap is the lack of any quantitative communication reliability data, especially since the paper itself reports PLC degradation at full thrust. I would recommend that the editor ask for a revision that either adds such measurements or substantially narrows the claims. If the venue is primarily for archival system papers, a revised version with explicit limitations and honest scoping might be acceptable."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Plain take: this is a systems report, not a research paper. What is genuinely new is the specific YellowCube vehicle and the way it splits low-level control, sensing, and navigation into separate watertight modules, each with its own Raspberry Pi and ROS node, using PLC for inter-module messages and fiber for video. That integration is useful as a concrete example, and the authors are candid about limitations: sea-trial PLC lag at full thruster power, poor visibility, planned move to fiber and ROS2.\n\nThe paper does some things well. The architecture is clearly described, the figures are helpful, and the authors do not oversell the sea trial—they report exactly what happened. The choice to put video on fiber instead of PLC is sensible engineering. The literature review is adequate, and the driver-integration notes will save time for anyone building a ROS-based UUV.\n\nSoft spots, in proportion: the headline \"P2P communication mechanism\" is not a new result. The paper itself notes that ROS is a peer-to-peer network, so running a ROS node per module is applying standard framework behavior. The claimed advantages—fault tolerance, quick integration, independent updates—are asserted, not demonstrated. There are no latency, throughput, packet-loss, or fault-injection numbers, and no error bars on any navigation plot. The stress-test note is on target: the PLC lag at full thruster power appears in exactly the regime where control commands matter, and the same PLC network carries /thruster_cmds to the low-level controller. So the central decentralization benefit rests on a link the paper itself records as degraded. This is not circular reasoning, just missing evidence. Also, no code, schematics, or raw data are released, which limits reproducibility.\n\nWho this is for: practitioners building a ROS-based modular UUV who want a worked example of module wiring, drivers, and pitfalls. For someone evaluating P2P or fault-tolerance claims, it will not persuade. I would send it to peer review at an applied venue because it is an honest engineering report, but I would ask for quantitative communication data or a softened claim before acceptance.","headline":"An honest modular-UUV systems report whose P2P headline is standard ROS behavior and whose key communication claim lacks quantitative support.","tokens_in":7581,"tokens_out":2960,"would_cite":false,"duration_ms":39637,"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":"YellowCube UUV replaces centralized control with peer-to-peer communication among modules.","keywords":["underwater unmanned vehicle","modular design","peer-to-peer communication","ROS","power line communication","decentralized control","sea trial"],"falsifier":"Run the vehicle with thrusters at full power and log end-to-end packet loss and message latency between modules on the PLC network; if latency spikes exceed the control loop's tolerance or packets drop regularly under load, the claimed smooth P2P operation fails.","tokens_in":6693,"feed_emoji":"🤖","tokens_out":7388,"duration_ms":88894,"temperature":0.7,"pith_summary":"The paper presents YellowCube, a modular underwater vehicle built around a peer-to-peer (P2P) software architecture rather than a central control computer. Each physical module has its own onboard computer running a robotics middleware node, so any module can publish or subscribe to messages from any other module, and an operator can reach modules directly. The authors claim this arrangement makes it quicker to add or swap sensor payloads, easier to update and maintain software module by module, and more tolerant of single-module failures. They report laboratory tank tests and a sea trial to support the claim that the vehicle and its communication network work in practice.","feed_headline":"Modular underwater robot replaces central brain with peer-to-peer links","feed_subtitle":"Every section carries its own computer and talks to every other over power-line links, tested in a tank and at sea.","key_machinery":"The mechanism is the peer-to-peer middleware-based communication network. Each module runs a middleware node on its own small computer, and modules connect in parallel to shared power and communication containers through generic interfaces, with data carried by Power Line Communication (PLC) over the electrical cabling. Because every module has its own node, it can publish to and subscribe from any other node directly instead of routing through a central computer; the operator terminal is one more node on the same network. This is what converts physical modularity into logical decentralization, and it is what the experiments are meant to verify.","core_discovery":"The central claim is that a modular UUV can be built and operated with peer-to-peer communication among its modules, and that this configuration works. YellowCube separates the vehicle into three core modules, namely low-level control, sensing, and navigation, plus interchangeable scientific payloads such as a computer-vision module. Each module is a watertight enclosure with standardized power and communication interfaces and its own small computer running a robot middleware node; the nodes form a network over power-line communication, with a separate fiber-optic channel reserved for high-bandwidth video. The paper reports that in tank experiments all modules worked smoothly and that in a sea trial the thrusters could maneuver the vehicle against a strong tide, with occasional communication lag on the power-line network when the thrusters drew full power. The intended contribution is the demonstration that P2P modularity, including the claimed benefits of quick integration and fault isolation, is practical on a real vehicle.","pith_inferences":["A natural extension the paper leaves unquantified is a direct comparison of integration time and fault recovery against a centralized baseline; without such numbers, the claimed advantages stay qualitative.","Because all control traffic shares the power-line medium, and the sea trial reports lag at full thruster power, the decentralization benefit is only as strong as that shared channel; moving control traffic to a dedicated link would remove one likely bottleneck.","The architecture still has a central power-distribution container, so the design is decentralized in software and data paths but not in electrical supply, meaning a failure there would still affect every module.","The vision module's dedicated optic fiber points toward a hybrid pattern for scaling: future bandwidth-heavy payloads may each need reserved channels rather than relying on pure peer-to-peer messaging alone."],"forward_implications":["Adding a new sensor becomes a matter of attaching a module with its own node and letting it announce itself on the network, with no central control code to rewrite.","A single module can be powered down, replaced, or debugged while the rest of the network keeps communicating.","Software for each function can be updated independently, since no central program owns the vehicle's behavior.","The operator can talk directly with a specific module, such as the navigation module, rather than through a central arbiter.","The separate fiber-optic channel shows that bandwidth-heavy payloads like video can be added without saturating the control network."],"supporting_citations":[{"why":"Supplies the baseline centralized modular AUV (Starfish) that YellowCube's P2P design is contrasted with.","marker":"[1]"},{"why":"Shows an alternative fully wireless modular inter-vehicle communication approach that motivates the P2P direction.","marker":"[3]"},{"why":"Defines the open-source robotics middleware and its publish/subscribe messaging that the module nodes use.","marker":"[9]"},{"why":"Presents the Yellowfin AUV with a ROS/MOOS bridge, the earlier hybrid software architecture this design moves away from.","marker":"[10]"}],"fun_headline_variants":["No central brain: modular underwater robot runs on peer-to-peer","YellowCube: modular UUV with peer-to-peer module links","Underwater robot goes modular, each section thinks for itself","P2P modular UUV tested in tank and sea, no central controller","Decentralized underwater vehicle: modules chat directly, proven at sea"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the power-line communication network can carry control and sensor messages reliably enough while the thrusters are drawing power; the sea trial's occasional communication lag at full thrust shows this has not yet been fully established.","fun_headline_variants_meta":{"raw":{"variants":["No central brain: modular underwater robot runs on peer-to-peer","YellowCube: modular UUV with peer-to-peer module links","Underwater robot goes modular, each section thinks for itself","P2P modular UUV tested in tank and sea, no central controller","Decentralized underwater vehicle: modules chat directly, proven at sea"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000834,"raw_usage":{"total_tokens":3591,"prompt_tokens":848,"completion_tokens":2743,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":464,"completion_tokens_details":{"reasoning_tokens":2664}},"tokens_in":464,"tokens_out":2743,"duration_ms":22087,"temperature":1.0,"reasoning_tokens":2664,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T05:21:22.646436+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the vehicle with thrusters at full power and log end-to-end packet loss and message latency between modules on the PLC network; if latency spikes exceed the control loop's tolerance or packets drop regularly under load, the claimed smooth P2P operation fails.","supporting_citations":[{"cited_title":"Hardware architecture for a modular autonomous underwater vehicle starfish,","cited_arxiv_id":null,"evidence_quote":"Supplies the baseline centralized modular AUV (Starfish) that YellowCube's P2P design is contrasted with."},{"cited_title":"The modular approach for underwater vehicle design,","cited_arxiv_id":null,"evidence_quote":"Shows an alternative fully wireless modular inter-vehicle communication approach that motivates the P2P direction."},{"cited_title":"An implemen- tation of ros on the yellowfin autonomous underwater vehicle (auv),","cited_arxiv_id":null,"evidence_quote":"Presents the Yellowfin AUV with a ROS/MOOS bridge, the earlier hybrid software architecture this design moves away from."}],"review_version":1}