thisismyrobot

Python iRacing API client

2013-03-11T17:03:00.002+11:00

Some of you will already know that I am a massive fan of the racing simulator iRacing. I signed up to this "game" a couple of years ago and it's lead to the purchase of new computers, steering wheels and even a dedicated "racing seat".

What I've always wanted to do was build a basic motion rig for the game, something that at least would represent lateral acceleration to give me a better idea of my grip limits when driving. The first step towards this is parsing the telemetry from the game.

iRacing has a telemetry API that's solely documented in the manner of a demo client built from a pile of C code. Whilst I am certainly capable of programming in C, my preference is definitely my pet language, Python. Some brave souls have built clients in C#, but that isn't much better *

Aside from my own bias, Python is a really nice language to use as a new programmer, so developing this client should allow for more people to develop iRacing add-ons which can only be a good thing!

Anyway, I decided to build a Python implementation of a client for iRacing. The API uses a memory mapped file, something Python happily supports out of the box, as well as C data structures for all the high-frequency telemetry which I was able to parse using Python's struct module.

As I was secretly hoping, Python's dynamic-programming abilities allowed me to write a client in short order, using very little code.

The code's right here on GitHub. It's, honestly, quite rough-and-ready, but it works. Please do let me know if you have success or problems with it, I'll do my best to help out. I expect it'll be updated regularly, or whenever I find a bug...

You'll have to extend and modify it to work with your application, but that's half the fun - enjoy! :)

* Whilst I'm not a huge fan of C#, the in-line debugging/inspection functionality in Visual Studio was a god-send when applied it to the C# demo client.

My home audio streaming setup

2013-01-27T17:51:00.000+11:00

As a slightly different post I thought I'd share the details of my multi-room audio streaming setup.

There's nothing special about it, but it's a very simple and cheap system that actually works really well, allowing multiple sources and speakers (with simultaneous playback), across a range of hardware and operating systems. I'm not going to link to every app and provide installation guides, that's what Google's for :)

The components
PC 1

Role(s): Source + destination + media share
OS: Windows 7
Software: iTunes (source), Shairport4w (destination), Air Playit HD (media share)

PC 2

Role(s): Source + destination + media share
OS: Windows 7
Software: Airfoil (source), Shairport4w (destination), Air Playit HD (media share)

Raspberry Pi

Role(s): Destination
OS: Rasbian "wheezy"
Software: shairport

iPad 2

Role(s): Media share -> destination bridge
OS: iOS 6
Software: Air Playit HD

How it all works together
Ignoring the iPad and the Air Playit HD software for a moment, the rest of the system involves Apple AirPlay sources and destinations. To be honest, I'm not a huge fan of some of Apple's work, but in this case AirPlay was simply the "right tool for the job".

Looking at the PCs, iTunes on the first one "just works", sending audio to one or more (simultaneously) destinations without a problem. Airfoil on the second PC allows audio capture from running programs (eg VLC) and sends that out in the same manner as iTunes to one or more destinations. Both PCs then perform double-duty as destinations thanks to the excellent Shairport4w.

The Raspberry Pi acts purely as a lightweight destination, thanks to the installation of shairport. I've attached an external USB sound card which helps with the sound quality.

Separately to this, Air Playit HD allows the iPad to play music/video off either of the PCs - the software on the PCs shares chosen folders and there's a client on the iPad of course. Any played music can then by pushed (via the iPad's built-in AirPlay tool) to a single destination.

These components work really well together, and allow me to scale the system really easily in the future. I hope they give you a good idea or two - let me know your versions in the comments!

Hat tip
Lifehacker's articles on setting up a Raspberry Pi and AirPlay streaming from/to all sorts of devices.

Use a Kindle and Python as a clock/dashboard

2012-11-04T16:49:00.000+11:00

When the Kindle Wifi came out I snapped it up and it became the most used electronic device I've ever owned. Then the Kindle Touch came out and I got that too (by which point I was well on the way to becoming an Amazon fanboy...)

