WebberTheSpiderBot
WEBBER - It Sees. It Thinks. It Protects.
Inspiration
Traditional security cameras can observe an area, but they cannot move toward an incident, inspect obstacles, or actively patrol different zones. We wanted to build something beyond passive surveillance - a robot capable of moving, perceiving, reasoning, and responding autonomously.
This inspired WebberTheSpiderBot, a 12-DOF quadruped designed for autonomous monitoring and security in environments such as warehouses, factories, data centers, server rooms, and restricted facilities.
The most rewarding moment was watching the robot take its first stable steps. What began as CAD models, equations, simulations, circuit design, servo calibration, and debugging eventually became a physical system capable of autonomous locomotion and AI-based perception.
What it does
Webber follows a closed-loop architecture:
Sense → Perceive → Think → Decide → Act → Record
Key capabilities
- Autonomous patrol of predefined zones.
- Obstacle detection and avoidance using VL53L0X ToF sensing.
- Person and object detection using Edge Impulse.
- Face detection using YuNet.
- Face recognition using SFace embeddings.
- Unknown-person detection with Telegram security alerts.
- Person following while maintaining a safe distance.
- 2D occupancy-grid mapping using sensor and motion information.
- Local AI reasoning using Qwen 2.5 0.6B.
- SQLite-based memory for storing recent events.
- Web-based monitoring and control with live telemetry.
- Reinforcement-learning-based locomotion trained in PyBullet.
Problem → Solution
| Problem | Solution implemented in Webber |
|---|---|
| Passive surveillance | A mobile quadruped can physically patrol an area instead of relying only on fixed cameras. |
| Blind spots | Webber changes its physical position and patrols multiple zones. |
| Unauthorized personnel | YuNet detects faces and SFace compares them against known identities. |
| Delayed security response | Persistent unknown-person detection automatically triggers a Telegram alert with a snapshot. |
| Obstacles during patrol | VL53L0X ToF sensing detects obstacles and enables the navigation system to react. |
| Complex 12-DOF locomotion | Inverse kinematics and PPO-based reinforcement learning generate coordinated leg movement. |
| Cloud dependency | AI inference and the local Qwen model run on the UNO Q Linux environment. |
| LLM hallucinations | SQLite memory grounding, constrained prompts, low temperature, and JSON validation restrict unreliable outputs. |
| Real-time motor control | The UNO Q separates Linux-side AI processing from STM32-based real-time hardware control. |
| Servo-to-servo variation | All 12 servos were individually calibrated for center position and direction. |
| Simulation-to-reality gap | Real-world testing was used to tune gait timing, stance support, yaw compensation, and servo behavior. |
| Power fluctuations | A dedicated battery/BMS/buck architecture, capacitor buffering, and delayed camera initialization were implemented. |
System Flowchart
The complete system can be represented as:
┌─────────────────────┐
│ POWER ON │
└──────────┬──────────┘
│
▼
┌────────────────────────────┐
│ Hardware Initialization │
│ IMU • ToF • PCA9685 • OLED │
│ Camera • Servos • Sensors │
└─────────────┬──────────────┘
│
▼
┌────────────────────────────┐
│ SENSOR ACQUISITION │
│ ToF + IMU + Camera Input │
└─────────────┬──────────────┘
│
┌────────────────┴────────────────┐
│ │
▼ ▼
┌────────────────────┐ ┌────────────────────┐
│ DISTANCE / IMU │ │ AI PERCEPTION │
│ PROCESSING │ │ Edge Impulse/YuNet │
└─────────┬──────────┘ │ + SFace │
│ └─────────┬──────────┘
│ │
└──────────────┬─────────────────┘
▼
┌────────────────────────────┐
│ DECISION / PLANNING │
│ │
│ • Patrol │
│ • Obstacle Avoidance │
│ • Person Following │
│ • Intrusion Detection │
│ • Mapping │
│ • Qwen Task Planning │
└─────────────┬──────────────┘
│
▼
┌────────────────────────────┐
│ LOCOMOTION CONTROL │
│ │
│ PPO Gait → IK → Joint │
│ Angles → Servo Pulse Widths│
└─────────────┬──────────────┘
│
▼
┌────────────────────────────┐
│ ACTUATION │
│ PCA9685 → 12 MG90S Servos │
│ → Robot Motion │
└─────────────┬──────────────┘
│
▼
┌────────────────────────────┐
│ OUTPUTS │
│ │
│ OLED • Web UI • SQLite │
│ Telegram Alerts • Map │
└─────────────┬──────────────┘
│
│
└──────────────► Feedback
│
▼
┌───────────────┐
│ Next Control │
│ Cycle │
└───────┬───────┘
│
└──► SENSOR
ACQUISITION
This creates a continuous closed-loop robotic system, where sensor information affects decisions, decisions affect locomotion, and the resulting movement generates new sensor information.
How we built it
Hardware Architecture
The main hardware consists of:
| Component | Purpose |
|---|---|
| Arduino UNO Q | Main computing and control platform |
| STM32 | Real-time hardware control |
| 12 × MG90S | 3 DOF per leg for quadruped locomotion |
| PCA9685 | 16-channel PWM servo controller |
| GY-87 IMU | Orientation and motion sensing |
| VL53L0X ToF | Distance and obstacle detection |
| Sony CMU-BR300 | Camera and microphone |
| SSD1315 OLED | Local status information |
| 2S 18650 battery system | Main power source |
| BMS + Buck converter | Battery protection and regulated power |
The robot contains 12 independently controlled servo joints, giving each leg three degrees of freedom.
Inverse Kinematics
For a simplified two-link leg, the knee angle can be calculated using:
$$ \theta_2 = \cos^{-1} \left( \frac{x^2+z^2-L_1^2-L_2^2} {2L_1L_2} \right) $$
The resulting joint angles are converted into servo pulse widths and sent to the PCA9685.
The gait uses phase offsets:
$$ RL=0,\qquad FL=0.25,\qquad RR=0.5,\qquad FR=0.75 $$
This produces coordinated diagonal movement.
Reinforcement Learning
Locomotion policies were trained using PPO (Proximal Policy Optimization) in PyBullet.
Approximately 5,000 simulated episodes were used with randomized friction and terrain conditions.
The objective was not simply to make the robot move, but to find a stable gait while maintaining:
- Forward velocity.
- Stability.
- Energy efficiency.
- Three-leg ground contact.
- Robustness to terrain variation.
Computer Vision Pipeline
The perception pipeline is:
Camera
↓
Edge Impulse / MobileNet SSD v2
↓
Person/Object Detection
↓
YuNet
↓
Face Detection
↓
SFace
↓
128-D Face Embedding
↓
Cosine Similarity
↓
Known / Unknown Identity
↓
Decision
Face similarity is calculated using:
$$ Similarity = \frac{A\cdot B} {||A||\,||B||} $$
A persistent unknown face moves through an identity state machine:
UNKNOWN
↓
SUSPICIOUS
↓
INTRUDER
↓
Telegram Alert + Snapshot
Local AI and Memory
Webber uses Qwen 2.5 0.6B locally through Ollama.
Robot events are stored in:
SQLite → spidey_memory.db
The LLM receives recent memory records and can answer questions such as:
"Where is Rachit?"
Task plans are generated in structured JSON and validated before execution to reduce hallucination-driven actions.
Mapping
The robot maintains a:
$$ 100\times100 $$
occupancy grid.
With a cell resolution of 5 cm:
$$ 100\times5\text{ cm}=500\text{ cm}=5\text{ m} $$
Therefore, the system represents approximately a 5 m × 5 m area.
Challenges we ran into
Building Webber was not simply about combining existing modules. Getting them to work together on real hardware created several unexpected problems.
1. Simulation vs Reality
The RL gait was stable in simulation but physical MG90S servos introduced approximately:
- 3° backlash
- ~100 ms delay
- Mechanical compliance
- Limited torque
The simulated gait cycle was 0.8 s, but this was too aggressive for the physical robot.
We increased it to 2.0 s, added stance-support compensation, and tuned the yaw trim to 0.82.
2. Servo Calibration
Each of the 12 servos had slightly different center positions and directions.
The center pulse could vary approximately between:
$$ 1300-1700\ \mu s $$
Incorrect calibration could cause a leg to dig into the ground or overload the servo.
3. I2C Contention
Multiple devices shared the I2C bus:
| Device | Address |
|---|---|
| PCA9685 | 0x40 |
| GY-87 | 0x68 |
| VL53L0X | 0x29 |
| OLED | 0x3C |
We solved this through scheduling and batching:
- Servo updates at 50 Hz
- Sensor reads at 5 Hz
- OLED updates at approximately 10 Hz
4. AI Accuracy vs Speed
The initial MobileNet SSD model achieved higher accuracy but was too slow.
We reduced the input size to 96 × 96 and reduced model complexity, allowing substantially faster inference while maintaining:
92% TPR and 4% FPR.
5. Lighting
Face recognition performance dropped when the training/gallery lighting differed from deployment lighting.
We addressed this by using 5+ gallery images per person across different lighting conditions and tuning the similarity threshold to 0.40.
6. Power
The robot consumed approximately:
- ~3.0 A peak
- ~2.2 A active average
- ~300 mA idle
Camera startup caused power sag, so we added a 470 µF capacitor and delayed camera initialization by 500 ms.
The resulting system achieved approximately 45 minutes of continuous patrol.
Accomplishments that we're proud of
The most important accomplishment was integrating multiple disciplines into a single working physical system.
Performance Results
| Test / Module | Result |
|---|---|
| Person detection TPR | 92% |
| Person false-positive rate | 4% |
| YuNet frontal detection | 96.7% |
| YuNet at ±30° yaw | 78% |
| SFace identification accuracy | 85% |
| Reported SFace false-match rate | 0% |
| Intrusion alert latency | 3.2 ± 0.5 s |
| Forward speed | 2.0 cm/s |
| Backward speed | 1.8 cm/s |
| 360° turning time | 8.2 ± 0.3 s |
| Heading error | <5° |
| Obstacle avoidance | 100% in tested scenario |
| Person-follow response | <1 s |
| LLM memory Q&A | 90% |
| Valid JSON task plans | 80% first attempt |
| Continuous integration test | >2 hours |
We successfully integrated:
12-DOF Robotics + Reinforcement Learning + Inverse Kinematics + Computer Vision + Face Recognition + Edge AI + Local LLM + Mapping + IoT Alerts + Web Control
into one system running on constrained edge hardware.
What we learned
Webber taught us that robotics is not just about writing an AI model.
It requires:
Mechanical Engineering + Electronics + Embedded Systems + Mathematics + Control Systems + Computer Vision + AI/ML + Software Engineering
We learned that:
- A highly accurate model is useless if it cannot run fast enough.
- Simulation does not automatically translate into reality.
- Servo calibration can be as important as the control algorithm.
- Sensor fusion provides more reliable decisions than a single sensor.
- Small local AI models can be useful when properly constrained.
- Power management needs to be considered from the beginning.
- Real-world failures are valuable engineering data.
- A robot becomes intelligent only when perception is connected to decision-making and physical action.
The most important lesson was simple:
The hardest part was not making individual components work - it was making them work together.
What's next for Untitled
Webber currently has several limitations.
| Limitation | Current Impact |
|---|---|
| Dead-reckoning drift | Approximately 2°/min heading drift |
| No SLAM loop closure | Map accuracy decreases after 5–10 min |
| Low-light vision | Performance decreases below approximately 5 lux |
| ToF range | Effective range is approximately 2 m |
| Smooth floors | RL gait can slip when friction is significantly lower than training conditions |
| Face recognition | Accuracy decreases with severe lighting/occlusion changes |
| IMU stabilization | Can oscillate on rough terrain |
Our next development targets are:
Visual SLAM
Add visual features and loop closure to reduce accumulated navigation drift.
Multi-Person Tracking
Move beyond single-person recognition using multi-object tracking and re-identification models such as OSNet.
Adaptive Locomotion
Use online reinforcement learning/meta-learning to allow the robot to adapt its gait to changing surfaces.
Smarter Autonomous Security
The long-term goal is to evolve Webber from an autonomous patrol robot into an intelligent robotic security sentinel capable of understanding its environment, identifying anomalies, deciding what requires attention, and physically responding to events.
Built With
- arduinounoq
- autonomousnavigation
- autonomousrobotics
- cloudlessai
- embeddedai
- environmentalawareness
- industrialsecurity
- perceptiontoaction
- physicalai
- quadrupedrobot
- reinforcementlearning
- sensorfusionai
- spatialmapping
- spatialmemory
- threatdetection