Playing around with the GoPiGo

The GoPiGo has been fun to work with as a platform for building robotic cars. In my usage, I started out with the base kit along with an older Raspberry Pi, and then gradually started to add pieces. I installed the wifi adapter (newer RPIs have wifi built in) for remote control, and the camera module for vision. A micro servo acts like a little arm on the side, and an ultrasonic distance sensor allows for obstacle avoidance. I even ended up including a foam dart launcher as well as a dancing water speaker for some audio with neat visual feedback.

GoPiGo spinning

Although the GoPiGo comes with a battery pack capable of delivering up to 12 volts, I decided to also add a USB based 5200mAh battery pack to help power the 5 volt accessories. With a wide variety of project ideas, access to forums, and the pluggable nature of open source hardware and software, the GoPiGo makes for a fantastic learning environment.

Construx test platform

Code examples are provided in languages like C#, Java, Python, Scratch, and NodeJS. Wheel testing was difficult in the beginning, but I was assisted by the help of my children when they built a test driving platform out of Construx. This kept the rig in place while walking the contraption through its exercises.

Below, you’ll find some video I took while playing with it. There’s also a screencast of the camera and distance sensor testing.

PowerShell for OS X and Linux

Microsoft released PowerShell for OS X and Linux. I tried a simple hello world on Ubuntu 16.04, and it seems to be getting that far. What interesting times we are living in the tech world. I hear that “Microsoft โ™ฅ Linux.” ๐Ÿ™‚

#!/usr/bin/env powershell

Write-Host "`nHello, World! `n"
$ ./hello-world.ps1 

Hello, World! 


Pi Motion

I’ve been wanting to return to the motion detection setups I’ve created in the past [1, 2] on the Raspberry Pi, and update them a bit using some more recent development approaches. For example, before I used Wiring Pi’s gpio utility in a bash script and displayed the results in generated pages using PHP’s built-in web server.

In this setup I am using the very capable Cylon.js framework for the server-sent events API and for controlling the PIR sensor with the hardware button. SQLite takes up duties for storing data in the database, while Node.js and Express run the server side portion of the web application. Polymer, Web Components, and some custom design are utilized for the front end side of things.

Here are the hardware parts used:

I used moldable wiring on the breadboard attempting to keep it clean and portable. The wiring that is connected to the GPIO pins on the Raspberry Pi is encased in clear heatshrink and is made into a sort of plug.

After everything is setup on the hardware end, the software side is setup.

Install Dependencies:

#!/usr/bin/env bash

cd /opt
sudo curl -O
sudo tar -xzpvf iojs-v2.0.1-linux-armv7l.tar.gz
sudo ln -s /opt/iojs-v2.0.1-linux-armv7l/bin/node /usr/local/bin/node
sudo ln -s /opt/iojs-v2.0.1-linux-armv7l/bin/npm /usr/local/bin/npm

Install Pi-motion:

#!/usr/bin/env bash

cd ~
git clone
cd pi-motion

Run unit tests, and see a coverage report:

#!/usr/bin/env bash

bin/gulp test
bin/gulp test-coverage

Check out the config file and change the options to access the web application from another browser (TV, phone, etc.). Next, serve the web app and cylon wiring app:

#!/usr/bin/env bash

bin/gulp serve

With just the defaults set, open a browser on the Pi, and go to https://localhost:3000 to view the Robeaux dashboard that is built into the Cylon.js framework (be sure to allow the browser to view the content behind the self signed certificate). Then browse to http://localhost to view the web application.

The main task runner installed is gulp and it exposes several pre-configured tasks such as:

  • serve (to start the Cylon.js and Express code)
  • init-database (to initialize a brand new database)
  • compile-js (to compile the front end code using webpack)
  • test (to run the mocha unit tests)
  • test-coverage (to get a unit test coverage report using istanbul)
  • lint (to lint the JavaScript using jshint)

Once everything is setup and running the user can activate the PIR sensor. To do this in hardware, press the button on the breadboard. Using software, touch the hamburger menu, touch the “PIR Sensor” menu item, and then touch the “Toggle” button under the sensor indicator (large red circle).

