PaPiRus ePaper HAT: what about the software?

In my previous post I mentioned that I was still getting the software for PaPiRus installed. Well, success and all is well. Here are a few screenshots of the 2.7” screen. Note as before that this is a pre-production model and I’ve been told that the screen I am using is an earlier version than what will be shipped to backers.

PaPiRus is available for three more days on Kickstarter.




PaPiRus ePaPer HAT hardware preview

Aaron of Pi Supply has very kindly posted me a PaPiRus ePaper HAT preview unit. This is a work in progress and Aaron was open that the software side of things still needs work. Fair enough, I’m happy with that: after all in a pre-production unit one does not expect perfection. I have previously covered the Kickstarter and the advantages of using an ePaper display. Today we will be looking at the hardware.


The unit was supplied pretty much ready to go with the three sizes of display (1.44”, 2.0” and 2.7”) along with a coin battery and v1.4 of the HAT itself. The first thing to note, and I owe Aaron and team a beer for this design decision, is that the ribbon connector between display and board uses a click up, insert, click down affair, as opposed to pull, slot in, push that is used on the Raspberry Pi Camera module. This makes inserting the ribbon cable easier and the connection notably more secure when clicked back into place.

The rest of the HAT is similarly well thought out (there is even a slot in place to allow the camera ribbon cable to pass through). As with all HATs this will be equally in place on a B+, B v2 or A+ Pi. The combination of Raspberry Pi A+, PaPiRus and 2.7” screen all in a tasty case mounted on a wall displaying data of one kind or another is very appealing as this will be a very compact, very energy efficient solution for a multitude of projects. I can even see this combination being used as an in-car display screen connected to a car’s OBD port for the same reasons.

The upper side of PaPiRUS is mostly empty, giving you a flat platform to rest your chosen screen upon. Along the top are four tactile buttons which will make interacting with the Raspberry Pi and PaPiRus straightforward.


On the reverse we find lots of little components, all pre-soldered with precision. This isn’t some DIY rough-and-ready solution, but a professional product. It re-confirms what I’ve known about Pi Supply for a while: this is a professional outfit producing products that us consumers can rely upon.


For those who like technical details I got my magnifying glass out and noted the following (obviously this is all subject to change, this being a pre-production board):

IC1 (directly above the edge-mounted ribbon connector) is flash memory from Winbond, part number W25Q32FV. This gives me a clue that the firmware could be updated in the future as needed.
IC2 (up-left from the battery) is a NXP 8523T which the datasheet tells me is a real-time clock and calendar
IC3 (above IC2) is a NXP LM75BD which is a digital temperature sensor and thermal watchdog
To the left of IC4 (below the battery) we have a B6MY which Google tells me may be a folding pocket knife. I think my Google Ninja skills failed me at this point.

The hole for the reset pin is present on v1.4 of the board (below-left from the battery) and with less than £3k to go at the time of writing we’re sure to unlock this stretch goal.

UPDATED: Most intriguing of all on the v1.4 design is the inclusion of a second ribbon cable connector at CN4 (above battery). Aaron pointed out what I had completely failed to notice: that this is a GPIO breakout (see the last photo on the Kickstarter page).

The board is rock-solid, with no loose chippery to be found anywhere. PaPiRus is on Kickstarter for 5 more days and looks set to be an excellent way to add an ePaper display to your Raspberry Pi.


PaPiRus ePaper HAT Kickstarter

Chatting with Aaron of Pi Supply recently I became aware that he was about to put something live on Kickstarter that is really exciting. I promised to keep quiet until launch day despite constantly wanting to shout “This is AWESOME!” from the roof tops.

Pi Supply are seeking funding for a superb ePaper / eInk HAT on Kickstarter called PaPiRus. It’s an absolutely genius design with four buttons mounted along one edge and up to a 2.7” ePaper display. Why is this “AWESOME” you may ask? Well, ePaper displays only require power when the image is updated. It is this fantastic property that gives the Amazon Kindle such excellent battery life in the “weeks” not “hours” category. Combined with the low power Raspberry Pi and you have something that’s cheap as chips to run. This is even more so with the Raspberry Pi A+. Alex Eames of did an excellent write-up of the respective Pi’s power usage.

