Monthly Archives

8 Articles

Posted by on

Sammy the Boblebot Part 12: Look Who’s Talking!

What fun is a robot if it can’t communicate? I want Sammy to be able to talk back to me and my kids and tell us what he’s doing. That means a text-to-speech engine, and specifically Flite, the lightweight version of Festival. I’ve played around a little bit with this in the past but only to the extent of making computers say things in funny sci-fi voices. Now I want to put it to use.

My initial idea is that Sammy should speak the status messages I introduced throughout the Arduino code to tell me what was going on. That means pulling messages off the serial connection from Arduino to Raspberry Pi and having something then feed that serial data into Flite.

Python is the obvious language for doing this sort of work. It’s the most popular programming language for RPi and there’s loads of example code out there. Which is good, because I’ve never done anything in Python before in my life.

So first thing’s first, off I went to CodeAcademy to learn the basics. Then I started hunting around for snippets I could weld together to do what I wanted.

I found this, from the father of home hacking in the UK, Simon Monk, which told me how to pull data off the serial output from the Arduino and do something with it in Python. And I found this, which told me how to pass text out to Flite (or actually eSpeak, a Flite alternative*, but it was easily adapted).

Now this is very simple, and arguably pretty ugly — neither the most efficient nor the most secure way of doing things. I’m sure real coders would have something to say about me passing commands from Python to the command line, especially when I know there are wrappers for Flite inside Python (the bit I haven’t covered here is all the stuff I couldn’t get to work, including these). But, it works for now and it’s a starting point on which to build, so I’ve posted my Python file here, along with a little video. The video shows Sammy responding to inputs from his ultrasonic range sensor. When something gets within 30cm it triggers his proximity alarm and he reports how far away it is (if you’re too young for the reference, ‘Danger Will Robinson’ is from Lost in Space).

You’ll notice the little amplified speaker: this is an early car hands free kit I’ve been hanging on to for ages because I thought it might come in handy for things like this. I hacked the mic off (it was that primitive it had a mic over your phone’s speaker) and added a 3.5mm jack. And I stripped off the 12v plug — for now replaced with a taped on 9v battery but ultimately this will run off Sammy’s new 12v power supply in the new chassis. The PC is in shot simply because my portable power supply was exhausted so this was powering the RPi.

Next, and finally before I start focusing on the new chassis, I want to get serial commands going the other way so that I can control Sammy over Wi-Fi…

*Why did I choose Flite over eSpeak? No good reason at all — I’d just started down that route already.

Posted by on

Sammy the Boblebot Part 11: Raspberry Pi Brain Boost

So, as previously referenced I’m reaching the limits with my Arduino brain, at least in terms of pins available. And there are lots of things I’d like Sammy to be able to do that are a little beyond the humble Arduino. Like serve up a web page and video stream showing what he is doing, for example. Or talk.

So I took the plunge with some of my birthday money and bought a Raspberry Pi. On which note I must thank both of my wonderful aunties for contributing to my toy fund even though I’m 35. Much appreciated.

The connection diagram for Sammy now looks a little like this:

The RPi is contained in a £2 case off eBay (Adafruit designed, laser cut — simple and effective) and for now power is routed through it to the Arduino. The result is a lot of cables winding around all over the shop as you can see. When Sammy next evolves physically, this will change and I’ll cut some custom-length cables, as well as mounting everything properly. For now though, it works.

Running on the RPi is the standard Raspbian Wheezy image, plus a few little tools like the Arduino development environment and a VNC server for the regular occasions when my limited command line capabilities fail me. It’s all installed on a 4GB SD card.

Power is starting to look like the big issue: I now need to get a stable USB supply into the RPi on the move. This may involve me incorporating an old powered PC USB hub into the next body alongside a new Li-Ion rechargeable battery in order to both provide the RPi with power and share connectivity across more ports for things like a webcam. In the meantime, mobile power can be provided by my Duracell or Energenie portable power packs, two of the most valuable gadgets in my daily load-out.

So, it’s all hooked up, what to do with it first?

Posted by on

The Future of Moore’s Law

Apparently AMD sees the end of Moore’s Law approaching. While the law may cease to be true in the strictest sense, I believe like many futurists that the spirit of the law will continue.

