MARS Modular Autonomous Rover System

The project started with a simple idea: building a rover.

At the beginning, I was interested in developing a mobile robotic system that could move autonomously using motors, sensors, and a microcontroller. However, as I started thinking about the project more deeply, one question became important:

What would the rover actually be used for?

A rover that could simply move around and avoid obstacles would demonstrate basic robotics concepts, but I wanted the project to have a more meaningful real-world purpose. This led me to think beyond the rover itself and explore the different situations where such a system could actually be useful.

That exploration eventually led to the concept of MARS — Modular Autonomous Rover System.

Finding a Purpose for the Rover

I began considering different applications for a mobile robotic platform.

One possibility was disaster search and assistance, where a rover could be deployed in areas that may be unsafe for humans. Another was material or package delivery, where the rover could transport items to a specified location. Remote inspection was another potential application, particularly for environments that are difficult or dangerous for people to access.

However, these applications presented an interesting problem.

Each application would require different hardware.

A disaster-search rover might need a camera or additional sensing capabilities. A delivery rover would require a mechanism to carry and release materials. An inspection rover could require a completely different set of sensors.

Instead of developing a separate rover for every application, I explored the possibility of using one common rover platform with interchangeable application-specific modules.

The rover would remain the same, while its purpose could change depending on the module attached to it.

This became the core concept behind MARS.

The Modular Concept

The proposed system would consist of a common rover base containing the fundamental components required for movement and basic autonomous operation.

Application-specific functionality would be added through interchangeable modules.

                     MARS
                      │
             ┌────────┴────────┐
             │                 │
        Common Base       Application Module
             │                 │
          Motors             Search
          Battery            Delivery
          Controller         Inspection
          Sensors            Other Tasks
          Chassis

This approach would allow the same rover to be adapted for different missions without having to redesign the complete robot each time.

For me, this was the key idea that made the project more interesting than simply building another autonomous rover. The goal was to develop a flexible robotic platform rather than a robot limited to one specific function.

Defining the Base Rover

Once the modular concept was established, I started looking at what components would need to be common to every version of the rover.

The base platform was planned around a microcontroller, DC geared motors, a motor driver, battery system, obstacle-detection sensors, chassis, and a modular mounting mechanism.

The ESP32-S3 was initially selected as the main controller. Its processing capability and wireless communication features made it suitable for the planned autonomous and IoT-related functionality.

For the initial obstacle-detection system, ultrasonic sensors were considered. These would provide distance measurements that could be used by the controller to detect obstacles and make basic movement decisions.

Subsystem	Initial Selection	Purpose
Controller	ESP32-S3	Main processing and control
Drive System	DC geared motors	Rover movement
Motor Driver	Motor driver	Motor control
Sensors	Ultrasonic sensors	Obstacle detection
Battery	Rechargeable battery	Main power source
Power Regulation	Buck converter	Regulated supply for electronics
Chassis	Rover chassis	Mechanical structure
Module Interface	Modular mounting system	Interchangeable modules

The Power Problem

One of the first technical challenges I identified was the power system.

The motors would require a considerably higher voltage than the ESP32-S3 and the sensors. This meant that the same battery supply could not simply be connected directly to every component.

A regulated power system would therefore be required.

             Rechargeable Battery
                      │
             ┌────────┴────────┐
             │                 │
       Motor Supply       Buck Converter
             │                 │
       Motor Driver      Low-Voltage Rail
             │                 │
        DC Motors       ESP32-S3 + Sensors

The main battery would supply the motor system, while a buck converter would provide a suitable regulated voltage for the controller and sensors.

This made power management an important part of the system architecture from the beginning.

Making the Rover Modular

The modular concept also introduced mechanical challenges.

The application modules needed to be securely mounted so that they would not become loose while the rover was moving. At the same time, they had to be removable so that different modules could be attached when required.

This meant that the mounting system would need to balance mechanical stability and ease of replacement.

The electrical interface also had to be considered. Different modules could require different power or communication connections, so the base rover needed to be designed with future modules in mind.

This was one of the aspects that made MARS different from a conventional autonomous rover: the base had to be designed not only for what it could do immediately, but also for what could be added to it later.