Now, ePaper is not going to be for everyone. If you require colour, or fast screen updates in the ms range then a traditional LED/LCD screen will be more to your taste. But for status displays, Twitter feeds and the like, and especially if you need to run off batteries (this HAT will work stacked with Pi Supply’s Pi Juice) you just can’t beat ePaper. Tim Cox once repurposed a Nook eReader as an ePaper display for his Pi, but obviously this requires a fair bit of effort to get working. The beauty of the Raspberry Pi HATs is that they are pretty much plug and play, hence PaPiRus gets a massive thumbs up.

What’s more, PaPiRus is being made by Pi Supply who have a history of creating superb add-ons for the Raspberry Pi (and PiJuice of course) that are delivered as promised. I’ve no qualms at all about entrusting my money to Pi Supply for one of their projects. Pi Supply just hit the £5k fully funded mark with 30 days to go. This is clearly a project you can have confidence in.

Head on over to Kickstarter to back PaPiRus.


Robotics 2: Using the Sharp GP2Y0A41SK0F IR distance sensor with Explorer HAT Pro

The HC-SR04 is a clever component. By measuring the time delay between signals from the included board one can easily calculate the distance to objects. Well, that’s the theory. Unfortunately it turns out that it does not play that well with Explorer HAT Pro board that it is connected to when using the provided explorerhat library. I’ve observed that ranges to perpendicular objects (to give the best result) are miscalculated by up to a metre (plus or minus). This seems to be a timing issue as the HC-SR04 does not return the distance to an object, but instead it sends a connected pin high for the same time as it took for a pulse of ultrasound to bounce back.

Instead, Zumo George has received an upgrade in the form of the Sharp GP2Y0A41SK0F infrared distance sensor. This has the added benefit of making him look more Goliath* and less WALL-E. This is an analog device that runs at 5V which matches perfectly with the Explorer HAT’s analog inputs. It measures distances accurately from 4cm to 30cm which, for the purpose of “don’t crash into an object” is perfect.
Wiring is straightforward with GND and Vcc to their respective 5V pins and the third cable to one of the analog pins (I use pin four). I bought the sensor on eBay for a few quid and the cable it came with did not have 0.1” pins attached at the breadboard end of things. A quick bit of soldering and heat shrinking later and we’re ready to go.

Next I needed to add to my library of tests for Zumo George to ensure that when he boots up all is A-OK. Let’s write a scenario:

Scenario: Verify infrared range finder is responding
  Given the distance to an object is greater than 10 cm
  When I read the infrared range finder
  Then I should see a distance greater than 10 cm

Now we execute this with Lettuce. Note though that I have added a tag with the @ symbol to enable me to run just this scenario while we get it working. Hence we:

sudo lettuce -t ir

We need sudo because Pimoroni’s Explorer HAT Pro requires this, and we use the -t parameter to specify the tag to execute.

Immediately we see that our three steps have not been defined, and Lettuce helpfully returns suggested step definitions that assert False. Copying these into place and re-executing moves us from not implemented to not coded, with the three steps each going red.

At this point we need to implement some code to make everything work as it should. To do this I have decided to create a new Python module, which will contain specific functions required by Zumo George. We are going to need a way of determining distance by using the GP2Y0A41SK0F sensor, hence in I enter the following to create a read_distance() function that we can call from a step definition:

import explorerhat
import time

def read_distance():
  # with help from:
  # and an idea from
  v_readings = []
  # read the voltage 10 times so that we can get a decent average
  for i in range (0,10):

  av_voltage = sum(v_readings)/10.0
  if av_voltage <= 0:
    av_voltage = 0.001
  distance_cm = 13 / av_voltage
  return distance_cm

The GP2Y0A41SK0F works on the principle that distance to an object is inversely proportional to the voltage that can be read from the connection on analog pin four. In other words the higher the voltage the lower the distance, and our equation takes this into account. The number 13 was determined by looking at the datasheet on the Pololu product page. In the graph we can determine for a reading of 1V we should be 13cm away from our object, i.e.: 13/1 = 13cm. I got the idea to do things this way from Yoctopuce who used another Sharp IR sensor. Their magic number was 60 for the GP2Y0A02YK0F which they obtained in the same way.

Into I then add the following three step definitions as well as the import zumo command. The Given sets up the expected result, the When is the event (i.e.: read the distance) and the Then is the comparison. I will be honest and say that in Python I don’t know if using global variables in this way is a good thing or not (note to self: must research this), but it works, so at this stage I am not too concerned:

