To my surprise over the approximately 3 month period since I last did some development, nearly all of the printed bar clamp parts have failed and those that are still in one piece, are showing serious signs of fatigue.

The obvious conclusion (looking at the above picture) would be that I had overtightened the frame around these parts, however I strongly refute this to be the cause and/or case and lay the blame on a combination of  both material properties and poor part design.

The nuts were only tightened just enough for the parts to grip both bars and function properly and in some cases no pressure was really applied at all, such as those used to support the Z axis rods (bellow).

I believe that over time the pressure of the frames construct, and in some cases also applied (within reason required by application) by the adjacent nuts, has caused the parts to fail.

Anyway I could point fingers an justify all day but what is important is that this was a major setback that needed resolving.

My solution was to design a new clamp that is more robust and also affords capability to apply grip.

What I came up with was a two half design that utilises pressure applied by the surrounding nuts to gift grip in one axis (the base). A solid body is used to relieve compression in this instance.

A 1mm gap between the top edge of the two halves above the bar and a bolt hole gifted so that just enough clamping force can be applied to the second bar if needed. The use of a maximum of 0.5mm worth of bend on each of the halves ensures that the flex is below that which would cause the plastic to snap and/or tear, however only time will tell

The above images show both the new and old clamp designs. As you can see both are pretty much equivalent in material volume. The only real impact in terms of cost is the requirement of a few additional nuts and bolts, however so far I have only needed two sets to apply a little additional pressure on the Z axis crossbar as shown in the image below.

This means that apart from these two instances, no additional pressure is applied to any of the clamps thus further reducing the potential for part failure.

The main impact caused by this issue was the need to completely reassemble most of the frame. This has severely delayed progress, however as you will be able to see in some of the images I have finally began to wire up the electronics.

So far I have managed to wire up the steppers and attach the cabling to the frame. I have also mocked up the end-stops and will finalise these when I have worked out placements, and the required lengths of wire etc.

As always I’ll finish with a image showing the current state of play.

Tomorrow I hope to attach the Y axis belt, finish installing the end-stops and finally run the motors for the first time. This will leave just the install of the extruder head and the base-plate.

Point one was easy to resolve, and after installing the drivers I soon had the Kinect up and running. Point 2 however, was a little more tricky, but also achievable via the development of a custom Kinect Robot Power Adapter.

Build Your Own Adapter 

In this post I will detail the steps I followed to create the adapter so that you too can add Kinect functionality to your robot or make use of your 360 Kinect with your PC without having to fork out £30+ on an equivalent PC adapter.

Why I Did It Like This

Whilst it is true that in reality I could have achieved the same outcomes via a little modification to the supplied Kinect cables. I also use the Kinect with my 360. Because of this factor I set myself an additional requirement, that no modification to the hardware was allowed. This meant that no wires could be cut and that the casing etc must all remain intact. If you too are worried about these issues then this is the adapter guide for you!

Investigation Of The Hardware

I decided early on that the best solution would be to fashion my own connector. This means that whenever I want to use the device for Koothrappali, all I need do is unhook it from its DC/USB adapter and plug it in. Careful examination of the Kinects bespoke adapter revealed that it be based on a standard USB type connection, however with a few major differences:

1. Its double sided
2. There are 5 pins on the second side instead of 4
3. The connections are slightly offset to the side.

The spacing between pins however was an exact match. With this in mind I concluded that I could approach the build in two ways: fashion a custom jack out of USB connectors or etch my own. Rather than invest time and resource (just in case the overarching concept was not feasible, also I hate chemicals and avoid whenever possible) I opted for option one.

Creating The Connector Heads

In order to build the heads I used three standard USB A plugs. First I separated the main connector boards.

The board it the white block with the connectors attached as shown in the image to the left.

You will also need to keep the little black wire keepers to hand, however the rest of unit can be put to one side and/or thrown away.

With the parts now ready I started on the 4pin head. If you line one of the boards connectors up with the Kinect sockets 4 pin side you will see that it almost fits perfectly however with a slight offset.

In order to fix this I cut away about 1/2mm from the respective side so that when inserted face to face the connections would line up. Next I sanded down the plastic lip surrounding the boards edge so that the contacts were proud. With this achieved the 4 pin head was complete. The following image (left) shows the head before and after (lower) modification.

Note the section cut away on the second board from top left through to the middle.

In order to fashion the 5 pin head (right, left) I had to cut away a section so that I could mount a new connector to the board. The new connector was removed from the as yet unused 3rd plug. This is done simply with a Stanley knife and a bit of care. As you can see in the image the cut away section is flush with the other connectors and reaches back into the middle of the body of the board. In my build I followed the line from edge of the adjacent connectors edge.

