[null, {"document_url": "http://nick.zoic.org/art/mbot-nodebot-blockly-arduino/", "unformatted_src": "/art/mbot-nodebot-blockly-arduino/mbot-with-kids.jpg", "src": "https://nick.zoic.org/art/mbot-nodebot-blockly-arduino/mbot-with-kids.jpg", "formatted_filename": "mbot with kids", "alt_text": "Mbot with Amelia and Charlotte"}, null, {"document_url": "http://nick.zoic.org/art/mbot-nodebot-blockly-arduino/", "unformatted_src": "/art/mbot-nodebot-blockly-arduino/mBlockly-t.png", "src": "https://nick.zoic.org/art/mbot-nodebot-blockly-arduino/mBlockly-t.png", "formatted_filename": "mBlockly t", "alt_text": "mblockly screenshot"}, null, {"document_url": "http://nick.zoic.org/art/mbot-nodebot-blockly-arduino/", "unformatted_src": "/art/mbot-nodebot-blockly-arduino/mblock1t.png", "src": "https://nick.zoic.org/art/mbot-nodebot-blockly-arduino/mblock1t.png", "formatted_filename": "mblock t", "alt_text": "mblock mac screenshot"}, null, {"document_url": "http://nick.zoic.org/art/mbot-nodebot-blockly-arduino/", "unformatted_src": "/art/mbot-nodebot-blockly-arduino/mblock2t.png", "src": "https://nick.zoic.org/art/mbot-nodebot-blockly-arduino/mblock2t.png", "formatted_filename": "mblock t", "alt_text": "mblock code generation"}, null, {"document_url": "http://nick.zoic.org/art/mbot-nodebot-blockly-arduino/", "unformatted_src": "/art/mbot-nodebot-blockly-arduino/mblock3t.png", "src": "https://nick.zoic.org/art/mbot-nodebot-blockly-arduino/mblock3t.png", "formatted_filename": "mblock t", "alt_text": "image"}, null, {"document_url": "http://nick.zoic.org/art/mbot-nodebot-blockly-arduino/", "unformatted_src": "/art/mbot-nodebot-blockly-arduino/chip8.jpg", "src": "https://nick.zoic.org/art/mbot-nodebot-blockly-arduino/chip8.jpg", "formatted_filename": "chip", "alt_text": "CHIP-8 Instruction Set"}, null]
Nick Moore




mBots using Nodebot, mBlockly and Arduino


robots / microcontrollers / electronics / education

I attended a Nodebots workshop a couple of weeks ago at BuzzConf, and Charlotte and I put together an mBot kit and had a go at programming it. We made a racetrack for the mBot, out of a bit of corflute with a track for the robot made out of black insulating tape. The challenge was to write a program which would follow the line quickly and without knocking down all the houses and people!

The mBot platform

The mBot itself is a great looking device, well packaged and comes with almost all of what you need to get started, even a double-ended screwdriver. The only other things youâll need are a pair of needle-nose pliers or tweezers to hold the nuts when putting the motor retaining bolts in, and 4 x AA batteries for the battery box. Any kid whoâs put together some Lego will be able to follow along with some minimal help.

The whole thing has a cheery and non-threatening presence which is encouraging to kids.

mCore board

The choice of 6P6C connectors is somewhat inspired, as they are cheap and easy to use. On the boards we got, thereâs 4 sockets, and each has power & ground, two I/O pins of its own and 2 pins for a shared I2C / TWI. More modern boards seem to have a mix of different port types. Thereâs also a row of 6 through hole behind each connector which offer the same pins in the more usual arduinoish way. If youâve got other arduino stuff already, maybe populate those holes with pin headers before assembling your robot.

Thereâs also a couple of H-bridge drivers already on the board for driving DC motors, and a 3.7 LiPo charging circuit with the usual connector, and some RGB LEDS, and a USB interface and so on, which means that getting the system up and running is quite painless. A couple of headers up the back let you plug in a Bluetooth serial module.


The mBot kit came with a couple of other little boards â¦ an ultrasonic transducer board and a line-detector board. These screw neatly to the mBot chassis and connect with tiny 6P6C cables. Nothing fancy but quite workable.

The motors supplied are neat enough little units, with quite good wheels and rubber tyres. They plug directly onto the mCore board motor ports, and the wheels just slip onto the axles.

Thereâs a 4 x AA battery box included, so pick up some high-powered alkaline cells for it and youâre away. If you want to play with the included remote control, grab a CR2025 lithium battery while youâre at it.

mBot Programming

So, now youâve assembled your robot, what can you do with it?


