```html
Seastead Convoy Mode Concept
Seastead "Convoy Mode" Concept
This document fleshes out a practical convoy mode for a fleet of seasteads that hold fixed positions relative to each other while underway or while drifting slowly together. It focuses on:
- Local communications mesh/networking
- Relative navigation and station keeping
- Shared situational awareness and watchkeeping
- Join/leave procedures
- Safety and fault handling
- Recommended low-cost hardware/software architecture
Short answer: For local convoy networking, a hybrid system makes the most sense:
- Primary local data links: 5 GHz directional Wi-Fi bridges between nearest neighbors
- Backup/omni local link: marine Wi-Fi or 2.4/5 GHz omni for low-rate control and discovery
- Longer-range backup: Starlink internet as fallback path between members
- Navigation basis: moving-base RTK GNSS + IMU + heading sensors + local relative ranging if possible
- Control basis: distributed autopilot with convoy manager and collision / separation safety rules
1. What "Convoy Mode" Should Do
A good convoy mode should provide these functions:
- Maintain formation: each seastead holds a target offset from a convoy reference frame.
- Allow joining: a new seastead approaches from outside, is assigned a slot, and smoothly enters formation.
- Allow leaving: a seastead exits without causing instability or confusion.
- Share sensors: AIS, cameras, radar if fitted, alerts, weather, obstacle tracks, status, and watchstanding information.
- Degrade safely: if communications or navigation become unreliable, each unit falls back to safe independent mode.
- Reduce watch burden: the fleet acts as a cooperative observation network.
2. Formation Model
2.1 Grid Layout
Your idea of a grid is sensible. The simplest model is a 2D rectangular or staggered lattice:
- Rectangular grid: easy math and easy slot numbering.
- Staggered / hex-like grid: often better packing and more uniform nearest-neighbor spacing.
For seasteads of your rough size, a practical spacing might be something like:
- Minimum experimental spacing: 100 to 150 ft center-to-center
- More conservative operating spacing: 150 to 300 ft center-to-center
Final spacing depends on:
- wave-induced relative motion
- thruster authority
- GNSS accuracy and latency
- windage differences between units
- how much maneuvering room you want for a failed unit
Important: even with very precise RTK positioning, spacing should be determined by control error in waves and gusts, not just by GPS precision. RTK can tell you position to centimeters, but your structure may still move several feet or more dynamically.
2.2 Convoy Reference Frame
Each seastead should know its desired pose in a shared convoy coordinate system:
- X: forward/back relative to convoy heading
- Y: left/right relative to convoy heading
- Heading: desired yaw relative to convoy heading
A convoy can be controlled in one of two ways:
- Leader-follower: one designated lead defines convoy motion; others hold offsets.
- Virtual leader / consensus: no single leader required; fleet agrees on reference using distributed logic.
For early versions, leader-follower is much simpler. A convoy master can be elected automatically, with backup masters ready.
3. Joining and Leaving the Convoy
3.1 Joining Sequence
- New seastead requests admission over Starlink or local radio/Wi-Fi.
- Convoy software assigns a candidate slot.
- New unit approaches from outside the convoy perimeter.
- At a pre-entry point, software verifies:
- RTK lock quality
- communications quality
- autopilot health
- thruster health
- human acknowledgement
- When inside a specified activation radius, convoy mode arms.
- Autopilot transitions from self-navigation to formation keeping.
- Slot status changes to
occupied.
3.2 Recommended Join Logic
Use several concentric zones rather than a single threshold:
- Outer rendezvous zone: convoy gives approach instructions.
- Pre-entry zone: speed limited, relative position checked.
- Capture zone: autopilot begins formation control.
- Locked zone: full convoy mode active.
This is safer than "within half a grid spacing and then switch on."
3.3 Leaving Sequence
- Member requests departure.
- Convoy manager checks neighboring slots and traffic.
- Departure corridor is assigned.
- Neighbors slightly expand spacing if needed.
- Leaving member transitions to independent navigation mode.
- Slot marked free and optionally offered to next joining unit.
4. Communications Network Architecture
4.1 Best Practical Architecture: Hybrid
Do not rely on only one network. Use at least three layers:
| Layer |
Purpose |
Suggested Tech |
| Primary local high-rate |
Convoy telemetry, sensor sharing, video snapshots, software sync |
5 GHz directional Wi-Fi point-to-point / point-to-multipoint |
| Secondary local low/medium-rate |
Discovery, control backup, short messages, health beacons |
Omni Wi-Fi and/or sub-GHz / LTE-style private link |
| Wide-area fallback |
If local mesh breaks, route via internet |
Starlink VPN / WireGuard tunnels |
4.2 Why 5 GHz Wi-Fi Makes Sense
Yes, 5 GHz Wi-Fi 5/6 can make sense because it is:
- cheap
- available now
- fast enough by a huge margin for control/data sharing
- easy to integrate with Linux routers and normal networking gear
But on the ocean:
- antenna alignment matters
- sea reflections can cause multipath fading
- roll/pitch can affect directional links
- salt environment is harsh on connectors and enclosures
4.3 Practical Hardware Choices
Commercial outdoor bridge gear from vendors like these is commonly used:
- Ubiquiti
- MikroTik
- Cambium
- TP-Link Omada outdoor products
For a cost-sensitive prototype, Ubiquiti or MikroTik are probably the easiest starting point.
4.4 Directional Antenna Layout
Your idea of 4 directional antennas is reasonable if the convoy uses a grid and each seastead mainly talks to near neighbors.
A practical arrangement:
- 1 directional radio facing forward
- 1 facing aft
- 1 facing port/left
- 1 facing starboard/right
- plus 1 omni backup antenna if budget allows
This supports a nearest-neighbor mesh and reduces interference compared to all-omni links.
4.5 Expected Range and Data Rate
Approximate numbers for 5 GHz outdoor directional Wi-Fi under good conditions:
| Link Type |
Typical Distance |
Realistic Throughput |
Notes |
| Short directional link |
300 ft to 0.5 mile |
100 to 500+ Mbps |
Very easy if line of sight is clear |
| Moderate directional link |
0.5 to 2 miles |
50 to 300 Mbps |
Still practical with decent gear |
| Longer directional link |
2 to 5+ miles |
10 to 200 Mbps |
Depends strongly on antenna gain, alignment, channel width, weather |
For convoy spacing on the order of a few hundred feet, this is far more than enough.
Convoy control and telemetry only need very low bandwidth, usually well under 1 Mbps per vessel unless you are sharing a lot of video.
4.6 Approximate Cost
Very rough 2026-ish price ranges per seastead for local networking:
| Component |
Low-Cost Range |
Higher-End Range |
| Outdoor directional radio/antenna unit |
$80 to $250 each |
$300 to $900 each |
| 4 directional units |
$320 to $1,000 |
$1,200 to $3,600 |
| 1 omni backup AP/link |
$100 to $300 |
$300 to $800 |
| Managed PoE switch + router/firewall |
$150 to $500 |
$600 to $2,000 |
| Marine mounting, enclosure, lightning/surge, cabling |
$300 to $1,000 |
$1,000 to $3,000 |
A practical low-cost prototype local network per seastead could likely be done for roughly:
$1,000 to $3,000 in hardware,
or more if you want robust marine-grade installation.
Recommendation: Start with 4 directional 5 GHz radios plus 1 omni backup radio, all powered by PoE, with a small industrial router running a VPN and mesh/routing software.
4.7 Software / Networking Stack
Recommended network/software stack:
- Linux router or industrial PC
- WireGuard for secure tunnels
- OSPF/Babel/BATMAN-adv for mesh or dynamic routing
- MQTT for telemetry and status messages
- ROS 2 or DDS-style middleware if you want more robotic/autonomy integration
- PTP or NTP for time synchronization
For simplicity:
- WireGuard + OSPF/Babel + MQTT is a good simple stack.
This gives:
- encrypted communications
- automatic routing changes if links fail
- easy publish/subscribe for vessel state and alerts
5. Navigation and Relative Positioning
5.1 Moving Base RTK GNSS
Yes, moving-base RTK GNSS is a strong choice. It can provide:
- very accurate relative position between convoy members
- good heading if using dual antennas
- common reference frame across the convoy
Each seastead should ideally have:
- dual-band multi-constellation GNSS receiver
- moving-base RTK capability
- dual antenna heading
- IMU / inertial measurement unit
- magnetometer optional, but GNSS heading is usually better on metal structures
5.2 Recommended Additional Relative Sensors
RTK is good, but for close spacing and robust operation, add at least one local relative measurement source:
- UWB ranging between nearby seasteads
- marine radar if budget allows
- computer vision feature tracking / marker detection
- LiDAR only if corrosion/environment is managed well and range needs are short
A very good low-cost enhancement is UWB ranging to neighbors. This can provide direct distance checks that help catch GNSS dropouts or spoofing issues.
6. Shared Situational Awareness
6.1 Sensor Sharing
Each seastead can publish:
- position, heading, speed, acceleration
- thruster status and available control authority
- AIS tracks
- camera detections
- radar contacts if fitted
- watch status / human acknowledgement
- weather data: wind, barometer, sea state estimate
- alerts: fire, flooding, power issues, network issues
6.2 Cooperative Object Tracking
Your parallax idea is good. If several seasteads have:
- precisely known locations
- synchronized time
- camera calibration
- shared detections of the same object
Then a central or distributed tracker can triangulate non-AIS contacts. This is useful for:
- small craft
- ships with AIS off
- floating objects
- lights on the horizon
Needed for this to work well:
- camera timestamp synchronization
- known camera orientation relative to hull
- automatic target association across vessels
- confidence scoring
Camera-only ranging over long water distances is possible but can be noisy. It works much better if fused with AIS, radar, and repeated observations over time.
6.3 Watchstanding Model
A convoy watch system could include:
- designated human watchstanders on some subset of vessels
- software heartbeat confirming they are active
- periodic acknowledgment prompts
- alert escalation if no acknowledgment
- shared event board visible to all vessels
Practical status levels:
| Status |
Meaning |
| On Watch |
Human actively monitoring and acknowledging prompts |
| AI/Auto Watch Only |
No confirmed human watch on that vessel |
| Watch Degraded |
Some sensors or acknowledgments missing |
| Watch Critical |
Convoy-wide minimum watch requirements not met |
7. Autopilot and Control Requirements
7.1 Each Seastead Needs Independent Control
Each vessel should always remain capable of safe operation by itself. Convoy mode should be an overlay, not a dependency.
Each unit should have:
- independent navigation computer
- independent local collision avoidance
- independent fail-safe station keeping or retreat mode
7.2 Convoy Controller Functions
The convoy controller computes:
- target position relative to assigned slot
- target heading
- allowed speed / acceleration envelope
- neighbor separation constraints
- emergency breakup or expansion commands
7.3 Control Law Considerations
Because your platform likely has relatively small waterplane area and possibly unusual motion characteristics, convoy mode should account for:
- heave, roll, and pitch in waves
- delayed thruster response
- wind load from living module and solar roof
- wave-induced drift differences among units
A practical control stack might be:
- State estimator fusing RTK GNSS, IMU, heading, thruster feedback
- Outer-loop position controller
- Inner-loop heading and surge/sway controller
- Thruster allocator for the 6 rim-drive thrusters
8. Safety Logic
8.1 Minimum Safety Features
- minimum separation ring around every seastead
- maximum closure rate limits
- link-loss timeout
- RTK quality threshold
- manual override on any vessel
- automatic convoy breakup mode if conditions exceed limits
8.2 Failure Cases to Design For
| Failure |
Required Response |
| Loss of local Wi-Fi |
Continue briefly on predicted state, then widen spacing or exit convoy |
| Loss of RTK fix |
Fall back to GNSS + IMU + local ranging, increase buffer distance |
| Thruster failure |
Mark vessel degraded, reassign nearby slots, possibly move failed unit to perimeter |
| Power failure |
Broadcast distress/degraded status, neighbors create exclusion zone |
| Unexpected traffic crossing convoy |
Convoy expands, parts, or turns under coordinated rule set |
| Human override |
Immediate release from slot and notify neighbors |
8.3 Emergency Modes
Suggested emergency convoy modes:
- Hold: freeze convoy geometry as much as possible
- Expand: increase grid spacing by a set factor
- Part corridor: open a lane for passing traffic
- Breakup: every vessel reverts to independent safe navigation
9. Data Model and Messages
At minimum, every seastead should publish these messages once or several times per second:
VesselState: ID, time, lat/lon, local convoy x/y, heading, velocity, acceleration
HealthState: power, GNSS quality, RTK status, network quality, thruster health
ConvoyState: assigned slot, mode, join/leave status, leader ID
TrafficTracks: AIS and non-AIS tracked contacts
WatchStatus: human on watch, acknowledgment age, active alerts
SensorDetections: camera/radar detections with confidence
MQTT topics could work well for this, such as:
convoy/vessel/<id>/state
convoy/vessel/<id>/health
convoy/tracks
convoy/watch
convoy/alerts
10. Recommended Hardware Stack Per Seastead
10.1 Communications
- 4 x outdoor 5 GHz directional radios/antennas
- 1 x omni Wi-Fi backup access point/radio
- 1 x industrial PoE switch
- 1 x router/firewall computer
- surge protection and good marine connectors
10.2 Navigation and Sensing
- dual-antenna RTK GNSS receiver
- IMU
- AIS transceiver
- camera suite with synchronized timestamps
- marine radar optional but strongly beneficial
- UWB ranging modules to nearest neighbors optional but recommended
10.3 Compute
- 1 x autopilot/control computer
- 1 x mission/vision/network computer
Keeping control and mission compute separated is a good safety practice.
11. Software Architecture Recommendation
11.1 Minimum Viable Software
- Local vessel autopilot
- Convoy manager
- Shared telemetry bus
- Track fusion service
- Watchstanding dashboard
- Join/leave planner
11.2 Suggested Stack
| Function |
Suggested Tooling |
| OS |
Linux |
| Secure networking |
WireGuard |
| Dynamic routing |
Babel or OSPF |
| Telemetry bus |
MQTT |
| Robotics middleware |
ROS 2 if needed |
| Database/logging |
PostgreSQL + time-series logging |
| Dashboard |
Web app on local LAN |
12. Recommended Development Path
Do this in stages:
- Simulation first: model convoy geometry, link behavior, and control logic.
- Single-vessel autonomy: prove independent station keeping.
- Two-vessel tests: validate moving-base RTK, local Wi-Fi links, and relative control.
- Three-to-five-vessel trial: prove join/leave and shared tracking.
- Larger convoy: test dynamic routing and watch system.
13. My Recommendation Summary
Best Practical Recommendation
- Use 5 GHz directional Wi-Fi as the main local convoy data network.
- Give each seastead 4 directional radios for nearest-neighbor links plus 1 omni backup link.
- Use WireGuard + dynamic routing + MQTT for secure and simple distributed communications.
- Use moving-base RTK GNSS + IMU + dual-antenna heading as the basis of relative positioning.
- Add UWB ranging if possible for extra robustness at close range.
- Implement convoy mode as a layer on top of independent autopilot, never as a replacement for local safety.
- Use a leader-follower model initially, then move to more distributed logic later if desired.
14. Rough Prototype Budget Per Seastead
| Item |
Approx. Cost |
| 4 directional Wi-Fi radios |
$320 to $1,000 |
| 1 omni backup radio |
$100 to $300 |
| Router + PoE switch + cables + mounts |
$300 to $1,500 |
| RTK GNSS + heading setup |
$800 to $4,000+ |
| IMU and integration |
$100 to $1,000+ |
| Cameras and synchronization |
$300 to $3,000+ |
So a basic but credible local convoy electronics package might start around
$2,000 to $6,000 per seastead if done cost-consciously,
not counting more advanced radar, compute redundancy, or marine-hardening upgrades.
15. Final Notes
The convoy idea is feasible, especially if convoy spacing is generous and the first versions are conservative. The most important design principles are:
- redundancy in communications
- clear join/leave procedures
- independent fail-safe operation
- shared but not overcomplicated data model
- testing in stages
If you want, I can next produce any of these in HTML too:
- a block diagram of the convoy communications and control system
- a sample message protocol / JSON schema
- a join/leave state machine
- a hardware bill of materials with specific Ubiquiti/MikroTik parts
- a concept UI/dashboard mockup for convoy operations
```