I then took the connector removed from the 3rd plug and super-glued it to the plug, ensuring a separation of about 1/2mm from the adjacent connector. The connector also needed bending twice at 90 degrees so that followed the edge of the casing (see wiring diagram below). Finally as with the 4 pin head, I sanded the surrounding rim so that the connectors are proud. With this achieved the 5 pin head was also complete.

Wiring The Heads

Next I had to work out the lines for each connection. This was done with a little play and a little googling for verification. The following image details the lines for each of the connectors. The line reading data Z should read data minus (my pen slipped, honest).

Please note that with the exception of the additional connection that the 5 pin head lines are equivalent to that of a standard USB connection. This factor formulated the basis of my wiring. I started the process by cutting a USB A cable in half and identifying the lines as follows (luckily I used a standard typical cable):

Red – 5Vcc
Black – Gnd
Green – Data z
White – Data +

Next I moved onto soldering lengths of wire to the heads. For simplicity I used equivalent colors for the known USB and GND lines and added Yellow for the 12V lines. At this stage I also twisted the GND’s together and the 12V lines together so that they in effect became 1 GND and 1 12V line.

I next began to fix the heads together. Be aware you will need to do a little sanding to the underside of each of the heads to ensure that they fit snugly into the Kinects adapter socket. Once I was happy with the fit I glued the heads together with superglue ensuring that they were lined up correctly to marry with the socket connectors upon insertion. At the same time I also fitted the two black cable keepers kept from earlier.

I then began to splice the wires to those of the usb cable.

Finally I also spliced 3 power connectors, a JST, PP3 and 2.5mm Jack to the GND and 12V lines. These provide the connection to your designated external power-source. In reality you will only need one but I thought I’d cover all bases and potential usage in a variety of contexts.

Before soldering and shrink insulating the connections I ran a few tests to ensure that everything was working. If you are having issues at this stage try checking your connections and ensure that your data +/- are the right way round (be careful as this could damage your PC and/or Kinect).

Once everything was working happily I then soldered and insulated the cables using cable shrink wrapping. The following images shows the fully soldered adapter cable.

Finally I wrapped the exposed cables with insulating tape and the adapter was completed (see top of post for image). As always Ill finish up with a quick video, this time demonstrating the adapter in action. An interesting outcome I noted during testing with my power-pack is that it seems that you can power the Kinect off only 8.5V.

The video demos this working for both camera streams and the motor (try at your own risk).

That’s it for this post, I hope you will find it useful. Currently I am working on a 11.1V power-pack for the Koothrappali build that will utilise this adapter via the JST connection. More information on this shortly. For preview postings and to find out what I’m at don’t forget to check out my facebook page.

The Haptic TrackPad

Designed primarily for those with visual impairment, the Haptic Track Pad is a peripheral input device that utilises force feedback to afford the user with an enhanced sensory experience in a similar manner found within contemporary gaming peripherals and mobile technologies such as smart phones and tablets.

To see prototype one in action check out the following video:

My research into Assistive Technology  peripheral development has indicated that on the whole as a device the standard laptop/net-book track-pad is usually completely abandoned by those with VI’s, resulting from artefact’s's such as incompatibility with screen readers and/or positional point of reference bearing.

This is a shame and a big problem especially as as we progress further towards Weisers Third Wave of computing. Many interfaces are now becoming touch screen dependant and as mobile and tablet computing grows in strength so too does an influx of potential new barriers for those with disability.

The Haptic TrackPad utilises a combination of technologies to alleviate the restrictions commonly found by those with visual impairment, for example PWM can be used to vary the feedback given for a variety of uses such as iconic hot-spot indication and/or physical boundary identification and even some novel uses such as per-pixel indication of image and/or colour.

Currently in its second prototype iteration, the pad is soon to be released as the second of my Open-Source Assistive Technology solutions which I hope will be built upon in an attempt to address the some of issues of future interface for those with disability and/or impairment, more details of this coming soon

Interfacing a PSP or DS Touch Screen with Arduino

The following sketch demonstrates simple interface of either a PSP or DS Touch Screen with an Arduino Pro and/or Pro Mini. In each case a breakout was used to provide connection to the Arduino via breadboard. The components used can be sourced as follows:

• PSP Touch Screen
• PSP Touch Screen Connector
• DS Touch Screen
• DS Touch Screen Connector

Both variants of the hardware utilise the same code and both connectors break out to the same connections. The only artifact that you will have to tweak in each case is the Offsets which are screen and usage dependant. These can be found within the main loop.

Just for ref, the following images show a PSP touch screen wired up to both an Arduino Pro and Arduino Pro Mini.

