Technical Design - Weber-State-Submarine-Project/Submarine GitHub Wiki

Technical Design

The technical design document serves to fully document the engineering design.

1. Introduction

Maintaining pools is a challenging task, and neglect can lead to costly repairs. For example, the Roy Complex faced a two-year shutdown due to significant issues, including broken boilers, rusted and damaged pool floors, and other structural problems. These challenges resulted in a $2 million repair and renovation effort.

The initial goal of this project was to design a water vehicle capable of mapping the pool and identifying surface damages. However, due to the complexity of the task, the focus shifted to autonomous navigation and mapping, which forms the core of this project. While there are pool cleaning robots available on the market, none provide the capability to alert users to potential structural damages. This highlights the need for a product like this, aimed at enhancing pool maintenance through automation and early detection.

2. Scope

This document outlines the design and implementation of a solution addressing a critical aspect of pool maintenance: autonomous pool mapping. It focuses on the system's capabilities and design for creating pool maps but does not address the detection of surface damages or pool cleaning functionalities. This focuses purely on the creation of the boat, components used for navigation, and the navigation behaviors.

3. Design Overview

In this section, we’ll delve into the project’s requirements, dependencies, theory of operation, and explore potential design alternatives.

3.1 Requirements

There are two main focuses, a vehicle able to autonomously create 3D maps of a rectangular swimming pool, and a user app to view the progress it's making. Here are tables of our deliverables:

3.1.1 Autonomous Mapping Deliverables

Deliverable	Description
3D Mapping	Generates a map of the pool floor and walls.
Surface-Level Mapping	Operates at the water surface to complete the mapping process.
Initial Positioning	Requires the boat to start with a wall .5-2 meters to the left and open space in front (2+meters). For proper mapping the boat must start facing in the direction that the depth changes
Wireless Communication	Transmits data and messages via Wi-Fi to the user app (Foxglove).
Rectangular Pools Only	Optimized for rectangular-shaped pools.
Excludes Objects	Does not include floating objects, ladders, or stairs in the map.

3.1.2 User Application (Foxglove) Deliverables

Deliverable	Description
Near Real-Time Mapping	Renders the map dynamically during data collection
Start/Stop Controls	Includes a button to start/stop the navigation.
Start Notification	Notifies the user upon initiation of automatic mapping triggered by the user pressing the start button.
Completion Notification	Alerts the user when mapping is complete.
Interruption Alerts	Sends notifications for manual stops during the mapping process.

3.2 Constraints

3.2.1 Materials, Costs, and Hours

The project required significant time and resources, combining labor, research, design, and implementation efforts. The total estimated effort amounted to over 300 hours per team member, with a detailed breakdown provided below. The financial constraint was set by an OUR grant of $1,084.85, which defined the allowable budget for the components and materials used in the project.

Estimated Project Hours

The project was divided into two primary phases: Research and Project Execution, each contributing to a estimated 300 hours as follows:

1. Research Phase (20% - 60 hours)

Requirements Analysis: 20 hours
Detailed examination of project needs and deliverables.
Technology and Methodology Research: 20 hours
Investigation of tools, platforms, and approaches applicable to the project.
Market Analysis for Similar Solutions: 10 hours
Study of existing products or systems for comparative insights.
Feasibility Study: 10 hours
Evaluation of technical, financial, and logistical viability.

2. Project Execution Phases (80% - 240 hours)

Design Phase (50 hours)

Requirements Refinement: 10 hours
Adjustment and clarification of initial requirements based on research findings.
Hardware and Software Design: 20 hours
Development of technical schematics, architectures, and flowcharts.
Prototyping and Testing: 20 hours
Creation and evaluation of preliminary versions of hardware and software.

Mapping and Navigation Development (110 hours)

Movement Control Software: 20 hours
Implementation of control algorithms for motor operation.
Autonomous Navigation Algorithms: 70 hours
Development of path planning and obstacle avoidance logic.
Testing Navigation and Detection: 20 hours
Verification of mapping accuracy and obstacle detection functionality.

Hardware Implementation and Testing (40 hours)

Hardware Integration: 20 hours
Assembly of hardware components into a cohesive system.
Testing and Validation: 20 hours
Validation of hardware performance and compatibility.

Software and Hardware Integration (20 hours)

Integration of Components: 20 hours
Synchronization of software and hardware functionalities.

Testing, Refinement, and Deployment (20 hours)