The only problem was that I couldn't actually read two Kindles at once.

Then I came across a post by Matthew Petroff - Kindle Weather Display. This sparked my curiosity and I decided to build a clock/dashboard with the Wifi - something that'd show things like number of unread emails, weather etc. This appealed to me as the Kindle has fantastic battery life, is silent, and the e-ink display is both large and invisible at night (when I really don't want to know the time). The goal was something I could glance at in the morning before going to work and ignore otherwise.

Initially I intended to go down the route of jailbreaking to display an image like Matthew did, but I didn't have any luck with that on my particular device. It then occurred to me that I could just use the built-in web-browser to display a self-updating page. The only blocker to this was stopping the screensaver from turning on, something I was able to work around. The browser chrome was not pretty, but also not a deal-breaker.

From then on it was all about building an appropriate web site, serving it (on my desktop, but it'll work on anything running Python) and pointing the Kindle's browser at the right URL. So far, I've managed to show the time (updated on the minute), the current temperature, today's forecast and today's agenda from my Google Calendar. There's nothing magical there and as the site can be displayed on any JS-aware web-browsing device I'm sharing this project on GitHub. It'll change a lot over time but hopefully there are some basics you can use in your own project.

Enjoy!

Update 05/11/2012: I've now added a count of unread emails in my Gmail inbox so head over to the GitHub repo if you're interested in that sort of functionality for your own project. I've also got server.py working on a Raspberry Pi without modification, and it's perfectly fast enough for my use.

Getting a Logitech C270 webcam working on a Raspberry Pi running Debian

2012-08-05T16:51:00.000+10:00

I thought it was about time I shared something after all the hours I've committed to Pi-hacking and the above title says it all. These instructions are very simple but should hopefully save you some trial-and-error.

Importantly, hat-tip to Insipid Ramblings and Hexxeh for their info and work that helped me get this far.

Firstly, I started with a slightly old version of Debian - namely the debian6-19-04-2012 image. Your results may vary depending on what version you use. I am also assuming that you have already installed the image and can successfully boot to the desktop.

So, here goes:

1. Add UVC support to the image
Download and run rpi-update as described here. This will update your image to include the initially-missing UVC support. Reboot as suggested.

2. Update your packages
sudo apt-get update
sudo apt-get upgrade

3. Install the guvcview webcam viewer
sudo apt-get install guvcview

4. Set up your permissions and enable the driver
sudo usermod -a -G video pi
sudo modprobe uvcvideo

Reboot the Pi.

5. Open up the cam (these are the settings that worked for me)
guvcview --size=544x288 --format=yuyv

Caveats
Well, you are almost done, there are a few things to keep in mind before you rush out to buy one of these webcams for your Pi.

Before you view the C270 you must disconnect your mouse*. I am not sure if this is problem specific to my install but if I don't the camera will either not connect or will drop out constantly. The error I saw was along the line of not having any "periodic" USB channels.
The resolution is low. Clicking on the above image will open it at full size (544x288). Trying resolutions above this didn't work.
The webcam "must" be connected before powering up the Pi. If not you need to run sudo rmmod uvcvideo and sudo modprobe uvcvideo before it will work.

Even with this caveats, this is better than nothing and step one towards my Pi-powered mobile robot.

Hopefully this how-to helps you out and if you have more luck than I using a mouse and/or higher resolutions please let me know in the comments.

* Now, "real" Linux people would say that you shouldn't be using one anyway, but when your goal is to use a webcam, it's somewhat inferred that you'd like to see the result in a mouse-equipped GUI :-)

Installing...

2012-07-21T18:00:00.001+10:00

Pi

2012-06-24T15:50:00.000+10:00

A small mobile testbed I'll be trying it out on. And a cat.

The Pi has landed.

A new Android app!

2012-04-15T12:28:00.000+10:00

Yes, I did say I wasn't going to write any more Android apps, but there's a really good reason this time :)