The PSPand DS touch screens are both a 4 wire analog resistive touch screen’s. This means by touching the screen at one point, a resistance between each edge is formed for both the x and y axises. As you move your finger across the screen the resistance changes between opposing sides of each axis. By applying a voltage across each axis, a changing resistance results in a changing voltage.

By way of result, simple Analog Digital Conversion (ADC) via four of the Arduino’s analog can be used to find x and y positions. The four  pins connected to the screen control 4 buss bars located around the screens edge. In order to read either an x or a y position, two opposing bars need to be powered and a third orthogonal bar is used to measure the divided voltage.

How this is applied in code can be seen in the following sketch:

// Set our pin id's
int y1 = A0;
int x2 = A1;
int y2 = A2;
int x1 = A3;

void setup()
{
// Period to allow for boot up
delay(6000);
// Initialise the serial port
Serial.begin(9600);
// Here we go...
Serial.println("Ready");
}

void loop()
{
// Get our X value
int x = readX();

// Get our Y value
int y = readY();

// Define our offsets (Screen dependant)
int Offset_X = 180;
int Offset_Y = 130;

if(x < 1000 & y < 1000){
Serial.print("x: ");
Serial.print(y-Offset_Y);
Serial.print(",y: ");
Serial.println(x-Offset_X);
}

// Slow things down for readability
delay(100);

}

int readX()
{
// Define the input lines
pinMode(y1, INPUT);
pinMode(x2, OUTPUT);
pinMode(y2, INPUT);
pinMode(x1, OUTPUT);

// Set the input lines
digitalWrite(x2, LOW);
digitalWrite(x1, HIGH);

// Dause to allow lines to power up
delay(5);

// Return reading
return analogRead(y1);
}

int readY()
{
// Define the input lines
pinMode(y1, OUTPUT);
pinMode(x2, INPUT);
pinMode(y2, OUTPUT);
pinMode(x1, INPUT);

// Set the input lines
digitalWrite(y1, LOW);
digitalWrite(y2, HIGH);

// Delay to allow lines to power up
delay(5);

// Return reading
return analogRead(x2);
}

That’s it, I hope that the code is self explanatory, however if you would like some more information as to how the system works check out the How Does it Work? data-sheet provided by Sparkfun here. If your still not satisfied, then sparkfun also provide a Touch Screen tutorial here, on which this code is based.

This post demonstrates the control of a Rover 5 Robot Platform via the use of an Arduino Pro and the Arduino Motor Shield R3. If you don’t have a Rover 5 or an Arduino Pro specifically, don’t worry as in theory the code can be used to control the shield with any variance of equivalents e.g. 2 DC motors and an Arduino Uno etc.

The Arduino Motor Shield R3

The Arduino Motor Shield lets you drive two DC motors with your Arduino board, controlling the speed and direction of each one independently. It also allows you to measure the motor current absorption of each motor.

The shield has two separate channels, called A and B, each or which can use up to 4 of the Arduino pins to drive and/or sense the motor. In total 8 of the Arduino’s pins are used by this shield. If steppers are more your thing, you can also combine A and B to drive one unipolar stepper motor.

One final thing to note about this shield is the addition of the SCL, SDA, IOREF and one other pin, reflective of the Arduino R3.

You wont find these sockets on the Pro and/or older variants of the Arduino, however, don’t worry this doesn’t affect the boards functionality. The only potential issue you might have is a little physical obstruction but this can easily be resolved by either not pushing the shield fully onto the board or by trimming the pins.

The Rover 5 Robot Platform

The The Rover 5 is a great platform for tank based robots. The variant of the platform used in this tutorial (available here) uses 4 independent motors, each with an optical quadrature encoder and gearbox. The entire gearbox assembly can be rotated at 5 degree increments for different clearance configurations.

For more information check out the platforms manual here.

The setting shown in the photos is that of the lowest clearance however as Koothrappali progress, I expect this to change. The base is very robust and  is documented at weighing in at over 2.5 pounds without batteries.

The main features of the platform can be summarised as follows:

• Adjustable gear box angles
• 4 independent motors
• 4 independent optical encoders
• Thick rubber tank treads
• 6x AA battery holder
• 10Kg/cm stall torque per motor

Wiring Rover 5 with the Arduino Motor Shield

Wiring up the shield for rudimentary motor control is dead easy. All you need to do is attach an external power source to the +/- inputs of the shield (check your data sheets to ensure that you are using the required voltage for your motors) and then connect your motors, one to channel A and the other to channel B.

Polarity is shown on the board, however I had to reverse the positive and negative on one channel to ensure that the motors run in the same direction when the direction control pins are both set to HIGH (more on this when we get to the code). As the Rover 5 has 4 motors, you will need to wire two in parallel to each channel, ensuring that they are paired by side.

