Paul O'Dowd

Robotville: Science Museum London

2011-12-02T11:05:00.001Z

I am exhibiting at the Science Museum London this weekend as part of RobotVille. There are lots of great robots here, and its really friendly. I've been having a great time chatting to all sorts of interesting people.

2 Axis Gimbal inside an eye

2011-11-22T10:11:00.000Z

Recently I have been inspired by some animatronic videos on youtube, such as:

This video is not my work.

One of the things that caught my attention was the necessity for eyelids to be working in very close proximity to the eyeball. This means the mechanism to give an eye the freedom to move and to be actuated has to be enclosed within the eye. I knew this had to be a gimbal type of mechanism. I decided to have a go at building one myself.

I used polymorph inside this plastic cup to create a hemisphere for the eye.

I then created holes in the edge of the 'eye' to run float the gimbal.

Next, some pvc pipe to form the inner ring of the gimbal. Note, the eye is itself an outer ring.

Finally, a bit of scrap wood as the support. M2 screws used as axles. All small and fiddly. Hopefully you can see how it can twist along the lines of the axles.

Working with Polymorph / Shapelock

2011-11-21T10:18:00.001Z

Late Saturday night I played with some polymorph plastic. You can heat this plastic up in hot water and it melts into a dough like form, and sets hard again as it cools. It is very easy to use and very strong. An excellent material for prototyping. I also think it is a good material in its own right. Mechanically it is very slippery and resilient to flexing. You can use it thick and rigid, or purposefully very thin to create flexible joints. I thought I'd share some tips on working with it.

Notice some clay trapped within the polymorph.

Using hot water means the polymorph will get wet. Have a tea towel on hand to dry the plastic off as you pull it out of the hot water. A tea towel is good because it is not fluffy! Fluff sticks to polymorph. I lay the towel flat on the table and press the polymorph into it.

If you can be a bit patient, I find polymorph can get really extra soft and squishy if you leave it in boiling water for longer.

Big clumps of polymorph don't melt well. Initially it is in granular form, but one of the good things about polymorph is being able to reuse it. Whenever possible, stretch any excess polymorph out thin before it cools, it will be much easier to re-melt.

The downside to stretching out polymorph is that when you reheat it, you will need to fold it to get thickness back. This is a really difficult stage, where water can get caught between layers. Try to dry out your polymorph properly before folding. Better yet, take the time to cut your polymorph up into tiny pieces before starting work.

Hot polymorph cuts really well with scissors. Scissors are my favourite way to get clean edges. Because it melts when it gets hot, any tools that create heat through friction are a bit more tricky to use. The plastic tends to stick to the tool. Scissors slice through nicely.

In a similar way, you can carve with a stanley knife, but this is quite dangerous. Polymorph is self-lubricating and very slippery. Its usually naturally creates organic shapes which are hard to carve down. It cools to a very hard object, so the blade is prone to biting in only to suddenly jump out and into fingers.

oops

Polymorph is reasonably easy to puncture with something sharp. I like using a throwing dart, as you can get a good grip and the dart point has a good taper to widen holes. However, the polymorph does seem to close up on itself. So use something like a dart, and then a drill bit by hand to cut away the hole a bit more.

If you can, work in details like holes and clean edges with tools whilst polymorph is a bit soft. It is much much easier.

You can add threaded holes to polymorph for screws! Simply, whilst the polymorph is hot, place a screw through the plastic and ensure the polymorph has a good grip on the screw. Once set, unscrew the screw and you'll have the negative threaded hole left. This is a good way to avoid using nuts on your screws, and to create boxes or access ports in objects that can be secured.

Polymorph only seems to stick to itself it both bits of polymorph are in their hot and malleable form. It you shape hot polymorph against cold polymorph, the two can be pulled apart really easily.

This can be a bad thing if you need to extend some work.
I've not tried it, but it might mean you can create a mold from polymorph, and then use more hot polymorph against the cold mold to cast a replica

When combining two bits of hot polymorph, the seams can be hard to blend and flatten out. By far the best strategy I've come across so far is to have something solid to push against. In most cases this means working with a mold. A mold could be a custom made plaster cast, or an ordinary object that meets your needs.

With a mold you can get very smooth surfaces on the polymorph. Working by hand leads to finger depressions and organic surfaces. Either could be useful.
When using a mold and pressing in your polymorph, use a pair of scissors to cut away the excess overflowing polymorph. I found a scalpel didn't work so well.

When using polymorph against objects be really careful with any other dirts or foreign objects. I pressed polymorph against an object I sculpted out of clay. The clay got between layers of polymorph, which made it really weak.