@step(u'the distance to an object is greater than (.*?) cm')
def the_distance_to_an_object_is_greater_than(step, distance):
    global minimum_expected_distance
    minimum_expected_distance = distance

@step(u'I read the infrared range finder')
def i_read_the_infrared_range_finder(step):
    global actual_distance
    actual_distance = zumo.read_distance()

@step(u'I should see a distance greater than (.*?) cm')
def i_should_see_a_distance_greater_than(step, expected_distance):
    assert float(actual_distance) > float(minimum_expected_distance), "Distance returned = %d" % actual_distance

Running Lettuce a third time now shows everything is green, meaning our scenario is passing and our code to generate distances is working. Well, sort of. We have to remember that we are now mixing a controlled software environment with real-world robotics and as the adage goes, “anything can happen in the next half hour.” Clearly this scenario will only pass if the distance from Zumo George to an object is greater than 10cm. For me this is perfect as George always starts his working day facing away from obstacles. We could of course change our code to simulate the response from the GP2Y0A41SK0F (not the easiest of components to pronounce, or spell) but then we are not demonstrating the desired real-world behaviour: that when Zumo George is not facing a nearby object he shall be a happy robot ready to drive.


You may note that something strange has happened though. We are clearly only running one scenario against a single feature by specifying the tag ir yet Lettuce is reporting that 2 features have passed (which you would think implies a minimum of two scenarios executed). I think of it this way: we have told Lettuce that only a single feature shall be run by telling it absolutely (in this case) that only a single tag containing a single scenario is within scope, therefore we have told Lettuce that the other feature passes and it counts it as such. This is on the basis that BDD should be all-or-nothing, i.e.: to demonstrate that software is fit for purpose all of our scenarios must pass and we are stating we are taking responsibility for this decision in this other case. Another way to think of it is that as the other feature contains no scenarios that we execute there is nothing that can fail, i.e.: it passes by default. It is something to be aware of though as it can make your numbers look a little strange if you are not used to seeing this outcome.

Next time: The Ryanteck 3 Line Follow sensor

* The evil truck from Knight Rider.

Robotics 1: Zumo George, a BDD rover

It is time to build a new rover, and to take a different look at how we can determine how it is controlled by a series of behaviours, defined using the tenets of Behaviour-Driven Development. BDD is a superb way to undertake development as it emphasises genuine communication and collaboration between business stakeholders, Developers and Testers. Behaviours are defined as features and scenarios, the latter elicited as specific examples using the Gherkin syntax, for example:

Scenario: Drive forwards
   Given Zumo George is greater than 10cm from a wall
   When power is applied to the motors
   Then Zumo George should drive forwards

BDD scenarios are written before other code, and determine what code is written. Hence no wastage: we develop what is required and it most likely passes first time. When the scenarios (the tests) are executed we can clearly see which steps pass (green), fail (red), or have not yet been implemented (that sort of muddy green-yellowy-brown).

I will be exploring the use of BDD to program this rover in quite some depth over a number of articles, intermixing some electronics to show how BDD is an ideal abstraction to explore behaviour-based robotic control. I’m going to term this BDR, Behaviour-Driven Robotics.


In the above example you will note too important points: firstly in the second feature I am defining scenarios that can be used for an internal diagnostic on Zumo George, for example: “Confirm ultrasonic is responding”. These tests will be executed every time Zumo George boots and if any test fails then he will flash a red light and not commence roving which should avoid the problem of an out of control robot. Perhaps more importantly, you can see that George has no lasers and has not been programmed to use them in any case (the first three undefined steps). This is fortunate for obvious reasons.

You will already have noticed that I have named my robot Zumo George and given him agency. I think this is a good thing as he will be expected to mimic certain human behaviours (e.g.: don’t bump your head on a wall while walking / driving). Agency in a robot enables me to mimic human-like behaviours in code. It does however mean I will find myself leaning towards anthropomorphism, referring to Zumo George as “he” rather than “it”.

The chassis of the rover is based on Pololu’s Zumo (hence the rover’s full name) and Pimoroni’s recently released Explorer HAT Pro. The Zumo is available in a number of variants for Arduino such as the all singing Zumo 32U4 which has sensors, buzzer, LCD, accelerometer and more, and also the bare-bones Zumo Chassis Kit which is perfect for the Raspberry Pi as we can add our own electronics.