After a forty second warm up time the PIR sensor will begin sensing movement. When it activates, the sensor indicator will turn green and the movement data will be logged to the SQLite database.

To view the saved data touch the hamburger menu, touch the “Charts” menu item, select an appropriate time range (by hour), and then touch the “Update Chart” button.

HipChat bot on AWS

Over the last year or so I’ve spent some time testing out Amazon Web Services. While at first the myriad of options seemed a bit overwhelming, once I figured out what I wanted, it was fairly easy to navigate and manage the setup. In particular I used Elastic Compute Cloud with a Debian Wheezy image and stuck to the AWS Free Tier. This setup allowed me to run a t2.micro instance of Linux continuously (only rebooting it for necessary software updates) with the following basic specs:

  • CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
  • RAM: A little over 512 MB
  • Architecture: x86_64

I was a little concerned while I used it that I would push the system out of the free territory, but was pleasantly surprised to not see any charges to my account. The first few months were spent getting familiar with what AWS was all about, and the next few on hosting a few NodeJS ideas.

The best test application I setup for it (and what I finished the free period with) was one based on good ol’ trusty PHP and the HipChat v2 API. As it turns out I haven’t been using an RSS reader in awhile (thanks Google) but still enjoy reading news. Instead of hitting a bunch of different pages to check and see the latest, I figured I would write a simple bot to collect the data for me and message a room in HipChat with the contents.

The project is called NewsToChat and installation was straightfoward:

  • On the HipChat profile page:
    • Create an OAuthAPI token
  • On the AWS instance:

The basic idea is that there are scripts setup to run in cron, and are mapped to the commands available in NewsToChat. These are:

  • pullnews
    • uses a few classes to pull from and format the identified news sources
    • makes a basic attempt to de-duplicate what was found
    • uses a database service to store the data
  • pushnews
    • push one article to the identified chat target
    • marks the article as expired
  • maintenance
    • perform maintenance on the pool of news articles in the database

For the little experiment I was running, I pushed the first article I gathered into the HipChat room on September 6th, 2014 and the last on December 16th, 2014. In all, a little over sixty thousand news items were gathered, providing more than enough content to publish about every five minutes.

It was extremely simplistic, but could have easily been expanded to behave more like an appropriate chat room bot. For instance, had I spent the time on it, it would have been nice for the bot to support user specific preferences and listen to commands from the chat room.

Shortly after the free period expired, I let it run for awhile to see how much it would cost me. Turns out, it was about 0.47 USD per day. Not bad. Less than the cost of a newspaper. ๐Ÿ™‚

Portable Development Environments

I have been enjoying setting up and utilizing my development environments these days. Though that may sound odd to some, it has been that way as I’ve been able to isolate them from my main system, allow them to be cross-platform, and easily reproduce them on other hosts. The most efficient way I’ve found to do this up until now is by utilizing Vagrant. While most of my work has been based on a mixture of Puppet and Bash shell script provisioning, I’m looking forward to utilizing Docker at some point in the future.

Here are some of the ones I have developed:

By no means should they be considered a complete development environment, or ready for all projects that are based on what is in the title. They should be a starting point for future work and something to build upon. Additionally they’ve been great for learning a little more about automation. Any comments, ideas, or applicable pull requests are much appreciated.

For the most part, the workflow goes like this for initially launching the development environment:

  • Clone the repository and start the virtual machine. The first time will take awhile to boot and subsequent ones will be much quicker. In this example I’m showing the nodejs branch:
$ git clone development
$ cd development
$ git checkout nodejs
$ bin/vm start
  • To turn off the virtual machine:
$ bin/vm stop
  • To login to the virtual machine:
$ bin/vm ssh

2048 on a Touchscreen Raspberry Pi

As I was checking out the latest accessories for the Raspberry Pi, I stumbled across this nice little shield at Adafruit: PiTFT Mini Kit – 320×240 2.8″ TFT+Touchscreen. Several days went by before I was certain I had to have it, and when it eventually arrived, I was not disappointed.


To start, I followed the excellent setup guide, which went from the soldering (hint: use thin solder and a pointed tip) and software setup all the way to instructions on the display calibration. Before, during, and after verifying that everything was working, I kept wondering about all the things I could make with this thing. What I ended up landing on was building a portable 2048 gaming system. ๐Ÿ™‚

