Riptide

TL;DR

• At Hack for Humanity 2026, Santa Clara University’s social-good hackathon, my six-person team built Riptide, a platform for coordinating ocean-pollution cleanup with a simulated drone operator console.
• I put a real flight simulator behind that console: a 607-line Flask bridge that flies a Microsoft AirSim quadcopter over RPC, an Express proxy and a rebuilt operator console. The first mission was in the air 91 minutes after I downloaded the team’s codebase.
• On the final morning I directed the same AI agent through an Android volunteer app, from an empty template to a compiled APK in about an hour.

The problem

The team’s drone console animated a drone on a map, but nothing was flying. For a cleanup-coordination tool, the interesting questions are physical: what the drone can see, where it actually is, and whether it can fly a survey pattern and come back.

What I built

• Bridge. A Flask service with 14 endpoints over one AirSim multirotor client. Telemetry covers pose, velocity, GPS, IMU, barometer and magnetometer, with orientation converted from quaternions to roll, pitch and yaw. There are RGB, depth and segmentation camera frames, LiDAR, a distance sensor and a composite scan, plus takeoff, land, fly-to, hover and reset.
• Missions. A threaded mission endpoint arms the drone, climbs to scan altitude (15 m by default), visits each waypoint with a 2-second scan hover, then heads home and lands.
• Proxy. An Express proxy with per-route timeouts. When the bridge is down it returns 503 with a start-the-bridge hint, so the console drops back to simulated mode instead of breaking.
• Console. A two-panel operator view: the camera feed and an auto-scaling position map on the left; IMU, orientation, barometer, magnetometer, GPS, flight controls and an event log on the right.
• Volunteer app. An Expo/React Native Android app with a dark-styled map of Bay Area cleanup zones and hazards. Tapping a marker flies the map to it and snaps a card carousel to the matching site; swiping the carousel re-centres the map.

The base platform is my teammates’ work. My pieces ran in my build, and the simulator’s own log shows the live mode flying; they were not merged into the team’s submitted repo.

Key decisions

• Decision: guard the simulator import and fall back to mock mode. Why: the bridge still starts on a machine without AirSim installed. Trade-off: two code paths to keep honest.
• Decision: return missions immediately and fly them on a background thread. Why: the console stays interactive while the drone flies. Trade-off: concurrency on a single simulator client (see below).
• Decision: degrade to 503 instead of hanging. Why: a demo console should fall back to simulated mode, not freeze. Trade-off: the operator has to notice the mode switch.

The hard part

One RPC client, many callers. The console polls telemetry and camera frames over HTTP while a background thread flies a multi-leg mission, and all of it goes through one AirSim client. The bridge serializes every call behind a single lock, health-checks the connection and re-establishes it lazily, so the console survives a simulator restart.

The trade-off shows up in the code: the mission thread holds the lock across each leg of the flight. Telemetry and camera requests wait until the leg finishes, and on legs longer than the proxy’s 5-second timeout, the console sees a 503 mid-flight. The fix I’d make next is to give telemetry its own client, or release the lock and poll the flight’s future, so readouts stay live between waypoints.

Results

• Three bridge-driven missions in the simulator’s own log, each with takeoff, a climb and four waypoint legs at the 15 m scan altitude: 18 completed flight segments in all.
• A compiled Android APK for the volunteer app, two hours before submissions closed.

What I’d do next

• A separate telemetry client, so readouts stay live during a mission leg.
• Log a full return-to-launch and landing, and record a mission end to end.

Links

• Devpost: Riptide
• Earlier drone work: SlugBites · AeroBites