One anoying thing about the Rover 5 is that it comes with its own custom connectors attatched to each of the motors (which I hav’nt managed to track down a male for) Rather than cut off the connectors I decided to fashon my own. This was achieved by taking a 4pin header strip and removing the middle two pins.

All in all 2 pairs of 2 connectors were created and soldered together so that the motors could be attached to the shield in parallel. To see how this was achieved check out the photos above.

One final item to mention in respect to wiring is that if you don’t need the shields brake and the current sensing abilities and/or you need more pins for your application. You can disable these features by cutting the respective jumpers on the back of the shield.

I haven’t done this in my setup, I have however cut the Vin jumper, thus removing capability for the Arduino to be powered via voltage from the shield.

This results in all the power applied to the shield being used solely for the turning the motors.

The Arduino Code

As with the wiring, the basic code needed in order to run the motors is dead easy.  Direction is simply handled by setting combinations of 2 pins to HIGH or LOW. Speed is controlled by using PWM on two further pins. The following table (as detailed at Arduino.cc) details the full pin assignment for the shield in terms of its interface with the Arduino.

Drawing from this deffinition we can easily draw up a simple script to get things running. Using the above table lets start with the properties:

//PWM control for motor outputs 1 and 2 is on digital pin 3
int pwm_a = 3;
//PWM control for motor outputs 3 and 4 is on digital pin 11
int pwm_b = 11;

//direction control for motor outputs 1 and 2 is on digital pin 12
int dir_a = 12;
//direction control for motor outputs 3 and 4 is on digital pin 13
int dir_b = 13;

// break control for motor output 1 and 2 is on digital pin 9
int brk_a = 9;
// break control for motor output 3 and 4 is on digital pin 8
int brk_b = 8;

As you will be able to see, currently I have left out the current sensing definitions this time around, however I plan to detail their implementation in another post along with the wheel encoders etc, for now were just concentrating on getting things moving

Next we need to set up the pins, this is done within the scripts setup function:

void setup()
{
  pinMode(pwm_a, OUTPUT);
  pinMode(pwm_b, OUTPUT);
  pinMode(dir_a, OUTPUT);
  pinMode(dir_b, OUTPUT);

  pinMode(brk_a, OUTPUT);
  pinMode(brk_b, OUTPUT);

  Serial.begin(9600);
}

I have also included initialisation for the serial for debug purposes. You may need to change the baud-rate here to reflect your setup. Next we are onto the loop. The following loop example demonstrates simple forward and backward motion and use of the breaks:

void loop()
{
  // First set the direction (in my setup FWD is LOW and BCK is HIGH)
  digitalWrite(dir_a, LOW);  //Set motor direction, 1 low, 2 high
  digitalWrite(dir_b, LOW);  //Set motor direction, 3 high, 4 low

  Serial.println("Direction Fwd");

  //set both motors to run at 100% duty cycle (fast)
  analogWrite(pwm_a, 255);
  analogWrite(pwm_b, 255);

  Serial.println("Full Speed");

  // We use a delay to define a period for the motors to run
  delay(2000);

  // Apply the breaks
  digitalWrite(brk_a, HIGH);
  digitalWrite(brk_b, HIGH);

  Serial.println("Break On");

  // Change the direction (in my setup FWD is LOW and BCK is HIGH)
  digitalWrite(dir_a, HIGH);  //Reverse motor direction, 1 high, 2 low
  digitalWrite(dir_b, HIGH);  //Reverse motor direction, 3 low, 4 high

  // Remove the breaks
  digitalWrite(brk_a, LOW);
  digitalWrite(brk_b, LOW);

  Serial.println("Break Off");
  Serial.println("Direction Bck");

  // Again use a delay to define a period for the motors to run
  delay(2000);
}

The above code will make the Rover 5 move forward of a period of 2000 then reverse for another 2000 period. Please not that we don’t have to use the breaks. If we want to stop the platform this can be achieved by setting the duty cycle to zero, however the break works instantly. By varying the value of duty cycle (0-255) we can vary the speed of the motors (0-100%).

In order to make the Rover 5 turn all we need to do is set each of the motors in opposing directions:

  digitalWrite(dir_a, HIGH);
  digitalWrite(dir_b, LOW);

That’s it really. In a future post I will expand upon this example to show you how to control your bot via use of a XBox360 Pad. Additionally I also plan to expand upon the example by detailing use of both current sensing and the wheel encoders.

But until then check out the following video to see the code in operation:

The code for this post can be downloaded from here.

