My Cart:

0 item(s) - £0.00
You have no items in your shopping cart.


Robot Buggy Part 6 Coding With The MakeCode Editor

To explain coding with the Microsoft MakeCode Editor we'll hand over to Martin Woolley. Martin not only wrote the code that we use for the remote controlled buggies, he also designed the Bluetooth profile for the BBC micro:bit. Over to you Martin...

PXT Editor -buggy-dpad-870

From a software point of view, the Kitronik Robot Wars remote controlled buggy consists of some code running on a BBC micro:bit and an application called ‘micro:bit Blue’ running on an Android smartphone or tablet. The two devices communicate using special messages called ‘events’ which are transmitted from the smartphone application to the BBC micro:bit using Bluetooth, a wireless communications technology which uses very little power and which both the smartphone and BBC micro:bit are equipped with.

The smartphone application sends different types of event, each with its own unique event code depending on which buttons on the touchscreen gamepads are touched or released. An event code is just a simple number and the code on the micro:bit decides what it should do, based on the event codes it is receiving.

Controlling the Buggy:

The BBC micro:bit is plugged into the Kitronik buggy using its edge connector, in this case via the Kitronik Motor Driver Board that the microbit is plugged into. The edge connector is divided into several separate electrical ‘pins’. The micro:bit software can control whether a pin has a high electrical value or a low value. In digital terms, we can think of this as meaning on or off. The motors which control the wheels of the buggy can each, separately, be made to move forwards or backwards or to stop moving, just by setting the value of the right edge connector pins to the appropriate values.

For more information on the Kitronik Motor Driver Board, download the Datasheet here.

Pins all have a pin number which acts as an identifier so that we can indicate in our code, which pin’s value it is that we want to change. To control the buggy, we use pins 0, 8, 12 and 16. The table below shows how each are used and the effect that they have in different combinations.

OFF OFF OFF OFF The buggy is stationary
OFF OFF ON ON Buggy drives forwards in a straight line
ON ON OFF OFF Buggy drives backwards in a straight line
OFF OFF ON OFF Buggy turns left in the forwards direction
OFF OFF OFF ON Buggy turns right in the forwards direction
OFF ON OFF OFF Buggy turns left in the backwards direction
ON OFF OFF OFF Buggy turns right in the backwards direction


The Microsoft MakeCode Editor:

To write the code which responds to Bluetooth events sent from the smartphone application and controls the motors which drive the buggy’s wheels, we’ll use Microsoft’s MakeCode code editor. You only need a web browser to use this tool and can access it at

MakeCode is similar to the old Blocks editors but has a few more tricks up its sleeve, especially where Bluetooth is concerned. It provides a series of function blocks, organised into collections called ‘packages’. For example, there’s a Logic package, a Loops package and a Bluetooth package.

PXT Editor block-menu-139

Go to the MakeCode editor now. Click on and delete any blocks that get created automatically for you. The Bluetooth package is not available by default. So your first job is to add it. Click on More/Add Package and select microbit-bluetooth. You’ll get a message indicating that you cannot have both the Bluetooth package and the Radio package. Opt to delete the Radio package.

It’s usual to begin by displaying a friendly and informative message on your micro:bit. From within the Basic package, click on the ‘show string’ block. Change its value to ‘Robot Wars’.
When a smartphone application uses Bluetooth to exchange data with a micro:bit, it must first connect to the micro:bit. We need to reset variables relating to the buggy control pins when a new connection is established and (importantly!) we need to stop the buggy if the smartphone disconnects. This could happen if the smartphone and micro:bit were very far away from each other or if you were to exit the micro:bit Blue game controller application. If we didn’t take this action, your buggy would continue to move and you would not be able to control it!

Coding With MakeCode:

So, we make use of the ‘on bluetooth connected’ and ‘on bluetooth disconnected’ blocks from within the Bluetooth package. When a bluetooth connection is established by the smartphone, we also initialise a variable called ‘drive’ which we’ll use to keep track of whether or not the buggy is moving (0 = not moving) and if so, whether it’s going forwards (drive = 1) or backwards (drive = 2).

