// robots — bench log

A robot built almost
entirely from clones.

SMARS chassis, £36 of parts, and a paying customer's worth of debugging time. Here is exactly what that gets you.

This is the other half of Meldrino: hardware. A first robot, built from the cheapest parts that would plausibly work — a clone Arduino, a Chinese motor shield, geared motors without encoders, an ultrasonic sensor, a 9 V battery, and a chassis off a 3D printer. Total spend: £36.08.

It does not drive yet. Not because any one part is broken, but because of the tax that clone hardware charges: undocumented boards, wrong assumptions, and a wiring mistake that is easy to make and hard to see. This page is the honest log — what we used, what went wrong, and what happens next.

What went wrong What we do next
// the kit
Clone-grade, one part at a time.
UNO
Arduino UNO R3 — clone, £3.01
Not a real Arduino. An ATmega328P board with a Type-C socket and a CH340 USB-serial chip instead of the genuine ATmega16U2. Windows sees it as USB-SERIAL CH340, VID 1A86 / PID 7523, on COM5. It works — but no official branding, no official driver, and no assumption you can make about it is safe.
PWM
Keyestudio KS0489 4WD TB6612 shield — £13.79
The single most important part, and the one that cost us the most time. Two TB6612FNG motor drivers, but not driven from Arduino pins. An on-board PCA9685 PWM expander at I2C 0x47 feeds them: 8 of its 16 channels drive the four motors, two per motor. Rated 8–12 V in, up to 3 A, with an LM2596S-5.0 regulator on board. Cheap, capable, and almost nothing like the shield the tutorials assume.
6V
GA12-N20 geared motors — £7.98 the pair
6 V, 150 RPM, metal gearbox, PH2.0 plug. No encoders, so there is no odometry and no way for the robot to know how far it moved — that is a later upgrade, not an oversight. They are also 6 V parts running off a 9 V pack, so firmware holds cruise duty at ~66% to avoid cooking them.
SON
2 × HC-SR04 ultrasonic sensors — £2.40
The classic four-pin sonar. Acquired, wired next, and the basis of Stage 1 obstacle avoidance. Two of them because at this price, one is a spare.
9V
9 V 650 mAh rechargeable PP3 — £7.89
A snap-fit battery, which means the cable connecting it to the shield is something we made ourselves: a battery clip soldered onto a cut-down PH2.0 extension lead. That home-made cable is where this project went wrong. See below.
STL
SMARS chassis — 3D printed, ours
SMARS is an open-source printable robot platform, so the chassis is filament rather than money. The rest of the build's "free" parts are: no buzzer, no display, no encoders — the motor whine is the only feedback the robot has.
// what went wrong

Nothing is broken. Everything is undocumented.

Five separate problems, stacked on top of each other, each one looking exactly like a dead motor. This is the honest list — including the mistakes we made.

01
The Arduino IDE would not install
On this machine, the IDE refused to install at all. Rather than fight it, the whole toolchain moved to the command line: arduino-cli, the avr core, the Adafruit PWM servo-driver library and avrdude, installed portable from a zip. Same result as the IDE, none of the installer. The sketch compiles and uploads to COM5 from a shell — the workaround is now the permanent setup.
02
Every tutorial targeted a different shield
The usual Arduino-plus-motor-shield examples drive motors straight from digital pins — direction on D4, speed on D5. That is a different Keyestudio shield (an L298P design). This one puts a PCA9685 at I2C 0x47 in the middle, so pin-driven code cannot move a wheel no matter how correct it looks. The firmware had to be written for the PCA9685 instead. Cloning saved £10 and cost an evening of archaeology.
03
Nothing lights up — and that is correct behaviour
There is no power LED documented anywhere on this shield, and none on the battery. So "nothing comes on" is not a symptom here, it is normal. Meanwhile the one LED the Arduino does have, D13, ends up buried under the stacked shield and invisible. Both obvious diagnostics were useless; all feedback had to be moved to timestamped serial output instead.
04
No wheel turned on any channel — but the board was fine
A sweep drove all eight motor channels in turn, one at a time, for three seconds each. Nothing moved. Reading the PCA9685's own registers back proved the entire chain — Arduino, I2C bus, expander, PWM outputs — was working perfectly: MODE1 0x20 (awake, auto-increment), MODE2 0x04 (push-pull outputs), PRE_SCALE 0x05 (~1 kHz), and channel 0 reading back OFF = 40,10 (=2624 of 4095) when commanded. So the fault had to be downstream of the driver: battery power, or wiring. Which led to the real culprit.
05
A home-made battery cable, soldered in reverse
The 9 V clip has a red and a black wire. The cut PH2.0 extension lead also has a red and a black wire. They were joined red-to-red and black-to-black — the obvious thing to do, and wrong, because the lead's colours do not match the shield's socket the way it assumes. The result: the battery's positive was being delivered to the shield's negative input, so the reversing protection simply refused to power the motors. The sockets are keyed, so the plug cannot be turned around — it has to be re-pinned or re-soldered the right way round. Multimeter first, then re-terminate.
06
The cost, stated plainly
£36.08 of parts. Roughly one evening lost to problem 2 alone, and the last hour to a two-wire cable. None of it is damage; all of it is fixable. Clone hardware is genuinely good value — it just arrives without documentation, and you pay for that in time instead of money.
// what we do next
Get it moving, then make it smart.
1
Fix the polarity, for real
Find the shield's positive input contact with a multimeter (continuity to the electrolytic capacitor's positive leg, or across the on/off switch), then re-pin the PH2.0 plug or re-solder the cable so the battery's red wire lands on it. Power up and confirm.
2
Map the channels to the wheels
Re-run the eight-channel sweep with the battery connected and write down which PCA9685 channel pair moves which wheel, which way. Without that map, "forward" is a guess.
3
Wire the sonar — Stage 1
HC-SR04 into the shield's 3-pin header: 5 V, GND, TRIG to D11, ECHO to D10. Then the robot drives, watches, and stops or turns before it hits anything. That is the first genuinely autonomous behaviour.
4
Then the upgrade path
Stage 2 — ESP32 with a PCA9306 level shifter and Bluetooth, so it drives from a phone. Stage 3 encoders, so it can measure distance. Stage 4 a servo-mounted sensor that looks around. Stage 5 an IMU so it knows which way is up. Stage 6 an LD06 LiDAR, at which point it is mapping a room.
4W
Then the honest question
Four-wheeled 6 V motors, one 650 mAh battery, no encoders: fine for a fun obstacle-avoider, not a mapping platform. Every upgrade above changes the electronics but not the drivetrain — so stage 3 onwards may well mean new motors, and the battery will become the limiting factor long before the software is.
// receipts

What we can actually prove.

Claimed evidence, not optimism: the board enumerates as USB-SERIAL CH340 on COM5 (VID 1A86, PID 7523); the shield answers an I2C scan at 0x47; the PCA9685's registers read back exactly as commanded (MODE1 0x20, MODE2 0x04, PRE_SCALE 0x05, channel 0 OFF = 40,10); the firmware builds at 10,620 bytes — 32% of flash — and uploads cleanly with no IDE involved; and the diagnostic sweep really did run across all eight channels for three seconds each with zero movement. That last one is the result that matters, because it is what pointed at the cable.

Next update on this page: a wheel turning.

The £36 robot.

Clone parts, real debugging, and no reason it should not work. Follow the build as it moves.

See the rest of Meldrino