Design and Implementation of a Peer-to-Peer Communication, Modular and Decentral YellowCube UUV

Baozhu Jia; Weichao Shi; Zhizun Xu

REVIEW 3 major objections 6 minor 22 references

Design and Implementation of a Peer-to-Peer Communication, Modular and Decentral YellowCube UUV

T0 review · 3 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read YellowCube UUV replaces centralized control with peer-to-peer communication among modules.

desk verdict An honest modular-UUV systems report whose P2P headline is standard ROS behavior and whose key communication claim lacks quantitative support. read the letter →

arxiv 2506.07924 v1 pith:AET4PZ2B submitted 2025-06-09 cs.RO

Zhizun Xu , Baozhu Jia , Weichao Shi This is my paper

classification cs.RO

keywords underwaterunmannedvehiclemodulardesignpeer-to-peercommunicationROSpowerlinedecentralizedcontrolseatrial

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

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.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the 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.

The 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.

Soft 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.

Who 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.

Referee Report

3 major / 6 minor

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.

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 (3)

[Section VI, Section IV.A] 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.
[Sections IV.C and V] 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.
[Introduction, Section I] 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.

minor comments (6)

[Abstract] The phrase 'Instead a centralised software architecture' is grammatically incomplete; it should read 'Instead of a centralised software architecture'.
[Section II, paragraph on Tolstonogov] 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 II, paragraph comparing ROS and MOOS] The phrase 'the like-mailbox data transferring mechanism' is unclear; 'mailbox-like' would be more precise.
[Section IV.B] 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 VII] There is a typo: 'the UUV preformed well' should be 'the UUV performed well'.
[Conclusion, future work] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper is a system design/implementation report with no fitted parameters, equations, or self-cited theorems, so no claim reduces by construction to its inputs.

full rationale

The paper does not present a derivation, model, or prediction. Its central claim is that a P2P ROS-based communication network is implemented across modular watertight sections of the YellowCube UUV, and that laboratory and sea trials demonstrate the vehicle operates. The P2P property is not a fitted output; it is a property of the ROS architecture described in Section III ("each module owns a micro-computer (Raspberry Pi) running a ROS node for publishing or subscribing messages") and corroborated by external citations [9], [10]. The claimed advantages (independent update, rapid integration, fault tolerance, Section I) are asserted qualitatively, not derived from a fitted parameter, so they cannot be circular. The sea-trial statement in Section VI that "communication lag occasionally occurred in the PLC network, especially when the thrusters were in full power" is a limitation on the evidence supporting the P2P advantage, and the conclusion that the UUV "preformed well" is optimistic, but this is an evidentiary weakness, not a circular reduction. No self-citation is load-bearing; the reference list contains no prior work by the present authors being used to justify the architecture. Because there is no equation, fitted input, or imported uniqueness theorem, there is no step that reduces to its own inputs by construction.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The central claim rests on standard robotics frameworks and commercial hardware rather than new theoretical constructs. The two load-bearing engineering assumptions are that ROS's native P2P behavior suffices for a decentralized architecture and that PLC provides reliable inter-module communication under load, the latter explicitly challenged by the authors' own observation.

assumptions (3)

domain assumption ROS1 provides a peer-to-peer publish-subscribe network.
The paper relies on this to claim its P2P decentralized architecture, citing ROS references in Section II.
domain assumption Power line communication can carry ROS messages reliably between modules.
The inter-module network uses PLC; the paper's sea trial reports lag at full thruster power (Section VI), weakening this assumption.
domain assumption Syntactic foam buoyancy gives the vehicle a 500-meter depth rating.
Stated in Section III as a design specification; no pressure test is reported.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Design and Implementation of a Peer-to-Peer Communication, Modular and Decentral YellowCube UUV." pith.science (2026). https://pith.science/paper/AET4PZ2B

@misc{pith2026250607924,
  author       = {Pith},
  title        = {Pith review of: Design and Implementation of a Peer-to-Peer Communication, Modular and Decentral YellowCube UUV},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AET4PZ2B}},
  note         = {Machine review of arXiv:2506.07924}
}

