Inspiration
What happens when a warehouse robot loses its network connection?
Most connected robotic systems depend on continuous communication to share information and make coordinated decisions. We wanted to explore a different approach: robots that can continue learning and operating when completely offline, then share what they learned once connectivity returns.
That idea became FleetMind — an offline-first fleet memory system built around Qdrant Edge.
What it does
FleetMind is a live warehouse simulation featuring four robots: A, B, C, and D.
Each robot navigates its own routes through a warehouse containing shelving, static pallets, and moving forklifts. When a robot encounters an obstacle, it records that experience in its own embedded Qdrant Edge shard without making a network request.
The memory doesn't just get stored — it influences future navigation.
FleetMind uses vector-similarity search over the robot's local memory to modify the cost of potential routes. Previously encountered obstacles can therefore become effectively impassable, while nearby remembered obstacles can influence route selection.
When a robot reconnects, its locally learned memories are pushed to a central Qdrant fleet store. Memories from different robots are merged, and the resulting fleet knowledge is pulled back through partial snapshots.
This creates the core demonstration:
Robot B can avoid an obstacle it has never personally encountered because Robot A discovered it first.
How we built it
FleetMind is built around a local-to-fleet memory architecture.
Robot-local intelligence
Each robot has two Qdrant Edge shards:
- Mutable shard — stores new, unsynchronized observations.
- Immutable shard — contains the robot's current copy of shared fleet knowledge.
The robots can therefore continue operating against local memory without depending on the fleet server.
Vector-based planning
Memories contain spatial and text vectors. During route planning, FleetMind performs vector-similarity searches against local memories and incorporates those results into the A* cost map.
A strong similarity match can turn a remembered obstacle into an effective wall, while weaker matches add a smaller route cost.
Fleet synchronization
When connectivity returns, local memories are pushed to the central fleetmind_memory collection.
The fleet store merges observations using rules for:
- New memories
- Confirmed memories from multiple robots
- Conflicting
blocked/clearobservations - Source tracking
- Memory history
The updated fleet state is then pulled back through partial snapshots, so only the required difference needs to be transferred.
The technology
The backend uses Python, FastAPI, NumPy, Qdrant Edge, and Qdrant Server/Cloud.
The frontend uses React, Vite, Three.js, and OGL to create the interactive warehouse and engineering console.
Ollama provides local text embeddings and an optional local LLM for the Ask Robot feature.
Challenges we ran into
The biggest challenge was making local memory and shared fleet memory behave like two parts of the same system without requiring constant connectivity.
We had to design a synchronization pipeline that could:
- Keep new observations local while offline.
- Prevent offline robots from making fleet-server calls.
- Push memories when connectivity returns.
- Merge observations from different robots.
- Resolve conflicting observations.
- Pull only the necessary fleet changes back to each robot.
We also introduced Chaos mode, which simulates network latency and packet loss during synchronization. This allowed us to demonstrate that the fleet's synchronization layer isn't simply assuming a perfect network.
Another challenge was making the vector database meaningful to navigation rather than using it simply as storage. The planning system therefore queries local memories during route generation and incorporates similarity scores into the A* cost map.
What we're proud of
The part we're most proud of is the knowledge transfer demonstration.
A robot doesn't need to personally encounter every obstacle in the warehouse.
One robot can discover an obstacle offline, store it locally, synchronize it later, and allow another robot to inherit that knowledge.
FleetMind also exposes this process visually through its console: local memories, inherited memories, synchronization events, merges, route changes, query latency, uplink calls, and synchronization savings can all be observed while the simulation is running.
The project isn't just showing the final route — it shows why the route changed and where that knowledge came from.
What we learned
Building FleetMind taught us that an offline-first robotic system isn't simply about putting a database on the edge.
The difficult part is the memory lifecycle:
Observe → Store locally → Retrieve → Plan → Sync → Merge → Inherit → Plan again
We learned how vector similarity can connect past observations to future navigation decisions, how local and fleet-level memory can coexist, and how conflict resolution becomes important when multiple robots independently observe the same environment.
We also learned that making the system observable is crucial. Metrics such as query latency, synchronization duration, partial-vs-full transfer size, shard size, and uplink calls make the behavior of the system measurable rather than purely visual.
What's next for FleetMind
The next step is moving beyond simulation toward real robotic systems.
The current architecture deliberately separates the robot's memory and synchronization layers from the simulated environment. The README's intended extension is to replace the simulated Robot.tick() and DYN ground truth with real sensor input while keeping the Edge shard, synchronization, and merge architecture intact.
From there, FleetMind could expand to larger fleets, larger environments, more sophisticated memory policies, and different conflict-resolution strategies.
The long-term vision is an edge-native fleet where every robot can learn independently, operate without the cloud, and make the entire fleet smarter when connectivity returns.
Log in or sign up for Devpost to join the conversation.