The Split Brain — Robot, Engine, and the Link Between Them

4.1 The central fact

Cozmo is not a robot that connects to an app. Cozmo is a robot that is completed by an app. Without one, the machine has no personality, cannot recognise anything, cannot plan a path, and will not play. The protocol documentation is explicit about the hierarchy, and its vocabulary is the clearest statement of the design anyone has written:

The Cozmo app (aka “engine”) acts as a client and Cozmo (aka “robot”) acts as a server.

The robot is the server. It holds the hardware and answers requests about it. The app is the client, and the app is where the thinking happens.

4.2 What runs where

The split is close to absolute, and it is worth setting out in a form that can be checked against the pycozmo feature lists, which enumerate the two halves separately under the headings “on-board functions” and “off-board functions”.

On the robot. Wi-Fi access point operation. Bluetooth Low Energy to the cubes. Localisation and path tracking — that is, executing a path once given one. Non-volatile storage. Over-the-air firmware update. Direct control of every motor, the display, the speaker, the backpack LEDs, the infrared LED and the cube LEDs. Reading every sensor.

On the phone. Procedural face generation. The animation system. The personality engine. Behaviours. Motion detection. Object, face and pet detection. Cube marker recognition. Face recognition. Expression estimation. Camera calibration. Navigation — that is, deciding the path. Text to speech. Songs.

Read that second list again with the question “what makes Cozmo feel alive?” in mind. Every single answer is on it. The personality, the animated eyes, the recognition of a returning human face, the emotional reaction to being picked up — all of it is software running on a phone, driving a peripheral over a network socket.

This is why Cozmo’s character survives its manufacturer and why it is simultaneously so fragile in a way that has nothing to do with the robot’s condition. The robot is durable consumer hardware. The personality is an installed application.

4.3 The link

The network arrangement is the mechanism that makes the split work, and its details matter to anyone intending to program the robot.

Cozmo broadcasts its own Wi-Fi network. The SSID follows the pattern Cozmo_XXXXXX, where the suffix is uppercase hexadecimal. The robot runs a DHCP server and hands out addresses in 172.31.1.0/24, taking 172.31.1.1 for itself. The phone or computer joins that network as a client.

The pre-shared key is not printed on the robot. It is displayed on the robot’s own screen, revealed by placing Cozmo on its charging platform and lifting the arm — a physical gesture that functions as proof of possession. There is no account, no registration and no pairing service.

Communication runs over UDP on port 5551, using what the protocol documentation describes as a UDP-based variant of the selective-repeat automatic-repeat-request scheme — that is, a reliability layer built on top of an unreliable transport, rather than TCP. Frames carry the seven-byte identifier COZ\x03RE\x01. The engine sends a ping every five seconds, and if the robot does not receive one for more than five seconds it drops the connection.

4.3.1 What that design implies

Several consequences follow directly, and they are the practical heart of this dive.

There is no internet in the path. The device controlling Cozmo has joined the robot’s network, which has no uplink. While the app is driving the robot, the phone generally cannot reach the internet at all. Owners routinely see a “no internet” warning during play, and it is expected behaviour rather than a fault.

No vendor server can be in the path, because no route to one exists. This is not a policy choice that a company could later reverse, or a feature that could be disabled remotely. It is a consequence of the network topology.

The five-second ping bounds the failure mode. A Cozmo that loses its engine stops within seconds rather than driving off unattended.

Range is the robot’s, not the router’s. Wi-Fi coverage depends on the ESP8266 in the robot, and the phone must be near it.

4.4 Why this outlived the company

Set the architecture against the events of Vol 2 and the result falls out arithmetically.

Table 1 — Why this outlived the company

What failed	Did Cozmo need it?
Anki as a going concern, April 2019	No
Anki’s cloud services	No — never in the path
Digital Dream Labs’ servers	No — never in the path
Vendor account or login	No — none exists
An internet connection	No — structurally excluded during play

Compare the same table for Vector, where speech recognition and knowledge answers were cloud services, and the shutdown removed them until the community rebuilt a local replacement. Cozmo needed no rescue because there was nothing to rescue.

It is worth being clear that this was not foresight. Nothing suggests Anki chose a phone-tethered architecture in 2016 in order to outlive itself. The choice was economic: offloading vision to a device the customer already owned let the robot ship with a hundred-megahertz microcontroller instead of an applications processor, at a USD 179.99 price point. Durability against corporate failure was a side effect of building to a budget.

That is the genuinely transferable lesson, and it generalises well beyond robot toys: a product’s survival prospects are determined by where its dependencies live, not by how good its vendor’s intentions are. Cozmo’s dependency lives on the owner’s phone. Vector’s lived in a data centre. Both companies died. Only one robot went quiet.

4.5 The dependency that did not disappear

Cozmo’s dependency did not vanish. It moved onto the app, and the app is not maintenance-free.

A mobile application must be kept compiling against current operating systems, must satisfy store review policy, must be re-signed, and must continue to support the hardware people actually own. An abandoned app does not stop working the day it is abandoned; it stops working gradually, as the platform beneath it moves, and then one day it cannot be installed on a new phone at all.

This is a slower and more forgiving failure than a server being switched off. A cloud shutdown is instantaneous and total; an app decays over years, and an already-installed copy on an already-working phone can keep running long after the store listing is gone. But it is a real dependency with a real end state, and it is the reason a reverse-engineered library that has not been touched since 2020 is the most strategically important piece of software in this dive. Vol 5 covers it.

4.6 Cross-reference

The Vector dive in this hub documents the opposite arrangement in detail — the cloud voice stack, what its shutdown removed, and the wire-pod local server that replaced it. The two dives are best read as a matched pair: the same company, the same era, two architectural choices, and two completely different outcomes for the owner.

Sources

• pycozmo protocol documentation (pycozmo.readthedocs.io, “Cozmo Protocol”) — the engine-and-robot client/server relationship, the Cozmo_XXXXXX SSID pattern, the 172.31.1.0/24 addressing, the 172.31.1.1 robot address, UDP port 5551, the COZ\x03RE\x01 frame identifier, the selective-repeat scheme, and the five-second ping and timeout.
• pycozmo documentation, “Cozmo Functions” — the on-board and off-board function lists that establish which half of the system performs each task.
• pycozmo README — the connection procedure, including revealing the pre-shared key via the charging platform and lift movement.
• Digital Dream Labs support material and owner reports — the expected “no internet” condition while connected to the robot’s network.
• microcontrollertips.com teardown — the ESP8266EX Wi-Fi subsystem and the Kinetis K02 that constrains what the robot could host.