Friday 25 October 2013

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.




5 comments:

  1. Hi,

    just started following your blog, as I got hold of an ORT robotic arm from some company named Concorde Robotique from Cardiff. It's a blue robot arm that has orange paint underneath.. And looks a lot like an Armdroid. The PCB looks newer and has Colne Robotics on it. The chips are from 1987, so I guess this is one of the later Colne Robotics Armdroids that has been rebranded (and repainted) by Concorde.

    Anyway, I really like your detailed progress report and the pictures. Maybe put your camera on a stand for the next video's :-) If you like to see my progress report, its on http://www.rudiniemeijer.nl. It's in Dutch, but I'll take comments in any language. Keep up the good work!

    Rudi

    ReplyDelete
    Replies
    1. Your arm looks like a clone of the later Armdroid 1000 models which replaced control strings with timing belts. The electronics is definitely a newer single interface board variant. It's very interesting to see this example...and many thanks for sharing this... looks like another sibling of the Armdroid family which doesn't seem to be that well documented on the internet.

      Richard
      - Tripod and HighDef Video camera already on my Christmas List :-)

      Delete
  2. Cleaned up the PCB of my ORT tonight. It is a newer version of the production Armdroid 1 PCB, but not the Armdroid 1000 PCB. It has the blue 10-pin header like the Armdroid 1 has (the production version that is, not the prototype one you appear to have), but it has the voltage regulator on the right side of the 10-pin header, not on top. The Armdroid 1000 all appear to have a DB9 connector. Furthermore, it appears to be a rebadged (and repainted) Armdroid 1000, but with the three-gripper from the Armdroid 1..

    ReplyDelete
    Replies
    1. This link http://www.anf.nildram.co.uk/beebcontrol/arms/armdroid/siblings.html talks about other follow on and re-badged models, but does not specifically mention Concorde Robotique anywhere. Hopefully, in time, another reader of this blog might be able to shed more light on the mystery

      Delete
  3. Hi Richard,

    tonight I got the ORT/Armdroid 1000 working with an Arduino connected to it. Took me a while to decode the 10 pin header and I'm still not sure if the motor select behaves like documented, but all axes seem to do something. I published my Arduino sketch here: http://www.rudiniemeijer.nl/714/

    ReplyDelete