So, I began to do some research on how exactly I was going to control 2048 itself. At first I wasn’t sure whether I wanted to use a keyboard like peripheral to simulate the arrow keys, wire up buttons for use with RPi.GPIO / WiringPi, or to look into using swipe events.

Also I reasoned, since I didn’t plan on writing the game from scratch, running the original seemed ideal as it works in a plain ol’ web browser. And if that didn’t pan out, I would resort to booting it in command line mode, as there are a variety of C, Python, and Bash ports. Obviously there are other ways to approach this, especially if I were to be developing the game for market, but I was looking at it as a minimum viable prototype project (MVPPรขโ€žยข). j/k

For the command line forks, the simplest way seemed to be a method involving launching the application, and then sending keystrokes such as ‘w’, ‘a’, ‘s’, or ‘d’ to /dev/tty1 using a small C utility:


#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>

#define O_WRONLY   0x0001
#define O_NONBLOCK 0x2000

int main(void)
  int hTTY = open("/dev/tty1", O_WRONLY|O_NONBLOCK);
  ioctl(hTTY, TIOCSTI, "b");
  return 0;

Another idea that came up was to start a tmux session and send keystrokes through it:

tmux send-keys -t SESSIONNAME Down
tmux send-keys -t SESSIONNAME Up

However, as much as I like the command line, for this project I wanted to avoid it for the UI. I also wondered how I would control it within X? The original 2048 didn’t seem to support using a mouse, or the touch screen from Adafruit, so I looked at utilizing XAUT or xdotool so that I could script out a solution that would be triggered from a button press.

Didn’t want to do any of those either. I did arrive at this solution though:

  • auto login to Linux without a password by modifying /etc/inittab:
    • look for a line like this: 1:2345:respawn:/sbin/getty --noclear 38400 tty1
    • change it to something like this: 1:2345:respawn:/sbin/getty --autologin {USERNAME} --noclear 38400 tty1
  • auto start LXDE
  • auto start Midori in fullscreen
  • and then make sure the default home page is set to the modified 2048.

The main difference from the original is that I have the app zoomed to 90%, and I swapped out the original touch event setup with one based on Hammer.js. This was done only to work with the touch screen and the events provided by Midori when swiping in various directions on the game board.

The only other functionality provided in the project is a listener script running in the background that is started from /etc/rc.local on bootup:

#!/usr/bin/env bash

#wiring pi pin 4 maps to gpio-23
/usr/local/bin/gpio mode 4 up

while true; do
  sleep .5
  if [ `/usr/local/bin/gpio read 4` -lt 1 ]; then
    sudo poweroff

This is to allow for a poweroff event to be sent to the Raspberry Pi, so that when I am done playing the game, I can get the unit to turn off without using a keyboard. Then, I power off the battery pack using a stylus on the underside of the unit.

Parts used:

Watch a video of it booting, a little game play, and the shutdown sequence here:

Checking out Bolt

Recently I was able to spend some time with Bolt, “a tool for Content Management, which strives to be as simple and straightforward as possible.”

Actually, It was very straightforward, as I only had to:

  • Clone the project from GitHub
  • Get Composer and install
  • Tweak my existing Nginx configuration
  • Export the entries from this installation of WordPress into XML
  • Enable the ImportWXR extension, and import the entries into the new Bolt database
  • And finally, tweak a few configs and Twig templates

Below you can see the entries and menu items from this blog (screenshots are from Firefox Mobile):

Tracking with Tasker

After finding Tasker for Android and realizing all of the potential it has, I had to try it out. To begin, I decided to build a prototype backend service for receiving the location signals sent from the app itself. The possibilities seemed endless. As the website states:

Tasker is an application for Android which performs tasks (sets of actions) based on contexts (application, time, date, location, event, gesture) in user-defined profiles or in clickable or timer home screen widgets.

What I came up with isn’t nearly as robust as something like Android Device Manager or services like Google+ location sharing, but it did allow me to think through the ins and outs of implementing products like these. The project requires:

  • Tasker
  • A web server that can run PHP 5.4 code
  • A terminal that can run PHP CLI 5.4 code

