Cambridge Raspberry Jam - 7th December

Yesterday, was the 4th Cambridge Jam (CamJam) of 2013 at the Institute of Astronomy, Cambridge University.

We arrived early to set up the Armdroid display, and before we could finish unpacking everything we had a small crowd hovering around the desk.....

Above, Matthew (The Raspberry Pi Guy) was really taken by the Robotic arm, and wanted one!   Ryan Walmsley was demonstrating his RTK-000-001 motor controller board & buggy, and some of the other demonstrations was equally as impressive!

Unfortunately, my Raspberry Pi was randomly rebooting itself, so out came the manual controller to the rescue !

Eventually the Pi started behaving itself....   Perhaps there was a shift in wind direction ?

I recompiled some of the test programs with shorter delay statements to speed things up, this made the arm appear a lot more responsive when controlled by the Pi.

Daniel Bull was back with the mighty AstroBlaster arcade console...  We spent most of the day talking (fantasying) about 3D Printing technologies.   The question being... can we print replacement Armdroid components with enough precision not to require further machining ?   We will have to wait and see...

Later in the afternoon I had the pleasure of meeting Gordon Henderson, author of Wiring Pi.  This is the GPIO access library I've been using to write my Armdroid software.

I met lots of interesting people and wished I had taken more photographs.

I've been invited to the forthcoming Peterborough Raspberry Jam starting in March which I'm really looking forward to attend.

Final picture of the day....  Yulia and myself, ready for a well deserved Beer at a local pub !   It was after all a long and very successful day.

We suffered a breakage in the afternoon....

The tension equaliser had been playing up all day, and eventually lead to failure of the fingers.  I suspect one of the retaining grub screws wasn't as tight as it should, this must have slipped.   If you look closely at the Kevlar which didn't snap, literately tore itself free.

Actually, I couldn't have asked for a better proving ground - the kids absolutely loved playing with the Armdroid, and really gave it a good hammering...   I've come away with a lengthy list of problems which need to be addressed & resolved for next time.

A full write up can be found at http://www.recantha.co.uk/blog/?p=7219 with an additional update http://www.recantha.co.uk/blog/?p=7290

Finally....   Big thanks to Michael and Tim, and all the Jam Makers for their superb organisation and dedication put into running such a good show.   Next jam will be Saturday, 8 February.

Driving Multiple Motors

I've been working on a slightly more advanced test program capable of driving multiple stepper motors simultaneously...

Of course, they don't really run at the same time - that's not possible with this interface, but with some clever programming we can make them step, so that they appear to be moving at the same time.

This is desirable for speeding up operations by running in parallel, instead of sequentially driving motors.

Another important reason is controlling the Gripper action - in order to Roll (rotation) or Pitch (up/down) the wrist mechanism - we need to carefully apply counter-rotations to the left/right hand side motors to drive the differential gearing.

In my previous test program we stepped a motor by calling the drive_motor() function.  This was a blocking function, it would not return until all the steps have completed.   Instead of this, I've written a new routine called drive_all_motors() which takes an array of motor commands.  You can still pulse just one motor with this arrangement, or pulse multiple motors as required.

The motor control array is a relatively simple structure consisting of the desired number of steps and direction  for each of the six motors:

 // define motor control structure  
 typedef struct MTR_CTRL_TAG  
 {  
   int  steps;  
   int  dir;  
 } MTR_CTRL;  
   

 // declare our motor control array  
 MTR_CTRL motor_control[6];  

A motor which is not to be driven should have steps = 0
Assigning a positive number will result in that motor being pulsed to the specified number of steps

