Recently I have been involved with a research project into how Virtual Reality devices, namely the Meta Quest 2, can be used to assess how well users perform within a ward based environment.

The user is presented with a virtual world and are assessed on how well they deal...or not deal...with various issues presented within the environment.

The project has regularly been demonstrated to stakeholders and other research groups and until recently this was achieved using existing equipment along with third party software SideQuest mirror what the user can see onto an external monitor. However shifting priorities meant that this equipment became temporarily unavailable.

Whilst SideQuest was suitable within our lab environment it would not be suitable for general use outside of the lab environment. It could potentially run on staff laptops and learner computers but this would mean another layer of administration being added to what was needed as it would then become another package that would need to be managed by our support unit and be outside of our control.

This presented a good opportunity to find a solution to the problem that could remain in house and be span up as needed...but also be one we could control.

At a basic level the Quest 2 headset can be thought of as an android phone with a fancy built in screen. Having used a tool called scrcpy in the past to repurpose old Android devices as cameras I wondered if this could be a potential solution.

Scrcpy's repository shows that the tool is cross-platform and supports Windows. However it would be unlikely that we could get this installed on our staff laptops due to policy restrictions.  What we did have though was one or two Raspberry Pi kicking around.

According to the repository scrcpy is currently at version 2.0 but the version available in Pi's repository was 1.17 so there was a requirement to compile the latest version. A set of instructions was found here and updated to use the version 2.0 of the scrcpy-server as shown below:

sudo apt -y install git wget meson libavformat-dev libsdl2-dev adb

git clone https://github.com/Genymobile/scrcpy.git
cd scrcpy

wget https://github.com/Genymobile/scrcpy/releases/download/v2.0/scrcpy-server-v2.0

meson x --buildtype release --strip -Db_lto=true -Dprebuilt_server=scrcpy-server-v2.0ninja -Cx

sudo ninja -Cx install

This builds two packages, both of which need to be placed into /usr/bin

Once ready this was, optimistically, tested on an Pi Zero with the expected results of the Zero becoming overloaded and very laggy.

It was then tested with a 3B+ and whilst still laggy it was usable but showing the contents of each eye lens in a separate window. After a bit of searching a solution was found here:

scrcpy --crop 1730:974:1934:450 --max-fps 15

With the --max-fps set to 15 performance became a lot better in use although there can be a slight delay of a second or two between what the user is seeing and what is displayed.

Also, as the ADB tools are installed, it's possible to install a APK directly from the Pi onto the headset providing that developer mode is enabled. The headset will also need to be connected to a ADB server...try doing it with scrcpy running.

adb install -r <path to .apk>

Info about the Project:

https://www.ncfe.org.uk/help-shape-the-future-of-learning-and-assessment/aif-pilots/calderdale-college/

https://www.calderdale.ac.uk/calderdale-college-first-to-deliver-virtual-reality-social-care-curriculum/

https://twitter.com/CalderdaleCol/status/1600134106297139200

https://twitter.com/CalderdaleCol/status/1643272446345203713/photo/3

Earlier I posted about FreeCad and how Jo Hincliffe (@c0ncreted0g) had started a series of how-to guides on using the package.

These guides have been thrown together and published by Hackspace Magazine!

Grab yourself a copy for free here

Before the end of the summer term in 2020 an introductory microcontroller session was ran using tinkercad to simulate basic electronics with a micro:bit. As this sparked an interest in the students I decided to enter a college team into to 2021 PiWars competition.

As we had two groups within the 2nd year group, the initial idea was to build two robots and have each group battle for the right to represent the college at PiWars and also to put into practice the skills they were learning on the course.

As the students were, generally, inexperienced in hardware building and having to fit the project work in around normal coursework each group would start with identical base hardware to allow them to concentrate on the software aspects and any adaptations required for the challenge.

After being accepted for the competition we were faced, unfortunately, with another period of covid lockdown causing disruption to teaching and the project was temporarily suspended although the search for a suitable hardware base for the robots continued.

Back in issue 32 of Hackspace Magazine a robot design was featured in the magazine. This design, name MTV Bot, created by Jo Hinchcliffe (@concreted0g) and with the rough price guide of around £25 for some parts and some 3D printing it looked like it would be ideal for the project.

