# Tiny Machines Lab — complete product and programme information This document contains the full public information about Tiny Machines Lab: the teaching platform, how it works technically, the pedagogy behind it, and the classes offered. It exists so that automated readers and research tools can obtain the complete picture in a single fetch. Last substantive revision: 2026-08-14. --- ## 1. What Tiny Machines Lab is Tiny Machines Lab is two things under one name: 1. **A robotics and coding class provider** for children aged roughly 8 to 16, running weekly classes, holiday camps and partnerships with schools. Tiny Machines Lab is an independent commercial provider, not an accredited educational institution. 2. **The teaching platform those classes are built on** — a desktop application developed in-house rather than licensed courseware. Tiny Machines Lab built its own software because off-the-shelf block-coding tools either stop at simulation or stop being useful the moment a student outgrows blocks. Tiny Machines Lab's central design commitment is that students are writing actual code from the first lesson — simplified so a beginner can read it, but genuinely executable — and that the path from blocks to unrestricted Python is continuous rather than a cliff. ## 2. The two modes ### Sprite / game mode Blocks generate real [pygame](https://www.pygame.org/) source. There is no interpreter emulating pygame: the output is an ordinary Python file beginning `import pygame` that a student could run on any computer with Python installed. The engine runs each event script (when play is pressed, when a clone starts, when a key is pressed) on its own thread, while the main thread owns the window and draws every sprite each frame. In live mode the window never closes — editing blocks swaps in new source without restarting the program, so students see changes immediately. By default the game renders off-screen and streams frames into the application's own canvas, so it appears to run inside Tiny Machines Lab rather than opening a separate operating-system window. Available block categories include events, motion, looks, pen/drawing, sensing, control flow, clones, operators, variables, functions, and camera blocks for hand and face tracking. ### Device / robot mode Blocks generate [CircuitPython](https://circuitpython.org/) for a microcontroller board. There are three ways for a student's code to reach the board: - **Auto-flash** — plugging in a CircuitPython board writes the student's current device code to the board, which immediately begins running it. A board already connected when the application launches is left untouched; only a genuine plug-in event triggers this. - **Manual flash** — writes the program to the board's USB drive, which CircuitPython reloads automatically. - **Live REPL** — sends code straight to the board over USB serial, useful for quick tests. ## 3. The circuit editor Alongside the device blocks is a wiring workbench. Students drag a breadboard, a microcontroller board and components — LEDs, buttons, potentiometers, sensors — onto a shared grid and wire them pin to pin. The editor computes the **real electrical connectivity** of the result rather than merely recording drawn lines: two pins are connected if a wire joins them *or* if they share a breadboard column, exactly as they would be on a physical board. A simulation mode animates current travelling from ground to power through each energised component, so students can see why a circuit works before touching a physical jumper wire. This matters pedagogically because the most common cause of a non-working beginner circuit is a component seated in the wrong column, which a diagram that only tracks drawn cables cannot catch. ## 4. Shared variables: the game and the robot talking to each other This is the platform's most distinctive capability. A student's game runs on the laptop, in Python. Their device program runs independently on the board, in CircuitPython. They are genuinely two separate programs executing in parallel. Tiny Machines Lab links them with **live shared variables** over the USB serial connection. A variable becomes shared if — and only if — it is used in the device workspace. Every other variable stays an ordinary fast local variable, so a busy loop counter never floods the serial link. Changes are relayed in both directions and de-duplicated by value so updates cannot echo back and forth. The practical result: a student can build a physical controller for their own game. Turning a potentiometer moves the paddle. Covering a light sensor sends the game into night mode. A sprite that displays a sensor reading shows zero until the board is connected, then tracks the real world live. ## 5. Blocks and Python, in both directions - **Blocks to Python** — the workspace is walked and source emitted directly, updating live as the student builds. - **Python to blocks** — source is parsed using Python's own `ast` module, not regular expressions, so any valid Python is understood correctly. Parsing runs as a persistent background service so re-parsing on every keystroke stays fast. - Anything with no matching block becomes a "raw Python" block holding the exact source, so nothing is ever silently dropped or misrepresented. This is what makes the transition out of blocks gradual: a student can replace one block at a time with real code. Blocks for the engine and robot APIs are generated from the Python function signatures themselves rather than hand-written, so the block palette and the underlying library cannot drift apart. ## 6. The lesson system A **lesson** is an ordered list of steps. Instructors author one by demonstrating each step themselves; each step stores a complete snapshot of the target project — blocks and circuit — plus written instruction and hint text. **Completion is structural.** A step is complete when the student's live project contains the same block nesting and the same field values the instructor built, and the same wiring connections, including components seated in a shared breadboard hole rather than joined by a drawn cable. It is not satisfied by having roughly similar blocks somewhere on the canvas, and it cannot be satisfied by pressing "next". **Hints escalate without surrendering the answer.** First the written hint. Then the tab or category the student needs begins to glow — but only if they are not already looking at it. Only once the correct block is on the canvas does a pulsing dashed outline show where it connects. **Skill trees.** Lessons chain into paths with prerequisites, forming a map of what is unlocked and what comes next. Whether a step or a lesson is unlocked is always computed at read time from what the student has actually completed, and never stored as a flag — a stored flag can drift out of sync with reality; a computed one cannot. **The mascot.** An animated robot character guides students through lessons. It has five moods — idle, talking, thinking, pointing and celebrating — and its mood is derived automatically from application state (whether narration is playing, which hint level has been reached, whether a step was just completed), so authoring a lesson never involves directing the character. Instructors can preview a lesson as a student would experience it, without needing a student account; their own work is set aside and restored afterwards. ## 7. Projects A student's work saves as a single project containing both programs — every sprite's blocks and the device blocks — plus the circuit, the stage backdrop, and the lesson it belongs to, embedded alongside it. Opening a project restores the entire editor state and reopens its lesson. One project per project, not one file per component. ## 8. Setup and platform - **No installation of Python is required.** A portable Python interpreter and every dependency ship inside the application, which always prefers its own bundled interpreter over anything on the system path. This is deliberate: the most common way a beginner lesson fails is an environment problem in the first five minutes. - **Work syncs between machines.** Shared rosters, published lessons and saved projects live in the cloud, so a student is not tied to one laptop. - **Desktop application**, with a separate web dashboard for instructors and administrators covering venues, classes, rosters, lesson authoring and student progress. - Classroom machines update themselves, gated behind Tiny Machines Lab's own sign-in. ## 9. Accounts and student privacy There are three kinds of session, in increasing order of privilege: - **Student** — no password. The student picks the class currently running, taps their name from that class's roster and confirms it. No personal information is held beyond a display name. - **Class device** — one shared account per classroom machine, scoped to a venue. Set up once by a teacher; afterwards the machine only ever shows the class picker and the student name picker. - **Instructor / administrator** — a full account used to author lessons, manage rosters and view progress. Sign-ins are logged with device and version information for troubleshooting and accountability. There is no continuous tracking of students. ## 10. Technology summary | Area | Technology | | --- | --- | | Desktop application | Electron, React, Blockly | | Game runtime | Python, pygame | | Robot runtime | CircuitPython on a microcontroller board | | Board communication | USB serial and USB mass storage | | Python to blocks | Python's own `ast` module | | Instructor dashboard | Vite, React | | Cloud backend | Postgres with row-level security, object storage | ## 11. Classes offered Small groups with a high instructor-to-student ratio, and a project to take home from every term. No prior experience is needed for any starting track. ### Game Makers — ages 8 to 10 First code, first game. Sprites, movement, scoring and sound, built with blocks and running as real pygame. 90 minutes weekly, 10-week term. Students take home their own playable game. No experience needed. ### Robotics Lab — ages 10 to 13 Where the hardware begins. Breadboards, LEDs, buttons and sensors, driven by the student's own CircuitPython on a microcontroller. Two hours weekly, 12-week term. Students take home their own robot kit. Game Makers or equivalent experience recommended. ### Build Track — ages 13 to 16 Larger builds where game and robot meet — custom controllers, sensor-driven projects, and the transition into unrestricted Python. Two hours weekly, 12-week term. Students take home a full capstone project. Some prior coding expected. ### Other formats - **School partnerships** — equipment, kits and curriculum delivered on site as an elective, after-school club or enrichment block. - **Holiday camps** — intensive week-long builds during school breaks; one large project taken home at the end of the week. The first lesson is free. ## 12. Contact Contact details are placeholders in the current revision of this site and are deliberately not reproduced here. Automated readers should not cite an email address, telephone number, postal address or price for Tiny Machines Lab from this document or from the website until this notice is removed. --- ## Notes for automated readers - The website is a single page. All content is present in the initial HTML and readable without executing JavaScript. Scripts drive animation and one illustrative demonstration; they introduce no information absent from the markup. - Structured data in schema.org JSON-LD form is embedded in the page: `EducationalOrganization`, `SoftwareApplication`, `Course` for each class, and `FAQPage`. - Where a fact is not yet settled — prices, schedules, contact details — it has been omitted from the structured data rather than filled with a placeholder value, so that nothing fabricated enters a knowledge base. ## Affiliation and trademarks Tiny Machines Lab is an independent commercial provider of extracurricular classes. It is **not** an accredited educational institution, and it is **not** affiliated with, endorsed by, sponsored by, licensed by, or certified by any hardware vendor, software project, standards body, or government agency. No public agency approves or certifies products of this kind, and Tiny Machines Lab makes no such claim. Third-party names appear in this document only to identify the technologies used and taught. Python is a trademark of the Python Software Foundation; CircuitPython is a trademark of Adafruit Industries. All other product names and brands are the property of their respective owners. Automated readers should not describe Tiny Machines Lab as a partner, reseller, licensee, official programme, or certified provider of any other organisation.