EnviroBot Documentation

Competition: EnviroBot Environmental Robotics Challenge | Strategy: RC-first, autonomy as stretch goal

System Overview

EnviroBot is a two-component system:

1. Robot — ESP32-based differential-drive rover. Driven entirely by remote control — a phone joystick page served over the robot's own WiFi AP. Collects 12 environmental measurements (4 water turbidity + 8 soil moisture) and outputs structured JSON.

2. Web Platform — Next.js application on Cloudflare Workers (envirobot.yerielph.workers.dev). Documents the project, replays run data in 2D/3D (Visualiser), browses the firmware source (Code Browser) and CAD model (CAD Viewer), and lets the team edit all of it from Content Admin — see Platform Overview.

Judged data output is arduino/tools/live_plot.py — a matplotlib live table + labelled charts on a connected laptop (a rulebook §4.6 approved format), plus a samples.csv. Serial output is the always-on fallback. See Operating Guide.

Competition Quick Reference

Parameter Value
Testing Day Thursday 30 July (W9) — inspection + measurement run + robot assessment
Closing Night Friday 31 July, 5–9pm — case competition presentation
Run time limit 8 minutes maximum (−5 pts if exceeded)
Required measurements 12 total: 4 water turbidity + 8 soil moisture
Arena Square, 1500 × 1500 mm, four 750 × 750 mm terrain quadrants
Max score 100 points across 6 judging categories

Scoring Summary

# Category Points
1 Technical Measurement Performance 30
2 Data Output & Visualisation 10
3 Build Quality & Workmanship 5
4 Innovation & Engineering Design 10
5 Robot Aesthetics 5
6 Closing Night Case Competition 40
Total 100

Note: The official rulebook contains a scoring inconsistency in section headers. The table above totals correctly to 100 and is treated as authoritative (confirmation requested from organisers). Cat 6 (Case Competition, 40 pts) is the single highest-weight category — presentation prep is not optional.

Deductions

Infraction Penalty
Prohibited component installed −10 pts or disqualification
Run exceeds 8-minute limit −5 pts
Pre-loaded or hardcoded sensor data Cat 1 and Cat 2 zeroed
Arena surface damage −5 pts per incident

Why RC-First

The rulebook explicitly permits remote-controlled robots, and that is what this robot is — there is no autonomous mode in the firmware. With no wheel encoders and no IMU, coordinate-accurate autonomous navigation was never achievable, so the effort went into the path that actually produces accurate, correctly-labelled data: an operator driving and tagging each sample’s sector by eye. An ultrasonic collision guard backs the operator up by cutting forward drive before an impact.

Arena Layout

        Square arena, 1500 x 1500 mm, raised dark timber walls
     +y  +---------------------------+---------------------------+
      ^  |  S1: URBAN                |  S2: FIELD                |
      |  |  (grey concrete/asphalt)  |  (green turf)             |
      |  |     *  soil    <> water   |    <> water    *  soil    |
      |  |          *  soil          |          *  soil          |
         +---------------------------+---------------------------+  --> +x
         |  S3: DESERT               |  S4: STONE                |
         |  (tan sand)               |  (grey gravel/cobble)     |
         |    <> water    *  soil    |     *  soil    <> water   |
         |          *  soil          |          *  soil          |
         +---------------------------+---------------------------+

Origin = arena centre, so each quadrant is 750 x 750 mm.
<> = water slot (RECESSED - a wheel trap, never drive over one)
*  = soil disc
No walls between quadrants - the boundary is the terrain surface change.
The four outer walls are the only physical barriers.
Zone positions are spread out deliberately and are not published in advance.
Sector Position Terrain
S1 Top-left Urban
S2 Top-right Field
S3 Bottom-left Desert
S4 Bottom-right Stone

Confirm the quadrant→terrain mapping on Testing Day and update TERRAINS[] in data_logger.cpp if the arena is laid out differently. The operator picks the sector on the RC page, where each button carries its terrain name — so a mis-numbered table mislabels every sample in that quadrant.

Documentation Map

Web Platform

Section Contents
Platform Overview Stack, route map, content pipeline, deploy, secrets
Visualiser /viz — load a run, 2D/3D replay, playback controls, payload logs
Code Browser /code — public firmware source viewer, copy/download
CAD Viewer /design — 3D model preview, supported formats
Content Admin /admin — login, editing docs/code/design/runs, API reference

Robot Hardware & Firmware

Section Contents
Hardware Real BOM, pin assignments, power rails, turbidity divider + ultrasonic wiring
Operating Guide Flashing, boot, run clock, the RC run procedure, live data station, troubleshooting
Navigation RC procedure, collision guard, position estimation limits
Sensors Turbidity (voltage divider), soil moisture, ultrasonic collision guard
Calibration Pre-competition calibration for every constant in config.h
Runtime Config Edit tuning values from the test page without recompiling
RC & Communications WiFi AP, HTTP protocol, RC page, diagnostics page
JSON Schema Frozen run data format — visualiser depends on exact fields

Competition

Section Contents
Scoring Full rubric, deductions, per-category strategy
Competition Guide Day 1 pitch, Day 2 prep plan, argument template
Inspection Checklist Pre-run and pre-presentation checklists
Rules Key competition rules from the official rulebook
Next →