Where the payload lives
The vehicle has six bays. We build one of them — the payload tray — and treat the rest as the host we have to fit inside, draw power from, and not disturb.
Bays, nose to tail
Proportional along the hull · nose at left
- 01 ImplementedSonar head Acoustic window
Transducer and acoustic window. The only part of the vehicle the water talks to directly.
- 02 ImplementedSensor bay
Temperature, salinity, turbidity and depth probes on the 1-Wire and analog headers.
- 03 ImplementedPayload tray Ours
The adaptive sonar payload. Everything this project builds sits here; the rest of the vehicle is the host.
- 04 ReferenceElectronics bay
Vehicle avionics — navigation, autopilot, comms. Not ours.
- 05 ReferenceBattery bay
Vehicle pack. The payload draws from it through the buck stage.
- 06 ReferenceControl surfaces
Thruster and fins. Not ours, but the reason the survey has a track at all.
Why the boundary matters
Everything this project claims stops at the payload tray. The vehicle's navigation, its autopilot, its pack and its thruster are someone else's problem and someone else's evidence — which is why those bays read Reference above rather than carrying a status we would have to defend.
The two places the boundary is not clean are the sensor bay, whose probes we read but do not own, and the sonar head, where our transducer sits behind their acoustic window. Both are interfaces, and both are where an integration problem would show up first.
Two of the six bays are shared. The sensor bay carries probes we read but do not own, and the sonar head puts our transducer behind someone else's acoustic window. Every other boundary is clean. If this vehicle and this payload are ever going to disagree, it will be at one of those two places — which is why they are named here rather than left inside an integration document nobody opens.