Keeping the Project Realistic

Another important consideration was the available development time.

There were many possible features that could be added to MARS, but attempting to implement everything would make the project difficult to complete and test properly.

Base Chassis
      ↓
Motor & Drive System
      ↓
Power System
      ↓
Sensor Integration
      ↓
Basic Autonomous Movement
      ↓
Modular Interface
      ↓
Application Modules

The project scope was eventually planned around two application-specific modules. This would provide enough opportunity to demonstrate the modular concept while keeping the development and testing manageable.

The initial architecture was also kept flexible so that hardware choices could be modified if testing revealed better alternatives during the development process.

What Made This Challenging

By the end of Week 0, the project had moved far beyond the original idea of simply building a rover.

The challenge was now to bring together mechanical construction, motor control, power management, sensing, embedded programming, autonomous movement, and modular hardware into one reliable system.

“How can I build a rover?”

But while exploring possible applications, that question changed into something more interesting:

“How can one rover be adapted to perform different real-world tasks?”

That shift in perspective led to the concept of MARS — Modular Autonomous Rover System.

The next step was to move from the concept and architecture to the physical development of the rover base.

##Links

• https://gamma.app/docs/Modular-Autonomous-Rover-System-r9c271r7w8i100q

Last week, MARS existed mostly as an idea—a modular rover platform designed around a common base that could eventually support different application-specific modules.

This week, the goal was much more straightforward:

Start building the rover.

After discussing the project concept and the requirements of the base platform, we moved from planning to the first physical prototype. Before worrying about autonomous navigation or application modules, we needed to establish a stable base on which everything else could be built.

From a Concept to a Chassis

The first task was to create the physical base of the rover.

For the initial prototype, we decided to use foam board as the chassis material. It was lightweight, inexpensive, and easy to cut and modify during the early stages of development.

We cut the board to a size of 30 × 30 cm, giving us a basic platform on which the motors, electronics, battery, and other components could eventually be mounted.

              30 cm
       ┌──────────────────┐
       │                  │
       │    Rover Base    │
       │                  │ 30 cm
       │                  │
       └──────────────────┘

The intention was not to create the final mechanical structure immediately. At this stage, the foam-board chassis served as a practical prototype that allowed us to experiment with the component placement and overall dimensions of the rover.

Getting the Hardware Together

Once the basic chassis was prepared, we began collecting the components required to build the base rover.

Component	Purpose
ESP32-S3	Main controller
DC Motors	Drive the rover
Tyres	Provide traction and movement
Motor Driver	Control the motors
Ultrasonic Sensors	Obstacle detection
Battery	Main power source
Buck Converter	Voltage regulation

Having the major components physically available made the project feel significantly different from the previous week. We could now begin thinking about actual component placement, wiring, and mechanical assembly rather than only discussing the architecture.

The Battery Holder Problem

The first practical obstacle appeared before we could even complete the power system.

We were unable to obtain a suitable battery holder for the battery we had selected. Since the rover required a 12 V supply, we needed a way to establish a reliable connection between the battery and the rest of the system.

Instead of delaying the prototype, we decided to solder the battery connections directly to obtain the required power supply.

This allowed us to continue with the initial prototype, although it also highlighted an important consideration for the later stages of development: the final rover would need a safer and more convenient battery connection method.

Battery
   │
   │  Direct soldered connection
   ↓
12 V Supply
   │
   ├────────→ Motor System
   │
   └────────→ Buck Converter
                    │
                    ↓
              Low-voltage electronics

The solution was therefore useful for getting the prototype running, but it was treated as a temporary arrangement rather than the final power architecture.

The First Physical Version of MARS

By the end of the week, we had completed the first physical foundation of the rover.

It was still a very early prototype, but the transition was important. MARS had moved from a concept and system architecture into something that could actually be assembled and tested.

The 30 × 30 cm foam-board base provided the platform for the next stage, while the major electronic and mechanical components had been acquired.

What We Learned This Week

The main lesson from this stage was that moving from a design concept to a physical prototype immediately introduces constraints that are difficult to identify on paper.

Component availability, mounting space, wiring, battery connections, and physical dimensions all started influencing the design.