These examples can be found dotted around the File>Examples> within the Arduino IDE. However, the example primarily used for basis of this  tutorial (also available online here) can be located via File>Examples>Communication>SerialEvent. SerialEvent() is a function which is called after loop() whenever  new data has been recieved over serial RX.

With minimal expansion to this example code its quite an easy task to add methods for data parsing via use of delimiters, thus affording functional instructions and/or commands to be sent between devices.

The following tutorial demonstrates the use of the strtok_r() function to parse an incoming string, so that it can be used to call independent functions and set property values. At the heart of the presented code is a function called ParseSerialData() which utilises strtok_r() to separate the received string each time there is a comma “,” present. Then depending upon how many chunks of data have been identified the function calls one of two (but not limited to) switch statements that are used to determine what we want to do with the received data.

In order to effectively demonstrate this, the use of an analog output on pin 9 is used to control the brightness of a LED. This in turn is reflective of the Arduino fading tutorial also available via the IDE, File>Examples>Analog>Fading.

If you don’t have an LED to hand (???) then don’t worry you will still be able to run the code and see its functionality via the Arduino Serial Monitor (Tools>Serial Monitor or Ctrl+Shift+M) or you could even use a dc motor etc

Onto The Code

Lets start by looking at the SerialEvent code itself. This function is called whenever incoming data present over serial RX. It is important to remember that as the data is streamed over the connection, as such it won’t necessarily all arrive at once. In order to cater for this a while loop is used to capture the data if it is available and/or until we tell it to stop.

This is so we can determine  a complete message and is achieved by evaluating whether each of the received characters is a designated termination character ‘\n’ , or in English, we read the data until we detect a new line call.

As we receive data we add it to a pre-defined char array called inData. The location of the data within the array is controlled via an index value, conveniently called index Each time we add to the array we also increment index so that we are ready for the next char etc.

Once all the data is received we reset index to zero ready for the next event and set a flag stringComplete to indicate that the data is ready to be parsed.

void serialEvent()
{
// Read while we have data
while (Serial.available() && stringComplete == false)
{
// Read a character
char inChar = Serial.read();
// Store it in char array
inData[index] = inChar;
// Increment where to write next
index++;
// Also add it to string storage just
// in case, not used yet!
inString += inChar;

// Check for termination character
if (inChar == '\n')
{
// Reset the index
index = 0;
// Set completion of read to true
stringComplete = true;
}
}
}

Each iteration of the main loop looks at the status of the stringComplete flag and if it is set to true we then calls the function ParseSerialData(). Upon completion of data parsing the flag is reset to false so that the system can continue listening for new data. Synchronisation is handled via the fact that the SerialEvent() call is only available after the completion of each loop.

void loop()
{
if (stringComplete)
{
// Parse the recieved data
ParseSerialData();
// Reset inString to empty
inString = "";
// Reset the system for further
// input of data
stringComplete = false;
}
}

As indicated the ParseSerialData() function is the place where we do all our evaluation and filtering of the received data.As previously stated, by using the strtok_r() function we split our received char array up into chunks each time we find a designated delimiter, which can be anything but in this case is is assigned as a comma “,”. Each time a chunk is identified it is then added to another pre-defined array called inParse. As with the SerialEvent() inString array the position of the data within the array is handled via the increment of an index value, this time called count.

Count is also used to determine how many chunks of data our received string contains. This is then used as a rudimentary filter for determining what we want to do with the received data via simple if statements e.g. if we have two chunks of data do this or if we have three then do that.

This example uses this to determine which out of two switch statements to apply to the data. This can be rationalised down and the cases could be used to populate additional properties dependant upon count, however this system keeps things simple and gifts provision for population of pre-defined properties if the application requires them to be globally available instead of dynamically (ref, char *func = inParse[0];) etc.

Finally the determined switch statement is used to call and pass data to a function depending upon an identifier “func”, the first chunk of our data. The code demonstrate the use of two switches and three independent function calls.

void ParseSerialData()
{
// The data to be parsed
char *p = inData;
// Temp store for each data chunk
char *str;
// Id ref for each chunk
int count = 0;

// Loop through the data and seperate it into
// chunks at each "," delimeter
while ((str = strtok_r(p, ",", &p)) != NULL)
{
// Add chunk to array
inParse[count] = str;
// Increment data count
count++;
}

// If the data has two values then..
if(count == 2)
{
// Define value 1 as a function identifier
char *func = inParse[0];
// Define value 2 as a property value
char *prop = inParse[1];

// Call the relevant identified function
switch(*func)
{
case 'A': FunctionA(prop); break;
case 'B': FunctionB(prop); break;
}
}

if(count == 3)
{
// Define value 1 as a function identifier
char *func = inParse[0];
// Define value 2 as a property value
char *prop = inParse[1];
// Define value 3 as a period
char *prod = inParse[2];

// Call the relevant identified function
switch(*func)
{
case 'A': FunctionA1(prop,prod); break;
}
}
}

