Spider-Like Robot with OLED Display

This four-legged robot was built with Jingyi Yang as the final project for PHYS 242: Electronics at Oberlin College. Each leg has three servo-driven joints, giving the Arduino Nano 12 actuators to coordinate. A small OLED adds an expressive face while the mechanical, electrical, and software layers turn a collection of printed parts into a characterful robotics prototype.

Design brief

A wheeled platform can move with only two motor channels. This design deliberately takes the harder route: four articulated legs that must lift, swing, land, and support the body in a useful sequence. The project therefore focused on four connected problems:

1. Mechanical range: design and print hip, knee, and foot linkages that move without colliding or binding.
2. Repeatable control: calibrate 12 inexpensive servos and keep each joint’s current angle in software.
3. Power and wiring: distribute regulated 5 V power while routing 12 control signals around a compact body.
4. Personality and interaction: render a custom bitmap face and prepare a serial/Bluetooth control path.

Mechanical and electrical architecture

Hardware choices

Servo pin map

The firmware treats the robot as a two-dimensional array: four legs, each containing a hip, knee, and foot. Keeping the wiring table in the same shape makes debugging much easier than tracking 12 unrelated variables.

How the robot was programmed

The main sketch is organized around the physical structure instead of giving every motor a separate name. A 4 × 3 servo matrix and a matching pin matrix let the same movement function address any joint by leg and joint index.

Servo joints[4][3];
const int jointPins[4][3] = {
{2, 3, 4}, {8, 9, 10},
{5, 6, 7}, {A1, A2, A3}
};

Mirroring the neutral pose

The servos are physically mirrored across the chassis, so identical angle commands would not create a symmetric stance. The sketch compensates with complementary values such as 180 - startAngle for opposite joints. This keeps the higher-level gait code readable: it can think in terms of legs and joint targets while the initialization handles orientation.

Smoothing each joint movement

Rather than jumping directly to a target angle, the movement helper advances one degree at a time and updates the stored position after the move:

while (current != target) {
current += (current < target) ? 1 : -1;
joints[leg][joint].write(current);
delay(10);
}

This reduces abrupt motion and made early testing easier to observe. The tradeoff is that delay() blocks the controller, so one joint completes before the next command progresses. A future version could replace this loop with a timer-driven state machine to update several joints together and remain responsive to new commands.

Building a diagonal gait

The forward routine alternates diagonal pairs: front-right with back-left, then front-left with back-right. For each pair, the knees lift, the hips swing, the knees lower, and the joints return toward their starting pose. That sequence aims to preserve support on the opposite diagonal while moving two legs.

movePair(frontRight, backLeft);
movePair(frontLeft, backRight);

The production sketch expands those two conceptual calls into explicit servo commands. Hip and knee joints drive the current forward sequence; the foot joints are attached and tracked but are not yet used in that gait. Keeping foot control in the data model leaves room for better ground clearance and body leveling later.

Serial control and the OLED face

The current interaction loop uses a simple character command: receiving f over serial triggers the forward sequence. A SoftwareSerial bridge for an HC-06 Bluetooth module is present as a prototype, but it is not yet called by the main loop. That separation was useful during development—motion could first be verified over USB before adding wireless behavior.

if (Serial.read() == 'f') {
moveForward();
}

The face is stored as a 128 × 64 bitmap in program memory and drawn to the OLED during setup. Storing the image in flash avoids spending the Nano’s limited working memory on a full-screen graphic.

display.drawBitmap(0, 0, faceBitmap, 128, 64, WHITE);
display.display();

Testing and iteration

The robot was brought up in stages rather than powered as a complete 12-servo system on the first attempt:

1. Individual servos were exercised with a separate calibration sketch to confirm direction and safe travel limits.
2. PLA joints were printed, fitted, and checked for mechanical interference.
3. Servo labels were matched to the physical legs and the Arduino pin map.
4. Breadboard wiring and continuity were checked before integrating the regulator board and OLED.
5. The complete assembly was tested with slow, observable motion sequences so binding or reversed joints could be caught quickly.

This process exposed the central constraint of the prototype: the assembled robot was heavier than the small servos and sequential gait code could comfortably move. The system demonstrated coordinated joint commands and the custom OLED face, but the planned walking patterns were too slow and did not produce reliable locomotion. That result is more useful than claiming a finished gait—it identifies where the next engineering iteration needs to focus.

What I would improve next

• Reduce mass and joint friction: revise the printed linkages and body so more servo torque is available for lifting rather than supporting the frame.
• Use non-blocking motion: update all active joints on a shared time step instead of finishing one blocking sweep at a time.
• Tune the gait from measured poses: record safe joint limits and stance offsets per servo, then interpolate coordinated body trajectories.
• Strengthen power distribution: replace the breadboard layout with a completed PCB and a supply designed for the combined current transients of 12 servos.
• Complete wireless control: connect the existing Bluetooth bridge to explicit forward, backward, left, right, and stop commands.

The prototype succeeded as an electronics and robotics platform: it connected mechanical design, power regulation, multi-axis actuation, embedded graphics, and firmware architecture in one build. Its limitations also made the next design decisions concrete—lighter mechanics, simultaneous motion, calibrated gait generation, and more robust power delivery.