Dec/090
Robotic Kite Flying
I saw this post in the IEEE Spectrum blog about a robotic kite flying. The group that did it, Festo, has done some other cool project like flying robot penguins.
I guess it's always more impressive to demonstrate learning algorithms on big expensive hardware. But having big hardware is not essential for having great algorithms. I'm sure there are ways to demonstrate great algorithms using relatively primitive hardware.
Peter
Sep/090
PRETzel
PRETzel is a research group based in the ECE department at the University of Auckland. Their research focuses on the development of Precision Timed (PRET) Machines, which are processor architectures designed to give precise, deterministic execution timing. Predictable timing can be crucial for the reliable operation of embedded systems.
The PRETzel group's approach is based on augmenting an existing general purpose soft-core processor with a "predictable functional unit". Their ARPRET processors are programmed in PRET-C, an extension of C that supports synchronous concurrency, preemption, and a high-level construct for logical time. PRET-C programs are logically concurrent, but compile down to a sequential program for execution.
Berkeley and Columbia are also collaborating on the devlopment of PRET machines, although their approach is slightly different to the PRETzel one.
I'd eventually like to start doing some work with PRET machines here - either on the architecture development front, or on language design for PRET systems. Vorpal's approach to concurrency might map well onto a PRET architecture. It'd be interesting to look at how well the two approaches match, and whether Vorpal could be augmented with timing instructions.
Sep/090
Robots Evolve to Deceive One Another
Just read an interesting article about a robotic evolution experiment. 10 robots were placed in a small arena where they gain or lose "points" based on their time spent in the "food" and "poison" regions. Each robot has a blue light which it can use to signal others. After only a few generations some robots started using the light to signal others away from the food.
Their evolution was made possible because each one was powered by an artificial neural network controlled by a binary "genome". The network consisted of 11 neurons that were connected to the robot's sensors and 3 that controlled its two tracks and its blue light. The neurons were linked via 33 connections - synpases - and the strength of these connections was each controlled by a single 8-bit gene. In total, each robot's 264-bit genome determines how it reacts to information gleaned from its senses.
Aug/091
Popular press article: “Why Music Moves Us”
I found this article, "Why Music Moves Us" by Karen Schrock. It's an interesting read, especially with regards to the organisation of the brain, processing music in the opposite side as language, but in apparently similar ways.
It suggests to me that teaching a machine to recognise important features in music may be equivalent to, or at least as hard as teaching a machine to recognise emotions.
Peter
Aug/091
Line tracing laser which generates sound
I can imagine this is quite fun to play with. Its a pity they haven't managed to get some more interesting sounds out of it.
http://www.youtube.com/watch?v=fBxPYhOnKv0
[Ed. Looks like a good system for making a simple interactive robot. Laser tracing of features in realtime should have some nice applications in games or learning systems. Building two robot which can interact by laser projection with each other sounds like a great demo and nice ML platform.]
Aug/090
Mobile Robot Control – The Subsumption Architecture and occam-pi
I was recently looking at Brooks' Subsumption Architecture for robot control for the first time in a while, and was struck by how well many of the ideas would map onto formalisms like CSP and languages like occam. So I wasn't all that surprised to discover that the good folks on the Transterpreter project have been experimenting with implementing a subsumption architecture in occam. A report of their initial experiments can be found in Simpson et al., Mobile Robot Control - The Subsumption Architecture and occam-pi.
The results look quite promising. Implementing subsumption in occam looks like it's extremely easy, and the expression of basic behaviours in occam ends up being quite clear and easy to follow. For example, here's a simple behaviour to prevent collisions, which is used in tandem with a distance monitoring process:
PROC prevent.collision (CHAN INT distance?, CHAN INT act!)
WHILE TRUE
INITIAL INT min IS 0:
SEQ
distance ? min
IF
min < 20
act ! motor.stop
TRUE
act ! motor.forward
:
It'd be interesting to see if we could build an occam-like interface to the TeRK platform used in ENMT301 (which seems to serve the same purpose as the Player API used in the paper). Alternatively, it seems likely that it'd be quite easy to integrate a JCSP-based Java application into TeRK, or perhaps for slightly cleaner behaviour descriptions it might be possible to use Communicating Scala Objects. --Allan
Aug/092
Prediction of Audio Signals, Round 1
I want to build a robot that learns music like a child would. That's a bit of a tall order, but it's gonna need adaptive signal processing/machine learning of some sort, and prediction is a good place to start.
So I wrote an echo state network (see Jaeger 2001) in Python, and I pumped some music through it. The echo state network (ESN) is trained to predict the signal 100 time steps into the future. The sample rate is 44.1 kHz, so that's 2.3 ms.
The ESN has 2 inputs and 2 outputs (I'm using a stereo audio file). I've used random internal connections but normalised the spectral radius of the connection matrix to 0.95. The input weights are in the range [0, 0.01] and I've used feedback with weights in the range [0, 0.05]. The ESN learns online using the LMS algorithm.
Here's the target, which is also my own work. So what does it sound like? I tried with two different network sizes:
10 neurons
30 neurons
They both sound rather distored, and it's not immediately clear that the 30 neuron version is a more faithful reproduction of the original. Perhaps I need a network with ~100 neurons in order to accurately expect to predict 100 steps into the future.
The original hypothesis was that the error signal of the predictor will contain some knowledge of the 'surprise' of the original signal. But I'm going to have to look closer, and probably, build a better predictor.
Peter
Aug/093
Wacky Idea #1: An Embedded-Systems “Multimeter”
Sometimes it'd be handy to have some kind of portable "multimeter" for embedded systems development. A kind of "universal embedded systems debugger". What I envision here is a handheld device with the capability to handle simple digital levels, JTAG, USB, RS232, SPI, I2C, ethernet, and wireless (probably 802.15.4) interfaces, to read in data and display it, and to output custom data. Possibly also including some basic current and voltage sensing, or a really basic oscillioscope capability. Something that would let you interface to a device in the field by whatever debugging port it has available, and try to figure out what's wrong with it.
Does anything like this exist already?
--Allan