Project

# Title Team Members TA Documents Sponsor
55 HydroFlora ( A Context-Aware Watering Can )
 Charis Wang
Delilah Dzulkafli
Idris Ispandi
 Mingrui Liu design_document1.pdf
final_paper1.pdf
photo1.png
presentation1.pptx
proposal1.pdf
video1.mp4
# Team Members:

Idris Ispandi (mm120) Delilah Dzulkafli (delilah5)

# Problem:

Many people care for multiple houseplants with different watering needs, but watering is typically done by intuition and inconsistent habits. Because plant type, pot size, soil type, and moisture all affect how much water a plant actually needs, manual watering often results in overwatering or underwatering. Overwatering can lead to root rot, fungus gnats, and wasted water, while underwatering causes plant stress, slowed growth, and wilting. Existing reminders or generic schedules don’t adapt to real-time soil conditions, and fully automated irrigation systems can be too expensive, complex, or impractical for small indoor plant collections. There is a need for a simple, low-effort tool that helps users deliver the correct amount of water per plant based on measured soil dryness and plant/pot-specific requirements, without requiring a permanent installed system.

# Solution:

In order to maintain optimal conditions for plants, we propose a smart watering can. The watering can will have two working parts: the MCU connected to a water pump (on the watering can), and the modular sensing unit (on the plants pot). The idea is that when you get a new plant, you input to the MCU the type of the plant, and the recommended amount of water the plant will be stored. The sensor unit will constantly broadcast the readings so when you pick up the watering can it will tell you which plant is in need of water based on the previous watering logs. You select the plant and go to the respective pot and press dispense and the MCU will tell the pump to dispense the needed amount of water = Recommended moisture level - current moisture level. This way, we can ensure that each plant has the most optimal amount of water needed to grow.

# Solution Components:

- ## Subsystem 1 (Water Dispensing Unit):
Components: Peristaltic Liquid Pump with Silicone Tubing