The battery-holder issue was a small problem, but it demonstrated an important part of hardware development: the planned design sometimes has to adapt to the components and resources that are actually available.

For now, the temporary battery connection allowed us to continue building. The next challenge was to bring the individual components together and make the rover move.

Next Week: Making It Move

With the basic platform and components ready, the next step was to begin assembling the actual drive system.

We planned to mount the DC motors and tyres, install the motor driver and ESP32-S3, and begin connecting the power system to the rover.

Make MARS move forward and backward.

Once basic motor control was working, we could begin building towards turning, sensor integration, and eventually autonomous movement.

The rover had a chassis.

It had motors.

It had a controller.

Now we needed to make all of them work together.

• Photos

After building the initial physical base of the rover in Week 1, the next challenge was to make sure that the components we had purchased were actually ready to be integrated. Instead of immediately assembling everything together, we decided to first understand and test each component individually.

At the same time, this week introduced us to an important part of the project that we had not worked with much before: designing the mechanical and electronic systems that would eventually hold the rover together.

Testing the Building Blocks

The main focus of the week was testing the components purchased for the base rover. We tested the major components individually, including the ESP32-S3, ultrasonic sensors, motor driver, DC motors, buck converter, battery, and other supporting components.

The purpose of this approach was straightforward: before connecting several components together, we needed to verify that each one was functioning correctly.

This also gave us an opportunity to understand the characteristics and requirements of the individual components. In particular, we spent more time studying the ESP32-S3, since it would act as the main controller of the rover.

Before integrating the system, we first needed to understand the individual building blocks.

Testing the components separately would also make future troubleshooting easier. If a problem occurred during integration, we would have a better idea of which components had already been verified and which part of the system needed to be investigated.

Learning About 3D Printing

Another important part of this week was learning how 3D printing could be used in the mechanical development of MARS.

We had a discussion with Kurian, COO of TinkerSpace, who introduced us to the fundamentals of 3D printing and explained how the design of a part affects the final printed result.

One of the important concepts discussed was tolerance.

A dimension specified in a CAD model does not always translate into exactly the same physical dimension after printing. Factors such as the printer, material, layer settings, and design itself can affect the final dimensions.

This was particularly relevant to MARS because we planned to use 3D-printed parts for components such as motor mounts and other mechanical structures. Understanding tolerances at this stage would help us avoid problems when assembling parts later.

Introduction to PCB Designing

We were also introduced to the basics of PCB designing.

Kurian explained the general process of converting an electronic circuit into a PCB and introduced us to KiCad, which we decided to use as we progressed with the project.

Until this point, our electronic connections were mainly being considered at the individual component and wiring level. Learning about PCB design helped us start thinking about how these connections could eventually be organized into a more permanent and structured system.

Circuit Idea
     ↓
Schematic
     ↓
PCB Layout
     ↓
Fabrication
     ↓
Physical PCB

This became particularly important because the final rover would contain multiple electronic components that would need to communicate and receive power reliably.

Learning From Existing Projects

During the session, Kurian also shared and explained some of the projects he had previously worked on.

Seeing these projects helped us understand how electronic, mechanical, and software components come together in practical systems. It also gave us a better perspective on the design process beyond individual components.

For MARS, this reinforced the importance of considering the complete system rather than developing the electronics, mechanical structure, and software independently.

The Main Challenges

This week did not involve a major mechanical assembly milestone. Instead, the main challenge was building the knowledge required for the next stage of development.

Some components needed to be tested individually before they could be integrated into the rover. At the same time, we needed to become familiar with PCB design and 3D printing before beginning our own designs.

The concept of 3D-printing tolerances was particularly important. A mechanical part that looks correct in a CAD model may not fit as expected after printing if manufacturing tolerances are not considered.

Therefore, the testing and learning carried out this week were not separate from the rover development. They were preparation for the integration stage that would follow.

Decisions Made This Week

Based on the work and discussions during the week, we made several decisions for the next stages of MARS:

• Major components would be tested individually before integration.
• KiCad would be used for PCB design as the project progressed.
• 3D-printing tolerances would be considered while designing mechanical components.
• The ESP32-S3 would continue to be studied in greater detail to understand its capabilities and requirements.
• Mechanical and electronic design would be developed alongside the physical rover rather than being treated as separate stages.

