Autonomous Grass-Cutting and Garden-Watering Robot Development

This case study illustrates the complete and thorough lifecycle of an autonomous gardening robot that performs two jobs: precision mowing of grass and efficient watering based on moisture of the soil.

Our cross-functional team supervised every component of the product, i.e., from mechanical design to custom PCB design to embedded programming to making use of computer vision and autonomous navigation to mobile application development and cloud backend creation as well as field tests.

Taking four months, we managed to turn an abstract idea into a workable prototype. Thanks to our innovation, we have reduced labor in lawn care by 70%, reduced water use by 30%, and got coverage of 95% on a test lawn of 400 square meters.

This case shows that end-to-end ownership is an important factor in speeding up iterations, improving hardware and software integration, and enhancing the user experience.

1.1 The Problem

Homeowners and small-scale landscape contractors spend approximately six to eight hours every month on lawn and garden maintenance that often consists of repetitive tasks. Manual mowing involves heavy physical strain and simple timer-based irrigation systems are notorious for over-watering and wasting a limited resource in many places.

The market had both robotic mowers capable of cutting grass but not watering, and smart watering controllers that were able to do watering but did not mow. This gave rise to an opportunity of creating a unique solution that automated both processes in an efficient manner.

1.2 Requirements Definition

Our technology team detailed the market prospects into a set of full requirements:

• Mowing: Cuts up to 500 m² with a minimum of 95% efficiency and adjustable mowing height.
• Watering: Waters up to 50 m² bed using closed-loop soil moisture detection and weather-aware irrigation.
• Autonomy: Works without human supervision during the complete cycle.
• Connectability: Mobile app command via Bluetooth and Wi-Fi, cloud scheduling, and monitoring.
• Safety: Blade kill switch, tilt detection, emergency stop, and high obstacle avoidance efficiency.
• Power: Minimum power supply working time of 90 minutes.
• Environment: IP54 rating for low-dust and rain protection.

We chose to implement a three-tier processing architecture rather than that of single-processor design. This choice was fundamental and needs clarification.

2.1 The Three-Tier Rationale

The real-time microcontroller (STM32F407, ARM Cortex-M4 operating at 168 MHz) was in charge of the motor control, sensor polling, and safety interlocks. Deterministic real-time response is vital for ensuring blade safety, and thus we isolated these functions from the upper-level software.

A Linux-based SBC (Raspberry Pi 4, four-core Cortex-A72) is responsible for navigation, path planning, and computer vision, where throughput and rich libraries are very important, but not determinism.

ESP32 provided Wi-Fi and Bluetooth connectivity, being a communication bridge.

By employing this separation principle, we were able to accomplish three objectives: safety-critical code couldn't be compromised by navigation errors; the Linux base could be modified independently; and the communications method could be validated and tested in isolation.

2.2 Hardware Architecture

The robot's foundation was a four-wheeled chassis that was driven by 250 W brushless DC hub motors, because they are able to provide a high torque output, as well as eliminating the need for any gear assembly. The cutting blade was deployed via a separate 500 W BLDC motor through a hardened steel shaft.

A diaphragm pump, rated at 12 V, was responsible for generating pressure in a 10-liter water tank. The robot was powered by a 24 V lithium battery pack that had a capacity of 20 Ah, and was controlled via the battery management system (BMS) which enabled the proper charging and regulating of the battery banks.

The sensor suite included wheel encoders for odometry, an MPU6050 IMU that provided information about tilt and heading of the robot, ultrasonic range finders that were responsible for detecting nearby obstacles, a GPS/RTK module for accurate positioning, a rain detector, and capacitive soil moisture sensors located in different sections of the garden.

2.3 Software Architecture

The embedded firmware used FreeRTOS operating system, with various tasks performing motor control, sensor data processing, safety monitoring, and communication. A boustrophedon-style A*-based navigation engine was employed.

In the irrigation subsystem, a proportional closed-loop control algorithm opened a solenoid valve only when moisture level was below the set threshold and no rainfall was forecasted.

2.4 Mobile and Cloud

The application employs Flutter so that both on Android and iOS, a single codebase is used. The application provides manual joystick control, scheduling, live telemetry, notification about battery and fluid level and sending push notifications.

The cloud-based backend uses MQTT in conjunction with AWS IoT Core, where the management of the device is carried out along with the collection of telemetry data and firmware updates.

3.1 Mechanical Design and Iteration

The chassis was designed in SolidWorks, with an emphasis on weight distribution patterns and clearance.

The cutting deck could be adjusted from 30 mm to 70 mm in height by using a lever, with the prospective addition of motorised height adjustment in the future.