The implementation of drive_all_motors() takes this array, and calculates the total number of iterations needed to drive the motors.  After this, we form a tight loop and pulse each of the running motors, decrementing the number of remaining steps as we proceed:

 void drive_all_motors()  
 {  
   // calculate maximum number of steps (total iterations regardless of direction)  
   // for all motors  
   int max_steps = 0;  
   int motor;  
   for (motor = 0; motor < 6; motor++)  
   {  
     if ( motor_control[ motor ].steps > max_steps )  
     {  
       max_steps = motor_control[ motor ].steps;  
     }  
   }  
   
   // repeat until all possible steps have completed  
   int step, output = 0, control = CCLK + SYNC;  
   for (step = 0; step <= max_steps * 2; step++)  
   {  
     // for each active motor, drive it!  
     for (motor = 0; motor < 6; motor++)  
     {  
       // motor is active if we have any steps remaining  
       if ( motor_control[ motor ].steps > 0 )  
       {  
         // add motor address to control pattern  
         output = control + mtr_addr[ motor ];  
   
         // now, add direction bit if necessary  
         if ( motor_control[ motor ].dir == 1 )  
         {  
           output += CDIR;  
         }  
   
         // output control byte, and delay  
         digitalWriteByte( output );  
         digitalWriteByte( output - SYNC );  
         delay( PULSE_DELAY );  
   
         // output again with sync bit restored - returning to input mode  
         digitalWriteByte( output );  
         delay( PULSE_DELAY );  
   
         // decrement motor step counter (when clock pulse is low)  
         if ( (control & CCLK) == 0 )  
         {  
           motor_control[ motor ].steps--;  
         }  
        }  
      }  
   
     // toggle clock-bit for next clock pulse  
     control = control ^ CCLK;  
   }  
 }  

The delay statements results in very slow running speeds when driven from a Raspberry Pi.  This is intentional as I'm still debugging my circuits, but we'll speed things up later.  We'll also consider speed along with acceleration/deceleration control in later versions of our software.

I'm going to start work writing a variation of the LEARN program documented in the manual allowing users to program sequences of movements & play them back.  This program will use the above technique as the bases for this work.  I also want to start abstracting the implementation details to make things easier to modify for direct-drive variants, and porting to other platforms.


The full source code for ArmTest_v2.c has been added to the software page.

Motor Addressing Solved

Finally, I have solved the motor selection problems.   This blog update will try and cover both problems in detail....


1. PCB interconnections (only applies to prototype models)

As suspected the PCB interconnects was crossed on my Armdroid causing motor selects to drive the wrong motor.   The cables feed the the bottom two data bits (CDIR & CCLK) from the interface to driver circuitry, and look like this:

They combine two channels into a single connector at the other end.

They need to be wired such that the outputs on the interface board below feed directly into the corresponding inputs on the driver circuit board above in the same sequence.   As pictured above, the ordering is - starting from the left-hand side, motor #1 - motor #6

The colour coding of my cables are Purple, Blue, White, and Grey

The labels on all my connectors will be replaced in time to correctly reflect the motor channels they represent.


2. Motor Addressing Logic

The ordering of the Motor Address Bits was not as documented

The give away is the 74LS138 IC6
If you look closely at the pin-out for the 74LS138, you'll see that pins 1 - 3 are the input select bits, illustrated as follows:

The Truth Table says, to get output Y1 selected (ignoring the reverse logic), where Y1 happens to be our motor select for channel #1, you need to set the input pins as follows:

C B A

L L H

L = LOGIC LOW,  H = LOGIC HIGH

Looking at the interface schematics :

You can see address bits D2 - D4 are wired to the 74LS138 as follows:

D4   -->   A (pin 1)

D3   -->   B (pin 2)

D2   -->   C (pin 3)

Which means to select motor #1 the address bit pattern would have to be:

D4   HIGH

D3   LOW 

D2   LOW 

The most significant address bit is actually D2, and least significant D4.

This is not quite what the article in the ETI magazine documented for the interface specification.   Previously, I was setting addresses with the assumption D4 was the most significant bit - for example 001 in binary, instead of 100 binary.

I revisited the construction manual looking for further clarification, unfortunately the documentation is somewhat ambiguous here.

Of course, none of this is actually a problem... we're dealing with an address pattern that is essentially reversible, so if your happy to re-wire your motor assignments, everything will then fall out in the wash.

