Book Review: Arduino Home Automation Projects

Categories Design, Interaction, Open-source, Programming, Technology

ishot-5

Arduino Home Automation Projects is a practical step-by-step guide to entering into the world of ‘DIY Home Automation’. The benefits of a DIY Arduino based approach to automation that this book puts forth are those of a vastly reduced expense as compared to a commercial fit-out, more control through understanding and an endlesslessly customisable solution.

The book covers real-world examples of use: Motion detection, Controlling lights using a smartphone or tablet, measuring temperature with bluetooth and even explores cloud implementation.

What I find most exciting is the chapter on hacking an existing commercial home automation device. I hope readers find the concept of hijacking existing products with their Arduino’s for their own benefit to be useful in other arenas outside of ‘home automation’ and I can definitely see the skills presented in this book being translated into future projects.

For those strictly interested in ‘home automation’, the book wraps things up with everything you need to build your very own custom solution from scratch – including 3D printed casings and custom PCB’s – which exposes the reader to invaluable skills they can use outside of the subject matter.

ishot-6
The book is well illustrated and documented with photography which is essential for learning. I would recommend this book to students and hobbyists who have experimented with a stand-alone Arduino but have yet to let their Arduino experiment with the world around them.

Book Review: Internet of Things with Arduino Yun

Categories Interaction, Open-source, Programming, Technology

Internet of Things with the Arduino Yun

Internet of Things with the Arduino Yun is a well-paced practical introduction to creating and exploring DIY smart devices. Or, as the book phrases it; “projects to help you build a world of smarter things”.

Each example project explores a specific real-world scenario similar to that of existing applications of Internet of Things (IoT) technologies within industry. Each example also exposes the reader to concepts and techniques that should be easily transferrable to many other projects and applications. Covering the subjects of sensing, data collection, automation and long-term presence, the book gives readers a good overview of the broad concerns that need to be considered when designing smart devices.

Power Consumption Data

An example of the kind of data readers might
gather about objects and habits within their home

 

Impressively, the book doesn’t require a great deal of prior knowledge to navigate, though some interest in coding and electronics is of course necessary. Those already familiar with Arduino will benefit from the exploration of the networking aspects of Arduino Yun as they are a bit different to control than what one might be used to with prior versions of the Arduino. The book would make a great companion for those unboxing an Arduino Yun for the first time.

Using Xbee with Arduino Yún

Categories Interaction, Open-source, Programming, Technology

Came across an issue today when upgrading a project I’m currently working on to make use of an Xbee + Arduino Yún stack instead of an Xbee + Arduino Uno stack and found that the solution wasn’t very apparent online. I thought I’d post a short writeup here. Special thanks to Bo for solving this issue.

Firstly, the Yún is amazing in that is has built-in WiFi capabilities, but this also means a few peculiarities with the serial due to the split architecture. If you are trying to use an Xbee with a shield, you will need to make a few modifications to both hardware and code in order to get it working.

Firstly, we cannot use the normal serial communication pins (0,1) and instead need to use alternative pins. I assumed I could use the SoftwareSerial library to allocate another set of pins (for example 10, 11) however for reasons I still don’t fully understand this doesn’t work either.

The solution was suggested by cmaglie in this thread to use AltSoftwareSerial (download the library here). I had not heard of AltSoftwareSerial before, it is an emulated serial comm.

What you need to do is install the above library (read here if you have never done that before) and change your code to include the new serial method. The example code below will recieve packets from another device and print them to serial:

#include <XBee.h>
#include <AltSoftSerial.h>

XBee _xbee = XBee();
AltSoftSerial altSerial;

void setup()
{
  Serial.begin(9600);
  altSerial.begin(9600);
  _xbee.begin(altSerial);
}

void loop()
{
  value="";
  processXBeePackets();  
}

void processXBeePackets()
{
   _xbee.readPacket();
   if (_xbee.getResponse().isAvailable())
   {
      _xbee.getResponse().getZBRxResponse(rx);
      //Serial.println(rx.getDataLength());
      for(int i=0;i<rx.getDataLength();i++){
         value.concat(char(rx.getData(i)));
   }

   Serial.println(value);
   }
}

Then on the hardware side, you need to modify your Xbee shield (or if not using a shield, simply reroute your pin-out). This is as simple as bending out two header pins (we’ve used spacers) so that they don’t actually come into contact with their Arduino counterparts. So, pins 2 and 3 don’t connect to Arduino and we instead use some jumpers to reroute them to 5 and 13 respectively. See the images for reference:

Xbee shield working on Arduino Yun
Rerouting pin 3 > 5 and pin 2 > 13

 

sparkfun xbee shield header pins modified for serial with Yun
The header pins for 2 and 3 need to be bent so that they don’t interface with the arduino.

You should now be able to pass your Xbee communication data on to your Arduino Yún and then pass it on to a server or computer via WiFi.

Displaying webcam video on Raspberry Pi using pygame

Categories Open-source, Programming, RMIT, Visuals

Another small exploratory project related to my undergraduate Major Project had me trying to stream video onto a small 3.5″ TFT LCD display using a webcam connected to a Raspberry Pi mini computer.

 

Firstly, not all USB webcams work with the Raspberry Pi, so after trying randomly to find a working webcam I discovered this list of Raspberry Pi verified peripherals and bought myself a Logitech C100 for $20 on ebay.

Secondly, USB webcams seem to be horribly slow on the Raspberry Pi, pulling dodgy framerates at what might be <10fps at their full resolution (in my case 640×480 pixels). Originally, I was using the custom imgproc library (available here) but found that there was either a lack of simple documentation for extended functionality like scaling and so on, or that the library wasn’t built to perform those sorts of tasks. Eventually I settled upon using the pygame library (which you can get here). The documentation for pygame is thorough and easy to navigate, making troubleshooting and extension or exploration of the library very easy to do.

In order to combat the low framerate and because resolution is not a priority (for the purposes of the concept I will be testing) I decided to pull the webcam feed in at a much lower resolution (32×24 pixels) and then scale it up to full screen (640×480 pixels). I’m unsure if the webcam can actually pull the feed in at 32×24 pixels, I have to look into that – and perhaps some pixel dropping techniques.

I wrote the code, copied it over, connected the webcam to the Raspberry Pi and ran the following python script:

import sys
import pygame
import pygame.camera

pygame.init()
pygame.camera.init()

#create fullscreen display 640x480
screen = pygame.display.set_mode((640,480),0)

#find, open and start low-res camera
cam_list = pygame.camera.list_cameras()
webcam = pygame.camera.Camera(cam_list[0],(32,24))
webcam.start()

while True:
    #grab image, scale and blit to screen
    imagen = webcam.get_image()
    imagen = pygame.transform.scale(imagen,(640,480))
    screen.blit(imagen,(0,0))

    #draw all updates to display
    pygame.display.update()

    # check for quit events
    for event in pygame.event.get():
        if event.type == pygame.QUIT:
        webcam.stop()
        pygame.quit()
        sys.exit()

After a brief pause a pygame window pops up and the webcam feed is shown on the screen, scaled to fullscreen. The framerate is better than the full resolution webcam feed, but is still very slow by modern standards.

 

Drawing in Python using Arduino data via serial

Categories Open-source, Programming, Visuals

Following on from my previous post where I established serial communication between an Arduino and a Raspberry Pi, I needed to find out if I could store the data being sent from the Arduino in a variable on the Raspberry Pi and use it to alter some functions in a Python script.

I wrote up a piece of code that tries to read the data from the serial and use it to change the colour of a circle drawn in the center of a 640 x 480 pixel screen:

# Title: Arduino2RPiSerial
 #
 # Goal: to draw a circle based on colour values sent from the arduino
 #

import pygame
 import sys
 import serial

pygame.init()

#create a screen
 screen = pygame.display.set_mode((640,480))

#create colour
 redValue = 255
 fgColour = (redValue,0,0)
 bgColour = (0,0,255)

screen.fill(bgColour)

#serial(device,baud)
 ser = serial.Serial('/dev/ttyACM0',9600)

# LOOP
 while 1 :

#Update from serial
 redValue = ser.readline()
 #update colour value
 fgColour = (redValue,0,0)
 pygame.draw.circle(screen, fgColour, (320,240), 200, 0)
 pygame.display.update()
 pygame.time.delay(5)

# check for quit events
 for event in pygame.event.get():
 if event.type == pygame.QUIT:
 pygame.quit(); sys.exit();

Getting the Raspberry Pi to talk to Arduino

Categories Open-source, Programming