What Comes Next

With the individual components being tested and the basics of PCB design and 3D printing understood, the next step was to begin developing the rover's structure around these components.

• Continue developing the base structure of the rover.
• Start designing the motor mounting structure.
• Continue testing and integrating the electronic components.
• Begin the PCB design process using KiCad.
• Improve the mechanical parts based on the results of testing.

Week 2 was therefore less about making MARS perform a new function and more about preparing the foundation for reliable integration.

We had started with individual components, but the next challenge was to turn those components into a single working system.

Links

-https://learn.pcbcupid.com/documentation/modules/glyph/glyph-esp32s3/glyph-s3-overview -Photos

After testing the individual components in Week 2, we began integrating them into the base rover. This week marked an important transition from testing individual parts to making the rover function as a connected system.

Integrating the Rover

We connected the ESP32-S3, motor driver, DC motors, ultrasonic sensor, and other required components and started working on the rover's control system.

The ESP32-S3's built-in Wi-Fi was then used to create a local host interface through which the rover could be controlled wirelessly. We tested basic movement commands, and the rover was able to move according to the commands sent through the interface.

Adding Obstacle Detection

We also implemented basic ultrasonic-based obstacle detection.

When an obstacle was detected in front of the rover, it would stop and wait until the obstacle was removed before continuing. After testing the system, both the wireless control and basic obstacle detection were functioning as expected.

Wi-Fi Control
      ↓
   ESP32-S3
      ↓
  Motor Driver
      ↓
     Motors

Ultrasonic Sensor
      ↓
   ESP32-S3
      ↓
Obstacle Detected → Stop

Starting the Mechanical Design

Alongside the electronics, we began planning the mechanical structure of the rover. Before moving into detailed CAD modelling, we created rough paper sketches to determine the positioning of the motors, wheels, and other components.

However, we faced a mechanical issue: the wheels were not attaching properly to the motors. This meant that the motor and wheel mounting arrangement needed further adjustment before the base structure could be finalized.

Decisions and Next Steps

Based on this week's work, we decided to continue using the ESP32-S3 Wi-Fi for wireless control and the local host as the control interface. Ultrasonic-based obstacle detection was also retained as part of the base rover.

For the mechanical design, we planned to improve the motor and wheel mounting and then proceed with the detailed CAD design.

The next stage would focus on improving the mechanical structure while continuing the integration of the rover's electronics and control system.

-Photos

After giving MARS wireless control and basic obstacle detection in Week 3, the next goal was to make the rover operate more autonomously. We wanted it to not only detect obstacles but also move between different points without continuous manual control.

Developing Obstacle Avoidance

Initially, we planned to place three ultrasonic sensors at the front, left, and right sides of the rover so that it could detect obstacles from multiple directions.

However, during testing, this arrangement did not provide reliable obstacle avoidance. The rover did not always respond as expected, which showed that the sensor arrangement needed to be reconsidered.

After testing different configurations, we decided to place all three ultrasonic sensors at the front. This provided better coverage in the direction of movement and was more suitable for our current obstacle avoidance approach.

Planning Point-to-Point Movement

We also started working towards a system that could allow the rover to move from one location to another without continuous manual control.

Our approach was to combine path following with obstacle avoidance. The idea was for the rover to follow a predefined path while using ultrasonic sensors to detect and respond to obstacles.

To plan this system, we measured the room dimensions and the intended testing path. These measurements helped us understand the environment in which the rover would operate.

Fixing the Wheel Problem

We also returned to the wheel connection problem from the previous week. After making the necessary adjustments, the wheels were properly attached to the motors, allowing the rover to move correctly.

This removed one of the major mechanical issues and allowed us to focus more on autonomous navigation.

Next Steps

By the end of the week, we had a better understanding of the limitations of our initial sensor arrangement and had established a direction for autonomous movement.

• Developing the path-following system.
• Integrating path following with obstacle avoidance.
• Testing point-to-point movement.
• Further improving the three-front-ultrasonic configuration.

The rover was gradually moving from being remotely controlled to making movement decisions based on its environment.