read the original abstract

The underwater Unmanned Vehicles(UUVs) are pivot tools for offshore engineering and oceanographic research. Most existing UUVs do not facilitate easy integration of new or upgraded sensors. A solution to this problem is to have a modular UUV system with changeable payload sections capable of carrying different sensor to suite different missions. The design and implementation of a modular and decentral UUV named YellowCube is presented in the paper. Instead a centralised software architecture which is adopted by the other modular underwater vehicles designs, a Peer-To-Peer(P2P) communication mechanism is implemented among the UUV's modules. The experiments in the laboratory and sea trials have been executed to verify the performances of the UUV.

Figures

Figures reproduced from arXiv: 2506.07924 by the authors.

**Figure 4.** Software Architecture The ROS nodes graph is presented in Fig.4. The operator terminal is the ROS environment running on the control platform for UUV operators, which often locates on the shore or a support ship. The operators terminal runs ROS RViz listening from multiple modules, and joystick nodes(joy node and joystick ctrl), sending the control commands to the low-level control module via a /thruster cmds messa… view at source ↗

**Figure 3.** The Locations of Modules on The Vehicle The software system is developed on the top of the ROS1 framework. Although the latest ROS2 has outperformed in real time applications, the better compatibility of the ROS1 makes it a ideal tool in the project which is not sensitive in the timing of reactions. In order to set up a P2P network, each module owns a micro-computer(Raspberry Pi) running a ROS node for publishing or… view at source ↗

Figures from the paper (6 more)

**Figure 5.** Figure 5: The States of YellowCube UUV in RViz [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]

**Figure 7.** Figure 7: Layout of Sensing Module Due to the big overhead of ROS on the video streaming, the GStreamer [19] is used to transfer 1080p live streaming from IMX322 Webcam to operator terminal. As for the IMU(Xsens MTi-300), the official C++ SDK and ROS driver are provided. We have…

**Figure 6.** Figure 6: Control System for One Thruster In the low-level control module, the ROS node is written in Python. The Python library of the Raspberry Pi I2C interface and the Python library for Servo driver are employed to wrap of the ROS Python scripts. The control mechanism is unc…

**Figure 9.** Figure 9: Computer Vision Module As mentioned above, the visual information transferring would eat up the huge communication bandwidth. The vision module has its own fibre optic cable which is separated from the PLC network. A pair of single-core, single model fibre optic tran…

**Figure 8.** Figure 8: DVL Configuration The official ROS Python driver of DVL A50 is supplied. Based on it, we modified the Python script to record all raw data and positions estimated by the built-in dead reckon algorithm. The SeaTrac USBL provides a professional software tool to record al…

