EPROM: Extended Projects for Robotics On Micro:bits Adrian Oldknow adrian@ccite.org March 2018

Section 5: Making smarter robots

If you do a Google image search on “floor model robot vehicles” you will

see many weird and wonderful designs. Many of them look slightly

humanoid because they have something that looks like a pair of eyes on

the front. The model on the right has a kind of `head’ sticking up which

is the mount for a standard kind of sensor which can measure the

distance to the nearest object in its line of `sight’. It is an ultrasound

transmitter and receiver. The `eye’ on the right sends out a high-

frequency pulse which is reflected from the nearest object and received

by the `eye’ on the left. The time between sending and receiving is used

to measure the distance the pulse travelled, and hence we know how far

away the object is e.g. in cm. The electronic component shown is called

an HC-SR04 and can be bought quite cheaply for c£2.

So we’ll start with finding out how to make this device

work with the micro:bit. Like many other electronic

components, it requires a greater voltage than the

3.3V produced by the micro:bit – in this case it is

designed to work with 5V. I found a helpful article

about using the HC-SR04 with a micro:bit here. The

Chinese MakerHawk company have developed a range

of clever devices such as the Octopus:Bit shown which

costs £13. At the bottom right is a switch which sets

the board to run at 3.3V or 5V. The I2C connector at

the bottom left can take a very small high-resolution

screen called an OLED which can display text and data

without scrolling. I also found that the Robot Shop sells a

large number of modules designed to work with the

Octopus. One of these is the OLED module at £8. It is

plugged in to the I2C connector and is displaying `Ready’ in

blue. The 4 pins on the HC-SR04 are attached to the

breadboard and connected to the Octopus. The red cable

connects the VCC pins, the black one connects the GND

pins, the green one connects Trig to pin P14 and the mauve

one connects Echo to pin P15. Of course we can use a much less sophisticated but cheaper

approach using e.g. the Monk Makes Relay Board and an external 4.5V battery box – which we’ll

look at later. But the programming principle will be just the same. To use HC-SR04 we will need to

add a package called `sonar` which has the block to set up the `trig’ and `echo’ pins. To use the

OLED display we need to add a package called `OLED’.

The simple program above has three blocks. `On start’ sets up the

OLED display and also writes a value to the serial port using a `serial

write’ block from the `Advanced’, `Serial’ menu. This has the effect of

setting up the latest versions of MakeCode to connect with the

micro:bit through the USB serial cable to receive incoming data. The

`On button A’ block will then repeatedly sense and transmit distance

data in centimetres until button B is pressed. The data is also

displayed (in very small digits) on the OLED display module. The `On

button B’ block stops the data collection by setting the variable `OK’ to

false. In order to see the data graphed in real-time, you will need to

install the MakeCode Windows 10 App, or use the beta version of the

MakeCode browser. Then, when the first bit of serial data is received

by MakeCode it displays the `Show data Device’ option. In the

following experiment I have set up the HC-SR504 ultrasound distance sensor below a heavy

wooden model elephant suspended from in a doorway from a long metal spring. As the elephant,

Ellie, swings up and down so the distance data in cm from the sensor to its underside is captured,

displayed on the OLDE, send down the serial cable, stored by MakeCode and graphed.

When the `pause’ button above the top right edge of the MakeCode graph is pressed you have the

option to use the blue button next to it to download the data to your PC as a comma-separated

variable CSV file. Once this is saved it automatically opens in Excel. Now you can select which block

of the data to use, and copy and paste it e.g. to the cell D1. In order to reset the `clock’ to zero you

can insert an additional column between D and F, and enter the formula for E1 = D1 - $D$1. Now

you can copy this down the E column, and then select the block of columns E and F to insert a

scatter graph as shown. From this you can easily find the mean height, frequency and amplitude of

the oscillations.

Now we have got the HC-SR04 range-finder working OK we

can use it sense how close it is to another object. So we

could use that to control a robot to stop, turn or reverse if

we get too close to an obstruction. To bring the ideas

together now we will build an autonomous vehicle, like a

Mars rover, which will also send data back wirelessly to

mission control!

You can buy ready-to-make kits or design your own.

A few years ago I built my first `calculator-based Mars explorer’

CBME, using some old Meccano bits and pieces to make the

chassis. The `smart’ bits are a TI83 programmable graphical

calculator, sitting on top of a Texas Instruments Calculator Based

Laboratory CBL and beside a TI Calculator Based Ranger CBR. One

of the CBL’s inputs is connected to a light sensor (middle of the

image), and the outputs are connected to a red LED, a buzzer and

a relay to switch the motor. The electronics cost around £400! So

I put them in a box and just left the Meccano chassis which is

powered by a single 6V electric motor driving a pair of wheels on a

fixed axle through a gear chain.

A switchable 6V power pack, costing about £1, is

attached to the chassis with Velcro and connected to

the red 5V and black GND power pins on the Kitronik

Motor Driver V2. The Driver board is also attached

with Velcro and connected to the Meccano motor’s

wires via the P12 and P8 pins for Motor 1. We now

just need to insert a BBC micro:bit into the edge-

connector on the Motor board with the LEDs facing

forward.

In order to build the code for the motor driver we