After working towards autonomous navigation in Week 4, this week brought an unexpected setback. A change in the power system led to the failure of the ESP32-S3, forcing us to reconsider the controller and communication system of the rover.

The Controller Failure

We changed the battery to a 14.8 V battery and began testing the motor driver. During testing, we noticed that the two motor-driver channels were not receiving equal voltage, so we started troubleshooting the system.

While the battery was connected during this testing, a short circuit occurred and damaged the ESP32-S3. Since the controller was an important part of the rover's control system, we needed to find an alternative quickly.

Moving to Arduino Uno

After considering the available options, we decided to replace the ESP32-S3 with an Arduino Uno.

However, this was not simply a controller replacement. The change required us to modify the wiring, code, and communication system to suit the new controller.

The Arduino Uno also does not have built-in Wi-Fi, so the previous local-host control system could no longer be used. We therefore shifted to Bluetooth communication, using a Bluetooth Serial Terminal app to send movement commands to the rover.

Bluetooth Serial Terminal
          ↓
      Bluetooth
          ↓
      Arduino Uno
          ↓
     Motor Driver
          ↓
        Motors

Getting the Rover Moving Again

After rewiring the rover and modifying the code, we tested the Bluetooth-controlled movement.

The rover was able to respond to commands and perform the basic movements successfully. However, the ultrasonic sensors had not yet been integrated with the Arduino Uno, so autonomous obstacle avoidance was temporarily put on hold.

This week showed us that hardware changes can affect the entire system, not just a single component. We had to adapt both the electrical and software sides of MARS to continue development.

Next Steps

• Integrating the ultrasonic sensors with the Arduino Uno.
• Implementing autonomous obstacle avoidance.
• Testing the sensors while the rover is moving.
• Improving the Bluetooth control system.
• Working towards combining remote control with autonomous operation.

The main objective was now to stabilize the new Arduino-based system and continue towards autonomous navigation.

Links

• Photos

After adapting the rover to the Arduino Uno in Week 5, this week we focused on autonomous movement and began developing the final mechanical structure of the base rover.

Developing Autonomous Movement

We integrated the three ultrasonic sensors with the Arduino Uno and tested the rover's basic movements: forward, backward, left, and right.

When an obstacle was detected, the rover stopped and remained stationary until the obstacle moved away. It could then continue its movement.

To improve the detection coverage, the three ultrasonic sensors were arranged at the front in a curved configuration. The left and right sensors were positioned at approximately +25° and -25°, with the third sensor at the centre.

Point-to-Point Navigation

We then worked on making the rover move between predefined points using a map of the testing area.

After providing the room dimensions and layout, we tested commands such as A to B and adjusted the movement several times to achieve the required path and positioning.

This helped us move from simple obstacle detection towards a more structured form of autonomous navigation.

Developing the CAD Model

Alongside the electronics and programming, we started designing the base rover in Zoo Keeper and Fusion 360.

The base was designed at approximately 21 × 18 cm, with dedicated spaces for:

• Battery holder
• Ultrasonic sensor holders
• Module integration area

After checking the dimensions of the physical components, we made several corrections to ensure that the parts would fit properly. The final design was then 3D printed.

CAD Design
    ↓
Check Component Dimensions
    ↓
Make Corrections
    ↓
3D Printing
    ↓
Physical Rover Base

Challenges and Next Steps

The main challenges this week were achieving accurate A-to-B movement and ensuring that the CAD dimensions matched the actual components.

By the end of the week, we had a working direction for autonomous movement and a first 3D-printed structure for the base rover.

Next week, we planned to:

• Improve autonomous movement and A-to-B navigation.
• Complete and test the 3D-printed base.
• Begin developing the module integration mechanism.
• Continue refining the CAD design based on testing.

Week 6 marked an important step from a temporary prototype towards a structured autonomous rover platform.

Links

• https://zoo.dev/docs/zoo-design-studio/zookeeper

After developing the autonomous movement and 3D-printed structure in Week 6, our focus this week was to make the rover more stable, reliable, and organized. The temporary breadboard setup also needed to be replaced with a more permanent arrangement.

