Monday, 13 July 2015

Wi-Fi-controlled Armdroid

Back during Easter Bytes at TNMOC, a visitor to the museum asked if it's possible to control the Armdroid on display using their Mobile Phone or Tablet Device...   This got me thinking, and decided to hack something together for the following weekend...

If your interested in controlling your Armdroid using Wi-Fi or across the internet, here's how you can setup your own stand-alone, web-enabled Armdroid, using the Arduino Yun.   When you're done, you'll be able to control your Armdroid using any web-browser, or control programmatically over the internet using Python or other scripting languages.

What exactly is the Arduino Yun you might be asking.... It's basically a combination of a classic Arduino Leonardo (based on the ATmega32U4 microcontroller) with a WiFi system-on-a-chip Atheros AR9331 running Linino (a MIPS GNU/Linux distribution based on OpenWrt).  The two processing units are connected together using the Bridge library allowing you to combine the power of Linux with ease of Arduino.

OpenWrt supports REST services for clients and servers.  REST is an acronym for "Representational State Transfer".  It is a software architecture that exposes functionality through URLs.  REST has gained widespread acceptance across the World Wide Web as a simple alternative to SOAP and WSDL-based web services.   A nice introduction to the concepts behind REST can be found here.

This project implements an Armdroid REST API allowing functions of the robotic arm to be manipulated through URLs.  I've prepared a simple web page that consumes this service to get you going, although you could easily interact with this from say, a Raspberry PI using the CURL library, etc.


The photographs above shows the project from Easter Bytes.  In this arrangement, we configured the Yun's WiFi as a standalone Access Point - visitors would simply connect to this network using a Mobile Phone web-browser, then take control.   This actually proved to be a real hit with many visitors to the museum, and was especially rewarding to get usability feedback from a 7-year old! (pictured)

You can see the simplicity of the set-up in the following photographs:

I've added the source code for this project to the Armdroid Library examples directory  https://github.com/Armdroid/Armdroid-Arduino-Library

If you wish to use the sample web page, you'll need to prepare a memory card by creating the directory structure "arduino/www" which ensures the Yun will create a link to the SD card "/mnt/sd" path.

The REST API is structured around verbs and Armdroid functions - for example, you want to move the shoulder stepper motor x steps, you would simply issue an HTTP web request like http://arduino/armdroid/shoulder/position/x.   Likewise, other Armdroid functions are described by their function - base, elbow, gripper etc.

If you wish to determine what is the current location for any stepper motor, you would use a URL such as http://arduino/armdroid/shoulder/position (without position value) and this will return in the response the offset counter for this channel.

