Circuit and wiring

AI-generated and unbuilt. Nothing on this page has been wired, powered or measured. Every number is tagged [D] datasheet or seller listing, [E] estimate, or [C] chosen by this design. Treat the meter readings in the bring-up as gates: do not move to the next step until you get the reading the table gives.

This page takes you from a bag of parts to a robot that answers the laptop. You get the whole circuit in one picture, where every board sits on the spine, a point-to-point wire list, the power budget, and a bring-up sequence with the meter reading you should see at each step. The reference (pin map, decay mode, wheel sensing, IMU, numbers to measure) sits at the end.

What you are building

Drawings: schematic.svg (the circuit) and wiring.svg (where each board sits, from the CAD, and the main wire runs). The netlist, pin map, wire list and power budget in machine-readable form: electronics.json. All three come from one model, docs/tools/gen_electronics.py, which reads the board positions from cad/tailwhip.py and checks that every net is drawn at both ends, every off-board net has a wire, and no labels overlap.

How it works

Two 18650 cells in a series holder sit in the battery sleeve on top of the spine (7.4 V nominal, 8.4 V full). The cells have no protection of their own, so the first thing their current meets is a 2S BMS with balancing (U3). It cuts off at about 2.5 V per cell, on a short, and on over-current, and it trickles the higher cell down while charging. A charge jack (J1) hangs off the BMS output, so the pack charges in place with the robot switched off.

From the BMS the current goes through a 3 A resettable fuse (F1) and the power switch (SW1) to the switched battery rail, VBAT_SW. Three things hang on it:

• the MX1508 motor driver (U4), straight from the battery, for the two TT motors;
• Mini360 buck U1, set to 5.0 V, for the ESP32 (and later the ESP32-CAM): the logic rail;
• Mini360 buck U2, set to 5.0 V, for the two servos, with 470 µF across its output: the servo rail.

A 100k/33k divider scales the battery to under 2.1 V for the ESP32's ADC on GPIO36.

The ESP32 on the back of the spine drives the MX1508's four inputs with 20 kHz PWM, the two servo signals at 50 Hz, and reads the MPU-6050 on the motor web over I2C at 400 kHz. Two TCRT5000 IR modules on posts look at the 16-window rings glued inside the wheels; their digital outputs go to GPIO34 and GPIO35 (32 edges per wheel turn).

A small junction board (JB, about 13 x 20 mm of perfboard, 5 x 8 holes) sits on the spine front beside the MX1508. It carries the servo rail (C1 and two 3-pin servo headers), the battery divider (R1, R2, C2) and the two IR pull-downs (R3, R4), so every small part lives in one place and the ESP32 connects to it with Dupont leads.

A second ESP32, the bridge, sits on the laptop's USB. It copies state packets from ESP-NOW to serial and command packets from serial to ESP-NOW. The Software page describes the programs and packets.

Why the circuit looks like this

Parts on this page

Per robot. Sources and prices are on the Parts page.

Battery safety and charging

Read this before you put cells in the holder.

• The cells are unprotected. Nothing inside them stops an over-discharge, an over-charge or a short. The BMS does that job, so the BMS goes on before anything else and nothing ever connects to the cells except through it.
• Use genuine high-drain cells, a matched pair. Same model, same age, voltages within 0.05 V of each other before they go in. Never "UltraFire", "GTF" or "9900 mAh" cells; buy from a battery specialist (see Parts). A good cell (Molicel P28A, Samsung 25R or 30Q, Sony VTC6) has a low internal resistance, so the pack sags little when the motors pull.
• Check each cell before it goes in: 3.0 to 4.2 V on the meter. Retire any cell under 2.5 V, dented, with a torn wrap, or warm at rest.
• Wire the BMS in this order: B- first, then BM (the strap joining the two cells), then B+. Undo it in the reverse order. Many 2S boards show 0 V on P+/P- until a charger has been connected once; that is normal.
• Charge with the robot switched off, through J1, with an 8.4 V CC/CV charger at about 1 A, on a non-flammable surface, attended. The balancing BMS evens the cells at about 40 mA [D], so check the two cell voltages once a month: if they differ by more than 0.05 V at full charge, charge each one in a single-cell smart charger.
• Switch off at the end of every run. After the firmware's low-battery cut-off the ESP32 sleeps, but the bucks, the IR LEDs and the regulators still draw roughly 40-60 mA [E]. The BMS stops it at about 2.5 V per cell, which the cells survive, but it is a deep discharge you do not want.
• There is no reverse-polarity protection apart from the Pololu MOSFET switch (it has some). Check polarity with the meter at bring-up step 2, before the boards are connected.

Wiring

Where everything sits

The positions come from cad/tailwhip.py (body frame: x forward, y left, z up the body, origin on the axle). See wiring.svg.

The motors stand vertically either side of the core, the IMU is zip-tied to the pad on the front of the motor web (chip facing forward, its x axis up the body), the IR modules screw to their posts beside each wheel, the tail servo sits in the hip block and the pan servo on the sleeve roof.

Build the junction board

A scrap of perfboard 5 holes wide and 8 long. Lay it out like this (top = up the body), solder, then zip-tie it to the spine front at the +y side, beside the MX1508:

1. Two 3-pin male headers side by side at the top: T (tail) and H (head). Pin order on each, left to right: signal, +5 V, GND (the servo plug's orange, red, brown).
2. Join both +5 V pins to a 5V_SERVO bus row and both GND pins to a GND bus row on the back.
3. C1 470 µF between the two bus rows, stripe (negative) to GND. Bring in S1 (red, 22 AWG) from U2 OUT+ and S2 (black) from U2 OUT- on the same rows.
4. R1 100k from a pad for the battery tap (P13) to a VSENSE pad; R2 33k from VSENSE to GND; C2 100 nF beside R2.
5. R3 100k from an IR_L pad to GND, R4 100k from an IR_R pad to GND.
6. Short tails of 26 AWG to Dupont female housings for the ESP32 side (J1-J6 below), and solder pads for I7, I8 (IR outputs).

Check with the meter before plugging anything in: 5V_SERVO to GND reads the capacitor charging (rising), not 0 Ω; VSENSE to GND reads about 25 kΩ (33k in parallel with 100k).

Wire list

Every wire, point to point. Lengths are estimates from the CAD positions plus slack; cut long and trim.

Motor polarity does not matter at the wiring stage: bring-up step 12 checks the direction and the firmware command flip l / flip r fixes it without re-soldering.

Power budget

Assumptions: both rails at 5.0 V, buck efficiency 85 % [E], pack 7.4 V. Currents for the ESP32, MPU-6050, SG-90 and TT motor are from datasheets and listings [D]; what the robot draws while doing each thing is an estimate [E] until you measure it (bring-up step 15).

Loads per rail

Battery current

With slow decay, the battery supplies the motor current only during the drive part of each PWM cycle, so battery current ≈ duty x motor current. Two 2800 mAh cells (P28A) give about 2.4 Ah usable [E]: three to four hours of mixed bench and balancing work.

What gives out first, in order

1. The MX1508's weaker channel. The MX1508 datasheet rates one channel at 1.5 A continuous and the other at 0.8 A continuous [D], and modules rarely say which is which. A TT motor stalls at about 1.5 A at 6 V [D]. Short stalls (a second while catching a fall) are fine; a robot pushing against a wall for 10 s is not. If one side starts cutting out when hot, swap in a DRV8833 or TB6612FNG board (both about 1.2-1.5 A continuous per channel, same two-input control).
2. The servo buck U2. About 1 A continuous [E]. Both servos stalled pull 1.3 A [D]. The tail servo holding the robot on its tail pulls about 0.25 A [E]. If the tail twitches or goes limp when the head moves, the rail is sagging: fit a larger buck (SPEC risk table), not a second Mini360 in parallel.
3. The logic buck U1 at stage 4. ESP32 plus ESP32-CAM is about 0.4 A typical, 0.66 A peak [D]. Fine for one Mini360. If the camera browns out anyway, give it its own (third) Mini360.
4. The polyfuse. 3 A hold, 6 A trip [D]: 4 A for a second will not trip it, but a hot fuse derates, so a long stall can. It resets once cool.
5. The cells. 4 A is under 2 C for a 2800 mAh cell; any genuine high-drain cell is rated 15 A or more [D].

Voltage sag

Two good cells (about 15-20 mΩ each [E]), the BMS MOSFETs (about 10 mΩ [E]), the fuse (about 50-100 mΩ [D]) and the leads come to roughly 0.15 Ω. That is 0.1 V at 0.6 A and 0.6 V at 4 A. The firmware measures VBAT every 10 ms and scales the duty, so a sagging pack does not change what u = 1 means until VBAT falls below 6.0 V (flag volt_clip).

Mini360 limits

No manufacturer datasheet exists for "Mini360"; it is an MP2307-type synchronous buck on a 17 x 11 mm board [D listings]. Input 4.75-23 V, 340 kHz, adjustable output by a tiny pot. Listings say 1.8 A continuous and 3 A surge; builders report it gets hot above about 1 A without airflow, so this design treats 1 A as the continuous limit [E]. It ships set to a random voltage, often 10 V or more, which kills an ESP32 or a servo at once. Set it with nothing on its output (bring-up step 4). The pot is touchy; turn it in small steps and give the meter a second to settle.

Set up the firmware toolchain

You flash four sketches: i2c_scan, servo_center and tailwhip_robot to the robot's ESP32, and tailwhip_bridge to the bridge. No extra libraries are needed.

brew install arduino-cli
arduino-cli core update-index && arduino-cli core install esp32:esp32     # 3.3.12 tested to compile
arduino-cli compile -b esp32:esp32:esp32 firmware/tailwhip_robot
arduino-cli upload  -b esp32:esp32:esp32 -p /dev/cu.usbserial-XXXX firmware/tailwhip_robot

In the Arduino IDE the board is "ESP32 Dev Module" (FQBN esp32:esp32:esp32) with its defaults. If upload fails at 921600 on a CH340 board, set Upload Speed to 460800. If it hangs at "Connecting...", hold BOOT.

All four sketches compile with zero warnings on core 3.3.12 (--warnings all). The code also uses the core 2.0.x API where the two differ (LEDC, ESP-NOW receive callback). Sizes on 3.3.12:

ROBOT_ID and WIFI_CHANNEL live in tailwhip_common.h, which exists in both the robot and bridge sketch folders. The two copies must be identical; host/test_protocol.py checks.

Bring-up, step by step

Each step has an expected reading. Do not move on until you get it. Motors unplugged (JST-XH) and servos unplugged until the step that needs them.

Once step 15 passes, do the bench measurements (host/bench.py, Software), then milestone 1 with host/drive.py.

Troubleshooting

Reference