Leg walk test

Quick update, started putting together a bit of a test leg.  Here's a rough walking motion test.

For this test I had the leg moving at half it's maximum speed.

Servo Driver Test

I modified the ArduinoServoSample code in GitHub to better test out the drivers.  I plugged in 4 servos on digital pins 1-4 for load testing (only 4 because I only have a 1amp power supply, and each servo is drawing 250mA).

I did however tell the software that there were servos on every pin, so the drivers were working overtime.  I manually moved the connection of the 4th servo from pin to pin and checked it's speed.  Every pin worked with the exception of pins A6 and A7.  I did come accross this quote in the arduino port manipulation reference

"PORTC maps to Arduino analog pins 0 to 5. Pins 6 & 7 are only accessible on the Arduino Mini"

As I'm using a Fio, I have a feeling that they may not be available to me.

EDIT:  
Upon review of the Fio Schematics it looks like ADC6 and ADC7 are indeed not on PortC.  PortC pin 6 is attached to the reset.  PC7 is not shown.

I have also since noticed that when the servos are being told to stay still, they have a tendency to occasionally jitter a very small amount.  There are a myriad of possible causes for this, as it's not important for my current application so I am just going to note it and move on for now.

Servo power

The next part of the puzzle is going to be solving for the battery and power system for the servos.  I just got out a multimeter and tested the current draw.  While moving under no load the servos draw between 150 and 200 mA.  When not moving the servo blips on and off at around 10 mA.  Applying a resistive force to the servo causes the power consumption to jump up to it max of around 500 mA, depending on the amount of force applied of course.  Since this robot has almost no real resistance to apply to the servos, I'm going to generally assume around a 250 mA working draw.

Side note:  I've fixed a couple of bugs in the github repo.  If anyone actually uses the library and encounters any more, let me know.

Servo Controller Library

Ok,

So while the multi servo controller library is not done yet, initial testing seems good.  I do see a jitter issue, but I'm confident I can work it out.  Here's the code released under the MIT license, so feel free to do what you like with it.

https://github.com/teastman/com.roborec.servo

Let me know if you have any questions, I'll do my best to answer them.  I'm likely going to take a break from working on these now, as it's caused me to go a little bonkers pulling my hair out.  I think I'll work on some of the physical construction a bit more now.

Functional:

• Arduino Fio (other arduinos should not be hard to add support for)
• Move servo to a given location.
• Support for as many servos as you have pins available. There will be a practical limit, but I haven't hit it with 18 servos on the Fio.
• Various servo support via setting the manufacturers defined maxVelocity, minPulseWidth, and maxPulseWidth.
• Angle inversion
• Angle limiting
• Angle normalization

Still to come:

• Collision avoidance
• Angle inversion
• Angle limiting
• Angle normalization over the set limitation.

EDIT:
Cleaned the code up a bit and did some testing.  The jitter issue turned out to be a servo defect, replacing the servo fixed the problem.

EDIT (23/07/12):
Added support for inverting, limiting, and normalizing.

Timers and Comparators

I've learnt a couple of interesting things over the last couple of days fighting with why my drivers didn't seem to be working.  What I found was that I was unable to modify OCR1A while the timer was running, or rather, I was able to modify it, but only once per timer cycle.

The reason for this appears to be due to a mechanism the chip uses to update the OCR1A register called double buffering.

The chips documentation had this to say about it.

"The double buffering synchronizes the update of the OCR1x Compare Register to either TOP or BOTTOM of the counting sequence. The synchronization prevents the occurrence of odd-length, non-symmetrical PWM pulses, thereby making the output glitch-free."

So you can set OCRnA as often as you want, but it will only actually be set when the timer reaches 0.  This is highly problematic as changing OCRnA on the fly is essential to achieve the pin output complexities I am looking for.

This table from the documentation shows all the timer modes.

The only modes that update the comparators immediately are normal mode and CTC mode.  Normal mode is out as it always counts from BOTTOM to MAX and doesn't allow us to set the timer to 20us.

CTC could work, but it means that overflow can't be used.  What a pain.

I'm now in the process of rewriting the drivers to use CTC mode timer instead.  I'll likely post the resulting code on GitHub.

EDIT:  Sooo, after all that I wound up using Normal mode.  I use OCR1B to change between triggering at 2600, and 19999.  When the 19999 trigger happens I call what used to be the overflow_interrupt function, and reset the timer to 0.  Seems to work ok.

Servo Controller