I decided not to do this, and instead will compensate in software...
By introducing an array of motor addresses, we simply index into this array to fetch the desired motor address bit pattern:

 // motor address bits  
 // 1 0x08 = 00001000  
 // 2 0x04 = 00000100  
 // 3 0x0C = 00001100  
 // 4 0x02 = 00000010  
 // 5 0x0A = 00001010  
 // 6 0x06 = 00000110  
 //              |||  
 //              ||+-- A3  
 //              |+--- A2  
 //              +---- A1  
 const int mtr_addr[] = { 0x08, 0x04, 0x0C, 0x02, 0x0A, 0x06 };

When constructing our output control byte, the new code looks like :

   int output = CCLK + mtr_addr[ mtr-1 ] + SYNC;  

I no longer need to shift the address bits into position because they are now already defined in the correct position.   The mtr-1 of course is needed because all arrays in "C" have indexes starting from zero.

Actually, I prefer this approach because it allows other readers to easily adapt to their Armdroid's configuration.   This is essentially mapping logical motor numbers to physical motor addresses.  If a motor has been incorrectly wired to the wrong channel, you only need to modify this address array to compensate.   Good eh?


The updated source code for the test program will be added later this weekend to the software section.


I still have plenty of other problems to investigate.  Some of the motors, not all, are not reversing properly, yet everything works when operated by the manual controller.   I also rigged up a test circuit to check the signals coming from the feedback switches - and not convinced this is working properly either.    But, resolving the motor addressing is certainly one step in the right direction.....

Motor Addressing

Today, bought a couple of terminal blocks which will be used to extend all stepper motor cables, and that will allow me to run with circuit boards outside of the base unit.  Only then, can I start debugging my interface circuity...


Meanwhile.... Rudi Niemeijer from the Netherlands, has also been busy hooking up an Arduino to his Armdroid clone, and seems to be experiencing similar motor addressing problems....