Interestingly, the thin layers of polymorph showed the clay, giving it a new colour.
Also, these many separated layers of polymorph gave it quite a good degree of flexibility, and could be a nice way of rendering joints.
Trapped dirt is really hard to later remove from polymorph, and can ruin your otherwise reusable stock :(

Lastly, I had a brief experiment with a hot air gun (paint stripper). This was really exciting. The polymorph seemed to retain its hot flexible state for longer. Also, it wasn't wet! I used the heat gun to heat up a piece of work to make some adjustments. I'll be doing some more experiments here - I'm not sure what will happen if the plastic gets too hot. But this could be a good way to keep polymorph flexible for longer, giving more time to play.

E-Puck Battery Charger

2011-11-12T22:43:00.001Z

This evening I decided to take my ideas for an e-puck battery charging station and realise them as a 3D model to later print. Having access to a 3D printer is really exciting! Ideally, e-pucks should be able to find the charging station, dock, charge-up and leave - all without switching off. Here are some images of what I have so far:

This is the front of the charger. The charger consists of two parts. One is a ramp (bottom part) and the second is a rocking element (vertical part). I've separated the two parts in these images, the two will interlock.

There are two ramps for the e-puck robot to drive up, one for each wheel. I think it is important to have the gap between the ramps as the robots have a very low ground clearance, so this allows the offending plastic body to 'float'. The ramps must be long and gradual. They are wider at the base to guide a robot in appropriately, reducing a the need for an accurate docking algorithm.

The second purpose of the ramp and gap is to allow an armature to slide underneath the robot. This is the long piece sticking out from the bottom of the vertical part of the charger. This will have the negative contact for the battery charger, and will make direct contact with the shell of the battery exposed under the robot.

You might notice the armature has a notch, and the bottom of the ramps have little notches too. This is to allow an elastic band to be stretched between the ramps and over the armature. This will cause the rocking part to naturally spring back to an upright position.

As the robot drives up the ramp, it will push into to the vertical piece, which has a protrusion at the very top. This protrusion will have the positive contact plate to charge the battery. I decided to only expose one charging plate on the robot to stop robots shorting each others batteries out. An e-puck pushing into the vertical piece will raise the negative armature up under the e-puck and start the charging process. Both the positive pushing protrusion and the negative armature will require some sheet copper, which will extend back to make contact with the charging circuit on the back.

The back of the charger mirrors the charging contacts on the circuit sold specifically for the e-puck batteries. The idea is to clip the original charging circuit straight to this station. There is a resistor in the charging circuit which sets the charging current. I will replace this with a variable resistor to compensate for the load of a running e-puck, allowing it to charge up without switching off. The hole in the vertical piece is to allow for a light source to act as an attractor to robots.

I'm quite happy with this idea so far. I need to think about how to keep the robot securely in place whilst charging. Minimal, interlocking parts seems to be the theme of 3D printing. This took about 2 hours to think up and sketch.

More to come!

Arduino, Smooth RC Servo Motor Control

2011-11-04T23:36:00.000Z

When using the arduino Servo.h library, you normally use myServo.write(), but you can use myServo.writeMicroseconds(). This lets you write out the controlling squarewave period in microseconds. The rc servo standard is typically 1000us <-> 2000us, with 1500us as neutral position. This means that you have a resolution of ~2000 individual steps, rather than the 180 (degree) steps the normal write() would provide - and therefore, the potential for significantly smoother servo motor movements.

Check out: http://arduino.cc/en/Reference/ServoWriteMicroseconds

Here is the test code I have used to good effect so far, I have been using servo motors with an extended range of uSeconds. Currently using one pot to set the target position, and the second pot to change the ramping/smoothing fraction. Ramping/smoothing is done with a technique called easing (see here) which means continually adding a fraction-of-the-difference between target and current position. See below, very simple code, only one variable to adjust smoothing.

The last point to mention is that if you want to benefit from writing out a higher resolution of steps, you need to write out the control signal much quicker! I found the Serial.print statements to considerably slow the code down.

#include <Servo.h>

// Using floats as the servo library can handle this and
// it makes for smoother progression through position
// values.
float current_pos;
float target_pos;

// One variable to control smoothing.
float easing = 0.7;

// Motors
Servo l_motor;
Servo r_motor;

void setup() {

   // Serial seriously slows this code down... commented out
   //Serial.begin(9600);

   // Start the code at middle-ish
   // position   current_pos = 1500;

   // pin/connector specific!
   l_motor.attach(4);
   r_motor.attach(5);
}

void loop() {
   int pot;   // target position
   int pot2; // easing fraction
   float diff; // difference of position

   // Read in pot, scale appropriately
   // to set uSecond position value
   // in range 600:2400
   pot = analogRead(A2);
   pot = map( pot, 0,1023, 0, 1800);
   pot = 2400 - pot;

   // Read in pot 2, used to create
   // a fraction to scale movement.
   pot2 = analogRead(A3);
   pot2 = map( pot2, 0, 1023, 0,1000);
   easing = (float)pot2;
   easing /= 1000;

   // Type cast to float.
   target_pos = (float)pot;

   // Work out the required travel.
   diff = target_pos - current_pos;

   // Debug prints
   // slow, so commented out
   /*
   Serial.print("Current: ");
   Serial.print( current_pos );
   Serial.print(", Target: ");
   Serial.print( target_pos );
   Serial.print(", Difference: ");
   Serial.print( diff );
   Serial.print(", Easing: ");
   Serial.print( easing );
   Serial.print(", L: ");
   Serial.print( current_pos );
   Serial.print(", R: ");
   Serial.print( 600 + (2400 - current_pos));
   Serial.println(" ");
   */

   // Avoid any strange zero condition
   if( diff != 0.00 ) {
      current_pos += diff * easing;
   } else {
      // if diff == 0, we don't need to move!
   }

   // Write out motor values.
   // Right motor is offset by 600, and the opposite of left.
   l_motor.writeMicroseconds( (int)current_pos );
   r_motor.writeMicroseconds( (int)(600 + (2400 - current_pos)) );

   // Delay, need to play with this, use millis()
   delay(20);

}

Drum Guitar

2011-11-01T11:15:00.000Z

On Sunday I pulled together some scrap parts and built a guitar around an Irish Bodhran drum.

R, Scripting Graphs

2011-10-28T13:20:00.000+01:00

My thesis has lots of graphs. My experiments have output huge amounts of data. I have found the application 'R' (here) to be fantastically useful in automating the process of taking data and transforming it into graphs.

The thing which is easy to overlook is how often a graph needs a tweak - a colour change, a placement change, a size change, a new representation - which is all fiddly and tedious business. When moving from columned papers to a thesis, there is the opportunity to make use of full A4 pages. So having the graphing scripted means it is easier to make tweaks and roll back to previous versions, easier to remember how the graphs were produced in the first place.

So here are some snippets from my scripts to produce graphs in R, they might be useful.

library( "RSvgDevice" )

This loads in the necessary library to export graphs in SVG format. I've found this immensely useful because it keeps all the drawn elements of the graph separate. So for instance, I can move the legend box around manually if I can't get it where I want in script, or resize and inset another graph. I work in Ubuntu, and Inkscape has been a fantastic SVG editor, from which I can save the graph to any other image format required.

devSVG( file="graph_filename.svg", width=6, height=8 )
...
dev.off()

The above sets up a file to save to disk. I find a width of 6 and height of 8 is a good proportion for a full A4 page of graphs. As an SVG image, everything is scalable, so the actual magnitude is not too important. dev.off() writes the enclosed commands (...) to disk and should be called last.

par( mfrow=c( 3, 2 ) )

The above formats the file to accept a grid of graphs, 3 rows by 2 columns; so it will place 6 graphs in total. When calling plot commands, it first moves from left-to-right, and top-to-bottom at each row end.

shade=rgb( 0, 100, 0, 35, max=255 )

The above allows you to set a colour in red,green,blue format. The important thing for me was being able to set the opacity. I used this on a scatter plot with lots of overlapping data points, so the regions with lots of data became darker in colour.

movingAverage = function( data, n = 5 ) { filter( data, rep( 1/n, n), sides=2 )}
myData = movingAverage( myData, 10 )

The above actually defines a function to perform a windowed average on a data set. The second line shows the call. Note, without '10', the function will default to a window of 5 samples because of 'n = 5' in the definition.

d100 = function( data ) { rep( data / 100 ) }
myData = d100( myData )

The above works similar to the previous function, but simply divides the data set by 100. These should be a good point to write more simple functions.

myData = na.omit( myData )
myData = as.numeric( myData )

The na.omit() removes any n/a data from the variable array. I found that afterwards I would have to use as.numeric() to cast the variable array back to a number array. Not sure why!

Finally, in Ubuntu, I use a bash script to call R --no-save < myGraphingScript.R.

Haptic Lotus, UBICOMP 2011 Best Paper Award

2011-10-07T18:06:00.000+01:00

A while ago I was involved in a side project. Adam Spiers lead the technical aspect of The Question in partnership with Extant and the Open University.

The project has been discussed in Wired (here), Disability Now (here), and Adam has done a great job disseminating (here, here and here).

Most recently, the academic paper "Haptic Reassurance in the Pitch Black for an Immersive Theatre Experience" was presented by the collaborator Janet van der Linden and won the Best Paper Award at the at the prestigious Ubiquitous Computing conference (UbiComp) in China.

At first it felt odd to be credited as an author when I did not contribute to the writing of the paper. However, I have come to realise that the paper simply would not have come to be if it were not for my technical contribution. This may sound a little arrogant or egotistical, but I am simply realising the value of my part in a larger contribution. When taking on the side project, I (naively) thought I was simply to be a spare pair of hands. As it turned out, I did my fair share of the making, and then my co-technical assistant David McGoran unfortunately broke his leg a week before the deadline.

I was drafted in and I worked tirelessly day and night for 5 days to fabricate, construct, solder, and wire all the Lotus devices along side my disabled and suffering friend. Exhausted, I stepped onto a train to London with the box of bespoke items headed straight for the imminent opening of the show. I was totally naive to the world of Theater, and was greeted by many hard working, stressed and anxious people. I had come with the goods, shouldered with responsibility, and they naturally looked to me to solve the new slew of problems as we introduced the devices to the setup.

It was one of the most stressful experiences I had ever had, and after the show I had a complete aversion to the project. I felt terrible. But in fact, this project has taught me many great lessons. One of the most important might be the perspective of knowing that hard work will pay off, but it may take time. In this case, the authors of the paper did an exceptional job and now I have the immense pleasure of the gift of an award plaque.

It is also interesting to note that since the Lotus project I have taken on many more with higher stress levels and perhaps even longer hours (the PhD is included in this, of course!). In some ways, I am observing again and again that it is the experiences that take me to breaking point (and some times, even the failures) that significantly increase my workload capacity, level of organisation and broaden prospective horizons.

In any case, I am proud to have worked with Janet van der Lindin, Yvonne Rogers, Maria Oshodi, Adam Spiers, David McGoran, Rafael Cronin and the others, in a tough project, but one that has more rewards than I imagined. I am very grateful for my inclusion as an author, and humbly admit I did not realise the significance when I was originally notified!

First 3D prints

2011-10-07T17:12:00.000+01:00

So, things with the Makerbot thing-o-matic are moving along nicely. I've had a few accidents but nothing too serious or costly. Machines can be so idiosyncratic! In the flickr window below are some examples of print jobs:

On the evolving front, I've rather taken to a program called OpenSCAD. Instead of drawing 3D objects with a pointer device (like a mouse, or scribe) you code objects. This means that dimensions and positions are explicitly stated. I find this much more relaxing as I do not have to fiddle with dimensions and view perspectives. I think this will also suit the evolutionary approach, as the text description of 3D models would be easy to generate as output from something like the C programming language.

This might sound like a backwards and horrible way to do it. However, OpenSCAD retains the 3D render of your object, which is easily used to quickly check and adjust your model. Here is a screen shot:

Describing 3D models is not as hard as I thought it might be. Here is a cyclinder:


cyclinder( h = 5, r = 4.5 );

And to subtract a cylinder from a cube (as if carving one from another):


difference() {
     cube( [ 10, 10, 10 ] );
     cylinder( h = 5, r = 4.5 ); 
}

Where 'h' is height, 'r' is radius, and the triplet in brackets represents a cube dimensions x,y,z.

The other good thing is being able to plan out a drawing, and then group that drawing into a module. You can then start another drawing, and call your previously defined modules as a component, and treat it like any other shape primitive. This could be key to creating printable, modular forms to evolve.

Great!

Enki, light, stripped.

2011-10-06T11:15:00.000+01:00

A while ago I was investigating the potential of running the Enki simulator (authored by Stephane Magnenat, Markus Waibel, Antoine Beyeler) on the e-pucks. As part of the process, I stripped the Enki source down, removing visualisation etc. I found this on my hard drive today and thought I should upload it before I lose it again. Of particular interest might be the makefile for the compiling and linking process. Available here.

MakerBot making Bots

2011-09-14T14:58:00.000+01:00

One of my recent tasks has been to build the 'thing-o-matic' from Makerbot Industries. The process was remarkably easy. I completed the majority of the physical build within a single weekend. I had to take a break to work on my thesis, and I finished the electronics side up this week. Here is a (pretty poor quality) stop motion of the machine printing a double helix, about 1 hour 15 in 1 minute 29:

I'm impressed with the speed at which it can build. So far I have had some small issues, that haven't quite caused problems. For instance, the extruding tool tip occasionally knocks the object it is building, which is probably a calibration error. When starting a build, the machine doesn't quite wipe away excess plastic before starting, etc. But so far, I'm really impressed. Especially with how easy it is to build models from the internet.

From here, I have to investigate how to integrate this printer into a closed loop of artificial evolution. I have almost limitless freedom to find a way to do this, preferably involving robots. So far I have been thinking about the genetic representation of the problem.

The 'thingiverse' is a huge online repository of 3d models, printed and validated by people using the Makerbot. These models seem to be in the file format "stl", and if we look inside they look like this:


solid Default
  facet normal -9.891329e-01 -1.039620e-01 -1.039620e-01
    outer loop
      vertex -4.959956e+01 -4.000151e+00 4.000000e+01
      vertex -4.959956e+01 -1.977981e+00 3.797783e+01
      vertex -4.949447e+01 -5.000000e+00 4.000000e+01
    endloop
  endfacet
  facet normal -9.891329e-01 -1.039620e-01 -1.039620e-01
    outer loop
      vertex -4.949447e+01 -4.500076e+00 3.950008e+01
      vertex -4.959956e+01 -1.977981e+00 3.797783e+01
      vertex -4.949447e+01 -2.472383e+00 3.747238e+01
    endloop
  endfacet

I think this is a description of surfaces that make up the 3D object. I think one option might be to try and evolve these surfaces. The nice thing about this approach would be that we could render the result of evolution on a computer first, not requiring the printing time. This would make assessing fitness and mutating hundreds of generations much easier, as we can simulate the whole thing.

A problem to this approach is the complexity in linking thousands of surfaces. We could let evolution go crazy, and rely on fitness assessment to get rid of the bad stuff. However, I think we would either have to constrain how surfaces can connect, or come up with a neat form of genotype transcription that would generate a phenotype of plausible objects based on the previous surfaces laid. This is a bit of a weird idea, as it means the genotype would be expressed as a function of itself - but evolution could refine the complexity of the phenotype expression for us.

Another file format is gcode. This is the file that is generated to move the tool head around on the print surface. Gcode is the instructions to lay the plastic, and references x,y,z and to extrude plastic. I think gcode inherits similar problems to stl files. Again, its a bit complicated and long winded. We could copy and paste in the start-up and shut-down routines, and evolve the building instructions. This is what gcode looks like:


()
(**** beginning of start.gcode ****)
(This file is for a MakerBot Thing-O-Matic)
(**** begin initialization commands ****)
G21 (set units to mm)
G90 (set positioning to absolute)
M108 R5.0 (set extruder speed)
M103 (Make sure extruder is off)
M104 S225 T0 (set extruder temperature)
M109 S125 T0 (set heated-build-platform temperature)
(**** end initialization commands ****)
(**** begin homing ****)
G162 Z F500 (home Z axis maximum)
G92 Z10 (set Z to 0)
G1 Z0.0 (move z down 10)
G162 Z F100 (home Z axis maximum)
G161 X Y F2500 (home XY axes minimum)
M132 X Y Z A B (Recall stored home offsets for XYZAB axis)
(**** end homing ****)
(**** begin pre-wipe commands ****)
G1 X52.0 Y-57.0 Z10.0 F3300.0 (move to waiting position)
M6 T0 (wait for toolhead parts, nozzle, HBP, etc., to reach temperature)
G04 P60000 (Wait t/1000 seconds)
(**** Start Acceleration ****)
(Note: nozzles smaller than 0.5mm might require adjustments to this acceleration routine)
M108 R1.0
G04 P15000
M101
M108 R2.0
G04 P10000
M101
M108 R3.0
G04 P5000
M101
M108 R4.0
G04 P5000
M101
M108 R5.0
G04 P2500

A third option, which is a simplification, would be to evolve structures of modular 3d objects. This would be like building something out of lego. This would be much easier to evolve, as we can copy and paste in stl files with relative coordinates. It would still need some error checking, for floating and disconnected objects. However, when making a simplification like this, we are limiting the scope of evolution.

So the first thing I have to decide, is what to evolve, for what purpose, and how to determine if it was a successful solution. Lots to think about.

Magnetic Quaking Egg

2011-08-22T22:11:00.000+01:00

There are plenty of things I should of put on here, but for the time being...

I have collaborated with Emma Powell on an art piece. It is in the Luggage exhibition curated by Matthew Arnold at the art gallery opposite College Green, Bristol. My part was to build the electronics, but I also sorted out the fitting of stuff inside the suitcase.

Here are some development photos, I'll get some photos of the work situated when the gallery officially opens tomorrow! The egg is quite a charming object in its suitcase. However, the real effect is picking it up and holding it. It pulses gently in your hands. It is not visual or audible. It is very subtle. It will be fun to see people interact with it, if I get the chance to hang around.

The circuit prototype.

The circuit mounted with standard AA batteries. The white cylinder houses the vibration motor. A reed switch is mounted in a groove in the wooden block at the top.

Stuffing the egg with packing foam, before inserting the circuitry. The foam dampens the mechanical feeling of the vibration motor, and snuggly holds the circuitry.

The first time the egg sat in the suitcase. We decided not to go with the mottled purple velvet. And the finished version features the egg in a little weaved harness.

Emma cast the egg from a real ostrich egg, and I built the electronics for it. It was a nice simple circuit and took me back to my teenage years of tinkering with analogue electronics. There is no mirco-controller (no arduino, etc).

Instead, it has a hex inverter (74hc14) linked up as a ring oscillator, which is timed with capacitors and resistors. This slow oscillator triggers a second oscillator built using two inverting gates of a 74hc240. The second oscillator causes a vibration motor to pulse, which is driven with the rest of the inverting gates of the 74hc240 ganged up.

A circuit diagram would have been much easier. The savvy might recognise that description as BEAM circuitry. In actual fact, the circuit I used could be more efficient... but I planned it all out over a coffee and it worked well enough first time.

The best detail is the use of a change-over reed switch. This allows the egg to be deactivated magnetically. I clipped the normally-open leg off the reed switch, instead using the normally-closed leg. This way, when the egg is removed from the suitcase (away from the magnets in the suitcase) the circuit is complete, and it starts pulsing in the recipients hand.

In theory, the batteries in this thing should last a very long time. It is essentially off most of the time. When it is on, it is powering only low-power CMOS, and about every 2 seconds a millisecond burst through a DC motor.

Emma Powell was a real pleasure to work with and hopefully we will have plenty more collaborations in the near future. And it wouldn't be possible without the invitation from Matt Arnold.

#pragma pack() update.

2011-07-21T13:33:00.000+01:00

I made a post a while back about the use of the #pragma pack(1) operator when coding for different platforms.

Yesterday I had a frustrating problem where the sizeof() a structure when passed to a function would change size. It turns out it is because I did not close my #pragma pack(1) statement. It meant that the point where I included a .h file with the #pragma statement from then on altered its memory packing routine.

Therefore, if using #pragma pack(1), close the statement with #pragma pack().

Minimal E-Puck Simulation

2011-07-19T13:23:00.000+01:00

I took this weekend to relax at my parents. Whilst there, I decided to re-write my minimal simulation of the e-pucks (written in C) into a program called Processing. Processing is written on the Java runtime, so it should run on any platform. I wanted to do this to remove all the bloat that has occurred over my PhD.

Zoomed in view of the simulation, showing IR proximity sensor activation.

This might be useful for someone out there - any one interested in two wheeled robots with basic sensing capabilities. Also, seeing a simulation graphically is a lot easier than trying to interpret lists of numbers.

The simulator represents e-pucks, and uses the two-wheel kinematics from Autonomous Mobile Robots. The sensor orientation is correct for e-pucks. I give the sensors a range of 50mm and use a noisy look-up table (taken from the real robots) for the proximity readings. But that is all - any other functionality and you'll have to figure out a way to implement it yourself.

200 e-pucks, moving and sensing.

Running on my laptop, I have no problem simulating 200 robots simultaneously at 30 frames per second. The simulation could do with a clock, but it simulates at roughly real-time speed. The motor stepping is actually in 40ms intervals, but thats another exercise for the enthusiast.

You should be able to view the simulation as a web applet after the break.

This browser does not have a Java Plug-in. Get the latest Java Plug-in here.

You should be able to see the simulator as a web applet. It will take some time to load. Press the 'a' and 'z' key to change zoom level, or use your mouse wheel. Click and drag to move the simulation. Press 'i' to enable/disable the IR beams, and 'g' to enable/disable the grid.

The source is available here:
MiniSim.tgz
MiniSim.zip

C Programming: Mapping / Addressing Hypercube Topologies

2011-03-08T14:38:00.000Z

Recently I have been working furiously to get some experiments done with the robots. I had to conduct 50 hours of experiments, and combined with retakes I think I clocked something like 80 hours in the lab. Lots of overnight sessions. After that, I had to write my results up, which felt like the end of a marathon. I'm still have corrections to make, but the bulk of it is over. Phew!

Today I want to post some more source code. I am exploring how lots of nodes (computers, robots, anything that communicates) is effected by the way they are arranged. I have had some trouble visualising how a hypercube is connected. These two youtube videos explain it for 4 dimensions, (or 16 nodes).

Part 1
Part 2

However, you can have hypercubes to as many dimensions you like, as long as you keep the number of nodes as a power of 2 (2, 4, 8, 16, 32). I have found it impossible to visualise what that would look like. Wikipedia has an article, but it wasn't helping me to think of an efficient way to program an algorithm to efficiently map communication between the nodes. Typically, I would want an elegant For Loop to whistle through each connection.

From those youtube videos, I realised that each node, with a binary address, maps to another node if only 1 bit changes. So 0101 would map to 0001, 0100, 0111, and 1101. I still couldn't figure out a sweet algorithm to loop through these bitwise values. Instead, I opted for a brute force search that you run once and creates a look up table to use from there on.

Here is the source code after the break and a brief example of how it is called. You should be able to map any dimension of hypercube as long as it as the number of nodes is a power of 2 and your computer has enough memory :) Again, I can't guarantee its correct operation, but I hope it helps someone. After making the initial call, hypercube_struct_t.map will contain a 2D table. This maps the source node to a destination by decimal index.

