Blog

Python and Raspberry Pi talk at FOSDEM

Earlier this month, I spoke on the Python track at FOSDEM 2017. My talk introduced the Raspberry Pi as a tool for physical computing and IoT to Python programmers in the free & open-source software community.

I talked about the Raspberry Pi Foundation’s mission, our education programmes, introduced the GPIO pinout, HATs, GPIO Zero, Remote GPIO, Picamera, Energenie, Sense HAT, Astro Pi and more. You can view the slides, and watch the video here:

Christmas Coding Challenge – Uno

During this Christmas break I decided to have a go at implementing the card game Uno in Python. It’s a fun and simple game for all ages, and the rules are easy to pick up and follow – but there’s quite a challenge in implementing the rules in a program! I spent a few hours over a few evenings working on it and now have a completed version, and wanted to share some of the interesting bits of the code.

Uno

Uno is played with a bespoke card deck (not a normal deck of playing cards). Uno cards have a colour and a card type (a number or a symbol). There are four regular colour cards, and there are special cards which are black.

Each player is dealt a hand of 7 cards, and they take turns to play a card, trying to become the first player to get rid of all their cards. A player can only play a card if it has the same colour or card type as the last played card. If they cannot play a regular card but have a special black card, this can be played instead. Some cards have consequences, such as the next player having to pick up extra cards, players skipping turns or reversing order of play.

Unit tests

I used a test-driven development (TDD) approach to further my progress in building up the game from simple isolated card logic all the way to simulating gameplay in a multi-player game. I used pytest for its ability to verify exceptions were raised, but otherwise simply used Python’s built-in assert statement.

An Uno Card

I started by writing some tests to check errors were thrown if you tried to create an invalid card, then proceeded to creating valid cards. The card was implemented as an UnoCard class, whose objects stored a colour and a card type.

Card rules

As well as validation on init, I added a method to determine whether a given card was playable on another card. The card playing rules are quite straightforward: you can place a card o

The deck

I started building up an UnoGame class, where a deck of UnoCard instances was created. The deck needed to contain a complete set of Uno cards, which I determined from this image on Wikipedia:

So it turns out there are digit cards 0-9 (and then 1-9 repeated) for each of the four colours, and two of each special card in each colour. There are also four of each of the two types of black cards.

I started by creating lists defining the colours and card types, and initially created the deck by combining these lists in a number of for-loops. However, I later refactored this to use product, repeat and chain from itertools in the standard library, which made it much neater:

color_cards = product(COLORS, COLOR_CARD_TYPES)
black_cards = product(repeat('black', 4), BLACK_CARD_TYPES)
all_cards = chain(color_cards, black_cards)
deck = [UnoCard(color, card_type) for color, card_type in all_cards]

The UnoGame’s deck was then simply a list containing UnoCard objects.

Gameplay

In order for there to be a game, there needed to be players. I made UnoGame initialise with a given number of players. This meant a new UnoPlayer class. Each player would be dealt a hand of 7 cards from the shuffled deck. But first, I wrote tests and made sure that an UnoPlayer object could be created with 7 cards, and couldn’t be created without them.

Reverse

In order for gameplay to take place, I needed to work out how I would designate a player as being the currently active player (whose turn it is). My first thought was itertools.cycle – a handy tool for infinitely iterating over an iterable object like a list, and just starting back at the beginning of the list once all items have been exhausted. However, Uno has a reverse card, meaning the order of play can be reversed at any moment.

I thought it through, and decided to design a new ReversibleCycle class to implement something like a cycle which could be reversed, as specified by the Uno rules. It took me quite a while to figure this out exactly, and get all my tests passing, but I was quite happy with the implementation I ended up with. A tricky part was the edge-case of what happens if the first card drawn (not played by a player – just the starting card) is a reverse card. According to the rules, play will start with the player to the right of what would have been the first player (i.e. the last player). Otherwise, in normal circumstances, the first player will play first, naturally.

I implemented the class as an iterator, so you could loop over it or manually next() it. Example usage of my ReversibleCycle class:

>>> rc = ReversibleCycle(range(3))
>>> next(rc)
0
>>> next(rc)
1
>>> rc.reverse()
>>> next(rc)
0
>>> next(rc)
2

I wrote tests of the ReversibleCycle in an isolated fashion. It works with any iterable, and I simply created an attribute within my UnoGame class which referred to an instance of ReversibleCycle, where the iterable was a list of UnoPlayer objects. I used a property to make it easy to look up which was the current player at any given moment.

More gameplay

Back to testing the gameplay, now I had a working model for cycling through players, with the ability to reverse order of play once a reverse card was played, I tested that players could play cards only when it was their turn, and that they could only play valid cards. I then tested that players playing cards would cause the correct consequences (e.g. the next player picks up 2, the new current player is the right one if a skip/reverse/etc. card is played, and so on).

The winner