The first bot was built during October. The chassis came as a kit requiring some assembly. First thing was to solder the power wires to the motors before mounting them to the chassis. As it was not actually specified in the original article, it was was found that 16AWG wire was both pliable enough to route through the holes in the body and, more importantly, the correct diameter size to fit snugly into the terminals on the L298N motor controller.

Once all this was done fitting the tracks to the motor drive wheel and spindles was next. This is best done with a sense of humour as it is a bit of a fiddly job and it was found that the tracks, on our chassis kits, were 2 or three links too long. Shorting the tracks requires driving out a track pin or two and then reconnecting at the correct length. This is explained in detail within Jo's article.

The bottom printed body part was then mounted onto the chassis using the M4 bars and nuts. Once secured the top layer was mounted onto the bars using nuts to form a support and the L298N mount was connected. Using spring washers helped here as they stopped the nuts from vibrating loose when the bot was in use.

At this point the bot was ready for testing. After a visual and multimeter check on the wiring for any shorts a Raspberry Pi was connected up. At this point the Pi was powered from a separate USB battery whilst the motor controller was supplied direct from the LiPO battery. Each motor was tested for function both as a pair and independently.

Eventually our 1st year group took up the mantle from the 2nd year groups and started to experiment with the bot. One thing that was quickly realised was that the extra battery for the Pi was starting to interfere with robot operations. Removing this extra battery and powering the Pi from the same supply as the motors would be a better overall solution and also that it would probably be a good idea to be able to isolate the motors.

Robot Party!#piwars pic.twitter.com/B8tsekefqD

— heeed (@heeedt) May 29, 2021

A potential solution to this was found on Dr Footleg's (@drfootleg) Mars Rover robot design. Here he had powered the entire system from a single LiPo battery with this design. The supply from the LiPo was split into two paths, one to supply the motor controller and the other to power the electronics via a UBEC module to drop the supplied voltage to a 5v supply. After testing to check everything still worked a switch was fitted on the wire connecting the LiPo to the motor supply input on the L298N.

After these modifications had been successfully implemented, further development was handed over to the students to solve the PiWars challenges. One of the first tasks they figured out quickly was to bring the bot under control via a console style controller.

Ultimately the team came 5th out of a beginners class containing 15 teams and also came first in 'Up the garden path' challenge by controlling the bot by with voice control.

With the school summer holidays on the horizon, the idea of a robot building workshop was pitched to Kirklees Libraries who showed interest. A few potential ideas/designs were discussed and the one that seemed to fit all the correct holes was the PounderBot.

The Pounderbot was a design created by a chap that you may (or may not) be aware of called @biglesp.
He set himself, as part of his Friday Fun sessions, a challenge of building a simple robot vehicle for under £10 pounds.

His design priced at £9.88 was under his £10 goal and produced a simple, easy to build robot.

Now with a design, and more importantly a shopping lists of parts, planning could begin for the sessions.

Building a test rig

At this point a few substitutions were made to the original parts list and the parts ordered.

These changes were the use of a pre-cut chassis kit and the motor/wheels changed from the micro-gear type motors to the big chunky yellow motors with big yellow wheels. The parts arrived in due course and a test build commenced.

Power it up for the first time

Once built the power switch was turned on and.....nothing happened. Power was turned back of and on again with almost the same result but for about 5 seconds the right wheel would spin of it's own accord.

The other wheel would then spin after a few seconds with the robot sometimes following it's test program or appearing to reset and start spinning its single wheel again.

This was a bit concerning as the robot would get very dizzy if all it could do was spin in a circle.

Les had already identified this issue and, with the help of Gareth from 4tronix, had diagnosed and fixed it by adding resistors between the motor controller and motors to reduce the current being used by the motors. This prevented stress on the current supply from the batteries which would cause the digispark attiny85 to reset making the individual motor spin which would cause the current to drop causing the attiny85 to reset....

Checking the robot I realised that I'd forgotten these resistors during the parts order and, as usually is the case, I had none in my component box.

Finding the fix

Probing around I noticed Pin 3 was high on boot even though the code had set it to low. This was causing the motor to spin with the resulting issues.

Digging further online I discovered the attiny85 has a five second delay when powered on to check if anything is trying to re-flashing the board. As Pin 3 doubles as one of the USB pins this appeared to be cause of the motor issue.

