The Hardware

3.1 Documented from the outside

Anki released no service manual, no schematic and no component list for Cozmo, and Digital Dream Labs released none afterwards. Everything in this volume comes from one of three kinds of evidence: published teardowns, in which someone opened a robot and read the markings on the silicon; the reverse-engineered protocol documentation maintained by the pycozmo project, which establishes what the firmware exposes rather than what the parts are; and vendor marketing copy, which is useful for the fact that a feature exists and unreliable for its specification.

Where those disagree or fall silent, this volume says so. The list of things no source establishes is given in full at the end, because a reader comparing this dive against another reference deserves to know what was searched for and not found, rather than merely omitted.

3.2 The compute

Cozmo’s main processor is an NXP Kinetis K02, a 100 MHz ARM Cortex-M4 microcontroller with integrated flash and RAM, mounted on the head printed circuit board.

This is worth pausing on, because it is the single most important hardware fact in the dive. A Cortex-M4 at 100 MHz is a microcontroller, not an applications processor. It has no memory management unit, runs no operating system in the sense that a phone or a Raspberry Pi does, and could not conceivably run face recognition, path planning or a behaviour engine. Its job is real-time control: drive the motors, read the encoders, sample the sensors, paint the display, and move packets on and off the network.

Compare Vector, whose Qualcomm Snapdragon APQ8009 runs a quad-core Cortex-A7 at 1.2 GHz under embedded Linux. The difference is not incremental. It is the difference between a machine that can host its own intelligence and one that structurally cannot. Cozmo’s architecture is not a design compromise layered on top of a capable computer; the computer was chosen on the assumption that the thinking would happen elsewhere.

RAM and flash capacities are not established. The Kinetis K02 family spans several memory configurations, and no reachable source identifies which part was fitted.

3.3 The two radios

Cozmo carries two separate wireless subsystems serving two entirely different purposes.

An Espressif ESP8266EX with an accompanying Winbond flash chip provides Wi-Fi. This is the link to the app, and its configuration is unusual: the robot is the access point, not a client. Cozmo broadcasts its own network and the phone joins it. The protocol details are in Vol 4.

A Nordic nRF51822 handles Bluetooth Low Energy and, per teardown analysis, also carries pulse-width modulation output and quadrature demodulation for the motors. Its wireless role is the link to the three Power Cubes.

The consequence of this split is that the cubes are not on the Wi-Fi network. They are BLE peripherals paired to the robot directly. Any account of Cozmo that describes the cubes as talking to the phone is wrong; they talk to the robot, and the robot relays.

3.4 Drive and actuation

Cozmo moves on two rubber treads driven by two motors through a three-stage reduction gearbox. Steering is differential — the treads run at different speeds to turn, and in opposite directions to pivot in place. There is no steering linkage.

Magnetic encoders are fitted to the motor shafts, described in teardown as having two lobes each, providing the feedback for closed-loop velocity control. This is a meaningful detail: it means the robot knows how far its treads have actually turned rather than merely how long power was applied, which is what makes dead-reckoning navigation possible at all on a machine with no other position reference.

Two further motors serve the head tilt mechanism and the lift arm, the forklift-style manipulator at the front that raises, lowers, carries and stacks the Power Cubes. The lift is Cozmo’s only manipulator; there is no gripper and no wrist.

Gear ratios are not established in any reachable source beyond the description of the drive gearbox as three-stage.

3.5 Sensing

Cozmo’s sensor complement is modest and worth listing precisely, because the most common error made about this robot concerns what is absent.

Table 1 — Sensing

Sensor	Purpose
Camera	vision, delivered to the app for all recognition work
Cliff detector	downward-facing, stops the robot driving off a table edge
Accelerometer	orientation, pick-up and impact detection
Gyroscope	rotation sensing
Wheel encoders	odometry and closed-loop velocity
Backpack button	user input; hardware version 1.5 and newer
Battery voltage	on the robot and, separately, on each cube