After a lot of research I've decided to write my own servo controller library from scratch.  I'm going to write it as generically as possible for the AVR chipset and avoid Arduino specific code.  I'll likely release it as open source as soon as it's done.

The goal of the library is to provide an efficient method of providing PWM servo control output to any port on the AVR chip.  To do this is not as trivial as I'd hoped.

The problem:
Each servo needs to receive a signal every 20ms for a minimum burst of .6ms to a maximum of 2.4ms (varies depending on the servo).  Originally I'd thought about sending them out sequentially.  But after some though, parallel signals seem to really be the way to go.

I'm writing up the code right now and will post it along with a detailed description of what it's doing as soon as it's done.

Servo Control and Multiplexing

I've been thinking more and more about Servo control, PWM and multiplexing. As I need at least 14 servos for the project, the Fio only has 12 digital out pins, and only 6 of those are PWM pins. My first instinct was to buy a couple of 4051 mux/demux chips, drive them from dI/O pins and feed the signal from one of the PWM pins. While I still think this is a good idea, I think I now have one that won't require any hardware modification.

From what I've read a Servo needs to receive a signal every 20ms. During that 20ms if it receives a burst of about 1ms it will go to position 0, if it receives a burst of 2ms it will go to 180. Apparently this is depended on the exact specifications of the Servo, unfortunately I haven't found a specsheet for the DFRobot SER0006. I have found however that the default settings in the Servo library from Arduino seem to suffice. They are set to 544us = 0, 1500us = 90, 2400 us = 180. note: us = microseconds

Now, with a max required burst time of 2400us, and a required repeat time of 20000us. It's obvious that we can get 20000/2400 = 8.33 ~= 8 signals out per cycle. The Arduino Fio has an ATmega328P which has 3 timers on it, only one of which is a 16 bit timer (timer1). 16 bit is preferable because it means that we can address more angles.  Each timer on the controller has 2 comparators (2 outputs) which means that in a given 20ms span we can get 2*8 = 16 outputs.

The other major part of this puzzle is the number of pins we have accessible, luckily the Arduino documentation states that

While the main function of the analog pins for most Arduino users is to read analog sensors, the analog pins also have all the functionality of general purpose input/output (GPIO) pins (the same as digital pins 0 - 13).  Consequently, if a user needs more general purpose input output pins, and all the analog pins are not in use, the analog pins may be used for GPIO.

We can therefore use all a grand total of 20 pins.  With 16 PWM timer outputs per cycle we could theoretically have enough outs to control all the servos I need.

The Servo Library only accounts for up to 12 servos.  So I will need to either modify it or write a new one entirely.  I'm thinking the second is more likely as I want to add in collision avoidance and better limits.

Reference:  A good article about Arduino PWM

Leg Collisions

To prevent leg collisions I will be implementing this check.  If you assume that the top leg wants to swing down, then we need to find theta 1 which is the maximum allowable angle before a collision occurs.

Android test

Managed a fair bit yesterday, got most of the major code done on the Android app.  Here's a demo video of it connecting to the Arduino and controlling it.

There's still quite a bit to do of course, namely the following:


Arduino:

• Normalize input between 0-180 for set limits.
• Associate related Servos and set relation limits so that they can't cross.
• Make sure that the servos don't move outside their limits on startup.
• Write a Servo library for multiplexed servos.

Android:

• Crashes if move before bluetooth
• Preset movements
• Read back from the servos in case of dissallowed movements
• Read in from servos to map legs when walking.
• Leg animations

Physical:

• Build Styrofoam model of legs and body
• Figure out servo layout.

Electrical:

• 5v power supply for servos.
• Charging for servo power supply.
• 4051 multiplexers

Micro Quadcopters

After watching the following video today I think once I'm done this walker bot I'll take on the challenge of doing a micro quadcopter.

The only things I think I'd like to add is possibly a cell phone camera with a 360 degree lense.  Heck, with one on the top and one on the bottom you could technically do 360 stereoscopic vision.  Would be amazing little bots for mapping.

Android Arduino communication

I've managed to get my Android phone (Galaxy Nexus) and the arduino fio communicating over bluetooth.  There were a couple of things to watch out for however,