**Figure 11.** Figure 11: The Vehicle in Experiments. The right image shows the [PITH_FULL_IMAGE:figures/full_fig_p007_11.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

22 extracted references · 21 canonical work pages

[1]

Hardware architecture for a modular autonomous underwater vehicle starfish,

M. Sangekar, M. Chitre, and T. B. Koay, “Hardware architecture for a modular autonomous underwater vehicle starfish,” in OCEANS 2008 . IEEE, 2008, pp. 1–8

work page 2008
[2]

A modular design approach for underwater rov: Trident,

T. Mangayarkarasi, R. Harshavardhan, R. Sujith, and K. Sricha- ran, “A modular design approach for underwater rov: Trident,” in 2024 International Conference on Power , Energy, Control and Transmission Systems (ICPECTS) . IEEE, 2024, pp. 1–4

work page 2024
[3]

The modular approach for underwater vehicle design,

A. Y . Tolstonogov, I. A. Chemezov, A. Y . Kolomeitsev, and V . A. Storozhenko, “The modular approach for underwater vehicle design,” in Global Oceans 2020: Singapore–US Gulf Coast. IEEE, 2020, pp. 1–7

work page 2020
[4]

Minion: Modular and independent navigational intelligent orientable nozzle-thruster,

A. Odetti, M. Caccia, and G. Bruzzone, “Minion: Modular and independent navigational intelligent orientable nozzle-thruster,” in Conference Proceedings of iSCSS , vol. 2024, 2024

work page 2024
[5]

Modular controls and instrumentation software for icefin rov,

C. Ramey, M. Meister, A. Spears, J. Lutz, D. Dichek, B. Hur- witz, J. Lawrence, J. Lawrence, M. Philleo, and B. E. Schmidt, “Modular controls and instrumentation software for icefin rov,” in OCEANS 2018 MTS/IEEE Charleston . IEEE, 2018, pp. 1–4

work page 2018
[6]

Hybrid-rov- development of a new underwater vehicle for high-risk areas,

G. Meinecke, V . Ratmeyer, and J. Renken, “Hybrid-rov- development of a new underwater vehicle for high-risk areas,” in OCEANS’11 MTS/IEEE KONA . IEEE, 2011, pp. 1–6

work page 2011
[7]

Moos-mission orientated operating suite,

P. Newman, “Moos-mission orientated operating suite,” Depart- ment of Engineering Science, University of Oxford, Tech. Rep., 2008

work page 2008
[8]

Robot operating system 2: Design, architecture, and uses in the wild,

S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, “Robot operating system 2: Design, architecture, and uses in the wild,” Science robotics , vol. 7, no. 66, p. eabm6074, 2022

work page 2022

Show all 22 references

[9]

Ros: an open-source robot operating system,

M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler, A. Y . Ng et al. , “Ros: an open-source robot operating system,” in ICRA workshop on open source software , vol. 3, no. 3.2. Kobe, 2009, p. 5

2009
[10]

An implemen- tation of ros on the yellowfin autonomous underwater vehicle (auv),

K. DeMarco, M. E. West, and T. R. Collins, “An implemen- tation of ros on the yellowfin autonomous underwater vehicle (auv),” in OCEANS’11 MTS/IEEE KONA . IEEE, 2011, pp. 1–7

2011
[11]

Decentralized linear convoying for underactuated surface craft with partial state coupling,

R. Turrisi and M. Benjamin, “Decentralized linear convoying for underactuated surface craft with partial state coupling,” in 2024 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS) . IEEE, 2024, pp. 1161–1168

2024
[12]

Adaptive and collaborative bathymetric channel-finding approach for multiple autonomous marine vehicles,

N. Gershfeld, T. M. Paine, and M. R. Benjamin, “Adaptive and collaborative bathymetric channel-finding approach for multiple autonomous marine vehicles,” IEEE Robotics and Automation Letters, vol. 8, no. 7, pp. 4028–4035, 2023

2023
[13]

A model for multi-agent autonomy that uses opinion dynamics and multi-objective be- havior optimization,

T. M. Paine and M. R. Benjamin, “A model for multi-agent autonomy that uses opinion dynamics and multi-objective be- havior optimization,” in 2024 IEEE International Conference on Robotics and Automation (ICRA) . IEEE, 2024, pp. 8305– 8311

2024
[14]

Backseat control of sandshark auv using ros on raspberrypi,

J. E. Naglak, B. R. Page, and N. Mahmoudian, “Backseat control of sandshark auv using ros on raspberrypi,” in OCEANS 2018 MTS/IEEE Charleston . IEEE, 2018, pp. 1–5

2018
[15]

Subjugator 2024: Design and implementation of a modular, high-performance auv

L. Bjellos, L. Bonilla, C. Brown, A. Fernandez, A. Hamdan, D. Parra, and E. Schwartz, “Subjugator 2024: Design and implementation of a modular, high-performance auv.”

2024
[16]

Implementation of a low-cost autonomous underwater vehicle using open source ros components with consumer class sonar technologies,

