My Raspberry Pi arrived on 24th May 2012. This
project will detail my experiences with it.

Today I went to HORIZONS: A celebration of the 30th anniversary of the
Sinclair ZX Spectrum which was part of Sci-Fi London 2012.

Chris Smith who runs the site zxdesign.info gave
a quite technical talk on reverse engineering the Spectrum’s
ULA. This information
is available in the book: The ZX Spectrum ULA: How to Design a
Microcomputer. Chris also
gave some technical details on determining exactly how many machine cycles
could be executed between line refreshes and how this knowledge could be used
to overcome the ZX Spectrum’s 2 colour per 8x8 pixel block limit.

There was time for some of the attendees to talk about their memories of the
Spectrum and things they’d done. One person had a Speccy
2010 which is an FPGA
implementation of a Spectrum that can read data from SD card.

There were a couple of RaspberryPi‘s on show:
one playing a short film and the other running a Spectrum emulator running
Manic Miner which has to be one of
my all-time favourite Spectrum games - I spent hours playing it and the sequel
Jet Set Willy when they were
released. My son started playing the game and got hooked - I have a suspicion
that if I set up an emulator on the home PC he’d put as many hours in playing
it as i did 29 years ago. Eben Upton of RaspberryPi fame also gave a short
talk on how the Raspberry Pi came to be.

What I hadn’t expected is that people are still developing for the ZX
Spectrum. Using emulators and PC-based development environments experienced
programmers are making use of the detailed knowledge of the machine that was
not readily available (AFAIK) in the 1980s and still cranking out new games
such as Chris Smith’s isometric 3D
game and Jason Railton’s
Buzzsaw

.

Change is a strange thing. We need some of it or we get bored but mostly what
we really want is homoeostasis - to find a situation we like and keep
everything the same indefinitely - this is unlikely to happen and if it did
we’d probably get bored eventually.

In the last three years both my parents died. Now some changes seem even more
painful as they remove things I associated with my parents and them being
alive. This made it hard to redecorate my parents house when I moved into it
last year - on one hand we needed to do a lot of work to make the house
suitable for my family on the other many changes removed something of my
parents. For example removing the cupboards that my Dad made himself (he was
trained as a cabinet maker).

So, I’ve been thinking a lot about change and memories recently…

No article on memories would be complete without the obligatory Blade Runner
quote: “All these moments will be lost like tears in rain.” However, this begs
the question “does it matter?” - One day I will die and much of what I’ve
learned will be lost. Not much will remain of Dave Snowdon after that except
for my children’s memories and those too will fade. Maybe some of what I’ve
written down will survive but that presumes that someone will think that’s
worth doing. So it’s a reasonable bet that in a hundred years or so not much
will remain of Dave Snowdon except possibly a few photos on decaying media and
maybe some blog posts in an Internet archive. This is not a problem for
humanity though - as long as I’ve prepared my children for adult life and
given them the resources to make their own way then I’ve done my job and while
I might hope that I’ll live on in more than the (pleasant I hope!) memories of
my children in the grand scheme of things it does not matter at all.

A tough one is architecture as that affects both the character of a place, the
quality of life of the people who live there and gives us a view onto the
past. We obviously have to make changes to the built environment as our needs
change but how to decide what to preserve and what to demolish? How do we
balance English Heritage and the National Trust against property developers
who simply see the space taken up by forests and ancient buildings in terms of
their monetary value?

Digital technology can help to some extent - if we can’t retain the physical
presence of something we can at least retain the digitally preserved memory of
it.

Apart from saying “leave England’s forests
alone!“ I can’t provide answers on the large scale, but
there is a local issue that’s been on my mind as I walk past it every day on
the way to work and because it’s been there throughout my entire life.

Photo by _moonpie

Electric Parade, South Woodford, London E18, was named so because of the
London Electricity
Board (LEB) showroom
that was originally there. One of the distinctive features of the row of shops
was a giant model of an incandescent light bulb under the lettering “Electric
Parade” The LEB showroom closed when I was still quite young and was replaced
by a series of shops, most recently Pizza Express.

