Edge-compute architecture for an unmanned surface vessel
Three architectures compared on real bandwidth budgets, so the platform decision was made on evidence rather than TOPS figures.
Outcome A ranked architecture recommendation with bandwidth and power budgets the customer could defend internally.
The customer’s unmanned surface vessel worked. The compute platform inside it was the constraint — and the question was not “which board is fastest” but “what does the sensor payload actually demand, and what happens when we add the next sensor”.
Bandwidth budgets before hardware
Autonomy platform decisions get made on marketing numbers far too often. TOPS figures do not tell you whether the camera pipeline fits.
So the work started with an inventory: every sensor, its data rate, its interface, its latency requirement, and its duty cycle. Cameras over MIPI CSI-2, LiDAR returns, AIS traffic, GNSS at update rate, and the radar and sounder data already on the vessel. That produced a real aggregate bandwidth figure and — more usefully — a figure for the payload the customer wanted to add in two years.
Three architectures, honestly compared
Each option was worked to the same depth: compute capability against the actual pipeline, ingress bandwidth against the sensor inventory, power and thermal in a sealed marine enclosure, software ecosystem maturity for ROS 2, and supply longevity.
Not one recommendation with two strawmen. Three real options, each with the case for it and the case against it, so the customer could take the decision to their own stakeholders and defend it.
Marine-specific integration
AIS reception, GNSS with RTK for the positioning accuracy autonomy needs, and antenna placement on a mast where every radiator competes for space and ground. Salt, spray, condensation and a sealed enclosure with a real thermal problem — a fanless design that must survive still air on a hot day.