Comprehensive Testing: 10 hours
End-to-end validation of the entire system.
Refinement and Optimization: 5 hours
Adjustments to enhance efficiency and reliability.
Deployment Planning: 5 hours
Preparation for real-world deployment and demonstration.

Although the estimated time was 300 hours each, there was more than 300+ hours contributed towards the project.

Estimated Project Costs

The project budget was strictly constrained to the $1,084.85 grant. The table below outlines the materials and associated costs:

Material	Quantity	Unit Cost	Total Cost
PVC Pipes	10	$7.00	$70.00
Brushless Motor	2	$64.00	$128.00
Side/Bottom Sonar Sensor	2	$28.00	$56.00
Front Sonar Sensor	1	$460.00	$460.00
Orientation Sensor	1	$35.00	$35.00
DC to DC Converter	1	$55.00	$55.00
LIPO Battery (2x)	1	$33.00	$33.00
USB Buck Converter (2x)	1	$16.00	$16.00
UART to USB (2x)	2	$9.00	$18.00
Epoxy	1	$14.00	$14.00
Corrosion X	1	$29.00	$29.00
Raspberry Pi 5	1	$91.00	$91.00
Shrink Wrap	1	$9.00	$9.00
M3 Screw Kit	1	$22.00	$22.00
Zip Ties	1	$12.00	$12.00
Micro USB Cable	1	$7.00	$7.00
USB C Cable	1	$8.00	$8.00
Cable Gland IP68	1	$15.00	$15.00
Pool Rental	1	$90.00	$90.00
Total Cost			$1,168.00
Grant Budget			$1,084.85

This comprehensive breakdown ensures clarity in resource allocation, project planning, and financial management.

3.2.2 Physical Limitations

The design and functionality of the autonomous pool mapping system are constrained by several physical factors, including environmental conditions, component specifications, and operational requirements:

1. Pool Environment

The system is optimized for rectangular pools and may not perform accurately in irregular or non-standard pool shapes.
Depth limitations of the sonar sensors restrict their usage to pools with a maximum depth within the sensors' range.

2. Device Dimensions

The boat’s size and shape are constrained by the need for compactness to ensure easy deployment and maneuverability within the confined space of a pool.
A balance had to be maintained between the boat’s buoyancy, weight distribution, and stability to prevent capsizing during operation.

3. Sensor Coverage

Sonar sensors have a limited field of view and range, requiring precise positioning and alignment to capture accurate data.
The side and down sonar sensors must be positioned at specific angles and distances from the pool walls and floor for effective mapping.

4. Power Constraints

The use of a lightweight design limits the battery capacity, which impacts the duration of mapping missions. Prolonged operation may require recharging or battery replacement.

5. Waterproofing

Electronics must remain fully sealed to prevent water damage. This introduces design challenges in routing cables and ensuring that connectors maintain a waterproof seal.
Prolonged exposure to chlorine and other pool chemicals can degrade materials, requiring additional protective coatings and careful material selection.

3.2.3 Scheduling Constraints

The development of the autonomous pool mapping system faced several scheduling constraints due to project timelines, resource availability, and external factors:

1. Academic Timeline

The project needed to be completed within the duration of an academic year, limiting the time available for iterative design, testing, and refinement.
Deadlines for key milestones, such as Preliminary Design Review (PDR - April 18th, 2024), Demo Day (November 21st, 2024), and Final Design Review (FDR - December 4th, 2024), required prioritizing deliverables and focusing on core functionalities over additional features.

2. Resource Availability

Access to testing facilities, such as swimming pools, was limited due to facility operating hours, maintenance schedules, and external bookings. Coordinating access required advanced planning to align with team availability.
Collaboration with external teams (e.g., 3D printing and design assistance) introduced delays due to their availability and workload.

3. Development Phases

Design Phase: Time was allocated for researching and selecting components, as well as creating the boat’s structural and system design.
Purchase Phase: Time dedicated when purchasing components and waiting for them to arrive.
Implementation Phase: Sensor integration, software development, and waterproofing required careful scheduling to avoid bottlenecks.
Testing Phase: Limited access to pools for real-world trials necessitated efficient test plans, focusing on critical features like mapping and navigation. Backup testing was performed in alternative water settings when pools were unavailable.

4. Contingency Planning

Unexpected challenges, such as equipment malfunctions, sensor integration issues, or delays in component delivery, required reallocating time from other phases.
Reducing scope (e.g., excluding damage detection) allowed the team to focus on completing the mapping functionality within the timeline.

By carefully managing the schedule, coordinating with pool facilities, and prioritizing essential deliverables, the project successfully met its core objectives within the given constraints.

