An open-source, AI-ready robotic companion, built from scratch to learn mechatronics end to end: mechanical design, electronics, control systems, and embedded + AI software.
roboPet is a small four-legged robot designed to feel approachable and expressive rather than industrial. It's built on a two-board architecture based on the open-source sesame-robot design: a Raspberry Pi Pico as a real-time controller driving 12 servos (3 DOF/leg) plus IMU and OLED, bridged over UART to a Raspberry Pi Zero 2W "brain" that handles camera, mic/speaker, RC control, and (eventually) an onboard AI agent.
A deterministic controller that:
- walks and turns on flat ground (static-stable gait) across 12 servos (3 DOF/leg)
- self-levels using IMU feedback (auto-balancing)
- shows expressions on an OLED "face" + status via an RGB LED
- runs the Time-Delta Kinematics state machine (non-blocking, 50Hz PWM) proven on the ESP32 prototype
- PiCam, mic, and speaker/amp for perception and expression
- Web dashboard + Bluetooth PS4/PS5 controller RC driving
- Hosts "PicoClaw," a lightweight AI agent for autonomous behavior
- Learned locomotion: reinforcement learning in simulation for disturbance rejection ("respond to sudden movements") and terrain traversal, with sim-to-real transfer
- LLM-as-planner: natural-language commands ("push the ball in front of you") turned into robot actions via a skill library, running on the Zero 2W
The architecture is intentionally two-layered (real-time Pico + high-level Zero 2W) so the platform scales from a simple walker to an AI companion without redesigning the core.
This project is my deliberate mechatronics learning vehicle. Mechanical design is my strength; the focus areas I want to grow are:
- Electrical design: power distribution, grounding, signal vs. power conductors
- Control systems: sensor fusion, inverse kinematics, PID, gait generation
- Programming: real-time embedded firmware, later computer vision + AI orchestration
I am documenting every decision with its why, so this repo teaches the reasoning, not just the result.
| Part | Role |
|---|---|
| Raspberry Pi Pico (MicroPython) | Real-time controller: servo PWM, IMU, OLED, LED |
| Raspberry Pi Zero 2W | High-level brain: camera, mic/speaker, RC, AI agent |
| UART bridge (Zero GPIO14/15 ↔ Pico GP0/GP1) | Null-modem crossover link between the two boards |
| 12× MG996R servos | 4 legs × 3 joints (3 DOF/leg) |
| MPU6050 | IMU (accel + gyro) over I²C, balance input |
| Mini OLED (SSD1306, I²C) | The "face": animated expressions |
| 1× WS2812 addressable LED | Status / mood indicator |
| Custom 3-cell salvaged laptop battery pack | Power source |
| 2× XL4016 buck converters | Two-rail power: servo rail (~7.2 V) + logic rail (5.0 V) |
| Bulk caps, fuse, switch | Power conditioning + protection |
| PLA chassis & legs (printed on A1 Mini) | Structure; custom 12-servo chassis in progress |
Note: this replaces the original single-ESP32/8-servo prototype (see Progress Log below). That build proved out the power system and control loop before the pivot to the dual-board, 12-servo architecture.
A battery pack feeds two independent buck converters:
- Servo rail (XL4016 #1) set to ~7.0–7.2 V, with bulk capacitors placed at the servo power bus
- Logic rail (XL4016 #2) set to 5.0 V, feeding the Pico and Zero 2W
Why two rails: servo current spikes during a gait would otherwise brown out the logic boards and cause phantom "firmware" bugs. Splitting them is the single most important power decision.
Key principle: power voltage ≠ signal voltage. A servo's power (7.2 V) and its PWM control signal (3.3 V logic) are separate. The 7.2 V must never reach a Pico/Zero pin; the rails meet only at common ground.
Also: shared common ground everywhere; inline fuse + switch on the pack; low-battery monitoring/cutoff planned via an ADC voltage divider.
The Pico runs the real-time control loop:
- Sense: read the MPU6050
- Think: sensor fusion → gait → inverse kinematics → balance correction
- Act: write all 12 servo angles
It uses a non-blocking, Time-Delta Kinematics state machine (proven on the ESP32 prototype) instead of blocking delay()/sleep() calls, which break balance and cause desync/stalls. Cosmetic output (OLED face, LED) runs on a slower, separate timer.
The Zero 2W runs the high-level brain: camera/mic/speaker I/O, the web dashboard, Bluetooth RC, and (eventually) the PicoClaw AI agent, talking to the Pico over the UART bridge.
Concepts in play: fixed-timestep loops, complementary-filter sensor fusion, 2-link inverse kinematics, proportional/PID control, state machines, UART bridging between boards.
The roadmap tracks progress as it actually happens rather than a pre-written day-by-day script. The architecture changed mid-build (single ESP32 to dual-board Pi Zero 2W + Pico), and a fixed checklist couldn't keep up. Completed work moves into Progress Log in the order it happened. Future Goals is the current wishlist, reprioritized as the build teaches us things.
Bench bring-up (single ESP32 era)
- 3S pack, fuse, switch, both XL4016 buck converters tuned to 7.2 V and 5.0 V rails
- ESP32 booted from 5 V rail; GPIO blink, OLED over I2C, WS2812 cycling colors
- Logic rail current draw verified (<500 mA) with OLED/WS2812 running
- Single servo on 7.2 V rail swept 0–180° from ESP32, pulse range tuned
- MicroPython + wireless web dashboard on ESP32 (glassmorphic UI, OLED emotive faces, WebREPL OTA)
- Servo rail buck converter soldered in; two 360° continuous servos driven from web dashboard
- Sentry tracker dashboard: dual-axis positional servos, non-blocking event loop + Time-Delta Kinematics state machine (fixes desync/stall issues from blocking
s.accept()/time.sleep())
Architecture pivot: dual-board (Day 4, 2026-07-04)
- Procured hardware for 12x MG996R servo build; committed to Pi Zero 2W (brain) + Pi Pico (real-time controller) architecture
- Flashed fresh MicroPython v1.23.0 to Pico via OpenOCD/SWD
- Wired Zero↔Pico UART bridge (null-modem crossover), wireless REPL over
/dev/ttyS0verified - Fixed
core_freq=250UART baud drift on Zero, fixed RP2040os.dupterm()slot crash - Built
ai/tools/upload_to_pico.py: host → SSH → Zero → raw-REPL upload pipeline - Blink LED test uploaded to Pico and verified end-to-end through the full pipeline
- MPU6050 + 2-servo gyroscope stabilization: complementary filter, slew-limited PID, measured (not assumed) servo axis mapping
- OLED (SSD1306) sharing the I2C bus: real-time 3D orientation cube from accel + gyro fusion
- Live PID-tuning web dashboard (
gimbal_server.pyon Pico + Flask dashboard on Zero over USB serial), verified end-to-end; root-caused an intermittent "commands not sticking" bug to a USB brownout under active servo load, not a software bug - Built
esp32_servo_tester/to validate MG996R servo health before mounting; fixed aparse_queryrequest-target bug; validated ESP32 -> D26 -> servo chain end-to-end - Diagnosed 2 earlier dead servos as voltage kills (MG996R clones ~4.8-6.0 V vs the 7.2 V rail); flagged dropping the servo rail toward ~6 V as an open investigation
- Recover from Day 7 incident: ESP32 DevKit + one servo destroyed by a reverse-polarity connection (VCC/GND swapped while powered); replace hardware, add reverse-polarity diode on servo VCC, resume servo validation at 5-6 V
Mechanical: 8-servo MVP chassis (Day 8, 2026-07-10/11)
- Basic CAD finished in OnShape for the 8-servo (2 DOF/leg) MVP chassis, with mounting for 8 servos + MPU6050 + Pi Pico + Pi Zero 2W
- Chassis printed on the A1 Mini
- Partial assembly: some servos mounted, MPU6050 and Pi Pico mounted to the frame; Pi Zero 2W mount designed but not yet installed
- Finish mounting remaining servos; wire Pico to servos + MPU6050 on the real chassis and run a first stand/servo-sweep test
- Mount and wire the Pi Zero 2W; re-establish the UART bridge on the assembled robot
The three tracks below (ecosystem, mechanical, channel) run in parallel rather than one-at-a-time, so nothing sits idle for weeks. Control software and mechanical design stay hand-led. PicoClaw is a small parallel thread: a personality for the robot that gets scaffolded early and develops its own character as the build progresses, not the thing driving these phases.
Near-term
- MPU6050 + servo gyroscope test on Pico (manual, proves the hardware): wire MPU6050 to Pico I2C, compute pitch/roll (simple atan2), drive 2 servos as proportional tilt correction, add OLED live pitch/roll readout
- Set up the channel: name, banner, short intro/teaser video explaining the project
- First video: "it reacts to gravity", gyro test footage
- PicoClaw v0: small agent scaffold on the Zero 2W (a personality/highlight thread, not a control-software owner)
Chassis and electronics
- Servo calibration/trim table, standPose()
- 8-servo (2 DOF/leg) MVP chassis CAD + printed on A1 Mini, partially assembled (servos + MPU6050 + Pico mounted; Zero 2W pending)
- Custom 12-servo (3-DOF/leg) chassis CAD, printed on A1 Mini
- Migrate electronics from breadboard to perfboard, common ground across all rails
- Zero 2W peripheral smoke tests: PiCam, mic, speaker/amp
- Second video: the ESP32-to-dual-board pivot story
Full-robot bring-up
- Assemble 12 servos onto the printed chassis, verify range of motion / no binding
- Complementary filter sensor fusion + 2-link IK per leg
- Gait generation (phase clock, static-stable creep gait, turning)
- Third video: "it stands for the first time"
- Video: "first steps, it barely works"
Later
- Closed-loop balance (PD controller), OLED affective states, WS2812 mood indicators, low-battery behavior
- PS4/PS5 controller RC driving over Bluetooth
- Milestone video: RC-driven walk demo
- PicoClaw grows into small autonomous behaviors and commentary as its personality thread matures, still a highlight, not the main event
Dual-board era (Day 8). OLED orientation cube, live PID dashboard, and ESP32 servo tester are built; the 8-servo MVP chassis is CAD'd, printed, and partially assembled (servos + MPU6050 + Pico mounted, Zero 2W pending). Open items: recover the Day 7 reverse-polarity incident (replace ESP32 + servo), stabilize the servo power rail (7.2 V vs MG996R 4.8-6.0 V), and wire the Pico to the chassis servos/IMU for a first stand test.
Parts of the code, scripts, and documentation in this repository have been written or scaffolded with the assistance of an AI coding agent. The architecture, goals, and mechanical design remain strictly human-led.
Open-source (hardware + firmware + software). License TBD.