T. Aaltonen, M. Saarivirta, T. Kerminen, and J. Gr ¨onman, “Implementation of a low-cost autonomous underwater vehicle using open source ros components with consumer class sonar technologies,” in 2020 43rd International Convention on Infor- mation, Communication and Electronic...

2020
[17]

R. D. Christ and R. L. Wernli Sr, The ROV manual: a user guide for remotely operated vehicles . Butterworth-Heinemann, 2013

2013
[18]

Vijayakumar

A. Vijayakumar. (2023) Rviz vs gazebo in ros: The importance of 3d visualization for robotics development. [Online]. Avail- able: https://ros-learnings .hashnode.dev/rviz-vs-gazebo-in-ros- the-importance-of-3d-visualization-for-robotics-development

2023
[19]

Gstreamer,

J. Newmarch, “Gstreamer,” in Linux Sound Programming . Springer, 2017, pp. 211–221

2017
[20]

C. Nantes. (2020) Ping360 sonar. [Online]. Available: https://github.com/CentraleNantesRobotics/ping360 sonar

2020
[21]

B. Subsea. (2025) Seatrac standard features. [Online]. Avail- able: https://www.blueprintsubsea.com/seatrac/seatrac-standard

2025
[22]

Cuda: Scalable parallel programming for high- performance scientific computing,

D. Luebke, “Cuda: Scalable parallel programming for high- performance scientific computing,” in 2008 5th IEEE interna- tional symposium on biomedical imaging: from nano to macro . IEEE, 2008, pp. 836–838

2008

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

Hardware architecture for a modular autonomous underwater vehicle starfish,

M. Sangekar, M. Chitre, and T. B. Koay, “Hardware architecture for a modular autonomous underwater vehicle starfish,” in OCEANS 2008 . IEEE, 2008, pp. 1–8

work page 2008

[2] [2]

A modular design approach for underwater rov: Trident,

T. Mangayarkarasi, R. Harshavardhan, R. Sujith, and K. Sricha- ran, “A modular design approach for underwater rov: Trident,” in 2024 International Conference on Power , Energy, Control and Transmission Systems (ICPECTS) . IEEE, 2024, pp. 1–4

work page 2024

[3] [3]

The modular approach for underwater vehicle design,

A. Y . Tolstonogov, I. A. Chemezov, A. Y . Kolomeitsev, and V . A. Storozhenko, “The modular approach for underwater vehicle design,” in Global Oceans 2020: Singapore–US Gulf Coast. IEEE, 2020, pp. 1–7

work page 2020

[4] [4]

Minion: Modular and independent navigational intelligent orientable nozzle-thruster,

A. Odetti, M. Caccia, and G. Bruzzone, “Minion: Modular and independent navigational intelligent orientable nozzle-thruster,” in Conference Proceedings of iSCSS , vol. 2024, 2024

work page 2024

[5] [5]

Modular controls and instrumentation software for icefin rov,

C. Ramey, M. Meister, A. Spears, J. Lutz, D. Dichek, B. Hur- witz, J. Lawrence, J. Lawrence, M. Philleo, and B. E. Schmidt, “Modular controls and instrumentation software for icefin rov,” in OCEANS 2018 MTS/IEEE Charleston . IEEE, 2018, pp. 1–4

work page 2018

[6] [6]

Hybrid-rov- development of a new underwater vehicle for high-risk areas,

G. Meinecke, V . Ratmeyer, and J. Renken, “Hybrid-rov- development of a new underwater vehicle for high-risk areas,” in OCEANS’11 MTS/IEEE KONA . IEEE, 2011, pp. 1–6

work page 2011

[7] [7]

Moos-mission orientated operating suite,

P. Newman, “Moos-mission orientated operating suite,” Depart- ment of Engineering Science, University of Oxford, Tech. Rep., 2008

work page 2008

[8] [8]

Robot operating system 2: Design, architecture, and uses in the wild,

S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, “Robot operating system 2: Design, architecture, and uses in the wild,” Science robotics , vol. 7, no. 66, p. eabm6074, 2022

work page 2022