How a 2008 Toy Became a Hacker Favorite: Spykee and the WiFi Robot Hacking Story

Every project below is somebody modifying a robot they bought, or a developer writing software that speaks a protocol the manufacturer itself put into the world. That distinction is the whole story, so it goes up front: nothing here involves reaching a device you do not own, and nothing here is a set of steps. Spykee World is an independent publication with no connection to Meccano or to Spin Master. What follows is the ledger nobody has kept in one place. The robot’s own story lives in our history of the Spykee robot.

What did Meccano actually promise?

The claim sat in the same bulleted list as the RAM and the battery: “Open source software.” Meccano put it in print. Then, one section later, the same manual gave the game away. Under 14.3, Programming, it reads: “The Spykee program is open source. You will find the SDK documentation on our website www.spykeeworld.com (NOT AVAILABLE YET).” That is a lot of weight for one parenthesis to carry.

The rest of the data sheet explains why anyone cared enough to be annoyed. A 200 MHz ARM9, 32Mb of SDRAM, an 802.11b/g WiFi client, a USB host port, charge control for a 9.6V NiMH pack, and, listed as flatly as the rest, “Ports JTAG / Serial / port i2c available.” Conceived in 2006, in US shops by late 2008 at roughly $200 to $230, or 175 to 200 GBP depending on market and year. Functionally it was a small networked Linux computer wearing treads, sold in a box with a spy cartoon on it.

Owners worked that out fast. A thread on the phone modding forum XDA opened on December 10, 2008, the robot’s first Christmas: “Apparently there is an SDK coming out soon, as spykee was advetised as having one I thought there was already one to download!” It never came out. The reference works still carry the same sentence, that no API or SDK was officially released.

Read that thread now and the thesis of this article is sitting in it, typos and all, written by an owner in 2008: “its true about the false marketing about spykee but hey, i know this can be more of a robot than meccano have advertised it as because once custom apps for the robot can be made … well lets just say we will ‘flash’ spykee just as we ‘flash’ our mobile devices … to get more functionailty out of them than the manufacturers initially permitted!” These were people who already modded their phones. Building the robot first bought them a particular kind of attachment: “it comes with about 1000 pieces. it took me about 6 hours in total to build it!!! … but its worth it!”

So was the open source promise real? The owner blogs split, and both were right about different years. In November 2008, David Beckemeyer put it bluntly: “The manual says the software is ‘open source’ but it is nowhere to be found.” Three years later the robotics team at DoBots was gentler: “Though the source code is released now, initially it was not and this is probably the reason that the Spykee community never grew very big.” Between those two sentences sits about eighteen months of silence, and it landed after the robot had started sliding off shelves.

Who was hacking a Spykee before Meccano released anything?

The first documented Spykee hack has nothing to do with firmware. In April 2009, more than a year before any source release, Hackaday wrote up a build by a maker going by epokh that drove the robot with hand gestures. The method was cheerfully low tech: “He filters out everything but green through his web cam, then wraps his fingers in green tape,” and “The resulting ‘blobs’ are tracked and converted to motor commands.” He was steering the stock system from the outside, using the only reliable input it had.

Others went at the control layer instead. zaheerm started zspykee in 2009, a Python project that reached 44 commits and included a Flumotion component, so the robot’s video went through a GStreamer streaming path rather than Meccano’s console app. RoboRealm’s Erector Spykee module put a whole machine vision package in the loop: “The robot sends images over 802.11 (WiFi) to a PC,” and the software “sends the resulting motor commands back to the robot also using 802.11.”

The practical fixes, though, came from owners on forums. On XDA someone kept pointing newcomers at a third party client: “There is a guy called Jimfx on www.spykee.org who has deleloped his own GUI in Delphi and it works really well. You can even change the speed to make Spykee a lot slower.” Read that twice. Meccano’s software could not slow the robot down, and a hobbyist’s Delphi program could.

What changed when the firmware source came out?

Around May 2010, possibly earlier, the full firmware source and its documentation went public. No announcement survives that anyone can point to, which is why the date is still recorded with a shrug in both the encyclopedia entry and the developer READMEs of the period.

Petter Reinholdtsen picked it up and wrote the library most later work leans on. “The firmware for the robot is available from the producer, and using that source it was trivial to figure out the protocol specification,” he wrote in October 2010. Trivial is a developer’s word for a good day, and it is the strongest evidence that Meccano’s engineers had built something sane. The libspykee-perl README records what they built: “The firmware listen on TCP ports 9000 and 9001, and allow the robot to be controled using a simple package based protocol via TCP.” Two ports and a packet format. His GPL v2 library ended up “capable of controlling the driving, fetching video, uploading MP3s and play them,” everything the official console did, from a language Meccano never mentioned.

The source release also opened the firmware scene, and that is where the Spykee stopped being a toy in any useful sense. A community Developer Wiki, archived from 2010 and 2011, listed alternate images with names that say exactly what owners wanted from their own hardware: a “Telnet-Enabled Firmware,” then a “Telnet, NFS, UnionFs and USB Mount Firmware,” plus a URBI variant and recovery notes for when a build went wrong. Most of the credit there goes to a handle, Lustinblack. We are not reproducing those procedures, which belong to the era’s wikis and to the people who owned the hardware. The part that matters now is narrower: a machine whose owners could mount a filesystem on it was never a toy, it was a small Linux box that came with treads and a camera.

Here is the full ledger, before and after the source drop. Dates are the earliest we can verify, and several of these repositories are still cloneable.

Two of those rows are the real surprise. Politecnico di Milano’s AIRLab built what its README calls a “Tower Defense Hi-CoRG (Higly Competitive RoboGame) based on Meccano’s Spykee robot,” running ROS and OpenCV, and at Grenoble students bolted a laser scanner to one for an inspection project. A discontinued Christmas present became lab equipment because its wiring and its protocol were both public. If you are hunting the surviving paperwork, we track it in our guide to Spykee manuals and firmware.