Compile with -lm for the math.h library.

I think this needs a bit more of an explanation.
1) Construct a list of bitmasks that are single bit values. If we need 4 bits to address 16 nodes, we need 4 masks which will be 0001, 0010, 0100, and 1000.
2) Take a source node address, such as 1100.
2) Exclusive Or this with a potential target address, capture the result.
3) Logical And the result with each mask value. If any is true, only 1 bit must of changed, and we have a good mapping.
4) We need to repeat this operation between the source node address and all other addresses.

Importantly, we loop through a number of masks to however many dimensions there are, but we are only achieving the number of mappings up to the connection degree. The number of nodes grows exponentially, whilst the connection degree grows linearly. I think iterating through the look up table is an efficient method.

#include <stdio.h>
#include <math.h>




typedef struct hypercube_details {
    int max_islands;        // Will contain  how many islands (power of 2)
    unsigned int max_degree;    // Will contain the maximum degree of connectivity
    unsigned int max_dimensions;    // Will contain max number of bits for address space
    unsigned int ** map;        // mapping, 2d array : map[ an island ][ to max_degree ] 
} hypercube_struct_t;




int makeHypercube( hypercube_struct_t * hc_ptr, int islands );
void freeHypercube( hypercube_struct_t * hc_ptr );




int main(void) {

    int source, connection;

    // Create the hypercube variable    
    hypercube_struct_t hypercube;

    // Call the make function.
    if( makeHypercube( &hypercube, 64) == 0 ) {
        printf("Something went wrong :(\n");
    } else {
        

        // example usage:

        // For each node/island.
        for( source = 0; source < hypercube.max_islands; source++ ) {
            printf("Island %d connects to islands: ",source);           
            for( connection = 0; connection < hypercube.max_degree; connection++ ) {
                printf("%d,", hypercube.map[source][connection]);                
            }
            printf("\n");
        }


        // and eventually free up the memory
        freeHypercube( &hypercube );

    }



}





int makeHypercube( hypercube_struct_t * hc_ptr, int islands ) {

    unsigned int target,source,dimension, degree;
    double d_temp;
    
    unsigned int * mask;
    
    hc_ptr->max_islands = islands;


    printf("%d Islands\n", hc_ptr->max_islands);

    // The degree is how many other nodes one node connects too
    hc_ptr->max_degree = log2(hc_ptr->max_islands);
    printf("Max degree should be %d\n", hc_ptr->max_degree);
    
    // Work out what power of base 2 this number is.
    d_temp = log2(hc_ptr->max_islands)/log2(2);
    hc_ptr->max_dimensions = (unsigned int)d_temp;
    if( d_temp - (double)hc_ptr->max_dimensions > 0.001 ) {
        printf("Error: Number of islands is not a power of 2, abort\n");
        return 0;
    }

    printf("Max Dimensions %d\n", hc_ptr->max_dimensions);

    // We create a number of bit masks equal to the maximum bits
    // required to map the addresses in binary.
    mask = malloc( hc_ptr->max_dimensions * sizeof( unsigned int ));
    
    mask[0] = 1;
    for( dimension = 1; dimension < hc_ptr->max_dimensions; dimension++ ) {
        mask[dimension] = (int)pow(2,dimension);
    }

    // We create a look up table map for each island, with the
    // max number of degree entries.
    hc_ptr->map = malloc( hc_ptr->max_islands * sizeof( unsigned int *));
    for( source = 0; source < islands; source++ ) {
        hc_ptr->map[source] = malloc( hc_ptr->max_degree * sizeof( unsigned int ));
    }        


    // We iterate through all the combinations and check for just a one 
    // bit change between addresses, saving to our map table.
    // We check that we dont create more address mappings than we malloc'd
    // by tracking the degree variable.  This shouldn't happen, but just to
    // be safe :)
    for( source = 0; source < hc_ptr->max_islands; source++ ) {
            
        degree = 0;
        
        for( target = 0; target < hc_ptr->max_islands; target++ ) {

            for( dimension = 0; dimension < hc_ptr->max_dimensions; dimension++ ) {

                if( (source ^ target) == mask[dimension] ) {
                    
                    if( degree > hc_ptr->max_degree ) {
                    
                        freeHypercube( hc_ptr );        
                        printf("\n Error, found an address match beyond the max degrees, abort\n");
                        return NULL;
                    
                    } else {

                        hc_ptr->map[source][degree] = target;
                        degree++;
                    }
                }
            }
        }     }
        
    free( mask );
    
}

void freeHypercube( hypercube_struct_t * hc_ptr ) {
    int i;

    for( i = 0; i < hc_ptr->max_islands; i++ ) {
        free( hc_ptr->map[i] );
        hc_ptr->map[i] = NULL;
    }    
    free( hc_ptr->map );
    hc_ptr->map = NULL;

    return;
}

Box Guitar Part 2

2011-01-21T15:21:00.000Z

It is done! For now. I am tempted to build a small amplifier and speaker inside the body of the guitar, but I was not particularly impressed with the amplified sound (I tried it on my friends external amp), and I have heard internal amps can be troublesome with regard to feedback. If I do make a change, I might place a proper pickup onto the sound board of the guitar, rather than piezo transducers.
I was pleasantly surprised by how well the guitar actually sounds, although it is a little quiet. At least I won't disturb anybody with my playing. I was hesitant about attempting fret pins, but actually, I am picking up the intuition of correctly fretting the strings without the fretboard. By pure chance, I cut the dowel for the neck and bridge such that the action on the strings is very level, and at a suitable height for bottleneck playing.

The neck hasn't snapped yet :) A bit worried as it is pine I think, but I was looking at trees swaying in the wind and decided I will have faith in this bit of wood.

This cost me less than £10 total!

I should give a nod to cigarboxnation as I have spent a fair amount of time on their forums.

Box Guitar Part 1

2011-01-18T15:04:00.000Z

C for csv files

2011-01-04T17:37:00.000Z

I want to post some C code I have written to take a large number of .csv files and read them into memory. The code is a single function call that will assertain how many files you have, and the dimensions of your .csv file.

It assumes your .csv files are all identical in format (number of rows and columns). It assumes you are using a comma as the separator. There is no support for text fields, but it wouldn't be too hard to implement.

The code therefore automates the laborious process of importing seperate .csv files, or writing routines to open each and parse them individually. The files are stored in a 3D array, which you can simply loop through to create averages, run other stats on, or simply merge some how and write out to another .csv for something like MatLab.

When writing your program, #include "collate_csvs.h". You need to declare a typedef'd struct I have made the same way you would any other variable. You pass the address of this to the function call, providing your base file name string. Therefore, in the following brief example your .csv files would be out0.csv, out1.csv, out2.csv... etc. When you call collateCSVs, it fills in all the member variables of the csv_struct_t for you to use. If the call returns 0, something went wrong and the function aborted.

int main(void) {

    // Variable declaration
    csv_struct_t my_csv_files;
    int file, row, col;

    // Function call, imports your files.
    collateCSVs( &my_csv_files, "out");

    // Do some loops...
    for( file = 0; file < my_csv_files.num_files; file++ ) {
        for( col = 0; col < my_csv_files.max_cols; col++ ) {
            for( row = 0; row < my_csv_files.max_rows; row++ ) {
                printf("%f\n", my_csv_files.csv_data[file][col][row]);
            }
        }
    }

}

Compile the files with -c, and link to your program like:

gcc -c collate_csvs.c -o collate_csvs.o
gcc -c your_source.c -o your_source.o
gcc collate_csvs.o your_source.o -o COLLATE_CSVS

Lastly, I'm sorry if you find any bugs, or if it is not commented enough for you.
It is missing a routine to free up the 3D array from memory, I only use this code as a one-shot and it dies automatically.
It is a starting point at least :)
The source code is hidden behind this jump (a bit bulky):

collate_csvs.h:

typedef struct csv_details {
    int num_files;        
    int max_rows;
    int max_cols;
    double *** csv_data;    // Access as 3d array csv_data[FILE][COL][ROW]
} csv_struct_t;


// Function call, provide base file name and pointer to struct.
int collateCSVs( csv_struct_t * csv_struct_ptr, char * base_file );

collate_csvs.c:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include "collate_csvs.h"
#define NEWLINE 10
#define COMMA    44

double *** make3dArray( int x, int y, int z ) {
    double *** array_ptr;
    int i,j;

    array_ptr = malloc( sizeof( double **) * x );
    
    // Check for not enough memory
    if( array_ptr == NULL ) return NULL;

    for( i = 0; i < x; i++ ) {
        
        array_ptr[i] = malloc( sizeof( double * ) * y );
    
        // Check for not enough memory
        if( array_ptr == NULL ) return NULL;

        for( j = 0; j < y; j++ ) {
        
            array_ptr[i][j] = malloc( sizeof( double ) * z );
            
            // Check for not enough memory
            if( array_ptr == NULL ) return NULL;
        }
    }    

    return array_ptr;
}