Gordon Moore, co-founder of Intel, never intended to create a ‘law’ in his own name, he merely observed that the number of transistors on a silicon chip was doubling approximately every two years. This was way back in 1965, and the trend he had observed stretched back to 1958. Amazingly this statement became a ‘law’ because it remained true and continues to be so right up to the present day.

Now we are constructing chips with such tiny components — working on a process at 22 nanometres, the width of just 220 helium atoms — that we are coming up against the limits of the laws of physics. AMD is struggling to shrink its transistors to this scale and beyond, though its main competitor Intel seems confident it will get down to 14nm and even 10nm in the next few years. The slower transition to 22nm is effectively breaking Moore’s law, at least for AMD.

Eventually Moore’s Law was always going to expire. There are only so many transistors you can cram on to a chip however incredible your technology. But to understand the spirit of the law you have to go back to what Moore originally said: he wasn’t talking about what was technically feasible, but what was economically feasible. Now if you accept that transistor count used to be a reasonable analogue for computing power, what Moore’s Law really represents is that computing power per pound increases exponentially.

Of course the measure of computing cost is not only the unit’s acquisition: you need to consider its power consumption. This too though has been falling exponentially. We can now deliver more computing power per pound and per watt than ever before. Continuing the trend is a challenge but you only need to look at initiatives like HP’s Moonshot to see the gusto with which it is being attacked (think of Moonshot like Southampton’s Raspberry Pi ‘supercomputer’ on a grand scale). After all, no-one would bet against there being a big market in the future for the infrastructure behind all internet services.

Ultimately we will reach the outer limits of what can be achieved with silicon. Physicist Michio Kaku predicted some time ago that we will reach that limit by the middle of the next decade. Though this may slow our ability to increase absolute computing power for a short time, it is unlikely to diminish our ability to refine the production processes and hence further diminish the financial and energy cost of each unit. And beyond this there are a number of candidates on the horizon to replace today’s silicon chips.

Many people believe that Moore’s Law or its successors simply cannot continue: exponential growth would ultimately end up consuming everything in the pursuit of computing resource were it to continue. But some don’t rule out even this extreme future. In Charles Stross’ visionary novel Accelerando, humans (or our information-based descendants) begin to demolish whole planets and asteroids to support the manufacture of ever greater volumes of ‘computronium’ — smart matter — the substrate on which their pure-intelligence life form exists.

That today though is the stuff of science fiction, outside of the 20 year window in which I choose to operate. Suffice to say, within that time frame I certainly don’t expect the rate of growth of computing power per watt and per pound to diminish. And that exponential rate of change will remain the biggest change driver in western life.

Posted by on

Sammy the Boblebot Part 10: Android Orientation

Sammy was going to be a bit of part-time, long term project. But I’ve been having so much fun working on him that he has become a bit of an obsession. The result being that I’ve started working on the next few phases of his evolution. A new, bigger body, rechargeable Li-Ion battery pack, and a Raspberry Pi to provide a major brain upgrade and more features.

But first things first: I need to get the basics right. And that starts with being able to reliably move around in the desired direction. From day one I’ve had an issue getting Sammy to go in a straight line. The new chassis may solve this but it would never be ideal if I didn’t know for sure that the motion commands being input were being replicated in output.

I still think there’s scope in the optical mouse sensor for measuring distance travelled. But in terms of absolute direction I figured I’d try something else. Amarino is a tool kit for accessing the sensors built into any Android device via a Bluetooth serial connection. One of those sensors is a magnetic compass and three dimensional orientation sensor. So using Amarino I plan to get the data from these sensors and make use of them in my Arduino sketch.

First things first, I needed a Bluetooth module. I picked up a ‘JY-MCU’ unit for a few pounds from eBay, selecting one with the relevant connectors already soldered on, along with some voltage regulation. This may or may not mean it can work safely on the 5v signals supplied by the Arduino rather than the 3.3v I know the core circuitry prefers. There was no real documentation to say. But so far, so good.

I plugged the unit in to pins 9 and 10 on my Arduino — the two remaining spare pins on which PWM had been disabled by the Servo library. I could have used pins 0 and 1 but this would have prevented me using the serial port via the USB to communicate with the Raspberry Pi down the line. In order to use 9 and 10 for serial communications I had to use the SoftwareSerial library, and I also downloaded an example sketch to check it worked.

