CONTAINERIZED DRONES
FOR COASTAL MONITORING
Run the containerized drone nodes today. The same interface on physical nodes tomorrow. Designed to be reproducible and accessible on commodity hardware.
WHY DOES IT MATTER
Transparent methods
All services (mobility, input, AI, networking) are containerized and documented. Results are reproducible on laptops or single-board computers.
Simulation ↔ field
The payload format and timing mirror our ns-3 scenario, so logs from the simulator and from the containerized node can be compared one-to-one.
Lower barrier to entry
No proprietary SDKs. Plain CSV/GeoJSON outputs and a small web viewer make the system useful for schools, NGOs, and local groups.
MISSION: PLASTIC DETECTION PROTOCOL
01_DETECT
Package sensor data. The input service pairs GPS with an optional image sample and publishes a normalized message for downstream processing.
02_SIMULATE
Mirror behavior in ns-3. Mobility, payloads, and timing are replicated. Logs export to CSV/GeoJSON for spatial analysis and comparison.
03_REACH
Systematic coverage. The mobility service follows a lawnmower sweep with configurable speed, segment length, and stop timing (measurement at t-1 s).
04_SHARE
Lightweight UDP exchange. The networking service sends {senderId, lat, lon, plastic} to peers. The same format is used in the simulator for easy interop and HIL.
HOW IT WORKS
DRONE NETWORK
Inside each node, micro-services communicate over ZeroMQ topics. Components are decoupled, so you can replace one without touching the others.
LAWNMOWER PATTERN
Advance, pause, shift row, return on a diagonal—parameters match the ns-3 scenario for one-to-one comparisons.
AI DETECTION
A lightweight placeholder sets a has_plastic flag and confidence. The interface stays stable as better models are dropped in.
LOCATION MAPPING
Events are logged to CSV and converted to GeoJSON by a small script. A Leaflet viewer renders samples and exchanges on a map.
THE CONTAINERIZED APPROACH
We use containers to keep the system practical and accessible. Each capability runs as a small service with a clear interface, so others can reproduce, modify, or replace parts without touching the rest.
WHY WE DO IT
- Reproducibility – same results across machines
- Interoperability with ns-3 – shared payloads and timing
- Hardware-agnostic – runs on laptops and SBCs
- Fast iteration – update a single service at a time
- Clear boundaries – mobility, input, AI, networking are decoupled
- Offline friendly – no cloud required to test
CURRENT LIMITATIONS
- Prototype stage – validated with 1–3 local nodes; larger trials in progress
- AI is a stub – accuracy not the focus yet; model is replaceable
- Security hardening – out of scope for this prototype
- Linux/Docker – best support on Linux hosts