Robot Buggy Part 6 Coding With The MakeCode Editor

Customer Notice (New Bluetooth App):

We have recently produced a new Google Play Store app called Kitronik Bluetooth Control. This Android app allows you to control a Kitronik Kitronik :MOVE mini buggy over Bluetooth. The new Kitronik Bluetooth Control app replaces our previous Android app that features in this resource. We suggest that you switch to this new app for a better and more consistent experience. See the links below for more details.

• Kitronik Bluetooth Control App - Google Play Store.
• Kitronik Bluetooth Control App - How to Guide.

 

This Resource:

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...

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.

PIN 0	PIN 8	PIN 12	PIN 16	EFFECT
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 https://makecode.microbit.org/. 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.

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:

NOTE:

Due to cosmetic changes to the MakeCode Editor, the screenshots below vary slightly in look to the blocks you will find in the editor. They still function in the same way. There is an embedded editor towards the foot of this page which shows all of the code as it looks currently. To open the code in the online MakeCode Editor, click the Edit icon in the top right.  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.

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.

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.

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.

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.

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:

 

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.

©Kitronik Ltd – You may print this page & link to it, but must not copy the page or part thereof without Kitronik's prior written consent.