When micro:bit Blue disconnects from the micro:bit, as you can see below, we write a value of zero to all the buggy control pins so that if it is moving, it stops. We’ll also display “C” when connected to and “D” when the smartphone disconnects.

PXT Editor -bluetooth-connected-332

To indicate that we want to receive events from the smartphone application and create a place to put blocks which will respond to those events and set the pins that control our buggy, we use the ‘on event’ block which is in the Control package. Events have two parts to them; an ID which represents the overall type of event (think of events as having a family – the ID tells us which family of events we’re interested in) and a value, which is any number from 1 upwards. 0 is a special value which means ‘any’. MakeCode has lists of predefined event IDs and values we can use and we can create our own as well.

PXT Editor -on-event-block-500

An event ID of MES_DPAD_CONTROLLER_ID is the ID that all events sent by the micro:bit Blue game controller application will have. We’ve indicated through the special event value of MICROBIT_EVT_ANY that we want to handle all values of this family of events. There are 8 touch-enabled buttons in the game controller, 4 in the left-hand pad and 4 in the right-hand pad.

PXT Editor -dpad-870

In fact, we only use two buttons from each pad. We use the left and right buttons on the left-hand pad for steering and the up and down buttons on the right-hand pad for driving forwards or backwards.

MakeCode has ready-made event value variables for our buttons and in fact has different event values for indicating that a button has been pressed (DOWN) or indicating that we’ve stopped touching a button we were previously pressing (UP).

The event values we need to use are as follows:

MES_DPAD_BUTTON_1_DOWN = right hand pad, top button, pressed
MES_DPAD_BUTTON_1_UP = right hand pad, top button, unpressed
MES_DPAD_BUTTON_2_DOWN = right hand pad, bottom button, pressed
MES_DPAD_BUTTON_2_UP = right hand pad, bottom button, unpressed
MES_DPAD_BUTTON_C_DOWN = left hand pad, left button, pressed
MES_DPAD_BUTTON_C_UP = left hand pad, left button, unpressed
MES_DPAD_BUTTON_D_DOWN = left hand pad, right button, pressed
MES_DPAD_BUTTON_D_UP = left hand pad, right button, unpressed


Now all we have to do is add code blocks which check the type of event which has been received (in other words which buttons have been pressed on the micro:bit Blue smartphone application screen) and decide what values each buggy control pin should have to make the buggy drive in the direction that is intended. We also check and if necessary, update, the ‘drive’ variable which tells us which direction the buggy is driving in.
This is all done in two big ‘if blocks’. Let’s look at each of them in turn.

PXT Editor -expanded-on-event-block-870

As you can see, our ‘if blocks’ are placed inside an ‘on event’ block because we only want to do this processing when we receive an event over Bluetooth. This first ‘If block’ tests for event value MES_DPAD_BUTTON_1_DOWN and in plain English says:

“If the smartphone user has pressed the top button on the right-hand game pad then set pin variables 12 and 16 to 1 so that the buggy moves forwards when we write to the actual pins and set the drive variable to 1 meaning ‘we’re driving forwards’”.

If the user has not pressed the top button on the right, we have another ‘if block’ which then tests for event value MES_DPAD_BUTTON_2_DOWN. This code means:

“if the smartphone user has pressed the bottom button on the right-hand game pad then set pin variables 0 and 8 to 1 so that the buggy moves backwards when we write to the actual pins and set the drive variable to 2 meaning ‘we’re driving backwards’”.

We have one final condition in this large ‘if block’ which we test if the others are not true. This time we ask whether either of the top or bottom buttons on the right-hand pad have been ‘unpressed’ i.e. they were being pressed but the user lifted their finger off them. If this is the case, we set all of our pin variables and the ‘drive’ variable to zero because we want the buggy to stop.

We then have another big ‘if block’ which decides what direction the buggy should travel in if it is moving at all because the user has pressed one of the two buttons on the right hand pad. So this block is concerned with checking which buttons on the left-hand pad are pressed and making some decisions about pin values there.

PXT Editor -set-pins-870

