中文 →

3C full flow · one diagram

2026-09-07 · from a pile of bricks to a machine that moves: what actually happens in between
Updated 2026-09-19: the real-board parts now follow the cube hardware line (cube-line overview 09-15 · board registration flow 09-16)

What you build → What's plugged in → What it does → Where it runs

The whole flow is just these four cells. It looks complicated only because "what the platform does for you" is laid out too — you never touch any of that. This is the target flow: in simulation it works like this today; for what already works on real boards and what doesn't, see the table at the end.

3actions you take
(drag a mechanism · drag cubes · drag blocks)
1thing you type
(the WiFi password, once, ever)
9things the platform does
(listed one by one below, not a padded number)

Those 9: ① compute pin assignments ② move apart cubes that want the same pin ③ infer the drive train ④ compile blocks to MicroPython ⑤ assemble main.py ⑥ claim the board (MAC → your account) ⑦ scan I2C to see what's connected ⑧ push the firmware to the board ⑨ reboot and bring readings back to the page
Real-board status: ⑥ claiming isn't built yet; ⑧ currently goes through a local bridge over WebREPL and is proven end-to-end only for distance, buzzer and screen.

Mind map

MakerKit 3C moving machine 🧱 What you build construct · 667 models 🔌 Plugged in cube · drag 12 kinds ⌁ What it does code · blocks or preset One program 1 board = 1 program In sim today Board 4 steps ↓ The four real-board steps ① Setup — enter WiFi via board hotspot ★ the only thing you type, once ② Register — its MAC ties it to you ③ Build — assign pins, write main.py ④ Push — send via WebREPL, reboot, run Goal: ②③④ automatic; status below You only do three things (all drag) 🧱 Drag in a mechanism — pick from 667, or upload yours 🔌 Drag cubes onto it — anywhere, move them freely ⌁ Drag blocks / pick a preset — "stop and alarm when close" In simulation it never asks: port · IP · pins · which board Real board: wire the listed pins; MAC is identity, not COM port

The four steps: who does what

1
WiFi setupyou, once
A board that has never joined WiFi opens its own hotspot MK-CUBE-xxxx. Join it with your phone, enter your home WiFi password + a 6-digit binding code copied from the page. After that you never deal with it again.
2.4 GHz networks only — the ESP32 can't receive 5 GHz (measured: 8 APs found, all on channels 1–11).
Status: the phone provisioning code is written and passes a local self-test 35/35, but has not been run on a real board yet; new boards are currently set up by hand over a serial cable, following the registration flow.
2
Registerautomatic
Once online the board reports in with its MAC, not a COM port — four different boards have shown up on the same COM5 in one day, so a port number is not an identity. While reporting it also scans I2C and can recognise an OLED or a gyro automatically.
Status: the self-report code exists but isn't installed on the boards yet; claiming a board to an account (/cube/*) isn't built. Boards are registered by hand, by MAC, for now.
3
Build firmwareautomatic
Pins are assigned from the cubes you dragged on (the platform separates cubes that want the same pin), and the blocks are compiled into one main.py. In the pin-assignment test, 10 cube kinds fit on one board — that is a software check, not real wiring.
Status: exported board code has been proven end-to-end on a real board only for distance, buzzer and screen. "Plug and play" is not true: on a real board you wire each cube to the listed pins (the original programs have 5 conflicting pins); the motor lives on a separate motor board.
4
Pushautomatic
Sent to the board over WiFi; it reboots and runs. After registration, no USB cable and no port hunting.
Status: a local bridge (mk_bridge.py) pushes over WebREPL, proven for distance, buzzer and screen; /deploy on the server can't reach into a home LAN, so it always returns 503 with manual steps.

Where things stand

StageStatusNotes
Drag mechanism / drag cubesworksPlace anywhere; positions are remembered
Drag blocks · run in simulationworksOne program per board; blue reads, red writes
Pin assignmentworksCriteria + 24 tests; just connected to the backend endpoint
Real-board status of the 12 kinds3/12 proven★ 3 proven from Blockly to a real board (distance, buzzer, screen); 2 run on their own boards (camera, motor); 7 are stubs (original program exists, not measured)
Flashable firmware from blockspartlyExported code for distance, buzzer and screen ran on a real board (09-09); other kinds not checked
WiFi setup / register / pushpartlyPhone provisioning code + local self-test 35/35 (not run on a real board); new boards registered by hand: MAC, WiFi, WebREPL (walked through 09-16); pushing over WebREPL works; account claiming not built
Several boards working togethernot yetDecided 09-09: no ESP-NOW / BLE mesh; the platform reaches boards over WebREPL + a host relay. Broadcast within one board works; the cross-board relay isn't built, so messages between real boards don't work yet

works partly works not yet

The one step that can't be simplified away: the WiFi password. A board can't guess your router password, so someone has to tell it the first time. Everything else (port, IP, pins, which board, how code gets there) can disappear — (pins can only disappear once each board carries a wiring profile recorded at the factory; that isn't done yet) and it has to, because those are exactly today's most expensive trap: a document hard-codes -p COM5, and the board on that port is actually a different one.