I then downloaded and launched Amarino on my Android phone — an Alcatel OneTouch 995 that the kind people at Alcatel let me hang on to after my review. This was my main phone for a few months after my previous iPhone was nicked and it is very capable for its price. It is certainly more than sufficient to run Amarino in order to provide Sammy with sensor data.

I set Amarino to feed out data from the magnetic compass and orientation sensors and then started up the sketch. I got junk. Then I set the baud rate down to 9600 and there it was: a nice long string of lovely data to play with.

What has struck me throughout the process of building Sammy has been how easy this stuff is. There are frustrating moments, sure, but in the space of an hour I just got a microcontroller wirelessly reading serial data from a bunch of sensors on a completely different computing platform. That sort of thing used to be HARD and now it is an hour’s work on my dining room table. The power of open source electronics plus a web of knowledge is great indeed. I have to say a big thank you to all the people out there who create and share their code — including the guy who wrote Amarino.

Of course now I actually have to make sense of the data. I tried doing this myself at first, scratch-writing a function to take the raw serial data and turn it into useful numeric variables that I can actually process. I started getting somewhere with this before realising I couldn’t be the first person to face this problem and returning to Google. There, staring me in the face on the Amarino website, albeit without a lot of documentation to support it, was the MeetAndroid library.

This solved half the problem: it provides the means to get data out of Amarino as useful integers. However it was designed for use with the hardware serial pins, when I wanted to use software serial. Fortunately a chap called Lewis has written a version for software serial that you can find on his blog here: Thank you Lewis. A little bit of tinkering with the examples from Lewis and Amarino and I quickly had the compass sensor returning nice little integers I can make use of. It shouldn’t be a huge leap from there to get the other sensor data back — such as the three dimensional orientation.

Next step is to actually use this data to keep Sammy on the straight and narrow, but that may form part of a complete code rewrite I’ve started, with a view to breaking all the pieces down more logically in a way that is easier to call from the Pi.

Posted by on

The Future of Microsoft

Today Microsoft moves the bulk of its customers over from Windows Messenger to Skype, the VoIP and messaging company it bought for $8.5bn. It shows just how times have changed for the technology giant that rather than integrating acquired technology into its own services, it’s moving its own 100 million active users over to an acquired service.

Why? There are many good reasons. First and foremost Skype has a better structured revenue model, generating income from a proportion of the 2bn+ minutes of voice calls it carries every day. Skype also has more active users and is growing, compared to the declining Windows product.

Finally there’s the issue of brand. Windows? Not sexy. Skype will become progressively more integrated into the Windows/Office environment over the coming months. But I find myself wondering: will anyone care?

Microsoft remains a major power — if not the major power — in PCs. For all the talk of the PC’s decline, they remain the best platform for much of our computing work. I’m writing this on a Windows 7 PC and very happy I am with it too. But I am no longer tied to Windows. And I’m no longer tied to Office. In the last two years I have jumped happily and easily between a Macbook, a Linux laptop, and a Windows desktop. Dropbox, Subversion, Google Drive, and InSync keep all my files available. Office, OpenOffice, AbiWord, and Google Docs allow me to edit them anywhere I need to with near-equal capability. Microsoft may still dominate the PC market but it no longer owns it. If I buy another PC (this one has lasted probably four or five years), I’m not convinced I’d pay for a Windows licence. I almost certainly won’t buy another copy of Office.

Where does this leave Microsoft? Clearly the loss of my custom won’t trouble the company too much. But it’s what it indicates that might: they no longer have a de facto role in the tech marketplace. And nothing they have tried to do in the recent past such as cloud services or tablets looks likely to earn them back that position.

You could argue that Microsoft has been playing catch-up for 20 years now. The company was late to the internet market, late to the mobile market, and late to the cloud. Its sheer scale makes agility tough and it hasn’t manoeuvred its juggernaut-like weight with sufficient foresight to be in the right places at the right times. What has sustained the company until now has been the incredible power of its market position, one gifted to it by a company in a similar position in the late 70s to the one Microsoft is in now: IBM.

Microsoft’s market position comes in part from Bill Gates’ early decision to licence MS-DOS to IBM for the first PC, rather than selling it outright. Instead of a few thousand dollars up front he chose a small licence payment with the same of each PC. IBM was happy with this because it didn’t have Gates’ confidence in the success the PC would prove to be.

IBM had handed development of the PC over to a little ‘skunkworks’ group within the company because developing something through the usual channels would have taken so long that new competitors like Apple would have established an even more significant lead in the burgeoning personal computer market. In other words, innovation had begun to stagnate inside the giant IBM.