The Zumo is very compact meaning that any model B is borderline too large. Whoever would have thought the words “too large” would be used to describe the Raspberry Pi! This is because the Zumo is designed to take part in Mini Sumo competitions where the robot must conform to dimensions of 10cm by 10cm. To be honest, a B/B+/v2B would just about squeeze into the available space and certainly others have created Zumo robots using the B. To minimise the footprint I have opted for a Model A+ which is almost small enough (ahh if only it was 1.5mm thinner. More about this in a later article).

I purchased my Zumo from those excellent people at Pimoroni, and also elected for two 95:1 ratio motors. The motors are intentionally purchased separately to enable you to opt for those that best match your robotics need (essentially outright speed versus torque). You can easily drop in replacement motors if you change your mind at a later date as the plastic motor cover on the chassis is removed with just two screws.


At this point a confession is in order: I like to tinker with things and see if I can break them. I think this is because my day job is in software testing. Unfortunately this tendency to meddle with things caused me to break one of the motors, necessitating ordering a third. The lesson quickly learned is never manually rotate the drive shaft of the motor as you will quickly grind down the gears until it slips horrendously in use. I share this in the hope that you only have to purchase two motors. On the plus-side I do have a (slightly crippled) spare motor I can now disassemble to better understand how the gearing works. To be honest the motor mechanism itself is fine as it is just the cogs that are worn so there is hope yet that I can resurrect this for a future project.

I considered various options to control Zumo George’s motors and in the end put four possible solutions up against each other in a winner-takes-Zumo knock-out:

PicoBorg is tiny, it really is, and is a great first-step into robotic motor controllers. I’ve had great success using this with a larger robot based on the Magician Chassis. However it is not bi-directional without the use of a pair of 5V relays and including such immediately bulks out the parts list as one also needs a board and cabling to mount them on. Bi-directional capability is essential in a tracked robot (IMHO) as it provides the ability to turn on the spot and not just in an arc. PicoBorg Reverse was briefly considered as a possible solution, but at £31 for the board was felt to be pushing the budget a bit.

The L298N is the go-to staple of bi-directional controllers. With prices in the £1.50 to £4 region it wins on cost. However it is a comparatively bulky thing with a big heat sink rising vertically, and as a 5V device requires additional circuitry for safe usage with the Raspberry Pi. This makes using it in a compact platform somewhat tricky.

The Ryanteck RPi Motor Controller Board is a great bit of kit. It provides bi-directional motors and is compact. Ryan has done an excellent job of documenting the board and providing example code in Python. The GPIO pins are also exposed making it easy to add further electronics (PicoBorg can be mounted on TriBorg for the same effect). I was all set to purchase this board when I spotted an announcement from Pimoroni...

The Pimoroni Explorer HAT Pro is a crazy good board. Using the available easy-peasy Python library one can control both bi-directional motors and take advantage of a large number of other available inputs and outputs. These include four capacitive touch sensors, four pads to attach crocodile leads to, four buffered 5V input and four buffered 5V output pins, two 5V buffered ground pins and 5V buffered analog pins. Also down one edge of the board are an array of 3v3 pins for use that are not buffered. To finish the board off there is even space for an included mini breadboard to be mounted on top. Coming in at the same size as the A+ this is my new favourite wonder board for the Raspberry Pi.

My parts list is now:

  • Pololu Zumo Chassis
  • 2x 95:1 micro metal gear motors (I needed 3 *ahem*)
  • Pimoroni Explorer HAT Pro with mini breadboard
  • Generic tiny WiFi network adaptor
  • 16GB Integral Micro SD Card
  • Raspberry Pi Camera
  • Bendy arm thing to hold camera up
  • Pimoroni Camera Mount
  • HC-SR04 ultrasonic distance sensor a Sharp GP2Y0A41SK0F IR distance sensor, sourced from eBay (see Part Two)
  • 3x plastic legs to raise up the Raspberry Pi Model A (more on this next time)
  • An assortment of wires to hook everything up.
  • Ryanteck 3 Line Follow Sensor (not shown in the above photographs)