The water tank was mounted as low and in the centre as possible to ensure proper stability when it is full, which was only learned after the first prototype tipped over.

3D-printed PETG brackets were utilized for sensor mounting in the initial stage of realization and transferred to aluminum chassis manufacture after studying the vibration characteristics.

Initially weighing 18 kg, we managed to lower the weight to 14.5 kg after many cycles of swapping parts and changing their position.

3.2 Electronics and PCB Development

A special four-layer PCB was created with motor driver circuits, power regulation, the STM32 microcontroller, and sensor interface circuits incorporated within it. The built-in board also included reverse polarity protections, over-current protections, and hardware watchdog functionality.

The careful ground-plane segmentation used allowed for separation of the high current outputs of the motors and high-accuracy analog sensor wires, which enabled us to solve encoder noise issues experienced in the prototype.

We validated every assembled board with a bed-of-nails test fixture before final assembly, catching solder defects and component placement errors before they reached the field.

3.3 Hardware Obstacles and Fixes

The vibration of the cutting motor caused connector failures early in the testing process. This was resolved using locking connectors and damping mounts made of silicone. A follow-up vibration test confirmed that the solution worked. The electronics were then sealed using IP-rated gaskets and conformal coating, especially on the USB, and charging ports.

4.1 Real-Time Control

The STM32 software implemented a cascade of PID controllers for both wheel speed and blade speed. Wheel encoders provided odometry for the robot, while IMU corrected heading drift using a complementary filter. There was a separate safety task that monitored tilt angle, bump sensors and emergency stop. The safety task cuts off the power to the blade in case of fault within 50 ms from the event which was confirmed many times in the tests.

4.2 Navigation and Coverage Planning

Raspberry Pi utilized the ROS2 navigation stack. RTK GPS was used for centimetre accuracy positioning while ultrasonic sensors were used for close-range obstacle avoidance. The coverage planner divided the grass area into parallel lines.

4.3 Watering Logic and Intelligence

The watering subsystem was arguably the most innovative element. It read soil-moisture sensors and weather forecasts, and if rain was predicted within twelve hours or the rain sensor was wet, watering was skipped entirely.

Otherwise, the pump activated zone by zone until target moisture was reached. This closed-loop approach reduced water consumption by 30% compared to a conventional timer-based system in side-by-side trials.

5.1 App Features

The Flutter application had both manual and automatic modes, a live map displaying the position of the robot, watering and cutting schedules, as well as alerts regarding the water and battery levels and an option to update the firmware. The interface was intentionally simplified to bring users confidence and clarity; user testing showed that people wanted simplicity over complexity.

5.2 Communication Reliability

Bluetooth Low Energy is used to manage the early provisioning phase and local control, while Wi-Fi is assigned to link the robot with the cloud, thus allowing remote control. The MQTT with TLS protocol is used for transmission.

In addition, the application was able to keep the latency for manual commands at less than 150 ms, which is a low enough value for the application to be considered responsive in comparison with other similar applications.

6.1 Testing Methodology

We conducted unit testing on the firmware modules, hardware-in-the-loop testing on the motor controller, and carried out field testing for 100 hours in a 400 m² lawn and a 40 m² garden over three seasons. During the testing, we measured various parameters including coverage, time involved, water consumption, obstacle detection rate, and app performance.

6.2 Measured Results

6.3 User Testing

Over a period of two weeks, ten different homeowners were involved in testing out the robot. The homeowners reported that their time on lawn and garden care was reduced by 70%. The main improvement requested by the users was a larger container for water, indicating the high value of the robot's watering function.

• In gardens, there was a GPS multipath effect that resulted in oscillations in GPS position. We managed to solve the issue by applying RTK correction and sensor fusion. However, dense foliation in trees continues to pose a problem that we are solving with visual odometry.
• It was hard to get the water pump primed reliably. We solved this issue by adding a self-priming pump with a check valve eliminating dry-run failures.
• Blade clogging occurred with wet grass. We increased blade speed and added a deck-cleaning routine triggered after wet sessions.
• End-to-end ownership accelerated debugging. Because the same team built hardware, firmware, and app, we could trace issues across layers in hours rather than weeks.
• Safety must be designed in, not added on. The blade kill switch and tilt sensor were integrated from the first prototype, not retrofitted.

This case demonstrates that a small multi-disciplinary team can design an entire autonomous gardening robot, which encompasses mechanical design, PCB making, and embedded firmware, along with mobile and cloud services.

Our application of E-E-A-T principles, including expertise through systematic engineering, experience through field testing, authority through compliance with safety standards, and reliability through honest reporting allowed us to create a working prototype.

The solution is now ready for the design for manufacturing and consumer trials.