int collateCSVs( csv_struct_t * csv_struct_ptr, char * base_file) {
    
    int file;
    int col;
    int row;
    int i,j;
    char buf[40];
    int c;
    FILE * fp;

    printf("\n Collating .csv files with base filename '%s'\n", base_file);
    printf("\n Attempting to find out how many files you have...\n");
    
    // We try to open file zero.
    file = 0;
    sprintf(buf, "%s%d.csv", base_file, file);
    fp = fopen( buf, "r");
    if( fp == NULL ) {
        printf(" - Could not open file 0! Assuming no files. Abort\n");
        return 0;
    }

    // We keep opening files until we run out
    do {
        file++;
        
        // If we opened the last file ok, close it.
        if( fp != NULL ) {
            fclose( fp );
        }
        
        // try to open the next file.
        sprintf(buf, "%s%d.csv", base_file, file);
        fp = fopen( buf, "r" );    
        


    } while ( fp != NULL );    

    printf(" - I found %d files (set limit to %d)\n", file -1, file);

    csv_struct_ptr->num_files = file;

    if( csv_struct_ptr->num_files < 1 ) {
        printf(" - Too few files, abort\n");
        return 0;
    }

    // We open the first file and use it to judge how many rows and 
    // columns we will need.
    sprintf(buf, "%s0.csv", base_file); 
    fp = fopen( buf, "r" );
    if( fp == NULL ) {
        printf(" I can't open the first file \"%s\", abort\n", buf);
        return 0;
    }    


    printf("\n Attempting to find out row and column dimensions...\n");
    row = 0;
    col = 0;
    i = 0;
    j = 0;
    while( ( c = fgetc( fp )) != EOF ) {
        if( c != COMMA && c != NEWLINE ) {
            j++;
        } else if( c == COMMA ) {
            i++;
            j = 0;
        } else if ( c == NEWLINE ) {
            if( j != 0 ) i++;
            if( i > col ) col = i;
            
            i = 0;
            row++;
        }
    }
    fclose( fp );
    
    printf(" - Sampled file 0, I found a max of %d columns, %d rows\n", col, row);

    // Create an array large enough to hold all of our data    
    csv_struct_ptr->max_cols = col;
    csv_struct_ptr->max_rows = row;
    csv_struct_ptr->csv_data = make3dArray( csv_struct_ptr->num_files, col, row );

    if( csv_struct_ptr->csv_data == NULL ) {
        printf(" Not enough memory :(\n");
        printf(" abort\n");
        return 0;
    }
        
    // Finally, read in the data from each file and store
    // in our array.
    for( file = 0; file < csv_struct_ptr->num_files; file++ ) {

        // Open the file to read, use sprintf to format
        // the filename string.
        sprintf(buf, "%s%d.csv", base_file, file );
        
        printf(" Opening \"%s\" to read data: ", buf);

        fp = fopen( buf, "r" );
        if( fp == NULL ) {
            printf(" Error, could not open %s, abort\n", buf);
            return 0;
        }    
        
        // Reset variables that index the arrays
        i = 0;
        col = 0;
        row = 0;
        c = 0;    
        memset( buf, '\0', sizeof(buf));

        // Read in the file data.
        while( ( c = fgetc( fp ) ) != EOF )  {

            if( c != COMMA && c != NEWLINE ) {
                    
                // We have a character
                buf[i] = c;
                i++;

            } else if ( c == COMMA ) {
                // We save the data, jump a column
                csv_struct_ptr->csv_data[file][col][row] = atof( buf );
                
                // Clear the buffer
                memset( buf, '\0', sizeof( buf ));

                col++;
                i = 0;

            } else if ( c == NEWLINE ) {
                if( i != 0 ) {
                    // We save the data, jump a column
                    csv_struct_ptr->csv_data[file][col][row] = atof( buf );
                    memset( buf, '\0', sizeof( buf ));
                }
                // We want to drop a line.
                col = 0;
                i = 0;
                row++;    

            }    
        }    

        // Close that file, ready for the next
        fclose( fp );
        printf(" - Done\n");
    }    

    return 1;
    
}

Poetry

2010-12-08T12:22:00.000Z

This morning I picked up my copy of The Narrow Road to the Deep North and Other Travel Sketches by Matsuo Basho. I missed two buses (long story) but it allowed me plenty of time to re-read. I am deeply moved by the exploits, sentiment and words of the poet; particularly some of his philosophy offered in the books introduction. I want to quote some here, and my own thoughts on the stuff.

The leaves of the Basho [banana] tree are large enough to cover a harp. When they are broken they remind me of the injured tail of a phoenix, and when they are torn, they remind me of a fan ripped in the wind. The tree does bear flowers, but unlike other flowers, there is nothing gay about them. The big trunk of the tree is untouched by the axe, for it is utterly useless as building wood. I love the tree, however, for its very uselessness... I sit underneath it, and enjoy the wind and rain that blow against it.

I really like the mindset of Basho, in that he seems to find interest and pleasure in the simplest of things, especially aspects and observations that are totally opposed to the drive and comforts of today's current consumerist society.

What is important is to keep our mind high in the world of true understanding, and return to the world of daily experience to seek therein the beauty. No matter what we may be doing at a given moment, we must not forget that it has a bearing upon our everlasting poetry.

He talks about the importance of abstracting your mind from daily troubles. Whilst he finishes with the term poetry, I feel that he is talking about our soul or spirit (not in a religious sense), our essence of being that we each carry and live with/as. I also like the passage because it does not advise to try to totally remove ones concerns from daily activity, but to try and enjoy them from a combined higher perspective. In that way, every thing can be fascinating. It reminds me of the quote, "There is no way to happiness, happiness is the way", and hints at the effect of the daily mindset on the long term good of ones spirit. "All stress comes from within".

I particularly like a section where he describes the role of self when writing poetry, but again I feel like it talks about the soul:

Go to the pine if you want to learn about the pine, or to the bamboo if you want to learn about the bamboo. And in doing so, you must leave your subjective preoccupation with yourself. Otherwise you impose yourself on the object and do not learn.

I think this is interesting, because I often think of how my 'self' influences my perception of art, and I take it as an exercise to attempt to view art from as many other imaginary persons view points as possible, to perhaps catch a glance of the original artists own mindset. Projecting oneself (or a fictitious character) is a common discussion in human-robot interaction. The natural world however, is not a work of art, or a product of humans; it has existed far longer than humans and will likely out last us. I feel like if we are to find our place in the world, then we must view it for what it actually is, and then only afterwards reflect on what our role and identity is. The interjection of our experiences and existence would only undermine the foundation of understanding.

Your poetry issues of its own accord when you and the object have become one - when you have plunged deep enough into the object to see something like a hidden glimmering there. However well phrased your poetry may be, if your feeling is not natural - if the object and yourself are seperate - then your poetry is not true poetry but merely your subjective counterfeit.

In the above, I feel like he is saying that with a greater, unobstructed, understanding of the world, your soul will be truer, more apparent in oneself, and lead to a happier more meaningful life. I think literally, he speaks of it being easier to write poetry when you are better integrated with your world - but surely poetry is the product of the soul (not simply brute force intellect)? The parts 'However well phrased...' and '...your subjective counterfeit' make me think that if you try to exist with presumptions and arrogance of self, no matter how well you pull it off, it will eventually undermine your well being.

I can think of many contentious issues - to be vegetarian, the desire for ownership and material possessions, the necessity of warfare - that seem to stem from self-importance and a dislocation from reality. But I feel like even at a lower individual level; awareness of human beings as fallible creatures, existing for an infinitesimally small period of time, in a world without morals and reason, a world full of uncertainties and unknowns; and an appreciation for the startling beauty of the natural world; can lend to a happier state of mind.

As I climbed one of the foothills called Takadate, where Lord Yoshitsune met his death, I saw the River Kitakami running through the plains of Nambu in its full force, and its tributary, Koromogawa, winding along the site of the Izumi-ga-shiro castle and pouring into the big river directly below my eyes. ... many a feat of chivalrous valour was repeated here during the short span of the three generations, but both the actors and deeds have long been dead and passed into oblivion. When a country is defeated, there remain only mountains and rivers, and on a ruined castle in spring only grasses thrive. I sat down on my hat and wept bitterly till I almost forgot time.
A thicket of summer grass
Is all that remains
Of the dreams and ambitions
Of ancient warriors.

#pragma pack(1)

2010-11-28T16:37:00.000Z

Recently I have been moving towards conducting some experiments on the robots. This is the real thing this time, and I intend to have everything run smoothly and as well organised as possible. I am expecting the results of my coming experiments to become a significant part of my final thesis, so I need to do all I can to have a comprehensive set of data. I have been debuggging from the microcontroller upwards, and moving all my code to a proper repository in the lab.

Today I found a nasty bug at the linux board level. I had been transmitting data between the robots (epucks) and my PC over Wifi (using sockets) and found that if I did not organise my data structure in a specific way the operation would fail. The data would get across, but be jumbled or offset in a strange way. For a one off experiment, I could turn a blind eye and simply to get it work with some hacking. But not now. I need it to work reliably and so that I can expand its functionality quickly.

It turns out to have been a memory packing problem that occurs at compile time. The first clue was a sizeof() on the data structure, which came up as 48 bytes on my pc and 56 bytes on the epuck. If I did a sizeof() to each of the structure members, and manually added up the result, it was the same (48) for both machines. If I set the size of the structure manually when performing the transmit call, it failed. So I had to find out why the epuck was reading the structure as 56 bytes.

The solution was a #pragma pack(1) at the top of my include file for the data structure. This line tells the compiler to pack the data in memory in a specific way. It seems that the word size of a processor prefers to have data in a certain format (for optimal processing?), and this is different for the epuck and my PC. So even though the members of the structure added to 48, the epuck was packing it out in memory to 56. #pragma stops this from happening.

I am sure there is more to it than this, because thousands of differing machines communicate over the web every day. However, the epuck is a bit of a special case, it is not using a processor you would find in a laptop or desktop machine. So I can forgive it, and add that niche feather to my hat. The epucks can now communicate bug-free over WiFi!

Interface C to Processing over TCP

2010-11-10T12:25:00.000Z

I use Processing to do a lot of visualisation and general hacks (we used it in Milk Pixel), but I do the majority of my work in system level C. I was looking for a quick way to send data to Processing from the command line and took the Network/TCP route. This code might also be useful for anyone looking to interface a Processing application with another program over a network, or simply create a C program as a command line interface between Processing and yet another program.

It is normal for every PC to have the network loopback device 'localhost', or to regard the IP address 127.0.0.1 as itself, regardless of whether you have an external network connection available. So we can use that to transfer data between programs (albeit, with a fair bit of overhead...).

Processing provides example code to create a TCP server and client, all neatly wrapped up in cosy layers of Java. You'll need to run the example server. It accepts strings of data as input, and the example code uses port 5204. This can be changed, but for simplicities sake, here is some C to talk to that configuration:

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h> 
#include <unistd.h>
#include <stdlib.h>
#include <string.h>

#define PROCESSING_HOST    "localhost"    // When on the same machine, otherwise IP
#define PROCESSING_PORT 5204        // Match this to your processing code

int sendProcessingMessage( char * msg ) {
    int sockfd, n;
    struct sockaddr_in serv_addr;
        struct hostent *server;

    // get socket
    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    if (sockfd < 0) {
               printf(" pro_client.c: Error opening socket\n");
        return -1;
    }

    // find host
        server = gethostbyname( PROCESSING_HOST );
    if (server == NULL) {
               printf(" pro_client.c: Error contacting host\n");
        return -1;
        }

    // fill in struct
       bzero((char *) &serv_addr, sizeof(serv_addr));
        serv_addr.sin_family = AF_INET;
      bcopy(     (char *)server->h_addr, 
             (char *)&serv_addr.sin_addr.s_addr,
             server->h_length); 
    serv_addr.sin_port = htons( PROCESSING_PORT );
    
    // connect
    if (connect(sockfd,(struct sockaddr*)&serv_addr,sizeof(serv_addr)) < 0) {
        printf(" pro_client.c: Error connecting\n");
        return -1;
    }

    // write data
       n = write(sockfd,msg,strlen(msg));
        if (n < 0) {
            printf(" pro_client.c: Error writing to socket\n"); 
        return -1;
    }

      close(sockfd);
      // return success
    return n;
}

It is pretty much any old tutorial on C sockets, but it has the right settings to mesh with the Processing configuration.

I hope this helps somebody :)

Computer Science Humour

2010-10-04T14:55:00.000+01:00

Looking for a sort algorithm, I came across this on Wikipedia today and it made me smile:

Quantum bogosort
An in-joke among some computer scientists is that quantum computing could be used to effectively implement a bogosort with a time complexity of O(n). It uses true quantum randomness to randomly permute the list. By the many-worlds interpretation of quantum physics, the quantum randomization spawns $2 N$ (where N is the number of random bits) universes and one of these will be such that this single shuffle had produced the list in sorted order. The list is then tested for sortedness (requiring n-1 comparisons); should it be out of order, the computer destroys the universe - implementation of this step being left as an exercise for the reader.^[2] The only observers will then be in the surviving universes and will see that the randomization worked the first time and that the list is in sorted order.
Note, however, that while this algorithm is O(n) in time, permuting the list requires O(n log n) bits of quantum randomness. (It also assumes that destroying the universe is O(1) in operation - since it has to be executed at most once.)

The Future of Robotics and Me

2010-10-02T20:18:00.000+01:00

On Friday 1st October I had lunch with academics from a multitude of disciplines hand-picked to take part in a discussion on the ethical issues surrounding contemporary robotics. Friday was the third and final day, and I think the most satisfying in terms of feeling like we had achieved something. I was priviliged to be there, and most certainly the smallest fish in the pond. However I feel confident that even as PhD student, I contributed significantly to the development of the groups ideas. My networking skills still require much practice, but I think I did well to speak my mind and contribute appropriately, so I feel as though I was noticed. One compliment I received was that it was assumed I was the Oxford Uni post-doc because of the frequency and quality of my contributions. This was highly flattering!

( fullscreen )

I think there were a few more gains for me personally. A question I was asked many times was 'what will you do when you finish your PhD?' which at first I had a little trouble answering. There is an obvious answer (continue research) but I was rather open in stating that I have a burning desire to travel, and not knowing precisely if academia was for me given I am still in the middle of this new experience. I think the root of this uncertainty was perhaps not knowing what my place in the field was and what the value was. After three days discussing the issues of ethics and how to communicate effectively with the public, I came to realise that perhaps a higher meaning/value in my work is in fact to use my fortuitous placement within the research community to contribute in steering the future of the technology and also to communicate science. It seems ambitious to remark on steering the technology, but if we as scientists do not each take on this responsibility, who will?

And so on leaving on the third day I felt remarkably inspired. My research is not just about producing potential future technology, but it is about carving out a place for me to do something meaningful. Furthermore, my developing skills and abilities are not just useful assets, but enabling. It seems as though I should not ignore the abilities I am gifted with, and in which others have invested to develop.

There is so much more I want to talk about concerning the three days, but I think I will post my thoughts on serpate issues individually. In the photobox above you can see some of the scenary we were in. When I attended the TAROS conference a month ago I did not seize the opportunity to explore. This time I was equipped! I went jogging one morning and broke out into a clearing, startling some deer. The second morning I used the swimming facilities and took my first sauna. Jogging shoes and swimming trunks will now be mandatory travelling equipment.

So now I just have to resolve my inner conflict with travel intentions :) All in good time...

Problems with Signal Hopping

2010-09-22T15:04:00.000+01:00

In my last post I mentioned that I was having some trouble with my gradient hopping algorithm, that the evolutionary algorithm would always optimise away from it, instead prefering a blind foraging algorithm. I listed a couple of areas that could have been going wrong, and this past week I brute forced my way through most of them. Well here is a brief follow up of what I discovered and what I intend to do now.

So, if I didn't explain it before, the IR transmission has a limited range, approximately 2 robot body lengths. This means a gradient is formed from a food source across the arena only when robots are within the transmission radius of another signaling robot. If there is an open space, transmission is lost. This means that unless the robots are densely packed within the arena, a gradient will not form, or at least, not extend very far. Robots can only detect food when they are on top of it, so the gradient is essential to increase the perception of the swarm and improve foraging efficiency. However, in a sparsely populated arena it is better to move quickly (even with a velocity penalty ) because signaling rarely has a benefit.

So logic dictates we should densly pack an arena with robots. This is what my inspiration paper did, placing 1000 robots in an arena. However densly packing an arena with robots has a few problems in itself. First, robots will struggle to navigate. This means that it is better for robots to move slowly, to give themselves more time to detect and avoid collisions. This is a problem for me because it means it takes a lot of simulation time to evaluate a solution, and I need this to be as quick as possible. Slow movement still requires a computation, and more computations (total) to achieve something.

There is also a problem with a densly packed arena because we require two conflicting directions of robot movement, not just random movement. In this case, the best solution is almost certainly for all robots to follow the wall of the arena in a uniform direction to collect and deposit food. If we look at ants, they construct corridors of foraging (a bit dense, but this paper explains how) to minimise collisions and traffic jams. But their pheremone trails are persistent and reinforced, unlike the signal gradient I have been working with, which gives them something to construct a corridor around.

When a signal hopped gradient forms, it is important that the transmission and recieving periods are asymetrical. The reception of signal must be blocked for a period of time. This is required because otherwise the retransmission by neighbours feeds back to the initial sender, and a positive feedback loop escalates the signal hops into infinity. Furthermore, the gradient becomes self sustaining and not dependent on the location of food as a trigger.

This positive feed back loop requires a bit of thinking, but it is mainly because of the time it takes for a robot to receive a signal, and because the robots are not 'clocked' in perfect synchrony. Robot A can signal robot B, and then Robot B can signal back to robot A (this is without a time period blocking mechanism). With a blocking mechanism, signaling becomes momentary, and usually the source robot has since moved away from food and the gradient is lost. This can be partially solved by slowing the movement speed of robots, but again, this is a computationally costly solution I don't really want.

I tried making sure the robots always took the lowest signal to hop (the food will be lowest), but isolated groups form that aggregate on their own phantom gradient. The important thing is that with signal hopping, the navigation aid is temporary and transient. Robots can only alter their navigation based on a single moment of information, unlike a persistent phereomone trail towards food. I have been unable to successfully route traffic on a transient signal, robots typically move towards food, collide, and disperse randomly.

All of the above had me thinking about a bigger problem. What happens when the robots are not constrained to an enclosed environment. What if we want robots to work in space, at sea or pretty much anywhere in the real world? Any kind of limited range signal hopping is going to have problems unless the robots stay relatively clumped up together.

I think this is drawing to an important point, question or train of thought. Signal hopping is really a form of communication between robots and it is transient. Laying down pheremone trails is persistent, and it is actually more like writing something down. So, when we look at swarm systems, is it more important/useful to write things down, than communicate them? Sure, it is possible to construct a swarm system based on transient communication, but can we evolve behaviours out of it? It seems like a mechanism which is too delicate, not robust, and needle-in-a-haystack when it comes to evolution.

So now I am going to take a look at some pheremone systems, and implement a virtual pheremone system for my robots, to see if that is more functional with my robots.

Bumpy road

2010-09-13T18:32:00.000+01:00

I usually update when I feel like I have achieved something but today I thought I would update whilst things are in the perplexing development stage.

So I have been working on implementing a slime-mould inspired aggregation algorithm to get the robots to forage for food. If you've not heard of the slime-mould, check out this article on Wikipedia, particularly the life cycle diagram. They have a fascinating level of intelligence. The paper I am using as primary inspiration is here, but I'm afraid I can only find that google preview with free access.

So in principle I have everything working. My robots explore their environment and when they find a food source they broadcast a signal in all directions. If another robot receives this signal, it adds 1 to the value and broadcasts this onwards. A chain of robots creates a virtual gradient toward the food source, the location of which would otherwise be unknown to the robots. One problem I came across was covered in that paper, requiring two gradients to allow robots to navigate upstream and downstream (with one gradient, outgoing robots collide with the incoming robots).

So since I had this working with my hard coded, guessed parameters, I thought I would get a genetic algorithm to optimise it. The result? It optimises NOT to use the gradient signalling mechanism. In other-words, the search algorithm finds solutions that work better when the robots blindly forage for food. How could this be? Well, there are a number of ways in which the system as a whole could be failing:

The simulation is flawed:

Perhaps I haven't coded the signalling mechanism properly?
I might not be giving enough simulated time for a solution to be revealed.
The simulated environment might not promote the 'solution'.

The genetic algorithm representation is flawed:

Perhaps I have isolated the wrong parameters to evolve?
The metric which measures the utility of a solution could be rewarding the wrong aspect.

The 'solution' is flawed:

It could be that the distance at which the robots can signal is insufficient to benefit them.
The way in which the robots move and navigate interferes with the signalling gradient.

And so this is a familiar situation for me. If you look at literature concerning evolutionary algorithms, you will often see the development times to a solution quoted in the number of evolutionary generations, but not the months of tweaking that go into getting the algorithm to work in the first place.

I'll let you know what the fix is.

New Brains, New Visualisation

2010-09-07T09:43:00.000+01:00

Whilst I was at the TAROS conference I put my mind to work on how to control the robots in the swarm with a behaviour based controller (or state machine). One of the problems I get hung up on is the relative simplicity of the robots, and therefore the very limited set of states they can exist in. Of course, this should be a good thing I guess, since it reduces the extent of the design problem. But I also find it hard to conceive a useful product of these simple interactions. What can simple robots actually do?

Anyway. I have been hard at work implementing some support infrastructure for my experiments. Earlier I mentioned that I had enabled the epucks to communicate over WiFi, by handshaking with infrared. I have used a similar idea to allow the robots to perceive areas of the arena as 'interesting'. Each robot runs a WiFi component that checks with my desktop pc if it is within a specified area, and updates a virtual sensor. On my desktop pc I simply create a text file which contains the coordinates and size of how ever many areas I want to create. I can set a value in these areas to signify something important, such as 'nest' or 'food', or maybe even the value of food available to the robot.

This method greatly improves the capabilities of the robots, creating more behaviours and states. It is an abstraction, but I am coming to terms with the fact that the robots will never operate outside the lab anyway, so why make it harder?

So whilst I was at TAROS I decided to code the simulation counter part. My work relies on robots using a minimal simulation whilst they operate, so I had better be able to simulate the same thing! Once I had this done, I set about programming a new behaviour based controller. When things weren't working as expected, it became clear I needed a new method of visualising the numeric output of the simulator. Processing stepped in :) One of the best things about processing (other than rapid development times) is the fact it will run on any operating system.

The picture above is the new visualisation for my simulator. It is much prettier. Importantly, it contains the 'virtual' areas (green and blue : food and nest), and give a clear visualisation of the robots interacting. I can now see a robot avoiding an obstacle (black circle). The blue halos are the infra-red signals. The white numbers is the value being transmitted. In the above image, the robots have used signal-hopping to form a gradient towards food. Robots with a green ring are carrying a food item. It is still work in progress, but it is much more swarmish. This visualisation is much more flexible, allowing me to define how many robots to represent, how many obstacles, etc, etc.

Since I have been developing a new controller, I decided to change the way I operate the epucks too. Now the controller resides on the Linux board, and drives the epuck (previously, the controller parameters were transferred to the epuck, where the same controller was mirrored). This removes the bottle neck in transferring data. The only downside, is with all these extensions to my idea the Linux board is getting very highly computationally loaded and I need to verify the development times.

On a side note:

I have always been fond of GOAP. It is a method of constructing finite state machines from a goal perspective. It is a relatively new method in computer game AI that takes the programming load off the developer. They create a pool of behaviours/actions that have prerequisites and costs. They then assign the behaviours to the 'bad guys' that seem appropriate. Whilst playing the game, each bad guy does a quick search through its allocated behaviour set to meet it's own current goal. This means that the statemachine does not have to be programmed for each enemy in the game. It does rely on determining an acurate state... I have been thinking about GOAP a lot, but I have not found a way to implement it in a swarm. Yet.

Stop Motion in Ubuntu

2010-09-04T15:15:00.000+01:00

I had to capture a video of the robots performing a task over about 30 to 40 minutes. A video of any quality at that length would be very long. Instead, I used the stop motion technique. I usually do this in Windows, but the web camera I have is a pain in the butt to get drivers for. So here is how I got it all working together in Ubuntu.

Install fswebcam

I had to download the source tarball from http://www.sanslogic.co.uk/fswebcam
tar xzvf
I had to install gd library

sudo apt-get install libgd2-xpm-dev

./configure, make, sudo make install

Install Mencoder

sudo apt-get install mencoder

Write a program/script to call fswebcam

I wrote a C program to call fswebcam, with a sleep argument. Not particularly precise.
Something like: fswebcam image%d.jpg
Write out your image files sequentially.

Note, buffer the numbering to maintain a logical directory listing. E.g. image0001.jpg, image0002.jpg ... for up to 9999 images.

Run mencoder to bring the files together into a movie.

I placed the following into a .sh file:
#!/bin/sh

