Tag: robotics

Penelopean robotics (part 2)

Penelopean robotics are about rebuilding technology in the woven cosmos. You can read more about the theory in part 1, but roughly our aims are to:

  1. Embody Penelopean technological practice – they should be easily undone (taken apart) so they can be understandable, self documenting and repairable.
  2. They are not automated looms, but must eventually be capable of weaving in some form, maybe by interacting with ancient Greek weaving technology.
  3. Capable of embodying elements of ancient Greek poetry and dance, perhaps via livecoding.
  4. Be constructed in the spirit of Simone Giertz rather than Boston dynamics

Some potential further directions we have discussed are swarm robotics and the use of May poles as a stepping stone between dancing, braiding and weaving.

This is a story of one Penelopean robot.

The original concept of the weaving robot as described in the project was an ‘arachnoid mechanism’. We wanted to stick with this general direction and begin by building a six legged insectoid. After a bit of acting out of the movements required, and looking on youtube for similar robots it seemed that it was possible to do this with 3 servos, two for the front and back which rotate horizontally and one in the middle which rotates vertically.

Weaving crops up in plenty of medical, space and industrial situations – the strength and lightness of woven structures has lots of advantages over other techniques used in engineering, and in the spirit of the project it seems appropriate to try tablet weaving as a way to construct the main framework for the robot. For more info on how to do tablet weaving yourself, see this previous post and this one.

Double weave can be used for this as it allows you to weave tubes and pockets without any cutting or stitching, so they have very strong joins. Here is a sketch of the initial design:

Three joined tubes can hold the micro servos in place, and I later added another smaller one in between for a cylindrical lithium ion battery from Adafruit that was the perfect shape for this.

The process of weaving was a case of starting with a normal section, followed by beginning a double weave split via two weft threads, and checking it every couple of wefts to fit the first servo. When it’s big enough to tightly fit you close the first tube and immediately start a second, for the battery – then the middle servo (which fits at right angles to the others so is slightly smaller) and finally the last servo, with a normal section of tablet weave to close it up. This didn’t take very long, but to make more I could easily count wefts based on the first one and do a lot more quickly – for example, manufacturing swarms of these robots.

As a comparison, this process would be much more difficult and slow via 3D printing – as you can’t generally change anything on the fly, and the design needs to be completed before printing, and the softness turns out to be important.

Although the weave is strong in itself, it still needs a skeleton for the robot to stand up. I used 2mm wire for both this job as well as the legs. One piece of wire is used for the top (which loops around
the battery) and another bent double for the lower side. This scaffolding means that the middle legs will be able to push against something to raise the other legs to walk. Then all you need to do is tie loops of thread around each servo to hold it in place along with the scaffold. This may be unnecessary with a bit more development.

The PCB for the microcontroller and radio (more on that in a later post) can also be tucked under the top wire so it’s locked out of the way of the legs on top.


Christian Faubel showing us the unique nature of analogue computation and what happens when you apply this to robotics at the Penelope robotics workshop in Munich.

At the time of of the Penelope robotics workshop I could get the robot to shuffle a bit in generally the right direction but it wasn’t very efficient or convincing. It took a little servo sequencer programmed by the pattern matrix (in a similar manner to how it sequences music) to experiment with it and work it out properly. This takes a short list of symbols representing angles (from -90 to +90 degrees) which loop.

This is the working code for walking on the pattern matrix – more descriptive tokens will be made in future! These patterns are sent over radio to the robot whenever they change.

The general idea is that if you have 6 legs you can keep 3 feet on the ground while moving the others, which is much more stable than if you need to balance. The front and back servos job are to drive the robot forward and have the same movement as each other at the same time. The role of the middle legs are to lift the side of the robot up in alternate phase so only the ones pushing ‘back’ are touching the ground.

This meant we could use the pattern matrix to do things like switch direction by inverting the middle row above, which controls the central servo. This lifts the robot’s sides in the inverse phase, which means its feet (following the same pattern) move it in the other direction.

You can see a selection of different patterns of movement on this video:

The best aspect of the woven structure was how strong it was – it could throw itself around all day without problems and the flexibility helps too with the movements required. I could also stuff the robot into the bottom of a bag and it would be fine the next day.

There will be more info here on how to build them – for now the code is all here, the electronics is based on this prototype board – watch this space for more of the details on the radio enabled tangible robot livecoding.

A tanglebots workshop report