Ok our data is now parsed, so lets have a look at the example functions to see how it can be used. If we were to send the command A,100 this would be separated into two chunks “A” and “100″ the “two chunk switch” would then use the first chunk “A” to determine to send the “prop” value of “100″ to FunctionA.

void FunctionA(char *prop)
{
// Output the data
Serial.print("FunctionA: ");
Serial.print(prop);
// Output new line
Serial.println();
}

FunctionA() then simply returns the value so that we can see it has been triggered via use of Serial.print(). Ok so we have the ability to call a designated function lets go a little further and use the property value to do something. If we now were to send the command B,100 this would also be separated into two chunks “B” and “100″ the “two chunk switch” would then use the first chunk “B” to determine to send the “prop” value of “100″ to FunctionB().

void FunctionB(char *prop)
{
// Convert prop to int
int val = atoi(prop);
Serial.print("FunctionB: ");
Serial.print(val);
// Output new line
Serial.println();
// Set value of pin 9 to val
analogWrite(9, val);
}

FunctionB however also contains some additional code that converts the property sent to an integer via use of atoi() which can then be used to set the Pulse Width Modulation PWM value of pin 9 and by way of result we can now use serial commands to control the brightness of the LED.

In order for this to be utilised effectively please remember to use values between 0-255 only, however for this sample it is deemed that this factor is a responsibility of the desktop app (ok cop-out) . For more information on this please refer to the Arduino PWM tutorial and the Arduino Fading examples.

Now lets have a look at sending data that consists of 3 chunks such as command A,100,1000. In this scenario the ParseSerialString() function would determine a count of 3 chunks “A”,”100″ and “1000″ aby way of result this time around the “three chunk switch” would be called and as our first chunk is “A” it then calls FunctionA1() passing it a prop value of “100″ and a prod value of “1000″.

In this case, as with functionA() all we do is return this via Serial.print(), however as with example FunctionB() we could use this data to operate an output. The additional value of prod could then be also used to determine extended functionality such as a period to apply this setting and/or a number of iterations to apply etc.

A good example of this could be for motor control e.g. turn the motor at half speed for 1 second, the possibilities are endless

Finally in order to use the code we need to initialise the serial link on setup() this is simply achieved via use of the Serial.begin() command as shown in the following code:

void setup()
{
// Delay to facilitate start up of Xbee usually about
// 5 seconds. Comment out if using wired serial etc.
delay(6000);

// Initialise the serial port
Serial.begin(9600);
}

I have also added a delay to the start-up to allow for start-up time when using an Xbee for wireless communication. This can be removed without effect if you are using a standard cable link. You also might want to change the baurdrate from 9600 to reflect your requirements etc.

That’s it for this time, I hope you find this tutorial a useful introduction to Arduino serial string parsing. The full sketch for this tutorial can be downloaded from here. Any comments and/or suggestions for improvements are welcome.

The device can be used to provide head tracking capability for natural user interface(s) and VR and is soon to be released as an open source project just as soon as I have finished putting together a little accompanying windows app and library etc. If you cant wait a few days send me a mail and i’l see what I can do beforehand (you will just need to parse the serial stream).

The EarTrack is to be the first of many open source projects demonstrating my research into Assistive Technology and Natural User Interface peripheral development.

More information and a how to guide to follow shortly

I thought long and hard before my initial purchase and after a little research and also by drawing upon my experiences with the Netduino platform I opted to go for 3V3 variants of the Arduino platform whenever possible. The rational for this decision were factors such as easier integration with the majority of  the breakouts that i’ve collected over the last few years and/or provision of power etc.

I always found 5V to be a real pain with the Netduino Mini.

The other advantage of this decision is affordance for unmodified distribution across each of variant, meaning that I can develop utilising the Pro and the same code (and circuit – most of the time) will also work on the other hardware… take note Netduino!

So without further ado let me introduce you to the hardware:

1. The Arduino Pro

The Arduino Pro! produced by SparkFun is as SparkFun quotes a “minimal design approach to Arduino”. The version I opted for is a 3.3V Arduino running the 8MHz bootloader (select ‘Arduino Duemilanove w/ 328′ within the Arduino software), but they are also available in a 5V / 16 MHz version.

The board has 14 digital input/output pins (of which 6 can be used as PWM outputs), 6 analog inputs, a battery power jack, a power switch, a reset button, and holes for mounting a power jack, an ICSP header, and pin headers. The six pin header can be connected to an FTDI cable or Sparkfun breakout board to provide USB power and communication to the board.