1. When programming the Bluetooh Bee you have to use a baud rate of 38400.  When it's in normal mode it will use whatever baud rate you have set via AT+BAUD.
2. Some android devices can't see Bluetooth devices that have a device class of 0 (which is the bluetooth bee default).  I'd suggest setting the device class, in my case the command looks like: "AT+CLASS=0x8C080C\r\n".  You can generate a device class numbers from this CoD Generator
3. For some reason my phone would not create a valid socket to the device using the standard createRfcommSocket.  After searching around a bit I found this tread, changing this code made it work.
4. Silly note, but:  you have to pair your phone with the device.  It is necessary to go to the bluetooth menu in the settings on the Android device, select the Arduino device (in my case called "DefilerBot"), and enter the pin.  The pin by default is "1234" but can be changed with the "AT+PSWD=1122" command.

// Change
tmp = device.createRfcommSocketToServiceRecord(MY_UUID_SECURE);

// To

Method m = device.getClass().getMethod("createRfcommSocket", new Class[] {int.class});

tmp = (BluetoothSocket) m.invoke(device, 1);

The base code for the Bluetooth connection and messaging came from the Android Bluetooth chat example.

My Bluetooth Bee Arduino config program now looks like this.

void setup(){

  Serial.begin(38400);

  Serial.write("AT+UART=57600,0,0\r\n");

  checkResponse();

  Serial.write("AT+CLASS=0x8C080C\r\n");

  checkResponse();

  Serial.write("AT+ROLE=0\r\n");

  checkResponse();

  Serial.write("AT+NAME=DefilerBot\r\n");

  checkResponse();

}

void checkResponse(){

  delay(500);

  String inputString = "";

  if(!Serial.available())

  {

     digitalWrite(13, HIGH);

     delay(1000);

     digitalWrite(13, LOW);

  }

  while (Serial.available()){

    char inChar = (char)Serial.read(); 

    inputString += inChar;

    if (inChar == '\n'){

      if(inputString == "OK\r\n"){

        digitalWrite(13, HIGH);

        delay(200);

        digitalWrite(13, LOW);

        delay(200);

        digitalWrite(13, HIGH);

        delay(200);

        digitalWrite(13, LOW);

        delay(200);

        digitalWrite(13, HIGH);

        delay(200);

        digitalWrite(13, LOW);

      }

      else

      {

        digitalWrite(13, HIGH);

        delay(1000);

        digitalWrite(13, LOW);

      }

    } 

  }

  delay(1000);

}

void loop(){

  digitalWrite(13, HIGH);

  delay(500);

  digitalWrite(13, LOW);

  delay(500);

}

Yay Servos

Servos arrived today!

Yay Servos!

Android Controller GUI

After spending a fair amount of time looking into using a PS3 controller, I decided it's just not worth it.  I could feasibly sink 2 months into building a comprehensive library that would work.  Instead I started looking into using my Android phone as the primary controller and got carried away.  The last couple of nights have been spent buried in code.  I've just now finished the initial elements of the GUI.

The above is a screenshot of the Android emulator running my code.  Each foot and the head have individual controllers.  Therefor if the user desires they can move each limb independently.  The large semi circle is what you see when you press one of the control nodes.  It shows the valid range of motion for the node.  If the user drags their finger outside of the valid area, the control node follows as closely as it can, but never goes outside the range.  Also note this supports multi-touch, so you can control multiple limbs simultaneously.

Still missing is a large circle in the center of the body for controlling global movement, like walking.  As well as some icons along the bottom for predefined moves like a swipe or a shake fist.

As for the back end, I still need to implement Bluetooth pairing and communication.

Bluetooth Cont.

Ok so I've been messing with bluetooth for the last few days and have consequently been bashing my head against the keyboard.

I wanted to be able to program the Arduino through the bluetooth bee wirelessly, but I'm not sure that it's actually possible.  I'll have to try a few more things yet.

Useful resources I have found are

DFRobot bluetooth bee wiki (kind of lacking)
DFRobot bluetooth bee PDF specsheet (extremely useful)

To test everything out I did the following.  Upload this sketch to the Arduino.


char val = 'e';

void setup(){
  Serial.begin(38400);
  Serial.write("AT+UART=38400,0,0\r\n");
  Serial.write("AT+ROLE=0");
}

void loop(){
}

This will set the bluetooth module into a slave mode and the baud rate to 38400.  I disconnected the FTDI cable and plugged the Bluetooth bee in.  I flicked the switch on the bee to "AT Mode", this allows it to be programmed.  I then plugged in the battery, waited 5 seconds, and unplugged it.  I removed the Bee and plugged the FTDI cable back in.

I then uploaded this sketch.


char val = 'e';

void setup(){
  Serial.begin(38400);
  digitalWrite(13, LOW);
}