http://www.rudiniemeijer.nl/ort-robotic-arm/
http://www.rudiniemeijer.nl/714/
(you'll need to Google Translate these pages from Dutch)


Update:  new English pages are being maintained here

http://www.rudiniemeijer.nl/concorde-robotique-ort-robotic-arm/

Even though Rudi has a newer single interface board, the motor address logic is however roughly the same to the prototype models.


My current thinking on the addressing problems :

Motor addresses are decoded by IC6 74LS138 which selects one of eight possible outputs given an address from the interface port.  We know only six (001 - 110) of these outputs are actually used, the others are not connected.  The outputs of IC6 selects IC7 - IC12 which are 74LS175 (quad D flip-flops) used to latch the data bits.

This week... I'll be checking these addresses are correctly selecting these flip-flops.  It's quite possible the MSB (most significant bit) of the Address is not as expected, and the bit pattern needs re-arranging to suit.  But, I've not seen any examples on the internet of controlling software doing this!  Of course, another potential problem would be address lines not running in order.

The next area where the addressing can be muddled up - and only applies to the prototype variants is the wiring of the PCB interconnects.  Which is the routing from IC7 - IC12 on the interface PCB to the jumpers C1 - C12 which represent the motor drive channels for motors 1 - 6.

Finally, the physical connection of these motor channels to stepper motors assignments is another area to check.

Could be more involved... but I'll start with the above checklist....

RPi Interfacing

Progress report on the Raspberry Pi computer control & software.

A couple of evenings ago, decided to bite the bullet, and power up the Armdroid connected to my Raspberry Pi.

Needless to say, nothing happened...  but I could hear a slight clunk coming from one of the stepper motors.

Eventually, I realized everything was working, but my delay statements was initially so large, it was taking minutes just to crank a few rotations.   I gradually reduced the pulse delays to approx 500 milliseconds.

The motor addressing is a bit weird.....
Selecting motor 1, results in motor 5 spinning into life, etc.   I spent hours double checking everything, and so far, my only conclusion is that the fly leads connecting the Armdroid's interface PCB to the driver PCB is mixing up the address selection.   A couple of months ago I traced the entire interface board and was pretty happy I knew what to expect here, so I don't think the issue is with the software or that part of the interface circuity.

I really need to run everything with the board outside of the base, but to do that, I'll have to extend my motor cables and modify the power connections.   Hopefully, I can then probe away with my Logic Probe on the running circuit to see what's happening.

Anyway, here is an example of my test program written in "C"  :

 /*  
  * ArmTest.c: Armdroid Test  
  *  
  * Copyright (C) Richard Morris 2013 - http://armdroid1.blogspot.co.uk  
  ***********************************************************************  
  *  
  */  
   
 #include <stdio.h>  
 #include <wiringPi.h>  
   
   
 //// interface definitions ////  
   
 #define SYNC        0x01            // sync - output Low / input High  
 #define CDIR        0x10            // motor direction  
 #define CCLK        0x20            // clock driver circuitry  
   
 #define PULSE_DELAY    500                // delay in milliseconds  
   
   
 void setup()  
 {  
   wiringPiSetup();  
   
   // set pins 0-7 as outputs  
   int pin;  
   for (pin = 0; pin < 8; pin++)  
   {  
     pinMode( pin, OUTPUT );  
   }  
   
   // set Armdroid initially to input mode  
   digitalWriteByte( SYNC );  
 }  
   
 void drive_motor( int mtr, int steps, int dir )  
 {  
   if (mtr < 1 || mtr > 6)            // check motor number in range  
     return;  
   if (steps <= 0)                    // no steps, nothing more to do  
     return;  
   if (dir < 0 || dir > 1)            // check direction flag  
     return;  
   
     // construct control byte  
   // shift motor address into correct position  
   // add SYNC and CLCK bits  
   int output = CCLK + (mtr << 1) + SYNC;  
   
   // add direction bit if necessary  
   if (dir == 1)  
   {  
         output += CDIR;  
   }  
   
   int i;  
   for (i = 0; i < steps * 2; i++)  
   {  
     // output control byte, and delay  
     digitalWriteByte( output );  
     digitalWriteByte( output-SYNC );  
     delay( PULSE_DELAY );  
   
     // output again with sync bit - returns to input mode  
     digitalWriteByte( output );  
   
     // toggle clock-bit to generate next pulse  
     output = output ^ CCLK;  
   }  
 }  
   
 int main()  
 {  
   int motor, steps, direction;  
   
   setup();  
   printf( "Raspberry Pi - ARMDROID TEST\n" );  
   
   for (;;)    /* repeat forever */  
   {  
     printf( "Enter motor number (1 - 6) ? " );  
     scanf( "%d", &motor );  
     printf( "Enter steps ? " );  
     scanf( "%d", &steps );  
     printf( "Enter direction (0 = clockwise, 1 = counter-clockwise) ? " );  
     scanf( "%d", &direction );  
   
     drive_motor( motor, steps, direction );  
   }  
   return 0;  
 }  
   

Very much work in progress, so might not be the final cut, just yet !   The pulse delay of 500 milliseconds is still very slow, but this is good enough for debugging.

Having written this simple test program for 'prototype' variants, I fancy writing another version for Direct-Drive models.   Only the implementation of drive_motor() will need to change,  but, at the moment, I wont be in a position to test it.

I'll be adding the code to the resource page just as soon as I've figured out the best way to share files with eBlogger.

RPi Interface - completed

Today...  Assembled my interface cable allowing connection from the Raspberry Pi interface circuitry to the Armdroid's parallel interface port:

Here's how this was assembled.....

Firstly, solder up the 10-way ribbon cable to a 20-way card edge connector - we only need to use one side as follows:

The other end is terminated with a 2x5 ribbon crimped connector:

To crimp, you need plenty of pressure...  But, you don't want to damage the pins in doing so....

I sacrificed an IC socket by removing the pins, inserted the crimp connector into the shell of this IC socket which protects the pins, inserted the ribbon cable, and pushed together using a clamp like this....

A small G-style Clamp would also do the trick, except I couldn't find one in my garage!

Now, we're ready to install onto the interface circuit:

Minor wiring rearrangements made to route correct cables through to the ribbon cable.  I have also coupled up the ground line (black) to the ground power rail on the breadboard.  The +5volts (white) power line from the Armdroid is left unconnected:

You'll notice that when I constructed the circuit last week, I adopted the colour coding of my wiring based on the ribbon cable, which should simplify troubleshooting.

Finally, one last check with the multimeter checking we're not dropping resistance, and verify continuity.  Then tested the whole circuit again with the Digital Logic Probe:

The completed interface:

RPi GPIO & Armdroid Interface

GPIO stands for General Purpose Input/Output, and a GPIO pin can be set to logic high, or low, with a value of 1 or 0 respectively.  The Raspberry Pi can set pins to take either value and treat them as output, or it can detect a value as input.

The GPIO header on the Raspberry Pi consists of twenty-six pins, which include power (3.3v/5v/ground) and seventeen GPIO pins.  Some of these pins have special functions as well, we won't concern ourselves with these for now.

The GPIO pins operate at 3.3volts, which means we need to do some logic-level translation in order to interface our Armdroid.

To make the make the task of breaking out the GPIO pins easier on a breadboard, I'm going to use an Adafruit Pi Cobbler breakout kit.  I soldered up mine in about 10 minutes, but looks like you can now buy these ready assembled.


The layout of my Armdroid / Raspberry Pi interface circuit.

IC1 & IC2 are 74HC4050  High Speed Hex non-Inverting Buffers
The header pins (see right-hand side) represent the Armdroid connector D1 - D8
Power is taken directly from the GPIO, we could use the power source from the Armdroid interface

The circuit works using two 74HC4050 as logic level translators, converting logic high 3.3v to 5v before continuing to the Armdroid's 8-bit Parallel Interface.   This design is not bi-directional, which means we cannot read the micro-switch sensors, but we'll revisit that later in time...

GPIO ASSIGNMENTS
PIN   GPIO       ARMDROID
11    0 (brown)     D1
12    1 (red)       D2
13    2 (orange)    D3
15    3 (yellow)    D4
16    4 (green)     D5
18    5 (blue)      D6
22    6 (purple)    D7
 7    7 (grey)      D8

This table gives the physical pin numbers of each GPIO channel and mapping to Armdroid notation.



The completed circuit on the breadboard:

Testing
As mentioned in recent updates, the gpio command-line utility can be used to test the circuit.  The following example sets pin 0 to output mode, and then sets to logic High.

gpio mode 0 out
gpio write 0 1

By substituting pin numbers, we can test all 8 output lines on our circuit with a Digital Logic Probe

All that I need to do now is solder up my ribbon cable and connectors.... and work can commence on writing software....

Motor Assignments

Eagle-eyed readers may have noticed an 'oddity' with my stepper motor numbering in previous photographs, and why these did not resemble the suggested assignments in the construction guide....

When starting this project, I simply gave each motor an arbitrary number as parts was bagged up for safe keeping during disassembly.  Later, having discovered my motor connections was in fact following the suggested assignments, I completely forgot to update the labels....

So, avoiding further confusion... at least for myself... here are two photographs showing the official motor numbering and function assignments:

Gripper (Motor 1), Left Wrist (2), and Elbow (4)

Right Wrist (3) , Shoulder (5) and finally the obscured Base (6)

I'll be relabeling my hand controller to match, all of this should make things easier to use next time!

Actually, it's a pity the original manual never included a diagram of motor assignments on the arm - I think it would have made visualizing this a hell lot easier !


Tomorrow....  An introduction to the Raspberry Pi's General Purpose Input Output (GPIO) facilities, and we'll discuss Armdroid interfacing.

Raspberry Pi Setup

A couple of weekends ago I installed Raspbian in preparation for work on computer control aspect of the project.  Raspbian is an optimized port of Debian Wheezy for the Raspberry Pi.   I've also setup a complete development environment to write applications in native C, C++ and embedded JAVA.

This update explains how this was done...

Installing Raspbian was surprisingly straight forward.  The same sd-card imaging technique used to install RISC OS was followed here.

I think the Software Configuration Tool started automatically on first boot, although it can be run anytime by typing:  sudo raspi-config

Expanding the Filesystem ensures all available space on the SD card is used by the root partition.  I would recommend this is done; a reboot is required.  Also, don't forget to configure your keyboard, timezone, and networking settings.  After which, the system will be ready for use....

This picture shows the standard X desktop running.  I configured mine to always boot to Desktop.

I would highly recommended before doing anything else at this point - update your operating system:

• Double click LXTerminal to get a command prompt
• sudo apt-get update
• sudo apt-get install

After updating the operating system, I installed a SAMBA server allowing files to be shared between Windows.   Other tools you might consider installing on your Windows clients are Putty, and WinSCP.

Useful Links
http://www.raspberrypi.org/
http://www.debian.org/
http://forums.debian.net/
http://www.linux.org/


Development Tools

The GCC C compiler is already included and installed with Raspbian.

Installed the following third party libraries which will be potentially useful (following the installation instructions on each site):

• BCM2835 Library
• WiringPi (version 2)

Both of these libraries are GPIO access libraries written in C for the BCM2835 used in the Raspberry Pi.   WiringPi includes a handy command-line utility gpio which can be used to program and setup the IO pins - very useful for testing!

I'm still looking for a decent text editor (please don't suggest vi), but in the meantime I'll probably write my code on Windows, then copy and compile on the device.