The complete REST API comprises of the following URL structure:
  • http://myArduinoYun.local/arduino/armdroid/base/position : returns base motor offset counter
  • http://myArduinoYun.local/arduino/armdroid/base/position/x : rotates base motor x steps clockwise or counterclockwise
  • http://myArduinoYun.local/arduino/armdroid/base/position/x/y : rotates base motor x steps clockwise or counterclockwise at y revolutions-per-second
  • http://myArduinoYun.local/arduino/armdroid/base/sensor : returns base sensor reading
  • http://myArduinoYun.local/arduino/armdroid/shoulder/position : returns shoulder motor offset counter
  • http://myArduinoYun.local/arduino/armdroid/shoulder/position/x : rotates shoulder motor x steps clockwise or counterclockwise
  • http://myArduinoYun.local/arduino/armdroid/shoulder/position/x/y : rotates shoulder motor x steps clockwise or counterclockwise at y revolutions-per-second
  • http://myArduinoYun.local/arduino/armdroid/shoulder/sensor : returns shoulder sensor reading
  • http://myArduinoYun.local/arduino/armdroid/elbow/position : returns elbow motor offset counter
  • http://myArduinoYun.local/arduino/armdroid/elbow/position/x : rotates elbow motor x steps clockwise or counterclockwise
  • http://myArduinoYun.local/arduino/armdroid/elbow/position/x/y : rotates elbow motor x steps clockwise or counterclockwise at y revolutions-per-second
  • http://myArduinoYun.local/arduino/armdroid/elbow/sensor : returns elbow sensor reading
  • http://myArduinoYun.local/arduino/armdroid/wrist/pitch: returns both LHS and RHS wrist offset counters
  • http://myArduinoYun.local/arduino/armdroid/wrist/pitch/x : counter-rotates wrist motors to pitch gripper up/down
  • http://myArduinoYun.local/arduino/armdroid/wrist/pitch/x/y : counter-rotates wrist motors to pitch gripper up/down at y revolutions-per-second
  • http://myArduinoYun.local/arduino/armdroid/wrist/rotate : returns both LHS and RHS wrist offset counters
  • http://myArduinoYun.local/arduino/armdroid/wrist/rotate/x : rotates wrist motors to roll gripper clockwise/counterclockwise
  • http://myArduinoYun.local/arduino/armdroid/wrist/rotate/x/y : rotates wrist motors to roll gripper clockwise/counterclockwise at y revolutions-per-second
  • http://myArduinoYun.local/arduino/armdroid/wrist/left/position : returns LHS wrist offset counter
  • http://myArduinoYun.local/arduino/armdroid/wrist/left/position/x : rotates LHS wrist motor x steps clockwise or counterclockwise
  • http://myArduinoYun.local/arduino/armdroid/wrist/left/position/x/y : rotates LHS wrist motor x steps clockwise or counterclockwise at y revolutions-per-second
  • http://myArduinoYun.local/arduino/armdroid/wrist/left/sensor : returns LHS wrist sensor reading
  • http://myArduinoYun.local/arduino/armdroid/wrist/right/position : returns RHS wrist offset counter
  • http://myArduinoYun.local/arduino/armdroid/wrist/right/position/x : rotates RHS wrist motor x steps clockwise or counterclockwise
  • http://myArduinoYun.local/arduino/armdroid/wrist/right/position/x/y : rotates RHS wrist motor x steps clockwise or counterclockwise at y revolutions-per-second
  • http://myArduinoYun.local/arduino/armdroid/wrist/right/sensor : returns RHS wrist sensor reading
  • http://myArduinoYun.local/arduino/armdroid/gripper/position : return gripper motor offset counter
  • http://myArduinoYun.local/arduino/armdroid/gripper/position/x : rotates gripper motor to open/close fingers
  • http://myArduinoYun.local/arduino/armdroid/gripper/position/x/y : rotates gripper motor to open/close fingers at y revolutions-per-second
  • http://myArduinoYun.local/arduino/armdroid/gripper/sensor : returns gripper motor offset counter
  • http://myArduinoYun.local/arduino/armdroid/torque/enabled : returns a value indicating torque has been applied to all motors
  • http://myArduinoYun.local/arduino/armdroid/torque/enabled/x : enables/disables torque
  • http://myArduinoYun.local/arduino/armdroid/home : returns to home (starting) position
All responses are returned using JSON (JavaScript Object Notation) formatted replies allowing simplified parsing in many programming languages.

If your interested to understand how the code works - you need to first understand how the Bridge example works as a starting point - see https://www.arduino.cc/en/Tutorial/Bridge

Basically, each of the six channels (base/shoulder/elbow/left wrist/right wrist/gripper) are implemented using a command method as follows:

 void baseCommand(YunClient client)  
 {  
  String baseCmd = client.readStringUntil('/');  
  if (baseCmd.startsWith("position")) {  
   // read number of steps, if none have been specified, parseInt()  
   // will simply return zero which will be ignored, and we'll  
   // finish by feeding back current position to the client.  
   const int steps = client.parseInt();  
   if (steps != 0) {  
    // if the URL includes a speed value, use it  
    int whatSpeed = DEF_MOTOR_SPEED;  
    if (client.read() == '/') {  
     const int speedInRpm = client.parseInt();  
     if (speedInRpm > 0)  
      whatSpeed = speedInRpm;  
    }  
    // drive motor to rotate base clockwise/counterclockwise  
    driveMotor( ARMDROID_BASE_CHANNEL, steps, whatSpeed );  
   }  
   // send feedback to client  
   client.print(F("{\"base-position\":"));  
   client.print(getPositionReading( ARMDROID_BASE_CHANNEL ));  
   client.println(F("}"));  
  }  
  else if (baseCmd.startsWith("sensor")) {  
   client.print(F("{\"base-sensor\":"));  
   client.print(getSensorReading( ARMDROID_BASE_CHANNEL ));  
   client.println(F("}"));  
  }  
  else  
   client.println(F("ERROR: invalid base command"));  
 }  