3.2.4 Safety Considerations

The development of the autonomous pool mapping system incorporates several safety considerations to ensure the protection of users, equipment, and the environment:

1. Electrical Safety

Waterproofing Electronics: All electronic components are housed in a waterproof enclosure to prevent short circuits or damage from water ingress. Cable glands and epoxy resin were used to secure connections and ensure complete sealing. As well as the components were sprayed with CorrosionX to allow them to function even when underwater.

2. Mechanical Safety

Propeller Guards: The brushless motors powering the boat are equipped with protective covers to prevent accidental contact with the propellers. Although it should be note not to place any components or body parts where the propellers should spin.
Stable Design: The boat’s frame was carefully designed for proper weight distribution, minimizing the risk of capsizing during operation. As well as due to the hollow base, the boat is able to pivot and turn in place.

3. Pool Environment

Non-Toxic Materials: Materials used, such as PVC pipes and resin coatings, were chosen for their resistance to chlorine and safety in a pool environment.
Chemical Resistance: Epoxy coatings were applied to the enclosure to prevent degradation from pool chemicals over time.
Limitation on Speed: Speed limitations of the vehicle was applied to limit collision damage of the pool walls.

4. User Safety

Remote Operation: The boat is controlled wirelessly via the Foxglove app, eliminating the need for users to be in the pool during operation.
Clear Start/Stop Mechanism: The system includes a user-friendly interface with start/stop controls to ensure safe and intentional operation.
Manual Control: The boat can be controlled manually by a controller to retrieve the device if in a unsafe/unreachable position.

By addressing these safety considerations, the system was designed to minimize risks and ensure reliable operation in a pool environment.

3.3 Applicable Standards

The autonomous pool mapping system adheres to the following engineering standards to ensure compatibility, reliability, and efficient communication between components:

1. USB (Universal Serial Bus)

Standards: USB 2.0 and USB 3.0
Description:
- USB 2.0 is utilized for interfacing sonar sensors (e.g., Ping2) and UART-to-USB adapters for serial communication.
- USB 3.0, with its higher data transfer rates, is used where faster communication is required, ensuring minimal latency for real-time operations.
Compliance Benefits:
- Supports a wide range of devices with backward compatibility between USB 2.0 and USB 3.0.
- Ensures reliable, high-speed communication for transferring sensor data.
- Simplifies device connection and configuration through plug-and-play functionality.

2. I2C (Inter-Integrated Circuit)

Standard: I2C Bus Specification (Version 2.1)
Description:
- The I2C protocol is used to connect the Raspberry Pi to the Adafruit PWM Hat and the BNO085 orientation sensor.
- Facilitates communication with multiple devices over a single bus, reducing the complexity of wiring.
Compliance Benefits:
- Enables efficient and synchronous communication for controlling motors and reading sensor data.
- Allows expansion of the system with additional I2C-compatible devices as needed.
- Ensures compatibility with the wide ecosystem of I2C-enabled hardware.

By leveraging these standards, the system ensures reliable performance, seamless integration, and scalability for future enhancements or additional features.

3.4 Dependencies

The following list all dependencies the autonomous pool mapping boat requires.

1. Power Supplies

LiPo Battery (14.8V): Provides power to the ESCs and Pi.
DC-to-DC Converter: Steps down voltage (14.8V to 8.5V) for sensors and other low-power components.
USB Buck Converter: Steps down voltage (14.8V to 5V) for Pi 5.
Raspberry Pi Power Supply (5.1V, 3A): Powers the Raspberry Pi for running software and managing components.

2. Structural and Environmental Requirements

Waterproof Enclosure: Protects electronic components from water ingress during operation.
Pool Environment: A controlled environment for testing and operation.

3. External Hardware

UART-to-USB Adapters: Facilitate communication between the Raspberry Pi and sonar sensors.
Cable Glands: Ensure waterproof cable routing into the enclosure.
PWM Hat: Provides motor control via the I2C bus.

4. Software Dependencies

Ros2 Jazzy: Required for running navigation and mapping nodes.
Foxglove: Provides a user-friendly interface for monitoring and control.
All Software Dependencies

3.5 Theory of Operation

The Theory of Operation section provides a high-level overview of the system's design and functionality. It includes block diagrams, flowcharts, and visual representations to explain the integration of components and how they work together.

Overview

The autonomous pool mapping system operates as a modular design where hardware components, software nodes, and user interfaces interact seamlessly. Each module performs a specific function, such as sensing, control, or communication, and collectively enables the boat to navigate and map the pool autonomously.