need to `Add Package’ in MakeCode, and search

for `Kitronik’. The `Kitronik-motor-driver’

packages just adds controls to run one or other of

two motors forward or back at various speeds, or

stop.

Here is a simple test program which just runs the robot buggy forward and back four times a few

seconds after button A is pressed:

With a more sophisticated buggy with a pair of motors or 360° servos we can steer left or right as

well as forward and back. Now we can use sensors and outputs to make the buggy more

sophisticated. The first example detects a bump using the accelerometers. The micro:bit measures

acceleration in each of three directions. With the micro:bit held vertically in the edge connector,

the acceleration in the direction of travel is measured by the z-accelerometer. While the buggy is

travelling with a steady speed

this value should be around zero,

but this will fluctuate if the

surface is bumpy or the motor is

not running perfectly smoothly.

But when the buggy bumps into

something this will change by

quite a lot. The units of

measurement are in thousandths

of the value of the acceleration

due to gravity. The acceleration

due to a knock or crash depends

on how fast the vehicle is

travelling. In this experiment I

guess that it will be greater than

0.9g. So the program will detect changes in the z-acceleration greater than 900 units.

The variable called `bump’ has the value `true’ or `false’. While the acceleration is not changing by

more than 900 units, the value of `bump’ stays `false’. Once a bigger change is detected, the value

of `bump’ becomes `true’ and we can take appropriate action. In this case we’ll just stop dead!

The variables `z’ and `nz’ hold the sensed accelerations at the beginning and end of a 200

millisecond gap, and `b’ holds their difference. If there is no bump, then we keep on moving

forward and store `nz’ into `z’ ready for the next interval. If `b’ is greater than 900, then we change

`bump’ to `true’ which will end the `while’ loop, and move execution to the next statement, which

is just `turn off motor’.

Once you have checked this out, you can make the end of the program more elaborate, such as

waiting a bit, then backing off for a short distance, and maybe flashing some LEDs, or sounding a

buzzer. In order to simulate a Mars rover you could change the start of the program. Instead of

manually pushing button A, you could detect the light levels and only start when there is enough

light. Of course with a pair of motors you could not just back off, but could then change direction a

bit and head off forward again, at least until you bumped into something else.

We can be a bit more sophisticated by using a range-

finder to detect the presence of something in the

buggy’s path rather than crashing into it! For this

experiment I am going to use the ready-to-build

Robo:Bit Mk2 kit from 4Tronix. Including the range-

finder this costs £28. The instructions for building and

programming are on the 4Tronix blog. Using a `New’

project in MakeCode you can use `Add Package’ to

insert the additional commands from this link:

https://github.com/4tronix/Robobit

Two of these are not

relevant, at least yet. We

won’t need line-following

sensors for our

autonomous vehicle and

we haven’t added a claw.

Later we will see how to

make such vehicles carry

out remote handling as

well using servos, but not

until the next section. The

Neopixel package has also

been installed

automatically so you can

add arrays of neopixels if you like.

We saw earlier that in order to use the HC-SR504

ultrasound distance sensor we could use `Add

Package’ and install the `sonar’ package to use

the `ping’ command to read data from the sensor.

With the 4Tronix Mk2 kit the `trig’ and `echo’ pins

are both set to P13. So here is a simple program

to test that we can read data from the buggy’s

distance sensor. Because the sensor needs at

least 5V, it will only work when the `On’ switch is

used to power up the board with the motor

drivers and other inputs and outputs. The

program collects distance readings in cm from the

range-finder and writes values both to the

micro:bit’s LED display and, via the

serial cable’ to the MakeCode

editor. We could use the 4Tronix

`read sonar’ command in place of

the `ping’ command.

So we are now set up to take the first steps in building a Mars explorer using the ultra-sonic range-

finder. Here is the basic structure. The main body of the program is in the `on button A’ loop. It

uses two Functions. `GetReady’ does just that before setting the buggy in motion. The logical

variable `clear’ has the value `true’ unless the range-finder detects an object in its path between 5

and 10 cm away. The main program is just the one `while clear’ loop which keeps updating `clear’.

When `clear’ becomes false, the loop is terminated and we call the `Avoidance’ function.

Here `Avoidance’ just consists of stopping the motors for a second, then running backwards for 0.5

seconds before stopping altogether. Now this basic program works, you can extend the project in

several ways.

`GetReady’ could include a loop to read the value of the light intensity from either the micro:bit’s

own light sensors or from a light dependent resistor LDR attached to one of the available pins. The

4Tronix Mk2 board has pins for GND, +3V, +5V, P2, P13, P14, P15, P16 – but P13 is already in use for

the ultra-sound range-finder. So you Velcro a small breadboard to the battery box and connect an

LDR to the GND and P2 pins say. Then you could include a loop to wait until the light intensity gets

bigger than a certain threshold level. As well as using `drive at speed’ to start the motors you could

also include some LED and/or sound outputs to make an all singing all flashing buggy. Again you

attach coloured LEDs or a neo-pixel strip to your breadboard as well as a buzzer.

The `Avoidance’ function could also use some lights and/or sounds. You could also make the buggy

turn a bit and carry on. In this case you would need to delete the `set clear to false’ command and

replace it by moving the `Call function Avoidance’ command into its place in the `If’ command.

You would now need to think of some alternative way to bring the day’s mission to an end before

the batteries ran out. You could just use an `on button B’ command to switch the system off. Using

buttons A and B manually are fine while testing manually on Earth, or for a manned mission to the

Moon, but not yet appropriate for Mars!

So now we could start to think about using the micro:bit to communicate with mission control! The

4Tronix blog has ideas about using another micro:bit for remote control, which you could

experiment with wirelessly. We could also transmit data from sensors on the buggy wirelessly to

that micro:bit. If that was also attached to a Windows 10 computer running the MakeCode App,

then we could graph the data in real time as well as store it in a csv file for analysis in Excel or

GeoGebra. This brings us firmly into the realm of what is called `telemetry’ such as used by the F1

racing car teams when monitoring Grand Prix races.

If you feel like making your own buggy there are lots of

interesting ideas for projects on the internet. The lunch-box-

buggy is one of the more robust ones!

In the final section we will develop some ideas for these and

other projects including remote handling of dangerous

substances!