The code begins by reading the client URL and tries to match the "position" command.  If this is present, we can then determine if the URL is specifying a value representing the position in which to drive the motors, or alternatively, we'll simply report on the current position.  If we do have a valid "position" command then we look to see if a speed has been specified.  If this is not the case, the default (120 RPM) will be used instead.

If the command matches "sensor" then we have the ability to return the current sensor reading for the given channel.

In either case, after calling the Armdroid Library to perform the desired function, we send feedback to the client such as the new position after the operation completes.


Limitations

Yun's web server times-out after approximately 5seconds when performing lengthy Armdroid operations.  This is mostly due to the design of the current Armdroid Library which is synchronous in operation, or blocking, when running motors for long periods of time.  In this situation, a response doesn't get returned from the microcontroller before the web server gives up, and returns 500 (Internal Server Error) back to the client.

This isn't immediately obvious using the example web page, although can be easily demonstrated when browser debugging is enabled:
Fig 1. short base rotation (200 steps)
Issuing the request /arduino/armdroid/base/position/200 rotates the base stepper motor 200 steps resulting in HTTP status code 200 (OK) returned.  You can see the reply includes our JSON response indicating the position (current offset counter) of this motor channel after performing the operation.

Now observe what happens when the request is made with 2000 steps:
Fig 2. lengthy base rotation (2,000 steps)
HTTP status code 500 is returned after 5seconds, and before the motor has finished running.  By the time the motor reaches the target position, the connection no longer exists, no response is returned.


We'll revisit this when Asynchronous enhancements have been added to the library, but in the meantime, you can work around this by calling the API to retrieve the current position and wait if necessary until the previous operation has completed.

The sample web page included with the example is very basic...  It serves purely as a demonstration only... if you want something with more sex appeal, you might want to look at DoJo or similar frameworks to create a richer experience.

Tuesday, 13 January 2015

Infrared Remote Control

I realise it's been a long time since writing anything here...

Today, I'm going to share with you my Armdroid Remote Controller project, which was quickly hacked together for demonstrating the Armdroid 1 during a recent meeting of volunteers at TNMOC.

The circuit makes use of a single TSOP4838 IR receiver module along with some rather cleaver programming that decodes key presses and operates various Armdroid functions.

I'll be including the source code for this project as an example sketch in the forthcoming release of Armdroid Library on GitHub.

The project works surprisingly well, although movements to preset positions are made point-2-point (P2P), which is slightly different to continuous path movements.  This is after all, a demonstration, although could be easily extended to support waypoints and recording/playback of movements.

I've been using an old Sky remote control handset, you'll need to change the scan codes to match your hardware, although instructions will be included how to do this.

Connecting an infrared receiver module is relatively simple, the sensor output is connected to a spare digital input on the microcontroller.

ArmdroidShield (version 1) utilizes pins 2-9 for connecting to the Armdroid's 8-bit parallel interface, so pin 10 was chosen for this purpose, along with +5V and Gnd connections.  There are many common IR receiver modules available.  Check the datasheet for your device to ensure that you connect it correctly.

The software works by decoding the IR signals to digital pulses that correspond to buttons on the remote.  A scan code lookup table is then used to assign Armdroid functions to key presses.   This table uses function pointers to simplify the program logic, also included are methods for Rolling/Pitching the Gripper, along with routines for calculating target offsets when moving to new positions.


Saturday, 15 November 2014

Arduino ArmdroidShield

