RasPi ‘Selfie’ Tweet Cam

I recently ran a workshop, with my good friend Phill Isles, at the Test Management Summit. The subject was Testing the Internet of Things: The Dark and the Light.  One of the things that we wanted to do was demonstrate a live Internet of Things device, that the delegates could actually interact with, see how it works, and begin to understand what IoT means.

Tweet Cam

Tweet Cam

So I thought I would build a Raspberry Pi Tweet Cam, that the delegates could use to take selfie’s.

It would need a Pi Camera, obviously. Then a button to press to take the photo. An LED to show the user what was happening. And finally another button so that we could turn it off.

The aim was to run headless, i.e. no monitor, keyboard or mouse.

Finally it would be equipped with a Wi-Fi dongle, to enable it to connect to the internet and Tweet.

A fun Raspberry Pi project. I mostly used the instructions for Tweeting from Alex Eames RasPi.TV site (which I find extremely helpful). Details can be found here RasPi.TV Taking and Tweeting a Photo. Then added my own design and functionality.

I needed some parts:

  • Model B+ (Tick)
  • Pibow Coupé Case (Tick)
    The pi looks great in the coupé case.
  • Breadboard Base for Pibow
    Which replaces the bottom layer of the Pibow Coupé case and gives a larger platform onto which a half-size breadboard can be affixed.
  • Some buttons.
    I got ones with round and square tops.
  • An RGB LED.
    Why install three LEDs when you can fit one that does all three colours. You still need 3 input connections though – one per colour.
    (You can then mix the inputs to create additional colours – Tough to do in an individual bulb!)
  • Resistors (Tick)
    I didn’t quit have the right resistors. I managed to use two in parallel.  And ordered a jumbo multi-pack of 2,000.
TweetCam Top

TweetCam from above

The Build. Once all of the parts had arrived, I thought on the matter for a few days.  When I had a rough idea of what I was going to do I started the build.  I used a rapid prototyping approach.

First I assembled the Pi in the coupé case extended with the breadboard base. Connected the camera using a simple flexible mount which plugs in the audio socket. (The mount works, but is a little loose in the socket – holds the camera just fine though.)

I then added a resistor, button and some wiring to the breadboard, and some jumpers to connect the breadboard to the Pi. Wrote some code to detect the button press. Then added code to taka picture when the button was pressed.

Next step was to add the RGB LED. There were no instructions for the RGB LED on the vendors site. I e-mailed them, and they responded with a two page .pdf, which had the orientation, and forward voltage. Not all RGB LEDs are the same. A simple internet search shows that.

After following some on-line guidance I connected the RGB LED, adding a resistor to the Red bulb. Then wrote a simple LED test program. When that was working I updated the TweetCam code to turn the LED Green when Ready, Red when not – I had decided that the TweetCam would only take a photo every 2 minutes, so as not to spam the world. And the LED would flash Blue when it was taking a photo. Wrote the code and tested it.

TweetCam Instructions

TweetCam Instructions

Then I added a second button, which was used to shut-down the Pi, as it would be running headless and this is always a good thing to do when turning off a Pi.  And I made the LED flash Red whilst the Pi was shutting down.

Finally with the program doing everything but Tweet I added in the Tweet code. I followed the excellent instructions from Alex Eames.  And yes, it worked. I pressed the button, the Pi took a photo, flashed the LED, and tweeted the picture.

This is ‘Testing in Production’. It is difficult to test a tweeting program without getting comments! So I only tweeted a few photos. I actually created a version of the program with the Tweeting line of code commented out, so that I could test changes, without bombarding Twitter.

The build took 6 hours from start to finish. I was quite impressed with the speed at which a functional and usable IoT (Internet of Things) device could be built and tested.

And if you are wondering what the pictures looked like the ‘live‘ output can be seen here TweetCam Pictures

PostScript.
We used the device in sessions on two days. On the first day the internet was not working at the conference venue. It was a all a bit of a damp squib. We were though able to demonstrate the inner workings of the Tweet Cam to the delegates but were unable to Tweet. Day two was perfect. Press the Blue button and tweet a picture of yourself.

Testing the Internet of Things: The Light and the Dark

Abstract:

IOT or the ‘Internet of Things’ is this year’s buzz word. Everyone is talking about it, but what is it, and what does it mean for Testers?

Every week you read another BBC Technology News article about how your next fridge is going to connect to the internet, your washing machine is setting the central heating, and your household lights work all on their own. The dark side.

This workshop, using practical and interactive demonstrations will help you to:

Tweet Cam

Tweet Cam