I was impressed when Pizza Express kept the giant incandescent light-bulb on
the frontage and changed the filament for a neon version spelling out Pizza -
it showed both some humour and some respect for the area and for the history
of the place - I thought.

Unfortunately, in 2012’s redecoration of Pizza Express the designer in
question seems to have thought that light-bulb wallpaper was a good
alternative to the giant light-bulb and as a result the new frontage is…
boring… dull. It says nothing about the history of the parade of shops.

Now maybe you think I’m making too much of this, it’s a just a plastic and
wood mockup of an obsolete lighting technology after all. However, I think
areas need a local character, a local presence otherwise everywhere will look
even more uniform and bland than city suburbs do anyway. Tourist hotspots have
big landmarks to help them stand out; places less blessed with architectural
gems need all the help they can get.

So I say to Pizza Express South Woodford: bring back the light-bulb!

I just upgraded the head of my NAO robot to a NAO next
gen head. The old head needs to go back to Aldebaran,
but before that I could not resist having a little fun. Ghene
Snowdon took my initial shots and edited them in
photoshop to create the images below.

And of course the legend of the headless robot.

I’d put off reading The Windup
Girl for a while as
I’d seen mixed reviews, but finally a review on
slashdot convinced me to give it a go.

Although The Windup Girl is a science fiction book, I feel it’s doing it a
disservice to view it solely as one. If books like
1984 can be viewed as
mainstream literature then I think The Windup Girl deserves it too - although
there are clear science fiction themes the book is really about what it is to
be human and how good humans are at objectifying others and so justifying all
manner of mistreatment.

The central character of the story, Emiko, The Windup Girl, is a genetically
engineered “New Person” manufactured in Japan as a secretary, sexual
companion, and slave. New People are disease resistant, have better hearing
and eyesight than normal humans, and think and move extremely quickly when
required. However, they are also sterile, genetically engineered to be
obedient even against their will. Bred for use by the rich Japanese (who live
in air-conditioned environments), they have smooth skin with fewer pores even
though that means they sweat less efficiently and can die of heatstroke in the
tropics. In order not to mistake them for natural humans their bodies move
with a jerky movement - hence the nickname “windups.”

The story takes place in Krung Thep (The Thai name for Bangkok) in a time
after oil has run out and genetically engineered plagues have ravaged the
planet. After many decades of insularism, international trade via dirigibles
and sailing clippers has restarted. Due to the disasters caused by genetic
engineering it and the animals and plants produced by it are viewed with deep
suspicion by Thais even though daily life is now dependent on genetically
engineered foodstuffs and animals such as the megodonts (genetically
engineered elephants) which provide much of the motive power in industry. The
Thai environmental ministry (AKA “white shirts”) are charged with preventing
pollution and genetic contamination but in fact are so corrupt as to be
useless and are basically a government sponsored protection racket.

One of the ironies of the book is that although the Japanese created the New
People and rely on them in their society they consider them just as much
objects as the Thai who hate them. Emiko is abandoned in Krung Thep when her
Japanese master decides that it is not worth the cost of bringing her back to
Japan and abandons her. Without the protection of the Japanese she is classed
as an illegal import and is in constant danger of being found and killed by
white shirts and general members of the population. She falls into the
clutches of Raleigh, a sadistic (or at best uncaring) bar/brothel owner, who
uses her in a degrading live sex show and pays the bribes that cause the white
shirts to turn a blind eye to her existence.

Apart from Emiko and Raleigh, we have Anderson Lake an amoral executive for
one of the hated genetic engineering multinationals posing as an entrepreneur,
Jaidee Rojjanasukchai and Kanya Chirathivat Thai white shirts and Hock Seng, a
Chinese refugee from ethnic cleansing in Malaya. The greatness of The Windup
Girl is the way in which these, and a host of less central characters, are
rendered as people with their own fears and motivations. None of the main
characters are truly evil but their scheming for their own advancement without
thought of the cost to others has dramatic consequences which play out to
devastating effect.