The restoration of TNMOC's Armdroid is getting closer to completion, and attention has shifted towards designing suitable displays for the robot at the museum.

Initial displays are likely to be Arduino based, and in time, we'll probably add other historical computers into the mix.   In the meantime, something I had not given much thought about, was what to do with my 'temporary' breadboard interface that's been used over the past year, a more permanent solution is however needed.

So, a couple of weeks ago, I decided to design a PCB to be called.... wait for it.... ArmdroidShield !

Having a purpose made PCB will of course be more reliable, and better suited to a harsher museum environment.  The goal was to keep things flexible - perhaps we'll use these at a future Summer/Winter Bytes and students can design other Armdroid-based control systems, so making the board using a Shield design, was an obvious choice.

This was my first attempt at designing a double-sided PCB.  Fortunately, the design doesn't require many components, so from start to finish - 2hrs including inspection of final design, and correcting contacts positioned too close together.

The PCB arrived the following week directly from the fabricator, and as you can see the results are pretty good:

ARDUINO ArmdroidShield

The shield has been designed around the Arduino R3 header standard making it compatible with the following products:
  • Arduino Uno R3
  • Arduino Leonardo
  • Arduino Yun
  • Arduino Ethernet
  • Arduino Tre & Arduino Zero (when available)
It's a very simple board, really just an adapter - only Digital Pins 2 through to 9 are utilized, along with common grounds.

The tricky bit was soldering the Stackable Headers and keeping everything properly aligned, but with perseverance, got there in the end.

ARDUINO ArmdroidShield

ArmdroidShield on the Arduino Leonardo:


Completed assembly ready for bench testing:


Monday, 6 October 2014

TNMOC Armdroid 1

The restoration work is progressing well, a few issues remain with the gripper and timing belts.  Hopefully, we'll have this heading to the museum in a few weeks :
Pictured TNMOC's Armdroid 1 and power supply

Tuesday, 16 September 2014

Sensors

Finally, the original proximity sensors have been refitted to my Armdroid, and a new wiring harness completes the installation work.  As you may recall, they had been removed earlier when diagnosing tight-spots in the mechanics.



Machining new aluminum spaces was probably the most time consuming part.  The original spaces were in bad shape and had a tendency to rub on the reduction pulleys with the timing belts, this caused friction and as result, performance suffered.





The sensors are aligned perfectly to reduction gearing.  Setting up can be tricky - a multimeter comes in handy for testing, and making position adjustments.

All sensors have been positioned within a millimeter of reduction gearing, and more importantly, no longer make any physical contact.

The new 6-core wiring harness, connecting the four sensors mounted on the rear support bar, front-mounted gripper sensor, and Base position sensor was installed:


The hand sensor is still a mystery, see previous post Magnet Madness
For now, accepting the fact this won't do anything useful, have purposefully left disconnected and will decided later what I'm doing here.

Update:  Its a shame Colne Robotics didn't invest in designing a decent gripper tension feedback mechanism similar to that employed in the Microbot MiniMover-5 triggering a micro-switch contact under tension, or the gripper is completely closed.
Pictured to right - TNMOC/Armdroid showing sensor installed under Right-Hand Wrist function.  Not convinced this is correct either, sure, it will work, but leaves the Left-Hand Wrist monitored by only one sensor.

Another grey area in the instructions is chassis grounding - prototype models had their 7805 voltage regulator bolted to the chassis which grounds the circuit to the metal work.  Later, single-interface models do not do this, so a chassis ground cable was included in my wiring.   This will allow me to easily switch between interface circuits.


Tracing the circuit, the majority of the 14-pin header for the feedback sensors are ground connections.
Also, note, in Input Mode, the port address line D2 (header pin 8) is spare - no connection


This configuration is likely to change, but these are my current assignments:

Microswitch Assignment to Functions INPUT BIT CABLE / PIN
Forearm MS1 (D3) Yellow (13)
Left Wrist MS2 (D4) Brown (12)
Right Wrist MS3 (D5) Green (9)
Shoulder MS4 (D6) Pink (11)
Gripper MS5 (D7) Purple (9)
Base MS6 (D8) Blue-Green (14)


