Firmware for the physical course elements Team Inspiration builds for the Maritime RobotX Challenge 2026 — the props the vehicles are tested against, not the vehicles themselves.
| Element | Folder | Used for |
|---|---|---|
| RoboBuoy light beacon | buoy_beacon/ |
Mission Task 1, Safe Passage |
An ESP32-C3 driving the light beacon on a RoboBuoy, built to the RoboNation RoboBuoy build guide. It cycles the five beacon states Task 1 defines and nothing else.
| Board | uPesy ESP32-C3 Mini |
| FQBN | esp32:esp32:upesy_esp32c3_mini |
| Library | Adafruit_NeoPixel |
| Panel | 64 px on GPIO 5 — the top beacon, visible to the UAV |
| Strip | 144 px on GPIO 6 — the side beacon, visible to the USV |
| Button | GPIO 7, INPUT_PULLDOWN |
OFF → flashing RED → flashing GREEN → flashing BLUE → solid BLUE, then back
to OFF. Handbook §3.3.2: flashing red passes to the boat's starboard,
flashing green to port, flashing blue is the ENTRY buoy, solid blue is
the EXIT buoy, and an unlit buoy is an obstacle that may be passed either
side.
Solid red and solid green are deliberately not in the cycle. They are not competition states, and including them meant six presses to reach the one you wanted plus a real chance of recording training data in a state the course will never show.
Flash cadence is 1 s on, 1 s off. The handbook specifies this exactly. Do not change it — the UAV's classifier keys off the flash.
It stays in when pushed in and stays out when pushed out, so the firmware advances on any settled edge — in and out are each one deliberate actuation and each moves one state. Advancing only on the press edge makes every second actuation do nothing.
The original bug here was a missing debounce, not the edge handling: a
bouncing contact advanced an unpredictable number of states, which is why red
and green appeared to be missing from the cycle. They were always in the table,
they just could not be selected reliably. DEBOUNCE_MS is 50.
115200 baud. It prints on every change:
RoboBuoy beacon ready - press to cycle
state 0 OFF
state 1 RED flash
Counting button presses in sunlight is how the wrong state ends up in a dataset.
At full brightness the beacon draws roughly 4 A at 5 V — 208 pixels (64 + 144) at about 20 mA per lit colour channel.
A laptop USB port supplies 0.5–0.9 A. Plugging a fully assembled buoy into a laptop has already shut a machine down and destroyed the port. Power the LEDs from a supply rated for the real load, with only the data line and a shared ground going to the ESP32 — never route LED current through the dev board's 5 V pin, whose traces are good for well under an amp.
If the beacon lights a garbage colour at power-up and the button does nothing, that is the signature of the ESP32 not booting: the WS2812s hold whatever random state they powered up in until firmware clears them. Check the supply before suspecting the firmware. A discharged 12 V battery sags under the surge even when its resting voltage looks fine.
arduino-cli ships inside the Arduino IDE at
resources/app/lib/backend/resources/arduino-cli.exe; it is not on PATH.
arduino-cli compile --fqbn esp32:esp32:upesy_esp32c3_mini buoy_beacon
arduino-cli upload -p COM21 --fqbn esp32:esp32:upesy_esp32c3_mini buoy_beaconReplace COM21 with whatever the board enumerates as — it appears as USB
Serial Device, not a Bluetooth COM port.
To confirm the flash took, you must reset the board while already connected to the serial port. The upload's own hard reset fires the boot banner before you can attach, so opening the port afterwards shows nothing and looks like a failure. Pulse RTS, or press reset, with the monitor already open.
Set DRIVE_STRIP to 0. The handbook says only one beacon is lit at a time, and
at Core Tier the red/green lights are the side-visible ones — so a buoy
showing both beacons does not look like the real thing from above.