<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Edge on David Bensoussan</title><link>https://blog.bensoussan.de/tags/edge/</link><description>Recent content in Edge on David Bensoussan</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 25 Aug 2026 10:00:00 +0200</lastBuildDate><atom:link href="https://blog.bensoussan.de/tags/edge/index.xml" rel="self" type="application/rss+xml"/><item><title>A Reference Architecture for Robot Fleets</title><link>https://blog.bensoussan.de/post/2026-08-25-a-reference-architecture-for-robot-fleets/</link><pubDate>Tue, 25 Aug 2026 10:00:00 +0200</pubDate><guid>https://blog.bensoussan.de/post/2026-08-25-a-reference-architecture-for-robot-fleets/</guid><description>&lt;p&gt;The last article listed five capabilities and the order to build them in. Before building anything, we must agree on the architecture: what runs where, and which direction each connection travels.&lt;/p&gt;
&lt;p&gt;The architecture has three layers. The robot runs its own ROS2 stack as before. Above it, one or more edge servers per site carry updates and data between the robot and the hub. Above the edge servers is a single hub, shared by the whole fleet, and every edge server connects to it. The hub never opens a connection to a site, that&amp;rsquo;s what makes control and security possible.&lt;/p&gt;</description></item></channel></rss>