At work a couple of weeks ago two of my co-workers were inventorying a large quantity of stock that had just arrived. They were hoping to scan the barcodes for each item into a simple CSV file. Their first though was obviously "there's an app for that". Turns out there wasn't. There are hundreds of barcode-scanning and inventory apps available, but none that simple scanned to a CSV list of barcodes, then allowed that CSV data to be emailed/saved etc.

So yesterday, after 4 hours work, I can now say there is such an app. Stock Scanner isn't pretty, nor feature-packed, but it exactly fulfils the above requirement.

Stock Scanner is available in a limited-scans free version, or a very cheap paid version, on ~~the Android market~~ Google Play.

Bucket-brigading neural networks

2012-04-10T21:01:00.002+10:00

I've recently been playing around with some Python code to explore a hunch I've had for a couple of years: that you can train a feed-forward neural network by simply indicating whether a output in response to an input was "good" or "bad".

I'd always imagined that I would hook up a small robot with a embedded neural network, giving myself a remote control with a button like this:

The robot would rove around, and whenever it did something "bad" (e.g. ran into a wall that it should have registered on its sensors) I'd press the button and it would train itself using that "bad" input->output pairing - e.g. that "move forward" when the front sonar sensor is registering an obstruction is "bad". I could also have a "good" button if it did something like turn just before a wall, for instance, to reinforce the correct behaviours.

This appealed to me as it was also very similar to how I (attempt to) train our cat...

Yes, that is our cat. No, that was not a training session...

Anyway, I have migrated this hunch to the GitHub repository BadCat. It has taken a few twists and turns along the way, but I have been able to "train" some very elementary neural networks using a simple set of rules based on the original hunch. I ended up taking a few pointers out of genetic algorithms theory just for fun too.

The algorithm works in the following way:

Read the "sensors"
Apply sensor readings to a learning tool (neural network), get the output
Try out the output "in the real world"
If the result of trying out the output is "bad":

Slightly mutate the output
Goto 3 above

Train the network with the resultant (original or mutated) output

The mutation amount increases the longer the output is "bad", based on the assumption that the original output will be close to the desired already, but allowing the output to chance dramatically if the robot is stuck in a new situation. The "good" input->output pairs form part of a fixed length queue of recent memory that is used for regular training.

This approach is similar to the "bucket brigade" rule-reinforcement technique that can be used to train expert systems. It is also not dissimilar to reinforcement learning principles, except that the observation-action-reward mechanism is implicit instead of being explicit - the action is the output generated based on the observation and the weighting of the neural network and the reward (or penalty) is externally sourced and applied to the network only when needed.*

I am looking forward to trying this out a real mobile robot as soon as I can order my Pi and I will keep you up-to-date on how it turns out.

* Oh, and just to be clear, I am not a robotics or AI PHD student and this is not part of a proper academic research paper. It is very likely that what I am doing here has been done before so I make no claim to extraordinary originality or breakthrough genius - just consider this some musings and a pinch of free Python code :)

Some small Python scripts

2012-03-22T20:34:00.000+11:00

So ... that's not quite the "picture of a robot" I was intending to lead this post off with :-)

Strictly speaking, the 'R' in the image above represents a "robot" in the very simple mobile robot simulator that I just developed. RoboSim is written in Python and allows a developer to include a very rudimentary 2D simulator in their project - for instance to test a neural network or genetic algorithm. The robot can rotate on the spot in 45° increments as well as move forward and backwards. Maps are defined as simple nested lists, with internal "walls" defined for areas that cannot be traversed. The robot is fitted with two front bumper switches that are triggered depending on what the robot is pressed against. RoboSim is available on GitHub, and may receive the odd tweak here and there in the future although it has served its purpose in another project already.