This seems to be the situation facing Microsoft today. Even its biggest announcements around tablets and Windows Phone recently only seem to have brought it to a ‘me too’ position with its competitors. Because it is struggling to innovate it has to acquire companies like Skype. And whereas in the past it would have bought those companies for technology and people, now it buys them for brand and market position.

When tech companies hit this stage of maturity, the chequebook can only take them so far. Microsoft may still be strong today but it is waning. In order to check that decline the company needs to innovate again, not delivering products that match the competition but reinventing the market faster and better than Apple and Google.

To finish on a positive — and I would like to see Microsoft stay in the race — now is a really good time to make a new market. I’m strongly of the opinion that we have hit pretty much the zenith of smartphone and tablet capability, if not sales. I think there is a big form-factor shift coming, backed by an evolved set of cloud-based services. Microsoft is a company with a big cash pile and a load of clever people. It could yet find a product that keeps it at the top of tech for another 20 years.

Posted by on

Sammy Arduino Part 9: Bump and Grind

With the ultrasonic range sensor moving up to Sammy’s head it is no longer going to identify small obstacles on the floor. So I wanted to add a bump sensor to the front of his chassis. Here’s how I did it.

Reuse and Recycle

I’m running a little low on spare pins for the Arduino. I could put in a multiplexer, but actually the work I’ve already done offers a solution. The PS/2 optical mouse I’ve converted for position sensing also has three buttons and a click wheel. These are operated with three micro-switches and a rotary encoder. I only need the signal from one of these in order to detect bumps. All I need to do is de-solder the switches, package one up appropriately and relocate it to the front of the chassis. Then work out how to decode the signals coming back down the serial connection.


I used my prototyping material of choice — Meccano — to make the bump sensor. It’s effectively just two plates bolted together with rubber spacers in between.

In the gap created by the rubber spacers is a strip of Veroboard with two micro-switches mounted in parallel at either end. These are connected in the ‘push to make’ arrangement as they were on the mouse — a third pin allows them to be connected in ‘push to break’ configuration.

The Veroboard is connected back to the mouse with pin connectors and a cable from an old PC case. A slice of packing foam and some insulating tape gives the rather flexible Veroboard support and stops it from shorting on the Meccano.

On the front plate of the sensor is a couple of bumper bars that should add a little leverage, making for a very small impact required in order to trigger a signal.

Front and back are connected by just two nuts. Note that at the moment none of the nuts are locking: if Meccano is to be used in the long term I will need to order a job lot of little locknuts.


Once I had the sensor hooked up and had tested with breadboard and an LED that it actually worked, the next part was working out how to get the signal from the mouse. X and Y movements were provided in the example sketch that came with the PS/2 library, but I couldn’t find evidence anywhere of people making use of the byte of data that came back reporting the switches’ status. And I’’ll be frank: it took me a little while to nail this.

What comes back from the mouse via the library is a series of bits — 1s and 0s. The second one from the right was the one that I was interested in: I could quickly establish that this was the one that was set (1) when the sensor was triggered. The problem was that the string returned seemed to vary in length — from four to six bits — depending on what else was happening with the mouse. Clearly the other switches weren’t being triggered since they had been de-soldered. But I remember the mouse also sets a flag if it has moved more than the sensor can register in a single cycle. I think this was the data being added to the string in some circumstances. With a very limited knowledge of working with binary, it took me ages to work out how to isolate the bit that I wanted.

In the end the solution was simple. The string — actually a byte (eight bits) — wasn’t varying in length at all. It’s just that it never shows the bits to the left if they are all zero. So all I had to do was a bitwise A

ND with the byte I was receiving and the number 2. In binary, 2 is 00000010. Doing an AND operation with my data would automatically set all of the bits I wasn’t interested in to zero. If my bit was a 1, then it would remain a 1. If it was a zero, it would remain a zero. Now I could simply compare the result to 2: if it was the same, the sensor had been triggered. If it wasn’t, it hadn’t. Marvellous!

The code for this is buried in the latest update to my robo code below. Bear in mind that this code is now starting to get a little unwieldy and is ripe for a rewrite/restructure with some of it being parceled up into libraries. That can wait though, because my Bluetooth unit has arrived, and it’s time to give Sammy his own mobile phone…