Looking at the Pounderbot design I wondered what would happen if I swapped the IR sensor input on Pin 4 to use Pin 3, then placing the evicted motor controller wire from Pin 3 to Pin 4 and updating the code to make sure the right signals made it to the right pins.

On power up, nothing appeared to happening for the first five seconds but then the robot happily trundled off under it's own steam. The robot was recaptured and the power recycled with the same result.

It appears that swapping the wires not only removed the requirement for the resistors but also prevented the wheel spinning...no more dizzy robots.

The Workshops

Now that the robot appeared to be working as intended a simple worksheet was created to allow a step by step build.

Each workshop catered for ten participants at various libraries in Kirklees. Due to some crossed wires we had some participants as young as eight attend.

During each session each participant got to experience soldering, with many enjoying being trusted with a soldering iron, under supervision and using the various handtools. Everyone left with the same amount of body parts as they came in with...probably due to the safety talk at the beginning being at a level children could understand.

As expected, some robots failed to work properly at the beginning but were quickly fixed. This was down to simple things as wires being placed in the wrong place or screws not tightened fully.

Hopefully these workshops have inspired future robot engineers :)

Further info

The files used for these workshops can be found here: Library Robot

Now we all know that the micro:bit can make noise either with makecode or Python but out of the box its quite a quiet little thing.

Luckily you can use some crocodile clips to connect a pair of standard headphones or use the amp:bit but these keep the awesome the music to the user.

However another way would be to make some speakers for use with the micro:bit...so whilst browsing the local poundland I found some of these:

After getting them back to the workshop the back of one of the speakers was removed by unscrewing the three retaining screws:

A quick use of the soldering iron and the cable was disconnected from the speaker and removed from the back cover.

A pair of crocodile clips were then snipped in half and the ends stripped:

These cables were then fed through the hole where the original cable had gone through. The hole needed to be enlarged slighty to allow both cables to comfortably fit through:

After the cables were through a quick bit of soldering connected the new cables to the speaker:

and the speaker case was screwed back together:

This shows that for the cost of £10, some crocodile clips and a bit of time twenty individual speakers can be created to for use in a classroom or CodeClub even.

One of the more interestng parts of the micro:bit is the bluetooth module. With this its possible to, amongst over things, flash the device and also control external bluetooth devices.

However due to various technical reasons this built-in Bluetooth functionality is not available when using micropython. However its possible to sidestep this issue by using an external module. In this project a 'Hello World' message will be sent over the airwaves to a waiting mobile phone.

The HC-0x Bluetooth Modules

These inexpensive modules are availiable from multiple sources. The main types in use in the maker community appear to be the HC-05 and HC-06 types. Both types are identical apart from the following points:

• The HC-05 module can build a connection to other modules. E.g. a Robot being a master and connecting to slave bluetooth module. Or in slave mode to make a wireless bridge to a notebook.

• The HC-06 module only can be a slave. This makes it only useful for say connecting a notebook as a master to a robot with a slave module e.g. for a wireless serial bridge.
  1

Wiring up the device

The HC-06 module is quite happy running on 3.3v that is supplied from the the micro:bit and the message data can be sent via Pin 0 to the Rx pin on the HC-06.

The micropython code

from microbit import *
uart.init(baudrate=9600, bits=8, parity=None, stop=1,tx=pin0)
while True:
 if button_a.was_pressed():
  uart.write('Hello World!') #send hello world
 elif button_b.was_pressed():
  uart.write(bytes([0x0A])) #new line
sleep(100)

Reading the Bluetooth connection

With the code flashed and the micro:bit happily sending the message via Bluetooth a way of reading this output is required. This was achieved using a Bluetooth serial terminal app from the Google Play store.

Once this app was installed and paired with the module, the 'Hello World!' message was displayed when button A on the micro:bit is pressed.

Resources:

Example of HC-06 on Amazon

Bluetooth Serial Monitor on Google Play

HC-06 Datasheet

As normal these things start with receiving an email mentioning that there is this really cool event happening and would you like to take part. The event is question was the Make:Believe event held at Leeds City Museum as part of the Leeds International Festival.

Joining forces with Phil M from the micro:bit educational foundation a plan formed to provide some micro:bit activities. Phil rolled out his awesome micro:bit house to wow the crowds and I deployed the fleet of bit:bots and robo:bits:

To keep it simple a plan was hatched to give the young attendees a chance to drive a robot. This took the form of having the micro:bit in the robot controlled remotely by another micro:bit.