Improving the Mechanical Setup

We replaced the existing tyres with 65 mm Universal Hub tyres. The new tyres provided better compatibility with the motors and improved the overall stability and movement of the rover.

We also 3D printed the remaining CAD-designed parts and began arranging the components within the structure. The Arduino Uno, motor driver, battery, and other components were positioned according to the planned layout.

This allowed us to check whether the available space was sufficient and whether the wiring and mechanical components could coexist without interfering with the rover's movement.

Moving to a Perfboard

The previous breadboard connections were temporary, so we began transferring the circuit to a perfboard.

Each connection had to be soldered and checked individually. Since there were many wires in a limited space, arranging them neatly while avoiding short circuits and loose connections was a major part of the work.

After completing the soldering, we tested the connections to verify that the components were properly connected and functio

After spending the previous weeks developing the rover's mechanical structure and transferring the temporary wiring to a perfboard, Week 8 focused on testing the permanent electrical system and integrating the complete rover.

The next challenge was no longer simply getting individual components to work. We needed to make sure that all the components could operate together reliably inside the 3D-printed structure before moving towards mapping and autonomous navigation.

Finalizing the Electrical System

We started the week by testing the completed perfboard circuit. Since the connections were now permanently soldered, each part of the circuit had to be checked carefully to make sure there were no incorrect connections or short circuits.

• Arduino Uno
• Buck converter
• Bluetooth module
• Ultrasonic sensors
• Motor driver
• Motor connections

After checking the individual connections, we powered the system using the 14.8 V battery through the required power arrangement.

We then tested the communication between the Arduino Uno and Bluetooth module, followed by the motor driver and motors. The rover was able to respond to commands and move correctly with the new permanent wiring.

Integrating Everything into the 3D-Printed Base

Once the electrical system was verified, we mounted the perfboard and other components inside the 3D-printed rover base.

This required careful positioning because the available space was limited. The components had to be arranged so that the wiring remained compact while avoiding interference with the mechanical parts of the rover.

The goal was to move away from the earlier breadboard-based prototype and create a more compact, organized, and reliable base rover.

14.8 V Battery
       ↓
  Power System
       ↓
  ┌───────────────┐
  │   Perfboard   │
  │               │
  │ Arduino Uno   │
  │ Buck Converter│
  │ Bluetooth     │
  │ Motor Driver  │
  └───────────────┘
       ↓
     Motors

Ultrasonic Sensors
       ↓
   Arduino Uno

Testing the Ultrasonic Sensors in a Real Environment

With the major components integrated, we turned our attention to the ultrasonic sensors.

Until this point, much of the sensor testing had been carried out during development. We now needed to understand how the sensors behaved in an actual room environment because their measurements would eventually be used for mapping and autonomous navigation.

We placed the rover at different positions and tested the sensors at different distances from walls and other obstacles. We compared the measured distances and observed how the readings changed depending on the sensor's position and the surrounding environment.

This was important because even a small error in distance measurement could affect where the rover believed an obstacle was located. Since the planned mapping system would depend on these measurements, we needed to understand and improve the accuracy before moving forward.

From Testing to Mapping

The room-based testing also helped us identify minor issues with wiring, sensor positioning, and component placement. These were corrected before moving towards the mapping stage.

Component Testing
       ↓
Permanent Perfboard
       ↓
3D-Printed Integration
       ↓
Sensor Calibration
       ↓
Room Testing
       ↓
Mapping
       ↓
Autonomous Navigation

This week therefore represented an important transition. The rover was no longer just a collection of tested components or a temporary prototype. It was becoming a single integrated platform, ready for the next stage of autonomous navigation.

Challenges and Decisions

The main challenges were checking the large

After completing the main base rover and integrating its electrical and mechanical systems, Week 9 was focused on demonstrating what made MARS different from a conventional rover: the ability to perform different tasks by changing its modules.

This week, we developed two different modules. The first focused on remote visual monitoring using a Raspberry Pi and webcam, while the second was designed for environmental sensing using an Arduino Nano.

Raspberry Pi Camera Module

The first module was built using a Raspberry Pi and a webcam to provide the rover with a visual monitoring capability.

