My programming story… so far

Early days

When I was 12, I was given a Raspberry Pi. For the first couple of days, it was really fun. After I had browsed the web for a while and played a bit of Minecraft, it sat in it’s box for a few months. I really had no idea what to do with it. That was until I discovered that I could build a website with it.

Continue reading


Dockering with cardboard

Although the PiGlow visualisation of CPU usage was pretty, we reckoned we could go a couple of steps further and integrate a much more complete tangible solution – a hardware-driven load monitor dashboard.

Made of cardboard.

This was to be driven by two high torque servos (Ben had them lying around) which would rotate according to whichever performance indicator we chose. Servos are not, of course, very good pointers so with a trusty craft knife to the fore we re-purposed some Pi packaging into a cardboard user interface.

Continue reading

Visualising Docker on Pi with PiGlow

In my last post I described how I set up a 5-strong Raspberry Pi Docker swarm. It wasn’t long before I realised I wanted some ambient way to see how they were performing which a) didn’t involve staring at a screen and b) would wind up the cat.

Luckily my friend Ben was round and he’s quite into tangible stuff so after rummaging in a few dusty boxes for inspiration we found a PiGlow and wondered if that would do the trick.

Continue reading

The Pi-Powered Hamster Hunter Part 4: Reflections


At the end of our project our initial objectives had now been added to and matured through the development process.

Objectives at the start

The objective of this project was to build an all terrain vehicle which could be used for various applications and controlled from anywhere in the world. We wanted it to be operational in all circumstances, which meant being able to operate in low light/pitch dark conditions and being able to traverse all terrain. It was essential for the user to be able to see from the ReCoRVVA’s point of view in real time. We also wanted the ReCoRVVA to be able to sense when it was about to crash and automatically stop to avoid collisions.

Objectives at the end

The ReCoRVVA is controllable from anywhere in the world, the user can see in real time where they were driving and knows the environmental conditions they were operating in. The ReCoRVVA is able to automatically stop if it senses an obstacle.

We have also shown that it can be adaptable to any circumstance and any user or their medium of control.

Continue reading

The Pi-Powered Hamster Hunter Part 3: Putting it all together

Assembling the components

The final model

The first prototypes we put together used an Arduino, and it was with these first prototypes that we had many problems with the motors.

The first thing we tried was to run each motor from one of the Arduino’s digital pins. They were 5v motors, and the digital pins on the Arduino supplied 5v each, so we assumed the motors would run. We wrote then uploaded a simple drive script to the Arduino.

However, the motors didn’t turn. We debugged the code and found no errors, we checked the pins were supplying voltage and yet the motors still didn’t turn. Eventually, we realised that there was a limit on the amount of current able to be drawn from each digital pin on the Arduino, and that we were exceeding this limit. The motors ran from the Arduino high current 5v supply perfectly, but there was only one of these constant 5v pins. We initially considered using transistors or relays to control each motor individually, and built this circuit with transistors, which worked well. Then we realised that this only allowed the motors to go forwards, and if it got stuck in a corner it wouldn’t be able to get out unless the motors turned backwards. This was solved by using a dedicated motor driver to control the motors.

While we assembled the ReCoRVVA, we tested it as we went, mainly using the Ardumote app (see controllers/user interfaces section). We had problems with nearly everything including:

  1. Power – current draw was too high. Adding on more battery packs solved this.
  2. Jittery servos – this made the camera judder. This was fixed by using a hardware PWM library on the Pi to send control pulses more accurately to the servos.
  3. Weight balance problems – the additional battery packs caused the vehicle to become unstable so we had to re-arrange them to make sure the vehicle didn’t tip over.

Although these kinds of problems seemed difficult to overcome at the time, we learned immensely from them in the long term.

Continue reading