However it is the story of Emiko in her journey from genetically engineered
victim to master of her own destiny that is the central thread of the story.

Although the characterisation is masterful, as others have
commented, the idea of a world in which muscle power is the main motive
force is less convincing. In my opinion this does not detract too much from
the story though since it is so character focussed.

To my mind one of the worst traits in humans is the way we can conceive a
being which is obviously sentient and intelligent as only an object which
deserves to be maltreated - in the book we see this in the way Emiko and her
kind are treated by almost everybody around them.

I would definitely recommend this book even if the world-building is sometimes
less than convincing the characterisation and the story they weave makes it
all worthwhile.

Links

• Paperback
• Kindle
• Kobo

View the discussion
thread.

Since I got my NAO I have not had time to do as much coding as I would have
liked. I decided to give myself a simple project in order to get myself
started and try out some programming in Choreographe and learn a bit about the
NAOqi runtime. I don’t know why I decided to try and get NAO to pretend to
hypnotise people.

You can see the result in the video below:

Although it’s hardly hypnotic and the stop motion animation of the arm (the
first I’ve attempted to do with NAO) is terrible, it allowed me to try several
things:

• Using layer to implement simultaneous actions - although you can’t see it in the video; the eyes are animated: NAO blinks while waiting to detect a face and the eyes rotate while NAO is performing his hypnosis routine.
• Using timeline layers to implement a state machine in Choreographe
• Selecting an option using speech recognition
• Face detection

NAO developers can grab the source
for the project here

I bought this postcard about ten years ago in Karlsruhe, Germany and it just
resurfaced while i was sorting out my stuff after moving house. The back
suggests that it’s titled “Dompteur” by Michael Sowa but I don’t know any more
about it than that. However, I think in many ways it sums up perfectly the
experience of writing computer software.

The picture depicts three IBM PC era computers mounted on pedastools in a
circus tent with a man in a lion tamer style uniform standing before them
holding a whip. Despite the vast tent there is only a single solitary man in
the audience dressed in a drab brown suit.

It’s a sad fact that despite many developers finding software development
fascinating few outside the industry do - hence the extremely sparse
attendance at the show. The drab clothing of the sole member of the audience
suggests to me the fact that, among non-geeks, geeks have a reputation of
being dull (not to mention socially incompetent) people.

Even for developers the experience of writing software can be frustrating
(hence the whip) and can feel unrewarding at times.

After some discussion on Aldebaran Robotics Developer program‘s
forum a few of the UK developers decided to meetup in London. We were lucky
enough to be joined by Jerome Monceaux, the architect of the NAO platform and
Akim, the developer program community manager who came over from Paris to
spend the day with us.

After introducing ourselves, the first order of business was a little surgery
on Tim’s NAO to replace some stripped screws on the battery compartment.

Here’s Tim’s NAO with the battery out - the serial number is written in the
battery compartment - this apparently differs from the body serial number
reported by software.

NAO4

The big surprise of the day was that Akim & Jerome had a brought a NAO4 with
them - naturally it did not stay in its box for too long after we found out.

One visible difference between NAO3 and NAO4 is that NAO4 has a standard USB
type-A socket which can be used for interfacing standard USB equipment such as
a Bluetooth interface (for regulatory reasons Aldebaran are not currently able
to ship NAO with integrated bluetooth) .

Jerome took us through a short presentation on the improvements to the
platform in NAO4. Overall the body is much the same except for an increase in
the PWM frequency used to control the motors. It’s NAO4’s head that contains
most of the interesting changes, including:

• a faster processor (Intel Atom)
• significantly more RAM
• improved cooling system
• better cameras - not only do these have increased resolution and better noise reduction, NAO4 is capable of running both cameras simultaneously (NAO3 can only use one camera at a time).
• Much better speech recognition - The acapela engine has been replaced by Nuance.
• The cameras are more securely attached to the head - in NAO3 it is possible for the cameras to be knocked slightly out of alignment if NAO falls over; this will not happen with NAO4