You will note two seemingly obvious missing items, namely a battery and some kind of game controller to drive Zumo George for when he is not in auto-roving mode. I am also investigating pan and tilt mechanisms for the camera and / or distance sensor. These parts will be covered in later articles. I have something cunning in mind for the battery but can’t say more about this at present.

Next time: Replacing the HC-SR04 due to a technical hiccup

A clock for your Pi

A Kickstarter is currently running for PiMuxClock. It is a great self-solder or pre-assembled (depending on what one pledges) kit that gives you a 4-digit clock, a header to attach a real-time clock module (not essential to use the kit), temperature sensor and a few other bits and pieces too.

What is absolutely fantastic is the price, which at £7 for the early bird (and £8-£10 for the not-so--early or the I-want-more-features pledger) represents stunning value for money. It is low priced kits like these that actively get people into soldering. Looking at the parts list this is a straightforward kit that has a definite pleasing end result and I imagine would be great as a supervised soldering project for kids.


Charlieplexing Kickstarter (with a Christmas Tree)

Over on Kickstarter I have just come across an interesting GPIO Christmas Tree project. Now, before you wonder why the world needs yet another GPIO Christmas tree, this one is a bit different as it uses something called Charlieplexing.

I’ll be honest and say I’d never heard of Charlieplexing before this point (multiplexing, yes). It’s a really interesting technique for getting more functionality out of a smaller number of GPIO pins. Andrew Gale, who is running the Kickstarter campaign, has an interesting video on how this technique works up on YouTube.

Andrew’s pocketmoneytronics is building up a great set of low cost interesting Raspberry Pi boards. Good stuff.

LedBorg arrives: time for some pretty GPIO-driven colours

Yeay! I bought a LedBorg recently from PiBorg (only cost a few quid) and it has proven very straightforward to set up and use. LedBorg is essentially 3 LEDs on a very small (as in VERY _small_) expansion board for the Raspberry Pi. It is about the width, and half the length of my index finger making it possibly the teeniest hardware add-on I have every installed.

LedBorg’s LEDs can be set to off, low or high for each of the red, green and blue diodes. In combination this can be used to generate up to 26 colours. The setup instructions are clear and easy to follow. Just make sure that if you have a 512MB Raspberry Pi that you follow the Rev 2 instructions that are on the page.

Changing the colour is as easy as issuing the following from the terminal:
echo “RGB” > /dev/ledborg
replacing RGB with the off (0), low (1) or high (2) value for each of the red, green and blue diodes.

A few examples:

echo “222” > /dev/ledborg
(all LEDs at maximum output)

echo “000” > /dev/ledborg
(all LEDs are off - strictly speaking the LedBorg is not actually outputting black... it is off)

echo “200” > /dev/ledborg

Darker Red
echo “100” > /dev/ledborg
(appears less intense than full Red’s 200)

echo “220” > /dev/ledborg

echo “202” > /dev/ledborg

Ok, so what practical uses can it be put to? Anything from a random colour generator, to colour waves to a CPU usage monitor. In the latter case the demo application that can be installed from PiBorg will change LedBorg’s colour output from Green to Red when the CPU spikes. Here’s an example of a random colour generator that I wrote quickly in Python:

import random, time

while True:
    lbRed = random.randrange(0,3)
    lbGreen = random.randrange(0,3)
    lbBlue = random.randrange(0,3)

    lbColour = str(lbRed)+str(lbGreen)+str(lbBlue)

    LedBorg = open('/dev/ledborg', 'w')
    del LedBorg

    print lbColour

This will pick a random value between 0 and 2 for each of the 3 diodes, set these values, causing the LedBorg to light up accordingly and then print the colour values selected to the terminal. Note that the range is specified as 0,3 as, from tutorialspoint the second value is the stop value and is excluded from the range. Try changing this to 0,2 and you will see that when run the program never output the number 2 (ie: high, LED on maximum) to the terminal. The Python docs do not explain this subtlety.

I have various plans for LedBorg using, AJAX and my Android phone for remote control of my Pi when not connected via SSH and with no monitor plugged in. I can see LedBorg as a very handy gadget to give visual feedback that whatever I set on my Android phone has been so set on the Pi.

PiBorg also make the PiBorg (unsurprisingly), an interesting robot controller for the Raspberry Pi. Here’s a thought: if you cross a LedBorg with a PiBorg do you get a Cylon?