Quadruped Robot - MK-II

Overview

This robot was built as a serious hobby project to apply and deepen my understanding of electronics, embedded systems, software architecture, and mathematics, while also serving as a platform to experiment with core robotics concepts.

Rather than focusing on a single demo or fixed behavior, the goal was to build a system that could evolve — something flexible enough to test ideas, refine models, and grow over time.

Leg model and kinematics

Each leg is modeled as a 3-DOF mechanism, consisting of a coxa, femur, and tibia.

Instead of controlling joint angles directly, leg motion is defined by specifying the desired foot position in Cartesian space. These positions are converted into joint angles using inverse kinematics.

This approach makes the movement of the robot dynamic and makes movement easier to reason about geometrically.

Dynamic, parameter-driven motion

The kinematics model makes the robot fully dynamic — nothing is hardcoded.

Walking motion is controlled using a stride vector:

  • The vector length defines the stride distance
  • The vector angle defines the direction of movement

Additional parameters can be adjusted at runtime, including:

  • robot height
  • stride length
  • leg lift height during the walk cycle
  • overall movement speed

Because movement is parameterized rather than scripted, changing how the robot walks does not require rewriting motion logic.

Software architecture

All control logic runs on the software and firmware side of the robot. The system is designed using clear, modular layers, inspired by established software architecture principles.

Core components include:

  • ServoDriver
  • LegDriver
  • Trajectory
  • MotionController
  • RobotController

Hardware abstraction and leg control

The ServoDriver handles hardware-specific responsibilities. It receives joint angles as input and uses the appropriate low-level drivers to control individual servos.

The LegDriver is completely hardware-agnostic. It operates purely on x, y, z foot positions, converts them to joint angles using the inverse kinematics model, and forwards those angles to the corresponding ServoDriver instances for the coxa, femur, and tibia.

This separation ensures that hardware changes do not affect higher-level motion logic.

Trajectories and motion execution

How a leg moves through space is defined by a trajectory. A trajectory describes the path a foot should follow.

Supported trajectory types include:

  • linear
  • Bézier
  • circular
  • other parametric paths

Individual trajectories — or groups of trajectories — are executed by the MotionController.

The MotionController is aware of speed, distance, and timing, and ensures smooth execution of motion. It can also apply easing functions to control acceleration and deceleration.

Remote control layer

A dedicated remote control layer runs on a separate core of the CPU.

This layer is responsible for:

  • receiving data via Bluetooth
  • parsing incoming commands
  • forwarding structured commands to the main control core

It includes modules such as BluetoothController and CommandParser, keeping communication concerns isolated from motion and control logic.

Modularity and extensibility

This modular architecture makes it easy to integrate new features or sensors with minimal changes.

The robot can be controlled not only by the Android app, but also by external systems such as:

  • a different microcontroller
  • scripted control systems
  • AI-based controllers

Control interface

A custom Android application is used to send high-level commands to the robot as structured strings. The robot parses these commands and executes them through its control system.

Detailed documentation for the Android app is provided separately here..

Hardware configuration

  • Microcontroller: ESP32-WROOM-32
  • Servo controller: PCA9685
  • Servos: DS Power 21G
  • Power: 2 × 3.7V Li-ion batteries
  • Servo power regulation: 20A buck converter
  • MCU power regulation: 3A buck converter

Closing note

This project represents a system I am genuinely proud of — not because it is finished, but because it is well-structured, extensible, and grounded in fundamentals.

It serves both as a functional robot and as a platform for continued learning and experimentation in robotics.