The two things owners fixed with a soldering iron

Software gets the attention, but the Spykee’s genuine design faults were physical. Gian Pablo Villamil wrote both up in February 2011. The first is ugly: the robot “has a design flaw in the battery charging mechanism that overcharges and soon destroys the included battery.” The second is cheap in the literal sense. “The built-in WiFi antenna is cheap,” he wrote, “a piece of PCB with etched traces - so the range is very poor.” His answers were the obvious ones for someone with a parts drawer: an RP-SMA pigtail out to a real external antenna, and a 6800 mAh LiPo at 12V in place of the pack that kept killing itself. Neither fix needed a line of code. Both needed owning the robot and being willing to open it.

The other standing complaint was the camera, which did not move. On the Synthiam forums in February 2012: “the biggest let down was the camera being static, thinking of adding the ez unit to it to control the camera for a start.” Nobody used a Spykee for a week without wanting a tilting head.

When the toy stopped being interesting on its own terms, some owners escalated. In September 2012, a father working with his 14 year old son described the exact mood that produces a rebuild: “The Spykee was kinda lousy as a robot, limited, never updated and i was starting to think i wasted my money on it years ago.” So they gutted it. They “stripped out all the electronics,” “hooked up 2 tazer 10T ESC’s to the motors,” then “stacked an erector platform to the top, mounted the ezb, some batteries” and wrote an obstacle avoidance script. The Meccano chassis survived as a chassis. Everything Meccano put inside it went in a box.

Spykee was not the only robot people were writing clients for

The Spykee landed in a short window when consumer robots were unusually open, and its direct rival made the point more clearly. WowWee’s Rovio, also 2008, was a webserver on wheels. Jonathan Bona and Michael Prentice at the University at Buffalo wrote a Python wrapper for it and published the PyRovio paper in May 2009: “The Rovio is controlled using HTTP commands to a web server hosted on the robot,” and because it joined the network over 802.11g, that allows “controlling the robot and accessing its sensory data from any client with an internet connection and in any language.” They used it to give cognitive software agents a body, and to run actors in a theatrical performance.

Rovio owners still had a rough time, and their complaints rhyme with the Spykee’s. A long hands on review at RobotReviews works through ad hoc mode, VPN and phone control, and every pain point is network shaped: “Rovio can only connect via WEP,” and a docking bug where “the Rovio is always Roaming with the battery not charging.” That owner also noticed the community had read the hardware harder than the company documented it: “The manual says to charge the Rovio for 2 hours, but reading on the forums, the Rovio should be charged a bit longer.”

A year before either toy, iRobot had made the idea official. The iRobot Create, released in 2007, exposed “a 7-pin Mini-DIN serial port through which sensor data can be read and motor commands can be issued using the iRobot Roomba Open Interface (ROI) protocol,” and became the main platform for the Autonomous Robotics course at Brown University. A vacuum company decided a documented serial protocol was a product feature, and universities bought it by the crate.

Then the idea took off, literally. Parrot unveiled the AR.Drone at CES in 2010 with an open API game development platform around it, and the aircraft became a fixture in research and teaching. The node-ar-drone README draws the line this whole article turns on: “Unlike the firmware, the client protocol is open, and Parrot publishes an SDK … including a good amount of documentation and C code.” Closed firmware, open client, nothing to reverse. On October 5, 2012, “a group of 60 developers got together at the historic Stadtbad Oderberger bathouse in Berlin” for an all day hackathon called Nodecopter.js, flying drones from JavaScript in a converted swimming pool. Meccano could have had that. Its protocol was just as simple. Its documentation showed up about eighteen months after the audience did.

Where the idea went after the toy aisle

The Spykee faded from shelves in the early 2010s and nothing quite replaced it in the toy aisle. What replaced it came from the parts bin. In January 2019 a maker called Max.K published an ESP32 WiFi robot he called “a shrunken-down version of the ZeroBot,” a rover that “streams color video over WiFi, runs on a small LiPo battery and can be controlled accurately from any web browser.” That is the 2008 Spykee’s feature list rebuilt around a board costing less than lunch, open by default because there was no company around it to close it.

Now compare a modern robot whose manufacturer stops paying the hosting bill. Anki’s Vector was a cloud device, so when the servers went dark it went quiet. The community answer was wire-pod, “fully-featured server software for the Anki (now Digital Dream Labs) Vector robot” that “allows voice commands to work with any Vector 1.0 or 2.0 for no fee,” made possible “thanks to Digital Dream Labs’ open-sourced code.” The difference is stark. Spykee owners wrote clients because the maker was slow. Vector owners had to rebuild the maker’s infrastructure because the maker was gone. Weigh that before buying anything with a cloud account attached. We keep a running check on which robot toys still have live support and separate notes on modern alternatives to the Spykee.

The Spykee’s own story is not finished, which still surprises people. A GitHub organization called spykee-resurrected appeared in 2026 carrying spykeed, “The daemon that runs on the Spykee robot for communication with users, via gRPC,” written in Rust, next to a repository preserving the “Original sources for the Spykee firmware, including clients, and manuals.” Eighteen years after a plastic spy toy went on sale, somebody is writing it a new daemon in a language that did not exist when it shipped.

That is the argument for publishing a protocol, and it is not a sentimental one. Meccano’s engineers got the hard part right: a small Linux computer, two TCP ports, a packet format simple enough that one developer called working it out trivial. Marketing got the easy part wrong. Every client, firmware, lab robot and Rust daemon in the ledger traces back to the code Meccano eventually released. None of it traces back to the SDK it advertised.