Interactor lets students compete and collaborate through code they write themselves. Each student programs a BeagleConnect Zepto, a microcontroller board (a whole small computer on one chip) about an inch square. The boards then plug into a shared game board, where their code plays against or alongside each other's in real time. Nobody holds a controller. What happens is decided by the code each student wrote beforehand.

Why it's here

Many school robotics clubs give students a robot that's already built and programmed, and leave them only the last bit of wiring and setup. Often the result is a remote-control car. Interactor asks students to write the behaviour themselves, and then to watch it meet other students' code.

It began as a proposal to Northville schools, to be carried out together with their teachers and students (The_Interactor.pdf).

Interactor is one project in a program, a group of projects run by the same maintainer. The projects share a workbench called OCX, where AI agents and people build and test code. The research for Interactor drew on complexity theory, the study of systems with many interacting parts and the ways they fail. That research shaped the rules OCX is built on: its core axioms and values. A talk, the Mechanical Turk presentation, introduces those ideas, and its final demo runs on code kept here. The Big Picture page shows how all the projects fit together.

What it's made of

Today the code builds demos with two of BeagleBoard.org's boards: BeagleBadge, a wearable Linux board with an e-paper screen, and BeagleConnect Zepto.

• Game board: BeagleBadge. BeagleConnect Zepto boards plug into its Qwiic sockets. Qwiic is a small four-wire connector that carries I2C, a simple two-wire bus that lets one chip talk to several others.
• Game rules: badgesnake, a Go program for BeagleBadge, uses the official rules of Battlesnake, a game in which each snake is steered by code rather than by a player (badge-demo/cmd/badgesnake).
• Student boards: C firmware for BeagleConnect Zepto that runs with no operating system, in a few kilobytes (badge-demo/firmware/zepto).
• I2C bus analyzer: a BeagleConnect Zepto with a small colour screen. It shows each message on the bus between the boards: who was addressed, whether it answered, and the first bytes sent. It only listens. Students send their own messages from BeagleBadge, then watch what the boards did with them (MechanicalTurkDemo.md).
• zepto-bridge: a small program on BeagleBadge, written in the Crystal programming language. It lets programs that run in a sandbox (fenced off from the hardware for safety) reach the I2C bus and flash (load new firmware onto) BeagleConnect Zepto (ZeptoBridge.md).
• Presentation material: the script for the explainer video (docs/Why_Interactor.md) and a set of scripts that produce the video (second-question).

How it's shaped

• Each BeagleConnect Zepto is an I2C target, a device that answers when addressed. It has its own address and a short list of registers (small numbered storage slots) that BeagleBadge reads and writes.
• BeagleBadge is the I2C controller, the device that starts every exchange. It runs the game and asks each board for its move. Drawing the game on its screen is still to be built.
• The analyzer sits on the same bus and shows every exchange as it happens.
• Every exchange follows a published register map: a table of which register holds what. Any board that follows the map can join, whatever language it was written in. The same firmware lets BeagleConnect Zepto plug into BeagleBadge or into the badge handed out at Hackaday Supercon 2026, an electronics conference. That is the design; it has not yet run on either (sao/README.md).

What success looks like

Each item links to its evidence: a forum post or a check-in (a recorded change in the repository).

1. The analyzer shows real traffic. Done: on BeagleBadge at 100 kHz (post, check-in).
2. BeagleConnect Zepto answers as an I2C target on hardware. Not yet: the firmware builds and passes its tests on a PC, but hasn't run on a board (TODO.md).
3. The Mechanical Turk demo runs end to end. A BeagleConnect Zepto plays snake moves for BeagleBadge, with the analyzer watching. Not yet: the snake firmware builds and passes its tests, but hasn't run on hardware (MechanicalTurkDemo.md).
4. Supercon add-on. BeagleConnect Zepto plays snake as an add-on for the Supercon 2026 conference badge. Built, not yet on hardware (check-in).
5. Several students' boards play one game. Not yet.
6. A classroom session with Northville teachers and students. Not yet.

The Status page says where the work stands today.

The virtues behind it

Like every project in this program, Interactor follows the four virtues of OCX:

• Clearly stated: anyone can tell what each part does. The analyzer makes the conversation between boards visible, rather than leaving it hidden.
• Loosely coupled: each part can be swapped without breaking the rest. Boards meet only through a published register map, so a board written in any language can take part.
• Demonstrably verified: every claim is shown working, not just stated. Firmware is tested on a PC first, and each item above says whether it has run on hardware.
• Parsimoniously bounded: it does no more than it needs to. The firmware is a few kilobytes with no operating system, and the analyzer only listens.

The original proposal

The text below is the proposal as first written, kept for its history.

What is it?

A kit for building a setup for seeing several students code interacting in real-time, providing physical presentation, but minimizing complex physical world factors.

Provides environment for:

• Enabling students to programming microcontroller boards (think BeagleConnect Zepto) using graphical or textual programming languages (MicroBlocks, Arduino/C, Micropython, etc.)
• A "game board" made up of a "controller" computer (think PocketBeagle 2) with status elements like LED matrix, audio output, LCD, etc. and I/O connections to the microcontroller boards
• Connecting multiple microcontroller boards that students have programmed to the "game board" to have them interact in real-time (over QWIIC or mikroBUS)

Background

Beagle has recently launched a $1 development board with 128KB flash and 16KB RAM about the size of a postage stamp and compatible with 1,500 mikroBUS add-on boards and 100s of QWIIC add-on boards called "BeagleConnect Zepto". There is an on-line competitive coding environment called "BattleSnake" (https://play.battlesnake.com/) that pits multiple snakes against each other where "code is the controller". I think putting your code on a Zepto board and bringing it to a system that will "battle it out" between multiple users where they cannot control it themselves, but instead have to have written code to handle the various conditions could be very inspirational.

Of course, I think there is a major personality bias when it comes to creating something that is purely competitive, but this is just to draw a picture for you. The objective could also be collaborative, like creating music or drawing a picture. I have specific implementations in mind, but want to get the conversation going before I get too far.

Videos