I began testing gameplay by allowing the deck not to be shuffled, so that I had a predictable, testable order of cards. Looking back, I should have used a random seed instead (thanks for the tip, Dave). I took this game all the way to a player being designated the winner and the game ending.

Automated play

I then proceeded to write some code, similar to my test code for the gameplay, which would automate play for all players, and end at some point declaring one of the players the winner. There was nothing clever about the way the players played – no strategy – I just determined whether they had any playable cards, and made them play the first playable one in their hand.

AI

The last thing I did was to take the automated play code and embed it inside an AIUnoGame class, allowing for a single player to be controlled by the user using text input on request. The playable player would be shown their hand each round, and asked which card they would like to play. All actions of other players would be displayed (e.g. “Player 2 plays Red 5”, “Player 4 picks up 2”), and the winner would be declared as before. Again, nothing smart in the AI, but that’s something I may add later.

GUI?

I had wondered when I started whether it would be feasible for me to create this as a GUI – a real visual playable game. I obviously wanted to start from a text-based interface, and get the logic of the game down before I worried about graphics, but again, it’s something I would like to look at next. I wonder if PyGame Zero or guizero would be suitable. Watch this space!

The code

You can find my code on GitHub.

All Things Open 2016 – Raspberry Pi for everyone!

I recently attended All Things Open, an open-source conference in Raleigh, North Carolina, run by Red Hat. I was invited by my friends at opensource.com – and it was a great opportunity to meet the team and some of the moderators, columnists and contributors.

Ben Nuttall on Twitter

ATO2016

I was asked to give a lightning talk, and I decided to speak about the Raspberry Pi Foundation’s mission: what we do, how we do it, and where we’re at now! Here’s the video of the talk (3m20s):

What is the Raspberry Pi Foundation? 10 million computers sold

The Raspberry Pi Foundation began with the purpose to find a way to get more students at Cambridge University to study Computer Science. A small, cheap Linux computer called the Raspberry Pi was created as the solution, and since the first product in 2012, educators, hobbyists, and industrial users have been creating amazing projects with it.

My slides are published on speakerdeck. I also wrote an article on the same subject for my column that month: Raspberry Pi continues to blaze new trails.

I also got the opportunity to visit Red Hat Towers, and meet their CEO Jim Whitehurst to talk about why I contribute to opensource.com. And for the conference social afterparty, they’d booked nerdcore artist MC Frontalot!

Ben Nuttall on Twitter

You have more stickers on your laptop than I’ve ever seen. Would you like a Vim mug?” #ATO2016

Ben Nuttall on Twitter

There’s no money in open-source

Thanks to the All Things Open and opensource.com teams, to Red Hat, to Jim Whitehurst, and to all the speakers at ATO!

PyCon Russia keynote – Physical computing with Python and Raspberry Pi

I was invited to give the closing keynote at PyCon Russia, which took place in Moscow in July. It was my first visit to Russia – and I had a great trip.

Ben Nuttall on Twitter

Today I am mostly being the Raspberry Pi Community at @PyConRu

I travelled with David McIver, the author of property-based testing framework, hypothesis. I also got to spend some time with other international speakers including Jackie Kazil (whom I met on my 2014 US Tour), Python core developer Raymond Hettinger, Google developer Nathaniel Manista, and (local) Armin Ronacher, the creator of the Flask web framework.

 

Here’s the video of my talk on Physical computing with Python and Raspberry Pi. I spoke about the Raspberry Pi, the Foundation and its mission, and lots of technical detail about the GPIO Zero library:

Physical computing with Python and Raspberry Pi, Ben Nuttall, Raspberry Pi

Uploaded by ??????? ?????????? on 2016-07-13.

You’ll find my slides on speakerdeck.

What’s new in GPIO Zero v1.3?

One year ago today, I started the GPIO Zero project. We now have a core team of three (Dave Jones, Andrew Scheller and me). There have been 587 commits, we’ve released four major versions, and published a book. The library has great coverage of GPIO devices, and contains features I never even dreamed of. In the last year I’ve delivered workshops and given talks about it at conferences and events around the UK, the US and even in Russia. It’s being used in Raspberry Pi’s learning resources, and teacher training and by hobbyists around the world. Read on to find out what’s new in the latest release.

GPIO Zero v1.3 is out now! Install it (or upgrade) with:

sudo apt-get update
sudo apt-get install python3-gpiozero python-gpiozero

What does this release bring?

  • New ButtonBoard class
  • New Servo and AngularServo classes
  • New CPUTemperature class
  • Improved remote GPIO support
  • Plenty of behind-the-scenes changes
  • Lots of new recipes

ButtonBoard

The new ButtonBoard class is a composite device representing multiple buttons. The idea being you can pass the value set from a collection of buttons into another collection of the same size: e.g. matching buttons to LEDs. You can also process the value set to get the information you want, for example the number of buttons pressed; any pressed, all pressed, proportion pressed or more. We’re currently discussion options for documenting these examples and possibly extending the features of this class in Issue #425.

