Gantry Electronics & Firmware

Everything electronic rides on the gantry in a single sealed enclosure bolted to one of the X columns, so it moves with the machine and the motor leads stay short. A 24 V supply feeds the DRV8825 motor rails directly, while two buck converters step it down to 12 V for the solenoid valve side and 5 V for the logic, the relays and the servos.

The ESP32 and the four stepper drivers sit on a custom PCB mounted over the Raspberry Pi, with screw terminals for the motors and a row of headers for the four limit switches. Bundled cables climb the column to the motors and sensors, and drag chains carry them, along with the irrigation hose, as the carriage moves.

All four motors are 200-step NEMA17s at 1/16 microstepping: 3,200 microsteps per turn. On X and Y a 20-tooth GT2 pulley moves the belt 40 mm per turn, so one millimetre is 80 steps. Z runs on a T8 lead screw, 2 mm pitch with four starts, for 8 mm per turn and 400 steps per millimetre. That's five times finer, and the screw holds the camera's height when the drivers let go.

A MOVE scales each axis's speed and acceleration by its share of the longest leg, so X, Y and Z start and arrive together in a straight line. The two X motors get identical targets and profiles, which is what keeps the 2 m cross-beam square as it travels.

Pi and ESP32 #1 speak plain text, one line per message. The Pi sends a command with key=value arguments, like MOVE x=1050 y=300 z=50 speed=150, and the ESP32 answers OK with a small JSON body or ERR with a reason. The whole vocabulary is eleven commands: PING, MOVE, HOME, POS, STOP, EN, RELAY, LIMITS, TOF, SERVO and SERVO_GET.

MOVE is asynchronous. The ESP32 accepts it with OK, keeps stepping, and sends a separate DONE line with the final position when every motor has stopped. Because its loop keeps reading serial while moving, the Pi can ask for TOF readings mid-move, and each answer is stamped with the current X, Y and Z. That's how the watering pass measures plant heights in one continuous sweep instead of stopping over every plant. ESP32 #2 uses the same style (PING, READ sensor=all) on the UART.

On the Pi, one thread owns each serial port behind a lock, so only one command is ever in flight. Quick commands time out after 10 seconds and moves after 300, so a silent ESP32 raises an error instead of hanging a session forever.

HOME runs Z, then Y, then X, so the camera is lifted clear before anything moves sideways. Each axis searches toward its switch at 90 mm/s, backs off 3 mm at 6 mm/s so the switch releases cleanly, and zeroes there. X homes both motors together, and each stops on its own switch, which squares the gantry every time it's homed.

The limit cables run metres alongside stepper wiring, and early on motor noise was enough to fake a switch hit. Every switch read is now debounced: the line has to stay low for 5 ms before it counts. During a normal MOVE a confirmed hit stops the axis, latches an emergency stop and reports ERR limit_triggered with the axis and position, which the Pi treats as fatal for the session.

The watering pass ties both ESP32s together. The ToF sweep gives the tallest plant, ESP32 #2 gives soil moisture from all three probes, and an interval type-2 fuzzy controller on the Pi turns those into a single duration. It has five growth stages from seedling to production, five moisture levels from very dry to very wet, a 25-rule table and Karnik–Mendel type reduction, producing 0 to 120 seconds of water. The Pi then switches the pump on through ESP32 #1 and steps along the bed, opening the solenoid for that long at each stop. If the inputs ever fall outside every membership function, the answer defaults to zero: a glitched sensor can't flood the bed.