My other project is probably going to keep me going for a little while longer, at least until my Raspberry Pi(s) arrive... The project was born out of a hope to combine a couple of them together for a seriously powerful mobile robot. I really wanted to use one for nothing but OpenCV video processing and another for navigation planning etc. What I really didn't want to do was to be constantly swapping between each Pi to upload new code as I tried out different ideas.

Then it occurred to me: wouldn't it be nice if I could just get one or more Pis to act as a "dumb" nodes to run arbitrary Python code provided it to it by a "master" Pi...

A couple of days programming later and the newly Github'd project, DisPy, does this. The README explains it better but essentially, instead of instantiating classes normally, I use a wrapper class to perform the instantiation. Behind the scenes the class' source code is copied over the network to a "node" machine, the class is instantiated on that node and all the local copy's methods and members are replaced by stubs that perform XML-RPC calls back to the "node".

The result is that method calls and member access happens transparently over XML-RPC, allowing for the runtime offloading of arbitrary code to one or many Pis (or anything else that can run Python).

The code is all contained in one module and has minimal dependencies, hopefully it works on other OS' but I haven't tested it on anything other than Ubuntu 11.10 yet. Please fork it, break it and have a play, I'd love your feedback on this one!

A few changes and an exciting future

2012-01-22T10:37:00.000+11:00

Tomorrow morning I will begin a new job and more importantly, a different direction in my career.

As you can tell from the history of this blog I have always had a passion for robotics and other embedded hardware systems. Graduating with a Bachelor of Computing, instead of Engineering, has obviously limited my job prospects in these more hardware-oriented fields. As a consequence, for the last five or so years I have been employed primarily as a web application developer with occasional forays into desktop application and embedded hardware development.

This all changed four weeks ago when I received an offer of employment at a local electricity generation business. I will taking on a role assisting with developing, administering and supporting their Energy Management System. This will involve working with complex hardware-oriented SCADA systems. I am extremely excited about this new role and the learning opportunities it will offer and I have decided it is time to adjust my non-employment priorities too.

These adjustments will have the greatest effect on my Android application development. I will still continue to bug-fix existing applications and I may even develop a few more new applications, but this will now be a low priority - a couple of hours a month. I've enjoyed working with this platform greatly but, frankly, I am not willing (with this new role) to put the time and effort in to turn this into a self-supporting business, and it doesn't make enough money to continue in a half-hearted manner.

The good news is that as a consequence of the above I intend to spend a lot more time on my embedded hardware/hobby-robotics projects. I've already been working on some as-yet undocumented projects and I would like to blog about these as they reach milestones and conclusions.

Thank you for indulging me in a personal post, I look forward to a picture of a robot leading my next one! :)

Video review of Sythe by content3300

2011-12-22T14:11:00.000+11:00

I just came across this video by the YouTube user content3300, showing Sythe in action. It appears to be an entry for a competition, but it shows all the features quiet well. Thanks content3300!

Distributed tournaments for the Google AI Challenge

2011-12-04T10:43:00.001+11:00

As I noted a couple of posts ago, I am taking part in the Google AI Challenge again this year (my entry). The challenge this year is Ants, a game which requires entries (agents) to control a number of ants in an environment made up of land, water, food and enemy ants.

The design of my agent is fairly simple and has a large number of parameters that are a adjustable (e.g. distance between an enemy ant and my base that is considered a "threat"). This made it a perfect candidate for trialling out some Genetic Algorithms (GA) theory to tune those parameters, as well as to evalute some algorithmic design decisions.

To start using GA one must generate an initial batch of solutions to the problem. This is currently in the form of 12 versions of my agent.

Once an initial set of solutions has been generated, the next step is the evaluation of the fitness of each solution. Each agent I design is a different "solution" to the problem of being the best agent - the best agent is the fittest.

I decided the simplest way to evaluate the fitness of each agent is for it to compete against other agents that I have made, and sample agents, in the standard game format that is used on the official servers.

As I have a number of laptops and computers, none of which super-powerful, I decided to try and make a distributed tournament system so that I could play as many games as possible to get the best idea of fitness - my setup is as follows.