Monday, 25 August 2014

Bearings & Shoulder Rebuild

A rainy Bank Holiday in the UK, so what a better way to spend the day..... playing with Armdroids of course !!

Its been a while since touching my Armdroid, or the one being restored for The National Museum of Computing, and decided today, I would strip down the base, clean, and inspect every individual part before rebuilding again.

I've not previously covered anything on the Blog about the Bearing Assemblies, so thought this would be well worth some coverage here.

The following picture is a recap from last year, what my bearing assembly looks like:



This is a custom machined from Aluminum which forms the following components: (1) Base Bearing support column, (2) Shoulder Bearing support, and (3) Bearing adjusting ring (pictured with grub screw).  This is complimented by 24 ball bearings fitted around the upper and lower flanges.   Reading the construction notes, I imagine its quite a fiddle to assemble, keeping the ball bearings in place whilst turning over to work on the opposite side.

When first inspecting TNMOC's Armdroid, I always knew there was a difference with the bearings, but couldn't see clearly what was happening under all the dirt 'n grime, but, check this out - beautifully machined from solid brass



...which accepts flat needle-type roller bearings with steel shims for the upper and lower supports:



This is how the top of the assembly looks without the other assembles installed:


I'm guessing a previous owner made this as a repair, or perhaps an enhancement to the original assembly
Update:  After searching the internet and examining further photographs, I've now seen plenty of other examples of this arrangement, implying Colne Robotics introduced this as a later improvement.

The center bore for the cables is a lot narrower than the original assembly which does make feeding of cables tricky.  Another observation with this design - its no longer possible for users to make adjustments here.

The original assemblies can be easily damaged by cross-threading the adjustment ring, so be careful not to over-tighten if you need to make any adjustments here.

Having stripped all this down, gave it a jolly good clean, lubricated all moving parts, rotates like a dream now!

I've added more photographs of the rebuild below - might be useful if your rebuilding your base and shoulder and need a reference.

Saturday, 2 August 2014

Talk about Torque

The Armdroid Library on GitHub has just been updated with an enhancement allowing Holding Torque to be released or re-applied, and this is especially useful when recovering the robot after things have gone badly wrong, or runaway.

Holding Torque is defined as the amount of stationary torque required for a stepper motor to remain in a fixed position.

This is unlike operating torque (max and minimum) which is the torque a stepper motor can apply when experiencing zero resistance.  Changing voltage will of course, change this torque rating.  Additionally, there is stall torque, which is the torque a stepper motor requires when powered but held so it cannot rotate.

The specifications of the ID35 stepper motors used on the Armdroid are rated with a holding torque of 8.5Ncm (newton centimeters) and its almost impossible to manually articulate any joint while these coils are energized.  The enhancement made to the firmware library allows stepper motors to be freed under computer control, making it possible to manually re-position the arm.  The steppers can then be explicitly torqued again to hold the new position, or by simply running the motors again will indirectly do this.

Another potentially useful purpose is power saving when the arm is idle for long periods of time.

 void ArmBase::torqueMotors(boolean torqueEnabled)  
 {  
  for(uint8_t motor = 0; motor < 6; motor++)  
  {  
   MTR_CTRL* const mtr_ctrl = &mtr_control_table[ motor ];  
   // combine with coils off pattern + control bits if disabling holding torque, otherwise  
   // reinstate coil pattern from last step index  
   const uint8_t output = (torqueEnabled ? mtr_waveform_table[ mtr_ctrl->step_index ] : FREEARM) + mtr_ctrl->address + STROBE;  
   // write command to Armdroid port  
   armdroid_write( output );  
   armdroid_write( output - STROBE );  
   delay(1);  
  }  
  // ensure Armdroid is returned to Input mode  
  armdroid_write( STROBE );  
 }  

To accommodate this new method, a slight modification was necessary to the Armdroid Serial Remote Control protocol, but still remains compatible with the existing revision.