o  Identify what IOT devices are,
o  Understand how they are built,
o  Determine how to test them,
o  Share some lessons learnt from; building, testing and using IOT devices,
o  And actually use some live IOT devices during the workshop to ‘make it real‘ and bring to life your understanding.

The session covers low cost hardware, open source software, the recently announced Windows 10 IOT program, scripting languages e.g. Python, internet connection, communication, data recording, and messaging. And from a software testing perspective, we focus on how to go about testing, what approaches to use, what the limitations are, and look at what can go wrong.

The world is changing, and never has it changed faster. The ‘machines’ may not have taken over yet. Current predictions from Gartner are that by 2020 there will be more than 26 billion non-PC and mobile devices connected to the IOT.
(These devices are going to require an awful lot of testing.)

Downloads:

 PowerPoint Show    PowerPoint show (45.6mb)

Presented at:

1. TMS, London, Apr 2015. (½ day Workshop)
2. TMS, London, Apr 2015. (Discussion Session)
[aka Testing the Internet of Things: The Pain and the Gain]

Notes:

This session was developed jointly with my good friend Phillip Isles.  We co-presented both of the above sessions at the Test Management Summit, London.

Techniques for Successful Program Test Management

Abstract:

Bear

Shouty Test Manager

After working successfully as a test manager for a while, the next step forward is into program test management.  Many think this is just some super test manager, or in a lot of cases, a ‘shouty’ test manager. In fact it isn’t. It is a transition into an oversight role where others do the testing, and you are setting the direction, giving guidance, and having oversight.

This is quite a step up and suddenly requires a set of skills that successful test management does not develop.

It is quite common for program test managers to look after a number of testing projects and testing teams. The scale has changed, and you have begun to operate at the organisational level, working with other members of the program management team.

In this workshop we will look at the new range of required skills; Leadership, Accountability and Responsibility, Oversight and Awareness, Stakeholder Management, Communication, Influencing and Negotiation. We will work though some useful models so that you can take away a kitbag of tools and techniques to use back in the office.

We will also look at how to stay relevant to the testing operation, and retain value-add for your role whilst now working at the organisational level, and delivering through others. And even if you aren’t working as a program test manager yet, the skills and techniques we look at in this session will be invaluable today, to start using, developing and refining.

Downloads:

PowerPoint Show  TMS Workshop (28mb)    PowerPoint Show  BCS SIGiST Keynote (12mb)

Presented at:

1. TMS London, Apr 2015. (Workshop)
2. BCS SIGiST, London, Dec 2015. (Keynote)

New Testing Tool – Binoculars

A few days ago I met my good friend Phill Isles for coffee to plan an upcoming workshop centered around testing IOT devices.

Phill is quite interested in electronics and at the end of our meeting he handed me a small circuit board with what looked like half a small golf ball on one side (something like an icosahedron).  It turns out to be an PIR motion sensor (Passive InfraRed sensor). He recently bought 5 and thought I could have some fun with one (Thanks Phill). And all for only 80 pence each including shipping.

Later he sent me a link to the adafruit website with a tutorial for the PIR sensor.

PIR motion sensor connected to Raspberry Pi

PIR motion sensor connected to Raspberry Pi

I wired the PIR sensor into my Raspberry Pi, then slightly modified the example program to print a ‘Movement Detected‘ message on the screen. And then started to test the sensitivity of the device.

As I moved away from the desk I could see the ‘Movement Detected‘ messages being displayed on the screen. But when I got 15 feet away I could no longer read the screen. Had a message been displayed? It was hard to tell.

How can I test the range? I was on my own with no-one to help. 2 minutes later I had a pair of binoculars to view the screen and all was well again.

It was the first time I have ever used binoculars for testing software. And a new tool was added to my software testing kit-bag.

Nikon Binoculars

Nikon Binoculars

 

100 Million Things To Do In Under 2 Minutes

Raspberry Pi 2

Raspberry Pi 2

According to Douglas Adams, it was the ‘Long Dark Tea-Time of the Soul‘, better known to all as Sunday afternoon. You can either hate them or engage them. Your mind begins to wander. And then you land on a thought. It won’t go away. An itch that needs scratching.

For me it was wondering how many lines of python the new Raspberry Pi 2 would execute per second. Just to give me a feel for how much work the Pi can actually do. I have 6 different Raspberry Pi models and a comparison would be interesting.

I wrote some simple python code:

#!/usr/bin/env python
import time
n = 0
print " \nBefore " + str(time.time())
while n < 100000000:
    n += 1
    continue
print " \nAfter " + str(time.time())

NB. This is the final version of the code.

I wrote and tested the code on my Windows desktop before transferring it to the Pi. And the first time I ran it I had to crash out because I had forgotten to increment the counter. An endless loop! Ooops.