mencoder mf://*.jpg -o out.mpg -ofps 25 -vf scale=352:288,harddup -of lavf -lavfopts format=mpg -oac lavc -lavcopts acodec=mp2:abitrate=224 -ovc lavc -lavcopts vcodec=mpeg1video:vrc_buf_size=327:keyint=15:vrc_maxrate=1152:vbitrate=1152:vmax_b_frames=0

Technical Progress

2010-07-07T14:57:00.000+01:00

( Sorry for the text heavy update, and inconsistent references to things I haven't even mentioned before. )

Soon I am going on vacation to Russia. A week ago I had my first scientific paper accepted to the TAROS 2010 conference. I've been working on the corrections for the paper, but over all I am not particularly happy with it. However, in the peer review I had some good comments:

Relevance: how well does the paper fit within the scope of Towards Autonomous Robotic Systems?: 4 (Appropriate)

Correctness: Does the paper appear to be flawed technically and/or methodologically?: 4 (The paper is technically good)

Novelty: How novel is the approach?: 5 (Very new, never seen this before)

Working systems: has the work been implemented in a working system?: 3 (Some technical evaluation, fair demo.)

Clarity: how well is the paper structured and presented?: 5 (Presentation is very clear)

Should this paper be considered for the best paper award?: 3 (definitely)

This is a well written and presented paper. The research question is well described and elaborated. The results are interesting and should lead on to further work of possible considerable significance.

I am bad at rewarding myself. I have some criticisms, I know I can do better. I know the next paper will be significant.

So before I set out for Russia I have been working to update my methodology and implementation. This means coding! I have not indulged in coding for a long while because I am very aware that I have a habit of tinkering, when I need to be producing results. Today I have finished implementing the ability for the robots to communicate with each other over WiFi. There are several advantages. The most important for me is the ability to observe and control a greater number of the variables in my experiments.

However, in the paper I published the robots communicated using infrared (IR). I was maintaining an emphasis on using only the available hardware, and also to adhere to the swarm principles of local information. The infrared only works over a distance of 2 robot body-lengths. Unfortunately, it is very unstable and can only transmit 16 bits of data at once. This is a very tiny amount of information. I was using the 16bits in two halves, using the least significant 8 bits to transmit a gene value, and the most significant 8 to transmit which gene was being sent. This meant that two robots had to transfer their genetic encoding gene by gene.

This was a very slow process, and whilst it was sufficient for my early work I was anxious about the future prospects. At this stage, a gene was a single whole numeric value. But what if a gene becomes a state-action, or a real value with a decimal precision? The other anxiety was how hard it was to track communication between robots. In a gene by gene transfer over IR, there was no room to transmit the ID of who the data came from, and no way to ensure data only came from one robot. In other words, my experiment had a significant variable that I could not trace or control; robots were engaging in multi-partner mating! A genetic sequence could be composed from many sources. You could view this as a nice 'feature', but there was no way to judge its significance or impact.

So, as I mentioned earlier, I've just finished implementing communication over WiFi. The greatest advantage to this is the vast amount of data that can be transmitted between robots exceptionally quickly. This means I can send the *entire* genetic sequence and any other information I fancy in one instance; such as who the genetic sequence came from (making communication tracable), the fitness/utility metric of the transmitted genetic sequence, I could even send the parameters of the simulation environment that each robot is using (if they happened to change between robots...). A lot of this might not make sense if you haven't spoken to me about my research in person - apologies. But robots being able to say more to each other has strong potential.

The downside to WiFi is that the potential range is vast compared to the 60mm robots. Using WiFi also presents a problem of how do robots initiate dialogue because it is not a directly observable quality like IR transmission. When using computers, we use URL's or IP addresses to contact another machine because we know who we want to talk to. But the robots are supposed to be exploring and conversing locally in an unplanned manner. Subunits in a swarm generally don't communicate over such large scales, the robots shouldn't be able to check up on each other when ever and where ever they feel like it. It may sound like I am imposing constraints (making my work harder!) but in reality it is a necessity for my research domain.

I had a number of options to solve this problem. We have a tracking system that can monitor the movements of the robots in the arena. Option 1 was to hack this system to allow robots to be aware of other nearby robots, and therefore start communicating. Using WiFi, i could create a virtual sensor for a such a purpose, but it requires quite a work around. Instead, I decided to first try and use the already functioning IR communication, this way, robots can observe the local presence of another robot by directly receiving an IR transmission. This transmission contains the IP address of the IR sending robot, allowing the receiver to initiate conversation back over WiFi. In so doing, we have WiFi constrained to locality. Backwards enough?

In getting the IR initiated WiFi to work, I improved the stability of the IR by reducing the data length to 8 bits. 8 bits gives me 256 numbers, which is the range of a /24 subnet domain, and more addresses than robots we have available. Reducing the IR to 8 bits improved the speed and stability in transmission (less corrupted data) and consequently the speed at which the IR code executes. All of that that takes place on teh DsPIC board controlling the robot. Unfortunately, depending on an instant of IR communication, and transferring this data up to the Linux Board over the SPI bus revealed a bug which hadn't been a problem - the stability of the SPI bus between the two boards! ARG! After two days of reverse engineering I had this fixed.

At this point I made another decision which I like. If you are getting a sense of the overwhelming details contained in my research, I am glad. Instead of allowing robots to communicate over WiFi with each other directly (robot to robot), I decided to write a program to mediate the communications. Basically, I wrote a server to act as a telephone exchange between robots. My reason for this was to allow me to track communications, but it has a secondary benefit of allowing me to track the evolutionary progress of each robot. As my robots evolving their controllers, they update their progress to my server. My server program maintains a database of each robots progress. When a robot requests communication with another robot, what it actually receives back is the last update from that robot stored by the server. This way, I see who is talking to who, and I have the evolutionary progress of each robot stored in one place.

During this work, I exposed another problem. Very occasionally, the WiFi communication to the server stalled and failed to receive a response. Consequently, the linux board waited indefinitely for a response from the WiFi and the SPI bus stopped operating and the actual robot stopped working. Occaisionally sounds managable, but if I am trying to control the number of robots in a group, and some 'occasionally stop', it ruins everything. Fortunately, I changed the default WiFi protocol to instead timeout and make a couple of retries to communicate, which fixes that problem. Phew.

Lastly, I did write a program to hack the motion capture system a long while ago. So I thought I should squeeze this in too. So, when a robot communicates with another, I also store their relative positions in the arena. This should allow me to conduct analysis of such things as frequency of communcation versus the spatial distribution of robots, or even check for erronous instances of communication. Because all of this is a computer program I have written, I get it to store all of this data in a format I like (comma seperated) to the harddisk, which I can then import to proper data analysis tools. So now the data for all the robots in the swarm (potentially 52 working autonomously) will be logged for my convenient review at a later date - at the press of a button!

I had concerns about abstracting some of the functionality of the robots to an external system, but I think the reliance on IR keeps it credible. So yes, the WiFi packets are routed through an external system, but you could have ad-hoc WiFi. Again, WiFi requires IP addresses in a system which should be ID-less (and decentralised...), but its not a problem in my experiment scenario. Can I assume technology will significantly improve in due time? I think so. I can hear Alan telling me not to make my PhD harder than it needs to be, and futhermore, as he advised, I have weighed up the pro's and con's of abstraction and found a solution which benefits the swarm (still localised) and me (lots of data to analyse).

I will try and draw a diagram of all the components of my system and post it on here. I think I remember Linus Torvalds remarking that a good programmer is measured by their ability to maintain the logic and struture of a problem in their mind. I'm not sure if I can get it all out.

I'm pleased because I have produced a significant amount of work in the lead up to my vacation, that means the remainder of my summer should be highly productive. I am excited to get a paper published that I am proud of!

Sorry for the text heavy update, and inconsistent references to things I haven't even mentioned before.

Talking Robots

2010-05-05T14:43:00.000+01:00

And it could get messy.

In that picture above 6 of the e-puck robots are communicating with each other over infrared. They are actually trading solutions to a problem that they are trying to figure out. Six robots is the most I have tried this with and unfortunately I did not get any significant findings - this time! This photograph really reminds me of one of my favourite episodes of Star Trek as a kid: The Quality of Life. In this episode they find 3 sentient robots that work together to solve problems (I seem to remember them having replicators to manufacture the tools they required in real time!). On days like today I realise I am fulfilling my dreams. Sorry about the bad quality picture. And the dirty yogurt pot. And the empty lunch box.

Oh, and check out this photo of my computer screen:

That is the interface into each robots' brain. It was pure lucky convenience that I had defined 6 colour schemes from a previous experiment.

I just had a supervision meeting with my second supervisor and it has made me quite nervous. After discussing all my exciting results and avenues of research I was cautioned that I have actually created a massively complex solution/scenario. One that might be extremely difficult to investigate empirically, to prove exactly what is happening within the system. It is a very wise caution because I know it is true. But sometimes you have to have something said at you to fully realise it.

I regularly struggle to keep all the elements of my ideas in a coherent form in my mind. At some point I need to take the time to step back and think about exactly what I am trying to investigate and/or prove. Scarily, I am over half way through now, so its about time I really considered my Thesis and the structure of work I intend to make. This caution at the end of the meeting made me chuckle as last night Lana was expressing the fact that she fears she might struggle to understand my work, despite her best intentions. Well, it seems like everyone does/might!

The meeting aside, I am feeling very motivated at the moment. I went to give a presentation at the BITE center in NE London on PhD life. It went very well. It was reassuring to hear the other PhD students all talk about how much of a 'lonely journey' a PhD can feel like. I was also proud of myself as there was some questions given to previous students that were left hanging open, so before I started my own presentation I addressed these prior questions and received a round of applause. Maybe I can be good at presentations!

Milk Pixel is on the road! If you are about in Bristol this weekend we will be at the Glass Works for your amusement. Potential Indifference - Milk Pixel

My side project with Extant is starting to go live, which means I can talk about it! Check out the Extant web page (and my small mention!) and the official page for the up-coming production (has nice pictures!). This has been a good project and now the finishing line is in sight. I have to admit that I am very excited about having my free time back. Come June, all my current side projects shall have come to a close, leaving plenty of time for surfing :D

I should really put my biography up on the Bristol Robotics Laboratory webpage.

Ladybirds

2010-04-20T14:50:00.000+01:00

Its been a while since I made a post and I think that is because I have been meaning to post about progress in my PhD, and I haven't felt there has been much. Its been a long dark winter for me.

To break the ice, I will post some photos I took recently of ladybirds. They had taken up residency in my flat for the winter and with the warmer weather awoke from their deep slumber. They were trapped inside the living room behind the windows. I scrapped them into a box and took photo graphs of them taking flight. I like the results!

I'm still figuring out Flickr. The interface doesn't seem obvious to me, is it just me?

Here is a link to a slideshow which will resize the photos to your screen size, i think: Slideshow

I really like the first image, where you can see the fully unfurled wings of the ladybird. Isn't it great that beetles can fold their wings up into that protective casing?

tagged!

2010-03-05T14:31:00.000Z

Claire tagged me in a random photo thing. I don't have that many connections here, but I'll tag adam, perchance he reads this and has a minute of time ;)

The game?

1: Open your first photo folder,

2: scroll to the 10th photo,

3: Post the photo and the story behind it,

4: Tag 5 or more peeps to continue the thread

Well, it could of been a lot worse!

My first folder is 101MSDCF, because thats the folder my camera creates and I'm a lazy filing person. That was the graduate show of my undergrad course. It brings back memories! Those two robots balance like the segway, they were made by my friends Paul and Gary. They both succeeded, and we joked that they should get their robots to joust. My robot was on the side somewhere. By this stage I was so sick of the thing I didn't want to be within 100' of it haha. It was gloriously sunny, so I went and drunk lots of free wine in the courtyard. Its a shame, the preceeding and next photo were group shots of various friends haha. That was over two years ago... how time flies!

Journal

2010-01-29T16:43:00.000Z

I decided to make a book. I briefly looked online for a general how-to's, because I wanted to make quite a fat book so it didn't seem imediately obvious. Figuring it out is half the fun though. Here is the result!

I like its fatness. It is like a tome. I like the way the pages don't match up, it looks rough-cut and natural. I used too much PVA across the cover, hence the damp looking patchiness, but it gives it a used/homemade feeling I like to think.

It was actually very cheap to make. I bought an A3 sketch pad and cut it into roughly A5 pages, and used the hard cardboard backing of the pad to make the cover sheets and spine. The brown fabric is a bedsheet from primark, for about £3 (of which, there is plenty left).

