EPROM: Extended Projects for Robotics On Micro:bits Adrian Oldknow [email protected] 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!