The code is very simple. I Just wanted a time-stamp before and after, and a minimal loop, to get a rough idea of speed. The amount of work that was being done.

I set the loop to 10,000 iterations to start with. The ran. It completed within the same time-stamp. Almost instantaneous. So I upped the loop to 100,000. Again a fraction of a second. Then a million. Again inside a second. So I jumped to 100,000,000. 100 million iterations. This took 8 seconds on the desktop.

My Windows desktop is an intel core i7 3770K. The program was only running in 2 cores. Using 25% of those cores. Roughly 8% of the processing capacity.

The code was working so I transferred it to the Pi 2.  I thought that this was going to take ages to run. First time through it took 156 seconds which I then got down to 115 seconds with the standard 1000mhz overclock. To process 300 million lines of python code. I find that amazing. (100 million iterations * 3 lines of code.) That works out to be 2,600,000 lines of python code a second. On a Pi.

PerfTest3

(04/12/2015 Updated to include new Pi Zero.)
(04/03/2016 Updated to include new Pi 3 Model B, at just under a minute, and an original release Model B 256mb at 290 seconds.)

NB. The Pi 2 result came from running the program simultaneously in 4 cores and taking the longest core time.

This is in no way scientific. It is not a performance test. But as a very rough guide to just how powerful a Raspberry Pi can be, regardless of model, I found it amazing.

(Do try this at home!)

And links to some more thorough Raspberry Pi Benchmarking:

Pi Foundation
Adafruit

 

2014 Some of My Favourite Things

As the year draws to a close it is fun to reflect on a few of my favourite things of the year.

  1. Pebble Watch
    Pebble Alert Message

    Pebble Alert Message

    I had known about the pebble watch for a while. I saw the initial KickStarter project but was too late to sign up. Over Christmas I thought that it was time to buy one. So on New Year’s Eve 2013 I bought one from the Pebble Watch site. It was on offer as a New Year special.
    The watch shipped from Singapore, and arrived about 10 days later. I paid the ‘government taxes‘ and the ‘mail handling charge
    First Impressions were that there was a fault with the screen, and the watch strap was too small.  It took several go arounds with support before someone told me all screens looked like that – a moire pattern. The software was poor, hardly worked from one day to the next.  The watch was put on the pile of ‘technology that I wish I hadn’t adopted too early
    A few months later the battery in my main watch died. I needed a watch to go away, so I turned to the Pebble. At the same time the software was updated to Version 2
    Now the watch worked, once you battled through the vagaries of set-up – I need to run Pebble Notifier on my Android phone to get Mail notifications. I bodged together a watch strap, and I was off.
    6 months later the Pebble is my main watch. I can’t go anywhere without it. It works perfectly, although the software is still updated a little too frequently. Some of the apps are a bit rough around the edge, but the main purpose is excellent.
    I don’t need to get my phone out to see whether I have an e-mail, or other messages, e.g. Twitter. They are delivered direct to my wrist.
    And having different watch faces is excellent. We use time differently as we do different things, and it is great to be able to do that all from your wrist watch. It is even better now that I have managed to send messages to the pebble from programs running on my Raspberry Pi 🙂
    And the screen moire – in certain lighting it is noticeable, but mostly it is not, and it doesn’t detract from the Pebble experience at all. I am sure they will fix that, but I love it all the same!


     

  2. Raspberry Pi A+ and B+
    The Raspberry Pi, but better.

    Lapdock and Model A+

    Lapdock and Model A+

    This is my new Raspberry Pi Model A+ sitting on top of a Motorola Atrix Lapdock – a screen and keyboard device for certain Motorola phones which can also be connect to the RasPi.

    Some people even think I have connected my Pi to a laptop in some way. No. It is a Pi Laptop, or should I say Pi LapDock.

    Connect a nano wi-fi dongle in the back of the Lapdock, open up a hotspot on your phone, and you are truly mobile with a snazzy Pi Laptop.  And I am getting 5 – 8 hours battery life.


     

  3. Google Sheets
    It is not often that I trip over something that I didn’t know, but the charting feature in Google Sheets that lets you scroll around a chart is excellent.  Someday all charts will look like this.  This might have been around for ages, but when I found it I could immediately see the potential – and used it for my Pi Weather Station.

    Scrollable Charts

    Scrollable Charts


  4. Heathrow T5 Pods
    I have travelled on the driverless personal electric transport Pods at Heathrow T5 a few times now and never fail to enjoy the experience. This year I was accompanied by a friend. They had a smile on their face for the whole way 🙂


     

  5. WordPress
    In just a short while it was possible to completely redesign this website.
    Yes, WordPress does have about 3 different ways to do everything, and each menu is context driven so the functions look different depending upon which way you arrived at them, which may account for why it takes ages for newbies (like me) to find what you are looking for. Notwithstanding all of that, the results are impressive to say the least:

    Ps. The old Doesn’t look that bad, but the new just looks ‘better‘.


     

  6. A £10 Temperature and Humidity Sensor

    Headless on Kitchen Windowsill

    Headless on Kitchen Windowsill

    I have had hours of fun with a £10 temperature and humidity sensor connected to my Raspberry Pi.
    I had to solder together some leads, then write a python program which updates an online Google Docs Spreadsheet, and sends low temperature messages to my Pebble watch (above).
    There is an immense amount of satisfaction to be gained from building something yourself. And great fun writing, and testing, the software to control it.
    A longer project post can be found here.


     