NAO4 boots noticeably faster than NAO3.

All developers currently on the NAO development programme will be offered an
upgrade to a NAO4 head (keeping the NAO3 body).

NAO store

Jerome gave a demonstration of the NAOstore - it works pretty much how you’d
expect a modern app store to work. There are several cool features though such
as:

• Apps getting automatically downloaded direct to your NAO after adding them via the NAOstore website.
• The ability to set a trigger phrase to cause NAO to run the app

At the moment it’s only possible to trigger apps in response to a spoken
phrase, but in future Aldebaran may add the ability to have other means to
trigger an app. NAO’s life was already a means to run various behaviours on
NAO - it’s now becoming a framework to download and manage applications
downloaded from the NAOstore.

NAO’s life has a concept of channels. A channel is just a way to group
behaviours with automatic updates with contextual triggers - the robot decides
when to trigger the behaviour. at the moment there is only one, but the intent
is to add the ability to create new channels.

Developing for NAO

One of the best parts of the day was having the chance to grill Jerome about
developing for NAO and he graciously answered all our questions.

Jerome advised us to start with small simple applications in order to get used
to the environment without also having try and create complex behaviour at the
same time. As an example he demonstrated the “touch my head” application. See
the video below.

There are several ways to create applications for NAO

• Graphically using Choreographe which provides a graphical view of component behaviours which can be “wired” together (and which works in a similar way to the Lego Mindstorms development environment) combined with a timeline view with key frames(similar to the way the original flash editor works)
• Python - Python code can either run independently or integrated with Choreographe. Python and Choreographe are tightly integrated so that new behaviours can be implemented in Python and represented as “boxes” which can be wired together graphically in Choreographe
• Native code (C++)
• URBIscript

Having not had much time to play with Choreographe apart from having tried
some simple experiments I was surprised by the depth and power that Jerome
demonstrated. All boxes shown in Choreographe have a script, flow diagram and
timeline (not visible by default). Each timeline can have multiple keyframes
with each keyframe having its own flow diagram. For example you might use:

• one frame to initialize configuration data
• one to download functions
• another to perform the action

The script associated with a box is a Python class with methods corresponding
to events linked to the box (eg receiving input). You can define as many
inputs and outputs on a box as required and each will have a corresponding
method or property in the Python script. The onload method, called when the
box is loaded, provides the ability to create objects for use by the rest of
the behaviour.

Having assumed that “real” applications would need to be developed in native
code or python I now feel that a better approach may be to develop modular re-
usable components and wire them together using Choreographe.

I’ve spent most of the last ten years writing either in Java, javascript & C++
and having a strong interest in other
JVM languages, I was a
little disappointed that there was not better integration with the JVM but I
can understand Aldebaran Robotics’s reasoning - Python has always been more
popular in the academic community than Java and I imagine that most NAOs
outside Aldebaran are currently located in academia. Python is a powerful and
relatively fast language and although I don’t really like the way indentation
is used to indicate structure I imagine I’ll be spending a lot more time
writing in Python from now on.

That said, Jerome said that SOAP is used for communication between remote
components and so it’s perfectly feasible to write code on a remote computer
that interacts with NAO. Version 1.12 of the NAO software (currently in beta)
contains a Java binding that allows any module to be invoked from Java -
however since NAO does not run a Java virtual machine use of Java is limited
to software on a remote machine. It’s still a great feature to have though and
I’m sure I’ll be making use of this once I feel ready to create projects too
large to run only on NAO.

The NAO runtime is divided into modules implementing the ALmodule interface.
Module code is not invoked directly - instead a proxy object is created and
this is used to perform operations using a module. NAOqi contains a broker
which is just a bag of modules and provides a way to locate a module by name.

Operations on proxies are synchronous by default however it is possible to
call methods asynchronously: If myproxy.foo() invokes the synchronous
operation “foo” on myproxy then myproxy.post.foo() will execute it
asynchronously and return an ID that allows the asynchronous operation to be
referenced (for example to test whether it has finished).