Servo

The long-discussed Servo classes have now arrived! Servo allows you to move a servo between its minimum, maximum and mid-point positions:

from gpiozero import Servo
from time import sleep

servo = Servo(17)
while True:
    servo.min()
    sleep(1)
    servo.mid()
    sleep(1)
    servo.max()
    sleep(1)

AngularServo allows you to move a servo to specific angles:

from gpiozero import Servo
from time import sleep

s = AngularServo(17, min_angle=-45, max_angle=45)

s.angle = 0.0
sleep(1)
s.angle = 15
sleep(1)
s.angle = 45
sleep(1)
s.angle = -45

We’re currently discussing what else should be added to the servo classes for different use cases.

CPUTemperature

We introduced some internal devices which act like regular GPIO Zero classes. CPUTemperature allows you to access the Pi’s CPU temperature, and use it to control other devices:

from gpiozero import LEDBarGraph, CPUTemperature

temp = CPUTemperature(min_temp=50, max_temp=90)
graph = LEDBarGraph(5, 6, 13, 19, 25, pwm=True)
graph.source = temp.values

Now the LEDs will light up according to the temperature: at 50 degrees all the LEDs will be off; at 90 degrees they’ll all be on; at 70 degrees half will be on; and anything in-between. There’s also a TimeOfDay class provided but it’s not working properly at the moment so I’ll cover that in the next release post.

Remote GPIO support

I talked about this last time. It’s really exciting. It was amazing to see this working in v1.2 but support wasn’t really very good, so its use was limited. However, significant work has gone into remote GPIO support since then and it’s going to be really powerful. Thanks to a pigpio, a C library from GitHub user joan2937, we can set up GPIO Zero devices connected to pins on Pis over a network. Easily.

Usually, you’d set up an LED like so:

from gpiozero import LED

led = LED(17)

led.blink()

Where the 17 refers to pin 17 on the Pi you’re executing the code. You can also do this:

from gpiozero import LED
from gpiozero.pins import PiGPIOPin

pin = PiGPIOPin(17, host='192.168.1.4')
led = LED(pin)

led.blink()

Here, rather than simply specifying the number 17, we’ve provided a reference to a pin on another Pi on the network. This means you can remotely control the LED connected to that other Pi.

However, an easier method is to supply the Pi’s IP address in an environment variable. Before running the python shell, IPython, IDLE or whatever you’re using, simply set the PIGPIO_ADDR environment variable:

$ PIGPIO_ADDR=192.168.1.4 python my_script.py

to run a file, or:

$ PIGPIO_ADDR=192.168.1.4 ipython3

to run the IPython shell, for example. Each of these will be set up so that when you type led = LED(17), it uses pin 17 on that remote Pi. Note: you’ll need to enable Remote GPIO, start the pigpio daemon, and install the pigpio python client on your host machine. See full instructions in this gist.

Of course, you can mix these methods and use a default pin factory but also specify pins on other Pis.

To set this up, you need the pigpio Python library installed on the device you’re running the code, and the pigpio daemon running on the remote Pi (and remote GPIO enabled in raspi-config). Read the pins documentation for more info.

Did I mention you can run this on any PC, not just on a Pi? That’s right. You can install GPIO Zero on your laptop and run GPIO Zero code which communicates with a Pi on the network. The Python code is running on your laptop, which communicates with the pigpio daemon using sockets. The daemon does all the GPIO stuff. I’ve seen this working on Linux, Mac and Windows. Admittedly, we need to provide much more solid instructions for getting this working if we want it to be seen as a viable solution for schools, Code Clubs and such. But it’s a start. Please give feedback if you’re using it (if you have any issues or not – we’d love to know). There’s also some interesting stuff around. If you know your way around installing with pip on Windows and Mac, we could use your help! See Issue #434.

What’s next?

We didn’t complete all the things we had on the list for this release, but we decided to push it out anyway, and leave the rest to the next release. As well as lots of minor improvements, we intend to add I2C support, including I2C expander chips (and probably SPI expander chips while we’re at it), which will be really handy. You’ll be able to set up an expander chip, and index it to refer to each pin, and create regular device objects on those pins, something like this:

from gpiozero import IOExtender, LED

ext = IOExtender()
led = LED(ext[0])

led.on()

Then there’s temperature sensors, different types of motors, servos and more. Feature requests welcome on GitHub! We’re also aiming to establish a release schedule for future releases.

Thanks

Again, thanks to Dave Jones and Andrew Scheller for all their hard work in the last release, and to everyone who provided useful feedback on GitHub. Keep it coming!

PyConUK

Dave and I will be giving a talk together on GPIO Zero at PyConUK this week. The video will be available shortly after the conference. We’re also running a sprint on GPIO Zero, welcoming new developers to the library. Come and have a go if you’re available, and we’ll show you where to start.