Latest version of my robot code for Arduino to download>>

Posted by on

Sammy Arduino Part 8: Remake and Remodel

Following my last post about testing Sammy the Arduino-powered robot, I’ve done few of the things I actually planned. What I have done is make a bump sensor, and — the subject of this update — do some work on the chassis.

As I noted in the testing, I was having issues getting Sammy to go in a straight line. In an attempt to overcome this I have reversed the chassis so that the drive wheels are at the front and the castor is at the rear. This has the added benefit of centering the weight between the wheels, dramatically increasing stability.

I have also replaced the crap castor that was part of the original chassis with one on bearings that I found in my box of project stuff. This turns with very little friction in both axes and has a lot less grip on the wheel, so even if it does drag it shouldn’t prevent Sammy going in the intended direction.

I’ve moved the ultrasonic sensor up to the ‘head’ area rather than stranded on its own out front, given that there will soon be a bump sensor for low-down obstacles. And I’ve improved the mounting on top of the servo with screws in place of (some of the) cable ties.

The secondary battery pack for the Arduino has been moved to the middle of the body, further improving balance and weight distribution. And I have added an external USB port (hacked from an old PCI slot expansion) and an external power switch, meaning I no longer have to open Sammy’s case up for programming and debugging. With the addition of a USB extension cable this means I can sit at the computer tweaking while he runs around the floor.

Next then, the bump sensor.

Posted by on

The End of the Mobile Phone

Today is a slightly artificial anniversary of the mobile phone. One probably cooked up by Motorola’s PR team many years ago as it features Motorola employee Martin Cooper making the first call from an old DynaTac back in 1973. You could probably pick any number of test calls around that time, made by a number of different companies, as the real anniversary, but this story seems to have gained traction, leading me to appear on a few different radio shows commenting on how far we’ve come in the last 40 years.

So much as I recently did for Twitter on its 7th anniversary, I thought I’d take a look at the future of the mobile phone. And I find myself thinking that it may not have one at all.

Forty years ago the mobile phone was just that: a portable handset connected to the telephone network via the airwaves. It was for voice calls and nothing more. Fast forward to today and people rarely seem to list ‘making calls’ in the top things they do with their smartphone. It is a camera, media player, gaming device, web browser, email and social media tool.

Each of these functions, alongside the ability to make calls, places both functional and ergonomic demands on the design of the device. Demands that have first shrunk it down and then stretched it out to accommodate more hardware and larger screens.

The result is a compromise. However slick and pretty we make these little slabs of glass and plastic, they are not ideally shaped for any of their functions. What keeps the functions all packaged together into one place has been — in part — technological restrictions. If you were to separate all of the features out into individual units you would need to supply each with power and connectivity so that they could keep running and share their functions with each other. This adds cost and complexity; small batteries powering wirelessly-connected devices would not last very long.

But the price of technology falls fast, in direct opposition to its capability. Before long the cost and capability barriers to breaking all of the converged functions out of the mobile phone will be outweighed by the benefits.

Does this mean we will be left with an old-school phone just for voice calls? No. For exactly the same reasons. Is holding your hand up to your head really the best way to put a microphone and speaker in the appropriate places? Strip away the technological restrictions and the phone was never a great design for its original purpose. Our first attempts at replicating these features wirelessly — the Bluetooth headset — may make you look like a bit of a twonk, but they are improving. We seem to have much less of an issue with less sci-fi, more stylish headsets that allow us to use both our hands while making a call.

What will be stripped from the phone will be all the user inputs and outputs: screen, camera, microphone, speaker, movement sensors. These will be distributed around the body through connected clothing and accessories. What is left will be storage and connectivity — a little personal server/router that links together your devices and connects you back to the net. Will this still be a ‘mobile phone’? Arguably not: descended from it but so removed in usage terms that it doesn’t really count.

How fast will this happen? Well it has begun: look at the increasing prevalence of wearable health sensors like the Nike+Fitbug, and Jawbone Up. Rumours are rife about Apple launching a smart watch to bring you updates from your phone; Pebble raised over $10m from Kickstarter in order to bring similar technology to market. Battery technology and wireless connections have improved dramatically. Printable, flexible screens are just around the corner.

I think there’s a good chance that in ten years time we might be looking back at the passing mobile phone era, rather than celebrating another anniversary.

Tom Cheesewright