I’ve tried a lot of different ways of teaching children programming, starting a few years ago with primary school children in a classroom, then doing inset training days for teachers and finally private tutoring in homes. For the finale to the weavingcodes project we are trying a new approach, teaching families about code, robotics and thread by building “tanglebots”.

25956891515_f3d0ea3ec7

The concept is to combine programming with physical objects, concentrating on sensor input and movement as output. It’s important that we incorporate our weavingcodes research process, so deliberately setting goals we don’t yet know the answers to.

The weaving focus allows us to ground the workshop in loom technology and demonstrate the challenges of manipulating thread, with its enormous history of technological development. For the first Cornwall workshop, Ellen started us off with an introduction using FoAM Kernow’s Harris loom and the fundamentals of weaving. We were also joined by Janet and Jon from lovebytes who are helping us to run these events. When first talking about possible workshops with children, we’d discussed the impossibility of making a functional loom in a couple of hours with only broken toys and lego – and so the focus on tangling was suggested by Alex as a way to turn these difficulties to an advantage. Similarly we created a series of prizes for different categories such as “Most technical effort with least impressive result” – inspired by hebocon events.

25956891515_f3d0ea3ec7_2

25324352694_30f0a1a2a4_k2

The workshop format we used is also influenced by Paul Granjon’s wrekshops – wherever possible we’re recycling by pulling apart e-waste, making use of electronics, motors, gears and ideas from the surprising complexity of what’s inside things people are throwing away. This turned out have a powerful implicit message about recycling, parents I talked to had tried taking things apart to learn about them, but the next step – making use of the parts discovered as we were doing here, needs a bit more help to do.

Also as normal for FoAM projects was the importance of the food, in this case tangled by Amber and Francesca to both provide sustenance and inspiration with cardamom knots, spiralised courgetti and tangle fritters.

25931225896_007b088e5d_k2

The groups ended up a bit lopsided, so in future we plan to pre-arrange them as we did on the machine wilderness workshop. In order to do that we need to ask for more information from participants beforehand such as family ages and backgrounds.

We tried using the small Pi touchscreens – these were a bit too fiddly to get away without a mouse, but are much less oppressive somehow than larger PC monitors – as they are so small, they became incorporated into the tanglebots themselves.

Crocodile clips were the best way to connect to random/plundered electronics as well as the lego motors. These removed the need for soldering (which we had set up anyway, but in a separate space).

A selection of other notes we made:

  • Start with a manual tangling exercise (weaving with rope, tablets etc)
  • Lego has a strange all or nothing effect, once you start using it – everything has to work that way, avoiding it may lead to more creative options than including it
  • A first aid kit is needed for these sorts of things
  • The Pimoroni Explorer Hats are good but needed periodic resets in some cases – the motors seemed to get jammed, not sure if this is short circuits interrupting the i2c comms?
  • The Raspberry Pi docs are riddled with minor errors, e.g. the Scratch GPIO section on the explorer hats has a lot of sometimes confusing typos.

All our resources are being uploaded to the kairotic github repository so other people can make use of the materials.

As well as being supported by AHRC Digital Transformations, this project was part of British Science Week, supported by the British Science Association.

25956947035_a44aa6bdd9_k(1)

Photos from the machine wilderness workshop

Busy times at Foam Kernow, here are some photos from the Machine Wilderness Workshop weekend before last. This was a project between Foam Amsterdam and us, with 30 participants from all over the place geographically and professionally. My role was as facilitator, so mainly obtaining raw materials (electronic toys, recycled trash and e-waste) as well as a bit of cooking and general running around which I found very enjoyable. The machines invented and prototyped were grounded in the environment of the Penryn river in Cornwall, so common themes were seaweed biomimicry and experiments with estuarine mud, both as a surprisingly rich power source as well as a design medium in it’s own right.

I’ll leave the in-depth write ups to those leading the event, but one of my interests was to see how a workshop involving e-waste would work, practically and as an inspiration – with an eye to doing this with primary school kids and teachers. We managed to locate a good quantity of old toys from various local second hand stores and warehouses, quite a modest outlay in return for some very good mechanics, motors and electronic parts. Resisting the temptation to take them to bits beforehand meant that the participants could open them up and discover what they could use, one of the best items was a bubble machine – inside was a good air pump and lots of mechanics (total cost ~£1.50). This was incorporated into a robot lifeform that was in part augmented by moss growth and LED lights.

See the rest of the photos here.

22444642273_6d6b6c6769_k

22649609288_dedb77b1db_k

23065937055_1621cd69f4_k

23068027015_727ee3aef9_b

