The clock takes shape

The project has continued, held back a little by holidays and work, but we're reaching the end now.
The electronics are working so now I just have to make them more permanent and take away the prototyping breadboard. There's a simple calibration interface, so if there's a power cut and the clock needs to be reset back to its initial position I can do that with the press of a button. I still need to mount the buttons and a warning LED into the case.

However, a trial run today worked very well, and the app seems to be functioning perfectly.

A new project!

Finally! I am working on something fun.

I haven't posted on here in what seems forever, not because I haven't been tinkering, but because most of the things I have been making have just been schoolwork related. I haven't had a good personal project worthy of sharing.

But now I am making a Weasley Clock!

Some people have made working Weasley Clocks before, like this beautiful thing and This LED whatsit, but I wanted to have a go at making my own and solving the problem myself. I don't know how to make the intricate mechanical workings that would be needed for the multi-handed clock that shows the location of all family members, so mine is just going to have one hand and show my location.

The project is broken down like this:

1. Make a smartphone app that periodically sends location data to a central location, preferably a database under my control rather than Twitter or some such.
2. Write a program for a Raspberry Pi that monitors this database and retrieves the location.
3. Create a mechanical clock, controlled by the Pi, that turns hands to the correct location.

So far I have pretty much completed the first two steps. Step 1 was surprisingly tough. I have some experience making Android apps using the MIT App Inventor, but this has limitations. Specifically, I need my app to run constantly, in the background, checking location and sending out the data. App Inventor apps can't do this. You have to have the app open on the screen to function correctly, so that was no good.

I have only ever played with making proper Android apps once, and only got as far as the Hello World-style "My First App" on the developer site. This made me realise how painful it can be to get even a simple app up and running on a smartphone. I don't know if I was doing it wrong, but it seems that you need to jump through a lot of hoops to even get one button on a screen talking to another item. There's a complex system of messages being sent back and forth, called Intents, which I don't fully understand. I guess I could spend a bit longer looking into it, but I just wanted to get this thing working without spending the whole summer on it.

My app needed to be location-aware, so I needed to access the GPS functions of the phone. Google have integrated location services into their ecosystem, one feature of which is something called Geofencing. This sounds like exactly what I need. You set up a series of areas, by defining a location and a radius around it. This forms a "fence". Whenever the phone moves into or out of this fence, your app can be notified of it. Perfect! All I needed to do was declare "home", "work" and any other places I might like to appear on my clock and it should work. Except for some reason it didn't. I spent a day playing with this, but the notifications were very sporadic and unreliable.

In the end, I gave up this approach and looked around for other methods. I ended up going with Repeating Alarms. These can be set to go off at set intervals, and can trigger a process in your app. The app doesn't need to wake up the phone, or display anything. It can just do its job and go back to sleep until the next alarm.

The app checks the location, then works out the distance to each of a hard-coded set of places using this algorithm. For each location I have also stored a radius, representing the size of the area I consider being "home" or "work" etc. The program decides if you are in each area, then sends a single ID number to the central database, with 0  being "home", 1 being "work" etc. I decided to only send an ID number, rather than the exact location, for privacy reasons. The interface is almost non-existent, but I would eventually like to add the ability to customise the list of locations. This would not be used very often, as it has to match the set of locations physically printed on the clock, but it would be a nice feature. Then I could maybe make the app available to other people, once I have added some security features, so they could use it in their own projects.

So, Step 1 is done. It's running now and storing my location ID every 10 minutes. You can see it in its testing phase now at this page.

It will eventually require a password to access, but since I am only using index numbers the information is of little use to bad people.

Programming Step 2 was trivial. I made a small PHP web page on my own web server that creates an API for storing and retrieving the data in a number of ways. Then I wrote a Python program that retrieves the location. This is just 3 lines of code. Accessing web pages through Python is easy (are you listening, Android?)

Step 3 is the next challenge. I have to work out how to program a motor using the GPIO pins of the Raspberry Pi to turn to particular angles, accurately and reliably over time, then mount that in some sort of clock casing. I have bought a very cheap stepper motor, which I think will give me the accuracy I need, and I am now looking into how to set it up.

More details when I have them!

Predator & Prey

Some more Javascript and HTML5 tinkering. This time I have been experimenting with adding some more behaviours to my little ball objects. I started off by making them move around the screen randomly, and added a little bit of mouse-cursor avoidance.

Then I started looking into how to make them exhibit flocking behaviour, like a group of birds or fish. I was greatly helped by this article on the three main rules of simple flocking.

I started with some attraction principles, which makes these dots gradually draw towards each other.

Then I looked at making them try to keep a distance from their neighbours, so they tend to jostle for position. This looked very nice. I also added a behaviour to make them avoid the mouse cursor.

This last example should also work on tablets, as I have learned how to grab touch events as well as mouse events.

The end result is something that looks quite hypnotic, which is especially satisfying as it is based on such simple rules!