The sending portion involves thoroughly understanding the location intricacies of Tasker, and a basic idea of how it works. I configured it as shown in the following images:

The receiving portion is setup by checking out and building the git repository, as well as configuring hosting for public/index.php.

 git clone
 cd tracking/

If everything is in place properly when Tasker posts to the service, the data can be stored in an sqlite database or a simple log file.


The final piece is to generate the output from the data stored. When tracker.php is executed on the command line, the help page is displayed showing the available arguments.

$ ./tracker.php 
Tracker version .001

  [options] command [arguments]

  --help           -h Display this help message.
  --quiet          -q Do not output any message.
  --verbose        -v|vv|vvv Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
  --version        -V Display this application version.
  --ansi              Force ANSI output.
  --no-ansi           Disable ANSI output.
  --no-interaction -n Do not ask any interactive question.

Available commands:
  help   Displays help for a command
  list   Lists commands
  map    Generate a Google static map URL.

In this version, the main command “map” parses through the included demo log file and returns a URL for a static map from Google, with location points marked.

$ ./tracker.php map -l logs/YYYY-MM-DD_post_capture_DOT_log
The Bermuda Triangle
The Bermuda Triangle

Controlling a Lego motor with the Raspberry Pi

Raspberry Pi and Gertboard controlling a 4.5v Lego motor #6216mWhen the Gertboard originally came out, it was a do it yourself kit that required soldering, and it had enough pieces that made me want to wait until one was offered pre-assembled (you can still get one like the original from Tandy called the Multiface Kit). After purchasing the latest version, I tried putting one of the Lego motors we have around the house through its paces. Using one of the older models (4.5v Lego motor #6216m) and learning from the examples in the Python Gertboard Suite made crafting my own setup surprisingly easy.

The main steps were to code a motor controlling script in Python (see, and demo it in Bash (see I find tinkering around with these components immensely rewarding while exploring topics like the Internet of Things. This type of exploration will only get easier as time goes on, for example, I just noticed today that Gert van Loo created something called the Gertduino. It is similar to the original product, but much smaller and easier to use. What kind of fun projects could be implemented with even smaller kit like TinyDuino or Intel Edison? I do like sticking with the Pi for now, so I dug up a list of compatible shields for your perusal (or browse an even larger list of expansion boards @

Also, check out the video to get an idea on how the Lego motor and scripts ended up working out:

echo -e "Turning the lego motor right for five seconds...n"
sudo python ~/ right &
sleep 5
sudo kill -INT $pid

echo -e "nSleeping for three seconds to let the motor wind downn"
sleep 3

echo -e "Turning the lego motor left for five seconds...n"
sudo python ~/ left &
sleep 5
sudo kill -INT $pid

#!/usr/bin/env python
import RPi.GPIO as GPIO
import collections, signal, sys
from time import sleep

# get command line agruments
arg_names = ['command', 'direction']
args      = dict(zip(arg_names, sys.argv))
arg_list  = collections.namedtuple('arg_list', arg_names)
args      = arg_list(*(args.get(arg, None) for arg in arg_names))

# set initial values
step      = 1
mota      = 18
motb      = 17
left      = motb
right     = mota
reps      = 400
hertz     = 2000
freq      = (1 / float(hertz)) - 0.0003
ports     = [mota,motb]
percent   = 100

# function to run the motor
def run_motor(reps, pulse_width, port_num, period):
    for i in range(0, reps):
        GPIO.output(port_num, True)
        GPIO.output(port_num, False)

# trap SIGINT and provide a clean exit path
def signal_handler(signal, frame):
    GPIO.output(direction, False)

signal.signal(signal.SIGINT, signal_handler)


# initialize the ports being used
for port_num in ports:
    GPIO.setup(port_num, GPIO.OUT)
    print "setting up GPIO port:", port_num
    GPIO.output(port_num, False)

# determine direction or set a default
if args[1] == "left":
    direction = left
elif args[1] == "right":
    direction = right
    direction = right

# the main loop
while True:
    pulse_width = percent / float(100) * freq
    period      = freq - (freq * percent / float(100))
    run_motor(reps, pulse_width, direction, period)