void loop(){
  if(Serial.available() > 0){
      val = Serial.read();
      if(val == 'H'){
          digitalWrite(13, HIGH);
      }
      if(val == 'L'){
          digitalWrite(13, LOW);
      }
  }
  delay(250);
  Serial.write("loop\r\n");
}

I unplugged the FTDI, and plugged in the Bee.  I flicked the switch off of "AT Mode" and plugged the battery in.

I then clicked on the bluetooth icon on my computer and selected "add a new device", the bluetooth bee was listed.  Clicking on it, I selected pair with this device using a code.  The default code for this bluetooth device is "1234".  Once connected I right clicked on it and selected properties.  This will give you the COM # you need to talk to the device.

I opened putty from the radio buttons I selected serial.  I entered COM4 and 38400.  Clicked open.

Bam, now when I hit H the led comes on, L and it goes off.

Load testing

Got 2 new servos in yesterday.  1 x DFRobot Micro Servo Motor and 1 x Dagu Micro Servo Motor.

The specs seem to claim that they have a 1.6kg stall torque.  They seem so small I'm very curious if they'll actually be able to get anything close to that.  So I've devised an extremely primitive load test.

I taped together 50g worth of coins.  1 twonie, 2 loonies, 5 quarters, 1 nickel and 1 penny.  I put them on the end of a 10cm boom arm.  When the servo has the arm parallel to the ground it should be experiencing
t = 10 x 0.05 x sin(90) = 0.5 kg cm of torque.

Time to see how it holds up.

Edit:
PASSED!  with flying colours!  with the 0.5kg cm load it did not even blink.  The servo rotated just as quickly as it did with no load at all.   I'm impressed.

Quick note about the Dagu Servo... it's definitely much lower quality than the DFRobot one.  I won't be ordering any more of them.  Especially when they cost that much more.

Bluetooth

Wow I had no idea what I was getting into when I decided that I wanted to use a PS3 Controller to drive this thing around.  I still have no idea what I'm doing, but a few articles that have definitely shed some light on the subject are:

• Arduino Serial Interface
• The bluetooth bee is connected to the Rx/Tx pins of the Arduino Fio, so the serial interface is what's used to communicate with it.
• Bluetooth HID Spec
• Human Interface Device Profile (HID) is what the PS3 controller uses as a protocol.
• Bluetooth Bee Wiki
• Contains a list of valid commands that can be sent to the bluetooth bee in order to set it up.  note: the default pin is 0000
• Overall Explanation
• Found this to be a bit useful, although I am still utterly confused.  

I will report back when I have even the slightest understanding of WTF I am talking about.

Edit:

Been reading for a while now, and frankly it's looking like it is no small task to use the PS3 controller.  That said there seems to be a fair bit of community support for wii remotes.  I may have to change my spec to use one of those instead.

Arduino Wiimote Library

Edit 2:

Best complete PS3 BT code found yet. 

/Cheer

Ok, so I got a Servo running!  yay.

For the record, it does work on any of the pins, not just the PWM lines.

Tested using the sweep script and the servo library from the Arduino site.

(quick note about this pic... the power and the signal wires coming from the servo are reversed... oops.)

Let the cardboard prototyping begin:

Servos

So I popped by the local hobby shop and told them a bit about what I was doing.  They unfortunately didn't have a lead on any small cheap servos.  I figure I can go pretty cheap (sub $10) on these servos because the actual weight load and accuracy requirements are pretty minimal.  They did however think it was a pretty cool project and gave me a Server to test with for free.  Thanks!

Next step is to get an actual program running on the Arduino that can cause the servo to move.  As well as finding out if I need to be using a PWM pin out from the board, or if I can just use one of the regular digital I/O pins.

I'm thinking about sourcing the HXT900 ($5.85 > $81.90) from SolarRobotics.  It has fairly good reviews for being so cheap.  Other options are the Dagu Micro ($4.57 > $63.98) or the DFRobot Micro ($3.60 > $50.40) from Robot Shop.

I may just order one of each to test.  We shall see.

Components Arrived

Components arrived from Robot Shop today.

Overall, extremely happy.  They even showed up a day earlier than quoted.  YAY!

Now to source those silly servos.

Components

A few things came up yesterday as I was trying to source components.