The first ‘if block’ which checks for the ‘drive’ variable having a value greater than 0 means ‘is the buggy moving’. Everything else in this ‘if block’ only applies if the buggy is moving, either forwards or backwards.

The next two ‘if blocks’ which check for event values of MES_DPAD_BUTTON_C_DOWN or MES_DPAD_BUTTON_D_DOWN mean ‘has the user pressed left or right on the left-hand gamepad?’.

In each case, the code has further ‘if blocks’ which then check the direction of travel, with ‘drive = 1’ meaning the buggy is going forwards (otherwise it’s going backwards) and then set pin variables so that one of the buggy’s wheels will keep turning and the other will stop so that the buggy turns left or right and in the appropriate forward or backward direction. It is important to note that for the buggy to turn, using the code we produced, the buggy has to either be moving forwards or backwards. If the buggy is stationary the right and left button press will have no effect.

Our final ‘if block’ tests for either of the two buttons on the left-hand game pad being unpressed in which case it sets pins so that the buggy stops turning and drives in a straight line, either forwards or backwards, depending on the value of our ‘drive’ variable.

So, we’ve handled an event which arrived at the micro:bit over Bluetooth and set some variables for each of the pins which control our buggy. But we haven’t yet changed the pins themselves. So our last job is to do just that:

PXT Editor -digital-write-500


Get The Code:

  • You can download the code for the microbit buggy here.
  • Alternatively, you can also grab the code from Bitty Software here.

You can also view and download the code from the embedded editor below, note that it currently doesn't scale well on a mobile phone, please view on a larger screen.


Build A Robot Wars Buggy Learning Resources.
Part 1 - Intro. What we did, why we did it and what we used.
Part 2 - The Buggy. It's all about the line following buggy, We used the buggy as is and attached custom parts.
Part 3 - The Perspex Top Plate. How we designed and cut the top plate, with alternative methods for those without laser cutters.
Part 4 - The 3D printed Add-ons. How we designed and 3D printed the add-ons, with alternative methods for those without 3D printers.
Part 5 - Making The Flag. Our design process for making the self righting flag.
Part 6 - Coding with the Microsoft MakeCode Editor. Beyond line following. Martin Woolley gives a very thorough breakdown of how he wrote the code for the Robot Buggies. Learn how!
Part 7 - Bluetooth Buggy Control. How to turn your Android device into a remote control for the buggy, including pairing instructions, Again, over to Martin Wooley.


Same Day Dispatch
← Previous Post Next Post →

5 thoughts on “Robot Buggy Part 6 Coding With The MakeCode Editor”

  • Fred Fisher March 14, 2017 at 11:50 am

    This is great but could do with an update the PXT editor has now moves and is part of the BBC microbit site and the completed code is no longer available (well I couldn't find it anyway..)

    • Mark Donnison March 14, 2017 at 3:37 pm

      Hi Fred, we've raised a ticket with the microbit foundation to see where the code has gone. We will update it as soon as we know.

      • Mark Donnison March 15, 2017 at 3:10 pm

        Hi Fred, The original code is currently not available due to changes to the PXT editor that it was created in So, we've recreated the code as a download and we've updated the links in the above document.

  • Sean A Guy March 24, 2017 at 12:02 am

    I was wondering how you would be able to code the buggy so that when rotating, one motor will move in the opposite direction to the other one therefore allowing it to rotate in a circle.

    • Mark Donnison April 3, 2017 at 2:44 pm

      Hi, on the page above there is a table that shows which pins need to be on or off to achieve travel in any direction. It shows that by turning on Pins 12 and 16 both motors will propel the buggy forwards and turning on just pins 0 and 8 will make the buggy travel backwards. The turns are executed in the code by turning just one wheel, either backwards or forwards to achieve a turn. If you look through the code in the PXT editor and use the table as you do so you will spot that the code matches the table and you should be able to see how to make the wheels turn in opposition.

      Pins 12 (forward) and 8 (backward) are one motor and pins 16 (forward) and 0 (backward) are the other motor.

      I hope this helps.

Leave a Reply