When powered by battery the header can be connected directly to a wireless solution such as a Bluetooth Mate Gold or Xbee radio to provide the unit with capability for wireless capability.

SparkFun state that the Arduino Pro is intended for semi-permanent installation in objects or exhibitions. Be aware that if you are thinking of getting one of these boards that it comes without pre-mounted headers. On the upside this allows for the use of various types of connectors or direct soldering of wires if your application so desires.

The pin layout is compatible with Arduino shields with the physical make up of the board mimicking that of the standard Arduino, however slightly shorter in length measuring in at 2.1×2.05″ (53.34×52.08mm).

Summary of Features

• ATmega328 running at 8MHz external resonator
• Low-voltage board needs no interfacing circuitry to popular 3.3V devices and modules (GPS, Accelerometers, sensors, etc)
• USB connection off board
• 3.3V regulator
• Max 150mA output
• Over current protected
• Reverse polarity protected
• DC input 3.3V up to 12V
• Resettable fuse prevents damage to board in case of short
• Power select switch acts as on/off switch

2. The Arduino Pro Mini

The Arduino Pro Mini again produced by SparkFun is their minimal design approach to Arduino. Once again I opted for the 3.3V version of this Arduino running the 8MHz boot-loader, but as with the standard Pro the board is also available in a 5V 16MHz variant.

The board has 14 digital input/output pins (of which 6 can be used as PWM outputs), 6 analog inputs, an on-board resonator, a reset button, and holes for mounting pin headers. A six pin header can be connected to an FTDI cable or breakout board to provide USB power and communication to the board.

The boards ATmega168 has 16 KB of flash memory for storing code (of which 2 KB is used for the boot-loader). It has 1 KB of SRAM and 512 bytes of EEPROM (which can be read and written with the Arduino EEPROM library).

Summary of Features

• ATmega328 running at 8MHz with external resonator (0.5% tolerance)
• Low-voltage board needs no interfacing circuitry to popular 3.3V devices and modules (GPS, accelerometers, sensors, etc)
• USB connection off board
• Supports auto-reset
• 3.3V regulator
• Max 150mA output
• Over current protected
• Reverse polarity protected
• DC input 3.3V up to 12V
• On board Power and Status LEDs

The overall dimensions of the board are 0.7×1.3″ (18x33mm) and it weighs in at less than 2 grams.

3. The Arduino Fio

The Arduino Funnel I/O (Fio) is a board designed by Shigeru Kobayashi in conjunction with SparkFun. As with the other two boards the Fio runs at 3.3V and 8 MHz, but this time utilising a ATmega328P chip.

The board has 14 digital input/output pins (of which 6 can be used as PWM outputs), 8 analog inputs, an on-board resonator, a reset button, and holes for mounting pin headers. It has connections for a Lithium Polymer battery and includes a charge circuit over USB. The prodominant feature of the Fio is an XBee socket available on the bottom of the board gifting the board with built in wireless capability.

The onboard miniUSB connector is used for battery charging only, as with the other boards, to bootload new firmware, you will need an external serial connection over an FTDI Basic, cable, or other serial connection.

Summary of Features

• ATmega328V running at 8MHz
• Arduino Bootloader
• XBee socket
• Lithium Polymer battery compatible
• MCP73831T LiPo Charger
• Reset button
• On/Off Switch
• Status/Charge/RSSI LEDs

The dimensions of the Fio PCB are approximately 1.1″ x 2.6″.

So with the introductions now out of the way over my next few posts I plan to introduce the Arduino platform and some of the  code that I have developed over the last few months in the realisation of several Assistive Technology products and Natural User Interface hardware(s).

A lot has happened since my last posting including the successful defence of my thesis in last December, a massive New Years Eve bash followed by the birth of my second grandchild in January, the realisation that I could not be bothered to buy a Kinect for Windows (Yet) in February and seeing Rammstien (check out the vid) live for the first time last week

As far as this blog goes however the major event of which you will probably be most interested (judging from page stats) is a shift in technology focus from that of Netduino and the .NetMicroframework to that of Arduino and C/C++.

Initially driven by the development of project Leonard and a desire to learn both C and C++ in readiness for the advent of Metro (just in case lol) I quickly fell in love with Arduino and have not looked back.

The transition over to the platform has enabled me to finally realise many personal projects that have in reality been hampered by the immaturity and limitations of the Netduino platform. Gone are factors such as limited access to USB/HID, lack of software serial, shield and related technology compatibility to name but a few.

In addition to the Arduino transition I have also made a real push into Windows Phone development. From now on the .Net aspects of this site will primarily reflect this new interest in conjunction with tablet based NUI development. However this may change with the advent of updates to the .Net Micro framework and or investigation of Fez hardware (just like dad lol).