Driven by the MCU, this unit is responsible for dispensing the required amount of water. This will be placed in the watering can.
[https://www.digikey.com/en/products/detail/adafruit-industries-llc/1150/5638299](url)


- ## Subsystem 2 (Sensor Node):
Components: Capacitive Soil Moisture Sensor SKU:SEN0193, ESP32-C3-WROOM-02, battery and regulator

This unit will have a sensor that will be attached to the plant to measure the soil moisture, and the readings will be transmitted to the main control unit periodically via WiFi/Bluetooth (tradeoffs are still being weighed).
[https://www.digikey.com/en/products/detail/dfrobot/SEN0193/6588605](url)


- ## Subsystem 3 (Main Control Unit):
Components: ESP32-C3-WROOM-02, LCD display, buttons

This acts as the device's main control unit. When the user chooses a plant by clicking the buttons (pre-defined for prototype), the LCD will display what plant the user has selected. It is then responsible for determining the amount of water to be pumped out based on the readings received from the plant’s moisture sensor.

- ## Subsystem 4 (Physical Build):

Components: A watering can

The MCU will be attached at the top of the watering can with a waterproof enclosure. This will be discussed with the machine shop for further opinions.

- ## Subsystem 5 (Power Management):
Components: Rechargeable Battery for MCU and LiPo battery for sensor unit

This subsystem provides rechargeable power and stable 3.3 V for our electronics. The pump, sensor node, and the control unit will have separate power systems.


# Criterion For Success:
This project will be considered successful if the system can reliably receive soil moisture data from multiple sensor nodes (sensor readings are stable under fixed conditions), accurately determine which plant needs watering, and dispense water within 10% of the target volume while maintaining a stable operation:


- Sensor nodes have a stable, repeatable moisture value where moisture reading increases after watering and decreases over time

- Sensor nodes can successfully broadcast soil moisture readings to the main control unit.

- Accurately determine which plant needs watering based on moisture level

- Pump dispenses water within 10% of target volume

- Different plants result in different dispense volume

- Sensor node operates continuously for >24 hours on battery without recharge

- Electronics remain functional after watering

Oxygen Delivery Robot

Aidan Dunican, Nazar Kalyniouk, Rutvik Sayankar

Oxygen Delivery Robot

Featured Project

# Oxygen Delivery Robot

Team Members:

- Rutvik Sayankar (rutviks2)

- Aidan Dunican (dunican2)

- Nazar Kalyniouk (nazark2)

# Problem

Children's interstitial and diffuse lung disease (ChILD) is a collection of diseases or disorders. These diseases cause a thickening of the interstitium (the tissue that extends throughout the lungs) due to scarring, inflammation, or fluid buildup. This eventually affects a patient’s ability to breathe and distribute enough oxygen to the blood.

Numerous children experience the impact of this situation, requiring supplemental oxygen for their daily activities. It hampers the mobility and freedom of young infants, diminishing their growth and confidence. Moreover, parents face an increased burden, not only caring for their child but also having to be directly involved in managing the oxygen tank as their child moves around.

# Solution

Given the absence of relevant solutions in the current market, our project aims to ease the challenges faced by parents and provide the freedom for young children to explore their surroundings. As a proof of concept for an affordable solution, we propose a three-wheeled omnidirectional mobile robot capable of supporting filled oxygen tanks in the size range of M-2 to M-9, weighing 1 - 6kg (2.2 - 13.2 lbs) respectively (when full). Due to time constraints in the class and the objective to demonstrate the feasibility of a low-cost device, we plan to construct a robot at a ~50% scale of the proposed solution. Consequently, our robot will handle simulated weights/tanks with weights ranging from 0.5 - 3 kg (1.1 - 6.6 lbs).

The robot will have a three-wheeled omni-wheel drive train, incorporating two localization subsystems to ensure redundancy and enhance child safety. The first subsystem focuses on the drivetrain and chassis of the robot, while the second subsystem utilizes ultra-wideband (UWB) transceivers for triangulating the child's location relative to the robot in indoor environments. As for the final subsystem, we intend to use a camera connected to a Raspberry Pi and leverage OpenCV to improve directional accuracy in tracking the child.

As part of the design, we intend to create a PCB in the form of a Raspberry Pi hat, facilitating convenient access to information generated by our computer vision system. The PCB will incorporate essential components for motor control, with an STM microcontroller serving as the project's central processing unit. This microcontroller will manage the drivetrain, analyze UWB localization data, and execute corresponding actions based on the information obtained.

# Solution Components

## Subsystem 1: Drivetrain and Chassis

This subsystem encompasses the drive train for the 3 omni-wheel robot, featuring the use of 3 H-Bridges (L298N - each IC has two H-bridges therefore we plan to incorporate all the hardware such that we may switch to a 4 omni-wheel based drive train if need be) and 3 AndyMark 245 RPM 12V Gearmotors equipped with 2 Channel Encoders. The microcontroller will control the H-bridges. The 3 omni-wheel drive system facilitates zero-degree turning, simplifying the robot's design and reducing costs by minimizing the number of wheels. An omni-wheel is characterized by outer rollers that spin freely about axes in the plane of the wheel, enabling sideways sliding while the wheel propels forward or backward without slip. Alongside the drivetrain, the chassis will incorporate 3 HC-SR04 Ultrasonic sensors (or three bumper-style limit switches - like a Roomba), providing a redundant system to detect potential obstacles in the robot's path.

## Subsystem 2: UWB Localization

This subsystem suggests implementing a module based on the DW1000 Ultra-Wideband (UWB) transceiver IC, similar to the technology found in Apple AirTags. We opt for UWB over Bluetooth due to its significantly superior accuracy, attributed to UWB's precise distance-based approach using time-of-flight (ToF) rather than meer signal strength as in Bluetooth.

This project will require three transceiver ICs, with two acting as "anchors" fixed on the robot. The distance to the third transceiver (referred to as the "tag") will always be calculated relative to the anchors. With the transceivers we are currently considering, at full transmit power, they have to be at least 18" apart to report the range. At minimum power, they work when they are at least 10 inches. For the "tag," we plan to create a compact PCB containing the transceiver, a small coin battery, and other essential components to ensure proper transceiver operation. This device can be attached to a child's shirt using Velcro.

## Subsystem 3: Computer Vision

This subsystem involves using the OpenCV library on a Raspberry Pi equipped with a camera. By employing pre-trained models, we aim to enhance the reliability and directional accuracy of tracking a young child. The plan is to perform all camera-related processing on the Raspberry Pi and subsequently translate the information into a directional command for the robot if necessary. Given that most common STM chips feature I2C buses, we plan to communicate between the Raspberry Pi and our microcontroller through this bus.

## Division of Work:

Given that we already have a 3 omni wheel robot, it is a little bit smaller than our 50% scale but it allows us to immediately begin work on UWB localization and computer vision until a new iteration can be made. Simultaneously, we'll reconfigure the drive train to ensure compatibility with the additional systems we plan to implement, and the ability to move the desired weight. To streamline the process, we'll allocate specific tasks to individual group members – one focusing on UWB, another on Computer Vision, and the third on the drivetrain. This division of work will allow parallel progress on the different aspects of the project.

# Criterion For Success

Omni-wheel drivetrain that can drive in a specified direction.

Close-range object detection system working (can detect objects inside the path of travel).

UWB Localization down to an accuracy of < 1m.

## Current considerations

We are currently in discussion with Greg at the machine shop about switching to a four-wheeled omni-wheel drivetrain due to the increased weight capacity and integrity of the chassis. To address the safety concerns of this particular project, we are planning to implement the following safety measures:

- Limit robot max speed to <5 MPH

- Using Empty Tanks/ simulated weights. At NO point ever will we be working with compressed oxygen. Our goal is just to prove that we can build a robot that can follow a small human.

- We are planning to work extensively to design the base of the robot to be bottom-heavy & wide to prevent the tipping hazard.