Open source

Open-sourcing our sargassum detection training kit

Sargassum blooms are getting worse along Atlantic coastlines, and one basic question turns out to be surprisingly unsolved: if you have a low-cost sensor drifting in the water, how does it know whether it's sitting inside a sargassum mat or in open water?

Almost everyone working on sargassum detection looks down. Satellites and aircraft use near-infrared imagery to spot mats from above, and that work is well published. Almost nobody looks up from inside the water, at close range, with cheap RGB hardware. We couldn't find a published version of that approach, so we built one and are open-sourcing it: a training kit that turns a low-cost drifter into a sensor you can label, train, and test in a single field session.

Quick answer: We've open-sourced the training loop behind our sargassum drifter under Apache-2.0: a web console for labeling readings, a small on-device classifier, and the firmware to run it. Treat it as a tool and a method to test, since the model hasn't been validated on a real sargassum bloom yet; that field test is still ahead of us. If you work on marine sensing, drone or buoy platforms, or citizen science, we'd like your help pushing it further.

Why build this instead of using satellite data?

Satellite and aerial remote sensing answer "where are the mats" at a coarse scale, using near-infrared bands that pick up the plant's reflectance signature from above. That's useful for regional tracking, but it answers a different question than the one a single deployed sensor needs answered: is this specific unit, right here, right now, inside a mat or in open water. That answer has to come from hardware cheap enough to deploy in numbers and lose without it hurting.

We looked for prior work on in-situ, submerged, visible-light detection at this price point and didn't find much. So we're treating this as an open sensing problem rather than a solved one, and the fastest way we know to make progress on an open problem is to hand the tool to more people who can run it in more places.

What's in the repo

The kit covers the training loop we've been using ourselves. It does not include the whole Hover platform. Three pieces:

  • A web training console. Load a session's sensor readings, label spans as in-mat, open-water, or out-of-water, and train a model against them.
  • The model. A small random forest trained on chromaticity features (more on that below) that runs directly on the drifter's microcontroller after training.
  • Training firmware for an ESP32-S3 drifter with a 4-point RGB sensor array. Source only: you compile and flash it yourself.

Left out on purpose: the LoRa mesh networking stack and the rest of the Hover platform. This release is scoped narrowly to the sensing and training loop.

How the training loop works

The workflow is: label a session's readings in the console, train a model in the cloud, push the compiled model back to the board, and watch it classify readings live. A full lap of that loop fits inside one field outing.

Two implementation details matter here.

It classifies on chromaticity, not raw brightness. Underwater ambient light shifts constantly with depth, cloud cover, and time of day, so raw RGB brightness is a moving target. Chromaticity normalizes color against brightness, and that's what lets the model track the green-brown-versus-blue shift a sargassum mat produces, rather than just tracking how sunny it happens to be.

The model refuses to lie to you. The training pipeline has hard floors built in. It won't train on fewer than 40 labeled samples. It runs a held-out separability check before accepting a model at all, and if the features don't separate in-mat from open-water in your data, it says so instead of handing back a model anyway. It also flags results that look suspiciously good on too little data, since a high score on a thin dataset usually means the model memorized your specific readings rather than learned anything general. The accuracy number shown during training comes from the same evaluator code that runs on the board, so what you see in the console is what the hardware does in the field.

We built those checks in because we wanted a tool that couldn't be talked into a confident answer on bad data. For the same reason, we're not making accuracy claims here. The model hasn't been run against a real sargassum bloom yet. That field test is coming; until it happens, treat this kit as a working method rather than a finished result.

How to get involved

This is a genuinely open problem, and we'd rather have more people testing it than keep iterating alone. A few ways to help:

  • Run the kit in a different location and share what you find, good or bad.
  • Add a near-infrared channel and see if it improves separability over RGB alone.
  • Try a different detection target with the same training loop.
  • Port the firmware to a different board.
  • Open an issue if something doesn't build, doesn't flash, or doesn't make sense.

The repo is Apache-2.0 licensed. https://github.com/hoverhq/sargassum-drifter

FAQ

Is this the full Hover platform?

No. This release covers the training console, model, and training firmware only. The mesh networking and the rest of the Hover platform aren't included.

Has the model been validated on a real sargassum bloom?

Not yet. That field test is still ahead of us. Treat everything in this kit as a method worth testing, since it hasn't been proven as a detector in the field.

What hardware do I need to run it?

An ESP32-S3 board with a 4-point RGB sensor array, matching what the training firmware targets. The repo has build and flash instructions.

Why RGB instead of near-infrared?

Cost and simplicity, mainly. RGB sensors are cheap and easy to source. We'd like to see someone add an NIR channel and compare results.

What license is this under?

Apache-2.0, including the patent grant.

Can I use this for something other than sargassum?

Yes. The training loop of label, train, push to board, run isn't sargassum-specific. If you swap in a different detection target, let us know how it goes.

Who do I contact if I want to collaborate on the marine-science side?

Open an issue on the repo, or reach out through hoverfeed.com. We're specifically looking for marine researchers, sensor and drone operators, and citizen scientists to test this in the field.

Building on this?

We'd like to hear from marine researchers, sensor and drone operators, and citizen scientists testing the kit in the field.