As part of an exploratory design project I am undertaking within my undergraduate Major Project, I needed to establish serial communication between a Raspberry Pi (a miniature, credit-card sized computer) and an Arduino Uno (an electronic prototyping board). I found that Raspberry Pi could both supply power and talk to the Arduino Uno via USB cable.

I also found that as a beginner in many aspects of Python programming, Linux commands and serial communication that much of the documentation on the internet seemed daunting, so I’ve made a very thorough documentation here to help anyone out who has the same amount or less of the starting knowledge that I had. Hopefully it can aid in the creation of more open-source Raspberry Pi / Arduino projects.

I based my efforts on the steps outlined here.

 

 

 

Arduino Uno, Raspberry Pi and Laptop.
Arduino Uno connected to the laptop, with  a Raspberry Pi bundled with it’s own 3.5″ LCD Screen running below.

 

Firstly, I needed to install pyserial onto my Raspberry Pi. I have no ethernet cable or Wi-Fi dongle connected to my Raspberry Pi and so I had to transfer the pyserial-2.6.tar file via a USB Flash drive. The file can be downloaded here.

After transferring the file to desktop (home/pi/desktop) and unzipping it’s contents to it’s own folder on the desktop (home/pi/desktop/pyserial-2.6) I opened up the LXterminal to execute the following commands:

cd /home/pi/desktop/pyserial-2.6

The cd command directs the terminal to a folder on the Raspberry Pi (in this case, the desktop), to give future commands a context of operation. Basically, the command tells the terminal where we are working from and where to look for any files called upon.

Next:

sudo python setup.py install

This command tells python to install pyserial. I hit enter and the terminal spat out line after line of output, completing the install process shortfly after.

From this point, the Raspberry Pi was ready for serial communication via the pyserial module.

I needed to find out what the device name for the Arduino Uno was on the Raspberry Pi so that I could reference it in the python shell when opening up serial communications. For this I used a command that lists the devices:

ls /dev/tty*

The ls command lists files within a directory, the second part ‘/dev/tty*’ is a filter. The use of the wildcard character ‘*’ means that we are looking for any files that begin with ‘/dev/tty’ and that end with any other combination of characters. I ran the command without the Arduino Uno connected and then again with the Arduino Uno connected so that I could see the difference between the two lists, and find out what it’s device name was.

 

 

 

Using ls /dev/tty* to display a list of devices
Using ls /dev/tty* to display a list of devices

 

It’s hard to see in the picture above because the 3.5″ TFT LCD screen has such a horrible resolution (and has a strange flickering colour issue) but in the second list positioned at 3 items from the bottom of the rightmost column, a file appeared that wasn’t present in the first list (/dev/ttyACM0). I made note of that file because I would need to reference it later.

Then, the code below needed to be uploaded to the Arduino Uno to generate a test signal:

//Code originally by simon monk (http://www.doctormonk.com/2012/04/raspberry-pi-and-arduino.html)
//Commented by Daniel Kerris

//This code makes use of the Arduino's built-in LED which is located on Pin 13
const int ledPin = 13;

 //This sets up the code and defines the baud rate as 9600 - it's important to use the same baud rate on the Raspberry Pi
 void setup()
 {
   pinMode(ledPin, OUTPUT);
   Serial.begin(9600);
 }

 //This part of the code loops continuously with a delay of 1000 milliseconds between each loop
 //It sends the message "Hello Pi" over and over again via USB
 void loop()
 {
   Serial.println("Hello Pi");

   //This section checks to see if the Raspberry Pi is talking back
   //and then makes a call to the flash() script which is define below
   if (Serial.available())
   {
      flash(Serial.read() - '0');
   }
   delay(1000);
 }

 //This flash() script takes the number that the Raspberry Pi has sent over via USB (stored in the variable n)
 //and uses it to determing how many times the LED should flash
 void flash(int n)
 {
   for (int i = 0; i < n; i++)
   {
     digitalWrite(ledPin, HIGH);
     delay(100);
     digitalWrite(ledPin, LOW);
     delay(100);
   }
 }

After the code was uploaded to the Arduino Uno, I connected it via USB to the Raspberry Pi. I could see that it was powered and that the code was working because the LED for Tx (serial communication) was flashing, showing that it was being used. The Raspberry Pi still needed some code to tell it to listen to the messages coming through the USB port.

I booted up the Raspberry Pi and opened up the application called IDLE, highlighted the Python Shell Window and entered the following commands, hitting enter after each line:

import serial
ser = serial.Serial('/dev/ttyACM0', 9600)

