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
Share this project:

Updates