-
-
A physical Go2 Air records the suitcase beside its route during the first visit.
-
The Go2 revisits the room after the suitcase has moved.
-
The Go2 edge camera preserves the suitcase state across two physical passes
-
Qwen3-VL-Flash flags the moved-suitcase candidate; local edge code keeps the update provisional until it is rechecked.
-
A fixed Gemini 2 adds independent qualitative depth evidence from the first visit.
-
DimOS replays the first Go2 onboard-SLAM point cloud, odometry path, and robot pose.
-
The next visit creates a new spatial record of the same route.
-
Qwen Cloud explains the change; the edge validates it and locally accepts, holds, or rechecks the memory.
-
The redacted Workbench proof shows the QwenGuard container running on Alibaba ECS with /healthz returning OK.
Inspiration
Robots remember what they saw, but the world keeps changing.
In our hotel test, we moved a suitcase between two visits. The robot's old memory was now wrong. That raised a simple question: how can a robot use cloud vision without depending on a perfect connection or treating every AI answer as fact?
What it does
QwenGuard helps a robot decide when to update its memory and when not to guess.
The Go2 records camera, SLAM, and odometry data. The edge selects a few useful frames and sends them to Qwen3-VL-Flash on Qwen Cloud.
Qwen explains what changed. Local code then chooses:
- Accept the new memory
- Hold it when evidence is weak
- Recheck when more evidence is needed
If the internet drops, uncertain updates stay on hold. When the connection returns, QwenGuard checks them again.
Each step is saved in a hash-chained receipt, so we can trace what the robot saw, what Qwen found, and why its memory changed.
How I built it
I built the pipeline in Python using:
- A Unitree Go2 Air for camera, SLAM, and odometry
- DimOS for spatial recording and replay
- An Orbbec Gemini 2 for RGB-D evidence
- Qwen Cloud for visual reasoning
- Local rules for validation and offline fallback
- Alibaba ECS and Docker for the cloud service
Raw video and maps stay on the edge. Qwen receives only the selected evidence needed for the comparison.
Challenges
The hardest part was splitting the work between cloud and edge.
Sending everything to the cloud wastes bandwidth and exposes more data. Trusting every model response is also risky. I solved this by letting Qwen describe the scene while local code controls whether that result enters memory.
I also had to line up evidence from different cameras and robot streams without hiding where it came from.
What I learned
The best split is simple:
The cloud explains. The edge decides.
A robot should not turn a missing connection or uncertain answer into a confident memory.
What's next
Next I want to add live keyframe selection, persistent object tracking, longer patrols, and shared memory across robots.
The goal is to give robots memory they can use and evidence people can check.
Log in or sign up for Devpost to join the conversation.