Each machine is running Ubuntu 11.10, with Dropbox installed. The game's Dropbox folder contains the game engine, maps and all the agents that are currently being tested.

This allows for new agents to be added at any point and all machines to be immediately updated.

Each machine continuously:

Selects a random map
Selects a random set of agents to play on that map
Plays the game
Writes the score to a file based on it's host name - eg "log-ubuntubox.txt". These files are also in the Dropbox folder.

Any machine can run a shared script that aggregates the results from all log-*.txt files, computing the average points/game for each agent. This is used as the fitness.

Because I am using Python 2.7 (installed by default on Ubuntu 11.10) for the game engine, agents and extra scripting the provisioning of a new machine is this simple:

Install Ubuntu
Install Dropbox
Run "python play.py"

So far this is working quiet well with quiet dramatic and unexpected performance differences between some nearly identical agents. Once each agent has played at least 30 games I will remove some of the lowest scoring agents and add some new versions based on combining the traits that are the most successful.

With any luck this should result in a pretty competitive entry in this year's Challenge - I will keep you posted!

Milestones

2011-12-01T20:57:00.001+11:00

I just had a look at my Market stats and I've just hit a couple of milestones:

More than 100 ratings of Sythe Free (average 4.3/5)
More than 10,000 active users of Sythe Free
More than 25,000 downloads of Sythe Free

If only the paid version was going so well... :-)

Sythe update released

2011-11-30T20:48:00.000+11:00

Just a quick one - I've just released an update to Sythe to fix:

Never-ending playback after closing Sythe
Incorrect step between octaves
Incorrect octave start/finish
Mis-match between note and frequency when switching modes

Thanks for the patience with this one guys, I've gotten totally bogged down in the 2011 Google AI Challenge (a greater time-sink than Skyrim...)

Sythe 1.3 is now available on the Android Market for free or very, very cheap.

Sneak peek

2011-10-06T20:47:00.000+11:00

You are looking at the main screen of an early version of my next app - a high-quality drum synthesiser. Currently it mixes 3 sine-wave sources with independent frequencies, amplitudes and ADSR envelopes.

Oh, and yes, it'll use my minimalist red-on-black UI again :-)

Warm fuzzy feelings

2011-09-24T10:22:00.000+10:00

As I mentioned a little while ago, my last update to Sythe was released into two apps - one free and one for the lowest price available in each currency.

With the exception of their names, the difference between these two apps is zero. I didn't even employ any tricky marketing; both apps openly refer to each other and both clearly state that they are the same app.

And you know what, people have bought the paid version!

Thanks guys, you've re-inspired me and I am already working on some new Android apps - watch this space...

Sythe 1.2 released!

2011-09-10T14:33:00.000+10:00

Sythe 1.2 has been released onto the Android Market. This release brings:

A 3-octave "Grid" mode
Faster and more refined user interface
Some German localisation

Get it from the Market for free or if you'd like to support my work you can buy it for the cheapest price allowed in your currency.

Thank you for all the feedback you've given me so far, I will continue to integrate your ideas into Sythe as long as you give them to me!

Hiatus, features and a thank you

2011-07-29T20:39:00.000+10:00

Well, that was a longer "week or so" than I initially expected. The short version is that since my last post my partner and I became home-owners (Yay!) and I simply didn't have the time to push out a serious update to Sythe. I also found a number of problems with the new UI - something that will be left on the back-burner for a little while.

The good news is I can now show you screenshots of some new functionality:

Firstly, I have added an toggleable Pad note grid that you can lock the synth to, with the input screen able to show a one or two octave span. The X/Y marker can still move freely but the current note is highlighted on the grid.

I have also added a Pad "Tilt" mode (toggled via the "+" button) where you can control the pitch and Sine/Saw mix by tilting the phone left, right, forwards and backwards. This allows you to change other parameters while still controlling the Pad behind the scenes.