Key Components

Sensors: Sonar sensors (front, side, and down) provide distance measurements for mapping and navigation.
Thrusters: Motors controlled via the PWM Hat enable propulsion and maneuverability.
Controller: The Raspberry Pi serves as the central processor, managing sensor data, motor control, and user interactions.
Software Nodes: ROS 2 nodes process sensor inputs, execute navigation algorithms, and publish data to topics for real-time monitoring.

Additional Resources

Explore the following pages for detailed diagrams and visualizations:

Pinouts: Details the wiring and connections for all components.
Block Diagrams: Provides a graphical representation of the system's design and component integration.
RQT Graph: Illustrates the ROS 2 node-to-node communication within the system.
Behavior Tree: Describes the decision-making process for autonomous navigation and mapping.

By combining these elements, the system ensures reliable operation and delivers accurate mapping results in a controlled pool environment.

3.6 Design Alternatives

The design process involved evaluating multiple alternatives to achieve the project’s objectives. While some designs were explored, they were ultimately rejected due to various limitations or challenges. This section highlights the alternatives considered and the reasons for their rejection.

Overview of Alternatives

Original Submarine Design:
- Initially, the project focused on creating a fully submerged submarine capable of mapping and detecting damages in pools. However, this approach was deemed too complex within the project’s timeline and scope.
- Reason for Rejection: The added complexity of underwater navigation, waterproofing, and damage detection made it unfeasible to complete within the allocated time and budget.
Speed Sensor-Based Localization:
- A Garmin speed sensor was proposed for velocity measurements to assist with localization. The system relied on detecting movement through water currents.
- Reason for Rejection: Testing revealed the speed sensor was ineffective at low speeds, as the water wheel did not rotate sufficiently to produce reliable data.
Acceleration-Based Localization:
- The BNO085 orientation sensor’s acceleration data was considered for estimating velocity and position.
- Reason for Rejection: The data was too noisy, leading to significant inaccuracies. Efforts to calibrate the sensor or filter the noise did not yield satisfactory results.

Detailed Documentation

For more information on these and other rejected concepts, visit:
Outdated/Failed Concepts/Alternatives

By exploring and rejecting these alternatives, the project team was able to focus on a streamlined and achievable solution.

4. Design Details

This section provides sufficient detail for another engineer to understand and duplicate your design. While this document summarizes key aspects of the hardware, more detailed schematics, diagrams, and full code listings can be found in the Appendices or referenced links.

4.1 Hardware Design

The hardware design encompasses the physical construction, waterproofing, sensors, motors, and orientation systems required to build the autonomous water vehicle. Below is an overview of each hardware component and its role in the system, with links to detailed documentation.

4.1.1 Boat Construction

The boat's construction serves as the foundation of the autonomous system. It ensures stability, buoyancy, and sufficient space for electronics and motors. The design includes:

Materials used for the hull and frame.
Materials used to counteract the weight of the electronics.
Mounting points for sensors, motors, and the electronics box.
The entire building process of the boat.

For a detailed explanation, visit the Boat Construction wiki page.

4.1.2 Electronics Box and Waterproofing

The electronics box houses all critical components, ensuring protection against water damage while maintaining functionality. Key aspects include:

The design of waterproof seals and gaskets.
Access points for connectors to external components (motors, sensors, etc.).
CAD models of the box.

For an in-depth guide, see the Electronics Box and Waterproofing wiki page.

4.1.3 Sonars

Sonars are crucial for mapping the pool environment and detecting obstacles. This section covers:

Types of sonars used and their specifications.
Placement on the boat for optimal field of view.
Pinout integration.
Communication procedures.
CAD attachment model.

More details can be found on the Sonars wiki page.

4.1.4 ESC Motors

The ESC (Electronic Speed Controllers) and motors enable propulsion and maneuvering. This section includes:

The selection of ESCs and motors based on power and efficiency.
Control strategies for forward, reverse, and turning.
Electrical and mechanical integration with the boat's design.
Communication of ESC Motors.
PWM signals.
CAD attachment model.
Hardware Vs. Software PWM.

Learn more at the ESC Motors wiki page.

4.1.5 BNO085 Orientation Sensor

The BNO085 is responsible for orientation sensing, which is critical for navigation and stabilization. This section outlines:

The sensor's capabilities (e.g., linear acceleration, angular velocity, orientation data).
Communication with the Raspberry Pi for real-time data acquisition.
Pinout Diagram of use.
Timing characteristics.