I hope 2014 has given you some favourite things as well?

A year in the life of Programming for Testers

It has been an exciting year presenting Programming for Testers It’s Easy! with my good friend Phillip Isles.

HorsesThe year actually started late September 2012 at the UK Testers Retreat at the village of  Eesergroen in the Netherlands (I struggled with that concept for a while as well).  Phill and I were in a discussion with someone about what we would like to present at a conference. I think I said something like “I would be interested, but only if I could run a workshop using the Raspberry Pi, a robotic arm, and got some testers to do some programming.

Well, I take credit for the idea, but it was just in the meme. I had unknowingly been influenced by the group. Later on in the weekend I spent an hour with Isabel Evans walking her through some basics in python programming. She had fun, and this became the programming spine of the workshop.

Phill and I added in the Robot Arm, the Raspberry Pi, some design and preparation, then headed off to Bruges for Belgium Testing Days.  Conferences now request speakers produce a video:

We were well prepared, rehearsed all of our moves, and not withstanding a few ‘technical issues‘ with an aged projector, got up and running for a 2 hour workshop. Amazingly we got through to the end, and managed to write some code to successfully achieve the Robot Arm challenge.  A good start then, and a real buzz that the workshop was successful.

We had also learnt a few things, like what to do for Mac users, the precise sequence to install the software in, and when people say “Yes my install is working” what they in fact might mean is “No, my install is not working!

 

 

Daffodils

We followed up Belgium with half day Tutorial at the London Test Management Summit (TMS). The longer half-day format giving us time to go into real depth with each exercise.  And the enthusiasm in the group after the session was a real reward for all the hard work and effort.

After London I was invited solo to the Czech Test conference in Prague to run the session again as a half day Tutorial.  Unable to turn down a trip to Prague, even though it also involved giving a track and Keynote, I immediately said “yes”.

As with the TMS the longer half-day format paid dividends. The real reward from the session was the fact that everyone managed to successfully finish the Robot Arm exercise, and the first to complete was a tester that had never coded before.

The next conference was at Agile Testing Days in Potsdam, on the outskirts of Berlin in early November. Phill and I had a few months off. We still had work to do though: updates to make to the slide pack and code exercises.

We also decided that to get real value out of the workshop we would write a supporting paper, which would take the reader through the process at an almost atomic level of detail. Given that when people were reading the paper, Phill and I would not be there to walk them through it.

I loaded all of the presentation material, including; slides, paper, video and code examples, onto my website here http://badgerscroft.com/home/programming-for-testers/ .

The workshop in Berlin went very well . We encountered some new problems. Language. Fortunately Daniel Maslyn joined us and was able to help out ‘internationalizing‘ the presentation. Mostly around the punctuation that is specific to python. Who would have through that # ! and :  would have caused so much trouble?

The following day in Daniel’s excellent presentation about Robotics he showed a couple of photos that he had taken in our Workshop to demonstrate the Robot Arm, Raspberry Pi, and Wii mote controller. Thanks for the kind words Daniel.

Afterwards Phill and I headed down to the Test Lab being hosted by Bart Knaack. Phill and I ran through the extra code submissions for the Robot Arm exercise that we hadn’t had time to run. All worked perfectly. Another testament to testers as programmers.

A weeks rest and then off to EuroSTAR in Dublin.  Phill only came to Dublin for the day. He wasnt originally coming but when we found out that over 70 people had signed up to an introductory programming session after the closing keynote we realized that it was going to take at least 2 people,  that our hard work was paying off, and we were gaining real traction.

The paper, although nominated which is a result in itself, didn’t win best paper. It was close . . . .

A lack of speaker prep facilities meant that we had to rehearse in the main hall. Sitting at table running a Robot Arm from Raspberry Pi is going to attract a crowd, and by a stroke of serendipity one of those was Neil Studd, who had attended the TMS workshop back in April. It took no time at all to persuade him to come along and help – thanks Neil.

