Differences

This shows you the differences between two versions of the page.

Link to this comparison view

--- en:safeav:as:applicationdomains [2025/10/17 09:30] – [Aerial Vehicle Architectures] agrisnik
+++ en:safeav:as:applicationdomains [2025/10/28 16:01] (current) – raivo.sell
@@ Line 55: / Line 55: @@
   * Computation Load: Real-time inference on limited onboard computing resources.
   * V2X Communication: Integration with smart infrastructure and other vehicles.
+===== Marine Vehicle Architectures =====
+Marine autonomous vehicles operate in harsh, unpredictable environments characterised by communication latency, limited GPS access, and energy constraints. They include AUVs (Autonomous Underwater Vehicles), ASVs (Autonomous Surface Vehicles) and ROVs (Remotely Operated Vehicles). These vehicles rely heavily on acoustic communication and inertial navigation, requiring architectures that can operate autonomously for long durations without human intervention ([(Benjamin12)].
+<figure Marine Vehicle Architecture  >
+{{ :en:safeav:as:rtu_ch1_figure8.png?400| Marine Vehicle Architecture }}
+<caption>Simplified Marine Vehicle Architecture (based on MOOS-IvP)</caption>
+</figure>
+The reference architecture is based on the MOOS (Mission-Oriented Operating Suite) IvP architecture discussed previously. It provides interprocess communication and logging, while IvP Helm enables a decision-making engine using behaviour-based optimisation via IvP functions. The architecture supports distributed coordination (multi-vehicle missions) and robust low-bandwidth communication ([(Benjamin12)]. The architecture is extensively used in NATO CMRE and MIT Marine Robotics research ((Curcio, J. A., Leonard, J. J., & Patrikalakis, A. (2005). SCOUT—An autonomous surface craft for oceanographic research. Proceedings of the IEEE/MTS OCEANS Conference.)).
+===== Comparative Analysis Across Domains =====
+While the overall trend is to take advantage of modularity, abstraction and reuse, the are significant differences among the application domains.
+^ Aspect ^ Aerial ^ Ground ^ Marine ^
+| Primary Frameworks | PX4, ArduPilot, ROS 2 | Autoware, ROS 2, AUTOSAR | MOOS-IvP |
+| Communication | MAVLink, RF, 4G/5G | Ethernet, V2X, CAN | Acoustic, Wi-Fi |
+| Localization | GPS, IMU, Vision | GPS, LiDAR, HD Maps | DVL, IMU, Acoustic |
+| Main Challenge | Real-time stability | Sensor fusion & safety | Navigation & communication delay |
+| Safety Standard | DO-178C | ISO 26262 | IMCA Guidelines |
+| Emerging Trend | Swarm autonomy | Edge AI | Cooperative fleets |
+An important trend in recent years is the convergence of architectures across domains. Unified software platforms (e.g., ROS 2, DDS) now allow interoperability between aerial, ground, and marine systems, enabling multi-domain missions such as coordinated search-and-rescue (SAR) operations. The integration of AI, edge computing, and cloud-based digital twins has blurred domain boundaries, giving rise to heterogeneous fleets of autonomous agents working collaboratively. Aerial systems look after stability, lightweight real-time control, and airspace compliance; open stacks like PX4/ArduPilot show how flight-critical loops coexist with higher-level autonomy. Ground systems exploit dense, dynamic scenes, heavy sensor fusion, and functional safety; stacks like Autoware illustrate a full L4 pipeline from localisation to MPC-based control. Marine systems suffer from low-bandwidth communications, GPS-denied navigation, and long-endurance missions; MOOS-IvP’s shared-database and behaviour-arbitration approach fits these realities.
+Summarising, a successful autonomy is based on sound software architecture instead of any particular single algorithm. The developed frameworks provide practical blueprints that can be adapted, mixed, and extended to meet mission demands across air, land, and sea.

en/safeav/as/applicationdomains.1760693426.txt.gz · Last modified: 2025/10/17 09:30 by agrisnik