The code from multiwingspans site was tweaked to allow the user to tilt the controller micro:bit in the direction they wanted to move the robot and to stop by pressing the 'a' button.

This worked well in general but got confusing for younger attendees which usually resulted in the bit:bot speeding off in a random direction and requiring to be rescued. The main issue seemed to be pressing the 'a' button to stop the robot and not being able to tell what direction was being sent from the controller.

With this in mind, later that evening, the PXT editor was started back up and the code modified to make driving the bit:bot a bit easier.

This time tilting the controller will display what direction the robot is to go and pressing 'a' will make the robot move in the direction required. To stop the robot, the controlling micro:bit is held flat.

Controller code:

let x = 0
let robotNumber = 0
let y = 0
basic.forever(() => {
    y = input.acceleration(Dimension.Y)
    x = input.acceleration(Dimension.X)
    if (y > 400) {
        basic.showLeds(`
            # # # . .
            # . . # .
            # # # . .
            # . . # .
            # # # . .
            `)
        if (input.buttonIsPressed(Button.A)) {
            radio.sendString("S")
        }
    } else if (y < -200) {
        basic.showLeds(`
            # # # . .
            # . . . .
            # # # . .
            # . . . .
            # . . . .
            `)
        if (input.buttonIsPressed(Button.A)) {
            radio.sendString("N")
        }
    } else if (x > 400) {
        basic.showLeds(`
            # # # . .
            # . . # .
            # # # . .
            # . . # .
            # . . . #
            `)
        if (input.buttonIsPressed(Button.A)) {
            radio.sendString("R")
        }
    } else if (x < -200) {
        basic.showLeds(`
            # . . . .
            # . . . .
            # . . . .
            # . . . .
            # # # # .
            `)
        if (input.buttonIsPressed(Button.A)) {
            radio.sendString("L")
        }
    } else {
        radio.sendString("STOP")
        basic.showNumber(robotNumber)
    }
    basic.pause(40)
})
radio.setGroup(10)
robotNumber = 1
basic.showNumber(robotNumber)

Robot Code

radio.onDataPacketReceived(({receivedString}) => {
    if (receivedString == "N") {
        pins.digitalWritePin(DigitalPin.P0, 1)
        pins.digitalWritePin(DigitalPin.P8, 0)
        pins.digitalWritePin(DigitalPin.P1, 1)
        pins.digitalWritePin(DigitalPin.P12, 0)
    } else if (receivedString == "S") {
        pins.digitalWritePin(DigitalPin.P0, 0)
        pins.digitalWritePin(DigitalPin.P8, 1)
        pins.digitalWritePin(DigitalPin.P1, 0)
        pins.digitalWritePin(DigitalPin.P12, 1)
    } else if (receivedString == "L") {
        pins.digitalWritePin(DigitalPin.P0, 0)
        pins.digitalWritePin(DigitalPin.P8, 0)
        pins.digitalWritePin(DigitalPin.P1, 1)
        pins.digitalWritePin(DigitalPin.P12, 0)
    } else if (receivedString == "R") {
        pins.digitalWritePin(DigitalPin.P0, 1)
        pins.digitalWritePin(DigitalPin.P8, 0)
        pins.digitalWritePin(DigitalPin.P1, 0)
        pins.digitalWritePin(DigitalPin.P12, 0)
    } else if (receivedString == "STOP") {
        pins.digitalWritePin(DigitalPin.P0, 0)
        pins.digitalWritePin(DigitalPin.P8, 0)
        pins.digitalWritePin(DigitalPin.P1, 0)
        pins.digitalWritePin(DigitalPin.P12, 0)
    }
})
radio.setGroup(10)
basic.showNumber(1)

Further info:

Cool micro:bit stuff can be found here
Robots can be found here

Picon Zero is an Intelligent robotics controller for the Raspberry Pi. A built-in processor handles all the direct communication between the parent controller and any attached devices and motors.

Whilst primarily an add on for the Raspberry Pi, due to it using I2C for communications, it is possible to use it with other small board controllers such as the micro:bit.

This guide will show you the basics and give you a foundation from which to develop further skills.

Also, whilst primarily aimed at use with the PiCon Zero, the techniques can also be used with other HATs or devices that are controlled via i2c.

Whats i2c?