3.5.1 There is no microphone

Cozmo has no microphone array and no voice input of any kind. It cannot hear, it has no wake word, and it cannot be spoken to. It has a speaker and is noisy, which appears to be the source of a persistent and widespread assumption to the contrary.

Voice interaction is Vector’s feature. Confusing the two is the single most common factual error about these robots in circulation, and it matters practically: a buyer expecting to talk to a Cozmo has bought the wrong robot.

3.6 The camera

The camera is mounted in the head assembly and is the robot’s only environmental sense of any richness. Its specification is more interesting than it first appears.

The firmware delivers 320 x 240 greyscale images. The sensor itself is reportedly 640 x 480, with the firmware exposing only the lower resolution; this higher figure is community-reported and is treated here as unverified. The sensor does see colour, but the firmware transmits greyscale only, to reduce the bandwidth required over the Wi-Fi link.

The optics give roughly a 60 degree field of view with a focal length reported around 290 mm in the calibration convention used by the community tooling. Critically, these parameters differ between individual robots and are measured at the factory per unit — the calibration is stored on the robot rather than assumed by the software.

The camera sensor part number is not established.

That a 2016 consumer robot performs face recognition on a 320 x 240 greyscale stream is a fair illustration of the whole design: the hard work is being done by an algorithm on a phone, not by an expensive sensor on the robot.

3.7 The display

The face is a 128 x 64 panel, identified in teardown as an in-plane-switching LCD, which is a better class of panel than the resolution suggests and explains the wide viewing angle that makes the robot readable from across a desk.

A detail from the community tooling is worth recording because it constrains anyone writing custom face graphics: to reduce burn-in, consecutive images are interleaved and only half the display’s rows are driven at a time, giving an effective vertical resolution of 128 x 32 in practice. The panel is monochrome; the colour display was one of the advertised changes for Digital Dream Labs’ Cozmo 2.0.

The display controller part is not established.

3.8 The Power Cubes

The three cubes are not passive props. Each contains a Nordic BLE radio, LED panels behind four translucent faces, what teardown identifies as probably an accelerometer on an unmarked part, and a user-replaceable cell on a spring terminal.

The division of labour is the same one that governs the whole machine: the cube reports its own motion and battery state over BLE and lights its own LEDs on command, but recognising a cube visually is done by the app’s vision stack, from the marker printed on its faces. The cube does not tell the robot where it is. The phone works that out by looking at it.

Cubes are the component most likely to be missing or dead in a second-hand purchase, and are covered again in Vol 6.

3.9 What is not established

The following are absent from every source reachable for this dive and are left explicitly unclaimed rather than estimated:

• Mass and physical dimensions of the robot. Widely circulated figures describe the retail packaging. See Vol 1.
• Battery chemistry and capacity. A runtime figure of around 45 minutes is quoted by secondary sources and is unverified.
• RAM and flash capacity of the Kinetis K02 as fitted.
• Camera sensor part number.
• Display controller part.
• Exact gear ratios beyond “three-stage” for the drive.
• The accelerometer part in the Power Cubes, which teardown could not identify from its markings.

A cooperative owner with a screwdriver and a scale could close several of these. They are listed as open items in Vol 8 rather than filled with plausible numbers.

Sources

• microcontrollertips.com, “Cozmo Robot, a distant relative of Vector: Teardown” — the Kinetis K02, ESP8266EX, nRF51822, the drive gearbox, magnetic encoders, the IPS panel, and the Power Cube internals.
• iFixit, “Anki Cozmo” device page — display resolution, sensor list, motor count.
• pycozmo documentation and repository — the supported sensor and actuator lists, the backpack-button hardware-version note, and the display interleaving behaviour.
• touretzkyds/cozmopedia wiki, “camera” — delivered and sensor resolution, greyscale transmission, field of view and per-unit factory calibration.
• anki.bot — the Cozmo 2.0 specification claims referenced for contrast.