The addition of this grid was suggested by a number of reviewers on Sythe's market page and I would like to take this opportunity to thank everyone who has given me feedback on Sythe so far. Your feedback has been both positive and filled with excellent feature suggestions.

These features will hit the market shortly, along with some internationalisation, reliability updates and background playback.

Sneak peak of the new Sythe UI

2011-04-29T18:19:00.000+10:00

I didn't mention this in my last post on Sythe's future because it was only an idea then, but the new UI has progressed far quicker than expected so here is a sneak-peak:

Click for a larger, clearer version

The design will evolve of course, but this is the general idea. The new UI will make its way into the next update, coming within then next week or so I hope!

What's next for Sythe

2011-04-22T13:18:00.001+10:00

Just a quick update on what's coming out with the next version of Sythe Free:

German Localisation - Germany makes up 10% of my active users and is the largest non-English user-base.
Background Playback - so you can use multiple applications at once.
Higher reliability - I've removed a ton of unhelpfully-buggy code, and thanks to the help of one of this blog's followers, dcp, I think I've fixed a rather nasty glitch sound that's triggerable by a certain combination of inputs. Thanks, dcp!

The rest of my energy has been going into developing the first release of the full version of Sythe - so far I have implemented about 30% of the record-loop functionality. The good news is that I have the next 10 days off work so it shouldn't be too far away!

Milestones

2011-04-11T21:06:00.000+10:00

Just a quick update - here are some milestones I have reached in the last week:

Downloads of Beat Dialer Lite: 6000
Downloads of Beat Dialer full: 100
Downloads of Sythe Free: 800
Active installs of Sythe Free: 500
5-star ratings of Sythe Free: 5

Sythe Free is the highest rated app that I have released with 4 stars average from 13 ratings - I must be doing something right! :)

Sythe update released

2011-04-03T14:51:00.000+10:00

The main input screen, showing the two new buttons

Turning on the "loop" button allows you to try out the effects in real-time

I've just released a new version of Sythe Free - the main changes are the addition of a button to keep the sound on whilst you are changing settings as well as the movement of the settings button from the menu to the main screen. Behind the scenes there are a few tiny tweaks to improve the synthesiser's performance.

As before, Sythe Free is available on the Android Market right now!

Managing multiple versions of an Android app

2011-03-20T11:26:00.000+11:00

When developing an Android app you may find yourself in a situation where you want to publish two different versions - one basic version that is free and a fully-featured version that isn't.

The free version is the marketing "hook" to get people to buy your full version - this is the tactic I am taking with Sythe, and that I took with Beat Dialer.

The obvious problem is that you end up with two codebases that undoubtedly share the vast majority of their code - requiring error-prone double-entry of any changes to common code. Here is the technique I am using to help mitigate the effects of this problem.

Firstly - this is what you'll probably have in your Eclipse Package Explorer:


Two identical hierarchies of code, the differences between versions limited to a few files in the "src" directory.

The key thing here is that I have broken the code up into "common" and "tests" packages, separate from the main "free" or "full" packages. In the filesystem these packages are different folders - allowing me to use Symlinked folders to share the "common" and "tests" code between the two projects:

I've also Symlinked the "drawable-*" folders in "res"

Whilst I obviously still have to test each project after an update, I no longer have to re-enter the same code in each - a major reducer of errors.

I how this helps you out with you projects - let me know if you have any suggestions for working with cross-project share code.

Free Sythe beta released

2011-03-19T18:48:00.000+11:00

The title says it all - I've released a free version of Sythe to the Android Market - please try it out and let me know what you think.

The forthcoming paid version will have extra exciting features like sequencing and background playback, so stay tuned!

Sythe sequencer layout

2011-03-13T14:30:00.000+11:00

Here's a sneak preview of the in-progress sequencer's integration into Sythe:

The idea being that you can have a different setting for each parameter for each step in the sequencer - crossed-fingers that that's how it turns out!