The bit I was quite excited about trying to make was the bridge in the bind on the spine. The book is so fat, it has to be detached from the cover along the spines length to open properly. Here is the effect we are all no doubt familiar with:

Although, not a particularly clear image. Also, you can see the stitching I used to bind the leaves into bunches. I didn't feel particularly pressed to make it a neat job, or keep the looping hidden within the spine. Only time will tell how long this book will actually keep together!

Musical Jam

2010-01-17T11:51:00.000Z

Last night I went to my friend Pauls' house and my friend Ben came along too. Between us we had a guitar, bass acoustic, trumpet, saxophone and harmonicas. It was the first time I had tried to simply create music with other people and it was really quite hard!

It was like making jam actually. We had all these ingredients (each of us with differing taste in music) and we had to keep putting energy in to get it to eventually set. I have to admit that Ben and Paul were much better with their instruments and at collaborating/improvising than me. It reminded me of dancing - at times I was just overwhelmed with what was going on. A slight hesitation on my part meant I [felt like I] would have to wait a whole bar to come back in again.

In that one evening I learnt alot though. My trumpet is in the key of Bb, and Pauls' sax was in something else. We had to sit down and work out how to transpose (?) each instrument. I also learnt what a 3rd and 5th is, and generally some good practice on improvising under pressure. Oh, and relaxing about making mistakes, and just finding a way back into the music. Meeting up and playing with people has also given me a lot of motivation to keep practicing.

I am really excited for the next time, these are my first steps into a band!

Maow-maow

2010-01-07T14:14:00.000Z

That is my cat.

On cold winter days she likes watch the world from the cosy comfort of the living room. But it makes me wonder, does my cat have idle thoughts? Or is it simply waiting apprehensively for the next exciting creature to flutter around on the bird table? It wouldn't make sense that her mind could be so occupied with observing prey that she wouldn't want to be out there physically chasing them, devouring their brains.

I sat and watched her, what could be going through her mind? And would it be in cat speech? I guess assuming everything has an inner monologue is a very human thing to do, but it amuses me.

She is also getting too old to be territorial, especially when there is so much snow outside. Eventually she has to leave the house to relieve herself, but immediately after she comes back in to warm her paw-pads up on the surface of the boiler.

Recently she has begun to wail like a banshee. She does it when she wakes up, like she is suddenly aware of being all alone. Maaaaaaaaaaaooooooooow.

Succulents

2010-01-04T23:45:00.000Z

So I collect succulents. Plump, fleshy and water retaining. A sister to the cacti, but they don't have spines. I have about 8 types now I think, but recently one shed *all* of its leaves :( They are normally incredibly robust, I'm not sure what happened to this one. Anyway, so I picked them all up and I have managed to coax the majority of them into spawning roots. Check out these photos:

A box of creation:

Its a marvel (of design?)

In all truth, they are not hard to stimulate into new growth. When I was around 13 years old I used to visit my friend Alex and we would play computer games for entire days on end. This is where I got my first succulent. I wasn't sure what it was, but it was certainly curious. I snapped a branch away (I'm so sorry Mr Tree) and took it home to plant it. Since then it has spawned many offspring (with my further help!) and grown to about 2 foot tall. Unfortunately I only have a tiny sapling of it in Bristol, but it is sure to grow into a healthy specimin. Ironically, Alex and I don't talk anymore, and yet that plant is commonly known as a friendship tree. heh.

The fantastic thing is that they seem quite happy to grow from only a leaf! Imagine that, if something of my body could simply replicate entire form, and only with the resources that remain to start it off! Why do people fear self-replicating nano machines? We already live with them :)

I find a good technique is to lay the leaves out on a moist tissue (in a tray, i would advice) and place it into a dark cupboard for a while - it should spawn roots. Check it and give the tissue some moisture every now and then.

That one above isn't a Friendship Plant, I'm not sure which it is! I will have loads spare soon enough if anyone would like a baby plant to nurture.

Milk Pixel, Lantern Robot and the Arnolfini

2009-12-14T10:13:00.000Z

We did it!

...just. What a manic last couple of days. We almost didn't pull through because aspects of the milk pixel project were left to the last minute. However, alls well that ends well. Here are some photos:

(Left to right) Paul O'Dowd (me), Adam Spiers, Tom Burton. Other group members not in the photo are Jason Welsby and Richard Craig. In the background, Milk Pixel! And if you have a keen eye, the robot in a lantern is on the desk :) The project was placed in the darkroom theater and provided visuals next to live music, spoken word and a series of short films projected onto the wall. The array of milk bottles visually reacted to sound and movement.

A bit of an abstract photo. You can see all the wires going into the milk bottle caps. This is where the RGB LEDs were located. Thats 192 pins to toggle to build an image. We used 8 CAN bus nodes to control them, although this almost didnt work. Tom and I built a multi-plexer (out of CMOS logic AND gates!) to do the same job that was driven by a single microcontroller. So we had control of the 192 pins through 6 pins of the microcontroller. I liked the old-school approach of our technique! It didn't get used, but I did some serious coding over 3 days for that chip - so its well broken in now :)

So thats how the little lantern robot ended up looking. I sprayed the thing gold and dry brushed it over with some black paint. Notice the RGB led on its back. This changed colour depending on what it was doing.

Throughout the exhibition I placed the completed lantern robot on the desk at reception. It got some really good exposure! And I didn't have to change the batteries. I got good comments.

Thats a shot of the thing in the dark room theater. I managed to get the robot to walk forwards, jump backwards, head-butt the glass, sit down, fall over and shake itself. Quite a behavioral repertoire! I actually ran out of storage space on the chip. I didn't figure out a good way of doing a random number generator, so instead I created a large table of random numbers which it indexed through to select behaviours. It also used the same table to decide how long to perform any of its behaviours. fun fun fun.

Robot Lantern II

2009-12-04T14:58:00.000Z

Progress!

I picked up this glass jar in Habitat today. It has a nice shape, slightly wider at the base but perfectly smooth with rounded edges. There is also no emboss on the base, which could turn out handy.

The jar is stoppered with cork. This was an intentional find. The next job is to bend some thin brass rods to push into the cork, which will form a cage effect around the jar. The rod I have in mind wont reach all the way around the jar, so i have to think of some way form a junction. Maybe some folded sheet brass.

At the moment I am unsure if I want the jar upside-down to allow the robot to walk on the cork, or the correct way. I think there are several good reasons for the latter. One, it looks like a robot trapped in a jar - aiding the victorian curiosity theme. Secondly, this robot will be powered by two wires which can conveniently hang through the cork down to the robot. In which case, I think I will add some extra wires through the top and cut them short, freying them so it looks as if the robot has partially escaped his tether.

I have quite a set of glass paints, so I am going to age the glass with some yellows and black. There is a little bit of work to do on the robot too. I have to add a Red/Green/Blue Light Emitting Diode (LED) for the candle effect.

I was thinking about how to draw the audience in from a distance and an idea struck me on the bus. By mistake, I programmed the robot to twitch at high speeed - it looked as if it was highly frustrated or having a panic attack. This made me think that I could use this behaviour coupled with some strobing white and blue light to look like it is blowing a fuse! And thats how I came to use a RGB LED as opposed to simple yellow ones. Conveniently, red and green make yellow, and i can use just the blue and all three for white. So it should be simple to mix the colour signals.

I'm not sure if I want to hang the lantern or if i should mount it atop a brass candelabrum. It could make a fun desk lamp after the exhibition!

Robot in a Lantern

2009-11-26T16:25:00.001Z

A robot post, hurrah! Not much of one unfortunately, just a quick post before I leave to catch my bus.

There is an open exhibition happening at the Arnolfini gallery in Bristol city centre, and I have set myself the task of creating a small piece of robot art work for it! The idea is to have a small robot crawling around inside a latern with an electronic candle on its back. It should look just like a latern from a distance, but closer you will probably be able to hear the motors. And on close inspection, a small robot scratching at the glass!

Today I put together the circuit board. Its very small and very simple. The robot won't have to do much other than crawl around and flicker some lights. Here is a photo:

It looks hilarious when it is moving :)

Mushroom hunting

2009-11-20T14:22:00.000Z

I promised to post some more pictures from last weekend, so here they are! I got up at 6am last Sunday and headed out into Leigh Woods with my camera. I also borrowed my flat mates tripod which was a lot of fun. I zig-zagged through the woods and found many mushrooms off the beaten path. Here are the best. I took over 270 photos haha. The light that weekend was fantastic. I uploaded some photos to deviantart.com and within 24 hours I have had some of them favourite-ed and a comment! thats so rewarding! I think I might have to upload more photos :) Again, you should be able to click these for the full resolution image.

Hopefully this blog will load a bit better with deviantart hosting as they keep image thumbnails :D

Hmm, not much robot stuff recently! I will try to make that my next post.

Painting

2009-11-16T12:01:00.000Z

I'm enjoying my new flat, it has great views of the Downs - a massive green space in Bristol. I have been trying to get up at 6am and this morning I was treated to a fantastic sunrise whist I finished off my latest 'stained glass' painting (its glass paint on plastic). Its an image from the first Hellboy comic. My render isn't quite true to the colours used in the comic, but it is one of my favourites yet! I had a good weekend, I will post a couple more photos later!

From a distance:

More true colours:

And a shot of work in progress:

Tiny Things

2009-11-10T15:18:00.000Z

It is coming up for a year since I bought my camera and I have over 6000 photos! I've been deliberating upgrading from compact to dSLR, but now that I write that down it seems justified :D

I thought I would compile some photos of really small things. I like the tiny world, its fascinating.

~~You should be able to click the images to view them at their native resolution :)~~
~~Photobucket resized the images :'(~~
Fixed!

Sorry if this takes a long time to load :|

Chip Tunes

2009-11-03T18:30:00.000Z

A while a go a friend showed me kohina. It keeps and plays an archive of old chip tune music, from old video games.

Too much of it can get irritating. However something interesting, most this music used to be programmed into hardware chips (hence the name). These days its easy enough to record high quality music. But back then there were programmers who would work out the waveforms to generate this sort of music - it all had to be squeezed into a chip on a cartridge! Thats why it sounds so simple of course, but some of it is musical genius.

Some tunes have synthesised words and voices! :D

Heres a radio link, you can open this in windows media or vlc as a network stream:

http://www.kohina.com/kohinasolanum.m3u

Manchester, Walking with Robots.

2009-11-03T17:27:00.000Z

So last weekend I went away to to Manchester for the Manchester Festival of Science. It was a lot of fun. The main event was based in the Manchester Museum of Science and Industry (MOSI). Claire Rocks had put in a huge amount of effort organising 3 years of Walking with Robots and this was the finale. I spent long hours talking to the publics about robots, mostly children. Just like at the Bristol Festival of Nature I was suprised at how much kids under 10 seemed to know about robots - even specifics about how sensors work!

I also got to do some fun stuff I wouldn't of thought I would be that good at. One evening I went along to a bar in Manchester and moved around sitting myself with complete strangers. I had the epuck robots with me, so I simply asked them what they thought the robots might be doing and used that to start conversation! The following day I went to a massive shopping centre (Trafford Centre) and did much the same - although this time I had to chase people down!

Over the five days it made me remember my years at college when I would scour the internet for news items and web pages on any kind of robots. Now I stand on the opposite side and try to explain myself to others! It made me feel very privaledged and made me feel excited about robots again. Working with the robots can be tough, but I shouldn't forget how much work it has taken to get here, its been worth it!

Here are some pictures:

I particularly liked this robot. Its a boat that is completely sealed and can self-right if capsized. It has a clear top to charge its batteries via solar power. The sail is fixed (correct term?) in that its not a sheet of canvas, but more like an aeroplane wing (an aerofoil). The white box on top is an ultrasound unit used to detect wind direction. I've not looked into this yet, but I guess that since wind is air pressure it affects the ultrasound ping time - doppler shift?. The robot uses electricity to move the sail into wind and to steer with a rudder. Apparently it can track GPS waypoints, but no one has managed to sail the Atlantic autonomously - what a great challenge!

This robot was cute but it didnt really do much other than roll about making japanese noises!

Manchester had a really mixed set of architectures. It might not be to everyones taste, but it was interesting for a new comer like me!

I thought that tall building looked great, but it did seem to be the only tall building around. I asked a taxi driver why it had the tall trellace on top, and he explained that they built it without; however the tv studio next door complained about noise from air turbulance over the top of the beast. So that trellace breaks that up! Something I had never considered before!

The most outrageous entrance to a shopping centre.