Little bit o' Javascript

I don't know much about Javascript. Embarassing, I know. I never got into it, even though it looks like lots of fun, and it has lots of advantages due to running on just about everything including tablets.
Anyway, I bought a book because I like learning from books instead of web sites. Don't get me wrong, sites like Codecademy have some nice challenges and reference sites like W3Schools are very useful for... reference, but there's nothing like a well written book to take you through a language and show you the ropes.

So, I've just been playing, and there's what I did this evening:

http://www.pagetworld.co.uk/js/test_dots.html

It's dead simple, but I wanted to see how easy it was to track mouse movement on a canvas and to use some Object Oriented stuff, including an array of objects. I learnt a bit in the process, which is always fun. Next thing I want to do is try a bit of flocking behaviour with randomly generated "birds".

Keep tinkering!

Python Powered SkyCam

A few days ago, I decided to have a play around with the Twitter API, to see if there was any fun to be had. Python has a few extensions that allow the user to post tweets and read timelines. They're all a bit fiddly, mind. I didn't have much luck with Tweepy, and I wasted some time playing with lots of different packages. In the end I went with this one.

Once that was all installed, I had to get authorisation from Twitter to access the API directly. To do this you need to visit their dev pages and create an application. (Log in at https://dev.twitter.com/apps)

When you do this, you get two important keys called a Consumer Key and a Consumer Secret. Your application uses these to log in and access your twitter account.

The code to log into your account and enable access is:

import os

from twitter import *

CONSUMER_KEY="YOUR KEY HERE"

CONSUMER_SECRET="YOUR SECRET HERE"

MY_TWITTER_CREDS = os.path.expanduser('~/.my_app_credentials')

if not os.path.exists(MY_TWITTER_CREDS):

    oauth_dance("YOUR APP NAME HERE", CONSUMER_KEY, CONSUMER_SECRET,MY_TWITTER_CREDS)

oauth_token, oauth_secret = read_token_file(MY_TWITTER_CREDS)

twitter = Twitter(auth=OAuth(oauth_token, oauth_secret, CONSUMER_KEY, CONSUMER_SECRET))

When you run this, it opens a web page in which you link the app to your Twitter account. This creates a small file on your computer which stores your login details. After that, you can start adding commands which send tweets, read other users' tweets etc. A bog-standard tweet command might be:

twitter.statuses.update(status="Hello World!")

And from there you can start all manner of bizarre auto-tweeting scripts! You can see such things on Twitter all the time, from the classically simple @big_ben_clock to funny and sarcastic meanie bots like these.

I thought I would make something unlike anything I had seen before, so I decided to combine the tweeting script with some of the stuff I had learned when playing with my webcam. Since I can grab a webcam image and analyse the pixels in it, I decided to write a twitter bot that looks out of my window and says what colour the sky is (see here!)

To do this, I needed this videocapture module, which grabs images from a webcam, and this Image processing library to analyse the images. My little script gets a picture from the webcam and crops it down so that it just contains sky (a rectangle of 540*200 pixels). It then samples one pixel in a hundred, and works out the average colour by adding together all the red components, green components and blue components, then dividing each by the number of pixels in the sample (1080, coincidentally).

When it has the RGB average, it does a quick denary-hex conversion to get a 6-character RGB string. Then it uses the handy webpage http://www.colorhexa.com/ to communicate that as a colour in a tweet.

So there you go. Pointless, but fun. It might get a bit repetitive after a while, but I think I might look into getting the program to detect things like sunrise and sunset. Also, I might see if I can get it to generate a colour-chart collage over time and save that as an image. I don't know how you can attach images to a tweet yet, but that would be better than relying on colorhexa.com.

Keep tinkering!


Update: It seems that TweetPony gives me access to an image-uploading API method. I should be able to create an image of the colour block and remove the use of the external website.

God and death

Version 1.9 is now in the source files folder. It was time for the enemies and the player to interact, so I have now added the code for collisions.

When you hit an enemy, if you are higher than the enemy, they die. If they are higher than you, you die. If you're at roughly the same altitude, you bounce off each other. Eventually, a dying enemy will turn into an egg that must be caught before it hatches into another enemy. At the moment you just disappear.

I have also added a God mode, to make testing easier. Press G to turn it on. When god is active, you cannot die. Also, you can prevent the enemies flapping by holding down 1. Take that, birdies!

Birds fly home to spawn

Just a small update here (Version 1.8, available by clicking the Source Files link top right).
I wanted the birds to spawn properly in their correct places, so I added a little routine for this. The birds Update method is getting a little messy. It might be time to start breaking it into smaller subroutines.

I also wanted to see what happens if you get loads of enemies, so I added a spawner routine which creates birds every few seconds. My old laptop can handle lots of birds, it seems.

Also, it turns out I'm quite pleased with the current flight pattern of the enemies. They seem to spread themselves around the screen quite nicely, so I'm not going to bother with the different flight algorithm for now.