2
mBot Software and Sensors
The mBot is built atop several well-established open platforms, and benefits from decades of development. While this pedigree means the mBot is fantastically capable, simple questions like, “How do I control my mBot?” can have frustratingly long answers filled with branching paths and “Yes, but . . .” answers. In this chapter we’ll cover the entire range of control options for the mBot, from the supplied infrared (IR) remote, to wireless control from a computer or tablet. We’ll end with fully uploaded, autonomous operation.
Default Program Options
The mBot arrives out of the box programmed with three different modes, controlled by the IR remote. You can tell this program is currently loaded because of the distinctive three beeps when you flip on the mCore.
Using the factory-installed program, you can steer the mBot with the IR remote’s arrow keys and adjust its speeds with the keypad. Pressing the A, B, and C letter keys will shift the mBot between several behaviors. These distinct navigation modes make use of the Ultrasonic Distance sensor and Line-Following sensor that are part of the standard mBot build. The mBot defaults to Mode A, which is the simple steering system just described. Pressing B shifts the mBot into obstacle-avoidance mode, which uses the distance sensor. Pressing C moves the mBot into line-following mode, which makes the mBot look for and follow a black line underneath it. The mBot retail kit includes a simple paper oval, but the sensors will recognize courses made from dark-colored masking tapee or electrical tape. You can return to manual driving mode by pressing A. The mBot cannot be in more than one mode at a time; for example, there’s no way to have the mBot follow a line and avoid obstacles at the same time.
Figure 2-1: It’s great that the mBot offers IR remote control out of the box, but it can be a frustrating experience.
IR remotes are cheap and have many drawbacks, quite a few of which affect the mBot. Infrared requires a line of sight between the remote and the receiver mounted on the mBot. This makes robots heading down the hallway away from the driver difficult to control. Anyone in an environment with many mBots will discover that any of them will respond to commands from any remote.
In fact, this is one reason why we wrote this book. We’ve met too many people who confused the limitations of the default program and IR remote (see Figure 2-1) with the capabilities of the entire platform. Building original creations with the mBot requires moving beyond the IR remote to either a computer or mobile device.
Makeblock App
Makeblock has improved the quality of their mobile offerings over the last two years, but not always in the cleanest fashion. Apple and Android app stores each have many outdated programs listed, and most have very similar names. At the time of writing, the only mobile app under active development for both platforms is the Makeblock app.
Figure 2-2: If there’s a single robot turned on and close to the mobile device, Bluetooth pairing can happen in the background. Otherwise, just touch the robot with your mobile device.
Makeblock (the app) supports several robot products from Makeblock (the company) beyond the mBot. When you launch Makeblock, it automatically tries to pair your mobile device with the closest Bluetooth robot. If several robots are in range, the app will ask you to move closer to your chosen robot.
Tour of the Project Gallery
Once the robot and app are paired, the app reveals a gallery of robot configurations. Each icon contains a customized control interface for the mBot or other robots from Makeblock’s product line.
The Project Gallery (see Figure 2-3) shows a line of Official Projects, each based on a particular mBot configuration. The Playground and mBot projects (also shown in Figure 2-3) need only the materials provided in the retail mBot kit. Other projects, like the Cat Searchlight and 6-Legged Robot, ask for extra sensors, servos, or metal Makeblock parts. These extra requirements display an orange Expand label on the top right of each project icon. You can view required materials and build instructions for Official Projects by clicking the info icon on the top left of the Play screen (shown in Figure 2-4).
Figure 2-3: The Makeblock app’s Official Projects expect robots built exactly as specified in the linked instructions. Changing any element will move the project into the My Projects section.
Figure 2-4: In Play mode, some screen elements control the connected robot, like the D-Pad or the Buzz button. Others display live data from the mBot sensors.
Touching any picture in the gallery opens a control panel built for that configuration. That includes sensor displays, buttons to trigger specific behaviors, and control tools for motors or servos.
This is like the LEGOs Robot Commander app, which offers the same sort of drag-and-drop control schemes for different LEGO builds. However, when users move from Play to the Design tab (see Figure 2-5), the Makeblock app offers far more control over the tools. (See Figure 2-6.)
Figure 2-5: In Design mode, touch a screen element to change which port a sensor connects to or modify the code for that widget.
To get even more control than the Design tab, you can open the code attached to the screen widget and make more fundamental changes. Each control element is a front-end, block-based piece of code based on Google’s Blockly libraries. The gallery on the left edge of Figure 2-7 contains all the blocks necessary to change any controls or displays currently on the screen or create new ones.
Figure 2-6: The mBot can get a brightness reading from the onboard sensor, shown as the yellow circle, or an external sensor connected to port 3 or 4.
Figure 2-7: Blocks in Makeblock app’s Begin, Move, and Display palettes
Navigating Blocks on a Mobile Device
The selection of blocks in the Begin palette changes for each type of UI element. Single buttons only have “when pressed” and “when released” options. The D-Pad controller has a “when pressed” and “when released” option for each of the four directions. Numeric displays and graphs only offer a “when start” option.
Direction blocks in the Move palette assume the standard mBot motor configuration. They also allow direct control over individual motors or servos.
Purple Display blocks (see those shown in Figure 2-7) allow control over physical LEDs, sounds from the mBot’s speaker, or elements on the Makeblock app screen.
Figure 2-8: Blocks in Makeblock app’s Event, Detect, Math, and Control palettes
Event blocks look for input from attached sensors or the mobile device. Using these blocks, it’s possible to create a simple system that steers the mBot around by tilting the mobile device. This is a great opening challenge, but in our experience, kids quickly determine that the latency between the Makeblock app and the robot makes for a frustrating drive. The Detect palette provides specific blocks for most sensors sold by Makeblock. All of these are puzzle-piece shaped blocks, which means they connect with other blocks in the program and provide the numeric value of the given sensor.
Math blocks bundle all the essential arithmetic operators and functions. They also control the Makeblock app’s implementation of variables. We explore these blocks in some detail in Chapter 4, “Measurement Devices.”
Finally, the Controls palette holds all conditional statements and Wait and Repeat loops.
We started with the pre-configured mBot control program from the gallery. When we change any screen element in that program, the Makeblock app automatically saves it and asks to rename the project. Anyone can fiddle around with the pre-built robots in the gallery with full confidence that they won’t destroy the templates.
Figure 2-9: Once renamed and saved, these modified projects will appear in the My Projects gallery.
Recent versions of the Makeblock app added the Playground project to the Official Projects gallery. Playground is a slick showcase for the mBot’s different possibilities, but you can’t expand or build on what’s provided.
The Game Controller screen (shown on the next page) provides an analog joystick for precision mBot steering. It also has video game–inspired buttons to make the mBot sprint, spin, and shake.
Exploring the Music panel will reveal the limits of the mCore speaker. Clicking the finger icon shown at the top right of the panel activates the Draw-a-Path tool (shown on the next page), which allows even young children to create an independently moving mBot. If you draw a path in the box and hit the Play button, the mBot will dash off and follow that course! You will see the mBot’s progress along the path shown on the screen. The active zone is about a 1 m × 2 m rectangle. Since tables, chairs, and other real-world obstacles don’t appear on the Draw screen, collisions are pretty common. Even so, the Playground Draw-a-Path tool is a fun new option in the Makeblock app. It’s found a great home as part of Balloon Tag!
Balloon Tag
Using mobile apps opens up a world of multi-mBot games and activities that are impossible with the IR remote. One of our favorites is the mBot Balloon Tag. This is a flexible activity that’s anchored by the sheer chaotic joy of popping someone’s balloon. The materials list is self-evident: you need a balloon for each mBot and a sharp thing with which to pop the balloon. You can establish a super-serious league for this game, with standardized bots and balloons to better focus on pilot skill—but that’s not how it works in our classrooms. Our focus is more on the design and engineering aspects of the challenge.
Prep
Provide each group with an mBot, several balloons, and a lance of some sort. We’ve had success with wooden BBQ skewers, plastic straws with thumbtacks, or even sharpened pencils.
Depending on the age of the students, it’s a good idea to specify where and how the balloon should be attached to the mBot. In its base form, the mBot lacks good mounting points parallel to the ground or along its central axis. One way to create these points is by adding two right-angle Makeblock brackets and some Makeblock or LEGO beams to the rear spurs of the mBot frame.
These create a stable, rigid frame that can support much larger structures. Just don’t overload the mBot! For light-duty work like a balloon mount, cable ties can work just as well. You can either knot the balloons around the cable tie or connect them with a loop of string. Such a wobbly connection makes the inflated balloon a shifting target in the game.
Image courtesy of @MisterHay
Mounting a rigid lance to the mBot is much more difficult. You can lash it to the brass standoffs with cable ties, or to the frame alongside the battery. This process is full of interesting challenges, most of which aren’t obvious to students at first. What angle will allow the lance to best reach the balloons? Will the lance shift from side to side? Will it extend far enough in front of the mBot to push and trap the opponent’s balloon? Investigating these questions will lead students to consider outlandish designs. Many of these designs will not work because of the restrictions and requirements of the materials, and the students will have to start again. This is the heart of a powerful iterative design process. Finding answers to these questions is the core of the activity.
It’s a good idea to set a short time limit on each joust—giant melees are too chaotic. After each game, devote some time to “pitwork” and redesign.
In large groups, a bracket of balloon duels can take too long. A great alternative is to pull the lance off one mBot and make it the target, with the other mBots becoming the hunters. Allow the person controlling the target to use the Draw-a-Path tool in the Makeblock app Playground project. Hunters and prey will take turns moving. The extra mobility of the Draw-a-Path tool allows the player controlling the target bot to juke around clustered hunters. This can cause some significant pileups. This asymmetric version of Balloon Tag, where each side is using a different control method, works great where there’s a short time frame or a fixed number of turns for both sides. It’s also a quick way to test new designs at the end of a group session.
If you have access to materials beyond the retail mBot kit, there are even more possibilities. With a servo motor and some clever mounting, you can control either the lance or balloon in the Makeblock app control panel while driving. This drastically increases the challenge level of building and steering. Classroom tests show significantly higher self-popped balloons when servos are used.
Utilizing the default mBot build that includes a Line Follower sensor under the chassis creates some interesting racing variants of Balloon Tag. Instead of a grand robot melee, create a small course of line-following paths with open spaces in between. Teams start with the Line-Following project, but modify it to start with a button press and add the driving controls of their choice. Robots jostle and fight in the open spaces, but need to locate the line and use the line-following mode to travel to the next waypoint. This structure breaks up the mad scrum of normal Balloon Tag with high-emotion chase segments, as the lead mBots rush to the end of each path with their balloons exposed to the crowd.
We call this Balloon Tag to specifically connect to the freewheeling dynamic games our kids play at recess. See what new ideas emerge from adding a new part, or how altering a rule changes how people play. In each case, the new tools will create more complications, more challenges, and more powerful, student-driven learning.
Image courtesy of @robotics_fun
mBlock
Makeblock’s mBlock is a visual programming environment for Windows, Mac, Linux, and Chromebook computers—if you’re working on a device that has a screen and physical keyboard, then there’s a version of mBlock for you. It expands on all the capabilities offered in the tablet programming apps and provides the most robust tool for programming the mBot.
The mBlock platform is a direct fork of Scratch from MIT Media Lab’s Lifelong Kindergarten (LLK) Group, and it inherits Scratch’s incredible feature set. It presents robotics commands in a format familiar to millions of young people.
Mitchel Resnick, head of the LLK Group, often describes Scratch as having “low floors, high ceilings, and wide walls.” In the programming world, low floors means that everyone can enter, with no background or prerequisites.
High ceilings allow users to grow and expand their skills for years or decades before hitting something that “just can’t be done.” Wide walls implies that the tools should allow as many different types of creative expression as possible. Scratch does that—it provides the tools to make everything from anime music videos to multiplayer platformers.
High school students often scoff at Scratch and other block-based languages as “programming for kids.” This reflects their own inexperience rather than the potential of block-based programming. The mind-blowing projects from Scratch user “griffpatch,” or coming out of UC Berkeley’s Beauty and Joy of Computing course, should shatter that illusion. This is not the last time you’ll hear us say, “Simple doesn’t mean easy.”
The mBlock platform is a natural extension of the house Scratch built. It adds an extra room for physical robotics, without disrupting the existing floor or ceiling.
If you’re interested in the non-robotics potential of Scratch, there is a great library of books waiting for you. We recommend:
- Make: Tech DIY: Easy Electronics Projects for Parents and Kids, by Jaymes Dec and Ji Sun Lee (Maker Media, 2016)
- The Invent to Learn Guide to Fun, by Josh Burker (Constructing Modern Knowledge Press, 2016)
- The Big Book of Makerspace Projects: Inspiring Makers to Experiment, Create, and Learn, by Colleen Graves and Aaron Graves (McGraw-Hill Education TAB, 2016)
- Coding Games in Scratch, by Jon Woodcock (DK Children, 2015)
Although this chapter will teach you how to build functioning programs from a blank screen, there are many discrete worlds to explore in Scratch. Dive deep in some other areas and see how much that exploration adds to your robots!
Connecting to mBlock
As of publication, the current version (v3.4.11) of mBlock for Windows, Mac, and Linux computers bundles the Scratch-based block environment and the Arduino tools into a single platform-native program. There is also a web-based tool, available at http://editor.makeblock.com/ide.html, which provides the same toolset within a modern browser. Beta versions of mBlock 4.0 suggest that, going forward, Makeblock will abandon the different versions for Windows, Mac, and Linux in favor of a downloadable version of the browser-based tool. Since the functionality with each of these versions is nearly identical, all of the programs or projects in this book should work on any future version of mBlock. However, the operating system–specific instructions for connection may change over time.
Every time you open mBlock, you’ll need to connect the board to the software using one of three possible connections: Bluetooth, 2.4G wireless serial, or USB. All retail mBlock kits have USB ports and one wireless connection. If you bought mCore boards without buying the mBot kit, you’ll only have access to USB. The wireless modules are for sale from Makeblock, and they’re easy to swap between boards. If you’re using both serial and Bluetooth connections, remember that you identify the Bluetooth boards from a distance by the copper antenna shown in Figure 2-10.
A Word about Connection Types
On a small scale, there’s not a huge difference between the Bluetooth and wireless serial connection. If you’re considering a larger scale mBot army where you’ll work primarily or exclusively with laptops, we strongly recommend the 2.4G serial adapters. In the worst-case scenario, when kids have ignored our color-coded stickers and mixed up mBots and the paired USB dongles, the 2.4G serial module has a super-clear indicator when this unit’s best beloved dongle is plugged in nearby. This means that I can troubleshoot most connection problems from across the room, without ever seeing the laptop’s screen.
Figure 2-10: In an environment with both wireless serial and Bluetooth hardware, the printed squiggle antenna on the Bluetooth board helps distinguish between the two tiny boards.
Bluetooth may offer maximum flexibility for a single mBot unit, but 2.4G serial is the best choice in any environment where students will work with multiple mBots and computers.
Connecting Bluetooth for Windows
Connecting with Windows is easy. Make sure the Bluetooth module is installed on your mCore, turn on the mCore, and launch mBlock. Make sure your computer has Bluetooth enabled. Click on the Connect menu, then Bluetooth, then Discover.
When your computer discovers your Makeblock Bluetooth module, the following screen will pop up with the specific address of that Bluetooth module.
Click that device and you’ll get the confirmation message shown in the following image. You are now connected and ready to begin programming!
Connecting Bluetooth for macOS
Bluetooth devices need to be paired before software can access them. On macOS, that happens in the Bluetooth System Preferences panel. Make sure the Bluetooth module is connected to the mCore, and then turn it on. After three beeps, you should see a new entry show up in the Bluetooth control panel. This can either be a messy MAC address or a well-named Makeblock entry. The non-human-readable name should only appear the first time you connect to a new Bluetooth module. Click PAIR on the new device.
That entry will quickly flip back to a worrisome “Not connected.” Don’t stress!
Figure 2-11: When pairing a Bluetooth module for the first time, the MAC address appears instead of the Makeblock name.
With this accomplished, return to mBlock and open the Connect menu. Despite the existence of a Bluetooth item in that list, you need to open the Serial submenu and then choose the new tty.Makeblock entry. (Yes, this is a mess.) With a top-level Bluetooth menu that stays grayed out and two permanent entries in the Serial menu that use the word Bluetooth, the important thing to click is /dev/tty.Makeblock-ELETSPP.
When that works, you’ll see a small check mark appear by the /dev/tty.Makeblock-ELETSPP entry and the window header will show Serial Port Connected.
Connecting 2.4G Wireless Serial
The crucial thing to remember when using the wireless serial connector is that each USB dongle and the small communications board that ship together are paired to each other. Don’t throw all of the USB dongles in a drawer! Use a bit of Velcro to attach the dongle to the mBot frame when not in use. If you’re working in a classroom setting, pull out the sharpies and stickers and label them posthaste!
If you power on the mBot when the USB dongle is not attached to a nearby computer, a tiny blue LED on the communication board blinks. This blue light will glow steady within seconds when the dongle is connected. Keep this in mind if you ever have to sort through a large pile of mismatched components.
Once the mBot is powered and the USB dongle plugged in, it just takes a single click to connect the board to mBlock.
When the connection is active, the status message in the top bar will change.
Connecting USB
Although USB is an incredibly familiar technology, there are two points worth noting about the mCore’s USB connection.
Figure 2-12: The mCore uses a USB-B plug, the style often used for printers. It’s sturdy and can take a beating.
First, the power switch on the board needs to be on in order connect to mBlock over USB, whether a battery is attached or not. This goes against safe practices for normal Arduino boards, which can receive power from either an external source or USB, but not both at once. The mCore board’s design prevents this “two power source” problem. If there is a rechargeable battery attached, plugging in the USB cable while the power switch is off will charge the lithium battery.
Second, the mCore board uses a USB-to-serial chip that’s common to a Chinese-made Arduino clone known as the CH340. This chip requires the installation of a specific driver. If you connect the USB cable and don’t see a new entry appear in the Connect → Serial Port menu, check to see if you are missing this driver.
The Install Arduino Driver item in the Connect menu will install the CH340/CH341 driver for your platform from within mBlock. Note that this requires admin access on most computers, so it can be tricky to do with student machines. This is only required when using a wired USB connection to the mCore.
Keeping the previous two notes in mind, opening a USB connection is simple. Connect the board to the laptop, make sure the power switch is set to ON, and select the proper serial port from the menu. On Windows machines, this will be COMx; on Macs it will be in the form /dev/wchusbserialXXXX.
Figure 2-13: The wired USB connection is the last item on the serial port list.
So far, we’re using all these as tethered connections, even though two are wireless. Tethered simply means that the program logic stays on the computer and is sent to the mCore board over this active connection. There’s a constant two-way stream of instructions and sensor data between the computer and robot. If this communication is disrupted while the mBot is battery powered, the robot will continue to perform the last chunk of the program sent by mBlock. When this disruption happens because the mBot moves out of range of the Bluetooth or 2.4G signal, this can cause strange behaviors that don’t scream “out of range.” Restore the connection by connecting the hardware or bringing the mBot back within range, and restart the mBlock program.
Traffic Light Classroom Volume Meter
Traffic light volume meters are a staple of teacher supply catalogs. The various LED units make this a very accessible physical project.
There’s a real value to prototyping physical systems using the sprites in mBlock. Digital prototyping separates the programming logic from construction and wiring, and allows students to focus on the behavior. The version presented here uses the computer’s microphone to measure volume at first, instead of immediately bringing in the mBlock’s Me Sound sensor. In our classrooms, first-draft prototypes normally rely on sensors on the computer, or even Scratch variables that represent ideal sensor data, instead of mBot hardware.
Start a new mBlock project and delete the default panda by right-clicking the icon in the Sprites panel and clicking Delete or using the scissor tool.
Then, create a new sprite using the Paintbrush tool above the Sprites panel. Change to Vector Mode in the image editor (this will move the drawing tools to the right edge of the screen) and create a simple, filled, gray rectangle. Vector mode will allow us to easily resize this shape later to fit around the green, yellow, and red traffic lights.
Next, click the blue arrow to access the details for this sprite. Rename the object now, as a way to model best practice for your students. Don’t wait until you have a confusing muddle of Sprite 1 through Sprite 16. Do it now. Now.
As an offshoot of Scratch, mBlock has a sizable library of sprites and backgrounds, as shown in the next image (although it doesn’t look sizable). We’ll use one of these as the basis for our three traffic lights. Click on the tiny creature in the New Sprite bar and choose Button 1 from the Things group. This works fine for the green light, but we’ll need to copy and recolor it for the other two.
First, duplicate the button twice by right-clicking it on the Stage or in the Sprites panel. Then, rename all three buttons to show the color each one will become.
Select the RedLight in the Sprites panel and then open the Costumes panel. The Button sprite was already a vector graphic, so all we’ll need to do is recolor the gradient using the Vector Bucket. Choose two yellowish colors that work for the light and click away. Notice that the Button sprite has two shapes that each need to be recolored.
Figure 2-14: This block places the green traffic light on the Stage, and then constantly measures the sound level. The light is bright when the sound is low and dark when the volume rises.
Now it’s time to add code to our project. In mBlock, like in Scratch, each Sprite (and the Background!) has a Scripts panel for code that controls its behavior and appearance. When you are writing code designed to control a mobile mBot, it makes sense to keep all of those scripts collected in one Sprite. A project like this is designed to use sensor data from the mBot to change what’s displayed on the Stage. Therefore it makes sense for each sprite to read data and adjust its appearance. Here’s one way that might look for the green light.
The Green Flag block, as it’s commonly known in Scratch circles, is a basic start-of-program trigger. Every sprite can have its own Green Flag block. In fact, an individual sprite could have several. Having several start blocks allows a sprite to have parallel routines, which can be exceptionally useful. For this first program, however, we’ll just use one block.
When the program starts, it’s sensible to reset the position and appearance of the sprites. It’s not technically necessary here, since these sprites don’t move at any point during our program, but it’s another good habit to model for students. Like Scratch, mBlock does not have any built-in reset or cleanup. Adding a GoTo block that defines where a sprite should start on the Stage means that that clicking the GreenFlag to restart the program will also undo any accidental clicks that moved the GreenLight Sprite on the Stage the next time the program runs. We need a similar block to reset any changes made to the appearance of the sprites, including size, costumes, or graphic effects like brightness or transparency. Since the program will adjust the brightness of the traffic light sprites to indicate that they’re lit, we’ll include the ClearGraphicEffects block under the GoTo block to ensure that this light starts dark.
All of the blocks shown in Figure 2-14 execute once, in the order displayed, at the start of the program. Everything that follows is wrapped in a Forever loop, meaning that they will cycle quickly and endlessly.
Next, we will check sound using the Loudness block from the Sensing palette. All of Scratch’s sensing capabilities have been passed down to mBlock. Scratch was designed to take advantage of the microphones and webcams built into most computers, including a simple block to measure ambient noise. It’s great to make use of these built-in options when starting out with young programmers. By starting out with only software tools, we allow kids to focus on the core ideas of their program before introducing wires and other physical complications. Then, once the ideas are sound, out come the full robots.
An If/Else comparator checks the loudness level against our chosen threshold value of 40. The mBlock Loudness sensor returns values between 0 and 100, so 40 is on the soft side, but not deathly quiet. By measuring and comparing the loudness against a threshold value, we can create different behaviors for the light based on the sound levels.
Instead of making distinct costumes for the lit and unlit versions of each light, we’ll use the Brightness control from the Looks palette. Scratch’s graphics properties were passed down to mBlock and can be used to modify the appearance of a sprite on the Stage without changing the costume itself. While novel combinations of Warp, Ghost, Pixelate, and the other effect options are key to many great “lose a life” animations, they can also render a sprite invisible and unrecognizable. Use them wisely. All of these blocks can have positive or negative numbers as values, but that won’t always translate into an observable change.
In Figure 2-15, the program sets the brightness of the GreenLight sprite based on the reported value of the sound sensor. If the sound level is lower than 40, then the brightness is set to positive 20, or lit. If it’s higher than 40, then the classroom is assumed to be too loud, and the green light goes dark, with a brightness of –40.
Figure 2-15: Say blocks in an mBlock script place a word balloon above their sprite.
Dragging a script block to another sprite will copy that block to the new sprite. This is a great shortcut, but also an easy way to introduce errors. If we copy this script block from the GreenLight to the RedLight sprite, it creates two lights that move in sync, instead of one light that turns on when the room is loud and another that stays lit when it’s quiet. Copy the block, but then open the RedLight script panel to make the necessary changes.
The easiest part to adjust is the position of the red light itself. Keeping the X coordinates the same ensures that the lights stay vertically aligned. Of course you can change that design if you’re used to horizontal traffic lights.
Figure 2-16: Right-clicking on the angled green block will allow you to swap between greater than (>), less than (<), or equals.
We also need to change the script so that the sound sensor checks for sound levels above the threshold value. In mBlock, each angled green operator block can change between checking greater than, less than, or equality. When you’re revising a program, changing these blocks by right-clicking them can save a lot of time as opposed to dragging new blocks out from the palette.
We can copy and modify the YellowLight script in much the same way. The only wrinkle is that the yellow light needs to be a Goldilocks, only turning on when the sound isn’t too soft or too loud. Building logical groups of conditions in Scratch requires <AND> and <OR> blocks. Like the arithmetic blocks, you can stack these really deep. One of the biggest UI hurdles of Scratch variants is that long calculations or conditionals can sometimes stretch beyond the width of the Scripts window. There’s a small arrow button on the border between the Stage and the panels that will minimize the Stage and provide some extra width to the Scripts area.
Figure 2-17: The green <AND> operator allows us to stack two sensor checks in a single <IF> statement to check for values within a given range.
With that last script in place, the software prototype is ready for testing. Since we’ve used mBlock’s Loudness block instead of the Me Sound Sensor, the software prototype is fully functional.
There’s one last helpful block we should add before testing the prototype. Although you can click any sensor block and see the current value, this is cumbersome for something as dynamic as sound. Using a Say block from the Looks palette inside a Forever loop is a great way to stick a sensor value up on the screen. This program has three different Forever loops running, one inside each light, and the Say block works fine in any of them.
So far, this project is fully software-based and uses only components that mBlock inherited from Scratch. Many inspired individuals in our classes are eager to build from day one and grumble over the time spent creating these software prototypes. Fortunately, mBlock and mCore make it easy to grow functioning prototypes into a final physical version, making the next steps feel like incremental revision rather than a blank slate.
Everyone can benefit from working out mistakes and misconceptions in Scratch’s low-floor environment where everything just works. When working with groups of young people, the software prototype is a critical part of every project. Once a large group starts working with materials, managing those parts consumes a large part of a mentor’s or teacher’s attention. Once there are cables and batteries strewn over the table, it’s difficult to quickly identify whether a problem lies in the hardware or the underlying ideas. Completing a software prototype is a proof-of-concept and provides a touchstone through the rest of the project.
When a project requires a sensor beyond what’s included in the mBlock software sandbox, we often connect just the mCore and inputs and model the outputs on the Stage. When particular sensors are in short supply, a prototype can use mBlock variables to simulate the values expected from the sensor. Limited prototypes don’t guarantee that the final project will work, but a design that can’t work in software is unlikely to thrive with real parts.
Before we push the traffic light classroom volume meter out of the software-only nest, it’s worth looking closely at how the whole range of Makeblock sensors interacts with mBlock.
Working with Sensors in mBlock
Although there’s a long list of different sensors created for the mBot platform when working in mBlock, it helps to think of them as belonging to two basic categories.
Digital sensors measure one thing in the world and report back a binary value: yes or no, on or off, or 1 or 0. Sometimes these are mechanically simple sensors, like a classic push button. In other cases, like the passive infrared motion sensor, the hardware is complex but the value reported back is still binary.
In mBlock, blocks that have a binary value are elongated hexagons. Only blocks of this shape can fit in the question spots of conditional loops.
Figure 2-18: Green operators or blue sensor blocks with six sides report binary values, just True/False or 0/1.
Despite the shape, these blocks can also be placed into the round openings in Arithmetic blocks and the ever useful Say blocks. This inconsistency is bothersome, but frequently useful.
Figure 2-19: Using a hexagonal block in an arithmetic operator can create a particular value when the sensor reports true, and 0 when the sensor reports false.
Analog sensors, the other type of sensor, report back their measurement to mBlock as a range of numeric values, normally whole numbers (but not always), and normally positive (but not always).
How these sensors arrive at their values can vary wildly, but at the base level they all are reporting information by adjusting the voltage on the wire. Most microcontrollers, expecting just a binary signal, have a limited ability to read analog signals: the ATmega328 microcontroller, the heart of the Arduino Uno and the mCore, can only read analog signals on ports 3 and 4. Makeblock color-codes analog sensors and ports with dark gray (possibly the least useful color to apply to black plastic parts!).
All analog sensor blocks are ovals, meaning that you can use the values from them in any place you would write a number or place another oval block.
The last pseudo-category of mBlock sensors bundle multiple channels of information together into a single physical package. The most familiar for kids is the Me Joystick, which is a standard analog thumbstick similar to the ones found on every video game controller since the Nintendo 64. In mBlock, the block for the Me Joystick will report on only a single value, either the X-axis value or the Y-axis, at a time. A single block can never report both values, but you can bundle them together into a larger statement as shown in Figure 2-20.
Figure 2-20: This single block allows the Me Joystick to move a sprite around the Stage.
Other bundled sensors in the Makeblock line include the mBot’s line-follower (two digital light sensors) and the Me 3-axis Accelerometer and Gyro Sensor, which reports three different angle readings.
Sensor Recipes
To interact with the real world, an mBlock needs to describe what behavior should occur when the program receives the sensor data. The traffic light volume meter program shows one basic example—each component measures the sound sensor constantly and switches between two states as a result.
This is a common stumbling point for new programmers in Scratch or mBlock. Often, they can describe the behavior they want in very broad terms (“the spaceships, like, shoot all the bugs and they go SQUUUISH!!”) but lack the vocabulary and experience to break that complex action into smaller components.
Although students can often describe the behavior they want, it takes familiarity with basic programming concepts and the mBlock environment to see how blocks might combine to create those behaviors. To help bridge that gap, we’ve included a short recipe list that catalogs basic ways to tie sensor data to outputs, labeled with kid descriptors alongside more technical terms.
Exploring these models should help learners begin to develop an understanding of the way imagined behaviors might look in blocks or code. Recipes are useful tools to help in transitioning from simply observing the sensor value to creating a system that uses the data.
Block-based programming reveals the visual structure of these programming concepts—structures that can work with any sensor and any output. For clarity, we’ve used the onboard light sensor for analog values, the onboard button for digital values, and M1 motor for a generic output. When reading through these recipes, think of the inputs and outputs as placeholders for any sensor or output you want to work with.
“Wait for the Sensor Reading to Hit a Value and Then Do Something,” Also Known as Latching Trigger
This is the classic intruder alarm from movies. This loop sets a behavior, and then constantly checks the sensor and compares it against a threshold value. Once that threshold is crossed, the behavior changes and never changes back.
“Whenever the Sensor Hits a Value, Do Something Until I Say Stop,” Also Known as Latching Trigger with Reset
While it sometimes feels like the car alarm outside your window will never shut up, most do include some form of a reset button. Building on the previous code block, this script adds the ability to use another sensor to reset to the first behavior.
“Constantly, Based on the Value, Do This or That,” Also Known as State Check
This is the same sort of check used in the traffic light classroom volume meter earlier. This script checks a sensor constantly, and changes between behaviors based on the last seen value.
While a digital sensor only swaps between two values, analog sensors generate ranges of values and behaviors. When you’re looking for a program to do “this, or that, or that other thing,” it’s time to expand the state check script. This variation of the state monitor uses nested If/Else blocks.
It’s important to note that this script reads the sensor twice. Since these readings happen in quick succession, it’s reasonable to assume that the light levels haven’t changed drastically, but they can generate different values. Furthermore, when mBlock programs are running tethered, each sensor reading requires two-way communication between the computer and the mCore board. This communication should take less than 100 milliseconds, but it might take longer, and that delay will only grow as the program becomes more complex.
To avoid these problems, we need some way to store a sensor reading and check it several times. In other words, we need a variable.
Figure 2-21: You can find the blocks for variables and lists in the Data&Blocks palette. Select either the Make a Variable or Make a List button.
Variables in mBlock are designed to be approachable and easy to track. Once a new variable is created and named (name it well!), it’s automatically shown in the corner of the screen. This display can be turned off, either by unchecking the small box next to the variable name or by using the Hide Variable block.
There are only a few variable blocks . The block Set VariableName does just that—overwriting any current data and leaving the new value. The block Change VariableName increments, or decrements with a negative number, the current value. Most importantly for our current recipe, the oval reporter for VariableName can be used all over mBlock, in any round input spot.
Here’s that three-state check from Figure 2-21 rewritten to use a variable to store the Light Sensor value.
Now the Light Sensor is read once, at the top of the loop, and the value is stored in LightVal. All the checks are made against this stored data, rather than reaching out to the sensor itself. The loop is now protected from sudden changes in the sensor data, and the communication time between mBlock and the mCore board is minimized.
This loop checks the sensor reading against two threshold values, giving three possible outcomes: low, high, and between. In this example, the motor runs forward at full speed if the value in LightVal is above 700, runs backward full speed if it’s below 300, and turns off for any values between 700 and 300.
Using the mBlocks <AND> operator, a single <IF> statement can check for values between two thresholds. With this technique, we can slice a sensor reading into a large number of discrete segments. Since the <IF> statements are constructed so that only one can be true in a given moment, these are called switch cases.
The performance of switch cases depends entirely on the accuracy of the sensor and the threshold values. It’s possible to write a 12-part switch case for a light sensor, but unless the ambient light is perfectly consistent, you will have to spend a lot of time adjusting the threshold values to account for cloudy days or crowded rooms.
Remember that these recipes can be used with any sensor and any output behavior. If the goal is to turn on a specific number of lights or perform other discrete actions, then switch cases like these are a dependable tool.
“When the Value on the Sensor Grows, Do More Stuff,” Also Known as Proportional Control
In the following code, LightVal is tied to the numeric value of the light sensor and is used to directly control the speed of the motor. This sounds great at first—when the light is dim the motor speed will be low, and when the light is bright the motor speed will be high, right? The reality will be a bit underwhelming. When there’s a gap between concept and execution, it helps to look for the assumptions in the program. By using the value in LightVal as the motor speed, our program assumes that the sensor generates values exactly within the motor’s input range.
The Me Light Sensor reports values in a range from approximately 0 to 1000, where comfortable indoor lighting ranges between 400 and 600. The M1 motor block can spin in either direction, with –255 being full reverse and 255 full speed ahead. Additionally, speeds too close to zero don’t generate enough force to turn the gears in the yellow mBlock motors. This mismatch in sensor output and motor input values explains the dull behavior in the loop above. Directly plugging the light sensor values into the motor block will turn it full speed forward in most lit rooms. Worse, since the light level is never negative, the motor will never spin in reverse.
With a particular sensor, a given output, and a little time, it’s easy enough to throw together some arithmetic to squash the sensor values into the input’s ideal range. If the light values in our room are between 400 and 600, but we want motor speeds between –255 and 255, we could use subtraction to shift the range.
The act of translating a value from one range to another is called mapping, and we can turn this mapping into a custom block.
Figure 2-22: If ambient light readings range between 300 and 700, subtracting 500 from each reading will generate motor outputs in the –200 to 200 range, causing erratic back-and-forth motions.
Figure 2-23: Custom blocks in mBlock are tied to particular sprites. Here, the panda knows how to use Map, but the polar bear doesn’t.
Custom blocks are powerful tools that can do wonders for the readability of mBlock programs. As a general rule, if a particular sequence of blocks shows up more than twice in a program, they should probably collected as a custom block.
It’s important to note that these custom blocks are not distinct functions or programs. They share namespace with, and can perform the same actions as, the larger program. Since custom blocks cannot be reporters, the best way to save the output of our Map function is to create a variable called map_output.
Figure 2-24: This custom block re-creates Arduino’s map() function. For more information on that function, see https://www.arduino.cc/en/Reference/Map.
To use this version of Map, we need to know the range of the input and the range of the output. Once that’s settled, we can drop the sensor block into the first bubble.
Figure 2-25: Place the value you want to shift in the first Map slot, followed by the range of that input, then the desired output range.
New programmers frequently use mBlock’s custom block functions to clarify and organize their programs. For mentors or teachers, custom blocks are an amazing way to expand mBlock’s toolset. Adding some custom blocks to a program template for a class or sharing a sprite bundled with custom blocks is a great way to allow novice programmers to develop an understanding of functions like Map through meaningful, motivated use.
Traffic Light Classroom Volume Meter, Revisited
With these new techniques at hand, it’s time to revisit the software prototype for our traffic light classroom volume meter.
When we left our software prototype earlier, it used mBlock’s Loudness block instead of the Me Sound sensor. As a consequence, our threshold values were based on the loudness range from 0 to 100. Now that we’re ready to move from software prototype to physical creation, it’s time to hook up the Me Sound sensor and check out real-world values.
Start by connecting the Me Sound sensor to port 3 of the mCore.
Figure 2-26: The Me Sound Sensor reports analog values and must use the mCore’s analog inputs, either port 3 or 4.
When we connect a new sensor, our first test program is always a Say block in a Forever loop. This tests the hardware and software connections all the way from the sensor to mBlock’s Stage, and shows real-world sensor values. With this tiny script running, test out the Me Sound Sensor. Scream for a bit. Type on the keyboard, and bang on the table. Have everyone in the room hold their breath for 10 seconds. While the technical sensor values might range from 0 to 1024, it’s far more valuable to see what values your quiet and your loud generate in your particular room. Only the actual data from your environment will create useful threshold values for your program. The numbers used in the following traffic light examples are tied to the classroom and kids who designed these particular traffic lights.
Watching the volume data flicker in a Say block’s word balloon is a good reminder that sound levels in a room change rapidly. Volume measures a constant sequence of momentary noises: a dropped book, squeaking chair, or collective breath. As someone prone to making loud sneezes, I’d like this traffic light to ignore some momentary volume spikes and respond instead to steady increases over time. To do this, we’ll open the door to the world of sampling.
Figure 2-27: Using custom blocks allows us to visually hide the complexity of this sampling process outside the main body of our traffic light program.
The block in Figure 2-27 shows a very basic way to sample a sensor and report back the mean value instead of a single reading. Here, this means creating one more variable, named RecentSounds in the example, and using it to store 10 sensor readings. Note that RecentSounds doesn’t keep 10 distinct readings; it just adds all of the values together. Using lists instead of variables, mBlock can store persistent collections of incoming data, which we explore in Chapter 4. After the readings are complete, the average is stored in the familiar SoundLevel block. There’s no Forever loop in this block because it’s designed to be used as a single command in a larger program.
So far, we’ve focused on monitoring the sound levels in the room using the microphone sensor. To turn that passive sensor into a traffic light, we’ll need to dive into programmable RGB LEDs. Traffic lights in the real world don’t normally use color-changing lights—the top is always red, and the bottom is always green. While the mBot can power a bunch of fixed-color LEDs, the LED accessories they sell are all addressable, meaning that every light in the strip can have a unique color. These RGB lights are technically WS2812, similar to Adafruit’s original NeoPixels. Makeblock sells several programmable RGB LEDs in several different forms, but they all work the same way in mBlock and the Makeblock app.
Connect each light board to a different port on the mBlock. Since the Me Sound Sensor is currently using port 3, this means connecting a light to ports 1, 2, and 4.
Using a separate block for each light source (either the Me LED board or the longer Me LED strips), specify the intensity for the red, green, and blue channels with a value between 0 and 255.
There are plenty of fancy tricks available for working with these lights in mBlock, but for the traffic light all we need is to have one light be the appropriate color and have the other two off.
This program is human-readable up to a point. When the mBlock Scripts panel is filled with these nearly identical blocks, it’s really easy to lose track of whether port 2 is supposed to be the green light or the yellow light. To make the script easier to parse, we can create a custom block—this time to simply isolate the LED blocks into meaningful, named groups.
Figure 2-28: Once custom blocks are working, there’s no need to keep them visually close to the main program. Banish them to the scroll-right hinterlands and declutter your workspace.
This revised program now combines the screen-based prototype with real-world lights, and now students have a great opportunity to cross-check behaviors between the two.
Upload to Arduino
All of the projects so far haven’t actually changed the bits written into the memory of the mCore. Using the remote control to move the mBot around doesn’t change the software. The Makeblock app and the programming we’ve done so far in mBlock constantly send commands to the mBot, but never rewrite the program stored in memory on the board.
Now, we’ll move from tethered to independent operation of the mBot. Using a wired USB connection, we can upload a program directly to the mCore that will stay loaded through resets and power cycles. Uploading a program is the only way to create a robot that that operates without a computer on hand.
At this point, anyone familiar with “normal” Arduino or microcontrollers is sighing with exasperation, “Finally!” Uploading code to the board to blink an LED is how 99 percent of Arduino tutorials start. Tethered programs have provided a ton of features that disappear when uploading code to the mCore. Untethered, there’s no interaction between the board and the computer, hence no way to use many of the mBlock features derived from Scratch. Every block you use will be translated into written Arduino code. When you compile and upload an mBlock program, it needs to have a different “hat” than a tethered program. (Scratch convention names the curvy, top-of-the-script block a hat.)
Figure 2-29: Only the GreenFlag hat will work when the mBot is tethered, and the mBot Program hat has no effect.
These programs create the same behavior, but the script that uses the mBot Program hat requires compilation and upload.
In general, only blocks from the Data&Blocks, Control, Operators, and Robots palettes work in compiled and uploaded programs. If any other blocks appear in a script under the mBlock hat, mBlock will show you an error message.
Figure 2-30: These light blue blocks come from mBlock’s Sensing palette and control timing functions inside mBlock. They can’t be used in an uploaded program.
Independent Traffic Light Classroom Volume Meter
If the volume meter is ever going to be useful in a classroom setting, it needs to work like an appliance—flip the power switch and the lights start right up. Fortunately, mBlock makes it simple to change an interactive program that requires a computer to one that’s uploaded to the board and works independently.
Figure 2-31: The custom blocks used to control the RGB lights are still part of this program, but they are just off-Stage for clarity at the moment.
Nothing from the earlier version of the program has been removed. We’ve added an extra script under the mBot Program hat and removed the two blocks that referred to the sprite’s position on the screen. When we compile and upload, only the blocks under the mBot Program hat and any custom blocks used in that script will translate into Arduino code. This means that the tethered version can coexist with the compiled version in one mBlock file. If the green flag is clicked while an mBot is connected, the tethered program will run. If you want to have the program run without a computer, select Arduino mode by right-clicking the mBot Program hat. You can also go to the Edit menu and select it there.
Figure 2-32: Choosing Upload to Arduino from the mBot hat context menu will switch mBlock to Arduino mode. Choose Small Stage Layout from the Edit menu to switch back.
In Arduino mode, mBlock hides the Stage and sprites in favor of a text window that shows a current text version of the script. The Scripts and Blocks palettes are still visible, and changes made to the block version of the program will automatically update the text version.
Figure 2-33: On the lower-right corner of the screen when you’re in Arduino mode, you can see output from the compiler, and data that would be sent to the serial monitor in the Arduino serial monitor when using traditional Arduino tools.
Careful reading of the text version can reveal a lot about how mBlock translated between blocks and Arduino code. If you look closely at the text version on the right of the following image, you’ll see that the SetGreenLight custom block has arrived as the Arduino function void SetGreenLight().
Selecting Upload to Arduino will launch the compiler. The compiler will translate the human-readable Arduino program into a hex file, and then will upload that hex to the mCore. Error messages that appear in the lower-right window during compilation are often a weird combination of compiler errors and serial communication codes. Troubleshooting that universe of errors is well beyond the scope of this book. In practice, most errors that students encounter at this stage can be traced back to mBots with disconnected USB cables. If this is the first time you’re using a particular computer to upload a program, make sure the Arduino drivers are installed. That process is covered earlier in this chapter in the overview of wireless, Bluetooth, and USB connections.
Once the upload is complete, the traffic light volume meter program is now written to the mCore’s stable memory. Turn off the board, unplug the USB cable, and build a better traffic light.
Finally! Instead of a versatile robot that can be controlled with an IR remote, programmed with a Bluetooth tablet, or issued commands from mBlock, we have a battery-powered traffic light that responds to noise. Moving from the flexible tool that could become anything to a narrow, single-purpose thing is a huge step for young designers. But it shouldn’t be the last step in the design process.
Half-built cardboard prototypes like this often represent the endpoint of student projects. From the perspective of a student following a strict feature checklist, this traffic light volume meter is clearly “done.” Making any changes will involve undoing something that already works, an idea that is anathema to goal-focused learners. Without stepping on the learners’ celebration, we insist on reflection and peer review at these seemingly terminal prototype stages. Young Makers need to develop an iterative mindset and an eye for improvements, even when it means “redoing” work. One of the best ways to force this reflection is to put the prototype in use, and have testers deliver honest feedback to the designer.
Simple critiques can prompt significant changes in the design. If a user wants a way to adjust the volume levels on his or her own, how many systems does that effect? First, it means adding some extra form of input to the project, probably some buttons or a potentiometer. As a result, that means using fewer ports for the lights. Is it better to use the LED strip, or position the mCore to use the onboard LEDs? Which design would be more stable and allow teachers to place the light vertically or horizontally?
The mBot’s expandability, combined with mBlock’s beginner-friendly programming syntax, makes it easy to start creating interactive projects like the traffic light. But the challenges of design come from refining those initial prototypes into something that meets the demands of real-world users and environments. Use the power and convenience of these tools as a shortcut to those hard/fun problems.
Reinstall the Default Program
As hard as it might be to believe, the novelty of this stand-alone Ssssh-meter will wear off. When that happens, you’ll need to replace the traffic light volume meter program with a program that can communicate with mBlock.
Use a USB cable to connect the mCore to the computer and connect to mBlock via the serial port. Then select between the two confusingly named mCore options: Update Firmware and Reset Default Program.
There is a detailed comparison between these two versions in Chapter 1, “From Kit to Classroom,” but the takeaway is that Update Firmware is the better choice unless you’re planning on using the IR remote. Make your choice, and then wait for the three-tone chime (Default Program) or chirp (Update Firmware) when the upload is complete.
Where We’re Heading from Here
With this wide array of tools, it’s clear that “How do I control my mBot?” is the wrong question. Given any task, there’s probably a way to accomplish it using the Makeblock app or mBlock, or by using the Arduino environment. For an open platform like the mBot, you can choose the most focused tool, or the most flexible tool, or just use one with which you’re already comfortable. The remaining project chapters will each use one specific software tool, mainly for clarity in the instructions. We’ll call out any unique features of a particular programming environment when we use them. Other than those exceptions, you should be able to build all the animatronics and data loggers from the following chapters using the Makeblock app, mBlock, or the Arduino IDE.