23077159031_f7021478d0_k

Scratch -> Lego Mindstorms

A bit of hardware hacking for Troon Primary CodeClub, who have tons of old style Lego Mindstorms they don’t use any more, and after a year of Scratch programming on their PCs are just getting started with Raspberry Pi. We’re using this Scratch modification together with the hardware I’m making which is based on this circuit. The main thing here is an L293D Motor Controller IC which can drive 2 DC motors in both directions. You can write the hardware code in Scratch like this to control the lego motors:

blink11

The most tricky part in this whole endeavour has been physically connecting to Mindstorms. At the moment I’m having to use crocodile clips which won’t work long in normal classroom conditions – but I’m wary of destroying/modifying the connectors as they’re not made any more…

IMG_20140317_111808

Spork Factory: evolving a light follower robot

Continuing with the structured procrastination R&D project on evolvable hardware, I’m proud to report a pretty decent light following robot – this is a video of the first real-world test, with a program grown from primordial soup chasing me around:

After creating a software model simulation of the robot in the last post, I added some new bytecode instructions for the virtual machine: LEYE and REYE push 1 on the stack if we are detecting light from the left or right photoresistor, zero if it’s dark. LMOT and RMOT pop the top byte of the stack to turn the motors on and off. The strategy for the genetic algorithm’s fitness function is running each 16 byte generated program on the robot for 1000 cycles, moving the robot to a new random location and facing direction 10 times without stopping the program. At the end of each run the position of the robot was compared to the light position, and the distances were averaged as the fitness. Note that we’re not assigning fitness to how fast we get to the light.

This is pretty simple stuff, but it’s still interesting to look at what happens over time in the genetic algorithm. Both motors are running at startup by default, so the first successful programs learn how turn one motor off – otherwise the robot just shoots off and scores really low. So the first generations tend to just go round in circles. Then they start to learn how to plug the eyes in, one by one edging them closer to the goal – then it’s a case of improving the sample rate to improve accuracy, usually by using jmps and optimising the loops.

This is an example of a fairly simple and effective solution, the final generation shown in the animation above:

loop:
  leye 
  rmot 
  nop nop nop nop nop 
  reye 
  lmot 
  or 
  nop nop nop nop
  rmot 
  jmpz loop

Some explanation, the right and left eyes are plugged into the left and right motors, which is the essential bit making it work, the ‘nop’s are all values that are not executable. The ‘rmot’ before the ‘jmpz’ makes the robot scan around in circles if there is no light detected (strangely, a case which doesn’t happen in the simulation). The argumant to ‘jmpz’ is 0 (loop) which is actually the 17th byte – so it’s cheekily using memory which has been initialised to zero as part of it’s program.

This is a more complicated and stranger program which evolved after 70 generations with a high fitness, I haven’t worked out what it’s up to yet:

  pshl 171 
loop:
  lmot 
  leye 
  pip 111 
  pip 30 
  rmot 
  reye 
  pshl 214 
  nop 
  lmot 
  jmp loop

Evolvable hardware

I’m modding a robot toy for the next Spork Factory experiment, the chassis provides twin motor driven wheels and I’m replacing it’s brains with a circuit based on the ATtiny85 for running the results of the genetic algorithm, and a pair of light dependant resistors for ‘seeing’ with.

Here’s the circuit (made in about 20 minutes after installing Fritzing for the first time). It’s quite simple – two LDR’s provide input, and some transistors are needed to provide enough power to the robot’s motors (it’s using PNP transistors as they were the first matching pair I could find, which means logical 0 is ‘on’ and 1 is ‘off’ in the code).

The robot needs to be emulated in software so the genetic algorithm can measure the fitness of hundreds of thousands of candidate programs. We need to simulate the effect of motor speeds on it’s position and velocity – here is a test running the right motor at a constant rate, and gradually increasing the speed of the left motor.

This is the code snippet that calculates the velocity from the 2 motor speeds – more work is needed to plug in the correct values for the distance between the wheels and the actual rotational speeds of the motor drives.

// update dir and pos from current motor speed
float relative_speed_diff=m_left_motor-m_right_motor;
float angle=atan(relative_speed_diff);
    
// rotate the direction by the angle
float nx=(m_dir.x*cos(angle))-(m_dir.y*sin(angle));
float ny=(m_dir.x*sin(angle))+(m_dir.y*cos(angle));
m_dir.x=nx;
m_dir.y=ny;
    
// update the position
m_pos=m_pos.add(m_dir);