JAVA

You might actually be wondering why...  why Java ?   After we have written some basic Armdroid test programs in C/C++, the first major project of this site will be constructing a web-based control solution.  We'll be implementing this software in Java, to be hosted in a Java based Application Server.

I happened to find this blog article https://blogs.oracle.com/hinkmond/entry/quickie_guide_getting_hard_float which explains how to setup an Early Access Oracle JDK 8 on the Raspberry Pi.

In case your wondering what all this Hard Float and Soft Float is all about....  Earlier this year, Raspbian was available in two flavors - with hardware or soft-floating point number support.  At the time, the available JVMs only supported the software floating point, so if you intended to use Java, you needed to install that variant of the operating system.   The article above posted last December introduced the Early Access Release of the Oracle JDK running on hard float editions.   A couple of months ago, it would seem the Raspberry Pi Foundation dropped all support for the soft-float images, and now, you can only download and install the hard float images...

I downloaded the JDK 8, then compiled & ran HelloWorld.java to prove everything is working correctly.

Finally, I installed the Pi4J library which simplifies controlling the GPIO port from a java application.
I ran the included sample programs to check everything was working using my Logic Probe to prove the pins are changing state high to low, etc.



- update -

Since setting up my Raspberry Pi, the foundation posted this article last week  http://www.raspberrypi.org/archives/4920 announcing future releases of Raspbian will include Oracle Java; existing users can install it by typing:
sudo apt-get update && sudo apt-get install oracle-java7-jdk