Refer to the BNO085 Orientation Sensor wiki page for detailed insights.

4.2 Software Design

The software design focuses on the algorithms, simulations, and control systems that govern the autonomous behavior of the boat. Below is an overview of each software component and its role in the system, with links to detailed documentation.

4.2.1 Simulation

The simulation environment allows testing and validating the software components in a virtual setting before deploying them on the hardware. Key aspects include:

Simulating the physical behavior of the boat.
Testing navigation and control algorithms.
Reducing risks in real-world deployment.

For more details, visit the Simulation wiki page.

4.2.2 Behavior Tree

The behavior tree governs the decision-making process of the vehicle. This modular structure enables:

High-level control of autonomous behavior.
Implementation of task priorities and conditions.
Flexibility in extending or modifying behaviors.

Learn more on the Behavior Tree wiki page.

4.2.3 Map Creation

Mapping is essential for the vehicle's ability to navigate and understand its environment. The software:

Processes sonar data to generate a 3D map of the pool.
Handles data filtering and merging from multiple sensors.

For additional information, see the Map Creation wiki page.

4.2.4 Robot Localization (Velocity)

Localization is critical for tracking the vehicle’s position and velocity in the pool. This component involves:

Estimating velocity using onboard sensors.
Maintaining an accurate state representation for navigation.

Refer to the Robot Localization wiki page.

4.2.5 Sonars

The sonar software processes raw sensor data to detect objects and create a representation of the environment. This includes:

Filtering noise from sonar data.
Integrating sonar data with the mapping and navigation system.

Learn more at the Sonars wiki page.

4.2.6 ESC Motors

The ESC motor control software manages the propulsion system, including:

Translating behavior tree commands into motor control signals.
Supporting forward, reverse, and turning motions.
Arming the ESC.

Detailed documentation is available on the ESC Motors wiki page.

4.2.7 BNO085 Orientation Sensor

The BNO085 software integrates orientation data into the navigation system. Features include:

Real-time data (imu) acquisition from the BNO085 sensor.

Visit the BNO085 wiki page for more details.

4.2.8 Manual Controller

The manual controller software enables manual control of the vehicle for testing and overrides. It includes:

Mapping joystick inputs to motor commands.

For more details, see the Manual Controller wiki page.

4.2.9 Foxglove

Foxglove provides a visualization and debugging tool for the vehicle’s data and state. It includes:

Real-time monitoring of system metrics.
Debugging visualization for navigation and sensor data.
Start/Stop buttons for mapping.
Displays 3D map when finished.

For additional details, visit the Foxglove wiki page.

4.2.10 Launch File

The launch file orchestrates the initialization and coordination of all software components. It ensures:

Proper startup sequence for critical systems.
Configurable options for different operating modes.

Learn more on the Launch File wiki page.

5. Testing

Testing is critical to ensure that the design meets the functional, performance, and safety requirements. This section outlines the tests performed, including procedures, expected outcomes, actual results, and their relation to specific requirements.

5.1 Overview

The testing process was divided into three key phases:

Unit Testing: Verifying the functionality of individual components (e.g., sensors, motors, control algorithms).
Integration Testing: Ensuring the seamless interaction between hardware and software components.
System Testing: Validating the overall system performance in real-world scenarios.

For detailed testing procedures and plans, refer to the Test Plan wiki page.

5.2 Test Procedures

Each test followed a structured procedure to ensure reproducibility and reliability:

Test Procedure: A step-by-step guide outlining how the test was conducted.
Expected Results: What was anticipated based on design requirements.
Actual Results: The observed outcomes during the test.
Requirement Verification: Links to specific design requirements tested.

5.2.1 Sensor Testing

Objective: Verify the accuracy and reliability of sensors, including sonar and BNO085.

Procedure:

Place the vehicle in a controlled environment (e.g., a swimming pool).
Collect sensor data while performing predefined maneuvers.
Compare recorded data with reference measurements.

Expected Results:

Sonar accurately maps distances with relative close readings to real data values.
BNO085 provides consistent orientation readings.

Actual Results:

Sonar mapping achieved a 92% accuracy rate.
Orientation data aligned with ground truth measurements.

Requirement Verification: Ensures compliance with 3D Mapping Requirement.

5.2.2 Motor and ESC Testing

Objective: Test the propulsion system for speed control and directional accuracy.

Procedure:

Run the ESC motors at various power levels.
Evaluate motor responsiveness to control signals.

Expected Results:

Smooth transitions between power levels.
Accurate directional control with slight tolerance and delay due to drag.

Actual Results:

Power transitions were smooth, but slight lag was observed in directional changes probably due to connection and drag.

Requirement Verification: Supports the deliverable of 3D Mapping.

5.2.3 Autonomous Navigation Testing

Objective: Validate the vehicle’s ability to autonomously navigate around the pool.

Procedure:

Position the robot, Launch the robot, and press start.
Ensure the robot follows the behavior tree.
Monitor real-time localization and wall avoidance.

Expected Results:

Completion of the path without collisions.
Consistent points collected for mapping.
3D map generated
Foxglove monitoring close to real-time.
Aligns itself based on orientation and will adjust/fix itself if off course.

Actual Results:

Successful navigation, return to original location and stopped.
Avoided all wall collisions and turned when needed.
Foxglove mapping slightly delayed with real-time as expected due to WiFi.
3D map generated and displayed on Foxglove with a 92% accuracy.
Was able to fix orientation and position after being pushed from pool jet

Requirement Verification: Confirms compliance with autonomous navigation, 3D Mapping, Wireless Communication, Near Real-Time Mapping, Start/Stop Controls, and Notification deliverables.

5.3 Results Summary

The results from testing were analyzed to verify system functionality and identify areas for improvement. A summary of test outcomes is documented on the Results wiki page.

5.4 User Testing

To ensure usability, here is a User Guide.

6. Conclusion

The testing phase of the autonomous boat project validated the functionality and performance of both individual components and the integrated system. Below is a summary of the key findings and observations:

6.1 Summary of Test Results

Sonar Sensors: Successfully generated 2D SLAM maps and 3D Octomaps with high accuracy, meeting the design's navigation requirements. Minor calibration was required to reduce noise in the sonar data.
Boat Build: The boat demonstrated excellent stability and maintained waterproofing under prolonged submersion tests, ensuring protection of critical electronics.
Orientation Sensor: The BNO085 provided reliable orientation data, enabling precise navigation and seamless integration with localization algorithms.
Motors and ESCs: The propulsion system met performance expectations, with smooth forward, reverse, and turning motions. Slight delays in directional changes were noted and adjusted during testing.
Behavior Tree and Navigation: The behavior tree handled task execution effectively in a controlled environment.
Integrated Pool Testing: The system successfully navigated and mapped a real-world environment, generating a 3D map. Minor gaps in coverage can be addressed through additional sensor passes.

6.2 Observations on Performance

The system achieved all primary objectives, with small concerns such as IP68 sonars struggling to receive data at certain aspects of the pool.
Real-time data acquisition and processing from sensors, motors, and navigation algorithms were consistent and reliable.
The modular design of both hardware and software components facilitated straightforward testing, debugging, and integration.

6.3 Insights for Future Improvements

Sensor Calibration:
- Implement automated calibration routines for the orientation sensors to improve initial setup time and accuracy.
Behavior Tree Refinement:
- Enhance the behavior tree logic to handle additional edge cases and improve obstacle avoidance in complex environments.
Robustness in Adverse Conditions:
- Test the system in more challenging environments (e.g., murky water, turbulent conditions) to identify potential vulnerabilities.
Improved Mapping:
- Explore the integration of additional sensors (e.g., cameras, 3D Sonar or LIDAR) for enhanced mapping resolution and coverage.
Custom PCB:
- Explore creating a custom PCB that includes the IMU, PWM, and other components together for a robust and easier connection to everything.
Dedicated Velocity Sensor:
- Integrate a pitot tube along with a water flow sensor to accurate measure velocity.
Saving Octomap Data:
- Explore the integration of saving the Octomap data so that it can be read and visualized into Foxglove later.

6.4 Closing Remarks

The autonomous boat project demonstrated a successful implementation of hardware and software systems working in unison to achieve precise navigation and mapping capabilities. The lessons learned from this project provide a strong foundation for future iterations and advancements in autonomous water vehicle design.

For detailed test results, see the Results wiki page.

7. References and Bibliography

This section lists references to other works you used to write this document.

ROS2 Tutorials: Official tutorials and documentation for learning and implementing ROS2 features and functionalities.
Dependencies: A curated list of software dependencies and installation instructions specific to this project.
Data Sheets: Technical data sheets for hardware components used in the project, including sensors and motors.

Acknowledgments:

Professor Dr. Jonathan West: For his invaluable guidance in teaching robotics principles and the fundamentals of ROS2, which played a crucial role in this project's success.