The first thing I realized was that in order to get the legs to move much more realistically I will need 3 servos per leg.  Which comes out to 18 servos for the legs and 2 for the body.  Well the Arduino boards I like all only have 14 digital I/O pins.  So this poses a bit of a problem.  My first thought is to use a demux to give me more outputs.  Indeed this seems to be a viable option, the Arduino site has an article on using a 4051 Analog Multiplexer/Demultiplexer.  But to keep this project as simple as possible I'm just going to use 2 Servos per leg, with the addition of 2 for the body, that puts me at 14, which should work out perfectly.  Note that I'm still not sure if I need to be using the PWM lines only for driving the servos.  If this is the case, I will need to get 2 x 4051s and use PWM lines as the signal input.

The other major thing that came up yesterday was trying to buy the components.  I'm located in Canada so sourcing was getting to be a bit of a pain.  I first tried to order directly from sparkfun, but when the checkout screen got to the shipping options, I saw that shipping was going to cost me 50% of the cost of my order.  That in addition to the duties on the import was not looking very cost effective.  To resolve this I started looking for Canadian companies that sell Arduinos.  I managed to find a company located in Calgary called Solarbotics.  Their prices seem reasonable to me, as does their shipping.  The biggest problem here is actually that they don't sell the Arduino Fio that I wanted to buy.  So now I'll have to come up with a new parts list and try to find another way to skin the cat.

The design I'm now considering will use an Arduino Pro Mini as the primary micro controller.  In conjunction with the SparkFun Bluetooth Mate, I should be able to get similar functionality.  The one thing I can see still having to add is a charging circuit, of which I know nothing about yet.

Edit:

Ok so I found a site with reasonable shipping, no duties and everything I needed.  Ordered from robotshop, I picked up an Arduino Fio, FTDI Basic Breakout - 3.3V, DFRobot Bluetooth Bee, and a Polymer Lithium Ion Batteries - 3.7V 860mAh.  Grand total after tax and shipping: $105.

Defiler

So prior to deciding to start this project I had recently bought a defiler.  This will be pretty handy for measuring components.  I just took a couple of photos of it partially assembled with a ruler next to it to get an idea of it's size.

Torso   

Width : 2.5cm - 3.5cm

Length : 6.2cm

Height : Odd shape, wide portion is 0.5cm

Space in a 2x2cm box on the top

I will likely make up a couple of paper / cardboard templates to work with.  I think it will probably help with picking the right servos.

Legs

Trochanter : 1cm ball

Femur : 3.5cm

Tibia : 4.5cm

Tarsus : 2.5cm

Width : ~1cm

First Project

So I'm thinking that for my first project, what I'd like to do is create a Hexapod.  They have the wonderful property of being extremely stable, this alleviates a lot of potential problems for my first go.  The largest downside I can foresee is their complexity.  With 2 servos per leg, and 6 legs, it will be a challenging first.

My thought is to create a bot that I can skin to look like a Warhammer 40k Chaos Space Marine Defiler.

(image from http://www.games-workshop.com)

I think I can do this by sticking to some fairly small Servos and using an actual Defiler model as the structure.  I'd like to be able to walk it around a Warhammer game table and aim it's turrets.  To control it, I'd like to use a Sony Dualshock 3 Wireless Controller.  Having the ability easily control the bot is pretty essential.  Failing this I'd like to be able to control the bot via my android phone.  Either way the method of wireless communication is going to be Bluetooth.

I spent some time doing some research today and I believe that I'd like to use an Arduino as the micro-controller.  More specifically the Arduino Fio seems to be a good choice as it has USB charging capabilities, as well as pin outs for XBee wireless modules.  The board has 14 digital outs, 6 of which provide PWM.  To program the board I'll need to pick up an FTDI Basic Breakout board, the 3.3v version, not the 5v.  The final piece for the control circuit is the XBee board, however from what I've seen, none of them are actually Bluetooth capable.  In its place I plan to pick up a Bluetooth Bee HC-05 this should be plug and play with the Arduino Fio, but I can't be sure.

The next step is going to be to checkout some Servos.  Unfortunately I know nothing about these yet either.  I'm going to go to a couple of local hobbie shops and ask around.

Introduction

First blog post of my first blog.  Step 1

So today I watched this TEDx talk

It really got me thinking about what I'd like to do in life.  I've always had a real passion for building electro mechanical things.  The only real issue has been the excuses I've laid out for myself.  Well, enough of that, time to build.

The primary purpose of this blog is going to be to keep an account of everything I learn as I struggle through creating, what I consider to be, fun robotic projects.  I simply figure that if I keep a blog about it I will be able to reference back to why I chose to do things a certain way, and who knows, maybe someone else will learn something from my mistakes.