The epucks came to the pub! This was a fantastic way to get science out there.

I like this photo. I like low-down shots of e-pucks! Its like being in their world. You can see a robot dinosaur in the background :D

This might win cutest photo award. The kids loved Pleo the dinosaur, although I do wonder how long the novelty would last. Suprisingly this company went bust, I think its because the robot cost £200, and for that you could get a games console. I wonder what the mark up was, if any?

Background Scheduling on an AVR

2009-10-28T15:36:00.000Z

So the other day I decided to try and implement something tricky on a microcontroller - task scheduling! It is not a normal feature for a microcontroller but it can be useful. I thought it would be fun to try and explain the process here!

My first attempt at this post had a lengthy explaination as to why a scheduler might be necessary. Lets just leap into the deep end. Most computers have a main processor (the CPU) which has to be divided up between what you want to achieve. Interupts are used to steal the CPU from one task and give it to another. Microcontrollers are very simple computers however (normally used for washing machines etc!) and usually don't have enough interupts to match all the tasks the robot has to do on time. Instead, we can use one interupt to share the CPU out!

So above is a description of a task. The 'counter' is sort of like a clock. Every time our interupt steals the CPU time it adds one to this counter. The second value, 'cycle', is set by the programmer (or robot!) to determine how often the task should be activated. Therefore, the counter keeps ticking up, and when it matches the cycle time we activate the task.

The 'activate' value is actually just a flag to turn off a task. Sometimes we want to temporarily turn of a task, but keep it in the schedule. If 'activate' was to equal zero (false), we simply stop adding 1 to the counter.

So when the counter matches the cycle time, we call upon our (*function) variable. This is actually a reference to another piece of code which will check sensors, move motors etc. Normally, the interupt will be ticking along and simply adding one to the counter of the task. But everynow and then it has to run off to complete the code pointed at by (*function). Once this has happened we reset the counter to 0 to start the clock until the task is required again.

So the final element in our task description is the *next variable. This is actually a neat trick to automate the process of checking each scheduled task. What *next does is point to another task. It means that we can create lots of tasks and string them all up in a list. Each time the interupt fires it updates the counter for the current task then uses *next to move to the next task in the list. It repeats this until *next doesn't point at anymore tasks. So we don't need lots of interupts to check lots of tasks, but instead one interupt fires then looks along a list of tasks.

So this method has a two-fold requirement. The interupt must run fast enough to check each item in the list (and perhaps activate and complete each tasks bit of code), but must run slow enough so that there is some main CPU time to get on with the usual stuff. If our CPU was running 10,000 times a second but our interrupt was firing at 9000 times a second, that would leave only 1000 'ticks' to do the normal stuff, or complete the background tasks. Hopefully you can see the conflict!

In the above diagram, the blue main code is running along the top on the black clock signal (black spikes!). This gets stopped by our green spikes, the interupt, which runs off to check the list of tasks. On the second sequence, it finds that the second tasks requires activation. So in the second, we would steal a bit more CPU time than normal. However, because the main clock is running 10million ticks a second compared to our interupts 100,000, this should be quite ok.

Using a structure in C to represent a task might be seen as a bit overkill. However, this method is nice though, because we can use functions like malloc() to add tasks to our scheduler on the fly. So instead of having to work out the timings to get lots of things to work simultaneously, or work out in which order things should be processed, we can add things or take them away by simply making a call to something like addTask( moveRobot, 3000), specifying the code and timing, and the scheduler will take care of the rest.

Furthermore, we can add the same task more than once. This might not seem that useful, but we can have some fun by writing code to create a waveform on an output pin, and then set it as a task twice but with different cycle times.

Being able to change things on the fly is something I find exciting for robots. Rather than have a distinct sequence of processes, robots can work out for themselves what a good timetable of events is.

Milk Pixel, Craftivism

2009-10-15T14:08:00.001+01:00

I have got involved with an open event at the Arnolfini due for December this year. I'm very excited, I've always enjoyed art and now I get to exhibit something in a public place!

You can check out the event webpage here.

Currently our blurb is:

"Milk Pixel is a semi technical piece of interactive fun that we hope to have ready in time for Craftivism..."

And we are trying hard not to spill the beans before then.

I am also going to make a few of my own interactive robots, if I have time. Milk Pixel is a group project (Adam Spiers, Tom Burton, Jason Welsby, Richard Craig, myself) and we already have a substantial amount done. I have boxes of electronic junk at home, so I quite want to cobble some interesting things together. This is an opportunity for me to make robots for no other reason than fun :)

It should be great, I hope my friends can make it down in December!

End of Year Report: Part II

2009-10-15T13:54:00.000+01:00

Horray!

I have finished the first draft of my end of year report, but it is very rough. The report is almost entirely speculative unfortunately. I have spent the year investigating the robots and their potential. I am confident that I have a good foundation, but the lack of hard results in the report troubles me.

I am reminding myself that I started this PhD solo, not part of larger, directed project. Its a small comfort, but I am telling myself that wading through all the literature to find a research area has been no easy job! In fact... I'm still not sure if I am 100% there yet!

I have handed the report in and I am doing my best not to open the document until i receive feedback. I get the feeling I could edit the thing forever.

End of Year Report: Part I

2009-08-04T02:24:00.000+01:00

Today I have officially begun my 'End of first year report', for lack of a better name. The report is supposed to reflect what I have learnt over the past year and state my intentions for the next two. I am sure the report is also intended to help me pull my ideas together and keep me on track.

After the business with the submarine competition, I returned to work and didn't recognise my own code. So last week deconstructed my source code into a library form, but more about that later. I also started pulling together all of the reading I had completed into a bibliography, required for my literature review. This was something I had started but had let slip.

Documenting all of my reading really made me realise just how many components there are to a swarm robotic system (real, not simulated!), and also the surrounding topics supporting my ideas. Already my bibliography has 114 entries, and I still have a few folders remaining to add into the archive. These are not books I should mention, but probably average 2000 words a paper. It still seems like a lot.

So today I also started another initiative. I picked up a small (A5) exercise book and labelled it 'Quotes'. I have highlighted passages on papers, so now I am actively keeping a quick reference to help speed up writing. Obviously, this will be a little bit time consuming, but if I can stick to it I think it will be very useful for finding citations. Perhaps this should be in my bibliography, but sometimes I know I read something particular which just needs to be more accessible.

Today I have broken down my report into the relevant sections and now I must decide how much emphasis should be made to each, and which citation to provide. It is quite exciting, but I am sure this will become an epic slog after a week. I am looking forward to publishing the finished document on here though. I have written a few short literature reviews previously in the year, but hopefully this one will be comprehensive enough to keep me happy, inspired, and feeling on top of everything!

SAUC-E 2009

2009-08-03T16:54:00.000+01:00

July 6th was the beginning of a 5 day competition to build an autonomous underwater robot. The robot had to complete a number of tasks using its own intelligence, and our robot came in 7th of 8, beating Cambridge!

[The Team]

The competition is annual so teams have the entire year to build something, but this was UWE's first entrance and we began the process in March. After the initial bureaucracy and the time to pull a stable team together, we had approximately two months to get something working. Mix in exams and coursework, and we were on a tight schedule. Furthermore, all but one of the other teams were veterans of the competition, so their robots were actually systematic upgrades spanning the years. Tough competition.

[Burning the midnight oil]

I had not done anything like this before. Matt Studley, one of my PhD supervisors, had recommended me to the position of team leader for UWE's entrance. I took the position but I certainly underestimated the stamina required to keep a team on track. I started with buckets of enthusiasm but was really knocked back in the early period of the project where a fluctuating team destroyed all and any attempts at progress. Luckily, my second in command Tom Rooney picked up the challenge, set his heart on a design and harassed the workshop technicians until something was built. Actually having a physical robot makes things substantially easier.

[ One of the french teams]

Making a first time entrance into a competition like this is definitely a most challenging endeavour. Conceptually many of the problems are similar to land based robotics, which is normally quite challenging (but do-able) in itself. However, here we had a fresh team (myself included) that had no idea about hydrodynamics, best known methods to seal electronics, good brands of marine components, etc. Simply building a robot and anticipating the perceptual problems the robot would face was a daunting task.

[A german team ]

The week proceeding the competition the team was able to make it to a diver training pool in Somerset. On the first day the submarine completely flooded with water. It was then that we learned from another team the the IP-68 rated connectors we had spent a large amount of money on were notorious among teams for leaking (Bulgin). Great. Connectors are essential - you need to have the majority of your control system waterproof but communicating to powered external components.

[The other german team, this was an impressive feat of engineering]

South Hampton university lent us one of their SeaCon connectors which worked like a dream. However, our pin count was now significantly reduced as we did not have enough time to order more connectors of the same brand. So we had to make do, reducing our robot to one serial connection to debug the whole system. To use this connector required going back to the workshops to machine a whole new back-plate for the submarine!

[South Hamptons robot]

Marios Georgiou had spent his time constructing a pressure gauge sensor to allow us to determine depth. This turned out to be a fantastic piece of work. When we looked at the commercial products we were flabbergasted with the cost - typically in high hundreds. Obviously these products are watertight to great depths, accurate and reliable. We had already allocated the majority of our budget to some purpose designed thrusters at an educational price of £400 each (!), on the basis that next year we would spend the budget on another quality piece of equipment, and so on. I think the price of these products gives an indication of the difficulty in design for submarine components.

[Harriet Watt, who have won 4 years in a row - its their expertise!]

So, one interesting problem we had with Marios' homebrew pressure gauge sensor was that the raw reading was fed through our single connector, and in so doing the oscillating motor signals induced noise into the raw signal. This combined signal-and-noise was then amplified to a detectable range and interpreted by our system, becoming useless. The solution was to relocate the amplifying circuitry and analogue-to-digital converter outside the submarine with the pressure gauge itself.

[Our robot weighing in at 13kg, one of the lightest there]

The result was then communicated over an I2C bus through the connector along side the motor cables. The conversion into digital 0 -> +5v made the transmission robust to noise. The obvious problem became making it watertight! Again, more word-of-mouth advice gave us the solution of potting compound. This is used on car electronics to render it watertight. It is a resin that can be poured like liquid and sets hard. Without a convenient mould, we used a Dr. Pepper bottle to encase our pressure gauge circuitry - giving our robot a Dr Pepper shaped undercarriage, which was amusing!

[The ex-MOD swimming pool, its huge! That white thing on the right is a crane gantry that allows them to place stuff in the pool. The pale blue machines down the left side are actually massive, and allow the side sections of the pool to be moved independantly to create various waves]

We added an entire kilogram of potting compound in waterproofing of various electronics, and our robot was still too positively bouyant! That was probably the biggest mistake for us this year, or biggest hole in our knowledge. Bath universities robot was 63kg in weight, and was 30grams positively bouyant. Our robot weighed 13kg, and was 2.5kg bouyant! We added so much lead as dead weight, which could of been batteries (or something else actively useful!).

[Another team shot. Geez, my hair can be high volume]

Slugs

2009-07-28T18:55:00.000+01:00

Well as always I am behind on my posts - before I have even made my first post to this blog! I have autonomous submarines to talk about, some experiments with genetic algorithms, some visual processing...

I missed the bus so I thought I would make a quick post. My flat has an out-house toilet, although it is not as bad as it sounds. It is a fantastic observation point for insects however! Over the weeks I have seen the rise and fall of entire arachnid empires. Recently I have been watching a pair of slugs, specifically Limax maximu. It interests me that I have always seen the slugs as a pair. How do they recognise each other? Do their brains have the capacity for devotion? Perhaps it is just happenstance.

Anyway, these two are almost full grown (nearing 20cm) so they are cool to watch. I couldn't help but wonder how much they can see. I decided to place my hand on the floor with a finger extended above and beyond the path of the slug. It didn't seem bothered, until about 15mm away, when the slug raised its 'head' to inspect with its optical tentacles. The tentacles slowly retracted with its forward velocity, remaining at a constant few millimeters away from my finger. Once within a certain range, the slug used the optical tentacles to feel. I assume that once a certain distance has been reached the tentacles can actually be used as tactile input, moving around to ascertain more information than sight alone. I can't help but think their behaviours trigger on perceptual thresholds. The slug reared up and ran its mouth parts over my finger. Apparently, I'm not that tasty, and the slug continued on.

The mating sequence for this slug is supposed to be quite something. If I manage to capture the act I will post some photos, but otherwise Wikipedia has some here and here, and more of the slug on the main page that are better than any I have.