I2C is a communication protocol that was created in the eighties by Phillips Semiconductors. It's normally used for short distance communication between peripheral devices and processors.

At a basic level devices communicate over a 2 wire bus. On each bus there will be a master which controls the other slave devices. Every device on the bus, apart from the master, will have a unique address. These addresses allow the master to talk to individual devices and to instruct them to carry out any functions.

A more detailed explanation can be found here: https://learn.sparkfun.com/tutorials/i2c

Connections

As the micro:bit edge connector and the HAT standard are physically incompatible, third party expansion boards are required. Examples of which are as follows:

• Kitronix micro:bit edge breakout connecting to either a Pimoroni black hat hack3r board or via the HAT mounted on a breadboard.

• 4tronix bit:2:pi

Setup

Once everything is connected and the micro:bit is connected to your laptop via USB then start Mu.

As we will be using REPL, the first thing we will need to do is flash an empty project onto the micro:bit. This will set up an environment that will allow the 'real time' entry of code to the micro:bit.

First steps...

The first thing that needs to be done is to find the i2c address of the PiCon Zero. The documentation shows that this address is 0x22.

With this we can now talk to the the PiCon Zero and request it to provide its Board and Software revision numbers. This information is kept in register 0, which is a read only register.

For this value to be read we first need to write the address of the register 0, 0x00 to the Picon Zero. This will instruct the PiCon Zero to read the contents of register 0 and make them ready for reading. The next command is to read the values from the device.

This can be seen when entering the following code:

from microbit import *
i2c.write(0x22,bytearray([0x00]))
output=i2c.read(0x22,2)
print(output)

This should result in the following being displayed:

b'\x02\x08'

The display should now look similar to the following:

>>> from microbit import *
>>> i2c.write(0x22,bytearray([0x00]))
>>> output=i2c.read(0x22,2)
>>> print(output)
b'\x02\x08'

i2c.write() is the method that writes data onto the i2c bus. It takes three arguments: the address of the target device on the bus, the data that is being sent and if you want to repeat.

i2c.read(), in contrast, reads data from the target device. It also takes three arguments: the address of the target device on the bus, the amount of bytes to be read and if you want to repeat.

As can be seen using devices, on an i2c bus is a case of writing commands and, if required, data and reading the responses generated.

Exploring the registers

The Picon Zero has the following registers availiable:

Read Only Registers

Values for Output Config Registers

Moving a Motor

As can be seen in the write only registers, motorA is controlled by register 0, address 0x00 and motorB controlled by register 1, address 0x01.
Each motor can take a value between -100, for full reverse, to +100 for full forward.

To make a motor move the required speed is wrote to the relevant register. For example the following code will make motorA move:

i2c.write(0x22,bytearray([0x00,80])

and to make it stop:

i2c.write(0x22,bytearray([0x00,0])

To make the opposite motor move substitute 0x00 for 0x01

Moving a Servo

Using a servo is slightly more involved. By default the bank of GVS pins on the board are turned off and will need to be switched to servo mode to use the servo.

Consulting the list of write registers shows that registers 2 through 7 control what mode each row of GVS pins operate under. The registers that follow, 8 through 13, accept the data that, dependent on mode chosen, is sent via the related GVS pin row. With the following example it is assumed that the servo is connected to Output0.

To start with the Output0_Config has the value 2 wrote to it:

i2c.write(0x22,bytearray([0x03,2]))

This setups Output0 as a servo control. At any point the 2 can be replaced by 0 which will turn the output off.

Once the output has been set up, the servo can have values passed to via register 8, Output0_Data, as follows:

i2c.write(0x22,bytearray([0x08,-90]) #servo fully left
i2c.write(0x22,bytearray([0x08,0])   #servo central
i2c.write(0x22,bytearray([0x08,90])  #servo fully right

Reading an input

So far only outputs have been looked at. The PiCon Zero can also be used to read values.

As seen before with using the ouput registers, we first need to configure the the relevant input. The write only registers 14 through 17 are responsible for controlling the configuration of each input.

Once configured correctly, read only registers 1 - 4 will hold the data for reading.

An example of this will be as follows:

#Set Input0_Config to Digital
i2c.write(0x22,bytearray([0x14,0]))

#Start a loop

#write the address of the register to read
i2c.write(0x22,bytearray([0x01]))

#read the selected register
i2c.read(0x22,1))

#increment loop