You’ll remember that ‘/dev/ttyACM0’ was the name of the Arduino that I had found out earlier. 9600 is the baud rate, which is set the same is in the Arduino code above.

Then:

while 1 :
     ser.readline()

The while statment is used to do a set of actions while a statement is true. In computer languages 1 and 0 are stand-ins for true and false or on and off. Basically, this line of code is saying that whilst 1 is equal to true (which is constantly) then do something. This creates a loop that executes itself until the program quits, just like the void loop() in the above Arduino code. The ser.readline() is telling our serial object ser that we want to execute the function readline() which reads from the serial device (‘/dev/ttyACM0′) that we established earlier.

I had to hit enter twice after the ser.readline() command to let Python know that I am finished writing commands within the while statement’s block (you can read more about code blocks here if you don’t understand).

 

 

Success!
Success!

 

Finally, the Raspberry Pi successfully read from the Arduino.

I couldn’t get return communication happening successfully, though luckily for me the project I am working on only requires one-way communication from Arduino Uno to Raspberry Pi and not the other way round. I’m going to be using the Arduino Uno to handle sensors and tangible controls as I am much more comfortable coding and prototyping in that environment. I will write code that analyses and packages the information from sensors and tangible controls and sends it via USB to the Raspberry Pi, which will handle all of the GUI and Sound output (which the Arduino would otherwise struggle to handle).

Swipe to lock-in

Categories Open-source, Technology

What follows is a slightly rambling stream of consciousness orbiting around the subjects of the patent system, technological development, the open-source community and user interfaces. The whole situation is far from simple, with benefits on all sides. I guess my thinking comes from a recognition of what I see as the inevitability of product transparency and how to curb that into economic growth. I’d love to hear other people’s thoughts on these subjects, so feel free to leave a comment or email me.

/ / /

 

We need to copy, right?

 

Ok.

 

The copyright and patent system can be a messy business – and I mean business in the literal term.

 

Right now, research and development teams are setting out like early colonialists to stake claim on ideas, theories and methodologies. This would be fine, if the driving factor for such activity was truly innovation – but I don’t believe that it is. Instead, we find patents being created and filed away with the manic fervour of an arms race. In fact, recently we’ve seen how this impacts the smartphone industry with the cases of Apple v. Samsung.

 

This means that the incentive for coining, describing and protecting an “original” idea, system or method has as much to do with the implementation or progression of a company’s own product or service as it does with crippling their financial opponent’s ability to progress. The implications of such a dynamic are that our technology suffers and it’s feature-set becomes porous – a collection of innovative features and stunted features, mutually exclusive between brands – or else is obfuscated for no reason other than to avoid legal penalties.

 

 

The oft talked about example is Apple’s ownership of “slide to unlock”, this is the reason Google Android’s lock screen is rendered as “swipe to unlock”. The distaste I have for the ownership of gestural actions in an interactive environment is doubly so when those gestural actions are informed by a borderline skeuomorphic interface. How is sliding a virtual slider to unlock a device a new, patentable idea? I was sliding my cassette player into operation from “sleep” to “stand-by” 10 years prior to the iPhone. I was sliding latches to unlock gates that were made by people long before I was even born. I realise that the iPhone created new territory, and that “unlocking” in that context is a slightly different concept to the gate I mentioned above, but the gesture must surely belong to a collective lexicon outside of ownership. At some point an idea is so integral – and I daresay basic – that to deem it only useable by a single company in a massive, emerging market sector is a flavour of lunacy that is detrimental to the progression of technology on the whole. The danger lies in this attitude being applied somewhere truly integral. How would our technology look if the rotating volume knob was patented? If one brand owned the push-button?

 

But then, perhaps my opinion is skewed by hindsight.

 

Imagine three children seated at a round table with a piece of paper in front of each of them. There are a box of crayons in the centre and each child has privilege to one colour that no other child can use – one child owns red, another blue and another yellow. All other colours are shared. The children then attempt to draw the same thing. The resulting drawing’s are all shit subpar for different reasons, probably stemming from an illogical lack of colour, respectively. Or maybe they all make innovative use of a limited pallette, in which case, touché imaginary children.

 

I don’t know anyone with blue skin. Damn patent system.

 

Everything you can do, I can do different

 

The work-around, of course, is subtle deviation or obfuscation or inversion or “different”. Which often leads to users being presented with what I can only describe as counter-interfaces. Counter-interfaces are equally devious.

 

 