NAOqi contains a fine-grained resource management system. It’s possible to
lock resources for a behaviour and the runtime will prevent other scripts from
using the resource until it’s unlocked. A nice feature is that, since
resources are organised hierarchically, it’s possible with a single lock to
lock the whole robot, a whole limb or a single motor.

NAO includes a version of OpenCV with
Python bindings which can be used for, among other things image recognition.
There is some support for generating training data built into Choreographe.
Below is a photo of the screen when Jerome was demonstrating how to create a
training set using Choreographe.

Random tips

Throughout the day I learned a lot from listening to Jerome (twitter: ), Carl
(twitter: @CC64)l & Tim (twitter:
@mechomaniac). Here’s a selection of
various useful bits of information:

When saving Choreographe projects same them as a directory, not a .crg file
since it makes it easier to commit the porject to git and allows all parts of
the project to have there changes to be tracked independently.

It’s possible to use ssh to connect to the Linux instance running on NAO.
Executing ssh nao@nao.local (default password nao) from a terminal window
should result in opening a session on NAO from which you can invoke Linux
commands an start an interactive Python session allowing you to interactively
experiment directly on NAO. If starting python in this way you’ll need to
manually import the modules you need (eg import opencv).

There is a logging module (ALLogger) that allows python code to write to a log
in order to help post-mortem debugging. ALLogger can be used either by
creating a proxy to it like any other modules or by using the self.log
reference (with methods debug, info, warn, error) in any Choreographe script.

here is a preference server running on Aldebaran Robotics’s website from which
NAO can download user depdendent configuration information for an application.
The communication takes place over an XMPP transport and is in XML format
(SOAP?).

NAO marks - these are cards that NAO can recognise. They are all numbered
allowing applications to perform actions based on what card is recnogised.
There is a PDF on the Choreoraphe CD and more can be downloaded (in PDF) from
the Aldebaran website. You can then print these and use the NAOmark box in
Choreographe to detect them.

The Python bindings are the most convenient way to use OpenCV. The
getMethodHelp(“”) function gives interactive help on the named OpenCV method.

Summary

A geek event does not get much better that this (IMHO) - a combination of very
knowledgeable (and gracious) people, robots, beer and food! Not only did I
learn a lot about NAO but I cam away inspired to learn more and develop my own
applications. I’m very grateful to Jerome and Akim for giving up their own
time to spend a day with us. Jerome and Akim demonstrated a sincere enthusiasm
and desire to help the NAO developer community and if there is any justice in
the world Aldebaran Robotics and NAO deserves massive success. I think the
only question mark regarding NAO is how to bring the platform to a wider
audience and I believe the availability of killer applications will play a
part in this - for this Aldebaran needs a vibrant developer community and
seems to be doing exactly the right things in this regard.

About Aldebaran Robotics & the NAO developer program

You can find find out more about Aldebaran Robotics via their website www.aldebaran-robotics.com and the developer program at developer.aldebaran-
robotics.com. The
blog is also a good source of
information on what NAO developers are doing. You can also follow the NAO
developer program on Twitter as
@NAOdeveloper and on
facebook.

View the discussion
thread.

Have finally got my Linux box back on-line today after a couple of months of decorating and then moving house. We now have at least one CAT5 cable to every room in the house except the kitchen. This afternoon I spent some time wiring up a patch bay in a utility cupboard and checking everything out with a cable tester.

Being the unashamed geek that I am I think it’s quite cool to have wired ethernet to every room and now my Linux box (which has no wireless interface) is taking advantage of it.

The children’s computer seemed to have a lot of trouble with its wifi signal and now that’s all in the past as I can plug it into a wall socket.

Still plenty of DIY to do and boxes to unpack though …

My wife (a portrait and wedding photographer) thought the NAO was so cute she
insisted on a portrait session:

http://www.gsnowdon.com/daily-picture-meet-our-new-baby/