The Buzzconf workshop was using NodeBots which we dutifully installed and much to my surprise it worked pretty well. I even got the Bluetooth interface to play nicely with Linux, miracle of miracles.

But Iâm not a fan of Node despite (or perhaps because â¦) of having done a bit of work with it, and Iâm not sure it is a good match for the robot. On the one hand, sure, if youâre going to learn a programming language these days, it might as well be Javascript â¦ itâs used in so many damned things.

On the other hand, teaching Javascript is a fairly dismal experience â¦ thereâs a lot of complexity to digest up front, and not a lot of consistency.

mBlockly for iOS This app loaded up nicely on a recent (iOS 8.1) iPad and found the robotâs Bluetooth interface straight away. (On an older iPad 2 (iOS 6) it started but couldnât find the robot.) It looks great, very friendly, and will be immediately familiar to anyone whoâs played with any of the Scratch family.

Unfortunately, it is a bit minimal: thereâs no variables, and motor control is limited. Yyou can set the motors to forward, or backward, or turn left or turn right. You can vary the overall speed, but you canât control the two motors separately, eg: set the left one to turn forward at 50 and the right forward at 100. Thatâs a bit limiting for things like line following.

But the real problem is that it is sloooooooow. Every message pings back and forth between the robot and the iPad-as-controller, and unfortunately by the time the messages ping from robot to controller and back the robot has already left the line, or hit the wall, or whatever.

So I gave up on mBlockly for now â¦


mBlock 2.2 for Mac Now weâre getting somewhere.

mBlock works by compiling Scratch-like block code to Arduino flavoured C++, and then using the Arduino toolchain to load the code onto the robot. Loading works great over USB cable but I never did get the Bluetooth loader to work properly. Once the code is loaded, the USB lead can be disconnected and the robot will continue to run indepedently.

The block code has variables and functions, which is great. Thereâs not much point trying to teach fundamentals of programming without them.

Arduino Code Generation Sadly, the code generation is a little funky. Thereâs no type inference (everything is a double), and strings arenât always escaped. Function names get cut off at white space, so youâd better not define two functions called âsay helloâ and âsay goodbyeâ. Sometimes things seem to come out in a different order than they go in.

C++ compiler error messages are displayed to the user, and itâs hard to imagine a primary school kid doing much with:

It is a cool idea, but it seems not quite ready for classroom use â¦

The other problem is that compiling and uploading the Arduino system takes time, and once it is uploaded thereâs no way to single-step or otherwise debug the robot. Debugging is of enormous benefit to novice programmers, so it seems like a bad limitation.

mBlock 3.1 for Windows mBlock for Windows has a newer version, 3.1.

I only took a quick look at this. Despite being a new major release, the code generation is still screwy. Thatâs quite disappointing. I think code generation to Arduino is a good approach, but thereâs no point if theyâre not going to take it seriously.

A Better Approach?

Thereâs two opposed approaches here: the Nodebots/mBlockly way of having the robot be a peripheral under control of the PC, and the mBlock way of building code to upload to the robot. Iâm not happy with either of them, really.

Untethered but Debuggable

Thereâs some conflicting requirements here: Iâd like to have the robot run untethered, and Iâd like it to be debuggable. Iâd also like to avoid having the robot run a full PC stack, even if single board computers like the RPi Zero make this quite practical â it seems like a lot of additional complexity.

(Actually, I could be convinced, if someone could squeeze a web-based Scratch-like IDE onto the RPi itself so that no configuration would be needed. Thatâd be cool.)

Remote Monitor Another alternative would be to run some kind of monitor / interpreter which could handle the single-step behaviour and so on. Scoff if you will at the thought of interpreting bytecodes on an ATMega328, but my householdâs first ever computer was a DREAM 6800 which could run programs in an interpreted mini-language called Chip8. It was a very very simple mini-language, as you can see from the instruction set list on the right.

Is a bytecode for Scratch too much to imagine?

Hardware Configuration Language

The other thing which would be useful is a âhardware configuration languageâ for the robot: that way you could define which pins/ports are which functions, and what paramters they accept/return, and thus end up with structured and more readable code.

These are simple questions for someone with some robotics knowledge, but no so much for someone without the background knowledge.


The mBot is a great little device which is very kid friendly to assemble and start using, and if youâve got someone around who knows something about programming kids can have a lot of fun with it.

But in my opinion it is still a few iterations away from being ready to hand over to an educator with no idea about programming.

UPDATE 2016-02-07

I learned a lot about the ESP8266 at LinuxConf this year and the interpreted approach looks more realistic â¦

See also Flobot: A Graphical Dataflow Language for Robots for some new ideas going forward!