The new WiiU Pro Controller and the Xbox Controller feature inverted button arrays creating two interfaces that directly clash in learned operation. Is this the result of trying to avoid legal hassle, or in trying to lock users in to their system through some sort of familiarity-loyalty?

 

What do I mean by familiarity-loyalty? A loyalty borne out of familiarity with a product’s idiosyncracies. But further than that, it refers to the idea of creating these idiosyncracies for the purpose of locking users in to your system. This is perhaps doubly apparent with video game consoles because they share mutual software in the form of video game titles. You can play the same game on multiple consoles, being forced to interact with each one differently only in a schematic sense. You still have all the same functions. You just have different buttons. Inevitably, your option of multiple consoles only exists in a theoretical world, because in reality you will only ever take the time to master and operate one of them. This doubtlessly helps to fuel fanboyism, and what brand would be complete without adversaries to go into consumer combat with?

 

I’m pretty sure every chainsaw I’ve ever operated had roughly the same interface. My loyalties are influenced by the quality of the chainsaw, not my reluctance to learn a new interface structure.

 

Take a moment to imagine what Nintendo would offer.

 

Ok, so the chainsaw scenario is probably an unfair example. I remember my first mobile phone, it was a Nokia 3310. In fact, my next three mobile phones after that were all Nokia models. Why? Because it was common knowledge that the GUI’s between their products varied minutely. I was free to choose any (Nokia) phone that I wanted with minimal hassle, but to deviate from their brand meant I would be met with a jarring user experience. My fourth device, a Samsung, provided me with just that – and a few embarrassing, unintentionally sent messages, given that the BACK and SEND buttons were reversed on my new device.

 

The interesting thing about this idea of familiarity-loyalty is that the opposite directive – attempting design convergence of your interface with that of your competitors – makes it easier for consumers to switch to your product, whilst at the same time making it easier for consumers to leave your customer-base.

 

Hide your source, hide your errors, hide your potentials

 

There’s a similar dichotomy between open and closed-source mentalities. The same sort of benefits at the expense of “control”. Closed-source means that you do not share your production methods – code, manufacturing details, CAD files and so on with the general public – meaning that competitors and DIY “makers” can’t replicate your product and modify it to suit their needs or material access or fuse it with new hardware. This seems like an obvious choice of conduct from a typical business perspective. Why would you give away information that you spent plenty of money and time on researching and developing?

 

The answer is this: Open information can lead to free, highly-dispersed, communal development. Open information and modification fuels product longevity.

 

Here’s the second answer: We’re going to steal the information anyway. We’re going to modify it anyway. We’re inquisitive creatures. We do it for fun.

 

Hammer Editor: An in-house production tool released to the community.

 

By allowing your users access to legitimate information regarding your product, marvelous things can happen. Companies are slowly starting to realise the potential benefits of letting users modify their products. When Microsoft first released the Kinect, they were of the anti-mod, anti-hack mindset. But in my opinion the hackers and modders and makers and academics were doing much more exciting things with the Kinect than Microsoft was. The mindset has definitely changed:

 

The enthusiasm we are seeing in the scientific community – specifically the research and academic communities – around potential applications of Kinect, is exciting to see… It’s an exciting time for Microsoft, our customers and partners as we explore the possibilities [Natural User Interfaces] has to offer and how we can make them a reality – Kinect for Xbox 360 is just a first step.

Steve Clayton, Microsoft Blog

 

It seems Microsoft realises that free research and development by minds outside their organisation, that are excited enough about the concepts they are exploring to explore them despite not being on their payroll is a good thing.

 

Videogame company Valve learnt this lesson long ago – they are a thriving example of how understanding your craft, your technology and your audience leads to healthy financial success. One of their most popular titles, Counter-Strike, was originally a community-made modification of one of their existing products. Valve knew early on of the advantage of community created content, releasing their in-house level editor Worldcraft (later Valve Hammer Editor) to the public. Basically, you release one product that spawns more products and relates to a wider audience or keeps your existing audience captive for a lot longer (people still play Counter-Strike 1.6, which is now ~10 years old). As long as you are still selling the seeds, who cares what the fruit is made into?

 

Don’t be afraid of the culture, leverage it, help create it

 

Again, it’s going to happen anyway.

 

Young kids at a “maker faire” (source: boingboing.net)