These shifts in focus have got me thinking about how I would like to further develop this website and my personal profile. The first step on this new and exciting path is a revamp of the look and feel of dyadica.co.uk , I hope you like it

The default Prusa couplings just would not grip the 8mm shaft, even when tightened to and/or even past full capacity. A little research of the RepRap wiki revealed another potential design solution as made by Chris Hanton, however I would need to machine the part. Instead I decided to utilise the design as a basis for the development of a printable solution. The above picture shows the bespoke part and the original coupling (with tightening damage).

As you can see the new design is much simpler in implementation.

Essentially the part has been dimensioned and shaped so that the bar can be used to cut a thread into the plastic forming a tight grip. The grip is further enhanced via use of a grub screw in the form of a 3mm * 10mm bolt. Once again the hole has been dimensioned so that the bolt is self threading, cutting into the plastic upon tightening. This can be further enhanced via use of a pillar drill to form a slight recess in the bolt so that the grub prevents turning.

In order to thread the socket the bar needs to be turned slowly into the shaft with mild pressure until it hits the step inside where the hole transitions from 8mm to 5mm. Once completed a bolt is tightened against the base of the socket. Care must be taken at this stage not to force the threaded socket to unscrew and/or the cut thread to break. This is not a problem if the grub is attached beforehand. The above images show the socket befor and after threading.

Once complete the stepper shaft is then pushed into the 5mm hole until it meets with the 8mm bolt. This is a tight fit as I dimensioned the hole smaller than the stepper shafts. Again a pillar drill can be used to create a recess to enhance the effect of the grub. Also as before the bolt is self tapping. The following image shows the completed unit with the grubs threaded and attached.

With the coupling issue resolved Its time to get back to finishing the build of the Z axis. I started by attaching the plastic bushings to both the X carriage idler and motor mounts. I eventually plan to replace these with a more robust bushing and/or bearing option so this was done via application of a small amount of superglue to the base of each bushing only.

This will enable me to easily snap them off when the time comes for an upgrade, but due to application use, is also robust enough for temporary and/or short term use. At this stage I realised that I have seemed to have not received or forgot to obtain (must check my parts order!) needed to implement backlash prevention on the Z axis (the two large springs mounted in the X carriage ends). This means that I will not be able to fully complete the mounting at this stage but will be able to get things assembled for a few functional tests.

With this in mind I then mounted the motors and shafts on the frame and provisionally mounted the X carriage. The above images show the positioned motor and new Z coupling attatched to the main frame (left). Also included above (right) is the default coupling setup, for comparison.

As always I’ll finish up with an image showing the current state of the build:

I hope you will agree things are really beginning to take shape now and the build is well on its way. Tomorrow I hope to finish off the rest of the X carriage by mounting the stepper and the pulley belt. If I get chance I’ll also mount the Y belt leaving me with just the inclusion of the backlash springs (as soon as I get hold of some) in order to finish the frame and/or mechanical elements of the build.

As promised yesterday I have uploaded the .stl for the Z couplings here. Feel free to download it if you wish however please be aware that I plan to decrease the diameter of the hole for the 8mm bar so that a greater grip can be achieved (although perfectly functional, I believe that this will greatly enhance the robustness of the design). I will upload this .stl also as soon as I have finished drawing/updating the CAD and have had chance to print and test etc.

Update: I have included a second .stl in the download, however please be aware that I have not tested it yet. Its only a .2mm difference though so should be ok its up to you. The original I used is the 2.6mm option, enjoy

Eventually one of the couplers snapped due to purpose over tightening (not surprisingly) and this brought a halt to proceedings for most of today’s build. The above image shows the snapped coupling. Despite this issue however, I decided to continue mocking up the axis so I could get a feel of how things go together ready for my next attempt.

Once completed I decided to have a go at developing my own coupler utilising the “more durable design” developed by Chris Hanton and as suggested at reprap.org.

The following images show what I came up with:

The large hole (right) will be threaded and two 3mm bolts are to be used to clamp both the rod and motor shaft firm. If they work I’ll upload the .stl’s so that others can use them If they so wish. Otherwise if you are doing a Prusa build I recommend that you go for the Haton coupling design.

The following image shows the current state of play with the mocked up Z Axis.

As you can see Leonard is beginning to look like a RepRap. Rather than do nothing I then decided to have a go at putting together the extruder. All in all the print-head came together quite smoothly, however I did need to clear out the 4 channels that spring load the keeper head.

Hopefully tomorrow I will be able to print out the new couplings at work and the build can continue. If not on to the electronics