Operation River Clean Up

The problem

The Pasig River runs about 25 km through Metro Manila. It is one of the world’s largest sources of ocean plastic, carrying an estimated 63,000 tonnes to the sea each year (Meijer et al., 2021). It is also a working waterway used by commuter ferries and cargo barges. Our need statement asked for a system that could identify, intercept and dispose of high-volume plastic waste without obstructing that navigation channel. We chose the Pasig over the Bagmati, Citarum and Yangtze with a weighted site-selection matrix, and mapped eleven stakeholders, from the Department of Environment and Natural Resources and the Philippine Coast Guard to ferry operators and residents.

My role

There were eight of us, and I was the group leader. I allocated roles, kept communication going across the team and with our lecturers, and led project management and validation.

Project management

I built and ran our 39-task plan in ProjectLibre, from the project brief on 7 October 2025 to the final individual submission on 23 January 2026. I treated the winter break as a planned buffer, a managed-contingency strategy: the life-cycle analysis and design-validation tasks ran alongside it instead of the plan pausing, and I kept everyone on the critical path with check-ins on WhatsApp and Teams.

Validation

I moved our focus from checking that the physics worked to validating the design against stakeholder needs, such as ferry access and operating time, and planned how each system requirement would be tested.

(opens full size)

Requirements

We wrote eight user requirements and six system requirements. The main ones:

Concept selection

We generated ideas by sketching, from nets hung from bridges to air-bubble barriers, then scored five concepts against seven weighted criteria: volume, access, wildlife, cost, safety, longevity and weather.

(opens full size)

We then settled six subsystem trade-offs:

The design

(opens full size)

Boats

Two 1.8 × 1.0 × 0.6 m marine-grade aluminium monohulls with a shallow draught, each driven by two 1.5 kW inboard motors behind meshes and steered by differential thrust.

Power

A 48 V, 15 kWh lithium iron phosphate battery in each boat. Below 60% charge, a boat overrides its navigation and returns to the drop-off for a battery swap.

Sensing and control

LiDAR detects obstacles and an AI camera identifies them. When a vessel approaches, the boats close up to occupy a single lane, and they stop their motors if it can’t pass.

Boom

Segmented, high-visibility HDPE links, 1 m long, that skim the top 0.5 m of water.

Collection and disposal

At the Manila Port drop-off, the boom pushes the catch onto bank-side conveyors that feed a bin for trucks. The plastic is dewatered and sorted there, then trucked to an existing licensed pyrolysis plant in Metro Manila rather than to a new plant on site, which kept capital cost, risk and development time down.

Safety and risk

A three-phase hazard analysis (extraction, collection and security), a legal and ethical risk matrix, and a safety architecture linking traffic, fire and structural sensors to automatic responses.

Cost

About £4.4 million per deployment: £1.2 m for the boats, £0.6 m for the boom, £0.9 m for collection and conveyors, £0.4 m for software, £0.5 m for electrical and control, and £0.8 m for installation, logistics and contingency.

(opens full size)

(opens full size)

Verification plan

We laid out the work as a V-model. The left side, from problem analysis down to subsystem design, was done in the module; the right side was planned. For each system requirement I set out how it would be tested: pool trials of propulsion and load carrying, camera tests on plastic objects, obstacle-avoidance trials in a safe private area, load and strength tests of the boom, and trial runs shadowed by rescue boats.

(opens full size)

Looking back

The structure worked. We covered every stage from need to verification plan, with real stakeholders and a functional–physical architecture, and the concept choice is robust: with all seven criteria weighted equally, the boom boats still win. But the analysis behind the headline numbers was thin, and some of it was wrong.

• Our requirements weren’t verifiable or traced. “About 30 m” and “about ≥80%” have no acceptance criteria, and 80% of what was never defined. We never built a matrix linking user requirements to system requirements: four of our eight user requirements had no system requirement under them. The offloading-signal requirement was “verified” by a test of something else (the battery-return function), and the force gauge from the early sketch that would have signalled a full boom was dropped. As validation lead, this is the gap I’d close first.
• We never sized the system against 10 tonnes a day. There’s no model of debris flux, capture efficiency, boom sweep width or operating hours. With about 2 hours of usable battery per sortie, even four sorties a day would need our two 1.8 m boats to bring back 2.5 tonnes each time. Our concept matrix also weighted volume lowest of the seven criteria, although collection volume was our headline need.
• The propulsion sums didn’t hold. We estimated 7.2 kN of thrust by dividing useful power by speed at 0.5 m/s. Momentum theory limits a 1.5 kW propeller to well under 1 kN, so the four motors would give roughly 2 kN in total, and we never estimated hull or boom drag to see what was needed. There were arithmetic slips too: 15 kWh ÷ 3 kW is 5 hours, not 4.1, and the boat mass adds up to 384 kg, not 370. We also didn’t consider that the Pasig is tidal and its flow reverses, although our concept relied on sailing upstream.
• The hazard analysis described a different system. Anchoring for a 1-in-50-year flood, a “40% clear central channel” and releasing the boom to protect its anchor all describe a fixed boom, not our towed one, so it wasn’t updated after we chose the concept. We also asked for “IALA-compliant navigation lights”, but vessel lights come under COLREGs; IALA buoyage (Region B in the Philippines) covers buoys and marks.
• The fallback could make things worse. Stopping the motors while towing a boom in a current would let it drift into the channel, and we had no logic for losing communications or one boat losing power.
• Our risk scoring was qualitative. Each risk had a single label, with no likelihood × severity score or owner.

What I’d do differently

• Number every requirement, give each a rationale, a measurable threshold and a verification method (inspection, analysis, demonstration or test), and keep a traceability matrix from user need to system requirement to test.
• Build a throughput model first, from debris flux, boom sweep width, capture efficiency and sorties per day, and size the fleet and boom from it.
• Do a towing-force budget (hull resistance plus boom and catch drag against the current) and choose motors and propellers from it, with an energy budget that includes the sensors and computing.
• Base the autonomy logic on COLREGs and design for failures, such as lost communications or a boat losing power.
• Score risks by likelihood and severity, with a named owner for each.