We really did have over 70 people in a programming workshop at EuroSTAR. It went very well. Everyone got set-up. Completed all of the exercises, and even got the Robot Arm going.  A few did have to leave for the Guinness trip through. Hard choice that, Robot Arm vs. Guinness. We understand.

2014-11-25 15.48.46

Not quite the sunset for Programming for Testers, but we are nearing the end. Phill and I headed off to the BCS SIGiST in London for a half-day Tutorial. This was almost the hardest session to run. It took us fully an hour to set-up. Fortunately we had arrived early.  The session went very well. Everyone managed the Robot Arm challenge.

A few conclusions from what has been an exacting but very rewarding year.

Testers are more than able to write code. Of course it isn’t easy. But the hardest part is not writing the code. It is actually taking the simple steps to start.

And it was fun.  Best comment half an hour in at EuroSTAR. Head pops up and says “This is fun“.

We may well run the session again somewhere in the New Year. And if you have got this far then it will be no surprise to find out that I have ordered another Robot Arm and am looking forward to performing some hand-shake testing (thanks for the joke James!)

Thanks to everyone who helped, attended, supported, took part, or just influenced us.

Thanks
Graham Thomas

RasPi Weather Station

Some time ago I tripped across the adafruit temperature & humidity sensing page  for Raspberry Pi and Beaglebone black, showing you how to build your own weather station which recorded details in a Google Docs sheet online.

At the time here in the UK I couldn’t get hold of a sensor so I put the project on hold. Recently I found a sensor available from ModMyPi in the UK for only £8.49 + VAT so I bought it.

Brilliant. With only a little soldering, I should be up and running with a weather station that can record temperature & humidity, and upload to a Google Docs sheet. Now that I had the sensor I re-read the instructions. They looked more detailed than my initial perusal, so I put the sensor on the shelf for a week or two.

Two weeks later I remembered about it, and thought ‘how hard can this really be?

Revisiting the instructions I thought they were actually very clear, and now I was getting down to the build, seemed quite simple and straightforward.

AM2302The instructions showed the connections made through a breadboard, but I wanted to connect direct to the GPIO pins on the Pi, so on each of the 3 sensor output wires, Red, Yellow and Black, I soldered a corresponding Red, Yellow and Black male to female jumper lead. (I soldered the Male pin to the sensor wire – the female pin connects to the Pi.)  I also put some heatshrink around the joint to protect the connection.

So I now have a sensor with long wires which can connect directly to the Pi.  Which I did.

Then I followed the software installs. Straightforward. Ran the test program. It surprised me, but the Temperature and Humidity were displayed straight away – yeah!

The next task was to follow the instructions to run the program and output the readings to a Google Docs sheet.  This was a little harder for the following reasons:

  1. I had to change the sensor pin value from 23 to 4. The diagram showed wiring into GPIO pin 4, but for some reason the code had pin 23.
  2. I struggled to name my Google Docs sheet correctly. Just a standard typo. I thought I had removed the spaces in the file name but I hadn’t.

Then it worked.  I was even more amazed, so I took a picture.  And yes, everything looks a bit Heath Robinson’ish, and so it should.  This is a prototype. I made a stand from a wire coat hanger. I still have to fix the heatshrink.  Put the sensor on a different Pi with a full enclosure case. And I have to amend the software so that it runs automatically on boot, and checks that the internet is present before trying to write out to the Google Docs sheet.  Then it will be a stand alone device that I can leave in situ working as a weather station.

I will update this post when I have completed the device, and post a finished picture for comparison. Just to say for now that if you want to build yourself a temperature & humidity sensing device ,and want to see the output on the internet from anywhere in the world, it will take you about 4 hours work and cost you less than £15 (that is assuming you already have a Raspberry Pi).

Postscript:

As I finish writing this the Pi is in another room in the house and I am viewing the spreadsheet on-line watching the temperature slowly go down overnight, and that gives me a real sense of achievement.
There are however a few blank lines being written out to the spreadsheet, and there is a note about this in the instructions, so I will also have to modify the code to overcome that. But it in no way diminishes the warm glow and in fact means more fun coding a solution 🙂

Addendum:

I made a couple of edits to the code, found some excellent new features in Google Docs sheets, and here is a ‘live‘ link to my Test WeatherStation data as a chart (Data No Longer Updated). This will be up actively updated for a few days or so whilst I fine tune the operation. [ And I have now added a Low Temperature alert messages direct to my Pebble watch via Pushover following these instructions. ]

PearlTrees2