☰

How to Make Almost Anything

My journey through the MIT course

Week 11: Interface and Application Programming

Assignment: write an application that interfaces a user with an input &/or output device that you made

1. Introduction & Project Goal

This project is an automated irrigation system designed to deliver precise amounts of water to distinct agricultural or garden zones based on real-time soil moisture readings. The primary goal is to optimize water usage, improve plant health by preventing over/under-watering, and automate a crucial aspect of plant care. The system, as of Spiral 4, supports multi-zone monitoring, configurable watering parameters, and basic fail-safe mechanisms.

2. System Architecture

The system is comprised of several interconnected modules:


graph TD
    SM1[Soil Moisture Sensor ESP32 - Zone A] -- HTTP POST JSON --> FAS[FastAPI Server]
    SM2[Soil Moisture Sensor ESP32 - Zone B] -- HTTP POST JSON --> FAS
    FAS -- HTTP GET JSON --> CCU[Central Control Unit (ESP32/RPi)]
    CCU -- Serial Commands --> PUMP[Irrigation Pump ESP32]

3. Component Breakdown

A. Soil Moisture Sensing Module

B. Irrigation Pump Module

C. FastAPI Server

D. Central Control Unit (CCU)

4. System Logic & Operation

A. Data Acquisition & Validation

  1. Soil Sensor Modules autonomously read sensor values, calculate moisturePercent, and POST a JSON payload (including sensorID, rawValue, moisturePercent, and timestamp) to the FastAPI server.
  2. The CCU, at a configurable interval (e.g., every 10-30 minutes), iterates through its list of configured zones.
  3. For each zone, the CCU makes a GET request to the FastAPI server for the latest data associated with the zone's sensorID.
  4. The CCU validates the received data:
    • Freshness: Checks the timestamp. If data is older than a defined threshold (e.g., 2-3 times the sensor's reporting interval), it's considered stale.
    • Validity: Checks if rawValue and moisturePercent are within expected operational ranges (e.g., 0 <= moisturePercent <= 100).

B. Zone Management & Configuration

The system supports multiple distinct irrigation zones, each with its own settings. Configuration is managed via a JSON file (e.g., config.json) on the CCU, structured similar to this:


[
  {
    "zoneID": "Zone1_Vegetables",
    "sensorID": "SensorA_Veg",
    "triggerMoisturePercent": 30,
    "targetVolumeML": 500,
    "pumpPeriodMicroseconds": 1200,
    "mL_per_microstep": 0.000625
  },
  {
    "zoneID": "Zone2_Herbs",
    "sensorID": "SensorB_Herbs",
    "triggerMoisturePercent": 40,
    "targetVolumeML": 250,
    "pumpPeriodMicroseconds": 1500,
    "mL_per_microstep": 0.000625
  }
]

C. Irrigation Decision Logic (executed per zone by CCU)

For each zone:

  1. Fetch and validate sensor data as described above.
  2. IF currentMoisturePercent < zone.triggerMoisturePercent AND data is fresh AND data is valid:
    1. Log decision to water.
    2. Calculate numberOfMicrosteps = zone.targetVolumeML / zone.mL_per_microstep.
    3. Send motor_enable\\n command to Pump ESP32.
    4. Send steps <calculated_numberOfMicrosteps> <zone.pumpPeriodMicroseconds>\\n command.
    5. (Optional: Wait for ACK\\n or DONE\\n from pump, or use a timeout).
    6. Send motor_disable\\n command to Pump ESP32 (either immediately after this zone or after the entire irrigation cycle for all zones).
  3. ELSE (condition not met, or data invalid/stale):
    1. Log reason for not watering (e.g., "Moisture sufficient for Zone1", "SensorA_Veg data stale").

D. Pump Control Mechanism

The CCU translates the desired water volume into precise motor commands. The Pump ESP32 focuses solely on executing these commands, handling the low-level motor stepping and timing. The blocking nature of the steps command on the Pump ESP32 is architecturally handled by keeping the CCU as a separate, non-blocked unit.

E. Fail-Safe Behaviors (Implemented in Spiral 4)

5. Communication Interfaces

A. Soil Sensor to FastAPI Server

B. CCU to FastAPI Server

C. CCU to Pump Module

6. Current Project Status (End of Spiral 4)

7. Code & Schematics

All source code for the Soil Moisture Sensor ESP32 firmware, Pump Control ESP32 firmware, FastAPI Server application, and the Central Control Unit logic can be found in my project repository:

(Consider embedding a Fritzing diagram or a clear photo of your setup here.)

8. Challenges & Learnings (Examples)

9. Next Steps / Future Development

Beyond the current Spiral 4 status, planned enhancements include:

Vertical Linear Actuator

1. Introduction & Overview

This project is an automated vertical linear actuator designed to precisely control the height of an LED grow light panel for an indoor garden system. The primary goal is to maximize the amount of plants that the light handle and optimize light distribution. The system employs a dual NEMA 17 stepper motor configuration, controlled by an ESP32 microcontroller, allowing for an extended range of motion and fine-tuned positioning.

The development followed a spiral methodology, incrementally building and testing functionality from basic motor control to coordinated multi-axis movement.

2. System Design & Components

The actuator is designed with two stepper motors working in tandem along a single vertical axis.

2.1. Mechanical Design

Dual-Stepper Configuration:

Linear Motion: Both motors drive lead screws (e.g., repurposed Prusa MK3 Z-axis TR8*8 lead screws) to convert rotational motion into linear motion. The entire assembly slides along a rigid linear rail to ensure stability and smooth travel.

Payload: A sideways-mounted LED grow light panel.

Cable Management: A critical consideration due to M2 and the LED panel moving with M1. A flexible drag chain or a carefully managed service loop is necessary to protect wiring.

2.2. Electronics Hardware

2.3. Software Design (Control System)

The control software is written in C++ using the Arduino framework for the ESP32.

Development Approach: A spiral development model was used to incrementally build features:

Key Features:

Communication: USB Serial for commands and feedback.

3. Key Software Functionality & Control

The system is controlled via serial commands sent to the ESP32.

3.1. Homing (home 1, home 2, home_all)

A critical function to establish a known reference point (zero position) for each motor.

3.2. Position Control

Direction (dir <motor> <0|1>): Sets the intended physical direction of movement (0 for UP, 1 for DOWN). The software handles any necessary inversion of the DIR pin logic for specific motors.

Relative Moves (steps <motor> <count> <period_us>): Moves the specified motor by a relative number of steps at a given step period.

Continuous Moves (speed <motor> <period_us>): Runs the specified motor continuously at a given step period until a stop command.

Position Querying:

Absolute Panel Positioning (move_panel_to <target_abs_mm>): This command moves the LED panel to a specific absolute vertical height from the base of the system.

The absolute panel position is calculated as: PanelPos_mm = (M1_currentPositionSteps / M1_steps_per_mm) + (M2_currentPositionSteps / M2_steps_per_mm)

The control logic determines the necessary movements for M1 and M2 to achieve this target, respecting individual motor software limits. Motors are moved sequentially.

Panel Position Query (get_panel_pos_mm): (Should be get_panel_pos_mm or similar, if get_pos_mm all doesn't give the combined value). This command would report the calculated absolute height of the LED panel.

3.3. Calibration & Safety

Steps per Millimeter (set_steps_per_mm <motor> <value>): Allows calibration of how many microsteps correspond to 1mm of linear travel for each motor. This is crucial for accurate positioning in real-world units. Depends on lead screw pitch and microstepping settings.

Example Calculation: For a TR8*8 lead screw (8mm travel per revolution) and a 1.8° NEMA 17 motor (200 full steps/revolution) with 1/128 microstepping: Steps_per_mm = (200 full_steps/rev * 128 microsteps/full_step) / 8 mm/rev = 3200 microsteps/mm

Software End-Stops (Iteration 3): Constants like M1_MAX_TRAVEL_MM and M2_MAX_TRAVEL_MM define the maximum permissible travel for each motor from its home position. Movement commands check against these limits (if the motor is homed) to prevent over-travel and potential mechanical damage.

3.4. Motion Smoothing (Iteration 4)

To prevent missed steps, reduce mechanical stress, and achieve smoother operation, especially when moving the significant mass of M2 and the LED panel, acceleration and deceleration (ramping) are implemented. This involves gradually changing the step period at the beginning and end of moves, rather than instantly starting/stopping at full speed.

(Describe your chosen method briefly: e.g., Linear Ramp or AccelStepper library integration).

4. Challenges & Learning

(This is a section for you to personalize heavily! Here are some potential points you might have encountered or learned from):

5. Future Work & Potential Improvements

Advanced Coordinated Motion: Implement more sophisticated algorithms for distributing movement between M1 and M2 when move_panel_to is called (e.g., to minimize wear, maximize speed, or keep M2 in a preferred part of its range). Potentially simultaneous movement of M1 and M2 if using a library like AccelStepper.

6. Code & Visuals

The complete Arduino sketch for the ESP32 controller can be found here:[Link to your Git repository or code file]

(Embed key code snippets here if desired, e.g., the homeMotor function or the move_panel_to logic).


    // Key code snippets can be embedded here.
    // For example:
    // void homeMotor(int motorNum) {
    //   // ... homing logic ...
    // }

Visuals

Irrigation System

Image 1 Image 2 Image 3 Image 4 Image 5 Image 6 Image 7