Recently I opened for myself a Mario interactive toy produced by LEGO. I wanted to try it out, and ordered the 72043 set. Basically, the playability of the set I didn’t check, but definitely the figure itself has a couple of strange things to fix.
Part 1 If I Were an Interactive Toy DesignerWhat feels off right now in the stock set- Mario toy's speaker is not loud at all. In a noisy environment you can’t hear anything from it. I brought toy to the kids outside event, and they were barely hear anything.In typical play contexts—classrooms, family rooms with TV on, makerspaces—the onboard audio gets masked fast. Quiet feedback makes it harder for kids to connect actions (tilting, jumping, triggering sensors) with outcomes (sound cues). For usability, a higher SPL or a “loud mode” would help.
- The Bluetooth and Power buttons are similar. Who at LEGO designed two similar buttons responsible for totally different actions? LEGO Interactive Play designers shouldn’t have similar mistakes when they release their Pokémon toy. Similar buttons for dissimilar actions in my case caused mis-taps, pairing confusion, and frustrate quick restarts during testing. Especially when I was trying to create Python script to connect toy to the Mac. I had to turn on Bluetooth pairing mode many times, and many times press Power off button instead. In kid-facing devices, affordance matters—one glance should tell you which button powers on and which enters pairing.
- Actually, the interactivity of the figure itself is really low. No extra-buttons to press. The figure doesn’t have touch areas. And basically, from sensors it has a color sensor and an IMU that can tell you the position of the toy in space.Adding even one capacitive touch zone (hat, belly, or boots) or a squeeze sensor would provide clear “press to do a thing” affordances.
- It might be worth adding a microphone, so Mario can record a kid’s voice and speak with the kid’s voice. It would be really fun. Voice mirroring personalizes play (“Let’s go!” in the kid’s voice), enables simple call-and-response games, and could support basic voice commands (“start race, ” “turbo”).
- Swappable pants and personality are a good idea, but it can be extended to the haircut so we can change it too.
- Really, LEGO had a chance to make a real interactive core like micro:bit board without trying to be linked with Mario IP. Like a micro:bit with a huge LCD screen. Yes, actually eyes, mouth, and belly is really one big screen.
A robust programmable core would have clearly extended the toy. They actually had a core, but the team didn’t take the idea far enough—or chose not to. I don’t know the full development story.
It’s not a smart move to use the LCD screen so inefficiently.
- Controller (LEGO Mario): The LEGO Mario figure’s built-in IMU is used as a tilt controller; it advertises over Bluetooth and streams roll/pitch readings that the bridge consumes.
- Bridge (macOS, Python + Bleak): A lightweight BLE bridge ingests Mario’s IMU, runs EMA smoothing and a brief startup bias calibration, maps to continuous analog throttle/steering, and relays commands over BLE UART to the micro:bit.
- Vehicle (micro:bit + WuKong motor driver): The micro:bit receives data, parses string, mixes to left/right outputs, and drives two Geekservo motors for differential drive (left/right).
- Build & Parts (Kart 72043 + add-ons): The physical build reuses the 72043 kart with a compact micro:bit + motor module; a BrickLink Studio model and parts list document the extra Technic gears/structure and tires/rims needed to mount the Geekservos.
- Live Control Loop: Commands stream at 10 Hz; each tick sends the latest filtered values. Deadzone stabilizes neutral, scale sets sensitivity, and expo softens the center while keeping punch at the ends.
- Future (AI Adaptive Layer): Optional on-bridge learning (e.g., per-user response curves/adaptive expo) can be added later to personalize the feel for different drivers; it’s not implemented in the current project yet. I’ve noticed kids use the Mario controller differently, so I’m building an AI layer that learns each player’s patterns instead of forcing a strict control scheme. The idea: there’s no “right” way to drive—play how you like, and the code will adapt, adjusting the control mapping to your style. In practice, each player gets a unique control profile. If someone else picks up your Mario figure, they should switch to their own profile so your ML-tuned settings stay intact.
After I told the explanation, we got back to the main topic: how do we make the kart RC?
The plan was clean: use the IMU to stream data from the figure toy to let the micro:bit talk to the motors, and bring the whole thing to life.
Then came the fork in the road. Do I build the classic RC scheme—one motor to drive, one servo up front for Ackermann steering—or keep the 72043 spirit intact? I tried a few prototypes. Each front-steer attempt messed with the look, added fussy parts, and pulled the build away from what it was meant to be.
So I made the call: preserve the design, trim the extras. Two motors in the rear, differential drive. Left motor, right motor—together they sprint; apart they spin. Not a scale racer’s dream, but perfect for play.
And that’s the point. This kart isn’t about lap times. It’s for kids—something they can tinker with, code, and understand without a drawer full of third-party parts. The IMU sends tilt and twist; the micro:bit turns that into go and turn. The kart hums across the table, pirouettes around a cup, bumps a cone, beeps, keeps going.
Mechanical Build Steps For LEGO 72043 SetFollow the instructions to modify rear axle. I published a modified Kart 3D model on BrickLink. See the full parts list in the: BrickLink Studio 3D Model
Additional LEGO elements (not included in the base 72043 set).
Technic gears (blue, used in this build)
- 2×
6396479
- 2×
69779
Alternative gears (tested, faster gearing, easier to source)
- 2×
10928 (3647)
- 2×
3648
Structural System parts (colors don’t matter)
- 1×
4210998
- 2×
4654580
- 2×
6083620
- 6×
4210719
- 1×
303426
- 2×
6225230
- 4×
6092585
Technic beams (to mount Geekservos to the WuKong board)
- 2×
4210686
- 8×
6279875
Tyres and rims
- 2× Tyre
30391
(or equivalent) - 2× Rim
55981
(or equivalent)
Assemble the micro:bit + Geekservo motor block as shown. I used the Elecfreaks Wukong micro:bit module because it was the smallest option I could find, includes a built-in Li-Po battery, and can drive two DC motors.
Connect M1 to the Left motor, and M2 to the Right motor.
/bridge
mario_bridge.py # macOS BLE bridge (Mario -> micro:bit)
mario_microbit_scan.py # helper: list BLE devices for sanity check
/microbit
microbit_mario_kart_driver.hex # MakeCode micro:bit program
Step 4.1 — Clone The Repogit clone https://github.com/maxxlife/interactive_microbit_mario_kart_toy.git
cd interactive_microbit_mario_kart_toy
Step 4.2 — Install DependenciesOption A)
Conda Manual Env Setup
conda create -n lego_mario python=3.9
conda activate lego_mario
pip install -r requirements.txt
Option B)
Conda Declarative Env Setup
conda env create -f environment.yml
conda activate lego_mario
Note (macOS): The Conda environment includes the PyObjC bits Bleak needs for CoreBluetooth.
Step 4.3 — Flash The micro:bit- Open MakeCode, import
microbit/microbit_mario_kart_driver.hex
. - Ensure Bluetooth UART service is enable, and No Pairing required is set 📷
- Flash to the micro:bit.
cd bridge
python mario_microbit_scan.py
Example terminal output:
% python mario_microbit_scan.py
Scanning for Bluetooth LE devices (5s)…
- BBC micro:bit [tapag] (E9F4DD5B-E022-4C3A-E889-784AB44424A5) UUIDs: []
- Mario asr5 (DC2BBB46-1DBE-BFBF-5C54-4971BDEE1F78) UUIDs: ['00001623-1212-efde-1623-785feabcd123']
Summary:
LEGO Mario found
micro:bit found
If both devices are in Summary, you’re ready to bridge.
Step 4.5 — Run The BLE Bridge (Recommended Defaults)# If you used Conda:
conda activate lego_mario
cd bridge
python mario_bridge.py --x-scale 28 --z-scale 32 --deadzone 0.08 --expo 1.3
Put Mario on table, don't move for ~0.5 s while the bridge calibrates center (bias).Then drive your Mario Kart with smooth control 🚗💨
Part 5 RC Kart Project VideoPart 6 Development History And Tests With Kids- At first, the kart wasn’t working smoothly. I based parts of the software build on a GitHub project by RickP/lego_mario_controller However, I still had to tinker with libraries and duplicate the source project just to read data from Mario.
- This was my attempt to connect LEGO Mario to a micro:bit-powered robot using Bluetooth Low Energy (BLE). In this stage, I’ve successfully connected Mario to macOS (M1) using Python and bleak. Subscribed to Mario’s IMU and tile sensors. Received real-time BLE notifications from Mario.
- After I got the kart’s RC drive mostly stable, I took it the next day to an open-day maker event with lots of kids. I brought it to playtest and spot improvements. That’s when I realized I needed to smooth the RC controls—obvious in hindsight, but not something I’d implemented initially. The event also sparked the idea for an AI RC transmitter that learns from each child’s control patterns, inspired by how differently kids held and moved the Mario figure.”
Best hack of the day: put Mario inside the kart and drive from there!
After enough testing, I know what needs improvement. Good luck building your own remote-controlled Mario Kart!
When class ends, a kid asks, ‘Can it drift?’ Maybe—if we install slick tires. The kart rolls off the desk, and the ideas follow.
Comments