Bench Test (No. 2)

This morning I opened up the base again to retrieve a lost nut that accidentally dropped in the other weekend back...

With the circuit board exposed, I happened to notice one of the links touching another component....  I re-positioned the link wire, and guess what....  The link was feeding into the direction control logic for the gripper stepper motor.   Hopefully a slight tweak was all that's needed to fix the problem!

The blueprints included flat washers on the PCB mounts which I added as mine was missing these...

I know... I've had bad experiences following the blueprints to the letter, but in this case, I see no reason why these washers would not help spread the load from the fastenings.   They are M3 flat washers, purchased from a local model shop.


Finally, I could replace the missing bolt on the side plate having retrieved that wild nut...

Connected the hand controller and powered up with my new power supply for bench testing....

A couple of video clips, firstly, the Gripper action now working:

In this clip - you'll see a problem with the Shoulder and Upper arms having tight spots causing a lot of judder.   I can see we're rubbing on the side plates at times, but I need to look at this again with fresh eyes to figure out what to do about it....

So, re-positioning that link certainly solved the problem with the direction control.  I don't really like these circuit boards with unshielded links running everywhere, if you have any problems in this area, I would recommend checking your not touching any neighboring components.

On the whole, I would say we're making good progress.

I'm still missing a few fastenings, so another weekend I intend to pop to a local Nut & Bolt stockist to remedy that situation.


Not a bad pose in these pictures...

MIT M-Blocks

I know, I know, my friends....  This has nothing whatsoever to do with Armdroids, but these self assembling cubes revealed today by MIT are totally awesome....

http://web.mit.edu/newsoffice/2013/simple-scheme-for-self-assembling-robots-1004.html