Setting up the Raspberry Pi was itself a learning process. I worked through the process of installing the operating system, configuring the Raspberry Pi, connecting it to the required network, and learning how to interface the webcam with it.

Once the setup was completed, we developed a live video streaming system. The webcam connected to the Raspberry Pi could capture video and stream it remotely, allowing the rover to be used for applications such as remote inspection and surveillance.

Webcam
   ↓
Raspberry Pi
   ↓
Wi-Fi Network
   ↓
Live Video Stream
   ↓
Remote User

Working with the Raspberry Pi also introduced me to a different type of development compared with the Arduino-based rover. From installing the OS and configuring the system to connecting peripherals and setting up the camera, I gained practical experience with the complete setup process.

Environmental Sensing Module

The second module was designed for environmental monitoring.

We used an Arduino Nano as the controller and integrated multiple sensors to measure different environmental parameters:

• Gas sensor
• Soil moisture sensor
• Temperature and humidity sensor

This module was intended to allow the rover to collect environmental information while moving through an area.

Gas Sensor ─────────┐
                    │
Soil Moisture ──────┤
                    ↓
Temperature/Humidity → Arduino Nano
                    │
                    ↓
             Sensor Readings

Adding a Servo Mechanism

We also added a servo motor to the environmental sensing module.

The servo was used to raise and lower the soil-moisture sensor when required. This allowed the sensor to be moved into position for taking measurements and then lifted when it was not needed.

This was an important addition because it demonstrated that a module could contain not only sensors but also mechanical actuation for carrying out a specific task.

The Modular System Takes Shape

With these two modules, the original idea behind MARS became more tangible.

The base rover provided the common mobility platform, while different modules could give it different capabilities.

                 MARS BASE ROVER
                       │
          ┌────────────┴────────────┐
          ↓                         ↓
 Raspberry Pi Camera          Environmental
      Module                     Module
          │                         │
     Live Video              Arduino Nano
     Streaming               ├── Gas Sensor
                             ├── Moisture Sensor
                             ├── Temp/Humidity
                             └── Servo Motor

The Raspberry Pi module demonstrated remote visual monitoring, while the Arduino Nano module demonstrated environmental data collection and sensing.

Challenges and Learning

The main learning experience this week came from working with hardware that was different from the electronics used in the base rover.

Working with the Raspberry Pi required learning the setup process from the beginning, including OS installation, configuration, peripheral connections, networking, and camera streaming.

At the same time, developing the Arduino Nano-based module required integrating several sensors and coordinating them with the servo mechanism.

This week showed us that the modular architecture could actually be used to extend the rover's functionality without redesigning the entire base system.

Next Steps

With the first two application-specific modules developed, the next focus would be on testing their integration with the MARS base rover, improving their physical mounting, and ensuring that the modules can be attached and operated reliably.

Week 9 was therefore a major milestone for MARS: the project had moved beyond simply building an autonomous rover and had started demonstrating the idea of one common rover platform supporting multiple specialized applications.

After developing the two application-specific modules in Week 9, the main focus this week was calibration and testing. At this stage, the major components of MARS were already working, but getting everything to work reliably together required repeated testing and adjustment.

Calibrating the Rover

A significant part of the week was spent calibrating the rover's sensors and movement system.

The ultrasonic sensors were tested repeatedly to ensure that their distance measurements were consistent and suitable for obstacle detection and navigation. We also checked the rover's movement and made adjustments wherever necessary so that its actual movement matched the expected behaviour.

Sensor Readings
      ↓
   Calibration
      ↓
      Test
      ↓
  Identify Error
      ↓
   Adjustment
      ↓
     Retest

This process had to be repeated several times. Small differences in sensor readings, motor movement, positioning, and the physical arrangement of components could affect the rover's overall performance.

Calibrating the Modules

The application-specific modules also required testing and calibration.

The Raspberry Pi camera module was tested to ensure that the camera and live-streaming system were functioning correctly.

The Arduino Nano environmental sensing module was also tested with its gas, soil-moisture, and temperature-humidity sensors. The servo mechanism used to raise and lower the soil-moisture sensor was checked to ensure that it operated correctly when required.

Each part had to be tested individually and th

e