I have to say, I really am taken by the relative simplicity of their design....   They can flip, rotate, jump, and snap together, all by wireless computer control.    It's really amazing to think in the 1980's the Armdroid seemed like technology that came straight out of Star Wars, and yet today.... we have these......

The BBC news website described these as having similarities to the 'Terminator' liquid steel which had the ability to form solid shapes.

I wounder if that will ever happen in my life time ?







One thing however that is on my mind is the concept of developing an open-source Humanoid Robot, using serial based digital servos, carbon fiber chassis for lightness & strength, maybe a Raspberry Pi as the main board....   Certainly has had my mind thinking about it as a potential next project....   After all, this is an area of robotics i'm rather passionate about!

Anyway, in the meantime, and a little more down to earth....  Armdroid....    A relatively simple job for the evening was dabbing the ends of the kevlar string using super glue as per the recommendation in the instructions to prevent the string from fraying.   What worked best for me, was applying the glue using a fine modelling brush, as some of the strings are in pretty inaccessible places.

Timeout

It feels like it's been a while, which it has ...  Last month I was trying desperately to ready my Armdroid for the next Milton Keynes Raspberry Jam.  This event, should have taken place on the last Sunday of the month, which unfortunately never happened.

An announcement was made on the forum discussing the future, attendances had been dropping, and could be closed down unless somebody is interesting in running the show...   It would be a great shame for that to happen as Bletchley Park makes such a great venue.   My next nearest jams are Oxford or Cambridge, so who knows, you might catch me attending in future!

In light of this, I decided to take a break for a couple of weeks from the project work, and catch up with other things around the house that had been neglected.

This weekend I'll be blogging about my Raspberry Pi Debian / development setup from a couple of weeks ago, and will start constructing the interface circuitry.

Focus over the forthcoming weeks/weekends will be exclusively centered around interfacing and computer control.

Talking of the Blog...   It's really exciting to see more readers interacting with the site, and received some very encouraging feedback.  I've now been linked from the excellent www.theoldrobots.com website which contains a wealth of Armdroid related information.

Power Supply

To make my Armdroid as portable as possible, decided it would be sensible to make up a dedicated Power Adapter instead of relying on my Bench Power Supply....

I bought a slimline AC Adapter with a regulated rated output of  12V, 5.0A from CPC - I think costing around £17 + VAT.   I could have chosen a 4 Amp adapter, but oddly, was more expensive.

I cut off the 2-pin connector and soldered on the GX-16 style connector, making sure the pins have the correct polarity:

On my Armdroid, +Vcc is on right hand side, GND left, as the connector is viewed plugged in.  Yours might be different, so it's worth double checking by following the cabling in the base to the 7805 power voltage regulator to determine polarity.   The 7805 has the following pin-outs:

The regulator on my Armdroid is bolted to the chassis, yours might be mounted directly on the PCB, but you can identify the +12V /+15V line by tracing the cable to the Input pin.  A multimeter can help with this.



The completed power supply :

Magnet Madness

This morning...  Reinstalled the sensors and cable tied everything back into place.   The spacer supports are not very good, I'll probably replace these with new lengths of aluminum tube and make a better job sometime.

This is rather puzzling.....

First paragraph of the assembly preparation talks about installing magnets into the reduction gear slots, with the exception of the hand gear, which needs no magnet...

... and fair enough, no magnet was installed there on my Armdroid.

The magnets are required for operating reed switches - a magnetic field causes the contacts inside to close, or open if they are normally closed.  When the magnetic field ceases, the reed switch returns to original position, making or breaking the electrical circuit.

But wait.....  What's this reed switch for ?

It's positioned directly in front of the hand reduction gearing in the middle - the very one which has no magnet inside!

That supporting bracket is described as "hand switch bracket" (part no. 16) in the parts listing.

What possible sense is there for having a reed switch without a magnetic field to activate it ?

The controlling computer will never get sensible feedback because it's state will always remain the same.

Perhaps I'll temporarily add a small magnet and experiment later what happens to figure out this discrepancy....   Have I discovered another mistake in the manual/blueprints, or maybe the designer's changed their mind implementing  feedback here?


Any ideas, anybody ?